RE: [sv-ec]E-mail Vote (part 1) Closes 12am PST April 24th

From: Jonathan Bromley <jonathan.bromley_at_.....>
Date: Sun Apr 22 2007 - 17:36:51 PDT
I'm not eligible for this vote, but I have reviewed these
proposals and my comments are below.  I have not attempted
to correlate them with comments from others, so there will
probably be some duplication - apologies if so.

I can't attend this Monday's call, so you can ignore all
this with impunity!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1777
~~~~

Red has been used for added text, blue for strikeout. Should it be 
the other way around?

One closing ] has been accidentally changed to ) in this 
excerpt (it was correct in the original LRM text):
  bins b2 = ( 2 [-> 3:5] );  // 3 to 5 nonconsecutive 2's
  bins b3 = ( 3 [-> 3:5) );  // 3 to 5 nonconsecutive 3's

Friendly amendment: close to the end of the proposal, the
long example string
     1 2 3 2 3 2 3 2 3 2 3 1 5 5 5 5 5 5
would be much easier to read if it had index numbers 
associated with it - perhaps like this:

     1st sample
     |       5th       10th      15th
     |       |         |         |
     1 2 3 2 3 2 3 2 3 2 3 1 5 5 5 5 5 5

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1371
~~~~

Clause 16 is now clause 23 in the merged LRM.  Presumably the proposal
should say which version it's modifying.

The first paragraph of the proposal (changes to 16.2/23.2) could
perhaps be re-worded to make it clear that a simulation may stop
earlier than this if some other code calls $finish.  Using
the phrase "the simulation shall terminate" seems to exclude that
obvious possibility.

I find this sentence very hard to understand:

   Calling $exit from a thread originating in an
   initial block of a program shall execute a 
   disable fork from within as well as end all 
   initial blocks in that program block.

Could I suggest the addition of two commas, and a slight
rewording?

   Calling $exit from a thread originating in an
   initial block of a program shall execute a 
   disable fork from within, and shall then end, 
   each initial block in that program block.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1384
~~~~

Clause 4.16 is now clause 6.22.3.  Cross-references 7.10 and 7.17
are now 8.10 and 8.17.

Clause 8.17 is now 11.8.

The following sentence doesn't seem to me to convey what I understand
the intent to be:

  It shall be illegal to stream a class handle with local or protected 
  members except when streaming the current instance this.

That sounds as though class-type members of "this" that contain 
local data can indeed be streamed if you're currently trying to 
stream "this".  It might be preferable to say

  It shall be illegal to stream a class handle with local or protected 
  members if those members would not otherwise be accessible at the
  point of use of the streaming operator.
  
That allows me to stream "this" when it is a derived-class object 
whose base class has protected members, but not if the base class
has local members.  It also prevents me from streaming "this" if
one or more of its members of class type has any local or protected
data.  I suspect that's closer to the intent?

I'm afraid I completely fail to understand the sentence

  Reconstruction does not modify any internal properties in 
  the target class object.

First off, we don't have a very good definition of "reconstruction"
at that point in the text ("reconstructed" is used in the previous
sentence, but in a fairly casual way).  Secondly, the process
of "reconstruction" (= unpacking into an object, I presume) 
most certainly does modify that object's internal properties.
I assume the idea is that unpacking never changes the value of
any class handle.  Would that description be OK?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1707
~~~~

Trying to describe the behaviour of bitstreaming rigorously
iS a reliable way to make my head explode.  I would prefer 
to see a description that used bitstream casting to get to 
a queue of bits, followed by an algorithm copying the queue 
of bits into a second queue of bits with appropriate re-ordering, 
and finally another bitstream cast to get that second queue of 
bits into the target.  However, I agree the new wording is an 
improvement.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1680
~~~~
OK

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1427
~~~~

I agree with Doug that the original wording is preferable, as it
licenses tools to throw an error if the user supplies a negative
signed expression.  If you want to be specific about the type,
you could say that the operand is of type longint but that it shall
be illegal for it to have a negative value.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1723
~~~~
OK.  Perhaps we could deprecate the num() method?  That would
help to explain why there are two identical methods with
different names!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1736
~~~~
OK.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                   Email: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sun Apr 22 17:37:28 2007

This archive was generated by hypermail 2.1.8 : Sun Apr 22 2007 - 17:38:07 PDT