[sv-ec] 890-5: suggested wording re. output to nets and variables

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(1) Prohibition of continuous assignment to 
    clocking output variables
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is an additional point that I didn't pick
up on my first pass, but it's closely related to the
next point so this seems like a good moment to raise it.

The penultimate paragraph of 890-5's text for clause 15.14
says

  Unlike a regular procedural assignment, the synchronous 
  drive syntax does not allow Verilog intra-assignment 
  delays. Also, it shall be an error to use continuous 
  assignments, force statements, and procedural continuous 
  assignments to write to clocking variables.

The first sentence is fine.  The second sentence is a little
unclear.  Is it prohibiting such assignments to clockvars,
or to clocking output variables?

I'm guessing that its intent is to prohibit any continuous
drive to a variable that is the target of a clocking output,
as we've already discussed.  If the latter is correct, then
I suggest it should be separated from the previous sentence
as it is a somewhat different issue.

However, it probably *is* a good idea to note that the only
permissible way to drive an output clockvar is by using a
synchronous drive statement.  Consequently I'd like to suggest
replacing that paragraph with the following two paragraphs:

  Unlike a regular procedural assignment, the synchronous 
  drive syntax does not allow Verilog intra-assignment 
  delays. Also, it shall be an error to write to a clockvar
  except by using the synchronous drive syntax described in
  this subclause.

  It shall be an error to use any continuous assignment, 
  force statement, or procedural continuous assignment 
  to write to a variable that is an output variable of 
  a clocking block.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(2) Driving value resolution, and clocking outputs
    that drive a net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I think we can roll together several of my suggested
changes in a single group of edits, and improve the 
flow at the same time, by moving some of the text of 
15.14.2 forward into 15.14.  Please feel free to 
re-word for clarity, conciseness etc.

[proposed change]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In 890-5, replace the third paragraph of 15.14:

  Clocking block outputs and inouts drive strong0 
  and strong1 strengths onto clocking signals that 
  are wires.

with the following paragraph:

  For each clocking block output whose target is 
  a net, a driver on that net shall be created.  
  The driver so created shall have (strong1, strong0) 
  drive strength and shall be updated as if by 
  continuous assignment from a variable inside the 
  clocking block.  This implicit variable, which is
  invisible to user code, shall be updated (in the 
  same way as any clocking output variable) in the
  NBA or Re-NBA regions by the action of synchronous
  drive to the corresponding clockvar.  It shall be 
  initialized to 'bZ so that the driver has no 
  influence on its target net until a synchronous 
  drive has been performed to the corresponding clockvar.

Entirely delete the final paragraph of 890-5's additions
to 15.14 by deleting the following text:

  During simulator initialization, clockvars associated 
  with clocking outputs or inouts are initialized to a 
  value of HiZ. Thus, clocking outputs and inouts that 
  are never driven in a simulation have no influence on 
  their associated clocking signal.

In 890-5.pdf, page 5, towards the end of the edits 
for "15.14.2 Drive value resolution", replace the
following paragraph:

  Multiple clocking block outputs driving a net
  [...]
  This semantic model applies to each clocking block 
  output that drives the net.

with this text:

  Multiple clocking block outputs driving a net
  cause the net to be driven to its resolved signal 
  value.  As described in 15.14 above, when a clocking 
  block output corresponds to a net, a driver on that 
  net is created.  This semantic model applies to each 
  clocking block output that drives the net.  The driving
  values of all these driver(s), together with any other 
  drivers on the net, shall be resolved as determined by 
  the net's type.
  
[end of proposed change]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Sorry to keep beating on at this, but I have a vested 
interest in getting it as clear as possible :-)
-- 
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.