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

From: Warmke, Doug <doug_warmke_at_.....>
Date: Sun Feb 11 2007 - 21:47:10 PST
Jonathan,

Thanks for the detailed review.
I like almost all your suggestions.
Please see below for my responses.

Regards,
Doug


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
General notes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(1) Throughout the text, ensure correct spelling of the
scheduling region name Observed (some instances lack
the final 'd').
DOUG: OK

(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.  The value should probably be interpreted
as unsigned, but this is likely to yield unexpected behavior
because small negative integers cast to unsigned will have
the effect of very large positive integers.  Is it a good 
idea to encourage implementations to issue a warning in 
this case?
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.



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Detailed comments on the text
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

15.2 Clocking block declaration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
First para in 890-5 text: 
=========================

(1) Suggestion: change

  The signal_identfier identifies a signal in the scope 
  enclosing the clocking block declaration and declares 
  the name of a signal in the clocking block. Unless a 
  hierarchical_expression is used, both the signal and 
  the clocking_item names shall be the same.
  
to:

  The signal_identifier identifies a signal (a net or 
  variable) in the scope enclosing the clocking block 
  declaration, and declares a _clockvar_ in the clocking 
  block. Unless a hierarchical_expression is used, both 
  the signal and the clockvar names shall be the same.
  
[Motivation: Introduce the term clockvar so it can be used
elsewhere with confidence; remove ambiguity associated with
the word "signal".]
DOUG: OK

(2) The last sentence of the first paragraph is potentially 
ambiguous thanks to the use of "includes".  In fact, the
*exclusion* of the previous sentence *includes* class
properties etc!  Suggested re-wording of final sentence:

  Likewise, it shall be illegal for a clocking 
  signal_identifier to specify either a class property
  or a dynamically-sized variable.
DOUG: OK

  
Second para in 890-5 text:
==========================

Some of the text in this paragraph is explanatory rather
than normative, and is intentionally incomplete.  It may 
be preferable to make some of the paragraph a Note, so 
that statements such as 

  input or inout signals specified in the clocking block 
  are sampled when the corresponding clock event occurs
  
do not conflict with later, more detailed normative text.
Specifically, replace the paragraph with the following  
two paragraphs (I've also suggested some tiny rewordings):

  The clocking_event designates a particular event to act 
  as the clock for the clocking block. The timing used to
  drive and sample all other signals specified in a given 
  clocking block is governed by its clocking event.  See 
  15.12 and 15.14 for details on the precise timing 
  semantics of sampling and driving clocking signals. 
  Bidirectional signals (inout) are sampled as well as 
  driven. An output signal cannot be read, and an input 
  signal cannot be driven.
  
  NOTE: All input or inout signals specified in the 
  clocking block are sampled when the corresponding clock 
  event occurs. Likewise, all output or inout signals in 
  the clocking block are driven when the corresponding 
  clock event occurs.
DOUG: OK
  

15.12 Input sampling
~~~~~~~~~~~~~~~~~~~~

(1) Penultimate para in 890-5 text would be clearer if it
referred to the clockvar; reference to "the signal"
is highly ambiguous.  Suggested rewording: change

  When a signal appears in an expression, it is replaced 
  by the signal's sampled value, that is, the value that 
  was sampled at the last sampling point.

to

  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.


15.14 Synchronous drives
~~~~~~~~~~~~~~~~~~~~~~~~

(1) First para at the head of page 4 of 890-5:  "The event_count"
has no antecedent in the text, and the syntax of "event_count" is
rather deeply buried in the production rules for "cycle_delay". 
Furthermore, part of the text of this paragraph appears to refer 
to the struck-out syntax
  [cycle_delay] clockvar_expression <= expression
at the foot of the previous page.

Suggested re-wording of the first two paragraphs of
this page: replace

  The event_count refers to the expression after the ## in 
  the cycle_delay production and is an integral expression 
  that optionally specifies the number of default clocking 
  events (i.e., cycles) that must pass before the statement 
  executes. Specifying a nonzero event_count blocks the current 
  process until the specified number of clocking events has 
  elapsed; otherwise, the statement executes at the current 
  time. The event_count uses syntax similar to the cycle 
  delay operator (see 15.10); however, the synchronous drive 
  uses the clocking block of the signal being driven and not 
  the default clocking.
  
  The second form of the synchronous drive uses the intra-
  assignment syntax. An intra-assignment event_count 
  specification also delays execution of the assignment. 
  In this case, the process does not block, and the right-hand 
  expression is evaluated when the statement executes.
  
with

  An optional cycle delay control, of the form ##expression,
  may immediately follows the synchronous drive operator <=.
DOUG: follows should be follow
  The expression in this cycle delay control shall be a 
  positive integral expression.  The syntax is similar to the 
  syntax of nonblocking intra-assignment delay, If this optional 
  cycle_delay is used, the clocking drive shall evaluate its 
  right-hand-side expression immediately and shall schedule 
  the clocking drive to occur in the future timeslot specified 
  by the cycle delay (that is, for a cycle delay ##N, in the 
  timeslot in which the Nth subsequent clocking event occurs).
  In this construct, the clocking event is that of the clocking
  block of the signal being driven and not the default clocking.
  
  Whether or not a cycle delay control is used, a clocking
  drive statement shall never block the flow of execution.
  
  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.
(Even though your NOTE: is technically correct)
  

(2) Towards the end of 15.14, three paragraphs before 15.14.1:
Discussion of asynchronous execution of clocking drives could
be misinterpreted as suggesting that the drive blocks until
the clocking event.  Suggested re-wording: replace

  It is possible for a drive statement to execute at a time 
  that is not coincident with its clocking event. Such drive 
  statements shall be processed as if they had executed at the 
  time of the next clocking event. The values on the right hand 
  side of the drive statement shall be read immediately, but 
  the processing of the drive is delayed until the time of 
  the next clocking event

with

  It is possible for a drive statement to execute at a time 
  that is not coincident with its clocking event. Such drive 
  statements shall execute without blocking, but shall perform 
  their drive action as if they had executed at the 
  time of the next clocking event. The values on the right hand 
  side of the drive statement shall be read immediately, but 
  the processing of the drive is delayed until the time of 
  the next clocking event
DOUG: OK

(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.  The default value
of the associated clocking signal will be something appropriate
to its type, and that will be the initialized value of that signal.

Maybe someone can come up with some better wording, to the effect of
"Output clockvars that never updated via a synchronous drive
have no effect on their associated clocking signal"


15.14.1 Drives and nonblocking assignments
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(1) Suggest replacing the last sentence:

  This is because reading the input always yields the last 
  sampled value, and not the driven value.

with

  This is because an inout clockvar is in fact an input
  clockvar and a distinct output clockvar of the same name.
  Reading an inout clockvar in effect reads the input 
  clockvar of the same name, yielding its most recently 
  sampled value.  A clocking drive to an inout clockvar 
  in effect drives the output clockvar of the same name
  the output clockvar of the same name, so the input 
  clockvar is not immediately updated with the driven value.

DOUG: I prefer the original sentence.
I think it says everything that needs to be said, with less words.


15.14.2 Drive value resolution
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(1) After the second code example, paragraph beginning 
"Multiple clocking block outputs driving a net" - is it
useful or necessary to add "e.g. through different ports"?
DOUG: This could be removed without harm.


(2) Same paragraph as (1) above: suggest replacing

  a variable inside the clocking block that is updated as
  a nonblocking assignment
  
with

  a variable inside the clocking block that is updated in 
  the NBA or Re-NBA region with clocking output behavior, 
  as described in 15.14 above
DOUG: OK


Thanks very much, Jonathan.
Those suggestions will help improve things.

Just curious:  Is another batch of suggestions coming on
the Program block changes?

Regards,
Doug
  

> -----Original Message-----
> From: Jonathan Bromley [mailto:jonathan.bromley@doulos.com] 
> Sent: Saturday, February 10, 2007 8:31 AM
> To: sv-ec@server.eda-stds.org; Warmke, Doug
> Subject: Comments on 890-5.pdf
> 
> I've started to review Doug's latest and very thorough 
> proposal for clocking blocks and programs (Mantis 890,
> document 890-5.pdf).  Herewith my comments on the proposals
> relating to clause 15, clocking blocks; I'll try to do the
> same for the clause 16, programs, proposal in the next 
> day or two.  Many of the points are fairly trivial 
> nit-picking or suggestions for clearer wording, but there
> are a couple of areas that seem to me to need a little
> technical clarification.
> 
> Seems to me that considerable thanks are due to Doug
> for his major effort on this.
> -- 
> 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.
Received on Sun Feb 11 21:47:44 2007

This archive was generated by hypermail 2.1.8 : Sun Feb 11 2007 - 21:48:18 PST