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

Hello All,

Jonathan Bromley brought up some interesting questions in his
posting on August 4th. (http://www.eda-stds.org/sv-ec/hm/3472.html)

There haven't been any responses to his questions, but it's
time to consider these issues as part of the Mantis 890
discussion.

Please see below for my initial thoughts.

> -----Original Message-----
> From: owner-sv-bc@server.eda-stds.org 
> [mailto:owner-sv-bc@server.eda-stds.org] On Behalf Of Jonathan Bromley
> Sent: Friday, August 04, 2006 6:59 AM
> To: sv-bc@server.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?

DOUG: I looked through Section 15 to see the frequency
of the various terms used to describe these objects.
"clocking signal" is used much more often than "clocking
variable".  So it seems it would be easier to stick with
"clocking signal".

In addition, these objects have somewhat unusual semantic
characteristics and restrictions.  Using a standard SV
term like "variable" or "net" could mislead people into
thinking these objects are plain variables or nets that
live in the clocking scope.  Using the unusual term (for SV)
"signal" connotes that some unusual semantics are going
on here.

I'm fine either way.  The above are the salient points
I can think of right now.  My initial vote is "signal".

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

DOUG: Jonathan's item (2) is directly related to Cliff's
questions about the nature of clocking signals.  Are they
their own object, with unique value storage?  Or are they
just syntactic sugar that refer to their related variable
or net object, and connote interesting timing characteristics
when accessing that related object?

Consider this simple program fragment:

  program(output logic d);

  clocking cb begin
    output #2ns d;
  endclocking
  ...

There are several possibilities on how to consider d and cb.d:
1. cb.d is a syntactic-sugar form of referring to d.
   When driving cb.d with <=, it is like directly writing
   to d with special delay semantics.  There is only one
   variable stored.
2. cb.d and d are independently stored variables.
   There is an update semantic like:
    always @(cb) d <= #2 cb.d;
3. cb.d and d are independently stored variables.
   There is a semantic like:
    always @(cb) if (someone_did_a_sync_drive_to_d) d <= #2 cb.d;

Jonathan's desire here seems to be for something like 2.
Cliff's reading seems to be either 1 or 3.
I think there is some evidence for 3, in particular
the second sentence of this paragraph from 15.14.2:

   The variable j is an output to two clocking blocks using
   different clocking events (posedge versus negedge). When driven,
   the variable j shall take on the value most recently assigned
   by either clocking block.



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

DOUG: Tried to take care of these suggestions in the
latest 890 proposal, SV-890-2.htm.

Thanks and regards,
Doug

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