Over the past few years, the term “pre-silicon verification” has been quite popular and several technology advancements have helped in solving that puzzle. Some of the biggest contributors have been languages such as e/Specman and SystemVerilog with supporting technologies such as constrained-random verification (CRV), coverage-driven verification (CDV) and assertion-based verification (ABV). All these three technologies when used in unison addressed the challenge at the block or intellectual property (IP)level fairly well. Recently UVM has been developed as a framework to use these languages in the best possible manner to try and keep these technologies scalable to larger designs, such as system-on-chips (SoC). Thanks to the Accellera committee devoting time and effort, UVM is becoming quite popular and the de-facto IP verification approach.
However with SoCs, there are several new challenges in the verification space that threaten to quickly outgrow the current prevalent technologies such as CRV and UVM. One of the key pieces in an SoC is the embedded processor/CPU – either single or multiple of them. Witha transaction-based verification approach such as UVM, typically the CPU gets modeled as a BFM (bus functional model). Some customers term this as a “headless environment” indicating that the “head” of a SoC is indeed the CPU(s). In theory, both the CPU bus and the peripherals can be made to go through grinding transactions via their BFMs.
Figure-1: Sample headless SoC environment
While this certainly helps to get started, soon engineers find it difficult to scale things up with advanced UVM features such as the Virtual Sequencer, Virtual Sequences etc. Even with deep understanding of these, developing scenarios around them has not been an easy task. The length of such sequences/tests, their debug-ability and review-ability have started begging the question of “are we hitting the limits of UVM” - especially in the context of SoCs?
If you thought this is too premature of an assessment, hold-on: the trouble has just started. Anyone involved in an SoC design cycle would agree that the so called “headless environment” is just a start, and would most certainly want to run with the actual CPU RTL model(s) running C/assembly code running on the same.
Figure-2: SoC environment with actual CPU RTL running C/assembly code
This is a significant step in the pre-silicon verification process. The current UVM focus doesn’t really address this immediate need, thereby forcing users to create a separate flow with a C-based environment around the CPU and hand-coding many of the same scenarios that were earlier tested with “headless UVM” environment. Though the peripherals can still reuse their UVM BFMs, the “head” is now replaced with actual RTL and the co-ordination/synchronization among the peripherals needs to be managed manually – no less than a herculean task. We have heard customer saying “I’ve spent two months in re-creating concurrent traffic, a la the headless environment in the C-based setup”.
The hunt has been on for a higher level modeling of the system level scenarios that can then be run on either a headless or C-based environment – keeping much of the scenarios as-is. Here is where the graphs start to make lot of sense as human beings are well versed with the idea of mind maps (http://en.wikipedia.org/wiki/Mind_map) as a natural, intuitive way of thinking about simultaneous activities, interactions and flow of thoughts.
Breker has been the pioneer in this space by introducing a graph-based approach to functional verification. With graphs, users capture the IP level scenarios as nodes and arcs making it ideal to capture the typical day-in-the-life (DITL) for the IP. Many such IP-level graphs can then be quickly combined to form a SoC level scenario model such as the one below:
Figure-3: SoC level scenario model
With a graphical scenario model, TrekSoc (http://www.brekersystems.com/products/treksoc), the flagship SoC verification solution from Breker, can then be asked to either churn out transactions for a headless environment or embedded C-tests for the actual CPU based system with a flip of a switch.
Figure-4: Using scenario models with TrekSoC
This is clearly way beyond current UVM intended goals as UVM is created to solve the problem of VIP reuse and it serves its purpose very well.
Now, with C-tests being auto-generated, the possibilities are endless – they can be reused across the breadth of verification and validation in various platforms starting with simulation, through emulation/prototyping, and all the way up to post-silicon validation.
Bottom line: UVM is serving the very purpose it has been developed for – to create interoperable, reusable VIPs. However a full SoC verification is much more than a bunch of VIPs. It requires next abstraction level models such as the graph based scenario models. Such scenario models can then be compiled by TrekSoC to produce C-tests and/or UVM transactions.
