Subject: Assertions - Re: Minutes Verilog++ 7th committee meeting
From: Steve Grout (grouts@flash.net)
Date: Tue Sep 11 2001 - 19:38:20 PDT
Re the mention in the minutes of needing comments
regarding assertions, I would like to share
the following comments:
> ...
> Assertion Requirements
> Looking for feedback from this group.
> ...
The present Assertions document, and indeed this
whole Accellera initiative on assertions is quite good, very important, and very
timely as we face having to describe and verify larger and larger, more complex,
multi-domain systems.
- I personally am a very big fan of explicitly
including constraints and assertions directly
within the HDL (or at worst, in a closely associated
testbench), rather than infer them from the testbench,
or the customer spec/requirements that drove them.
- Its really a very practical matter to explicitly
state the customer's or the designer's
design intent. I know that in delivered aerospace
and defense product design, such inclusion
VERY GREATLY improves the usability, maintainability,
and operational readiness of critical chips and
systems.
But those are comments we all agree on, right?
The present document seems to include all or at least most
of the more useful assertion mechanisms one might use in
describing both hardware, function about hardware, and
function about electronics product behavior.
The current set, though, are, in my personal parlance,
'mechanisms' one uses to state general propositions
about concurrency (temporal) and process when describing
basic hardware using an HDL like Verilog.
If we move from mainly focusing on RTL flow, and
cover wider applications of Verilog to hardware
and systems, I would suggest we also consider
including some of the assertions classes
the SLDL subcommittee on constraints
and assertions I lead (with able participation
of Ron Waxman and Jean Mermet) identified, including
notions such as product hierarchy,
configurations, design management, test, environment,
power, cost, decision, signals, conditions,
reliability, bound, association, etc.
Also, the current set are very crisp and quite useful.
(I had downloaded the current set from website
and was using them for full-chip SERDES A/MS chip verification while I was with
Tality A/MS Design Services.)
However, I would wonder if these assertions would
be more useful if we could define a
refinement mechanism for them, so one wouldn't
have to 'stamp and repeat' them in full each time
one needed another slightly-different instantiation
of them in their HDL description.
Needless to say, I fully support the current set
of proposed assertions and the current document.
Regards,
--Steve Grout
-- --Steve Grout Design Verification, CAD Methodology/R&D, Manager, Individual Contributor - Design Verification, CAD System, Database, Flows, Tools, Integration, and Support for both Digital and Analog/Mixed-Signal Design Teams. 101 Kenneil Court Apex, NC 27502 Phone: 919-303-5066 email: grouts@flash.net http://www.flash.net/~sgrout/Personal/resume2001.txt (or doc,rtf,pdf)
This archive was generated by hypermail 2b28 : Wed Sep 12 2001 - 21:17:19 PDT