Anyone can create a testbench and verify the design, but it can’t be simply reused as a verification IP. Most of the module/IP level testbenches are used once to verify the design. We always want to use the same module/IP level testbench to verify the IP’s derivatives or the same IP at the chip /SoC level too. Also, if the testbench will be used by any third party to verify their IP/Chip, then the testbench should comply with coding guidelines as per the methodology like UVM. So, the reusable testbenches that follow a standard methodology, TB architecture and coding guidelines are called Verification IPs. Let me share some of the important guidelines to implement a VIP.
Verification Plan: Defines the verification intent of the DUV [Design Under Verification]. It captures all the design features and defines how each feature can be verified and tracked closely. It acts as a golden reference document for all the verification folks who are responsible for the complete verification sign-off. It will have all the details – TB architecture, Coverage Model, Verification Strategy, etc.
TB Architecture: Currently most of the companies prefer a standard testbench methodology like UVM [Universal Verification Methodology] to define their SystemVerilog TB architecture. It doesn’t mean that one can simply create UVM agents for all the interfaces and connect them together at the top level. To create a proper working TB, one needs to understand how the working environment of RTL would be in real time and how it can be modeled. This is the most difficult part of the verification process. Having a proper TB architecture means 50% of our job is over.
Let me share my experience, how I created the TB architecture for the Bluetooth verification IP [ABLE – Aceic’s Bluetooth Low Energy]. Refer the figure below – ABLE’s architecture.
ABLE was created mainly to verify the Link Layer RTL of Bluetooth. So, I modeled the TB as a host and created a TLM functional model in UVM for Link Layer. TB was using HCI [Host Controller Interface] as a TLM interface to connect and interact with the Link Layer functional model.
All the Link Layer compliance and HCI tests were modeled using UVM sequences. LL-TS[Link Layer Test-suite and HCI-TS[Host Controller Test-suite] were calling those virtual UVM sequences.
Also, we added necessary adapters [BFMs] to replace the functional model by RTL DUT at one end, as most of the DUTs use standard bus interfaces like AHB. One can configure the DUT adapter and use it with any interface. So, the DUT sequences remain the same at the top level. Smartly we had the facility to create a UVM register model for the DUT and capture the DUT status and reference/received data through backdoor access.
Verification Strategy: As we were into only VIP development, we didn’t have any access to RTL. So, we had to find a way to verify our functional model. I had created two different teams, the TB team and the modeling team, and made them work independently in parallel on both the functional model and testbench. TB folks created their own DUT reference model independently, based on their interpretation of DUT[Link Layer] specification. Eventually, we had to deal with their difference in terms of interpretations and that really helped us to find all the bugs in the VIP.
You can’t sell a VIP which has more bugs than the DUT. Eventually, your customer will end up finding bugs in VIP rather than verifying their DUT. So, the verification strategy is critical for the success of your VIP.
As shown in the above figure, the VIP provider should provide all necessary things:
- Executable verification plan which maps all the coverage data
- Run scripts that can run regression and back-annotate the coverage data to verification plan, Regression test-suite that runs all the compliance tests
- Assertion IP to verify the interface protocols
- Reference models that can be used independently
- User guides to understand and run the VIP, examples, etc.
No one will buy the VIP just because its source code compiles and generates stimulus on a simulator. Your customer will ask you to prove how your VIP is different from other commercially available VIPs on their DUT during a detailed evaluation phase, beyond your impressive pre-sales presentation and demo. So, you really need to think how fast you can find bugs in their design and excite your customer, beyond their usual expectations like easy VIP integration and complete automation.
