RE: [sv-ec] Apologies, 890 still not ready

From: Jonathan Bromley <jonathan.bromley_at_.....>
Date: Mon Jan 22 2007 - 11:12:23 PST
Doug,

I can't attend SV-EC today, but some comments on your 
interesting points:

> 1. Cliff has shown that we need to allow procedural
>    assignments to variables that are also driven by
>    clocking outputs.  This is useful for initialization.
>    This will require exempting clocking blocks from the
>    strictures about multiple writers to variables from
>    different processes (something I will put in 890).

Forgive my ignorance, but *what* strictures?  If we think
of a clocking output as making NBAs to its target variable
(see below for the difference if the clocking output's
target is a net) then the only problem would arise if
someone tried to do a *continuous assign* to the same
variable "round the back" of the clocking, and I think
it would be reasonable to disallow that conflict.

>    A question now arises about continuous assignments
>    to variables that are also driven by clocking outputs.
>    What should we do with those?

I'd go for outlawing it.  That would be consistent with
the conceptual model in which a variable that is a clocking
output suffers NBAs from the clocking (admittedly NBAs
that got there in a slightly odd way, but NBAs nonetheless).
You can't make NBAs to a variable that is also driven
by a continuous assignment.

On the other hand, non-clocking continuous assigns to a 
*net* that is also a clocking output should be OK, if 
you  accept the model I proposed a while ago in which 
the clocking writes to a hidden internal variable by NBA 
and then that variable is driven out on to the target
net by an implicit continuous assign within the clocking.
The only missing detail would be the need to specify
the drive strength of that implicit continuous assign.
I suggest it should be (strong0, strong1), but you
might consider making it configurable thus:

  wire W;
  clocking cb @(...);
    output (strong0, weak1) #2 W;
  endclocking

A while ago I put together a few pictures relating to
this.  I haven't heard any specific objections to their
content, and they might be useful as a focus for some 
discussion, so I attach them again here.  They talk 
about the resolution behaviour I'd like to abolish,
but that's another question :-)

> 4. Generalizing on 3, what does it even mean to have
>    clocking variables that are of dynamic types?
>    The LRM only discusses and shows integral values.
>    Should we introduce a rule that limits clocking
>    variables to be of integral types?

If you don't have clocking drive resolution then it's
reasonably easy:  If you could legally do an NBA to it, 
then it's OK for a clocking to drive it.
-- 
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 Mon Jan 22 11:13:46 2007

This archive was generated by hypermail 2.1.8 : Mon Jan 22 2007 - 11:14:01 PST