Subject: [sv-ec] Clock Blocks - what does ModelTech Want & Why?
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Wed Jan 29 2003 - 12:33:34 PST
Hi, All -
I know clocking domains is a topic of current debate. At the last
face-to-face meeting I asked Dennis Brophy what ModelSim thought of
clocking domains and he mentioned that verification tool vendors had been
asking for specifically scheduled and standardized hooks into the Verilog
event queue to facilitate tool interoperability for testing. That is one of
the most persuasive arguments in favor of clock domains that I have heard
so far, but it is still somewhat anecdotal.
Can Dennis or the ModelTech team give examples of what verification tools
want to do and why they need hooks into the existing Verilog event queue?
Again, this could be very persuasive.
Jay Lawrence mentioned in the last meeting that a prepone process or any
other modification to the event queue is not necessary, and I believe he is
technically correct.
· A very good testbench methodology requires testing of desired
signals just before the next rising clock (this has been required by ASIC
vendors since the 1980's).
· Testing late in the cycle insures that the output for a 0-delay RTL
model has been valid for almost a full cycle, while the output for an
equivalent gate-level model with delays should be stable by the next cycle
(the key - the same testbench can be used for both types of testing).
· In good RTL models:
· the clock transitions.
· then we wait for sequential logic nonblocking assignments to update.
· the updated nonblocking assignments trigger the combinational logic
with blocking assignments.
· If assertions are done in the active events queue (before
nonblocking assignments update), this is virtually the same as testing all
values (except the clock) just before the rising clock edge.
· In general, testing or checking assertions at the end of the
simulation time where a clock has transitioned is a bad idea because the
same testbench cannot be used for a gate-level model with delays.
· An ideal test methodology with good RTL coding does:
(1) clock transitions
(2) assertions and verification is checked
(3) sequential logic updates
(4) combinational logic updates
(5) ?? do not do testing at the end of this time step - wait until the
next clock (the next output-stable point)??
This having been said, Arturo has given me one or two semi-good reasons why
the new clocking blocks would be useful to some customers.
1st example: A company that generates multiple clocks with nonblocking
assignments and if two clocks generated this way transition high at the
same time, the first clock could trigger and update sequential logic coded
with nonblocking assignments, which would be a race condition with the
transition of the second clock. The verification phase would get you past
this race condition. NOTE: the real solution is to teach the customer that
generating clocks using nonblocking assignments is a really bad idea,
subject to other race conditions in the simulated design. Unfortunately,
some customers might insist on keeping their clocks as is and blame the
verification tool if the desired results are not achieved.
The question is, are we facilitating bad coding styles by fixing this
problem for the stupid and stubborn customers? I understand the vendors
desire to satisfy even the semi-stupid customers so this is a reasonable
argument in favor of the later verification phase.
2nd example: A customer that codes registers and flip-flops with blocking
assignments. Now when a clock transitions, there is no way to guarantee
that the assertion is looking at the desired signals either before or after
clocked transitions. NOTE: This is a race condition due to a very poor
coding style (should use nonblocking assignments for sequential logic and
this is fixed).
Again are we facilitating bad coding styles for stupid customers? Probably,
but most of the Verilog books on the market still show blocking assignments
for registered logic (can we sue some of these authors for mal practice? Is
that part of the Accellera charter?? ;-)
Stefen Boyd raises another valid point. These clocking and program blocks
seem to introduce unwanted verbosity. I certainly support any initiative to
reduce verbosity in code.
As I consider whether or not to favor a clocking block in SystemVerilog
3.1, these are some of the issues that I have considered. Good examples
from ModelTech showing why the extra hooks are needed by verification tool
vendors would be persuasive.
----------------------------------------------------
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, Synthesis and Verification Training
This archive was generated by hypermail 2b28 : Wed Jan 29 2003 - 12:32:52 PST