Array
(
    [content] => 
    [params] => Array
        (
            [0] => /forum/threads/sva-system-verilog-assertion-is-for-designer-too.2236/
        )

    [addOns] => Array
        (
            [DL6/MLTP] => 13
            [Hampel/TimeZoneDebug] => 1000070
            [SV/ChangePostDate] => 2010200
            [SemiWiki/Newsletter] => 1000010
            [SemiWiki/WPMenu] => 1000010
            [SemiWiki/XPressExtend] => 1000010
            [ThemeHouse/XLink] => 1000970
            [ThemeHouse/XPress] => 1010570
            [XF] => 2021770
            [XFI] => 1050270
        )

    [wordpress] => /var/www/html
)

SVA : System Verilog Assertion is for Designer too!!

Dear Reader,

I have been hearing one question over SVA is "Is System Verilog Assertion is for Designer too?". Usually the impression is 'System Verilog is for Verification'. I agree with this impression to some extend but there are some strong constructs in SV which adds values for designers too for design coding !

Actually System Verilog is nothing but a extension of Verilog, It has everything to support Verilog with lots of new features for Verification as well as for design!! This is again one important topic to discuss, I will try to cover this in some other blog post. Here I would try to capture question which I have mentioned above "Is System Verilog Assertion is for Designer too?".

Simple answer to this question is "YES" !!

Usually Verification engineers add assertions to a design after the HDL models have been written which means placing the assertions on module boundaries to signals within the model, or modifying the design models to insert assertions within the code.

Design Engineers can/should write assertion within a design while the HDL models are being coded. Usually here is where main question/challenges occurred, what type of scenario or assertions designer should provide within design? Answer to this question is : Decision should made before design work begins.

There is no doubt that 'Verilog Checks like assertions can be added into a design using the standard Verilog language' But I would like to point out some drawbacks on writing verilog checks like assertions this way,

1. Complex Verilog checks can require writing complex Verilog code.
2. Checks written in Verilog will appear to be part of the RTL model to a synthesis compiler.
3. Verilog assertion/checks will be active throughout simulation, there are ways to control over it but there is no simple way like SVA does with system functions ($assertoff, $asserton, $assertkill etc..)
Please read my blog post on "SVA Control Methods"

Let me explain some advantages for designer with SVA:

1. SystemVerilog assertions are ignored by synthesis. The designer does not need to include translate_off / translate_on scattered throughout the RTL code.
2. SystemVerilog Assertions can easily be disabled or enabled at any point during simulation, as needed. This is a beauty of SVA!! Don't you think ?

I have covered 2nd advantage in my blog post "SVA Control Method"

These advantages allows designer to add assertions to RTL code and gives a flexibility to disable the assertions for simulation speed later in the design process. Using this control methods we can focus to a specific region of the design by controlling assertions dynamically or disabling respected assertion in the design.

Suggestions and Comments are always welcome.

Enjoy
ASIC With Ankit
 
Ankit,

Absolutely! Assertions essentially capture design intent, whether placed at an IO boundary to describe the interface protocol or to describe the internal functions of the logic within the module. Who better to write these that the designer who developed and implemented the design? To expect a verification engineer to write these is asking too much. Traditionally, I've seen verification engineers write protocol assertions and some assertion to verify behavior after a bug has been discovered. The protocol assertions are valuable but writing assertions after bugs are discovered isn't a good use of the benefits of Assertion-Based verification. For designers just getting into ABV there's a good introduction here. The design methodology I prefer is to capture as much functionality as possible and then completely verify it. The assertions provide a robust functional model that when verified, guarantees the correctness of the design.

One other way to add assertions seamlessly is to use the SVA bind facility:

rtl_module #() u0 (.*);
bind rtl_module bind_module #() u1 (.*);

where bind_module is:
module bind_module (
input .....

);

`include "sva_file_1.sv"
`include "sva_file_2.sv"

endmodule

This leaves the RTL "pure".

A question for all our design colleagues: Why aren't you using assertions and ABV?

Jim O'Connor
Solid Oak Technologies
www.solidoaktech.com
 
Last edited by a moderator:
Thanks Jim for reading this post and providing your valuable comment !

Yeah, agree with approach of using SVA bind facility.

I have seen people (designer) who are using the treditional assertions for standard functions/functionality/feature, They develop these type of assertions and use those assertions libraries for upcoming product as it is or with minor modification if applicable.

I would say, designer have already started writing a assertions at some extent !

Regards,
Ankit
www.asicwithankit.blogspot.com
 
Using binding and making the files with assertions suitable for it make the SVA reusable. I.ex, assertions for single IP test bench can be used on higher level, to monitor the usage of the IP when instantiated on system level.
 
Back
Top