Staged Scenario Generation For SoC Verification

By Sidhesh Patel & Prakash Bodhak, LSI Corporation
Pune India

Abstract:

SoC (System-on-Chip) involves number of IP blocks and verification of these blocks and interaction within these blocks is a complex procedure. Various methodologies such as eRM (Cadence/Specman) [1], RVM (Synopsys/Vera) [2], VMM (System Verilog) [3] are used by verification engineers to make SoC verification controllable and reusable. These verification methodologies definitely help to reduce efforts of SoC verification. However, problem faced these days is reuse of device level test infrastructure at system level and to generate complex test scenarios. Also challenge for verification engineers is to manage reusability, controllability and scalability of stimulus from device level to system level. Complexity of generating test scenario increases as verification progresses from device level to system level. This paper presents a staged scenario generation methodology for SoC verification to control, reuse and scale transaction generation from device level verification to system level verification. This methodology can provide various levels of transaction generation abstraction to reuse, control and scale stimulus to generate test scenarios for device level as well as system level.

1. Introduction

Verification consumes up to 50-70% of the development effort in today's multi-million gate ASICs, Intellectual Property (IPs), and SoC designs. A variety of approaches are used to ensure that all bugs are caught in verification before the design goes to silicon. Present reusable verification methodologies provide guidelines to reuse module level components like monitor, reference models, transactors and assertions at system level verification. Interestingly not much attention is paid to reuse test cases or test case development infrastructure like GENERATORS. It is a great challenge to generate complex test scenarios at system level. Generation of system level test scenario by reusing device level generators can be achieved by using our proposed staged scenario generation methodology. SoC has number of devices communicating with each other using on-chip bus. Verification for SoC normally follows bottom-up verification approach i.e. module level à device level à sub system level à system level. A typical verification environment using HVL (Higher Level Verification Language) has generators, transactors, checkers & monitors for stimulus generation and transaction validation. Abstraction (Nature) of stimulus changes as we progress from module level to system level. At module level, abstraction of stimulus is very close to bus and ports of module; where as at system level abstraction of stimulus would be close to actual application of SoC. In this paper we have explained how stimulus generated at lower level can be reused to generate stimulus of higher level.

2. Existing Stimulus Generation Methods

Direct signal/pin driving

This is the simplest and straight forward technique, to drive design pins from the test case. This method is useful when the design has very few input pins and needs to drive very few combinations on it. This method fails when we have design with complex protocols. Also it is inefficient when it comes to stimulus controllability, reusability and simplicity of test case.

Direct BFM (Bus Functional Module) control

In this method BFM contains tasks/functions to drive design ports as per the protocol. Tasks/Functions take input data, which is used by BFM to drive design ports. The difficulty with this method is, task/function of BFM must be called repeatedly in certain order. As scenario gets complex, testcase also get complex. Reuse of test cases in this method is almost zero as we move from device level to system level verification.

Transaction level control

In this method transaction class contains data, control or other information which can be decoded by transactors and driven to design ports as per the protocol. Atomic transaction generator is used to generate and send transaction to transactors. Atomic generator usually generates random transaction using only one transaction class or even it can get transaction object from test case or other source to send it directly to transactors without any modification. This approach is commonly used in verification.

Scenario level control

In this approach scenario [4] generator is used along with the transaction level control to generate sequence of transactions. Scenario generator randomizes array of atomic transactions. Constraining of items in array is done to generate scenarios as per need. This approach has following issues.

Number of constraints to be coded and its complexity increases as we move from lower level to higher level test case abstraction.
Reusability of constraints is difficult as we progress from lower level to higher level.
Tool requires more time/resources to resolve constraint, as constraint complexity and their number increase.

3. Proposed Staged Scenario Generation Methodology

3.1 Methodology

In this methodology stimulus generation process is proposed in following different stages

Figure 1: Verification levels

Atomic generator

It is the same atomic generator as used in module level atomic generation as explained above in transaction level control.

Stage0_scenario generator

This is one higher level stage of generation above atomic generation. Stage0 scenario generator will randomize stage0_scn_trans as per the constraint on its fields. Decode each scenario type and generate a list of atomic_trans by using constraint [Figure-2]. When scenario type is of random_type, generator will generate random sequence of atomic_trans.

Stage1_scenario generator

This is one higher level stage of generation above stage0 scenario generation. This generates sequence of stage0_scn_trans as per the scenario type.

StageN_scenario generator

This is one higher stage of generation above the previous stage (N-1) of generation.

Figure 2: Stages in staged scenario generation

3.2 Stage Scenario Generator

Each stage in this methodology has a stage scenario generator. Following steps are executed by the stage scenario generator as show in figure-3

Randomization/Injection

Generator can be configured to generate random scenarios or higher level generator can inject scenario to this generator.

Decoder

Decoder will decode the scenario type and generate sequence of lower level scenarios. Decoder is implemented using callback mechanism. Thus, decoder becomes scalable. For each scenario type add a callback which can decode that scenario type and generate sequence of lower level scenarios. Default scenario type will be random_type. When scenario type is random, generator will generate sequence of lower level scenarios without any constraint from generator.

Inject to lower stage

Generated sequence of scenarios will be injected to lower stage generator.

Synchronization operation (Optional)

Till now we have been considering generator as passive component which does not have access to any DUT (Design Under Test) signals. In certain cases at sub system or system level we need to wait for interrupt, check status and clear interrupt after each scenario/command. A callback mechanism should be implemented so that generation could be synchronized with external events.

Figure 3: Stage scenario generator

3.3 Advantages of Staged Scenario Generation Methodology

Controllability

The main advantage of this methodology is controlling each stage of stimulus generation. Suppose we need random generation at X stage. We can turn off higher stages after stage-X, while configure stage-X generator to work in random generation mode. Each stage generator or transaction class has one object of previous stage transaction class which is randomized by decoder callback to generate directed random scenario of lower level. Figure-4 shows controllability in stage generation.

Scalability

The following points highlight the scalability of proposed methodology;

Stimulus generation can be scaled from device level to system level without modifying lower level generator to implement more complex scenarios.
Stimulus can be generated for one transactor/BFM or for multi transactors/BFMs in stage scenario generator.
Each stage in staged scenario generation can add new scenario decode callback as and when needed without any modification to generator.

Figure 4: Controllability at various stages of staged scenario generation

Figure 5: Test case pseudo code

Reusability

In this methodology we can keep on adding new generation stages with full reuse of lower level generation stage. In order to reuse the test case from device level to system level, use scenario generation logic in generator while test case should only have scenario type selection. This will take test case logic from device level to system level with full test case logic reuse. Figure-5 explains test case reusability in terms of coding. In the known methods porting test case from one lower level to higher level needs some kind of transfer function. Graph A of figure-6. Shows the existing approach in which the transfer function is as simple as including a code or manual recoding.

Figure 6: Graph A -Test space and reusability graph

Graph B of figure-6 shows the advantage of staged generation which simplifies test case development and hence reduces number of transfer functions needed and thus increasing reusability of test cases from lower level to higher level. In a known method there is no test case code reuse and hence no overlap of test space as seen in the above graph whereas in the proposed methodology there is reuse of test code and there is overlap of test space. Reusability limitation of this method is that we can reuse at higher level until device, sub system and system is on same interconnect bus.

Figure 7: Graph B -Test space and reusability graph

4. Compatibility with Existing Methodology

Proposed staged scenario generation methodology is an extension to existing generation methodologies in VMM/RVM.

The first generator in this chain is normal atomic transaction generator same as defined in VMM/RVM methodology.
Each stage generator is an atomic generator with randomized object of its own transaction class. The only addition is that after stage scenario is generated it will be decoded by callback mechanism. Callback mechanism will create sequence of lower stage scenarios which will be injected to lower stage generator.
Each stage randomized object can be replaced by test case with its derived class instance with additional constraints.
Injection to lower stage can be same as sending transaction to transactor from atomic generator. Higher stage generator will inject in a channel and lower stage can receive it from the channel between these two stage generators.

5. Proposed Methodology Implementing Experiences

Practically we have used this approach for verification of NAND Flash Controller. Stage-0 is used to generate sequence of AHB transaction required to configure NAND Flash Controller to initiate command to NAND Flash memory for data storage or retrieval. Stage-1 was used to generate scenario like to perform status read

page write

page read

block erase

status read

page read. At system level we have used stage-2 generator which controls stage-0 generator to generate NAND commands to perform data transfer from NAND Flash Memory to DDR and vise versa as required by the system level scenario. Callbacks are appended in stage-0 generator which decodes command type of stage-0 scenario transaction class and returns list of AHB transaction which configures NAND Flash Controller to initiate command to NAND Flash Memory. Device level test case only has constraint to select command type. Stage-2 generator generates stage-0 scenario transaction by constraints on command type as required by system/stage-2 scenario. This way all logic required for each scenario generation is embedded in generator and not in test case, thus logic used at lower level of generation became reusable from device to system level.

6. Conclusion

This staged scenario generation methodology provides guidelines to implement controllable, reusable and scalable stimulus generator by dividing generation process in different stages. The lowest stage of generation uses atomic generator provided by HVL. Higher stage of generation is accomplished using generator class which creates constraint scenarios and injects them to lower level generators. Constraint management and scenario controllability is achieved through callback mechanism. Test case development becomes simpler and reduces to implementing callbacks and calling them as per the need. Thus, complex scenarios can easily be created by cascading different staged generators where lowest level is nearer to the design ports and protocols and the highest level is nearer to the application. Cascading of stages can be achieved using HVL mechanisms like channels. Practically we have used this methodology for NAND Flash Controller verification with 2 stage generation and reused at system level verification adding third stage.

7. References

[1] eRM reference manual Version 2.1.
[2] RVM User Guide Version 8.6.1.
[3] VMM for System Verilog by Janick Bergeron, Eduard Cerny, Alan Hunter and Andrew Nightingale.
[4] System Verilog LRM 3.1a.