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

Jonathan,

We had internal discussions, and in general we are in favor
of your proposal to eliminate the special "drive value resolution"
in favor of more natural Verilog update semantics.

Tools could choose to issue a warning or error when they encounter
the scenarios described in 15.14.2, and consider that a "value add"
feature.

Regards,
Doug 

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Jonathan Bromley
> Sent: Tuesday, January 16, 2007 10:28 AM
> To: sv-ec@server.eda-stds.org
> Subject: [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.
> 
> 
> 

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