[sv-ec] Proposal for change: clocking block drive resolution

I know there has been some discussion of the 
"driving value resolution" behavior of clocking 
blocks, but I don't recall seeing the results 
of such a discussion and I have some fairly 
intractable practical issues with it.  I'd like 
to raise it once again, and I promise that 
if a reasoned argument goes against me (or 
can be shown to have already gone against 
me!) then I'll shut up about it once and for all.

I have a nice PDF of the attached proposal, but 
the email reflector won't accept it so you get 
plain-text; sorry.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Clocking block drive resolution
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Introduction
============
1800-2005 clause 15.14.2 specifies "drive value resolution" 
behavior.  I believe this should be replaced by traditional 
last-write-wins behavior.  There is at least one use case, 
sketched in the code example below, in which last-write-wins 
is more appropriate for a realistic reactive testbench. I submit 
that the last-write-wins behavior that my example relies upon is:
* too useful to give up;
* reasonable;
* familiar to users from other verification coding idioms in 
  Verilog and, in particular, familiar from the behavior of NBAs;
* matches de-facto behavior of existing SystemVerilog tools.

Example
=======
In the following example, a cycle is active or inactive 
depending on a signal ENA that is generated by the testbench.  
ENA can be false (inactive) for an arbitrary number of cycles 
between active cycles.  On a clock event at the end of an active 
cycle, the testbench samples a DUT output and uses it to determine 
whether the next cycle is to be active.

Consider the following very simple BFM task that works through a clocking block:

  task ActiveCycle(input byte WD, output byte RD);
    // Assume we're aligned with the clock at the time of call.
    cb.WrData <= WD;
    cb.ENA <= 1;  // Make this cycle active
    ##1  // Wait for the end of the cycle
    RD = cb.RdData;  // Get the output
    cb.ENA <= 0;  // By default the next cycle is inactive
  endtask : ActiveCycle

Now a testbench can use that cycle BFM as follows:
...
  ActiveCycle(stimulus, response);
  if (response == CONTINUE)
    // Second cycle back-to-back with first:
    ActiveCycle(stim2, response); 
  <wait a long time for other testbench activity to complete>;
  ##1 ActiveCycle(stim3, response);

During "wait a long time", our cycle BFM has held ENA at zero 
because of the assignment at the end of the task.  Our testbench 
was spared the bother of calling a special "idle" task during that 
time.  However, if we got a CONTINUE response then we fell immediately 
into the second call to ActiveCycle, which needs to hold ENA at 1 
for a second cycle.  Obviously we now have a drive conflict on ENA 
at that time, and the code would be broken in tools that implement 
15.14.2 correctly.

Conclusion
==========
None of the major simulation tools yet implements 15.14.2 at all.  
Consequently there would be no backward compatibility consequences 
of removing drive value resolution behavior from the LRM - my BFM 
example works according to its design intent today, but it would be 
broken in any tool that correctly implements 15.14.2.  

The original intent of 15.14.2 could be preserved by allowing tools 
to issue a warning or error message in the event of such a conflict, 
if so configured by a command-line switch or similar means.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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