Subject: RE: [sv-ec] Minutes from 1 December 2003 meeting
From: David W. Smith (david.smith@synopsys.com)
Date: Mon Dec 08 2003 - 10:32:13 PST
How very strange. They come from the same file... Well, at least the ones
posted on the site are correct.
Regards
David
David W. Smith
Synopsys Scientist
Synopsys, Inc.
Synopsys Technology Park
2025 NW Cornelius Pass Road
Hillsboro, OR 97124
Voice: 503.547.6467
Main: 503.547.6000
FAX: 503.547.6906
Email: david.smith@synopsys.com
http://www.synopsys.com
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Neil
Korpusik
Sent: Monday, December 08, 2003 9:52 AM
To: David.Smith@Synopsys.COM
Cc: sv-ec@eda.org
Subject: Re: [sv-ec] Minutes from 1 December 2003 meeting
Hi David,
The text version of the minutes doesn't match the html
version. Item 5 is missing and some of the text right
before item 5 is also missing. The html version appears
to be complete.
Neil
> "David W. Smith" wrote:
>
> Greetings,
>
> I have updated the site with all of the latest documents from the
> meeting on Monday. This includes the changes to EXT-12.
>
>
>
> I am in the processing of completing the LRM changes for SV-EC which
> will be posted later today.
>
>
>
> Here are the minutes.
>
>
>
> Regards
>
> David
>
>
>
>
>
> SV-EC Meeting Minutes
>
> 1 December 2003 12:00 pm. Monday
>
>
>
> (rrrrrrrrrrxrxrx)
>
> Voting Members (3/4 or > 75%)
>
> (aaaaaaaaaaaaaaa) Arturo Salz (Synopsys)
>
> (-aaaaaaaaaaaa-a) Brad Pierce (Synopsys)
>
> (--aaaa-aaa---a-) Cliff Cummings (IEEE 1364)
>
> (aaaaa-aaaa-aaaa) Dave Rich (Synopsys)
>
> (aaaaaaaaaaaaaaa) David Smith (Synopsys)
>
> (-aaa-aaa-a-aap-) Dennis Brophy (ModelTech)
>
> (aaaaapaaaaaa-aa) Jay Lawrence (Cadence)
>
> (aaa-aaaaaaaaaaa) Michael Burns (Motorola)
>
> (-aaaaaaaaaaaaaa) Mehdi Mohtashemi (Synopsys)
>
> (aa-aaaaaaaaaaaa) Neil Korpusik (Sun)
>
> (--aaaaaaaaaaaaa) Ray Ryan (ModelTech)
>
> |||||||||||||||_ 1 December
>
> ||||||||||||||__ 24 November
>
> |||||||||||||___ 17 November
>
> ||||||||||||____ 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)
>
> (-------------s-) Doug Warmke (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):
>
>
>
> AI-47: Arturo: Update EXT-12 with comments from meeting
>
> Reword last paragraph on page 1 from:
>
> the first dynamically-sized item is resized to accept all
> the
>
> available data (excluding subsequent fixed-sized items) in
> the
>
> stream;
>
> to:
>
> compute the size of the source, subtract the size of the
> fixed
>
> size data elements in the destination, then adjust the size
> of
>
> the first dynamically sized object to the remaining size;
>
> Page 3, first example: Change syntax to SV (add ; to function
> and
>
> replace Packet with endfunction)
>
> Page 3 BNF: Change first stream_concatenation to
> streaming_expression
>
> and add use in primary.
>
> Page 4, end of first paragraph: Change:
>
> If the data is smaller than the slice-size, the data is not
> sliced
>
> (no padding is used).
>
> to:
>
> If, as a result of slicing, the last slice is less than the
> slice
>
> width then no padding is added.
>
> Page 4, second paragraph: Change:
>
> they recursively traverse the data until reaching an
> integral type.
>
> to:
>
> they recursively traverse, in depth first order, the data
>
> until reaching an integral type.
>
> Page 4, 3rd paragraph: pack operator to pack operation
>
> Page 4, 4th paragraph: unpack operator to unpack operation (2
> times)
>
> Page 4, 7.16.1, 1st paragraph: unpack operator to pack
> unoperation
>
> (3 times)
>
> Page 4, 7.16.1 title: Change title to "Streaming dynamically
> sized-data"
>
>
>
> AI-48: Arturo: Modify ERR-4 example to show the race condition
> with
>
> automatic. Suggestion of second process follows:
>
> begin
>
> automatic int l = j; // Generates a race condition
>
> #l $write("%0d", l);
>
> end
>
> AI-49: David: Remove the e.g. clause when putting implementing
> ERR-50 LRM
>
> change.
>
>
>
> Minutes 12/1/03 taken by Mehdi Mohtashemi
>
>
>
> 1. Review of the meeting minutes (5 Minutes)
>
>
> http://www.eda.org/sv-ec/Minutes/SV-EC-Minutes-2003-November-24.txt
>
>
>
> Motion: Accept Minutes of 24 November
>
> Moved: Ray
>
> Second: Michael
>
> Abstain: Brad (was not at meeting)
>
> Opposed: None
>
> Passed
>
>
>
> 2. Review of open Action Items (2 Minutes)
>
> David: Vassillios asked us to re-reivew EXT-16, to get an
> agreement
>
> a vote which is not a tie, if we can deal with it.
>
> eda.org, maybe on line by later today,
>
> Third item is AI-18.
>
>
>
> AI-18: Create appendix for built-in standard package: Assign an
> owner
>
> Volunteer: to be fine
>
> David: Cosolidate all uses of :: with std::, and consolidate
> appendix
>
> all of standard packages, looking for volunteer. To create
> an
>
> appendix just for the standard package. Try to find someone
> to do
>
> the editorial documentation.
>
> Ray: Just the text or the complete definition?
>
> David: Prototype declaration and definition.
>
> Will look for volunteer later.
>
>
>
> 3. Review of Inter-committee dependencies (10 minutes)
>
> OCR-2: Discussion on inside proposal from SV-BC
>
>
>
> David: Intercommittee dependencies. Did anyone look at the inside
> operator
>
> at BC.
>
> Dave: No comments on it so far.
>
>
>
> OCR-3: Sequential constraints
>
> David: Anyone here in AC meeting earlier today? Any action/change
> on
>
> the sequential constraints? it is referring to withdrawal to
>
> their extension2 (AC). Extension 1 was still keeping the assume.
>
> Neil: There is nothing in EXT2 on svAC about assume.
>
> David: I think assume is there in another extension.
>
> The sequential constraint is withdrawn.
>
> Any comments/questions on this from last meeting?
>
> Neil: Its part of program block.
>
>
>
> 4. Review 3.1a Extensions and discussion (50 minutes)
>
> Complete review of:
>
> EXT-12: Bitstream support ( minutes)
>
>
>
> David: The latest one is v2, November 17th, posted on the site.
> Just sent it
>
> again to the reflector.
>
>
>
> Starting with Neil's comments:
>
> Page 1:
>
> Issue 1.
>
> Neil: Last paragraph Page 1, the sentence about 'unbounded
> dynamically
>
> sized' is confusing.
>
> Dave: The sizing happens first, What size the dynamic sized
> needs to
>
> be, then the transfer occurs. If fixed size byte appears
> first,
>
> followed by dynamic sized for a 10 byte, fixed size gets the
>
> first byte, dynamic size byte gets the 9 bytes. If in
> reverse,
>
> the dynamic sized gets the first 9bytes, the fixed size gets
> the
>
> last byte.
>
> Neil: I do not have a problem with that, writeup is not clear.
>
> Dave: Exclusion should mean subtracted. Algorithm should be
> fixed size
>
> data should be calculated then the dynamic sized gets all
> rest.
>
> When you say excluding the data, you mean the size of data.
> It
>
> does not distinguish between the content and the size.
>
> Neil: I think intent is fine.
>
> David: How to clarify it in the text? Does it need something
> else?
>
> Dave: It is two steps, determine the size of dynamic structure
> and the
>
> second step to transfer.
>
> Ray: Depending on the size, it could cause an error.
>
> Dave: Yes.
>
> Ray: If the structure contains qint, followed by q of bits,
>
> Dave: I think that is an error, only one dynamic object can take
> it.
>
> David: How do we deal with it?
>
> Dave: Both the content and size of data, we are talking about
> excluding
>
> the size of data.
>
> David: So you are excluding all fixed sized data.
>
> Dave: You calculate the size of the source, subtract the size of
>
> fixed sized data element (in the destination), then adjust
> the
>
> size of first dynamically sized object to match the
> remaining
>
> object.
>
> Neil: The error situation is discussed later, page 2.
>
> Ray: That could be large size queue followed by small queue. Why
> can't
>
> you have that.
>
> Dave: It gets complicated.
>
> Ray: Would there be any reason to handle something that you do
> not know
>
> what it is. If you had a dynamic sized inside it, is it
> saying
>
> that I can only get the bits if there is no other dynamic
> sized
>
> item.
>
> Dave: It makes the compile time checking more complicated.
>
> David: Here is the proposal. The sentence in the last paragraph
> gets
>
> replaced with:
>
> compute the size of the source, subtract the size of fixed
> sized
>
> data element, then adjust the size of first dynamically
>
> sized object to the remaining size.
>
> Arturo: I think this is more confusing than original one.
>
> Neil: I think the original one is more confusing.
>
> Arturo: In the verbage you need to say that this is the
> algorithm.
>
> Dave: Can we propose later errata for this.
>
>
>
> David: Lets go through the rest of proposal and see if this is
> the
>
> only change. We have hit two of Neil's questions.
>
> On to the third question.
>
>
>
> Page 2:
>
> Issue 3.
>
> Neil: Where it says that it is of type Bits should the order of
> the
>
> bit range be on the left?
>
> Dave: It should not matter since it is converted to a stream
> whether
>
> it is packed or unpacked.
>
> Arturo: This is an unpacked array so it is ok.
>
>
>
>
>
> Ray: On page 2. With this assignment, variable to cast of
> another
>
> variable. convert it to bitstream and cast it to the left
> hand
>
> side then convert pack. Is this the same as explicit
> casting?
>
> Arturo: You cannot cast an unpacked array. This is what this
> allows.
>
> You can do it with integrals.
>
> Dave: Explicit casting of unpacked/packed items is prohibited.
>
> David: The question is, if it is legal as an explicit cast does
> the
>
> bitstream conversion result in the same thing.
>
> Jay: The answer to the question is yes.
>
> David: The new thing ist that you now have this with unpacked
> data.
>
>
>
> Ray: When you packing a struct if I happen to have real data
> then I
>
> cannot use this. Is there a way to get around this?
>
> Dave: I think the answer is no, since real numbers are not
> allowed in
>
> packed data.
>
> Jay: We could define it in terms of bits2real and real2bits then
> you
>
> could include it.
>
> Arturo: We could do that.
>
> Ray: In streaming data, you may have non-integral data, try to
>
> redefine it with a nunion, you cannot do that.
>
>
>
> Page 3:
>
> Issue 4.
>
> Neil: Looks like typos here.
>
> Arturo: Correct.
>
>
>
> Issue 5.
>
> Neil: In the BNF box at the bottom stream_concatentation is
> duplicated.
>
> Arturo: Correct. The first should be streaming_expression. It is
>
> used in primary.
>
> Brad: Where is it used? Where does it go?
>
> Arturo: It is used in primary. Look at concatenation, this is
>
> modeled after that.
>
> David: For the first one we should change it to streaming
> expressions
>
> and add the primary production using it.
>
>
>
> Page 4:
>
> Issue 6.
>
> Neil: The paragraph below the example seems really strange. For
> example
>
> if it is a list will it walk the list to find all integral
> types?
>
> Arturo: This is only for arrays, structs or classes. Handles are
> not
>
> a bit-stream type so it would be an error.
>
> Jay: Is this going depth-first search and be specified?
>
> Brad: Do we define the algorithm for structure literals?
>
> Arturo: Not sure what the question was.
>
> Jay: Imagine s1 with struct s2 and integer, s2 contains an
> integer.
>
> With depth first you get the integer in s2 if depth first.
>
> Arturo: What would it mean to be breadth first? The left to
> right
>
> implies depth first.
>
> Jay: I agree that this makes sense.
>
> Ray: Not sure what depth first clarifies.
>
> Jay: You could do it breadth first.
>
> Ray: I thought the order of declaration was used.
>
> Brad: Add "in depth first order" after "recursively traverse".
>
> Arturo: Fine.
>
>
>
>
>
> Neil: The intent is to find all the streaming types. If a
> non-streaing
>
> type is found then it is an error.
>
> Arturo: Correct
>
>
>
> Ray: Does slice size mean the width of each slice or the total
> size of
>
> the data? For data of size 12 does it get sliced and does it
>
> get padded? (Last sentence of first paragraph on top of 4).
>
> Arturo: If you specify a slice of size 8 with 2 bits of data
> there is
>
> no slicing to be done.
>
> Ray: With 12 bits and 8 bits is there padding?
>
> Arturo: There will be 4 bits of padding.
>
>
>
> Arturo: If the data (or the remainder) ...
>
> Ray: When the data is sliced partial words are not padded?
>
> Ray: Suggest the following:
>
> If, as a result of slicing, the last slice is less than the
> slice
>
> width then no padding is added.
>
> Neil: Ok
>
> Arturo: Ok
>
>
>
> Issue 7.
>
> Neil: Should refer to operation and not operator in the two
> paragraphs
>
> above the example. There are no pack and unpack operators.
> There
>
> is only the streaming operators.
>
> David: It is being viewed as two different operators depending
> on LHS
>
> and RHS usage.
>
> Dave: It depends on the type, source or destination, as to you
> do a
>
> pack or unpack.
>
> David: The one would be pack on one side, and unpack on the
> other side.
>
> Neil: If that is what you do I find it confusing. Just use
> operations
>
> instead of operator.
>
> Arturo: It is fine.
>
> Neil: The long paragraph on the bottom is the same thing.
>
> David: There is no where that the pack operator is defined
> before you
>
> use it.
>
> Arturo: It is defined there.
>
> David: The behaviour of streaming operator is mentioned,
> streaming
>
> operator is defined by which side of the operation it is on.
>
> We need to clarify.
>
> Arturo: 1364 has the same problem. They talk about it with the
>
> left/right hand side.
>
> Dave: There is no pack operator there.
>
> David: There are pair of operators for streaming. Section 7.16,
>
> rationlize the verbage. Usage of streaming operator when
> doing
>
> pack/unpack operations seems to be the point. Not defined. I
> think
>
> Neil is right to change them to operations.
>
> Arturo: Neil is making a distinction between the operation and
>
> operators. I agree with the change.
>
> David: So we have to do it in 7.16.1 where ever pack/unpack
> operator
>
> was used.
>
>
>
> Issue 8.
>
> Neil: The section 7.16.1 talks about packing and unpacking. The
>
> title is somewhat misleading.
>
> David: So you are suggesting it should be 'unpacking/pakcing
>
> unsized data'
>
> Dave: Arturo's usage for unpack reformating is the same.
>
> David: The paragraph Neil refers to on page 5, talks about
> packing.
>
> Ray: Is it using the with expression.
>
> David: It is using the with expression, dynamically sized data
> during
>
> packing and unpacking. Should we change it?
>
> Arturo: I think streaming dynamically sized-data is better.
>
> David: Ok.
>
> Arturo: All the pack operators would be changed.
>
>
>
> Page 5:
>
> Neil: I had to read section several times, jumping into details
>
> before more verbage up-front.
>
> David: The first paragraph does not do it? The question is just
>
> ordering of the statements?
>
> Brad: In array_range_expressions, does it say the right thing.
>
> Can $ be an expression? There is no restriction, you can
>
> put anything there?
>
> Arturo: No.
>
> Brad: So this is truly an expression?
>
> Arturo: Correct. Does this cause any problems with new BNF work?
>
> Brad: Will look at the BNF implication.
>
>
>
> David: We have gone through changes, like to get a straw vote on
>
> approving this extension with the suggested changes. The
> result
>
> will be used to see if we go to a email ballot.
>
>
>
> Jay: In general this extension is fine, yet more syntax for what
>
> users can write.
>
> David: This is not an official vote but will be done by compnay.
>
>
>
> Straw vote:
>
> Motion: Straw vote on approving EXT-12
>
> Jay: yes
>
> Neil: yes with corrections
>
> Michael: yes
>
> Ray: yes
>
> Mehdi: yes
>
>
>
> David: We will update the proposal, place it on the reflector, and
> send
>
> out an email request for vote.
>
>
>
> 5. Review Errata list (55 Minutes)
>
> Proposals:
>
> ERR-50 (Arturo): Program visibility rules
>
> David: This is just adding a restriction that was missing (but
> agreed
>
> to in 3.1).
>
> Jay: Remove the e.g. since it would have to be updated when
> other
>
> things change.
>
>
>
> Motion: Accept ERR-50 with Jay's suggestion
>
> Moved: Arturo
>
> Second: Jay
>
> Abstain: None
>
> Opposed: None
>
> Passed
>
>
>
> ERR-51 (Brad): Method calls and class parameter overrides
>
> Jay: What is the essence of the change?
>
> Brad: About method call, currently you can put it on an
> identifier, if
>
> there is an expression for method call, to move it from
> primary
>
> on identifier to any expression.
>
> The other you can not overwrite a parameter in a class with
> scope
>
> operator. Also you can do a part select with the scope
> oeprator.
>
>
>
> Motion: Accept ERR-51
>
> Moved: Brad
>
> Second: Arturo
>
> Abstain: None
>
> Opposed: None
>
> Passed
>
>
>
> ERR-55 (Ray): Remove use of priority in constraint block
>
> David: Any issues or discussion?
>
>
>
> Motion: Accept ERR-55
>
> Moved: Ray
>
> Second: Brad
>
> Abstain: None
>
> Opposed: None
>
> Passed
>
>
>
> ERR-53 (Arturo): Add BNF for virtual interface declaration usage
>
> David: This is just the BNF. It was requested in the last
> meeting.
>
>
>
> Motion: Accept ERR-53
>
> Moved: Arturo
>
> Second: Michael
>
> Abstain: None
>
> Opposed: None
>
> Passed
>
>
>
> ERR-54 (Arturo): Split 19.8.2 into 19.4.5 and 19.8.2
>
> David: This is the rest of the pdf file, just related to virtual
>
> interfaces and example its usage, use of clocking and
> modport.
>
> Jay: I would like to read that one, to see how it came out, can
> not
>
> look at it now.
>
> David: We will delay this until the next meeting.
>
>
>
> ERR-4 (Arturo): automatics in fork/join_none
>
> David: It is not on the temporary site. Arturo sent it, AI-40.
>
> It remove note out of 9.6, adds the initialization for the
>
> automatic variables.
>
> Neil: The example I sent was incorrect in that it had a begin
> end.
>
> Could we put the begin end around the #k $write.
>
> Jay: The last sentence in the second to last paragraph allows
> room for
>
> things defined within the scope to exist after the end of
> the fork
>
> join block.
>
> Arturo: Correct. This has the same semantics as v2k.
>
> Jay: Does this allow me to have a task which is entered, do a
>
> fork..join, and then leave the scope and have the scope
> within
>
> the fork..join be active?
>
> Arturo: Correct.
>
> Dave: They cannot be accessed outside the scope since they are
>
> automatic.
>
> Jay: What if it is not an automatic task but is an automatic
> variable.
>
> Can it be accessed?
>
> Dave: No.
>
> Jay: Just have the begin k=k+17 $display, with two copies of k.
>
> Arturo: I do not think this is what the proposal says, it is one
>
> variable for all the processes, here.
>
>
>
> Jay: The example may be better to add a second example with a
> begin
>
> end.
>
> David: Suggested example:
>
> begin
>
> automatic int l = j; // Generates a race condition
>
> #l $write("%0d", l);
>
> end
>
>
>
> Ray: Do you get multiple copies of k in each of the branches? Do
> they
>
> have overlapping lifetimes?
>
> Arturo: Correct.
>
>
>
> Motion: Accept ERR-4 with addition for example from above
>
> Moved: Arturo
>
> Second: Neil
>
> Abstain: None
>
> Opposed: None
>
> Passed
>
>
>
> ERR-44 (Jay): Consolidation of implication operators
>
> David: It was out on Nov 24th. Should we go off at this point if
> Jay
>
> can not walk through it.
>
> Jay: We have already walked through it.
>
> David: You have list of changes in the LRM?
>
> Jay: Yes. Boolean expression used inside of constraints for now.
>
> future in assertion.
>
> Neil: I have not checked all the references, but I agree with
>
> the consolidation.
>
> Ray: Does this just apply to constraints.
>
> Jay: Yes. May be used in for boolean implication operator later.
>
>
>
> Motion: Accept ERR-44
>
> Moved: Jay
>
> Second: Neil
>
> Abstain: None
>
> Opposed: None
>
> Passed
>
>
>
> ERR-52 (Arturo): Events used within coverage are immediate
>
> David: It is better to delay this until next meeting.
>
> Neil: How are we going to do this, with EXT-16.
>
> David: To make the behaviour of event associated with it,
>
> to make the trigger of event, you do not need ERR-52.
>
> Neil: I would prefer to do ERR-52 first before EXT-16.
>
> David: That is fine.
>
>
>
> ERR-45 (Dave): Wildcard equality
>
> Dave: I am waiting for inside operator resolution, then I do not
>
> have to worry about wildcard.
>
> David: We will wait until the inside operator proposal is
> resolved.
>
>
>
> No Proposals:
>
> ERR-8 (Dave) Using event control with methods
>
> ERR-20/21 (Arturo) Update of example based on ERR-4
>
> ERR-47 (Brad) Keywords as identifiers
>
> ERR-56 (David) Fix all locations in LRM for built-in package to
> use std::
>
>
>
> 6. Meeting logistics (2 minutes)
>
> December 8
>
> Complete Errata list review and votes
>
> Review and re-vote on EXT-16
>
> Start LRM editorial review
>
>
>
> 7. Next Meeting
>
> Monday December 8, 2003, 11:00am-1:00 pm PST
>
>
>
> 8. Meeting adjourned at: 1:52 pm
>
> Name:
SV-EC-Minutes-2003-December-1.txt
> SV-EC-Minutes-2003-December-1.txt Type: Plain Text (text/plain)
> Encoding: quoted-printable
-- --------------------------------------------------------------------- Neil Korpusik Tel: 408-720-4852 Member of Technical Staff Fax: 408-720-4850 Frontend Technologies - ASICs & Processors (FTAP) Sun Microsystems email: neil.korpusik@sun.com ---------------------------------------------------------------------
This archive was generated by hypermail 2b28 : Mon Dec 08 2003 - 10:30:29 PST