16 August Verilog++ Assertion Extension Requirements Proposal

16 August Verilog Assertion Language Goals:  Expressiveness: The assertion extension should be expressive enough to cover most implementation properties likely to be used by the design engineer.  Usability: The assertion extension must be easy to understand and use by the design engineer.  Formalism: The assertion language must have rigorous formal semantics to ensure correct compilation.

16 August HDL Assertion Language Extension Justification:  HVLs and Property Languages could do it all, however…  A variety of stakeholders necessitate a variety of approaches to specify design properties.  Verification engineers prefer working with HVLs or property languages, yet design engineers prefer working with HDLs.  Verification engineers lack sufficient implementation knowledge to achieve a good / high white-box coverage.  At the same time, design engineer should capture low-level assumptions and and implementation propositions.

16 August Lessons from VHDL: [label] assert event [report message] [severity level] VHDL procedural assertion to trap illegal invariant behavior. Trapping illegal temporal behavior requires creating state machines combined with the assert statement.

16 August Assertion Language Requirements  Assertion Identifier – the extension should enable the user to associating a unique identifier (name) with each assertion.  Assertion Reset – the extension should provide a mechanism for disabling the assertion. (E.g., designating a Verilog expression, when TRUE disables the assertion)  Assertion Sampling Clock – the extension should provide a mechanism for defining an optional sampling clock, whose raising/falling edge defines the correct assertion evaluation time.

16 August Assertion Language Requirements  Assertion Expression – the extension should support the entire synthesizable subset of Verilog++ for the assertion expressions (if not, we should explicitly identify what is not supported).  Assertion Severity Level – the extension should provide a mechanism for defining the assertion violation severity level.  Assertion Violation Action – the extension should enable the user to define an optional action associated with an assertion violation in simulation. (e.g., possibly make a PLI call, call $finish, etc.)

16 August Assertion Language Requirements  Concurrent and Procedural Assertions – the extension should support both concurrent and procedural assertions. Possibly a sampling clock could be associated with a procedural assertion, and a callback would occur on the sampling clock if the assertion initially evaluated TRUE. This would prevent FALSE firings due to simulation transient micro-time event ordering.  Assertion Event Rise or Fall Detection – the extension should provide a mechanism for specifying (detecting) rising or falling events (e.g., the assertion expression). [I’m not passionate with this requirement.]

16 August Assertion Language Requirements  Setting A Variable Upon Assertion Violation – the extension should provide a convenient mechanism for setting a Verilog variable upon assertion violation. [I’m not passionate with this requirement.]  Assertion Options – the extension should provide a mechanism for enabling tool specific options, such as defining an assertion as a constraint to formal tools. Possibly the new Verilog attribute construct could be used for this feature.

16 August Assertion Language Requirements  Assertion RISC Approach – At a minimum, the Assertion Committee should consider two simple construct extensions to the Verilog language. These extensions would consist of (a) a procedural assertion statement, and (b) a simple concurrent assertion statement. With these simple statements more complicated assertion could be constructed—providing expandability as well as assertion tool unification.  Assertion CISC Approach – To simplify the designer’s effort in assertion specification, the committee might consider creating a larger set of assertion types based off real user experiences (e.g., HP, Cisco, Verplex customers, 0-In customers, RealIntent, etc.). Again, the focus is at the HDL implementation level, not a higher levels of assertion specification.

16 August Proceeding Forward  The committee needs to come up with a final set of assertion language extension requirements. My proposal was created to focus the committee’s discussion on requirements  After completing the requirements, the committee should start studying assertion language implementation options (syntax/semantic).