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

Comments below... 

> -----Original Message-----
> From: Jonathan Bromley [mailto:jonathan.bromley@doulos.com] 
> Sent: Monday, February 12, 2007 4:34 AM
> To: Warmke, Doug; sv-ec@server.eda.org
> Subject: RE: [sv-ec] Comments on 890-5.pdf
> 
> Doug,
> 
> > (2) Signedness of cycle delays:  Cycle delays in a ##
> > construct must be integral and non-negative.  It's not
> > entirely clear what happens if a negative number appears
> > in this context.  [...]
> > DOUG: You seem to have taken care of this with one of
> > your proposed edits below (requiring cycle delays to
> > be non-negative integers).  That's fine with me.
> 
> I'm not sure it is taken care of.  My concern is
> that someone might unwittingly supply a negative 
> integer in a ##N, and because ## requires non-negative
> the expression is implicitly cast unsigned'(N).  If
> that were the case, no error would ensue and we would
> probably have a very bewildered user a rather large 
> number of cycles later.  It seems to me there are three
> viable choices: 
> (a) treat all ## expressions as unsigned, avoiding any 
>     error but risking crazy delay values;
> (b) silently clip negative expressions to zero;
> (c) follow (a), but issue a warning or even an error 
>     for a negative value.
> 
> My personal preference is definitely for (c), but it's 
> probably more important to follow whatever already 
> happens with #N delays - what *does* happen there?!

DOUG: I like (c) as well.
Any suggestions for wording that into the LRM?
BTW, I inspected the 1364 standard and the topic of
negative delays is not treated clearly for delay_control
and delay_value.

There is an indication that delay_value should be an
unsigned integer.  But that's all.  A similar proposal
could be made for delay controls - maybe as part of a
new Mantis?

> 
> > 15.12 Input sampling
> > ~~~~~~~~~~~~~~~~~~~~
> [...]
> >   When an input or inout clockvar appears in any expression 
> >   its value is the signal's sampled value, that is, the 
> >   value that the clocking block sampled at the most
> >   recent clocking event.
> > DOUG: Is this better than "sampling point"?
> > There may be a skew involved, which would mean that
> > the sample doesn't occur precisely at the clocking event.
> 
> Hmmm... the clockvar is updated at the clocking event, with
> a value sampled at some earlier clocking point.  I don't 
> feel too strongly about it, although the imprecision of 
> the existing wording troubled me somewhat, hence my phrase
> "the value that the clocking block sampled".  (No criticism -
> the wording that bothers me long predates your proposals!)

DOUG: That's a good interpretation and explanation.
I'm now fine with your wording if others are.

> 
> 
> >   An optional cycle delay control, of the form ##expression,
> >   may immediately follows the synchronous drive operator <=.
> > DOUG: follows should be follow
> 
> Oops. Thanks.
> 
> 
> >   NOTE: As with any other procedural statement, a clocking
> >   drive statement may have a cycle delay of the form ##N 
> >   as a prefix.  Such a cycle delay, used as a prefix to 
> >   any procedural statement, waits for the specified
> >   number of cycles of the default clocking.
> > DOUG: I'm not very comfortable with this suggestion.
> > The main text treats cycle_delay as if it's only used
> > on the rhs of the <= operator.  Since that use is probably
> > fairly rare, it seems confusing.  I'd rather treat both
> >    ##n cb.v <= e;   -and-   cb.v <= ##n e;
> > as equals when it comes to describing cycle_delay.
> 
> Really?  My reasoning was that ##N as a delay prefix now
> universally adopts the default clocking, and is a prefix
> to ANY procedural statement - so it makes more sense to
> keep it out of this discussion of "intra-drive" ##N,
> which uses the target's clocking.  The note was there
> to answer the question that might pop into a reader's
> head - what happens to ##N as a delay prefix, then? -
> after discussion of <=##N .
> 
> The problem here, I think, is that you've (correctly)
> got rid of the special syntax for
> 
>   ##N cb.tgt <= expression;
> 
> (because the target clocking has no effect on that ##N)
> so we now have no hook for discussing the semantics of
> ##N as a prefix to a procedural statement.
> 
> 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.

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.

> 
> 
> > (3) Last paragraph of 15.4:  Is it true that we want *all*
> > output clockvars initialised to 'bZ?  Surely clockvars that
> > drive a *variable* should be initialised to 'bX?
> > 
> > DOUG: This doesn't matter.
> > One can't read the value of an output clockvar.
> > And an output clockvar won't spontaneously update its associated
> > clocking signal - a drive needs to occur first.  
> 
> That dawned on me about an hour after I sent the previous
> message.  In fact, there is no point whatsoever in 
> initialising an output *clockvar*.  The thing you should 
> initialise to 'bZ is the hidden variable that's created 
> when a clocking output drives a net, because it's that 
> hidden variable whose value is driven out on to the net by 
> continuous assignment until such future time as the relevant 
> clockvar is driven.  This hidden variable is definitely 
> distinct from the clockvar, just as a clocking output
> variable is distinct from its clockvar.  It may be necessary
> to add something to the effect that this is a conceptual
> or reference model, and implementations are free to 
> get the same effect by other means; I've noticed that
> whenever I try to discuss a reference model for the 
> behaviour of clocking, someone always says "ah, but it
> doesn't have to work quite like that"!

DOUG: Totally agreed here.
I'm open to any suggestions for improved wording,
and I do think the wording I chose in 890-5 should
be improved.

> 
> 
> > (1) Suggest replacing the last sentence:
> > 
> >   This is because reading the input always yields the last 
> >   sampled value, and not the driven value.
> > with
> [stuff]
> > DOUG: I prefer the original sentence.
> > I think it says everything that needs to be said, with less words.
> 
> OK, mine was an attempt to make it more precise, but
> I'm happy to accept your judgment on it.
> 
> 
> > Just curious:  Is another batch of suggestions coming on
> > the Program block changes?
> 
> Yes, that was the plan, if you can face the effort of
> reading through it.  Sorry it didn't come all at once,
> but I was interrupted by a grandson crawling over the
> keyboard :-)

DOUG: Thanks for all the help, Jonathan.
I really appreciate it.

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.