[sv-ec] Re: [sv-bc] Clocking blocks: terminology and clarifications

-----Forwarded Message-----
By Jonathan Bromley
Sent: Friday, August 04, 2006 6:59 AM
To: sv-bc@eda-stds.org
Subject: [sv-bc] Clocking blocks: terminology and clarifications

This query springs from training needs, but I suspect it may also be
useful input to the LRM.

(1) Clocking block variables

We lack a well-defined way of talking about the variables (signals,
nets, whatever) in a clocking block.  Given

  wire Wi, Wo;
  logic Li, Lo;
  clocking cb @(posedge Clk);
    input Wi, Li;
    output Wo, Lo;
  endclocking

we have created "objects" cb.Li, cb.Wo etc.  The LRM does not seem to
offer a generic term for these "objects".
In various places in the text the phrase "clocking block variables" is
used to describe this notion, but it is nowhere rigorously defined and
its usage appears to be somewhat arbitrary.  Am I entitled to use the
phrase "clocking block variable", unambiguously and exclusively, to
describe these access points that appear in a clocking?
If so, can I please urge that a definition of that term be added to the
LRM text?  And in any case, may I please invite everyone to think of a
snappier name for it?

(2) Multiple clocking blocks driving an output variable

Suppose that, in addition to "clocking cb" above, I add

  clocking cb_ddr @(negedge Clk);
    output Wo, Lo;
  endclocking

My understanding is that the two clockings will, *on each and every
clocking event*, update the value of Lo with their current
<clocking>.Lo, *even if <clocking>.Lo has not been driven in the current
cycle*.  Furthermore, these updates follow the usual last-write-wins
semantics for variables.
This is extremely useful behaviour for modelling DDR interfaces and
various other things, but I don't see it unambiguously defined in the
LRM.  In particular, 15.14.2 states

  When the same variable is an output from
  multiple clocking blocks, the last drive
  determines the value of the variable.

But "drive" has elsewhere been used to describe the action of depositing
a value on a clocking block variable using the <= operator.  As I
indicate above, this does not appear to be the intended meaning in
15.14.2.  Here's an attempted re-wording:

  When a variable is an output from more than
  one clocking block, each of those clocking blocks
  shall update that variable at the clocking's
  specified output skew time after every occurrence
  of its clocking event.  The most recent such update
  shall determine that variable's value.  [NOTE: This
  most-recent-update behavior is the standard
  behavior of variables, whether updated by
  a clocking block or by any other means.]

(3) Multiple clocking blocks driving an output net

Given the two example clocking blocks above, how is wire Wo driven?  The
very last paragraph of 15.14.2 seems to apply, but is not clearly
worded.  First, the initial "The" of this paragraph should probably be
deleted.  Second, and more important, it's not entirely clear that
*each* participating clocking has its own implicit internal variable and
corresponding driver for the output net.  Even if we assume this
common-sense interpretation, what is the driving strength of that
driver?
Finally, the term "register" in this paragraph is anachronistic and
should probably be replaced by "variable".

Thanks for your attention
--
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

This e-mail and any  attachments are  confidential and Doulos Ltd.
reserves all rights of privilege in  respect thereof. It is intended for
the use of the addressee only. If you are not the intended recipient
please delete it from  your  system, any  use, disclosure, or copying
of this  document is unauthorised. The contents of this message may
contain personal views which are not the views of Doulos Ltd., unless
specifically stated.