Basics of Assertion IP

By Sandeep Vaniya

The purpose of this article is to provide some basic information about Assertion IP to people who don’t have much information about it.

As per the name, AIP is having assertions written at interface level.

Mostly, AIP is written following strict design coding guidelines so that it can be synthesizable.

AIP can be used in Functional simulation environment as an interface monitor similar to transaction level monitor which is used to check interface behavior as per interface protocol. But, mainly it is targeted for Formal environment with Formal tool.

In Formal environment with Formal tool, it is used to generate stimulus to design, perform interface level checks and provide coverage in the Formal environment to verify the design with very less efforts.

Inside AIP

One will found following details in most of the AIP

• Top level module having Inputs and Outputs which is used to connect [or bind] AIP with DUT
• Parameters to customize AIP to work with customized DUT
• Having interface checkerswritten in the form of properties
• Assert / Assume / Cover declarations of the properties
• Glue logic to help writing complex protocol check conditions in the properties

Bind

Bind will be used to connect AIP with DUT without creating separate test bench module or without editing design code.

One can create separate bind file and using bind keyword, AIP can be connected to DUT.

One can use internal signals and parameters of top level DUT module during binding. Binding AIP with DUT using bind keyword is something like one is creating instance of AIP module inside top level DUT module.

Glue logic

Main purpose of the AIP is to run it with Formal tool in Formal environment. So, AIP should be written in such a way that it will be Formal tool friendly and fully synthesizable. There are various coding guidelines to code AIP to make it formal tool friendly. Those details are out of scope for this article.

Glue logic is required in AIP to avoid writing very complex conditions in the properties. Formal tool will find it very hard to converge on properties if they involve very complex conditions. So, one need to write separate glue logic which can take care of complex condition of the property and code in the property will get simplified.

Assert, Assume and Cover

People familiar with SystemVerilog assertions will be mostly aware of assert, assume and cover declarations of the properties.

AIP will be having various properties to perform protocol checks on given interface.

Then, those properties will be declared as “assert” so that it can indicate adherence or violation of the protocol condition in either formal or simulation environment. In Formal environment, one can look at property falsification and in simulation environment, one can look at failing message in the log.

Similarly, properties will be declared as “cover” so that it can be ensured that what all protocol conditions are exercised in the Formal environment. It gives confidence that what all stimulus Formal tool is able to generate.

Now the important part, “assume” declaration of the property. “Assume” declaration of property will help tool to generate VALID stimulus to the DUT. By default, Formal tool will try to generate all permutation-combination of inputs of DUT. As per given protocol, all those combinations may not be valid. So, formal tool will tune its auto-generated stimulus to DUT based on conditions written in the properties which are declared as “assume”. It will generate stimulus such that all conditions specified in “assume” properties are satisfied.

For example, in AXI protocol AxBURST [ARBURST or AWBURST] is 2-bit signal and valid values as per protocol are 0, 1 or 2. So, we can write assume property for this mentioning (AxBURST != 3). So, Formal tool while generating values for AxBURST will make sure it will generate value 0, 1 or 2 for AxBURST and not 3.

Advantages of AIP

AIP will provide following advantages which adds more value on top of functional simulation environment

• No need to develop test bench or verification environment. Formal tool and AIP code itself does everything to verify the design. One just needs to bind AIP with design and run with Formal tool.
• Formal tool with the help of AIP will be able to generate stimulus to the design automatically i.e. no need to write any test cases
• Formal tool with the help of AIP will be able to generate interface level design corner cases easily which may take very long time to get produced in randomized transaction level functional simulation environment because it directly generates various interface level stimulus without dependency on any high level transaction on top of it
• Since there are very less efforts [or almost zero effort] needed to develop formal verification environment with Formal tool, one will be able to discover potential bugs in the design very early in the design cycle [In Functional simulation environment, large amount of time will be spent in developing test plan, verification components, verification environment, test bench, test cases, etc., only after which actual verification will start.]

AIP with Formal environment is not substitute for functional verification in simulation environment. It helps in achieving better confidence about design in early stages of design cycle without waiting for verification environment to be built and executed. AIP with Formal environment may not be able to generate ALL high level complex scenarios which randomized transaction level functional verification environment can generate in simulation environment.

About Author:

Author has more than 11 years of experience in VLSI / Semi-conductor industry in Design and Verification domain.

In case of any query/question, you can reach me on my email ID: sandeep.vaniya@gmail.com