Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Bug hunting SoC for full functional coverage closure

Posted: 18 Sep 2014 ?? ?Print Version ?Bookmark and Share

Keywords:system on chip? SoC? verification? constrained random verification? constrained random verification?

The aim of system on chip (SoC) verification is to ensure that the design is an accurate representation of the specification. Achieving fully verified SoC is an arduous task, yet verifying the SoC by using both directed verification and constrained random verification (CRV) can result in a 100% verified design.

Constraints help to reach coverage goals by shaping the random stimulus to push the design under test into interesting corner cases and avoid hitting invalid/illegal scenarios.

Using CRV, corner cases in the design can be exercised and system behaviour under stress can be observed. Stress can be induced in the system by generating random traffic in the SoC. 'Random traffic' implies initiation of transactions from random selection of master to randomly selected slaves with any transaction type, size of data, and latency of transactions.

This paper describes how to use constrained random verification to uncover bugs that are difficult to find using traditional directed verification.

Differences between scope of directed and random verification
In directed verification, the verification environment has mechanism to send the stimulus to DUT, collect the responses, and check them. The stimulus is generated, and each stimulus verifies specific features of the design.

This becomes tedious when design complexity increases; it becomes more difficult to create stimuli that fully exercise the design. Stimulus maintenance becomes harder and time consuming.

In directed verification, the verification engineer has to list out each scenario, hence there is a probability of missing potential bug scenarios, allowing bugs to escape and lurk in corners, hidden until late in the development cycle, or not found at all until product is taped-out.

The solution to the above problems is constrained random verification (CSR) in which a constraint provides the feature by which to reach the coverage goals through shaping the random stimulus to push the design under test into interesting corner cases. To constrain data items, two things are necessary:
1. Identifying the data item classes and their generated fields, and,
2. Creating a derivation of the data item class that adds or overrides default constraints.

Using constrained random verification, the stimuli required to verify test features are generated automatically. Verification owner specifies the set of specifications, and the test bench automatically creates a solution space and picks up scenarios from it.

Constrained random verification is necessary for these reasons:
???It stresses the system bus and connected gaskets with multiple masters working simultaneously.
???It provides a random transaction based environment which involves all masters/slaves.
???It allows the SoC designer to focus on system level issues rather than unit level ones.
???The use of CSR shortens functional verification cycles by rapidly achieving coverage goals once the random testbench environment becomes stable.

Setting up your design for CSR
A mandatory requirement to do CSR is to set up a self-checking testbench (figure 1) with built-in capabilities for stimulus generation, drivers, monitoring, scoreboarding, and checking. Once that is done the following methodology should be followed:
???Identify the masters and slaves (example C memories) in the system.
???Replace IO masters (unit level) by stubs (assuming the hard IPs are already verified). The rest of the system remains unchanged with all the physical buses and gaskets at their respective places.
???Set up a weight based control for random selection of slaves.
???Set up a weight based control for number and size of transactions from different masters.
???Set up a weight based control mechanism for type of transaction issued C read, write, snoopable, etc.
???Set up randomized delay between transactions from each master.
???Set up standard monitors and system level scenarios specifically targeting functional coverage; sampling should be available.
???Set up coverage dumping with integrated exclude list.

Figure 1: Test environment for random stimulus generation and coverage.

Performing CSR in your SoC design
Once you have set up your test environment as shown in figure 1, you need to first write a generic stimulus base class from which you can derive various methods and attributes to convert generic commands with respect to specific protocols.

1???2???3?Next Page?Last Page

Article Comments - Bug hunting SoC for full functional ...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top