Subject: Re: [sv-ec] Minutes from 1 December 2003 meeting
From: Neil Korpusik (Neil.Korpusik@Sun.com)
Date: Mon Dec 08 2003 - 09:52:11 PST
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 - 09:54:14 PST