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

Please see below for a couple brief comments.
Others - Feel free to jump in, so that our discussion
at the next meeting will be more streamlined.

> -----Original Message-----
> From: Jonathan Bromley [mailto:jonathan.bromley@doulos.com] 
> Sent: Tuesday, February 13, 2007 3:58 AM
> To: Warmke, Doug; sv-ec@server.eda.org
> Subject: 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.

DOUG: This Clause of the LRM uses the term "clocking signal"
extensively.  The term means "the variable or net associated
with the clockvar".  We can make that clearer in the beginning
of the section, I guess.

I can see you have avoided using the term "clocking signal"
in all your suggestions.  I think that term is fine, and brief
than the round-about "the net or variable associated with the
clocking output" (or similar).

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

DOUG: OK

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


"...to a variable that is a clocking output signal."
-or-
"...to a variable associated with a clocking output."


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

DOUG: This is wordy, but if it's fine with others,
I can accept it.

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

DOUG: Wordy, but acceptable if everyone agrees.

Thanks and regards,
Doug

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