Subject: [sv-ec] Minutes from 8 December 2003 meeting
From: David W. Smith (david.smith@synopsys.com)
Date: Tue Dec 09 2003 - 12:23:26 PST
Here the minutes from Monday's meeting.
Regards
David
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>
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
This archive was generated by hypermail 2b28 : Tue Dec 09 2003 - 12:23:14 PST