Design Article
Tell us What You Think
We want to know what you thought about this Design. Let us know by adding a comment.
Design Reuse without Verification Reuse Is Useless
Adnan Hamid, Breker Verification Systems
11/26/2012 10:32 AM EST
Removing the Processors
Constrained-random test generation is a transaction-oriented verification solution, similar to driving packets onto the bus that had been driven by a processor now removed. This solution allows the maximum flexibility in terms of what can be sent into the rest of the hardware.
The problem is that this traffic is not realistic unless scenarios are created in the verification code to perform functions representative of the system’s operation. This involves knowing how to set up the peripherals to perform certain functions and generating the correct sequence of events on the bus to make data move through the system in a useful manner.
The UVM breaks down when a processor is added to the system, as shown in Figure 3. VIPs are not available for processors and there’s no way to write sequences that mimic the flow of data through a processor. Thus, with a UVM verification strategy, the usual option is to remove the processor and drive it with a bus functional model (BFM) that enables transactions to be driven onto the bus. Again, this approach may not produce realistic system-level traffic.
Running Production Software
Few designers would object to running production software on the system to see if it behaves as expected. This is the heart of hardware/software co-verification and many companies include this step as part of the sign off process.
However, it is unlikely that software will be available in the right timeframe. Prior to tapeout, a Catch-22 [3] situation is created. The hardware design is not ready and stable so that running software may be unreliable, but the software cannot be debugged and stabilized without executing it on stable hardware –– a difficult way to perform system-level verification and debug.
In addition, relying only on the execution of production software provides inadequate testing. Production software tends to be well-behaved and not stress corner cases in the design. Further, if the software were to change and exercise different flows through the hardware, bugs lurking in the design could restrict the versions of software that could be run. Finally, production software usually runs slowly in simulation. Booting a real-time operating system (RTOS) on an embedded processor is feasible on a hardware accelerator, but this option is not available to all SoC verification teams.
Writing Custom Software
Of course, it is possible to handwrite custom software to run on the processors and could be at two different levels. First, directed tests could be written that move data through the system in a specific manner. This may use some of the production software, such as drivers, to create a hardware abstraction layer so that the test developer does not need to know details, including peripheral configuration. Directed tests suffer from many of the same problems as running production software, in addition to the time it takes to write the tests.
Alternatively, software could be written that is more specific for verification, analogous to the process of writing code for built-in self-test (BIST). While multiple tests could be written, this tends to be customized code that may not be useable when the platform is modified or extended. It gets successively more difficult as additional processors are added into the system, especially if they are heterogeneous in nature. Moreover, humans have trouble visualizing parallel activity within the SoC, making it difficult to handwrite multi-threaded tests for multiple embedded processors.
Constrained-random test generation is a transaction-oriented verification solution, similar to driving packets onto the bus that had been driven by a processor now removed. This solution allows the maximum flexibility in terms of what can be sent into the rest of the hardware.
The problem is that this traffic is not realistic unless scenarios are created in the verification code to perform functions representative of the system’s operation. This involves knowing how to set up the peripherals to perform certain functions and generating the correct sequence of events on the bus to make data move through the system in a useful manner.
The UVM breaks down when a processor is added to the system, as shown in Figure 3. VIPs are not available for processors and there’s no way to write sequences that mimic the flow of data through a processor. Thus, with a UVM verification strategy, the usual option is to remove the processor and drive it with a bus functional model (BFM) that enables transactions to be driven onto the bus. Again, this approach may not produce realistic system-level traffic.
Figure 3: UVCs with Processor Added
Running Production Software
Few designers would object to running production software on the system to see if it behaves as expected. This is the heart of hardware/software co-verification and many companies include this step as part of the sign off process.
However, it is unlikely that software will be available in the right timeframe. Prior to tapeout, a Catch-22 [3] situation is created. The hardware design is not ready and stable so that running software may be unreliable, but the software cannot be debugged and stabilized without executing it on stable hardware –– a difficult way to perform system-level verification and debug.
In addition, relying only on the execution of production software provides inadequate testing. Production software tends to be well-behaved and not stress corner cases in the design. Further, if the software were to change and exercise different flows through the hardware, bugs lurking in the design could restrict the versions of software that could be run. Finally, production software usually runs slowly in simulation. Booting a real-time operating system (RTOS) on an embedded processor is feasible on a hardware accelerator, but this option is not available to all SoC verification teams.
Writing Custom Software
Of course, it is possible to handwrite custom software to run on the processors and could be at two different levels. First, directed tests could be written that move data through the system in a specific manner. This may use some of the production software, such as drivers, to create a hardware abstraction layer so that the test developer does not need to know details, including peripheral configuration. Directed tests suffer from many of the same problems as running production software, in addition to the time it takes to write the tests.
Alternatively, software could be written that is more specific for verification, analogous to the process of writing code for built-in self-test (BIST). While multiple tests could be written, this tends to be customized code that may not be useable when the platform is modified or extended. It gets successively more difficult as additional processors are added into the system, especially if they are heterogeneous in nature. Moreover, humans have trouble visualizing parallel activity within the SoC, making it difficult to handwrite multi-threaded tests for multiple embedded processors.
|
|
|
|
|
Navigate to related information