Verilog++ Assertion Extension Requirements Proposal

1. Verilog++ Assertion Extension Requirements Proposal harry_foster@hp.com

2. 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. harry_foster@hp.com

3. 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. harry_foster@hp.com

4. Lessons from VHDL: [label] assert event [report message] [severitylevel] VHDL procedural assertion to trap illegal invariant behavior. Trapping illegal temporal behavior requires creating state machines combined with the assert statement. harry_foster@hp.com

5. 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. harry_foster@hp.com

6. 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.) harry_foster@hp.com

7. 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.] harry_foster@hp.com

8. 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 attributeconstruct could be used for this feature. harry_foster@hp.com

9. 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. harry_foster@hp.com

10. 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). harry_foster@hp.com