I don’t want to write assertion in my RTL design…i can ask verification engineer to write assertion binding the TB-RTL interface…right?
ABSOLUTELY!!! In fact, it is recommended that assertions be in a module or in checkers and be bound to the DUT. This is a preferred approach for the following reasons:
- It physically separates the verification environment from the DUT. Thus, adding or making changes to the assertion module bound to the DUT is a transparent thing.
- When synthesizing the RTL, some compiler time-stamp the compilation. Any change to the RTL, even to just tune or add assertions, would change the time-stamp, and thus redo the synthesis.
- Adding or changing assertions within the RTL model may accidentally cause changes to the RTL (like adding a character, changing names, or even deleting code, thus causing unnecessary headaches and aggravation.
- Often, it is necessary when writing assertions to add supporting code that is not intended for synthesis. There is a danger that this supporting code will be accepted by the synthesis tool as real RTL code, and that may impact on the performance or the design.
Question though: Why are you limiting the writing of the assertions to just the verification engineer? The verification engineer should write assertions in a separate module (or checker) to address the design requirements from the specificationa point of view. The RTL designer should write the assertions in a separate module from the design point of view. That would address things like the internal FSMs and their inter-relationships and relationships to outputs, assumptions about inputs or states or max sizes (e.g., FIFO depths, address range, etc.
Ben Cohen http://www.systemverilog.us/
- SystemVerilog Assertions Handbook, 3rd Edition, 2013
- A Pragmatic Approach to VMM Adoption
- Using PSL/SUGAR … 2nd Edition
- Real Chip Design and Verification
- Cmpt Design by Example
- VHDL books