I dont want to write assertion in my RTL design…i can ask verification engineer to write assertion binding the TB-RTL interface…right?
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
In reply to ben@SystemVerilog.us:
While I do agree with your points, I think that having to keep things separate like this is one of the reasons why some designers don’'t write assertions for their blocks. This was one of the reasons I quite like the concept of PSL (being able to embed assertions in comments in both languages - VHDL and Verilog).
In reply to Tudor Timi:
Embedding assertions in comments still has the same issues I mentioned above, namely potential for errors, time stamping and unnecessary re-synthesis, and supporting assertion code not intended for synthesis.
It is the responsibility of management (or project engineer) to enforce the methodologies used in the project.
Just because an engineer does not “like” the binding concept is not a reason for not using assertions.
The benefits of assertions were proven because they not only clarify the requirements and assumptions, they also pinpoint the errors quickly.
SVA and PSL are just an assertion language used for verification. One can also write assertions in plain RTL-like code, since an assertion is simply a statement that some property of the design is true.
As far as PSL or SVA, SVA is far superior. Engineers who use VHDL must (or most likely) know SystemVerilog.
Personally, I would abandon VHDL and use SystemVerilog for RTL and verification.
Ben http://SystemVerilog.us
In reply to ben@SystemVerilog.us:
@Tudor
Embedding SVA via comments is/was supported in atleast one EDA tool, check with your vendor if interested. Also why not use `ifdef SVA if you insist you want to use it as “embedded” style? That would keep it portable across tools…
I would still prefer going with my co-author’s suggestion, but in case you insist - basically PSL or SVA is matter of choice.
I for one prefer PSL for VHDL as it is “free” (as VHDL 2008 has PSL in it)
Srini