SV-EC Meeting Minutes 21 January 2003 Voting Members (3/4 or > 75%) (rrrrrrrrrrrrrrrxr) (-----a----aaaaaaa) Arturo Salz (Synopsys) (-----aa-aaaaaaaaa) Brad Pierce (Synopsys) (a-aaaa-aaa-aaaa-a) Cliff Cummings (IEEE 1364) (aaaaa-aaaa-aaaaaa) David Smith (Synopsys) (---aaa-a-aaaaaaaa) Francoise Martinolle (Cadence) (------------aaaaa) Jay Lawrence (Cadence) (aaaaaaaaaaaa-----) Karen Pieper (Synopsys) (aaa-aaaaaaaaaaaaa) Kevin Cameron (National) (aaaapaaaaaaaaaaaa) Mehdi Mohtashemi (Synopsys) (-aaaaaaaa-aaaaaaa) Neil Korpusik (Sun) (-aaaaaaa-aaaaaa-a) Stefen Boyd (IEEE 1364) (--------aa-a-a-aa) Stu Sutherland (IEEE 1364) Non-Voting Members (attendance based) (----------------a) Chris Spear (Synopsys) (----------------a) David Rich (Synopsys) (-aaa-a-aaaa---a-a) Dennis Brophy (ModelTech) (----------------a) Jayant Nagda (Synopsys) (---a-aa-----a----) Kurt Takara (0-in) (aapaa----------ma) Peter Flake (Synopsys) Guests (non-voting) (--a--------------) Adam Krolnik (LSI Logic) (---a-a----------a) Alec Stanculescu (Fintronic) (----------------a) Alex Zamfirescu (ASC) (---------aa-a-aa-) Don Mills (LCDM Engineering) (aa-aa------------) Heath Chambers (HMC) (-----a-a-a-a-----) Tim Corcoran (WHDL) Inactive Members (Missed last 4 meetings) (-aaa-------------) Dave Kelf (Synopsys) (--a--a-a---------) Michael McNamara (Verisity) (aaa--------------) Paul Graham (Cadence) (a----------------) Roy Armoni (Intel) (aapa-a-----------) Simon Davidmann (Synopsys) (aa---a-----------) Steven Sharp (Cadence) (-----a-----------) Stephen Meier (Synopsys) (-aaaaa--a--------) Tom Fitzpatrick (Synopsys) (-----a-----------) Zeev Kirshenbaum (Verisity) r => Regular meeting x => Extra meeting (Presence counts for attendance, absence does not) a => Attended p => Attended by proxy - => Missed Action Items: 1. Committee: Approve minutes from 6, 13, and 21 January. 2. Approve CH-32, CH-34 through CH-41 (chapter 3 and 4 changes) 3. Francoise: find all types with ranges on them. Check to see if shorthand notation can be specified and if it's already present. 4. Arturo: Add discussion of optional use of () to 7.10. 5. Arturo: In 4.7 make change on compiler error in comment to be a prose description. 6. David: Get clarification of use of slice notation with unpacked arrays from SV-BC. 7: Arturo: Define the order of evaluation for the new operator when used with dynamic arrays. 8. Arturo: Add a short sentence at the start of 4.8 that specifies dynamic arrays passed by value are passed a copy. 9. Jay: Add discussion of use of canonical form for ints in determining an index. 10. Jay: Define order of 01xz and define both integer and in indices for associative arrays. 11. Arturo: Clean-up Table 4-5 so it is clearer. 12. David: Extract action items from the body of the minutes and assign to appropriate people (if unassigned). Minutes taken by Mehdi Mohtashemi and Stefen Boyd. This was a full day meeting. No review of minutes or action items was done. Focus was on Clocking Domains, Signal Operations, Program Block, and Scheduling Semantics. 1. David presented a few slides, agenda of meeting, guidelines, [had problem with phone line!, took a few engineers to fix it!] 2. Review of Sections 13, 14, 15, including some preliminary discussion of Scheduling Semantics Section 13 Clocking Domains Jay: Clarify page 103, section 13.3, and page 115, section for sampling after all non-blocking-assignments. Can skew be a parameter? Can they be back-annotated, or specparam? Since users want to see it. Peter: there is overlap between specparam, param Jay: there is no mention of parameters, in program block, examples are all constants. Francoise: delayed constants: page 101, bnf, Jay: time_literal, should be what v2k defines. Arturo: it should be the same as the v2k defines. Dave: time_literal is an SV constant, it needs a constant expression. Jay: is there a reason for the assignment in example on page 102, to enable signal. Peter: it is synchronous, clocked notion. Neil: it is just meant for hierarchical references. Jay: data and ready are shorthand because they are in local scope. David: BNF is given for this. Jay: The step definition, smaller than smallest precision. Arturo: nothing can happen between those small steps. Neil: page 103: infinitesimal delta? is it confusing, Peter: It should say at the end of previous simulation time. Jay: Big issue, sampling with clock, clocks do not have fixed periods, every change on the signal has to be followed. location that tracks the signal. our experience in assertion env, many number of assertions. If clocking domains are necessary to get assertions to work, then we are creating lots of extra nets to do assertions. Peter: Are these nets or assertions? Jay: Are we requiring that assertions be sampled on clock. Jayant: Assertions need to be stable, Jay: Not necessary to do it, race conditions need to check if require to get the users to write clocking domains. Jayant: Clocked ones are efficient. Jay: Edge triggered assertions are the same as edge triggered latch that have same semantics in the race condition. Jayant: Also the assertions be used in formal tools., very important. Peter: The clocking domain Alec: Tester analogy, in testers you could not do it in the same way, Jayant: Emulation and hardware acceleration could benefit as well. Jay: What we are doing for this is the emulator knows where the clock edges are. Peter: This handles gated clocks. Jay: How is it handled? Arturo: It is a separate signal. Jayant: It is separable testbench/checker vs. design, assertions on the bus, transportable and usable across many areas. People write internal and external assertions, but need clocking domains for external assertions to make them portable. David: Sounds like using it for portability allows you to change the binding. Arturo: This simplifies the specification of clocking domains. David: There are two arguments: 1) it is not necessary and 2) it is expensive, Alec: The argument can be that there is a danger for expense, it can be misused, but it will help. Jayant: 3) third argument is we would like to have common with formal, and 4) fourth to be same as testbench as well as assertion. Jay: Do you rely on this to do asynchronous. Francoise: How would a user determine skews? Arturo: If a user knows what they need, then use it, otherwise Neil: Defaults are fine unless doing something specific Jay: This makes it look like cycle semantics are superior and desired. Peter: Yes it does simplify doing cycle based test benches. It is to encourage a synchronous testbench style. Kevin: How does this work with gated clocks. Mehdi: You define gated clock for the clocking domain. Kevin: How do I specify that it is a gated clock? It doesn't know how it was derived. If you are going through the problem of creating these clocking domains, then you might as well specify the relationship. Section 13.2 Clocking domain declaration David: What is #1step? Arturo: It is just like #1ns Jay: We need a better definition. Is it the smallest time unit, precision, local precision? Peter: It's the global smallest precision. Jay: There is a new concept about time steps. Stu: As soon as you make it a standard time specification, it's going to be wildly abused. Peter: Can't use it to define a timeunit or precision. Jay: Smallest global precision is what it needs to be used... Lots of discussion about implications of #1step being added Jay: I disagree with adding it into the language as a whole. Arturo: It's better than what we had before with 0. Jay: Yes, this is a better solution. Neil: Is the name of the clocking domain required. Arturo: Can have an anonymous so you can do assertions David: With the as yet unseen assertions part of the spec. Stu: If these clocking domains can occur anywhere in the design (including modules), why do we need a program block? Jay: You aren't alone, but can we discuss that with the program block? Neil: Problem with bnf. Skew definition is unclear Arturo: Should show delay or event control, not optional event control with delay expression always given Francoise: Clocking event is it one or can there be more? Brad: I would like a semi-colon with the default Jayant: There should be one. Jay: If you do that, it's better to add it somewhere else Neil: I believe we had a problem with zero delays driving. Arturo: Vera had a problem when going through PLI, but the problem is solved. Jayant: The semicolon is there at the end of 13.7, so 13.2 is just wrong. Brad: But that's not the same. Peter: We all agree that 13.2 needs a semicolon Changes: skew definition in BNF is wrong. Should be edge and optional # delay expression or optional edge and # delay expression. Skew used for default_skew must have delay. Skew used with clocking_direction must have edge. This is two different skew definitions. Needs cleaned up. "clocking _event" is really a special kind of event_control. Similar to @*. Needs cleaned up. Make BNF show ; at end of clocking_item more clearly (appears that default does not have a ;). Modify example to use it. Define step. Cannot use to define timeunit or simulator time step. It is the minimum global time precision. Indicate impact if other modules added that change global minimum. How general is it defined? Part of time literal or event_control. Clarify definition of delay_expressions. Is it a time variable or constant expression? Section 13.3 Input and output skews Kevin: Problem understanding last paragraph of 13.3. The approach specified doesn't work with mixed design styles. Brad: What about constant expression for skew. Either it must be a constant expression or it must be one of those two things. Arturo: If you use just a number, it uses the precision and unit of the enclosing scope. Peter: We could remove everything after constant expression. Neil: Should remove the entire paragraph for "An input skew of 1step..." Jay: There are two ways to add 1step, either by a keyword or by adding it to time literal David: I thought we were in agreement that it was limited to clocking domain. Jay: Then it should be a context sensitive keyword Changes: Remove "and can be specified either as an unsigned integer value or as a time literal" from second paragraph. Replace "an infinitesimal delta before the clock event" with "at the end of the previous time step" in paragraph after example. Clarify "after all nonblocking assignments" to be at the end of the verification phase (or similar from Scheduling Semantics). Section 13.4 Hierarchical expressions No changes Section 13.5 Signals in multiple clocking domains Neil: I think this implies that the same signal can appear in multiple clocking domains. Arturo: That is what it means Neil: But that should be explicitly stated. Brad: What does it mean 'logic semantics'. Dave: The output signal is the last thing, Stu: If the semantics of the logic changes what happens. Arturo: If there are several NBA on the signal, the last one wins. Jay: Really concept of drives, Arturo: clocking domains executes the signal drives., a bit of redundancy with respect to section 14.4 Discussion about removing reference to 'logic' semantics being removed. Kevin - What about multiple chips with same clocking domains Peter - There is confusion about use of clocking domain and the instantiation of it. Jay - There is no way to get multiple copies of same clocking domain. David - Are we changing anything? Added interface and program as restrictions for where clocking domains can be put. Changes: Add clarification that the same clock can be in multiple clocking domains. Move discussion about drive semantics (last two sentences of paragraph) to section 14.4 and remove reference to "logic" semantics. Section 13.6 Clocking domain scope and lifetime Kevin: if you have two chips in SOC, how does clock domain work. Discussion followed. Kevin: Why not define clocking domain in $root. Arturo: it is not usable, it has no ports, it has to use XMR. Changes: Add interface to the last two paragraphs (after program). Section 13.7 Multiple clocking domain example No changes Section 13.8 Interfaces and clocking domains No changes Section 13.9 Clocking domain events No changes Section 13.10 Cycle delay: ## Dave: event control in the clocking domain? #5 Arturo: #5 is not event control. Neil: there is a reference to 12.9, it should be 13.11 reference. Change: Add "the default clocking" after "using" in example of ## [5]; Make brackets bold in BNF Change reference from 12.9 to 13.11 Section 13.11 Neil: Example 1 and 2 on p108 don't show brackets, which are required. Arturo: We need brackets to make this the same as cycle delay in assertions. Arturo: brackets are consistent in assertion, cycle delay in assertion. Dave: we have to reconcile the delay syntax with Assertion Committee, Jay: we may want to support two different ways to define it. Brad: What do you mean by sub-modules? Peter: Nested modules have name available? Arturo: If it nested-module, or macro-module. name would be visible. Jay: Why is name visibility different for these than anything else? Arturo: It isn't. Arturo: This is specifying that only one default can be given and it isn't inherited and not available in nested modules. Jay: Requiring them in every module just make this less useful. Feeds argument that this isn't needed. Need to define. Arturo: Avoid confusion, it has to be explicitly specified. Peter: There is no implementation problem, but more usage. Arturo: This came from Vera's system clock. Jay: This makes sense in nested module. What is the visibility of this in the nested module? Dave: It should work like declaring timeunit, one allowed, and you can over-rule it. as long as it is defined in the scope. Jay: Was it intentional that the clocking domain is put in $root? Kevin: What about library of modules, how would they use the clocking? Peter: Nested modules are not to create packages. Arturo: If used, need to define the default clocking, it is invisible. Jay: If you do not have a default, then it is an error. Francoise: only one can be there... Kevin: how does this work with libraries. Stu: there is no such thing as sub-module, it is not inherited, nested module. Arturo: We will allow in the nested module. Francoise: Default type declaration, scope of them should be defined, since it is new wording. Changes: In Paragraph starting "A default clocking ..." replace "that particular module and not in any of its sub-modules" with "in the scope of the module, interface, or program" Deal with the issue of sub-modules on clocking domains. Modify description to make similar to declaration for timeunit. In example 1 and 2 add brackets for ## specification. i.e. change ## 5; to ## [5]; In example 2 change endprogram to endmodule and put entire example into a module definition. Section 14: Signal Operations Section 14.1 No Changes Section 14.2 Synchronization Jay: You have created a new class of objects that behaves differently when used? Peter: Yes there is a new class of objects defined. Jay: The crux of session is revolving around new objects that are synchronous. Why can't we treat them like a reg and do nonblocking assignments to them. Arturo: They have skew that makes them different. That makes a drive different. Difference between @foo and @ clkdomain.foo is that the clkdomain.foo has the involved. Jay: So if I write to a signal with a skew, it works just like non-blocking delay assignment after skew has completed. Brad: Why was the decision to put the delay on the statement instead of the signal. Jay: I don't understand use of @signal? Arturo: It's for inputs. We didn't change definition for event control, it's just the inputs. Jay: 14.4 delay number of clocking events (cycles) - How is this different than regular Verilog? Why isn't this ##? Arturo: @ operates on the clocking domain for the clockdomain, ## refers to the default clocking domain. Jay: If we use ## instead of @ then this makes lots of sense. Arturo: Well, ## uses default clock, but @3 would use the clock domain related to the signal in use. It's very valuable to provide. Stefen: Why can't we use ## but when signal is there, it uses clock for that signals domain. Neil: Users would prefer a way to define/show the clock for the clocking domain. Kevin: ...like having a method for clock domain. repeat for example. Jay: ## could be as notion of delay control. So this is just a shorthand for @posedge clk do something? I would rather see this as a intra assignment delay on a non-blocking assignment Kevin: Would you have a problem if you cross the clocking domains? Arturo: no concatenation on the left hand side. Jay: We've talked about is input skew valuable, now we're talking about the value of skew on outputs. I would write less statements. Dave R.: What about use in design? Jay: How would you write it in Verilog today: is it useful for design, is the verification phase complete mirror to design phase. Peter: You do not want to the design to react to testbench in #0 time after testbench has reacted to assertions. Jay: That is whole point of issue with scheduling phases... if we have use in design, then use of these clocking domains would negate need for separate phases. What is the difference between a drive and a non-blocking assignment? I don't see need for special semantics and design or verification, it's just a shorthand for doing the same thing as we can do with non-blocking questions. Alec: Existing Verilog language already has these concepts using notifiers for modeling UDPs. We have already done design and verification cycles in existing Verilog. Jay: What is a difference between drive and NBA? It looks like additional delay, output skew for this signal. back-annotating delay. Jay: This smells like way things were done through PLI, but I don't see why drives have to be different than non-blocking assignments. Jayant: The design and verification phase are mirrors of each other. Jay: If drives and non-blocking assignments happen in design phase as atomic, then why are they different? Arturo: Output drives are not done after non-blocking delays when not zero delay. Jay: So they show up as active events? Stefen: In the design phase? Arturo: Yes they are active events in design phase. You may want to use this for modeling. Alec: In addition you can produce different results using the clock domain. Stefen: Why are drives handled different than non-blocking delays with and without delays? Arturo: Because of the skew. Jay: I don't see why zero vs. non-zero delays on drive should be handled differently: 1) Why different semantics? 2) Why not just use non-blocking event? Francoise: It says that if you use blocking vs. non-blocking assignment. Jay: This is one of those constructs that could just be defined in terms of existing constructs and this whole section could go away. Example: clocking bus out skew #5 a ... bus.a <= foo; || \/ @ (posedge clk) bus.a <= #5 foo; Arturo: people want the design to respond in the same simulation cycle Jay: When you instantiate a design in a testbench, you want the same semantics. Mehdi: If you use a device to drive DUT, it will behave just like testbench. Jay: But if you follow those kind of coding style, you don't need the special evaluation phases. The testbench is just to model the way the outside environment will behave. Peter: Design vs. testbench races are a real problem. Testbenches tend to be used with blocking assignments with zero delays. We're trying to make this work. Stefen: I see lots of races with blocking assignments but non-blocking assignments in verification code... why do we need the design vs. verification phases? Arturo: Assertions need it. More discussion regarding phases... Peter: Have defined clocking domain that assumes that it's being driven from Jay: Two big things given: 1) Give VHDL signals 2) Give VHDL 'delayed stuff... So if we are going to going to get this, then we should just create a new operator that does this semantic using a new operator. Alec: To set the record straight - actually VHDL just hides the problem under the carpet, which isn't a good idea. Jay: To get what you need may need different operators, and you could get all virtues of race free verification code. (I am not sure where the following comments go but did not want to loose them) Arturo: you can do 0delay, happen in simulation point, skew on the output drive, design not to wait for the NBA. Need to re-word 111. in 14.4.1 Peter: the signals from the program block, verification block, should not be written in the design code. Alec: you can read the information and use it for modeling, and change the behavior and drive it, ***LUNCH*** Neil: Several people have problems understanding drives. Dave R: Issue of driving signal vs. clocking domain signal. Jay: If module and program drive same signal and it's a net, it'll get driver contention. If is reg, and delays would cause... Kevin: How do we drive asynchronously to the signal? Arturo: Just assign it, the usual way. (I think the following went in here ...) Stefen: why doing in drive. Arturo: because of explicit skew, it does look like NBA, if you read the value, it is the current value. #0 it appears in NBA time of verification phase. Kevin: It is a driver Arturo: If you have 0delay you have to use NBA, Peter: #1 is very common, for drive Arturo: What needs to be, requirement for testbench, emulators, etc, to be the last in the queue. Kevin: I would like to use these clocks/domains in the design. Arturo: This is part of problem, it would be good to explore ideas how to bring it in the design side. Jay: What is relationship between signal sampled or driven? Much question and answer... result was clarification that driving a signal in a clocking domain is done by verification side. Stu: From user perspective - wouldn't use anything in these sections. What I would like is a simpler way to do this, not a more complex way. Arturo: But this does do the same as what you can do today. Alec: This construct comes with extra semantics automatically. If you assign directly, you get normal semantics. Arturo: We looked at Verilog and added constructs to simplify the code written. Jay: Can see value of compressing code, but can't see value of different cycle semantics for these constructs rather than just doing expansions of new constructs into old ones. Alec: Adding determinism into verification is good, but not in the design as it hides problems. Much discussion about value of adding these new concepts. Stu: Would like a name change from "signal" since it sounds too much like a VHDL signal. Francoise - Call it synchronous operations Lots of discussion on what to call "signal"... but will just keep signal. Stu: Makes sense to merge into end of Section 13. Jay - how are we going to handle deciding whether we will keep program block and clocking domains? David: 13-15 should be done as a block Brad: Is it true that in section 14 signal always means clocking domain signal. Arturo: There may be other text that may use "signal" in other contexts. David - Claim has been made that testbench will be much smaller than Verilog equivalent. Can we get an example? Neil: in 13.9 we can use clocking domain to synchronize, so there should be reference in 14.2 to that way to synchronize. Jay: Just extend event control syntax to include synchronous aliases as well as clocking domains. Editor's note on comma separated event list is addressed when section changed to event control enhancement... Changes: Add Reference to 13.9 as way to synchronize. Change @ to ## in syntax. Remove bold after in definition of "specific_edge" Rework definition to use event_control. Add example of what shorthand is. In last paragraph replace use of primitive with "event control" Look at moving into Section 13 (evaluate issues including effect of assertions) - Arturo AI Change Signal Operations to Synchronous Operations for section title. Provide same semantics for delayed vs. non-delayed version of skew on signal drive - Arturo AI Section 14.3 Signal sampling Jay: Noted that it wasn't clear what part of cycle when inputs are sampled. Changes: Replace the "before the clock edge" in first paragraph with "just before read-only-sync time [ROSYNC]". Section 14.4 Signal drives Stefen: We started calling signal synchronous aliases, looks like we really need a new name. Cliff: We created genvar in 1364 when needing a new name. Consensus around clockvar Jay: clockvar can be a good thing for other things that you need to define in the clocking domain. Dave: Can it be hooked to a port? Changes: Expand explanation to define what a drive means in this context and remove the confusion of signals, drives, etc... Change @ to ## in syntax. Clarify use in design code (cannot be used). Provide "equivalent code expansion" as part of definition. In delay definition reference 13.10. Move "write semantics" from 13.5 to the end of 14.4. Resolve change from signal to clockvar. Section 14.4.1 Blocking and non-blocking drives. Changes: Expand description in last paragraph. Section 14.4.2 Drive Value Resolution Neil: There is confusion between 13.5 and 14.4.2. Jay: I think they are both true - depending on if reg or wire. Jayant: Need to clarify the distinction. Brad: Does this impact synthesis? Synthesis should ignore it. Jay: Assertions with clocks have been used all over the place. Arturo: If you hook it to a port it may have impact on synthesis. Changes: Add reg vs. wire distinction to discussion. Add support for drive(reg) and variable Section 14.4.3 Drive/assignment ambiguity Stu: If I do ##foo.bar, what am I referring to? Jay: Taking value of foo.bar and delaying by that number of cycles. Stu: How do I differentiate? Peter: It is an expression, and integer expression. Jay: It is just an integer expression that will be evaluated. Stu: Can ## be followed by everything that # can be followed by? Peter: Almost, but there are some things like 1ns that can't. David: Defined with ## in 13.10 as anything that evaluates to positive integer value. Arturo: We had talked the NBAssignment, and blocking ones. Peter: Blocking and NBA semantics are well defined by Verilog. Jay: It is where it is scheduled, active queue. More discussion about when in the cycle blocking or nonblocking drive is made (whether skew is zero or not) Changes: Change @ in example to ##. Review last paragraph. Section 15 Program Block (Both Stefen and Mehdi took notes and am I including both from here until Section 15.2) (Mehdi's notes) Stefen: Having a DUT as bridge, environment wrapping around the DUT, DMA engine, it lends itself to hierarchy and structure that is not in the program block, the common/shared objects or components placement. Some central error messaging, etc. In Vera these end up in separate classes. In Verilog, why within the confine of program block. Protocol checker has a thread of itself. It makes it easier to do it with always Mehdi: Protocol checks as in Assertions? Stefan: Yes assertions as well. Peter: Why can you not do it as many program block. Arturo: I do not see need for hierarchy. Stefen: they have to communicate with each other, if we put it in one thing, they can be separate program. I would like to have individual modules, contained in the module. Arturo: You can create objects statically, Kevin: What is the value in dynamic creation? Stefan: Be able to use program in module form. Arturo: Program block major benefit, the timing, everything is executing in verification domain [time]. Jay: Why is the testbench unique, why is it unique to create multiple always blocks... Neil: Since Verilog users are familiar with it to use. Stefan: There is restriction. Arturo: There is single entry point that allows full determinism. Stefan: You are inheriting a limitation. Arturo: Not arbitrary, Neil: You can use a separate program to have it finish the simulation. Jay: $finish is used currently we do not need another way. Peter: But there are many other programs that maybe running. Arturo: It is not a limitation, it is special time it executes, Stefan: The assumption is that the verification phase, but we want to use the constructs, but not the program block. Alec: It is something that you used in the Vera. Jayant: Are you proposing that some of the constructs [semantics, the dynamic allocations], all other functionality be used be some other time. Arturo: What you can not have is that you will not be able to to have ordered executions... Kevin: If we can put everything in the $root, why not?! Dave: How do you add verification phase functionality to module, how do you make it sensitive to the clocks? Jay: We do not need the verification phase,... Arturo: It will provide the functionality of deterministic/ordered verification activities, as well as the combination of assertions into the environment. Stu: There are strobed assertions. Peter: There is problems with it. Arturo: You can not write assertion, how do you synchronize to the clock edges, and make sure everything is stable? Jay: We write the assertions just like a design environment, that is sensitive to the same clock that the design is. Jayant: Users headache is with races. performance is not a problem, Arturo: If you do not want to use it, you do not have to use it. Stefan: We should exercise caution for it. Dave: The issue is that is there reason to have it exist, or not exist. Alec: Now if we need to remove major blocks from the donation there will be problem. ... Stu: If all of this can be done with a initall, something like always_test ..or some thing like this. Peter: Also task that you can define in verification phase. Dave: The constructs are different, the differences are important how do we resolve this? When I look at the scheduling semantics and the idea of having a stable time it makes sense. It is similar to what is required in analog and connection analog and digital simulators. Arturo: You can look and make sure that clock change is not triggering. Jay: You can do it at read-write sync, about to do ROSYNC, stable but many can be staying there. That can be generic change to language. Arturo: You sampled all signals 1step before, races are impossible, Jay: If we call the task to write the register, the design can not be modified from verification phase, you can affect the design, Cliff: Clocked block is what helps make one testbench to work for all RTL and gate netlist. ... Peter: Clock propagation, clock stability phases instead of design and verification phase. Stu: reactive assertion is what users want and it is a good thing. (Stefen's notes) Francoise: You can have only one initial statement? Arturo: Actually no initial keyword, but acts like it is in initial block. Stefen: Want to kill program block because I want hierarchy and static threads. Arturo: But it is needed because verification cycle happens there and it automatically finishes the simulation. Much discussion about what makes a program block special and valuable. Jay: Adding hierarchy to testbench allow substitution of implemented blocks. Arturo: We feel de-racing the testbench with respect to the design using design phase is a very important. Stu: We have strobed assertions to deal with need for stability instead of Jay: Can write assertions using non-blocking assignments and use same type of sensitivity as other always procedures Arturo: But this won't work with multiple clocks, etc. Jay: No, we have implemented this and it works. It's only a race if the signals used in the assertion are not clocked by the same clock used for the assertion. Arturo: You still have sampling overhead Jay: No we don't have to use sampled versions. Cliff: I would like to see what Jay and Cadence has done. If there is a way to do this without the phases, I would like to see it. Jay: I have found that the immediate stuff isn't required. You can write invariant assertions that would do best in ROSYNC time. Arturo: But then they can do something as a result of the assertion such as coverage or changing the state. Jay: If you are going to do an invariant assertion, you wouldn't write an invariant assertion this way. David: What do you do if you have assertions with races? Jay: The user has a race and has to fix the code. David: The whole justification for program block is the need for verification phase. Stu: Why can't you define clock domains and assertions in a module and give them a verification phase. Alec: program also assigns to objects like the clock domain. Jay: but we've already said that we can assign to them from a module. Stu: So why can't we do this with a module. Arturo: We need lexical containment More discussion of why phases are needed vs. not required Jay: In design task, called from verification phase, does this write to the design in verification phase. So the design can be modified in the verification phase. Kevin: Why not look for when event on clock will happen? Jay: That will work for nets, but not for variables. Cliff: Want to be able to test everything as first thing after seen clock. Jay: The idea of immediate processes is that not only clock has been changed, but other logic. Cliff: Usually use non-blocking for clocked logic vs. blocking for combinational logic. Jay: That's why I didn't send out long paper on immediate processes, since it doesn't solve problem completely. Other areas that this occurs is timing checks with notifiers. The comment is that the clock happens as part of the design phase. Jayant: This adds determinism, modularity, etc. Cliff: My claim is that by adding these extra phases is adding complexity to cycle that I don't need. Jayant: The purpose is to make this very clear to make assertions work. No clock value change allowed in verification phase is what makes assertions work. Peter: I would like to re-label the phases as clock propagation and clock stability. Cliff: I'll look into the changes to see how it addresses the issues I'm aware of. Jay: The idea of adding clock domains in order to add assertions to legacy designs is horrible. (End of general discussion) Section 15.2 The program construct Jay: Needed clarification for what could be declared inside a program block. I like a lot of the new constructs and want to make sure I can use these in modules. Arturo: You can. Brad: in 15.2, it should be list of ports declaration. K&R style. Jay: in 15.2, last paragraph.. limited to the procedural context. Arturo: Assertion or declarative context is what it can not be used. Changes: Add clarification of what can be declared in program block. Replace "list_of_ports" with "list_of_port_declarations" in declaration and in paragraph after example. Section 15.3 Static Data initialization Jay: Initialization of static data is done before always blocks? Peter: This is the same as 2001 if the right order was provided so that it is initialized before the always procedures fire. Alex: We are struggling with trying to test things the same way as the hardware. We can look ahead at the queue. David: Sounds like we're going through a new requirement looking at predictive testing. Arturo: There is a distinction with 3.0 where all this can be pre-computed and where it has to be done at runtime. Peter: Key issue is whether initializing a class pointer causes an event or not. Dave: There is clarification in the SV-BC, for the last paragraph in 15.3. Change: Replace "Note:" with reference to SV-BC clarification. Section 15.4 Scope and lifetime Neil: Looks like partial list of what can't have same name. Francoise: We need bnf here. Dave: The BNF is needed. Neil: This is the partial list of what is not allowed, is it going to be completed in BNF? Jay: Comment about global declarations... need to be aware of possible changes if $root is changed. Dennis: Stefen can put his shared testbench objects into $root. Stefen: Definitely not! I tried my best to eliminate or at least severely restrict $root in 3.0 Brad: statement on the top of page 115. block statements do not have to be named to create a new scope. it is redundant, can be removed. Changes: Remove next to last paragraph. Add BNF to clarify. Section 15.5 Multiple programs Jay: another ref to $root, can be shared by hierarchical references. Changes: Add hierarchical reference to first paragraph. Move second paragraph to 15.1 Section 15.6 Eliminating zero-skew races Changes: Clarify when execution is occurring by referring to Scheduling Semantics. Section 15.7 Eliminating races and SystemVerilog event queue Arturo: 15.7 should really be in scheduling section. Changes: Last paragraph should be deleted Need to reconcile nonblocking assignments and read-only synchronize time in second paragraph with Scheduling Semantics Move entire section to new chapter on Scheduling Semantics Section 15.8 Blocking tasks in cycle/event mode Jay: Need to update scheduling to be RWSYNC. Neil: Is this a requirement to run design code in verification time? Arturo: We saw the need for calling tasks from design in the testbench. Neil: So you are modifying the design from the design phase? Peter: Yes, but you can't modify the clocks. Stefen: Still not clear Arturo: You can call module task from program but not vice versa. Neil: first sentence of 15.8, restriction: from modules calling verification tasks is not allowed. Changes: Remove "other design" from first sentence. Rewrite last sentence to be consistent with new Scheduling Semantics. Section 15.9 Program control tasks Brad: last sentence of 15.9.1 should be the second sentence of the 15.9. Francoise/Dennis: Why use $exit instead of $finish? Peter: Since the first $finish ends simulation, whereas last $exit, will end the simulation. Jay: So if there is a Verilog testbench in the simulation that isn't done, the simulation finishes even though... Arturo: There is a final block missing, obvious emission, to do housekeeping. Changes: Add final block - Dave Rich AI 3. Voting discussion Jay: Would like to know if we are keeping program block, clocking domains, scheduling semantics. David: Considering email vote since this is relatively large impact vote for inclusion. Cliff & Jay: Is this a company vote or an individual vote? David: Inclined to make it a company vote. ***BREAK*** David: Delay in voting is due to issues with IEEE members voting. Vassilios is asking for motion to have IEEE members vote. Dennis: Stan at Cadence has made a motion and Dennis has seconded the motion. The vote is still out with board. Jay: If there is any question, and the board is acting on it, then we should wait to take the vote. David: Propose that we wait until we get clarification from board before taking vote. Cliff: I would like to hear from Dennis as to ModelTech's preferences regarding these things. Dennis: Given all the inquiries on integrating other languages into simulations, this might be quite helpful in meeting those requests. David: Next meeting is on Monday, it is a non-voting meeting. What do you think of making the non-voting meetings a normal meeting. Cliff: For those of us who are independent consultants, meeting every week is very hard. Jay: So for extra meetings in Jan & Feb why not allow those to accrue voting rights, but not hold them against voting rights for those who miss. David: Agreed. David: Where can we get another meeting in around DVCon? Discussion on meeting dates and times. Decided on half day face-to-face meeting on Feb. 27th (8-12) so that some could attend by phone. Cliff: So for extra meetings, will there be voting? David: No. Voting will happen at regularly scheduled meetings. Stefen: How about email vote? David: That should work. We need to set the guidelines. Changes: Create alternate proposal for program blocks and clocking domains to consider instead of current proposal in donation - Jay AI 4. Close Meeting adjourned at 5:09pm