RE: [sv-ec] Comments on 890-5.pdf

Doug and sv-ec,

sorry it's taken me so long to respond on this very simple
matter.

[Jonathan]
> > > I think we could both be satisfied by a fairly explicit
> > > discussion of the role and semantics of ##N as a delay 
> > > prefix, probably _before_ the material on "intra-drive"
> > > delay
[i.e. the syntax  cb.ckvar <= ##N expression;]

[Doug]
> > Agreed.  The _before_ would be good, since that will
> > be the main usage, and thus it would make sense to treat
> > it earlier than the more arcane usage.
> Let me know if you can come up with some explicit suggestions
> for rewording the proposal in this area.

In the end I think it's rather easy, since 15.10 already describes
the hehavior of ##N as a procedural delay control in some detail.
I'd like to suggest the following changes to 890-6's proposed text
for 15.10:

(1) Trivial friendly amendment: the very first words of 890-6's
added text for 15.10 are "The cycle delay statement ..."
Surely that should be "The cycle delay timing control ..."?

(2) Add the following text at the end of 15.10:

  Cycle delays using ## shall not be legal for use as intra-
  assignment delays either in blocking or in nonblocking 
  assignment statements.

  NOTE: As discussed in 15.14, ## cycle delays can be used 
  in synchronous drive statements, with syntax similar to
  that of a nonblocking assignment with intra-assignment
  delay.  

(3) Remove the last sentence of 890-6's text for 15.10:
      When used as an intra-assignment delay, a ##0 
      cycle delay shall have no effect - as if it 
      were not present.
This sentence probably belongs in 15.14, but in any case 
we've just stated that ## cannot be used as an intra-
assignment delay!

If change (2) is implemented, I don't think there's any risk
of confusion between the two uses of ## delay.  However, 
I'm still a little unhappy with the present wording of 
15.14 at the top of page 4 of 890-6, particularly the use
of "event_count" that doesn't appear elsewhere.  Perhaps 
someone else could take a look?


> The signed/unsigned nature of cycle_delay and normal delay.
> That is taken up in your new Mantis, [1739]
> so we don't have to worry about it anymore on this thread.

Agreed.  I haven't yet written a proposal for it; I'm hoping 
we can get consensus at the face-to-face before I do that.

Finally it's worth noting that Mantis 1717, which I reported,
is now completely subsumed in Doug's proposals for 890 so 
I suggest 1717 should be closed with no action.
-- 
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.