A Community of Verification Professionals

Create an Account	Home | Calendar | Downloads | FAQ | Links | Site Admin | Your Account
Modules · Home · Downloads · FAQ · Feedback · Recommend Us · Web Links · Your Account Advertising Who's Online There are currently, 25 guest(s) and 1 member(s) that are online. You are Anonymous user. You can register for free by clicking here Login Nickname Password Security Code: Type Security Code Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.    Verification Guild: Forums  Forum FAQ   Search   Usergroups   Profile  Digest    Log in  Module vs Program block?          Verification Guild Forum Index -> Main View previous topic :: View next topic   Author Message Dhaval Senior Joined: Feb 16, 2006 Posts: 90 Posted: Mon Mar 15, 2010 11:51 am    Post subject: Module vs Program block? What is the diff between module and program block? why cant we use module to start the testbench instead of program block? Dhaval Back to top dave_59 Senior Joined: Jun 22, 2004 Posts: 710 Location: San Jose Posted: Mon Mar 15, 2010 9:51 pm    Post subject: Re: Module vs Program block? Dhaval wrote: why cant we use module to start the testbench instead of program block? Dhaval, Who ever said you couldn't. See my article at http://blogs.mentor.com/verificationhorizons/blog/2009/05/07/programblocks/ Dave Back to top Dhaval Senior Joined: Feb 16, 2006 Posts: 90 Posted: Mon Mar 22, 2010 7:07 am    Post subject: Fair enough Dhaval Back to top pavanshanbhag Senior Joined: Mar 25, 2009 Posts: 271 Location: Bangalore Posted: Mon Mar 29, 2010 6:23 am    Post subject: Hi Dhaval, Quote: why cant we use module to start the testbench instead of program block? The main advantage of using a program block is it avoids race conditions . Sometime people wonder how race condition is avoided in program block. The simplest answer to it is program block executes in re-active region , thus avoiding the race condition w.r.t. TB <-> DUT _________________ -Pavan K Shanbhag “The difference between genius and stupidity, genius knows his limits.” - Albert Einstein Back to top Dhaval Senior Joined: Feb 16, 2006 Posts: 90 Posted: Mon Mar 29, 2010 6:27 am    Post subject: Pavan, Isn't clocking block in interface takes care about race condition between TB and DUT? Dhaval Back to top pavanshanbhag Senior Joined: Mar 25, 2009 Posts: 271 Location: Bangalore Posted: Mon Mar 29, 2010 6:49 am    Post subject: Hi Dhaval, Quote: Isn't clocking block in interface takes care about race condition between TB and DUT? A clocking block assembles all the signals that are sampled or synchronized by a common clock and define their timing behaviors with respect to the clock . But, the thief lies in executing of mulitple events in a simulation time slot thus the execution of program block in the reactive region come into picture in avoiding race conditions. _________________ -Pavan K Shanbhag “The difference between genius and stupidity, genius knows his limits.” - Albert Einstein Back to top dave_59 Senior Joined: Jun 22, 2004 Posts: 710 Location: San Jose Posted: Mon Mar 29, 2010 3:26 pm    Post subject: pavanshanbhag wrote: But, the thief lies in executing of mulitple events in a simulation time slot thus the execution of program block in the reactive region come into picture in avoiding race conditions. Pavan, Please read my article. It is a myth that program blocks prevent race conditions. Dave Back to top pavanshanbhag Senior Joined: Mar 25, 2009 Posts: 271 Location: Bangalore Posted: Tue Mar 30, 2010 1:51 am    Post subject: Hi Dave, Initially thanks for your quick response. Im a bit confused when I read your article, please highlight me on it : Quote: 1. Erroneous use of blocking assignments for sequential logic. You have a race within your DUT regardless of the race between your testbench and DUT. 2. Erroneous use of non-blocking assignments in combinational gated clock logic. You may have a race within your DUT regardless of the race between your testbench and DUT. I believe its the other way around. In sequential logic we use NBA and in combinational blocks we use BA. Isnt this true to avoid races. Quote: Using a clocking block by itself takes care of the same testbench to DUT races that a program block addresses, plus it takes care of the races caused by non-zero delay skews introduced by gate-level propagation. It does this by the use of the input skews for sampling and output skews for driving. I do agree on it , since skew level for sampling/driving facilitates setup and hold time ... Inbetween question of avoiding races by incorporating a program block is still a puzzle to me. I think the re-active region executes @ end of every time slot , thus updating the value @ next posedge of system clock... Would be very appreciative if you please elongate on it _________________ -Pavan K Shanbhag “The difference between genius and stupidity, genius knows his limits.” - Albert Einstein Back to top Dhaval Senior Joined: Feb 16, 2006 Posts: 90 Posted: Tue Mar 30, 2010 8:21 am    Post subject: If there is no diff between program and module, why redundancy was added? 1. why most of the test-benches use program block as starting point of their TB? Why module is not used instead? Is it just lack of awareness? 2. Why always block is not allowed in program block? Dhaval Back to top pavanshanbhag Senior Joined: Mar 25, 2009 Posts: 271 Location: Bangalore Posted: Tue Mar 30, 2010 9:06 am    Post subject: Quote: If there is no diff between program and module, why redundancy was added? At once we cannot justify that program block is same as module. But, we can co-relate it some valid points such as : Similarities between Program block and Module 1> Same as w.r.t. module one can have multiple program blocks inside a design. NOTE - multiple program block does not mean nested program within a common program block. This is invalid which implies same to the module defination . 2> Task declaration or function declaration and data types can be declared within a program as the same way which is been done in modules. 3> Likewise in module a program block can be with i/p's, o/p's or inout. 4> Same holds good for concurrent assertions, initial blocks, continuos assignments and so on. But if you see on the other side of the Mirror . i.e., DIFFERENCES 1> Program definition can occur within a module. But not the other way around. 2> Program block cannot contain any always statement, UDP, module, interface or other program. 3> Module can not call a task or function in a program. But the other way around is true. Quote: why most of the test-benches use program block as starting point of their TB Simple reason being program block is the leaf node of any design, it facilitates the entry point for all TB design. Quote: Why module is not used instead? Is it just lack of awareness? And why always block is not used in a program ? Now this is a question to think. It may not be lack of awareness. Generally any language/methodology is not just released on a fly. There will be a lot of cross talks and session with absolutely 100% result oriented to build up a strong base. _________________ -Pavan K Shanbhag “The difference between genius and stupidity, genius knows his limits.” - Albert Einstein Back to top dave_59 Senior Joined: Jun 22, 2004 Posts: 710 Location: San Jose Posted: Tue Mar 30, 2010 3:09 pm    Post subject: Pavan, With respect to NBA or BA, I mean you can get the same races within program blocks that you can withing modules if you do not use careful coding guidelines. In the following example, there is a race because mode is written/read in the same time slot: Code: program race_example;   bit mode;   bit other_mode;   initial begin       mode = 1;       end   initial begin       if (mode==1) other_mode = 1;      end endprogram And Code: initial forever statement; is the same as Code: always statement; The rules about visibility and nesting do not deal with race conditions, they only enforce certain coding organization. By using virtual methods of classes, I can easily get a module to call a program method. Code: module top;  class A;   virtual function void foo;     $display("defined in module");   endfunction  endclass  A a;  initial begin     #5 a.foo();    end  program P;   int Pvar;  class B extends A;    function void foo;     $display("defined in program");     $disaply("Pvar is %0d",Pvar);    endfunction  endclass  B b;   initial begin    b = new();    a = b;   end  endprogram endmodule   -Dave Back to top Logger Senior Joined: Jun 15, 2004 Posts: 300 Location: MN Posted: Wed Mar 31, 2010 12:34 am    Post subject: <rant> I say down with silly and arbitrary language restrictions all together! program is definitely a pointless invention. Dave points out all the reasons why. For that matter SV and even plain old Verilog is filled with what now feels like ridiculous and arbitrary inconsistancies and restrictions. Its an old language that has had features grafted on over the years, and it reminds me of one of those grafted Orange/Lemon/Lime trees. 3 quick examples: 1) begin/end vs. { }. If there is any purposeful distinction here, it's one only a mother could love. Everyone I've encountered hates it. 2) Can't use "foo inside {1,2,3}" in an if statement. Really, come on! 3) Can't put a specify block inside a generate for loop. I had cause to do this recently. So I instead created another module with the specify block, and then instantiated the module in the generate for loop. Silly workaround for a pointless restriction. </rant> I could go on and on. As far as languages go, it reminds me of another craptastic language, Perl. I've written mountains of that too, cause it get's the job done. Even with the problems SV has, I still find it easier to read and write than C++ based verification environments. So, no matter how ugly it is, it get's the job done so we use it. -Ryan Back to top dave_59 Senior Joined: Jun 22, 2004 Posts: 710 Location: San Jose Posted: Wed Mar 31, 2010 1:40 am    Post subject: Verilog Trivia Ryan, FYI, Verilog was developed in the early 80's and the procedural aspects of the language was derived from Pascal, which was popular at the time. For example, the begin/end blocks, the way variables can be declared within those blocks (must occur before procedural statements), as well as the way procedures are declared with the function/task keywords are derived from Pascal. Even the integer/real data type keywords come from Pascal. {}'s are used for concatenation in Verilog and would create ambiguities if we replace them for begin/end. SystemVerilog (through the Vera donation) added a few places where {}'s are used for blocks, but in those cases, they are all preceded by specific keywords. I'm not sure what you mean by Can't use "foo inside {1,2,3}" in an if statement. Perhaps this is a tool limitation/bug. -Dave Back to top pavanshanbhag Senior Joined: Mar 25, 2009 Posts: 271 Location: Bangalore Posted: Wed Mar 31, 2010 2:54 am    Post subject: Hi Dave, Thanks, for your valuable information. _________________ -Pavan K Shanbhag “The difference between genius and stupidity, genius knows his limits.” - Albert Einstein Back to top Logger Senior Joined: Jun 15, 2004 Posts: 300 Location: MN Posted: Wed Mar 31, 2010 11:20 am    Post subject: Re: Verilog Trivia dave_59 wrote: {}'s are used for concatenation in Verilog and would create ambiguities if we replace them for begin/end. SystemVerilog (through the Vera donation) added a few places where {}'s are used for blocks, but in those cases, they are all preceded by specific keywords. I get the history, and I realize why {} can't just replace begin/end. It just bothers me that constraints and covergroups use {} rather than begin/end. It feels like another language is intruding, which as you point out is in fact the case. For classes, rather than using Vera's {} brackets, class/endclass was introduced. That feels very verilogy, which I like. Why that treatment wasn't given to all occurances of {} in Vera is a mystery to me. dave_59 wrote: I'm not sure what you mean by Can't use "foo inside {1,2,3}" in an if statement. Perhaps this is a tool limitation/bug. Thanks for pointing that out, it apparently was a tool issue. And I spoke too soon. Or maybe more accurately, too late. Last time I tried this it didn't work, but I see it does now. Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         Verification Guild Forum Index -> Main All times are GMT - 5 Hours Page 1 of 1   Jump to: Select a forum Main----------------MainEDA NewsCommunity Services Networking----------------Looking for a jobLooking for candidates Archives----------------AssertionsCoverageFormalSimulationDesignMiscellaneous Test----------------Test  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Forums ©

Verification Guild © 2006 Janick Bergeron
Web site engine's code is Copyright © 2003 by PHP-Nuke. All Rights Reserved. PHP-Nuke is Free Software released under the GNU/GPL license.
Page Generation: 0.424 Seconds