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

My understanding has always been that for # unit delays, a negative delay
value is treated as an unsigned value.  I also thought that was in the 1364
LRM, somewhere.

I ran the following case on two simulators:

module test;
  parameter delay = -5;

  initial begin
    #delay $display("Current time is %0d", $time);
    #1 $finish;
  end
endmodule

Surprise, surprise.  One simulator treated the negative delay as a large
positive value.  No errors or warnings were generated.   The other simulator
treated the negative number as 0, again with no errors or warnings.

I agree that the LRM should standardize at least what ## does with a
negative value.  I also like option (c), treat as unsigned but issue a
warning.  Question: Should this only be a run-time warning, or should the
warning could be issued at the earliest point it can be detected, which
might be compile, elaboration or run-time, depending on context?

Regarding # negative unit delays, I would prefer the standard define the
same behavior as ##, but anything we define could have far reaching backward
compatibility issues, since at least two products took a radically different
approach to the corner case.

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
Sutherland HDL, Inc.
stuart@sutherland-hdl.com
503-692-0898
 

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Warmke, Doug
> Sent: Monday, February 12, 2007 10:14 AM
> To: sv-ec@server.eda.org
> Subject: 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.
> 
> 
> 
> 



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.