1 / 10

Verilog++ Assertion Extension Requirements Proposal

Verilog++ Assertion Extension Requirements Proposal. 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.

kaveri
Download Presentation

Verilog++ Assertion Extension Requirements Proposal

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related