RE: [sv-ac] 16.4 questions

hi,

[Shalom]

  1. The first reference to a clocking block variable 
  is to an input variable. Should that include inouts? 

  2. The following references to clocking block variables 
  do not specify 'input'. Is that to be understood? 

  3. The last sentence references Clause 4. I don't 
  understand what is intended. Clause 4 does not mention 
  assertions or clocking blocks.

  4. The term "simulation tick" is used in the LRM only 
  with respect to Figure 16-1 and 16-3 and is thus undefined. 
  It would be better to use a term consistent with the rest 
  to the LRM. I think "time step" is the LRM term for "tick".


Mantis 2021 clarifies that a clocking inout is merely
shorthand for a clocking input and a clocking output
that reference the same signal; its input and output
clockvars are distinct.  There is no such thing as
an inout clockvar.  So I suggest that "input or inout"
is strictly superfluous, but would be a useful 
clarification.

I have never understood this text...

  Para. 2 says, 

  The assertion using the clocking block variable 
  shall not do its own sampling on the variable,
  but rather use the sampled value produced by the 
  clocking block.

because "input #1step" sampling of a clocking input
has exactly the same semantics as Preponed sampling,
as used natively by assertions.  It seems to me that
the restriction to only #1step sampling is sufficient
to make the property work identically through the
clocking block as it would if the clocking were not
present.

Clause 16.17 still leaves lots of room for doubt about
the relationship between clocking blocks and properties.
The key problem is whether a property inside a clocking
respects the scope of the clocking.  Consider...

  interface ITF (input bit clk);

    logic a, b;

    default clocking cb @(posedge clk);
      input a; output b;
      property p1;  a |=> b; endproperty
    endclocking

    property p2; a |=> b; endproperty

    assert property (cb.p1);
    assert property (p2);

    modport mp (clocking cb);

  endinterface

In property p1, are the references to a and b in fact
references to cb.a and cb.b?  Evidently not, because
cb.b is not readable.  So they're referencing ITF::a 
and ITF::b.  In that case, why bother to mention the
clocking at all when discussing the sampling of a?
What about property p2?  Why is it necessary or helpful
to insist that its "a" is sampled by cb?  It seems to
me that putting a property into a clocking block is
useful only to provide it with an inferred clock (the
clocking block's clock event) and to hide it inside
the clocking block's scope; the latter might be useful
because clockings can be exposed through modports,
but properties cannot.


Thanks
-- 
Jonathan Bromley


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.