SV-EC Meeting Minutes 11 November 2003 1:00 pm. Tuesday Face-to-Face (rrrrrrrrrrxr) Voting Members (3/4 or > 75%) (aaaaaaaaaaaa) Arturo Salz (Synopsys) (-aaaaaaaaaaa) Brad Pierce (Synopsys) (--aaaa-aaa--) Cliff Cummings (IEEE 1364) (aaaaa-aaaa-a) Dave Rich (Synopsys) (aaaaaaaaaaaa) David Smith (Synopsys) (aaaaapaaaaaa) Jay Lawrence (Cadence) (aaa-aaaaaaaa) Michael Burns (Motorola) (-aaaaaaaaaaa) Mehdi Mohtashemi (Synopsys) (aa-aaaaaaaaa) Neil Korpusik (Sun) (--aaaaaaaaaa) Ray Ryan (ModelTech) ||||||||||||_ 11 November |||||||||||__ 3 November ||||||||||___ 27 Octobter |||||||||____ 20 Octobter ||||||||_____ 13 October |||||||______ 29 September ||||||_______ 15 September |||||________ 2 September ||||_________ 18 Aug |||__________ 4 Aug ||___________ 21 July |____________ 7 July Non-Voting Members (attendance based) (------a-----) Chris Spear (Synopsys) (-aaa-aaa-a-a) Dennis Brophy (ModelTech) (-----s------) Francoise Martinolle (Cadence) (--a-aaa-a---) Jeff Freedman (ModelTech) (-----------a) Peter Flake (---a--------) Stefen Boyd (IEEE 1364) (-a---a------) Stu Sutherland (IEEE 1364) Guests (non-voting) (--a-a-a-----) Don Mills (LCDM Engineering) (-----a------) James Young (HP) (-a----------) Kevin Cameron (National) r => Regular meeting x => Extra meeting (Presence counts for attendance, absence does not) a => Attended p => Attended by proxy s => Attended as proxy - => Missed Action Items: [identified with AI (#) in this text, # refers to AI number] Added this week (please see the site for existing action items): Note: Edits discussed in the meeting were applied to new versions of the documents which are already posted to the site. No Action Items were created for the edits. Minutes 11/11/03 taken by Mehdi Mohtashemi 1. Review of meeting minutes from 27 October 2003 meeting Motion: Accept the minutes from 27 October 2003 meeting with correction. Moved: Mehdi Second: Jay Abstain: None Against: None Passed 2. Review of Vote Results David: Copies of the extensions documents have been made. Ext-9, Ext-14, latest versions, are part of packet printed and passed Also given out: ERR-41(Dave Rich), Brad (Err19) Ext-9: Constraint discussion: Neil: Saw one typo: page 2 at the bottom, second sentence, last paragraph, 'weight is only meanigful...' n is missing. 12.14.3. Bottom of page 3, production expressions. 1364 states the length of expression this should say the same kind of things. The x,z are not mentioned here. The same comment on 12.14.4 (page 4) repeat production does not say anything about x, or z, in the expression. Ray: In 12.14.5, working through some examples. The items that are interleaved together, are they immediate token of sequence, how deep do you go into the definition of production. What is the legal path, can you do rand join of rand join. Text does not make it clear, if you fully expand the terminals, then do the interleave, or not. Arturo: I think implementation is unroll the whole terminals. Ray: The text needs to be updated AI: 12.14.5 - clarify that the depth of the unrolling is 1. Ray: In the grammer, page 1, 12.14. If you get something that gets 3 code block, can it be 2 code blocks rs-production list. If the rules for rs-production list have special semantics to it, then ambiguity in this will make a difference. Peter: Is it Left associative or right associative? Arturo: It is Left associative. I will check with implemenation folks/ grammer implementation. AI: Syntax 12-9: Clarify the associativity or removal of ambiguity from rs_production_list. Brad: Also on the repeat, do you have x in it, is it illegal if there is x? Arturo: Yes it will be illegal. Neil: It does not describe any of the information on x,z. If you get an expression you may have an x. Arturo: Generally the stimulus does not have x. David: Do we need to explicitly describe what it would do in x, z? Brad: In case expression you evaluate it only one time. David: Is there a proposal how to simplify this. AI: To add the clarification for case statement to indicate it works like the case procedural statement. Jay: Having three or several special statements here in this context makes it more difficult for users, I do not want to drive that rathole. Three items on this: 1. Is this production features really needed in the first place. 2. Namescope rule, that does not allow to get at these rules. 3. These things act like tasks, pass arguements, the behaviour of these must be better specified, arguments passing, how to disable them, Arturo: I do not understand why this is different from any other thing in the LRM., why should it be any different than regular tasks, you can not disable one of these. Jay: But these can take argument. In a regular task, if some thing is returned, production themselves can have return value. What happens if the task is diabled which has one of these productions, what would happen to the arguement. The production returning value when the task above it is disabled. What is the value of the parameter. David: How about a function that returns a value. Jay: You can not wait inside a function, so it is not the same. The other tasks, the value of the output arguement gets copied out. For this, is the value of the output arguement unchanged, changed,? if we return to this task. Trying to understand what the behaviour is when it is disabled. Peter: Is it static or automatic? Arturo: It is automatic, otherwise we would have problems. Ray: The terminal productions are regular code blocks. They can have any thing. Arturo: What would happen if you call two of these concurrently, if they were static. I can call a task twice/or/more. If we make it automatic it is consistent. Ray: Within the code block inside the productions, the default for code block would be automatic, where as in the regular code block the default is static. Arturo: Except classes. Ray: This must be stated. AI: Add statement that the randsequence, sub-scopes, are automatic by default. Brad: Where does the automatic start. Do you need a lifetime declaration in case to make it static. Arturo: randseq is where it starts, and you cannot make it static. Ray: What if you use tasks instead of productions. Reviewing the compare example on the board. The simple productions do really look tasks. You can do the if then else Generally put all the tasks in a class. Arturo: You can create them in the class, use virtual methods. Ray: Interleave, I declared another class, some support functions. Start method, initialize class, then call sync function, it has semaphores in it. You can do the interleave with this method. One thing I have not figured out, is break out of the inner loops. Arturo: You are trying to find equivalent semantics to not go for randseq. Ray: I wanted to do this, but both have advantages. For example, we have specifically put in repeat statement but not the while statement. The advantage is the semantics is defined in the language, whereas the tasks is with methodolgy to build it. I can see advantage for both. David: In a sense it is arguement for not having randseq. Jay: Glad you went through the exercise, Arturo: This does not preclude the randseq. David: So far all items have been answered, only one on the rand join, interleaving implementation. We can vote in general fashion, but no closure. Ray: There is a second issue. Example on page 7, function. The function needs to have begin/end, because it is part of randseq. Can you put a randseq in a function. Dave: You do not need begin/end for task/functions now. Arturo: If a randseq is a blocking randseq, you can not in a function. Dave: You can not call a task in a function. David: Any other questions/suggestions for this. Will wait until we get an email on the implementation. We can get it resolved and vote on it next meeting. EXT-14: Constraints. David: The major changes: object guards with constraint guards.[got rid of ordering issues, when you get error, and not]. Getrandstate from task to method to be consistent, process has to be updated to have getrandstate,setrandstate as well. Jay: Have we eliminated $getrandstate? David: Yes we did. Arturo: That was the implication. David: The constraint guard was the biggest change. Neil: Page 6, add queue to the list of array types [now queues is in] AI: Last line, the inside operator, add [] to inside operators on the bottom of page 6. AI: Page 7: k < A.size, The logic is backward. The relationship is backward, you may want just change the word. '...It allows the creation of .. ' in the middle of paragraph needs to be changed. AI: Page 9: on the disjunction table, R 1 entry becomes 1. Top of page 9: under disjunction, the second if sentence, what does 'ungaurded' mean. Arturo: It is just the case you were pointing to, in the table. It is an unconditional constraint. AI: Page 9, second if, it should be 'unconditional constraint'. Page 10: The first sentence underneath the example, remove the verb '...guard..' AI: Remove 'of the guard' in the three sentences for three examples. The predicate sub-expressions are Ray: Why, part of the predicate. AI: last sentence before the case examples, change 'which are' to 'which is' AI: The sentance under case3 in example on top of page 10. Case 3 on page 9, case 3 on page 10 [first one] also case 4 on page 10. Change it to: 'The conditional constraint .... is generated' Brad: You need a section for these annex, page 12. David: We already have AI for this. Neil: Section 12.11, starting on page 11. On page 13, last sentence on 12.11. If you are calling randomize inside a class you have to call no arguement to behave as a checker, it is inconsistent. Arturo: The issue is to allow null arguement. Jay: Randomization of scoped arguements is important. Why we can not have constraint blocks and refer to them in scope. A set of constraints like in a class, and call them in scope. Instead of syntax following with, I would like to put the name of constraint. The constraint would turn into a declarative item. It is still valuable to inline it, but I would like to do above. Arturo: These are typed, different than macros. You may want to make it like a macro use it where you declare it. Ray: If the constraint refers to x, then x that it refers to would be different where you call them with with statement. Jay: Yes. The extension to this would be to allow them to have arguements. Arturo: You are allowed to turn them on/off for use. David: This sounds like an interesting idea but not worked through yet. Jay: You are creating whole new class of constraints. David: Is there anything orthogonal to this? Any thing to change in this proposal. Need to explore it and work it through. Any other items for EXT14. Email the typos to me, will take care of them We have list of corrections, any one to move to accept the proposal with those question. Brad: Two foreach, one after another, you can not put ; there is no punctuation between constraint expression. Arturo: Every rule ends in a semicolon, page 2, is correct. Brad: Which one is the required {} for constraint. Arturo: You can do a ; or another {}. Motion: Accept EXT-14 with changes indicated. Moved: Arturo Second: Ray Abstain: Dave Rich, David: as a clarification, this is company vote, only. None Opposed: None, This is passed, we will get it corrected and posted in the LRM change. EXT-10: Functional Coverage (Section 20) Neil: Page 4, First large paragraph, ...When a covergroup... This is inconsistent. Michael: I would propose to change the instantiated to initialized. Arturo: I like Mike suggestion, to change implicitly instantiated to initialized. David: Do we have suggestion for better wording. Jay: The problem is with instances in the first paragraph. AI: PAGE 4: Replace instances with variables, defined with declared. Jay: In general coverage and constraints are needed, only thing about both of them is the dynamic nature of them. I need the static version of them, declare them statically, this is more closely related to classes. David: 20.5 is where we left off last time Jay: How about 20.4, change from attributes to keywords, ignore_bin, illegal_bin David: It used to be attributes of illegal and ignore. Arturo: You can actually query the coverage numbers, you can change the simulation semantics. There is semantics impact, attributes as of today does not make sense. David: Do we have time to get the attribute proposal [1364] through in the time frame. Jay: Ok, I will put this in the list of action items. David: That takes us to 20.5, page 10- starting. Jay: What is .intersect Arturo: It is a method, you can define the bins and call this method on them. Peter: conjunction of sequences in the sequences. Jay: I do not have a problem with reuse of the word, it is not in a way that is similar. AI: Replace the use of .intersect (pg 13) with the keyword intersect. Ray: Should the same be applied by the label created by coverpoint. Arturo: Yes, It is important. AI: Page 6. Paragraph under the syntax box. Add the sentence, The label also creates a heirarchical scope for coverpoint. Neil: Page 12, what about x, z values in the cross. Arturo: The coverpoint definition. The tool automatic creation[bins], x,z are not part of it. If user creates it x, z can be part of bins. Neil: On page 12, 256 vs 64 bins. AI: Second paragraph, 64 needs to be changed to 256. Michael: Is number of bins are not automatically chosen, if you cross those, where it is limited how would that work. Arturo: The cross auto bin is not limited. Michael: If it is possible to the bins for crosspoint is limited, then how would you know which ones they are, how do you do the partitioning. Arturo: Once you are running you only keep track of the limits.You can fillup those many bins, and then run out of them. Jay: So you do not pre-enumerate them and divide. Ray: So the user may not want to do that. Arturo: With the coverpoint, you need to compute the space but not allocate them, efficiency trade-offs. Neil: Page 12, second example. How do you determine the number of bins for an expression. Arturo: This is verilog, self determined expressions. It is 5 bits, for addition. 20.5.1: Neil: Bottom of page 13, AI: Permutation gets changed to combination in last paragraph on Pg. 13. Ray: On top of page 14, First line, AI: Get rid of bin, all first line Second line remove bin Third paragraph: remove bin 20.5.2 (Excluding Cross products) 20.5.3. 20.6 Options Jay: Can we query this option, can we treat it more like rand_mode. Arturo: If you want to set it during simulation, you need a global method on this, can not have a semantic check. If it is a struct type, we can check. It is implicit and exists at multiple points. Brad: On page 19, option and type_option are methods. Arturo: Option if implicit definition of struct. You can not declare additional members in it. Brad: You can use these things, what does it mean when it is standalone. It is a member of something, of what Arturo: It is a member of covergroup, coverpoint, or a cross. David: You can not extend the covergroup, not useful and interesting. AI: Add a struct declaration as a definition mechanism. In covergroup, in coverpoint, and cross. Brad: Is there a way to set these option as the same time. Arturo: By name, Arturo: A discussion on struct types, equivalency not by name, but by content. AI: table 20-1, 20-3 become struct definition. Arturo: Option is the name of declaration. You could not be able to assign it. Jay: What form does this struct take, named or anonymous? David: There are six named definitions. Arturo: Some can be set statically. Brad: If you did have a typed name, you would use :: Arturo: In a class, typed identifier can be nested, or a package. Jay: If we bring struct type into existence, needs to be declared in some scope, it would be built in a type of package. If this were true, then refer would be ::optionName, or optionName. David: Do we take the straw-man vote. Is it named, or not named. All those in favor, of named. Arturo: I would like to move, to name it. David: Are they part of covergroup so that they can be refered to. Anybody care for a name. AI: Structural definition with name, scoped to covergroup. Neil: Second sentence page 16, What does it say, I think it is instance specific. David: In LRM 11.18, class properties, instance constants. used there. AI: Page 16, first paragraph, delete 'is instance constant. It' AI: coverpoint in example is bold. 20.6.1: 20.7: Methods 20.8: System Tasks Ray: Is it important to have these systems tasks as opposed to methods. Arturo: To get the data from the full testbench. Michael: The database format for coverage data, are they different from vendor to vendor. Arturo: We have not defined it. Michael: There is no reason the vendors get together and define one standard. Jay: The only problem with this, saving environment, sometimes use different/many databases for different things, so one database for coverage is problematic. Arturo: Can reset the database, Jay: We will probabely add extensions to this later on. AI: page 18, add the word function in 20.8 title and the first page. Arturo: I would want to remove get_inst_coverage from 20.8, does not add to the functioanlity. AI: Remove $get_inst_coverage from 20.8 Brad/Ray: Why is 20.9? Arturo: Here the coverage query of individual bins, would have been described in 20.9. But does not need to be there. AI: Remove 20.9 sections. David: Section 8.10 event control was included. Jay: Was this there when we were voting for this proposal. Arturo: Some text was there that alluded to this. Arturo: The semantics is named events , event that gets triggered. begin or end of task. Jay: The motivation for this in coverage group, that the coverage groups be sensitive to beginning or end of tasks. Neil: This is not included in assertions? Arturo: Any place that event is used. Dave: Does disable trigger end event for task? Peter: No, it is stated in the paragraph. David: Is the suggestion to add disable real? Jay: It would not be strange to add disable. Dave: I think you need to test the block is active or not. David: For the purpose of coverage that is not needed. The only suggestion I have heard, is addition of diable. Jay: The ability to handle the 0-delay cases. Peter: The aspect oriented items may be required. Arturo: Even with aspects you can not. Jay: Looks like in VHDL, 'transactions, it goes through before you know you need it or not. I would recommend that we remove this section to a separate proposal and move with functional coverage, keep it separate. It has ramifications outside of coverage. AI: Will move this section, create EXT-16 from this. David: Except the last item, the only other major item is the structure declaration. I would like to move that we approve this with the modifications. Jay: Again, I would note that this is related to implication syntax. Motion: Accept EXT-10, with changes discussed in meeting. Moved: Arturo Second: Neil. Abstain: none Opposed: none. Passes. David: Some erratas, and AIs, or look at 'Reacting to Assertions'. Ray: I have not gotten to this yet. David: I do not know if people have looked at. Jay: I am not prepared to debate this today. David: Is it useful to have a discussion on it? Jay: What are the other options. David: Implication operator (Jay sent out email). Is there a benefit for us, Spend 15 minutes to review this. Jay: The 'next cycle' is more like ##1 in the sequence term. Sequence implication vs boolean implication. The operators are difficult to intuitively figure out. In SV, alternative one is acceptable. In constraint implication, in transitions, it is fine. Arturo: When you use boolean implications the => is used. Jay: Is there any reason we should not use |->. For constraints we use =>. Today we have two oeprators. Arturo: 1. In constraints, => this is non-temporal, overlapped, bi-directional. 2.In assertions: |-> this is temporal, overlapped. 3. also |=> temporal non-overlapped. 4. boolean (PSL) -> Implications (non-temporal) 5.and in coverage -> transition operator. Jay: Original suggestion was to use ## for transitional dely. It is close to the counting operator. The alternatives: JAY1: 1. |->, 2. |->, 3. |=>, 4. ? 5. |=> JAY2: 1. -> , 2. |->, 3. |=>, 4. ? 5. => Peter: =>, ==>, |=>, ?, ->, Arturo: =>, |->, |=>, ?, -> Arturo: Could we use => instead of ##1 in sequences. Jay: Peter's suggestion is interesting, but with PSL will be difficult. In PSL |-> is a boolean implication. Neil: Either one of Jay's options is better than doing nothing. David: What about a straw-vote: Jay1,2 gets 4, the other two get 2. David: I will bring it up in chairs meeting on Thursday. David: We will delay the 'lifetime of automatic variables' Neil: It has not been merged into the proposal, we really need to have it in writing. David: In next Monday meeting we need it. Two others: 9, ERR-9: Brad: Will go through the document for BNF. 5.5 In BNF, Section 5.5, added footnote on BNF on data declaration. Rather than change the syntax, 12.6: This is class variable. Peter: Is this very useful? Jay: Given this change, if i refer to static object in a class, Brad: You can use this as a data type, David: The BNF was inconsistent before. Peter: This is static, Jay: Can this syntax, be used, when i am refering to object outside of class. a = C::B#(4)::X; Do we have to have an object within C, Arturo: You do not need it, the static one always exist. The parametrized types you do not need to create instances of the object. David: Is this described anywhere in 11.23? Arturo: May not have been explained there. Peter: This is why i would like to restrict this to typedefs. typedef B#(4) foo; foo::x; Arturo: Then could you have said a=foo::x; did not have to create it in class. This is what is different than module, a parametrized module does not come into existence until instantiated. Brad: The next change, variable declaration. I like 1995 italics. Jay: I prefer identifier, Brad: I prefer member_identifier, in A.9.3 we need to say member_identifire= identifier. struct_union_ A.2.4: variable_decl_assignment Motion: Accept ERR-9 proposal. Moved: Brad Second: Arturo. Abstain: none Opposed: none Passes. ERR-41 David: Next is one page from Dave Rich, ERR-41, associative array index. Neil/Peter: What is an empty value. Dave: empty string, empty dynamic queue. Jay: Why make a null value. Dave: You can not compare the null value. You are pointing to something that does not exist. Jay: A structure with different feilds, with null handle. Dave: That is not part of my change, my change is if you have unpacked type. Jay: A null class handle itself can not be used as an index. Neil: This is talking about expression Jay: It is the struct with valid fields and some null handles. Arturo: There is ordering, this removes the ordering. Dave: I was only following the existing rules. As long as equality defined for null handles Arturo: yes, not the relational operation on the handle. Peter: null is an unordered case. Dave: We have to go back and change section 4.9.3, you can get rid of bullet 3, David: You have to say in 4.9.3, null is valid Motion: Remove the third bullet, and modify 4th bullet to say empty and null bullet. In Section 4.9.3 change to null is valid. Moved: Dave Second: Michael Abstain: Arturo Opposed: None Passes Motion: Move to accept the ERR-41 proposal with the changes Moved: Dave Second: Mehdi Abstain: None Opposed: None Passes Arturo: fork-join unrolls to level one, We have an answer one. David: With that clarification I would like to vote on EXT-9. Motion: Accept EXT-9 with changes noted. Moved: Arturo Second: Neil Abstain: None Against: Jay Passes 3. Meeting on Monday, David: start with reacting to assertions, EXT-7, virtual interfaces and ports EXT-3. I am concerned with Jay not being there. Jay: I have breifly looked at the virtual ports, David: Do you have any problems with, either one more comfortable with. The next one is EXT12 Bitstream support. 4. Next meeting Monday November 17, 2003, 12:00-2:00 pm 5. Meeting adjourned 5:22 pm.