SV-EC Committee: Face-to-Face meeting. Non-Voting meeting. Monday November 6 2006 11:00am - 1:00pm PST [Notes distributed for documentation and review] (1212020) Day (4815936) (0000111) Month (8899001) (0000000) Year (6666666) --------- Attendees ---------- (-AAAAAA) Arturo Salz (--AAA-A) Cliff Cummings (AAAAAAA) Dave Rich (AA-A-AA) Francoise Martinolle (-AAAAAA) Mehdi Mohtashemi (AAAAAAA) Neil Korpusik (AAAAAAA) Ray Ryan (AAAAAAA) Gordon Vreugdenhil (AAAAAA-) Steven Sharp (--AAAA-) Phil Moorby (---AA-A) Doug Warmke (AAAAAAA) Stu Sutherland (-AAAA--) Heath Chambers (-AAAAAA) Don Mills (--AA--A) Jonathan Bromley (--A----) Logie Ramachandran (----AAA) Melvin Cardoza (-----A-) Mark Hartoog ^ |------- non-voting meeting ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ///////////////////// November 6 2006 ///////////////////////////// (A) Special thanks go to Dave Rich to help host this meeting. (B) Special thanks go to Neil for taking careful notes of our face-to-face meeting discussions and spending numerous hours to organize and document the discussion which is appended below. (C) Druing our face-to-face meeting Cliff Cummings created a document based on an earlier email sent by Doug on clocking-block. I have included the notes at the bottom of this document, and posted a .pdf version at the sv-ec site. Points from Doug's email is also referenced in the notes below. (D) Dialed-in via phone conference: Francoise, Don, Jonathan. Agenda: 1. Special Face to Face meeting This meeting was hosted by Dave Rich of Mentor in San Jose. This was a non-voting meeting intended to allow the committee to reach consensus on various issues with: (referring to mantis 890) clocking blocks program blocks scheduling semantics 2. Review of scheduling semantics and clocking blocks ------------------------------------------------------ - Cliff presented his training material to build a framework for the discussion on clocking block, program block, and scheduling semantics. There was good agreement among the participants with the material that was presented. 3. Major Discussion points ---------------------------- a) show ## usage earlier in the LRM --------------------------------- Cliff - The discussion on the definition of clocking blocks (15.14?) should occur earlier in section 15. State that you need a default clocking block to use this. b) The #1 step discussion in LRM ------------------------------ The LRM describes the semantics of #1step in slightly different ways in 9.3, 15.2 and 17.3. These should be made more consistent. See page 5-37 of Cliff's presentation slides. Dave - step is parameterizable, this requires it to be defined with respect to the Postponed region. Gord - VPI callbacks that try to read the value would be the only issue. Dave - assertions in a clocking block use the cb's timing versus #1step used in other assertions. Arturo - there are clearly no rounding issues with #1step "The step time unit is equal to the global time precision." p.340 Agreements reached: #1step should always be described with respect to the Postponed region. c) Non-blocking assigments and clocking drives (first discussion) -------------------------------------------- The example on page 5-46 of Cliff's slides shows a case that has been implemented in an inconsistent way by various vendors. The problem occurs when there is a mixture of clocking drives and non-blocking assignments to the same program output port. initial begin d <= '1; ##1 d <= '0; ##1 cb.d <= '1; // clocking drive end d) Examples ---------- d <= ##2 v; // save value of v and apply it to d after 2 clocking events default clocking cb1 @(posedge clk); output #2 d; // ##2 not allowed here endclocking e) "clocking drive" versus "nonblocking assignment" (discussion) ------------------------------------------------- Care was taken to distinguish between a clocking drive and a nonblocking assignment. The clocking drive is scheduled in the module NBA region, but it is not the same as a nonblocking assignment. A clocking drive can have a skew associated with it (i.e. specified for a clockvar within a clocking block) and a nonblocking assignment cannot. Stu - one implementation erroneously allows cb1.d='0; // should be <= - the message produced by a syntax error for a clocking drive incorrectly uses the words "nonblocking assignment". - cb drive within functions - some implementations don't allow since a function currently can't contain an NBA (Dave has an open mantis item on NBAs in functions -- 1336) Dave - within a module: a clocking drive in the same procedural block as an NBA to the same variable, no guarantee of the assignment order since the clocking drive is not an NBA. f) Separation of module execution and program execution ----------------------------------------------------- Gord - current LRM can't guarantee the original intent of program blocks - he is ok with the original intent Dave - there can be a loopback to module execution regions - generating a clk from a program block causes problems Arturo - the fundamental goal is for program block execution to stabilize without any interactions with modules Gord - given: a module variable with a connection to a program port. Calling module functions from programs can modify module variables. Any reference to this module variable from within the program now sees the updated value. Forces are also currently a problem. Arturo - cb is the sampling mechanism for program blocks (trampoline) Agreements were reached later in the discussion to address these issues. g) Defining corner cases ---------------------- Gord - we need to define corner cases simply enough such that we can reason about any situation that arises. - anything that isn't currently defined needs to be defined. - as long as everything is clarified he will be happy. h) NBA to program variables - This was item 9 in "Doug's email" ------------------------------------------------------------- Gord - Mentor would like to allow this Arturo - mentioned the concept of copying code from a module and having it behave the same way within a program block. Agreements reached: A Re-NBA region will be added to the event queue. - NBAs to program variables take place in this new region - this region will follow the Re-inactive region and will be part of the "reactive inner loop" - Pre-re-NBA and Post-re-NBA VPI regions will also be added (we didn't discuss the actual names of these new VPI regions) i) program ports - This was item 3 in "Doug's email" ------------------------------------------------- program p (input .portname(expr), ...); Dave - a module can't access a program variable via a hierarchical reference. This is in the LRM today. Gord - a named port connection is not a hierarchical reference. It is a named association program p (.myport({mnet1, mnet2}), ref a, output pwire, preg); logic mnet1, mnet2; // clearly these are program variables int a; logic preg; // continuous assignment to it wire pwire; - a variable name gets created inside the program - a virtual interface can be used as a port (Dave thinks of it as a handle) - today a function call from a program block could cause active region scheduling within a module Arturo - 1. When do assignments within a program to a program port mature? 2. Original intent was module and port executions to be separate Dave - type of variable versus where assigned, which way to schedule? Gord - Determine scheduling based on where an assignment occurs. Doesn't want object being updated to determine scheduling. Thread of execution should have a place in scheduling. Scheduling should be a runtime decision. - Anonymous program - can exist within a package - Vera has a cleaner interface between the testbench and the design, this makes NBAs a bigger issue for SystemVerilog. - which region wake up in if there are delays? - continuous assign in a program to a module variable the last value written by a program is available in the module active region - assign cb.v1 = expr; // not legal A clocking drive is a "clocked entity" not really a continuous assignment. Gord - multiple clocking drives to the same variable get resolved. a good reason to not allow continuous assignments to clockvars. Agreements reached: Don't make scheduling decisions based on the target, instead the thread of execution will be used to determine scheduling. clockvars can't be on the LHS of a continuous assignment. j) Are program ports considered program variables - item 3 in "Doug's email" -------------------------------------------------------------------------- Based on what we decided in item 3. i) this no longer matters. Assignments made in a program now execute in the reactive regions and don't depend on the target. Doug - why can't we have always blocks in a program? Neil - a module can be used for this Arturo - we want the program to end. A program block is more like a C program. That is why allowing continuous assign in a program was a mistake A continuous assign is always active and doesn't end. k) Are continuous assigns in program blocks subject to reactive scheduling? (item 1 in "doug's email") ------------------------------------------------------------------------ - Yes - For bidi ports, the port must be a wire (not logic) and then driven by a cb.port from an initial block. Dave - if we get rid of continuous assignments within program blocks you need to always use clocking blocks. Arturo - if you allow continuous assignments to program ports there can be races. Gord - 2 programs connected to each other via a module, the "big loop" is required in order for those programs to communicate with each other via a module variable. - a ref port or a collapsed port are the only ways that two programs can communicate without having modules wake up in-between. In these cases execution remains in the reactive regions. - a continuous assignment in a module between 2 programs will require the module to wake up first. l) Concept of a "continuous Re-NBA" - item 6 in "Doug's email" ------------------------------------------------------------ Arturo - it was meant to be used for program to program communication - this idea was meant to be a shorthand for having to create a temporary variable in cases where multiple programs could drive onto the same bus. Using the continuous Re-NBA would prevent races, since the last drive would win. Others felt that using classes and mailboxes was a more appropriate way for programs to communicate with each other. Agreements reached: This is something that could possibly be added at some point in the future. Disallowing it today would not prevent it from being added later. Since it is only a shorthand the committee didn't see a reason to add it at this point in time. m) Vars in a package ------------------- Francoise - what about vars in a package? Gord - both BA and NBA are now allowed in both places - packages are considered design constructs except for anonymous programs. Francoise - what about task calls from a program? Dave - these are now thread based (not declaration based) n) NBA in program scope - this was item 7 in "Doug's email" -------------------------------------------------------- - clocking drives are based on thread of execution Gord - clocking drives to a program variable - in Re-NBA? Dave - could also be in NBA? Arturo - could be in either NBA, but Re-NBA is cleaner Jonathan - with glitches on the clock - you are hosed Dave - we need to define the number of times a clocking drive can occur per timestep. There could be multiple drives on the same variable if we go around the big loop. Gord - where a clocking drive occurs depends on where the clocking block is declared. Cliff - clocking block in an interface - NBA clocking block in a program - Re-NBA Gord - a clocking drive is like an "implicit thread" Arturo - didn't like this idea of an "implicit thread" Gord - existence of a thread is always up to the simulator e.g. cascaded assigns - can be collapsed by a simulator - could get an Active region glitch if have module changing the same variable being driven by a clocking block NBA. Agreements reached: A program can schedule both Re-NBA and NBA events. A clocking drive to a program variable will be scheduled into the Re-NBA region. Glitches on clocks can give surprising behavior. No attempt will be made to make this more predictable since the committee believes designs should have a well-behaved, glitch-free clock. o) port collapsing between modules and programs - was item 2 in Doug's email ------------------------------------------------------------------------- - affects visibility - this is allowed p) Are program ports connected to parent objects in the same way that design ports are connected to parent objects? - was item 4 in Doug's email - Yes q) Program calling blocking tasks from a module - item 5 in Doug's email ---------------------------------------------------------------------- - Doug had originally referred to this as a loophole - others didn't view it as a loophole Agreements reached: When a task is called from a program block the task will execute in the reactive regions (this was referred to as the "native region"). The same task called from a module will execute in the active regions. Need to take out the existing statement in the LRM about calling a design task from a program and the task blocks. Today the return takes you back to the reactive region. This is no longer necessary, now it will execute completely within the Reactive regions. r) Tasks declared in packages - was item 5a in Doug's email -------------------------------------------------------- - considered design scopes (unless within anonymous programs) Agreements: - no longer an issue - we plugged this hole - there are no threads of execution within packages ?) bidirectionals ?) procedural continuous assigns Jonathan - why is this not allowed? 4. Areas of general agreement --------------------------- a) Vote to close mantis item 1604 at the next voting meeting. All of the agreements reached today will be incorporated into mantis 890. b) #1step should be described with respect to the Postponed region Sections 9.3, 15.2 and 17.3 of the LRM. c) ##0 - synch to next clocking event, if not currently at one - glitches on clocks can give surprising behavior. No attempt will be made to make this more predictable since the committee believes designs should have a well-behaved, glitch-free clock. d) ##1 - wait for next clocking event - same as ##0 if not currently at a clocking event e) a Re-NBA region will be added to the event queue - NBAs to program variables take place in this new region - this region will follow the Re-inactive region and will be part of the "reactive inner loop" - Pre-re-NBA and Post-re-NBA VPI regions will also be added (we didn't discuss the actual names of these new VPI regions) - a clocking drive to a program variable will be scheduled into the Re-NBA region f) Don't make scheduling decisions based on the target, instead the thread of execution will be used to determine scheduling. g) clockvars can't be on the LHS of a continuous assignment. h) How do we describe the "initiating thread"? 5. Miscelenous discussions ------------------------- It was suggested that the SVBC have a "time-0 face to face" meeting. 6. Related mantis items (to mantis 890 and today's discussion) 236 - ##0 - can be closed after we finish with 890. - This mantis proposes the same semantics for ##0 that we have agreed to 239 - Proposed enhancement to cycle delay operator ##5 @(posedge clk); // proposed The committee believes that @cb_name is preferable. 597 - How refer to items within an unnamed clocking block (see 1325) At the next meeting we can close this mantis item. 608 - People felt that this was now clarified by 890. [Neil - not sure this is the case] 609 - issue with determining which clocking block to use ##5 cb.x <=3; // which cb to use for ##5? 1325 - was closed by SVAC - unnamed clocking blocks 1615 - was approved already - allows fork/join_none within functions 7. Action Items --------------- Doug - rewrite the proposal for mantis 890 based on our agreements ? - rewrite the description of #1step in 17.3 8. Next meeting: Monday November 20, 2006 11am-1pm PST ======================================================================= == Cliff Cummings Document/notes during this face-to-face meeing ===== == ( pdf file is uploaded at sv-ec meeting minutes site) ===== ======================================================================= ##0 in the same time slot as the active clock = no delay ##0 between clock events = ##1 NBA & Mehdi, Cliff, Arturo, Gordon, Steven, Dave, Jonathan, Here are some issues I think we need to discuss in the face-to-face: 1. Are continuous assigns in program blocks subject to reactive scheduling? Yes. No cb.port continuous assignments - cb.port requires clocking drives. For bi-dir ports, the port must be a wire (not a logic) and then driven by a cb.port from an initial block. Continuous assignments and cb.port clocking drives - legal and have normal resolution semantics. 2. Are program wire ports allowed to be collapsed using conventional port collapsing techniques? Yes (please!) 3. Are program variable ports considered program variables? Immaterial for the purposes of new assignment semantics. Assignments within the program execute in the reactive-regions and do not depend on the target.(!!) Example: // ref int a; causes problems!! program p (.myport({mnet1, mnet2}), a, pwire, preg); ref int a; output pwire, preg; output [1:0] myport; logic mnet1, mnet2; // re-NBA scheduled logic preg; wire pwire; 4. Are program variable ports connected to parent objects in the same way that design variable ports are connected to parent objects? Yes 5. Are we OK with the loophole of a program calling a blocking task in a design region? Such programs would wake up in the active region, and possibly return to program scope executing in the active region. I don't know how to plug this except by disallowing programs to call design tasks by hierarchical ref. Yes - Some change to the LRM is necessary with regards to resynchronizing a reactive process after calling such a module task (the returned task output). Now all of the task code is going to execute in the reacitve and #0 re-inactive and NBA to the re-NBA region. 5a.Tasks declared in packages are considered design scopes (unless they are within anonymous program blocks). Calling such a task will have similar loopholes as 5. Now Immaterial 6. Are we all OK with Arturo's proposal to create a continuous NBA? I think that is a good idea. - For now, this will not be added (but no strong objections - could be added later if stronger support exists). 7. Should we allow NBA's in program scope, and create a re-NBA region in which they are scheduled? Dave has illustrated the usefulness of this construct for testbench modeling. He's not convinced about the need for a re-NBA region. I think it is needed in order to avoid blurring between design code running through loopholes in tandem with program code running. Yes (also covered in question #9) 8. If the answer to 7 is no, what are the semantics of a clocking drive to a program variable? Should that be allowed? (The answer was yes!) And it will be updated in the re-NBA region 9 Should we allow NBAs to program variables? - Yes and make the updates occur to a new Re-NBA region. Regards, Doug I reviewed all my emails and notes from the meeting and this mail is an attempt to consolidate everything. If no one else wants to volunteer to crank the revision on Arturo's 890-4 to 890-5, I can go ahead and do it this week. I found the following Mantis items which I think we should consider together with the overall 890 proposal: http://www.verilog.org/svdb/bug_view_page.php?bug_id=0000608 http://www.verilog.org/svdb/bug_view_page.php?bug_id=0000609 http://www.verilog.org/svdb/bug_view_page.php?bug_id=0000597 http://www.verilog.org/svdb/bug_view_page.php?bug_id=0000239 http://www.verilog.org/svdb/bug_view_page.php?bug_id=0000236 I'm not a big fan of 609. The others are pretty straightforward. In a very interesting coincidence, Eugene Zhang apparently defined our most recent ##0 behavior way back in Oct 2004! See Mantis #236 above. Also recall 594, which is slated to come up right after 890: http://www.verilog.org/svdb/bug_view_page.php?bug_id=0000594 I'd like to hear your thoughts on all these items. Most are quite short. And they could have a good deal of influence on 890's proposal. ======================================================================