Common Reusable Verification Environment for BCA and RTL Models
📝 Abstract
This paper deals with a common verification methodology and environment for SystemC BCA and RTL models. The aim is to save effort by avoiding the same work done twice by different people and to reuse the same environment for the two design views. Applying this methodology the verification task starts as soon as the functional specification is signed off and it runs in parallel to the models and design development. The verification environment is modeled with the aid of dedicated verification languages and it is applied to both the models. The test suite is exactly the same and thus it’s possible to verify the alignment between the two models. In fact the final step is to check the cycle-by-cycle match of the interface behavior. A regression tool and a bus analyzer have been developed to help the verification and the alignment process. The former is used to automate the testbench generation and to run the two test suites. The latter is used to verify the alignment between the two models comparing the waveforms obtained in each run. The quality metrics used to validate the flow are full functional coverage and full alignment at each IP port.
💡 Analysis
This paper deals with a common verification methodology and environment for SystemC BCA and RTL models. The aim is to save effort by avoiding the same work done twice by different people and to reuse the same environment for the two design views. Applying this methodology the verification task starts as soon as the functional specification is signed off and it runs in parallel to the models and design development. The verification environment is modeled with the aid of dedicated verification languages and it is applied to both the models. The test suite is exactly the same and thus it’s possible to verify the alignment between the two models. In fact the final step is to check the cycle-by-cycle match of the interface behavior. A regression tool and a bus analyzer have been developed to help the verification and the alignment process. The former is used to automate the testbench generation and to run the two test suites. The latter is used to verify the alignment between the two models comparing the waveforms obtained in each run. The quality metrics used to validate the flow are full functional coverage and full alignment at each IP port.
📄 Content
Common Reusable Verification Environment
for BCA and RTL Models
Giuseppe Falconeri, Walid Naifer, Nizar Romdhane
STMicroelectronics - OCCS (On Chip Communication Systems)
Abstract
This
paper
deals
with
a
common
verification
methodology and environment for SystemC BCA and RTL
models. The aim is to save effort by avoiding the same work
done twice by different people and to reuse the same
environment for the two design views. Applying this
methodology the verification task starts as soon as the
functional specification is signed off and it runs in parallel
to the models and design development. The verification
environment is modeled with the aid of dedicated
verification languages and it is applied to both the models.
The test suite is exactly the same and thus it’s possible to
verify the alignment between the two models. In fact the
final step is to check the cycle-by-cycle match of the
interface behavior. A regression tool and a bus analyzer
have been developed to help the verification and the
alignment process. The former is used to automate the
testbench generation and to run the two test suites. The
latter is used to verify the alignment between the two
models comparing the waveforms obtained in each run.
The quality metrics used to validate the flow are full
functional coverage and full alignment at each IP port.
- Introduction
Nowadays, System On Chips are increasing in terms of
complexity and time to market is becoming more and more
critical and functional verification is a bottleneck.
Development time of such activity takes 80% of design effort. This effort is mainly spent to test RTL design, since it will be the circuit to map on silicon. The introduction of BCA development in the flow is becoming wider. The fast simulation of BCA models permits to fast find the optimized configuration, in terms of bandwidth, area and power consumption. Therefore, these models are becoming key elements in SoC development and the constraints in terms of functional point view are similar to RTL, that’s why it is necessary to have the powerful verification environment also for the models. Moreover having a common verification environment that is reusable for both BCA and RTL can give a big benefit. The idea of the common verification environment is not new [1] and we want to follow this new strategy because of the gains in terms of development time and accuracy of the verification since the random traffic and automatic checkers can be applied for both the views of the design. In this paper the common verification environment developed for the dynamic functional verification of the STBus1 [2] components is described. - The Past flow In the past there was no strategy for a common verification of the two views of the IPs. The BCA model verification and the RTL verification were two different activities managed by two or more different teams. In fact in the verification of the BCA models the test bench was developed by the model owner and occupied a short time of his whole activity. It was based on a very basic model of harnesses written in SystemC and doing write then read operations towards a memory model. The tests cases were directive and allowed checking particular features of the design. And a lot of checks were done visually. On the opposite the verification of RTL model was based on Verisity Specman [3] tool allowing random generation and automatic checks that cover all functional rules. Whole activity was performed independently from design. The fact that verification environment was handled by the BCA model owner makes self-error detection more difficult. The test bench was also not strong enough to reach corner cases. Other drawbacks were that the effort spent to develop verification environment was duplicated in RTL and BCA development and there was no way to understand “quality metrics” like coverage for BCA so a new strategy for the verification becomes fundamental.
- STBus Overview The aim of this section is to introduce the STBus, the communication system developed for System-On-Chip in 1 STMicroelectronics proprietary on-chip bus` Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE’05) 1530-1591/05 $ 20.00 IEEE ST. The STBus is a set of protocols, interfaces and architectural specifications defined to implement the communication network of digital systems such as microcontrollers for different applications (set-top box, digital camera, MPEG decoder, GPS). The STBus protocol consists of three different types (namely Type I, Type II and Type III), each one associated with a different interface and capable of differing performance levels. x Type I is a simple synchronous handshake protocol with a limited set of available command types, suitable for register access and slow peripherals. x Type II is more efficient than type I because it supports split transactions and p
This content is AI-processed based on ArXiv data.