Verification IP vs Testbench

Anyone can create a testbench[TB] and verify the design, but it can’t be simply reused as a verification IP [VIP]. So I would like to address in this article: What is VIP? How can we build a high-quality VIP? How can we verify the VIP? What else can we do to make the VIP unique and commercially more valuable?

Most of the module/IP level nonstandard testbenches are used once to verify the design. Is it efficient? 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 efficiently. Also, if any third-party vendor or client wants to use the testbench to verify their IP/Chip, then the testbench should comply with coding guidelines as per the standard methodology like UVM. So, a reusable testbench that follows a standard methodology, scalable TB architecture, and coding guidelines is called Verification IP. Let me share some of the important guidelines to implement the VIP.

Verification Plan: Defines the verification intent of the DUV/DUT[Design Under Verification/Test]. 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 responsible for the verification sign-off. The VIP functional specification will have all the details – Vplan, TB architecture, Coverage Model, Verification Strategy, Test Scenarios, etc.

Verification Plan [Vplan] is different from the test plan as it’s based on the DUT features and random testcases. In SystemVerilog, we use covergroups and assertions to generate the functional coverage primarily to track the verification progress during the regression testing, which is predominantly done through random testcases. This verification tracking process can be automated by back-annotating the functional coverage to the Vplan document[Excel/Word Doc] during simulation using the EDA tool. But using the test plan, we track it manually by running every directed testcase, usually developed in HDL. Despite this huge difference Directed vs Random, traditional verification folks still refer to Vplan as test plan, similar to how we informally refer to the RTL as DUT instead of DUV.

TB Architecture: Currently, most companies prefer a standard testbench methodology like IEEE standard  UVM [Universal Verification Methodology]  to define their SystemVerilog TB architecture. It doesn’t mean that one can simply create UVM agents for all the DUV interfaces and connect them together at the TB 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 modelled. It is the most challenging part of the verification process. Having a proper TB architecture that can support our verification strategies means that 50% of our job is over.

Let me share my experience, how we created the TB architecture for the Bluetooth verification IP [ABLE – Aceic’s Bluetooth Low Energy]. Refer to the figure below – ABLE’s architecture.

ABLE was created mainly to verify the DUV, Link Layer RTL of Bluetooth. So, we created the UVM TB to mimic the host and TLM functional reference model in UVM to mimic the Bluetooth Link Layer. TB was using HCI [Host Controller Interface] as a TLM interface to configure and interact with the Link Layer functional model. The TB as the host for generating stimulus to configure and drive both the BLE reference model and RTL. The scoreboard for comparing the DUV outputs with the expected values generated by the reference model.

More importantly, using the DUV reference model as TLM, one can add or remove any number of BLE devices dynamically during simulation by creating or deleting the TLM objects, as we do in the real-time environment.

All the Link Layer compliance and HCI test scenarios were modeled using UVM sequences. The LL-TS[Link Layer Test-suite and HCI-TS[Host Controller Test-suite] were invoking those UVM virtual sequences.

Also, we had added necessary adapters [BFMs] to replace the functional model with RTL BLE IP at one end, as most of the DUVs use standard bus interfaces like UART/SPI. One can configure the DUT adapter and use it with any interface. So, the DUT side sequences remain the same at the TB top level. Smartly we had used the UVM RAL model to capture the DUT status, and reference/received data through backdoor access for the scoreboard data comparison.

Verification Strategy: Our approach was back-to-back verification using our BLE reference model, UVM TLM. As we were into only VIP development, we didn’t have access to the BLE RTL IP. So, we had to find a way to verify our functional model. I had created two different teams, the TB and modeling team, and had made them work independently in parallel on both the functional model and testbench. TB folks created their own DUV reference model as a predictor logic independently, based on their interpretation of DUV[Link Layer] specification. Eventually, we had to deal with their difference in terms of interpretations, which helped us find all the VIP bugs.

You can’t sell a VIP that 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 also provide all necessary things:

• Executable verification plan which maps all the coverage data
• Scripts that can run the regression test-suite that includes all the compliance tests and back-annotate the coverage data to the verification plan
• Assertion IP to verify the interface protocols
• Reference models that can be used independently as TLMs
• 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 any industry-standard 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 about how fast you can find bugs in their design and excite your customer beyond their usual expectations like easy VIP integration, user interface, and complete automation.

Maven Silicon Corporate Courses

Also Read:

CEO Interview: Sivakumar P R of Maven Silicon

Experts Talk: RISC-V CEO Calista Redmond and Maven Silicon CEO Sivakumar P R on RISC-V Open Era of Computing