SV-EC Meeting Minutes 8 December 2003 11:00 am. Monday (rrrrrrrrrrxrxrxr) Voting Members (3/4 or > 75%) (aaaaaaaaaaaaaaaa) Arturo Salz (Synopsys) (-aaaaaaaaaaaa-aa) Brad Pierce (Synopsys) (--aaaa-aaa---a-a) Cliff Cummings (IEEE 1364) (aaaaa-aaaa-aaaaa) Dave Rich (Synopsys) (aaaaaaaaaaaaaaaa) David Smith (Synopsys) (-aaa-aaa-a-aap--) Dennis Brophy (ModelTech) (aaaaapaaaaaa-aaa) Jay Lawrence (Cadence) (aaa-aaaaaaaaaaaa) Michael Burns (Motorola) (-aaaaaaaaaaaaaaa) Mehdi Mohtashemi (Synopsys) (aa-aaaaaaaaaaaaa) Neil Korpusik (Sun) (--aaaaaaaaaaaaa-) Ray Ryan (ModelTech) ||||||||||||||||_ 8 December |||||||||||||||__ 1 December ||||||||||||||___ 24 November |||||||||||||____ 17 November ||||||||||||_____ 11 November |||||||||||______ 3 November ||||||||||_______ 27 October |||||||||________ 20 October ||||||||_________ 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) (-------------s-a) Doug Warmke (ModelTech) (-----s----------) Francoise Martinolle (Cadence) (--a-aaa-a-------) Jeff Freedman (ModelTech) (-----------a----) Peter Flake (---------------a) Ron Goodstein (First Shot Logic Simulation and Design) (---a-----------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): AI-50: Arturo: ERR-52: update proposal for wording, show examples, and gather usage. AI-51: David: ERR-54: Section 19.4.5: Remove first declaration of program T in second example during creation of LRM change. AI-52: David: EXT-12: Section 3.16: Fix the use of size in the last example. Fix the channel declaration in the next to last example. Minutes 12/8/03 taken by Mehdi Mohtashemi 1. Review of the meeting minutes (5 Minutes) http://www.eda.org/sv-ec/Minutes/SV-EC-Minutes-2003-December-1.txt David: Neil made the comment on the html version vs the text version, HTML version is correct, no idea how they got mixed-up. Motion: Accept Minutes of 1 December Moved: Neil Second: Arturo Abstain: Cliff (missed meeting) Opposed: None Passed 2. Review of open Action Items (2 Minutes) AI-5 (Cliff/Arturo): Response to Cliff's email David: Cliff do you want to go through discussion? Cliff: I would like to go through it with Arturo and others today. David: We will do it after this we are done with the errata and extensions. AI-18 (David): Appendix for built-in package contents David: I will close this AI since ERR-57 is open. AI-39 (): Review SV-AC Assume proposal David: Has anyone looked at this proposal from this committee. Neil: Where is this? What category? David: In AC website, extension lists, item number 1, ../sv-ac/extensions It has some connection to biasing mechanism in constraints. 3. Review of Inter-committee dependencies (10 minutes) OCR-2: Discussion on inside proposal from SV-BC David: I believe OCR-2 has passed in sv-bc. Inside operator. Dave: Inside operator is avaialble to all other types, originally only available to integral types. Also added wildcard capabilities. David: We can take a look at by next meeting, we can close it then. OCR-3: Sequential constraints David: This one is also removed. 4. Review Errata list (55 Minutes) Proposals: ERR-20/21 (Arturo) Update of example based on ERR-4 David: Placed on the website last week, re-work of example in process description. Arturo: Two changes, automatic local variable. The next one was in the second loop in the forked process. The first one was fixed when agreed on the mechanism on local copy. Neil: It used to wait for single process, order was not defined. Change to all process. Motion: Accept ERR-20/21 Moved: Neil Second: Arturo Dave: Is the comment on "wait for first process to finish" correct? Arturo: Yes. Abstain: None Opposed: None Passed ERR-45 (Dave): Wildcard equality Dave: Now that inside is passed. Will withdraw. David: ERR-45 is withdrawn. ERR-52 (Arturo): Events used within coverage are immediate Arturo: Change is simple, coverage object looks at sampled variables. This is a clarification of what was there before. Jay: I think it is crazy. There is no other place in the language that responds to an eventimmediately. What if more than one event, assertions, wake-up in wrong region of scheduling. This says that there is special use of event control. All other threads suspend execution and only coverage block is active. This is incompatible with the current definition of the simulation cycle. Problems with parallel processor execution with events. Arturo: It is unique and it is a special event control. We are trying to bring determinism to something that requires it. Jay: We have already added cycle accurate determinism in other ways. We should use them. Arturo: Granted that those mechanisms work for sampled events that ar clock edge triggered. For cases were we are trying to do measure metrics on items which are not sampled we require the ability to sample as this. For example with transactional coverage. Cliff: Neil have you done any coverage of the transactions? Neil: I do not know of anyone that has used this explicitely. Arturo: Sun does explicite coverage of the DUT. Neil: It is possible that it is used and I do not know it. Arturo: There are other customers that use this. Jay: Whatever triggering event they use they can use the sampled one to get the deterministic results. What region does the coverage block run in? We should not modify the scheduling semantics. Arturo: There is no user code being evaluated. There is no potential for a race or users modifying the state. It is only for sampling the data at that point. If you are using signals from the clock then it is stable. Jay: We should not modify the simulation cycle to add special semantics for coverage. Arturo: Example for networks. One place to cover is creating the traffic, another is where it is injected in the DUT. You may want to get coverage on both. This is all running at zero time. If we do not do something like this then it will make a big burden for users to create special code just for coverage. Cliff: I am pursuaded by Jay's comments. I am uncomfortable with this, can be added if users demand this, users feedback is very important on this. Neil: I was leaning toward favoring this. Arturo: There is an option to user coverage as a strobe (wakes up at the end). If you are covering the software world then what you want is this kind of coverage. Jay: If you want is a glitchy event control mechanism then it is used differently. Dave: Is there some way to cause a covergroup to be triggered procedural? Arturo: Yes. This is one way to handle the this. Jay: I do not think the wording says it. No other simulation activities happen during this. Michael: Either way, the wordage is insufficient in defining what happens. David: I apprecitate the comments you are making about potential impact on simulation cycle. Cliff: We have got users out there who want many things. David: The issue that Jay raises that event inherently are un-deterministic, fundamental basis here. This is fairly useful to have determinism. Arturo: You are running in parallel and HW, you do not want to force the determinism. There is an option to use the coverage as strobe, coverage wakes up at the end. Peices of code executing at zero time, you want to have glitchy coverage. Dave: Is it possible to do this procedurarlly, would that take care of this case? I am agreeing with Michael, neither one of the words are clear, we do not define what an instant is. Arturo: This is a separate syntax. It is not a procedural event control. It is in the context of a cover group. It is not the same. Jay: They should work the same. It is an event ctronol. Arturo: It is similar to clock domain, it is a little bit different, not as simple as event cotrol. Jay: No, it is an event control. Litterally triggering an event, the next thing to do is to wake up the coverage group, not a good thing to add to the language. If we want to add sampling regions to cover group, same way we did it with assertions and clocking group. Arturo: They are different. It samples in the past. It is a little bit different. Jay: It is the same. You do not do anything special. Arturo: Yes you do. Michael: Would it be correct to say that the singles being sampled in the coverage block is similar to adding a clocking block. Arturo: The cleanest semantics would be to describe the event trigger to have function call semantics. It would guarantee that no state was modified and would return right away. Dave: We do not have atomic execution semantics. Function calls do not update. Arturo: I said function call, not atomic calls. Jay: I download this to an emulator and then trigger this. What is the state? Arturo: First, how do you run testbenches in the emulator? Jay: I need to gurantee stability. Arturo: I did not ask for the gaurantee stability, I just asked for a function call. Jay: This does not exist in the language. We need to then create a new semantic (function execution control) if we need it. Michael: I tend to agree. If you do coverage on the wire level and the DUT then you have to do it correctly. This is an experimental area. Arturo: Not at all. This has been in use for years.You can call function calls to sample. Function calls call be used in a few places. Event control, explicit events, mailboxes. Mehdi: On the functional coverage, there are two aspects. One is purely on the stimulus generation (create packets and instructions and measure) and this is being used heavily. People are looking at the generation mechanism and coverage on it. Jay: Why does the procedural mechanism not work? Mehdi: You are doing it multiple times. Arturo: You start with straight forward test program, then change constraints and coverage points. You do not want to have to modify every place it is used. You would have to insert function calls every place. This is painful and error prone. Mehdi: What is being covered if this is in 0 time? Jay: Anywhere they are calling events, they can place the function call. Sample when I call this function, do not know why we need to change the event control mechanism. We can do @@ and only allow it for coverage group, it was just an example. Arturo: If we were to change it to use @@? Jay: I do not particularly like that either. Arturo: This was your proposal. In assertion would be zero effect, in clocking domain ,there is no code to execute, same as in coverage group. Jay: Any where you can use event control you can stick this, we will have many problems. Arturo: I am not suggsting to change event control. This is not executing user code here. I am providing very specific semantics for the coverage triggering which happens to use the event control syntax. There is already a way to turn this to strobe, this gives you two alternatives, either right-away or ROSync at the end of this. Cliff: Mehdi's example is interesting. I would like to see an example of how this makes things easier. Jay: Suggest we either vote or update the proposal and try again. David: Looks like there are some new ideas coming up based on Cliff's question. It would be useful to get an example to show this. Cliff: I would like to see an example and more input on how wide spread the usage is. Michael: Is there anyway via the PLI to get this functionality. Cliff: If the PLI is the only way to provide it then I would be inclined to support the proposal. Michael: I am assuming this is used in Vera, do users see using it. Arturo: If you are sampling things in the Verilog world then the device is stable and all of the information is stable. You get the values from the observe or before the propone regions. Michael: So, in the case where we are doing coverage sampling, are all of the cases caught? Arturo: The use of this is on the "software" side. Michael: Never mind, this is not the DUT [HW]. David: Lets see if we can get the example. Jay: Are you going to update the wording. Arturo: Yes. David: Action item to update proposal for wording, show examples, and gather usage. ERR-54 (Arturo): Split 19.8.2 into 19.4.5 and 19.8.2 David: Virtual port, modport, split into two sections. Neil: Section 19.4.5 page 4, example bottom of page 4, looks like you do not need the two lines for program T, take out the first program T. David: Any other comments, Motion: Accept ERR-54 with removal of duplicate "program T" in 19.4.5. Moved: Arturo Second: Michael Abstain: None Opposed: None Passed ERR-59 (Brad): Undo of block_item_declaration removal Motion: Accept ERR-59 Moved: Brad Second: Mehdi Abstain: Neil Opposed: None Passed ERR-60 (Brad): void' casts Brad: Using of void' was present in LRM without parens. BC indicated that this is not correct. This proposal adds the parens. Motion: Accept ERR-60 Moved: Arturo Second: Neil Abstain: None Opposed: None Passed ERR-61 (Brad): expect property statement Brad: May need to defer, since property expect from AC. Davdi: We will until AC passes their changes to expect No Proposals: ERR-8 (Dave): Using event control with methods Dave: I have a proposal and are having it reviewed. ERR-47 (Brad): Keywords as identifiers Brad: Yes, looking at it. ERR-56 (David): Fix all locations in LRM for built-in package to use std:: ERR-57 (David): Create appendix for std package David: Have someting in process, for next meeting. ERR-58 (Arturo): State that constraints deal with 2-state values David: We did discuss it during the meeting, so need a writup for next meeting. 5. Review 3.1a Extensions and discussion (50 minutes) Complete vote on EXT-12: Bitstream support David: I got half of the votes, can we get the rest. This is the bit stream casting, pack/unpack proposal, updated. Straw poll was ok with it, only thing was checking the changes to make sure that everyone is ok with it. Neil: There were couple of items on this. Page 3, second example byte stream channel, it should be byte channel[$] for the queue. Example below that last two lines using size, need to subtract one. size-1, and second one is size. Mehdi: For casting can you specify name only or can you specify the type. Arturo: For casting do we require a name only, Brad: Name only. Arturo: Before the casting there should be declaration of channel type typedef byte [$] channel_type. David: So we have change to the declaration in the same place. David: Any other discussion or issue? If not I would like to get all the votes on this with changes on the examples Motion: Accept EXT-12 with example modification above Moved: Dave Second: Arturo Abstain: None Opposed: None Passed Discuss and re-vote on EXT-16: Event control for coverage Neil: I think the resolution of EXT-52 is required. Arturo: This is available for design. There is no deterministic ordering being handled for design. This works just as expected. If you use the beginning of the task as a trigger in the design. Jay: And if you want to do it than you add a trigger to the block. Arturo: This does that without modifying the code. Jay: This is my point, I did not see the writeup, what I thought these would behave [begin and end] immediately, same as coverage event control. They have to act a little differently, begin - to have all sensitive to it, to start immediately, and end - wake everybody up after variables outside the task. That is the relationship between this and EXT-52. Arturo: If all you are using is the entry/exit of the task/block then this is no different then @posedge(signal). Jay: I do not feel any different about this than weeks ago, people get different behaviour. Arturo: I do not see what unexpected is, everything happening in parallel like everything else. We do not have to go and modify the code if you want to trigger off it, it is particularly usefull for coverage. David: There is two things: adding a general mechanism to trigger off of events in the simulation, also how do you want trigger events to occur in the coverage, which is not part of this EXT-16 proposal. Jay: Because the two are interrelated. Looking from outside without disturbing the inside, is a stimulus/testbench activity. If there were a design thing, there would have been a signal in there. David: Nobody suggested how the design/testbench worked, only the coverage. Jay: I am arguing if you are doing this one, you have to pass EXT-52 as well, I am not happy with either of them. In the design, they will get the undeterministic behaviour. Arturo: It may wake up or it may not, it is in parallel, you should not expect any thing else. How is it different than @(posedge read), read is a wire in design? David: Neil were you suggesting to delay this until we resolve EXT-52? Neil: I was just suggesting this. Cliff: Sounds good to me. David: One more meeting left, next week, final deadline for anything going into 3.1A. Last chance. Jay: I do not think my vote on this will change. David: Yes, I know, you have expressed it. For the other errata, there were support from some of the people who were hesitant. The first case where events control are confusing, the second is that it arised from the coverage needs. It seems like there is a need for it, is it a case we show the need for begin end for coverage. Do we need the ability to measure coverage off of entering and exiting blocks? Anybody disagree that this is a requirement? Cliff: I am not sure. Neil: I think it is useful to have it, it is just that one case I know they are not using it today, more of simplistic. An area that is opening up now more. David: Jay, do you think this is needed? Jay: It is useful for coverage yes. David: So the issue is not with the requirement, the issue with semantics. Jay, do you have a proposal on how to meet this requirement? Cliff: In my mind for these that have not been resolved, we can use the donation in the IEEE committees. David: But I asked Jay a question on this. Jay: No I do not have a proposal. David: The options are: 1. To withdraw the proposal. 2. to get this on the vote, and pass 3. In case of a tie we would take it to vassilios. There is a proposal here that has been implemented and used, yet can not be framed in a way to get sufficient support for it, there is no counter proposal. Cliff: Maybe the problem is not having enough experts. I think the experts in IEEE who also are knowledgable about coverage they can give guidance. Jay: I do have a problem with adding a generic kind of named events to do this. I do agree with need for coverage usage. Creating coverage around procedural block of code that are not aware of coverage gathering. Adding new semantics does not cut it. The two proposals do not add up to a whole, open up pandora's box. Arturo: If we were to restrict this event in the coverage, would that help. David: When this thing is being used in coverage, similiar to what you were proposing (Jay), looking like an event trigger when it is not in coverage. Jay: Together when they solve the problem of begin/end yes, but adds new mechansims for evnet control. David: So if we just restrict it in coverage, proposed in a general fashion. Jay: So if we went back there, only occur in coverage, I have to look at it again, it may work. David: The basic capability is of sufficient value. Doug: In that time the block enters, worried about the race. Arturo: You look at the data, typically the entry point to the block, at end, usually data is stable. We have both mechanism, turn it into strobe, not caring about value. Doug: Isn't there determinism there, blocks in the design portion? Arturo: From the design yes, but in the testbench it is different. Doug: For the design it is ok, for the testbench you are worried about it. David: We'll look at it then. 6. AI-5 Cliff David: Now going back to AI-5, Cliff. Cliff: Email from July 22. Cliff: What seems make scheduling in these chapters confusing, helps me to talk about what regions we are talking about. For one, nothing executes in reactive region, events are scheduled in reactive region for execution in active region. Arturo: The observed region, no user code is executed. Cliff: The clocking domain section, seems like to call it clokcing block, since clocking domain means different to hw designers. The third item is differentiation for zero-delay and no-delay. Arturo: I support your request for change clocking blocks. Cliff: I will write a proposal for change of clocking block. Dave: This creates scope, block. Arturo: In fact in all proposals blocks has been used. Neil: I prefer clocking block. Cliff: There was a feedback loop from the observed region, figure 14-1. Feedback arrow stays. Section 14.3, fourth paragraph, after 1 through 11 numbered items, change observed region evaluation with inputs sampled in pre-poned region. Arturo: Is that redundant, Cliff: There is a lot of talk about that the samples are at the pre-pone of the previous slot. Arturo thinks it is redundant? how about others? Page 126 in standard 3.1. Jay: The whole paragraph should be removed. I would change this paragraph. Property expression and sample values are in assertion chapters. It would be dangerous to place it here. Cliff: Second to last paragraph on page 121, 3.1 [132 in 3.1a] Arturo: I would leave 'code-specified in the prgoram block'. Just remove the 'to occur'. Cliff: so just delete 'to occur'. I proposed some additional wording, but I skip that. At the top of page 128 3.1, or 132 in 3.1a, the paragraph, starting with pre-pone region. I am proposing to add a second sentence: pre-pone region for assertion Jay: Did we specify that sampling #0 happens in pre-pone region? Arturo: The #0 sampling occurs in observed region. The only code in that region is PLI. That is the only thing the paragraph states. Cliff: So my addition, talking about it in two places. Arturo: I would not put it here, leave it in assertion regions. Cliff: Three more paragraphs, I would like to change zero-delay, explicit #0 delay or no-delay. Jay: I agree with Cliff, replace zero with #0. Cliff: In section 15, page 131 in 3.1, [page 137 in 3.1a]. The wordage, simple edge, if you want to say negedge, you need posedge in clocking block, otherwise you would not be able to use negedge. Arturo: It should be ok, if you use the @edge, you should be able to use either posedge or negedge. Cliff: This is for driving stimulus, at least my example. Jay: I thought the whole point, wake-up on edge, then driving on the next edge. If we say we wake this thing up on any edge but driving occurs on negedge. Arturo: I just said that this is implementable Jay: It is implementable, but I do not feel it is useful. Cliff: Next one, next page, section 15.3, default input and output skew. After 0 for the output skew, in the NBA region, one, is this correct, 2, is it needed. Arturo: Yes, correct, Jay: It is fine. Cliff: Top of next page, page 133, for 3.1, page 139, for 3.1a. Skew of 0. Rewrite it with: input with explict #0 skew are sampled in observed region. and assignment to design signals... with no-skew are driven in the NBA region. Arturo: I agree with your first change. The second one would be incorrect. More appropriate to say clocking block output with no-skew. Cliff: clarification to changing zero to no-skew. 7. Meeting logistics (2 minutes) December 15 (11 to 1) Complete handling of EXT-16. Complete Errata list and action items Start LRM editorial review 8. Next Meeting Monday December 15, 2003, 11:00am-1:00 pm PST 9. Meeting adjourned at: 1:03 pm