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

Thanks Jonathan.
A little feedback is included below. 

> -----Original Message-----
> From: Jonathan Bromley [mailto:jonathan.bromley@doulos.com] 
> Sent: Monday, February 19, 2007 8:58 PM
> To: Warmke, Doug; sv-ec@server.eda.org
> Subject: 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 ..."?
DOUG: Sounds good.

> 
> (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. 
DOUG: Sounds good.  How about this slight modification?

   NOTE: As discussed in 15.14, ## cycle delays can be used 
   on the right-hand side of synchronous drive statements.

> 
> (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!
DOUG: That's true, but I still want the sentence in the Clause.
Otherwise the use of ##0 on the rhs of the <= operator will
be a source of head-scratching.

We can reword as follows:
     When used on the right-hand side of a synchronous drive,
     a ##0 cycle delay shall have no effect - as if it were
     not present.
What do you think?

> 
> 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?
DOUG: I'll 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.
DOUG: Good!

Thanks Jonathan.

Regards,
Doug

> -- 
> 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.