Verification Guild
A Community of Verification Professionals
Search


  Login  
Nickname

Password

Security Code:
Security Code
Type Security Code
BACKWARD
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.

  Modules  
  • Home
  • Downloads
  • FAQ
  • Feedback
  • Recommend Us
  • Web Links
  • Your Account

  •   Who's Online  
    There are currently, 113 guest(s) and 1 member(s) that are online.

    You are Anonymous user. You can register for free by clicking here

     
    Verification Guild :: View topic - Program block: Necessary?
     Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Private MessagesPrivate Messages   Log inLog in 

    Program block: Necessary?
    Goto page 1, 2  Next
     
    Post new topic   Reply to topic    Verification Guild Forum Index -> Main
    View previous topic :: View next topic  
    Author Message
    vhdlcohen
    Industry Expert
    Industry Expert


    Joined: Jan 05, 2004
    Posts: 1325
    Location: Los Angeles, CA

    PostPosted: Mon Aug 28, 2006 8:30 am    Post subject: Program block: Necessary? Reply with quote

    mxg wrote:
    One more thing: program blocks are a vestige of Vera and are really not necessary.
    Mark Glasser
    Verification Technologist
    Mentor Graphics Corporation

    You always hear different opinions on this question: At DvCon, Doulos swore that they were absoluley necessary. The SV committee did approve the use of the program block. I also heard from members of MTI that they were not needed, particulalrly since the clocking block with setup and hold time took care of any timing ambiguitity. Also, this was a time when Questa did not yet support the program block (they do now). I get the feeling that both opinions are correct. However, I also get the feeling that without a clocking block with setup and hold time, one can run into trouble, particularly if one abuses the blocking assignments in a testbench. Comments are welcomed.
    _________________
    Ben Cohen http://www.systemverilog.us/
    * SystemVerilog Assertions Handbook, 3rd Edition, 2013
    * A Pragmatic Approach to VMM Adoption
    * Using PSL/SUGAR ... 2nd Edition
    * Real Chip Design and Verification
    * Cmpt Design by Example
    * VHDL books
    Back to top
    View user's profile Send e-mail Visit poster's website
    Ajeetha
    Senior
    Senior


    Joined: Mar 29, 2004
    Posts: 425
    Location: Bengaluru, India

    PostPosted: Mon Aug 28, 2006 12:26 pm    Post subject: Re: Program block: Necessary? Reply with quote

    Ben,
    Here is MHO on this.

    SV LRM wrote:

    The program block serves three basic purposes:
    ? It provides an entry point to the execution of testbenches.
    ? It creates a scope that encapsulates programwide data, tasks, and functions.
    ? It provides a syntactic context that specifies scheduling in the Reactive region.


    While surely there are varying views, it is an enhancement over plain Verilog/V2K.

    One of the arguments is "we don't need them". Just look at other SV constructs such as always_ff/comb etc. - people have been designing chips, taped out and we have fully working cellphones/TVs with plain old always block. So will we declare "always_ff" is unnecessary and claim that it is added b'cos of Co-Design/SuperLog founders? My take on it: if there is a better way of doing it, why not take it with open hands - provided all tools support etc. - Let's leave the tool support for now (to have unbiased view).

    The second point LRM makes for program is IMHO significant and very important as I mentioned in other post - with program , a tool can be restricted to debug TB alone - a boon for TB development and failure analysis. I understand it is often difficult to say it is a TB bug or design bug to start with, but once sorted to be a TB bug, such an option is extremely useful - imagine doing single stepping through million lines of code while your TB code is say 10K lines alone (numbers are guess work here).

    I would also see that the 3rd argument LRM makes is significant for reactive TBs. By observing what happened in current clock through a SVA seq I can now tune my random generator. If not for Program (and associated reactive/observed etc.) - my results can vary across tools and TB become non-portable with same results. I don't want to go tracking all possible features wherein LRM leaves some ambiguity (I'm sure there are), but atleast here is a place it attempts to do some thing unambiguous. Why go against it or declare it useless - let the users decide. I'm NOT saying program is a *must*, but it looks to me like a *GOOD* enhancement.

    I know there are SV Gurus out here in this forum who can share confcliting views on this, but ask them the same with other tiny enhancements on SV (such as always_ff ) - if they are "necessary", then so is my harmless program Smile

    My 2 cents!

    Regards
    Ajeetha, CVC
    _________________
    Ajeetha Kumari,
    CVC Pvt Ltd. http://www.cvcblr.com
    * A Pragmatic Approach to VMM Adoption http://www.systemverilog.us/
    * SystemVerilog Assertions Handbook
    * Using PSL/Sugar
    Back to top
    View user's profile Visit poster's website
    jonathan
    Senior
    Senior


    Joined: Jul 20, 2004
    Posts: 20

    PostPosted: Tue Aug 29, 2006 5:13 am    Post subject: Re: Program block: Necessary? Reply with quote

    Ben Cohen wrote:
    You always hear different opinions on this question: At DvCon, Doulos swore that they were absoluley necessary.


    urrrm, not quite - or at least, not if I read my own script correctly Smile

    What I aimed to say was that program blocks are essential when accessing variables in a clocking block. I don't really want to go into all the sordid details at this point, but my understanding is clear: if you try to access clocking block variables from code that's not running in a program block, all bets are off. If you access a clocking block from program code, all the advertised benefits (centralisation of timing and directionality details, freedom from testbench-to-design races and so forth) are yours for the taking.

    It is definitely the case that you can build good testbenches without using either program or clocking constructs in SV. There are plenty of existence proofs of that. It is also definitely the case that the VMM methodology insists on their use, and mandates a very specific way of using program, clocking and interfaces to make it all work smoothly. My personal opinion about all this changes alarmingly frequently, but ultimately the bottom line is: like every other language, SV gives you plenty of opportunity to abuse language features; but if used properly, those features can help you. Find and adopt an approach that is well known to work reliably, and follow it consistently.

    Jonathan Bromley, Doulos Ltd

    Personal opinions only, not necessarily the opinions of my employer.
    Back to top
    View user's profile
    dave_59
    Senior
    Senior


    Joined: Jun 22, 2004
    Posts: 981
    Location: Fremont, CA

    PostPosted: Tue Aug 29, 2006 3:03 pm    Post subject: Re: Program block: Necessary? Reply with quote

    jonathan wrote:

    What I aimed to say was that program blocks are essential when accessing variables in a clocking block. I don't really want to go into all the sordid details at this point, but my understanding is clear: if you try to access clocking block variables from code that's not running in a program block, all bets are off. If you access a clocking block from program code, all the advertised benefits (centralisation of timing and directionality details, freedom from testbench-to-design races and so forth) are yours for the taking.


    Jonathan,

    First I want to point out that what the LRM says about clocking blocks and what has been implemented are different. If you follow the LRM precisely, your clocking block outputs will be a clock cycle behind where they should be. This and other problems are being discussed in the sv-ec committee as issue 890.

    Next, I agree that whenever you use the same clock triggered in the same region for both the testbench code and the clocking block, you will have a race condition reading the sampled input clocking block variables. So you could have that race if the clocking block and testbench are both defined in a module or both defined in a program block. There are a number of ways to avoid that race condition without using a program block; one way is to use the clocking block event to trigger the testbench.

    And finally (at least for this discussion), I believe that program blocks create a false sense of security in that they do allow many race conditions. In fact, a program to program block race is the easiest to wite given that NBA writes to program variables are not allowed. For this example, assume the two clocks are the same in this example:
    Code:

    program p1(input clk);
    logic A;
    initial begin
               @(posedge clk)
               A = 1;
              end
    endprogram
    program p2(input clk);
    initial begin
               @(posedge clk)
                  $display(p1.A); // this is a classic Verilog race
              end
    endprogram


    Some will say that you should know what you are doing and use something like a mailbox or event for this kind of communication. Yes, that?s true, but a similar level of knowing what you are doing will avoid races without using program blocks. And because program blocks don?t allow NBA assignments, there are many un-timed testbenches that can?t be written without introducing artificial delays. For those familiar with SystemC, NBA assignments provide the functionality of request_update() in a primitive channel. This prevents thread hogging and starvation in a un-timed system-level model.

    Dave
    Back to top
    View user's profile Send e-mail Visit poster's website
    vhdlcohen
    Industry Expert
    Industry Expert


    Joined: Jan 05, 2004
    Posts: 1325
    Location: Los Angeles, CA

    PostPosted: Tue Aug 29, 2006 8:37 pm    Post subject: Re: Program block: Necessary? Reply with quote

    Many thanks Ajeetha, Jonathan, and Dave for your explanations. While these clarified issues, they also raised other questions and muddied the real question: Is the program block needed?". It seems that the answer to this question is "it's the methodology, STUPID!". A summary of what I read so far:
    From Jonathan, program blocks are essential when accessing variables in a clocking block.
    From Dave, you could have that race if the clocking block and testbench are both defined in a module or both defined in a program block.
    Question: What if the clocking block is defined in the interface?
    Question: Are clocking blocks synthesizable?
    Guideline: Use the clocking block event to trigger the testbench when clocking blocks are used.

    Quote:
    Some will say that you should know what you are doing and use something like a mailbox or event for this kind of communication. Yes, that?s true, but a similar level of knowing what you are doing will avoid races without using program blocks. And because program blocks don?t allow NBA assignments, there are many un-timed testbenches that can?t be written without introducing artificial delays. For those familiar with SystemC, NBA assignments provide the functionality of request_update() in a primitive channel. This prevents thread hogging and starvation in a un-timed system-level model. Dave

    Referring to the VMM methodology,the heart of the testbench is implemented in classes instantiated in a program block.
    The transactor class makes NBA to variables in the interfaces. Synchronization is achieved with the vmm_notify facilities. For example:
    Code:
      interface fifo_if(input wire clk,
                      input wire reset_n);
       ..
      wire  push; // push data into the fifo
      wire  pop;  // pop data from the fifo
      ..
      parameter hold_time=3;  // 3ns
      parameter setup_time = 5;
    ..
      clocking driver_cb @ (posedge clk);
       default input #setup_time output #hold_time;
         input  empty, full, data_out, error;
         output data_in, push, pop;
      endclocking : driver_cb
    endinterface : fifo_if

    // The command transactor is instantiated in the environment within the program block
     task Fifo_cmd_xactor::push_task (word_t data);
        f_if.driver_cb.data_in <= data;
        f_if.driver_cb.push <= 1'b1;
        f_if.driver_cb.pop  <= 1'b0;
        @ ( f_if.driver_cb);
        f_if.driver_cb.push <= 1'b0;
      endtask : push_task
    ...
    // synchronization
    this.fifo_xactn_gen_0.notify.wait_for(Fifo_xactn_atomic_gen::DONE);


    Getting back to the original question, maybe the real answer is:
    "it's the methodology, STUPID!"
    _________________
    Ben Cohen http://www.systemverilog.us/
    * SystemVerilog Assertions Handbook, 3rd Edition, 2013
    * A Pragmatic Approach to VMM Adoption
    * Using PSL/SUGAR ... 2nd Edition
    * Real Chip Design and Verification
    * Cmpt Design by Example
    * VHDL books
    Back to top
    View user's profile Send e-mail Visit poster's website
    kirloy
    Senior
    Senior


    Joined: Sep 20, 2004
    Posts: 174

    PostPosted: Thu Aug 31, 2006 2:29 am    Post subject: Reply with quote

    @DAVE
    Are those changes in LRM (from below link - file : SV-890-1.htm 02-23-06 0:53)approved ? Will they be puted into next version?
    http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=0000890

    After reading I've still some doubts.
    1st - about #1step intput: we know whan values are sampled but we don't know when sampled value is updated (in active region with all others - which is race with design signals)?

    2nd with clocking drives - LRM says that they should propagate after ractive and re-inactive region is complited (this is new region?). While there is also writen that values shuould be updated in NBA. So do we have loop from after re-inactive into NBA to execute (probe and update) clocking drives value? In below sentence there is about after re-inactive and NBA.
    LRM update:
    Quote:
    Clocking block outputs are scheduled to propagate back into the design after the reactive and re-inactive regions of a given time unit have completed their iterations and contain no more events. (See Figure 9-1) After these regions have been processed, all possible synchronous drives will have executed. For zero skew clocking block outputs with no cycle delay, the new values will be scheduled in the NBA region of the current time unit. For clocking block outputs with non-zero skew or non-zero cycle delay, the corresponding signal shall be scheduled to change value in the NBA region of a future time unit.


    3th - there is no word about what happen if we assign value binded to clocking block in simple way I mean: cb.a <= X vs a <= X vs a=X. Is it allowed? How it should work?
    Back to top
    View user's profile
    jonathan
    Senior
    Senior


    Joined: Jul 20, 2004
    Posts: 20

    PostPosted: Thu Aug 31, 2006 6:20 am    Post subject: Re: Program block: Necessary? Reply with quote

    dave_59 wrote:

    First I want to point out that what the LRM says about clocking blocks and what has been implemented are different. If you follow the LRM precisely, your clocking block outputs will be a clock cycle behind where they should be. This and other problems are being discussed in the sv-ec committee as issue 890.

    Indeed, although I believe the current proposals still leave some questions unanswered - I suspect it's time I got a bit more actively involved...
    dave_59 wrote:

    Next, I agree that whenever you use the same clock triggered in the same region for both the testbench code and the clocking block, you will have a race condition reading the sampled input clocking block variables. So you could have that race if the clocking block and testbench are both defined in a module or both defined in a program block. There are a number of ways to avoid that race condition without using a program block; one way is to use the clocking block event to trigger the testbench.

    Aaargh! Another rabbit pulled out of the bottomless hat that is clocking blocks! Why on earth should it make any difference if I trigger module-based TB code from the clocking block event rather than from its underlying "real" event? The LRM clearly says that the two events are "equivalent". I can easily understand that some implementations might choose to forward the event under the guise of @clocking, so that @clocking is guaranteed to happen after the original event has taken effect and caused the clocking block variables to be sampled/updated; but I see nothing in the LRM that enforces such an ordering.
    dave_59 wrote:

    And finally (at least for this discussion), I believe that program blocks create a false sense of security in that they do allow many race conditions. In fact, a program to program block race is the easiest to wite given that NBA writes to program variables are not allowed.

    That really is a methodology question; any language that allows open visibility of a thread's variables to other threads is subject to that kind of race. Maybe, just maybe, it's time for proper concurrent programming to become part of every verification engineer's core training?????

    dave_59's point about untimed testbenches is, however, a very valid one.
    Back to top
    View user's profile
    dave_59
    Senior
    Senior


    Joined: Jun 22, 2004
    Posts: 981
    Location: Fremont, CA

    PostPosted: Thu Aug 31, 2006 9:08 am    Post subject: Reply with quote

    kirloy wrote:
    ]@DAVE
    Are those changes in LRM (from below link - file : SV-890-1.htm 02-23-06 0:53)approved ? Will they be puted into next version?
    http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=0000890


    Issue 890 has not been approved, nor has it even been brought up for discussion in the sv-ec. They have not been meeting regularly and that PAR for the next revision was just approved less than a month ago.

    I'm going to reply to your other specific questions by moving this discussion over to the sv-ec email reflector. To view or subscribe to this reflector, see http://www.eda-stds.org/sv-ec/

    Dave
    Back to top
    View user's profile Send e-mail Visit poster's website
    kirloy
    Senior
    Senior


    Joined: Sep 20, 2004
    Posts: 174

    PostPosted: Thu Aug 31, 2006 10:03 am    Post subject: Reply with quote

    sory for my post bu there is no other way;)

    Dave I cannot contact on priv with you and also I dont know how to contact with web site adimn - but I cannot subscribe mial reflector which you've mentioned.

    my address is:
    ____kirloy at gazeta . pl___

    ofcrource after removing all underscores
    Back to top
    View user's profile
    dave_59
    Senior
    Senior


    Joined: Jun 22, 2004
    Posts: 981
    Location: Fremont, CA

    PostPosted: Fri Sep 01, 2006 12:36 am    Post subject: Reply with quote

    kirloy wrote:
    sory for my post bu there is no other way;)

    Dave I cannot contact on priv with you and also I dont know how to contact with web site adimn - but I cannot subscribe mial reflector which you've mentioned.

    my address is:
    ____kirloy at gazeta . pl___

    ofcrource after removing all underscores


    I tired to send you e-mail and it bounced with the message below which I assume is in Polish. You should now be able to send me private email through this site by clicking on the e-mail button below this message.

    host mailis01.gazeta.pl [194.149.231.60]: 550 Brak rekordu SPF/MX nadawcy lub brak poprawnej autoryzacji SMTP!

    Dave
    Back to top
    View user's profile Send e-mail Visit poster's website
    cliffc
    Industry Expert
    Industry Expert


    Joined: Jan 15, 2004
    Posts: 30
    Location: Provo, UT

    PostPosted: Sun May 03, 2009 9:51 pm    Post subject: Program Block - Useful Reply with quote

    One of my SystemVerilog students pointed me to this thread after I recommended putting testbench code into a program. I stand by that recommendation.

    If you have a working verification methodology, you do not need the program blocks, but it is easier to avoid design-testbench race conditions if you use program blocks.

    The new event scheduling algorithm that was incorporated by Mantis 890 into the SystemVerilog-2009 Standard can be viewed and is explained in a paper that Arturo Salz and I presented at the 2006 Boston SNUG (see paper at the following link)

    http://www.sunburst-design.com/papers/CummingsSNUG2006Boston_SystemVerilog_Events.pdf

    When we were first discussing the program block event regions (Re-Active Regions), I argued against the program regions. In a conference call with Arturo Salz and Medhi Mohtashemi of Synopsys, I outlined a Verilog verification methodology that I had used for more than a decade that worked fine without the new regions. At the end of my presentation, Arturo and Mehdi noted that I had a good methodology that indeed did work, but that by allowing the inclusion of the new program regions, other engineers could more easily develop testbench methodologies without being required to understand my methodology. This argument is what persuaded me to support the new event regions.

    IMO - separating the RTL code and reference model from the testbench code is a good idea and the separation helps to avoid design-testbench race conditions that can occur if you are not precise with a module-only methodology. I now recommend that engineers use modules for the design, reference model and top-level model, and use program blocks for testbenches.

    One rather common technique for applying stimulus to a design is to apply stimulus vectors on the active clock edge (I discourage this technique for a variety of reasons, but it is commonly used). To do so in a module-only verification environment requires that all stimulus vectors be assigned with nonblocking assignments. The idea is to make sure the input stimulus vectors do not update the design registers until the previous values have been sampled by the active clock edge. Using a program block, the assignments can be made using either blocking or nonblocking assignments since all program statements are guaranteed to execute after the first pass through the RTL design (one less verification gotcha).

    Another advantage of the new event regions is you can control when C-functions execute with respect to the design and testbench. Mantis 890 clarified that if C-code is called from a program, that it executes in the Reacitive regions and if the C-code is called from a module, it executes in the Active regions. There are similar other useful possibilities as a result of the new Reactive regions.

    The industry now has a few good verification methodologies in place, but I am not naive enough to assume that the current methodologies are perfect and could not benefit from the added capabilities offered by the new Reactive event regions. I do not have any reason to believe that the OVM would not work equally well with program blocks as it would with modules.

    Regards - Cliff Cummings
    Verilog & SystemVerilog Guru
    www.sunburst-design.com
    _________________
    ----------------------------------------------------
    Cliff Cummings - Sunburst Design, Inc.
    cliffc@sunburst-design.com
    www.sunburst-design.com
    World Class SystemVerilog & UVM Verification Training
    Back to top
    View user's profile Send e-mail Visit poster's website
    dave_59
    Senior
    Senior


    Joined: Jun 22, 2004
    Posts: 981
    Location: Fremont, CA

    PostPosted: Wed May 06, 2009 2:45 am    Post subject: Reply with quote

    Hi Cliff,

    Who would have ever thought we?d be having language wars within the same language! Smile

    As far as I can tell, a program block by itself only addresses two race conditions between the testbench and DUT, both of which are covered by using a clocking block by itself.

    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.
    As a user, if you don?t understand why these create races within your DUT, you?re going to have the same races within your testbench, and there?s nothing a program block does that prevent races within your testbench. There lays the false sense of security of having a race-free testbench.

    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.

    Now, in addition to the false sense of security, and the redundancy with clocking blocks, here are some additional reasons why I don?t recommend using program blocks

    1. If you have legacy Verilog testbench code, sometimes you want to share legacy BFM tasks by having your ?class? based testbench call those BFM tasks. You?re going to run into nasty timing problems if that task was designed to be scheduled in the active region, and now is scheduled in the re-active. Sampling will be off by a clock cycle. You?ll have even nastier problems if some tasks are called from a program block, and other are still called from a module.
    2. One person?s Design IP is another person?s Verification IP. At the system level (ESL), there is less of a distinction between models written to represent higher level abstractions of the design, versus part of a testbench. You can?t have differences in scheduling just because one time it?s called from a program, and another time it?s called from a module. Same problem with C code called from a program block or module.
    3. Unless you?re an experienced Vera user, there is the unexpected surprise that your simulation exits immediately after the thread in your program block ends. Again this is an issue with mixing legacy testbenches, or mixed-language testbenches.
    4. Most advanced users can barely understand the scheduling semantics of SystemVerilog even without using program blocks. Why introduce unnecessary complexity. Quick quiz: How can you get an assertion pass and fail in the same time slot?
    The SystemVerilog language has had many hands involved with its development, including yours and mine. I?m not dismissing anyone efforts, but sometimes you have to take a step back and realize how bloated the language has become. Just because some feature exists in the LRM doesn?t justify that it needs to be used. Let me tell you about virtual interfaces? Evil or Very Mad

    Dave Rich
    Back to top
    View user's profile Send e-mail Visit poster's website
    rdsalemi
    Junior
    Junior


    Joined: Nov 15, 2006
    Posts: 7

    PostPosted: Wed May 06, 2009 10:05 am    Post subject: Reply with quote

    Too add a newbie slant to this.

    I thought that a program block was essentially the same thing as a module that only contains initial blocks.

    Did I miss something magical about program blocks?

    Ray
    Back to top
    View user's profile
    cliffc
    Industry Expert
    Industry Expert


    Joined: Jan 15, 2004
    Posts: 30
    Location: Provo, UT

    PostPosted: Wed May 06, 2009 1:17 pm    Post subject: Reply with quote

    Responses to Ray and Dave below:

    Ray - in addition to the initial block restriction (which continues to be a point of debate on the SV enhancements committee), programs can call module tasks and functions that will cause them to execute with the rest of the program code, but modules cannot reference program variables, tasks and functions (to keep interaction between module activity and program activity separate).

    The main idea behind the program was to separate module (design) activity from program (testbench) activity. If you setup a testbench to drive stimulus on the posedge clk, then the posedge clk will typically execute the following steps:
    (1) module registers will trigger first (they use nonblocking assignments).
    (2) when the registers update, they will trigger the combinational logic in the module. The combinational logic will settle out.
    (3) program (testbench) activity will be executed.
    (4) after the program testbench activity settles, it will be driven to the module design and re-trigger any sensitive combinational logic (but will not re-trigger the registers).
    (5) the combinational logic settles and simulation advances to the next event in a future time slot.

    Any module task, module function or C-function called from a module will execute in the module (Active) regions.

    Any module task, module function, program task, program function, or C-functions called from the program space will execute in the program (Reactive) regions. This was not clear in the 1800-2005 Standard but has been clarified in the pending 18000-2009 Standard.

    Dave - you raise interesting points and I will have to examine them in more detail and respond later. Thanks for the thoughtful discussion. I don't consider this to be a language civil-war Smile I consider this a discussion of best practices, which I think we are still sorting out.

    Dave is correct that we added programs for a specific reason and Dave has now challenged the original reasoning behind programs. Dave may be right but I need to review his comments before I can sign off on his reasons.

    History: the event scheduling algorithm was largely proposed by Synopsys engineers and was updated three years ago after publication of the SystemVerilog-2005 Standard to make necessary corrections for program block timing (go to www.eda.org/svdb - username: guest / password: guest / issue # 890 - page down to "attached files" and select: SV-890-7-part2.pdf to see the corrected event scheduling with separated Active and Reactive event regions).

    When I first saw this proposed event scheduling, two thoughts came to mind:
    (1) I asked if the new event scheduling would slow down simulations - the Cadence representative on the committee answered that there would be no slow-down. The Cadence rep said that all of the events still had to be scheduled and the new event regions just made it clear where the events were scheduled.
    (2) I asked the Mentor representative if they were ready to support the more complex event scheduling - the Mentor rep said they supported the new event scheduling because it would reduce race conditions between third party hardware verification languages and SystemVerilog designs (reading between the lines, I believe Mentor had some customers that were having design-testbench race conditions between Verilog designs and e-code testbenches and now vendors could force e-code testbenches into the "program" regions to avoid the races).

    After all three major vendors expressed support for the new event scheduling, I dropped all of my objections.

    So now the interesting question is, what type of design-testbench race conditions have been observed by e-language users? I will make this a separate thread since e-users are not as likely to read this thread.

    Dave makes the valid point that clocking blocks can now control the timing to avoid the design-testbench races. My next question is, are all OVM and VMM users using the clocking block to control drive-and-sample timing?

    Since the clocking block has a rather unique syntax for clocking drives and clocking samples that requires cb.variable <= syntax for drives (to use the clocking drive skews) and "if (cb.variable == expected)" syntax for sampling (to use the clocking sample skews), I wonder if users find that syntax confusing?

    I look forward to examining Daves other comments in more detail.

    Regards - Cliff
    _________________
    ----------------------------------------------------
    Cliff Cummings - Sunburst Design, Inc.
    cliffc@sunburst-design.com
    www.sunburst-design.com
    World Class SystemVerilog & UVM Verification Training
    Back to top
    View user's profile Send e-mail Visit poster's website
    Logger
    Senior
    Senior


    Joined: Jun 15, 2004
    Posts: 348
    Location: MN

    PostPosted: Wed May 06, 2009 1:26 pm    Post subject: Reply with quote

    dave_59 wrote:
    Let me tell you about virtual interfaces? Evil or Very Mad


    Please do (in another thread). I don't have any qualms with them, but are you implying there is an alternative to using them (currently in the language)?

    -Ryan
    Back to top
    View user's profile
    Display posts from previous:   
    Post new topic   Reply to topic    Verification Guild Forum Index -> Main All times are GMT - 5 Hours
    Goto page 1, 2  Next
    Page 1 of 2

     
    Jump to:  
    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

    Powered by phpBB © 2001, 2005 phpBB Group
    Verification Guild (c) 2006-2014 Janick Bergeron
    PHP-Nuke Copyright © 2005 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
    Page Generation: 0.14 Seconds