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?!

> 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!)


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


> (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"!


> (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 :-)
-- 
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.