System Verilog Assertion Binding - SVA Binding

Dear Readers,

As we all know SV has become so popular in verification industry with its very good features and constructs which helps us verify today's complex designs. Today, I am going to discuss about SVA binding that we use in test bench for SVA properties.

There are VHDL and Verilog model we use to deal with these days. Mostly verification engineers are not allowed to modified these modules. But still SVA addition to these modules are required and easy to verify lot of RTL functionality. How can you add SVA to these modules? 

Here is where system verilog ‘bind’ comes in picture. Generally you create a SVA bind file and instantiate sva module with RTL module.

SVA bind file requires assertions be wrapped in module that includes port declaration, So now lets understand this with a small example to understand basic things on  how to use SVA bind : 

click on below image to enlarge.. 

DUT_Module - Dummy RTL module to understand this example

SVA_Module - Dummy SVA module with implemented assertion property

TB_Module - Dummy test bench code to see how bind works with module instantiation 

Here, you could see there is DUT instantiation created DUT_u1 instance of DUT_Module. Now point of interest for us would be, how to bind DUT instance to SVA module.

To understand this take a look at line number 50 in image from TB_Module, where you could see 'bind' keyword used with DUT_Module module and SVA_Module. This is the place where we are binding DUT module with SVA module. Thus passing DUT signal information to SVA module. With this we could play around with DUT signal and can check assertion properties using DUT signals available through this instantiation.

If the assertion module uses the same signal names as the target module, the bind file port declarations are still required but the bind-instantiation can be done using the SystemVerilog .* implicit port connections. If signal names are not exactly matching between target and bind file module then we need to expand the instantiation with respected port names.

Hope, this information on SVA binding is useful, stay in touch with me and share your views !

Thanks,

Ankit Gopani

System Verilog : Functional Coverage Guidelines

We have been implementing every possible checks to make sure design is verified but what have we done to check our test bench ? How do we make sure that our test bench has covered everything that needs to be covered w.r.t to specification and test plans ? Here is the place “Functional Coverage” and “SVA” comes in picture!

Before we start on few guidelines to follow while working with functional coverage, I would encourage you to refer various posts on functional coverage and assertions to get high level idea on architecture and usage. Click on 1, 2, 3!

Now, Basic questions can come to mind is, "what is the difference between code and functional coverage?". Let’s understand it at high level and then we will move forward to understand guidelines for functional coverage.

Sr No	Code Coverage	Functional Coverage  and SVA
1	Derived from design code with the help of simulation tools	It is user specified, controlled approach coverage by test bench
2	Evaluate design code to check whether structure is covered or not	Measures functionality part with the help of covergroup, cover point and bins (with the help of luxury feature of System Verilog J) (With SVA you can capture functional coverage using cover property)

To conclude with few guidelines from various posts on functional coverage and assertions:

Functional coverage and code coverage both are contributing highly on sign off criteria for verification. Verification engineers have to make sure that their test plan and test environment is intelligent enough to satisfy the code/functional coverage closer. Code coverage is generated by tool with the help of the simulations generated by the test environment. So test environment should be random and intelligent enough to make sure design is covered as a part of code coverage and designer should be in agreement while code coverage review. There should be valid comments with reason for all exclusions for code coverage w.r.t to design specification. Functional coverage should be written such a way that it should be able to capture all identified functionality while defining the test plan. Coverage and assertions are very important entity in the verification process and there are few guidelines that would help in verification process.

Few guidelines while working with functional coverage

1. Your test plan should be based on the functionality you want to verify w.r.t to specification
2. You should have a coverage matrix with the list of cover point details w.r.t to your test plan scenario and there should be link of traceability between test scenario and cover point.
3. Environment should have control mechanism for enabling or disabling coverage and assertions for better control ability in your environment
4. Don’t enable functional coverage at the beginning of the verification to avoid simulation overhead in the starting phase of verification
5. During the initial time of the verification bug ration is typically high, as you move forward to the verification bug ration would start to drop. Here is the time when you should enable coverage and analyze it
6. Functional coverage plan needs to be updated as verification progresses
7. As your knowledge of the design and corner case understanding increases, you should keep updating your functional coverage plan
8. Make effective use of cover group “trigger” and sampling mechanism. (Stay tune for sampling mechanism on upcoming blog post !)
9. Follow meaningful names of cover group and cover points. This will help when you in debug process
10. Coverage should not be captured on failing simulations. Make sure to gathered coverage for only passing simulation. If few tests are not passing in regression first make sure to fix those issues before come to a conclusion on coverage achievement
11. If your tests are keep exercising the same logic in design, start developing the new tests for uncovered coverage part of coverage (coverage holes)

For guidelines on SVA, please refer to this article !

Stay tuned to understand functional coverage sampling mechanism !

Thanks,
ASIC With Ankit