RE: [sv-ec] Program Block / Reactive Region Use Cases & Requirements

Quick Response to Rob Slater's follow-up -

At 06:20 AM 12/7/2006, Slater Rob-R53680 wrote:
>Hi Cliff,
>
>I'm not sure I understand the Use Cases.  In the past, it was necessary
>to write test benches in PLIs because the Verilog language wasn't rich
>enough to support proper verification needs.

Aside from enhanced file-IO (which we added to Verilog-2001) I'm not 
sure I totally agree.

Certainly people did very creative and elaborate testbenches employing PLI.

Many engineers, myself included, did very creative and elaborate 
testbenches using plain old Verilog (and Verilog-2001 file-IO) using 
simple Verilog just so we did not have to mess with the PLI.

>The PLI had its own scheduling region, so the use of PLIs required
>mastery of alternative scheduling techniques and the mastery of new
>types of races; races difficult to detect and fix in practice because
>they weren't centered in one language.
>
>Vera (a model for SV program blocks) as well as e, and other languages
>operate in a separate scheduling domain because when used as PLIs, they
>have to.
>
>But now with (System)Verilog rich enough for test bench needs, I don't
>see the need for the separate regions for Verilog code.  The separate
>domain was a necessary evil for verification, not a requirement.

This is the same argument I made off line with Arturo and Mehdi a few 
years ago. I showed Arturo and Mehdi the slides that I showed at the 
Nov 6 face-to-face meeting, and told them that I had a working 
methodology to address timing and races between RTL and testbenches. 
Arturo and Mehdi agreed that I had a fine working approach to 
testbenches but that adding the new event regions and capabilities 
would make it easier for those unfamiliar with my methodology to get 
a robust working testbench.

That is what finally sold me on the new regions. I had a working 
methodology but the new event regions facilitated the creation of 
simpler methodologies.

To this day, I still find experienced verification engineers that try 
to apply stimulus to their DUTs on the active clock edge using 
blocking assignments, and it is a rather common practice to apply 
stimulus on the active clock edge using nonblocking assignments, 
although the testbench will not work if a gate-level model with 
back-annotated delays is used with the testbench.

>Verilog code operating in an active/inactive region is not new.
>Designers have had over a decade to get used to it and today tools even
>exist to help find race conditions when designers forget.

You are absolutely right. Engineers with a decade of experience and 
familiarity with existing race conditions (people like you and me) 
have developed fine methodologies to avoid the problems. Engineers 
who are new to Verilog/SystemVerilog can execute their testbench code 
out of a program, which will cause stimulus events to be scheduled 
into one of the reactive regions and they will more easily avoid the problems.

The new use model is also designed to get engineers away from the 
cumbersome PLI coding.

>Rob Slater
>Freescale Semiconductor

Again, if your team has run into specific problems with your existing 
use-models, that information would be very valuable to the committee.

Regards - Cliff


>-----Original Message-----
>From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
>Clifford E. Cummings
>Sent: Wednesday, December 06, 2006 10:04 PM
>To: sv-ec@eda.org
>Subject: Re: [sv-ec] Program Block / Reactive Region Use Cases &
>Requirements
>
>Hi, Rob -
>
>I will take the first stab at discussing use cases and requirements
>and allow others to add their perspective.
>
>First let me offer an editorial comment on programs and clocking
>blocks and programs. Due to the ambiguous descriptions in sections 15
>(clocking blocks) and 16 (programs) in the LRM, I believe you will
>find significant differences in current implementations of programs
>and clocking blocks. This is why we are having this rather urgent
>discussion to fix the ambiguities and to determine the perceived use
>models for programs and clocking blocks. I am not surprised that you
>having "challenges." You are not alone and I would be happy to
>compare usage notes with you off-line.
>
>Use Models:
>Largely based on Vera and the Vera interface (clocking block
>equivalent). Event scheduling is based on user experiences with Vera.
>
>Program - execute testbench code in different event regions than RTL
>designs with the intent to eliminate DUT-testbench race conditions
>(this was the goal and I think we are close). Major implementers
>noted some of the troubles they had experienced integrating
>third-party HVLs (such as Vera and 'e') with Verilog simulations
>through the PLI.
>
>PLI - make the need to use PLI in a testbench obsolete or near-obsolete.
>
>Interaction with other languages was not well considered. Steve Sharp
>is off exploring those issues as related to event scheduling.
>
>Did you see my PDF slides showing Verilog-2001 testbench strategies
>versus SystemVerilog strategies? The slides were used in our
>face-to-face meeting on November 6th.
>
>Editorial Comment: I believe many of the examples in the clocking and
>program sections are much too terse to be instructive and I have
>requested permission to add more detailed examples to show correct
>usage and how interaction really takes place.
>
>What we are seeking from you are your use examples and why they are
>causing you grief. If you mention that the implementations do not
>track, that is already known and will not be very useful. If you tell
>us how you tried to use the constructs and what you expected when you
>executed your examples, that will be immensely valuable, as it will
>show the ideas and misconceptions surrounding these new features and
>will give us a clue on how to improve the features or their
>descriptions.
>
>Regards - Cliff
>
>At 05:14 AM 12/6/2006, Slater Rob-R53680 wrote:
> >Hi,
> >
> >Sorry for the step backwards, but in light of the challenges program
> >blocks are presenting us, I went looking for the Use Cases &
> >Requirements that drove this particular design decision.
> >
> >Could someone point me to where they are documented?
> >
> >Thanks,
> >
> >Rob Slater
> >Freescale Semiconductor
>
>----------------------------------------------------
>Cliff Cummings - Sunburst Design, Inc.
>14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
>Phone: 503-641-8446 / FAX: 503-641-8486
>cliffc@sunburst-design.com / www.sunburst-design.com
>Expert Verilog, SystemVerilog, Synthesis and Verification Training

----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training