ASIC Main | Archives

Page 1 of 4

Jump to...

Introduction Language vs. Technique Cycle-Accurate Modeling Speed vs. Accuracy Comparison of Actual Simulation Times for a 3GPP Turbocoder

Introduction—The Difficulty of Verifying System Designs

"Block-based design" has become a common design methodology for creating complex systems on chips. In a block-based design, individual system blocks are designed independently of each other (possibly even by different companies), and are then later combined on a single piece of silicon. Examples of blocks are RAM, ROM, DSP processors, controllers, and application-specific blocks such as voice codecs, A/D converters, video compression, and bus interfaces. Each block can be developed internally or can be purchased from third-party intellectual property (IP) vendors. Because of their complexity and the fact that they frequently include reprogrammable resources, modern System-on-a-Chip (SoC) devices are often also referred to as platforms.

Block-based design has several advantages for SoC design. It makes the design process more manageable because the complexity of a single block is vastly less than that of the entire system. Experts in specific application domains can design individual blocks that are optimal for a specific task. For example, Bluetooth experts can design the Bluetooth baseband, while memory experts can design the memories. Thus, the overall quality of the design is better. Finally, since the functionality and timing within each block can be verified independently of the other blocks, the verification problem is more manageable. Although it is very rare that an IP block can be re-used in another design, the experience gained in designing that block is applicable to the design of a modified version of that block.

More Complexity Causes an Exponential Increase in Verification—Combining the various blocks into the SoC, however, poses new verification challenges because simulating all the blocks together exponentially increases the amount of simulation required.

For example, when Resource (Block) A and Resource B are combined, the communication between A and B on the silicon must also be modeled. When C is added, the communications between blocks A and B, B and C, and A and C must be modeled. As each resource is added to an SoC design, the verification problem grows disproportionately larger.

Increased Depth of Simulation for System-Level ICs—Another issue that compounds the simulation problem is that SoCs must be tested with real-world signals. Many SoC designs are deployed in application domains as a silicon platform that will be used for multiple designs. The flexibility and extensive embedded resources allow SoC platforms to perform multiple functions in the targeted application domain. For example, an SoC platform for digital camcorders could handle the user interface for processing recording and playback, video, and audio functions, servo motor control, and so forth. The same SoC platform can be used for a range of different end-product derivatives with different feature sets and price points.

The complexity and flexibility of these designs, plus the fact that natural signals are often fed to the inputs or are generated from the SoC, necessitates extensive testing of the system with the natural signals. In addition to verifying whether the SoC has been designed properly, the designer must ensure that it behaves properly in the end product in all relevant environments and circumstances. Thus, the complete SoC must be simulated with real sampled data and in simulation scenarios that include multiple thousands of input signal samples and several millions of SoC clock cycles.

Consider a fairly simple MP3 audio system. The only way to test the quality of audio designs is to have people listen to them. However, testing just three seconds of operation of an MP3 audio SoC generates 132,300 output samples (3 × 44.100 Hz). Assuming an SoC system clock frequency of 10 MHz (a low-power implementation), 30 million SoC clock ticks will have to be simulated. If event-based simulation at the RT-level can only handle around 100 samples per minute, simulating a single three-second snippet of audio would take nearly a day (1,300 minutes). In order to fully simulate multiple audio scenarios and effects, a much larger timeframe than three seconds is needed. In these cases, the time required to simulate an RT-level model can easily extend to weeks.

It is estimated that silicon complexity (viewed from the verification/simulation standpoint) increases by about 160% per year, while the processing power of workstations only increases by about 60% per year. This means the amount of elapsed time required for simulation and verification is doubling each year. Today simulation and verification amount to more than 50% of the total design cycle. Using current event-based verification technologies, SoC verification will either have to be much less robust in its scope and depth, or design cycles will have to be extensively lengthened.

Fortunately, a new modeling technique has emerged recently that provides simulation speed improvements of 30 to 100 times, greatly improving the ability to verify SoCs.

Language vs. Technique
Back to top

Abstraction Level is Language-Independent—There is some confusion about modeling languages versus modeling techniques. Most system-level designs are written first in C or C++ using a behavioral modeling technique. The factual hardware designs are described using register-transfer (RT) level Verilog or VHDL.

Behavioral system designs are concerned with functionality only. and consequently they have no notion of hardware architecture, concurrency, clocks, physical timing, and so forth. The only aspect of a behavioral design that can be evaluated is its functionality (e.g., the encoding and decoding of a fragment of audio data). Consequently, these C/C++ behavioral system models simulate very quickly.

RT-level Verilog or VHDL hardware designs include extensive details on hardware resources and architecture. They model concurrent processing structures and take into account clocks and even physical (normalized) timing. The modeling of this level of hardware detail makes RT-level models much slower to simulate than the behavioral models.

The fact that most high-level system designs are done in C/C++ and most hardware designs are done in RT-level HDLs frequently leads to the conclusion that all designs written in C simulate quickly, while all designs written in Verilog or VHDL simulate slowly. However, this is not the case. The difference in simulation speed is less attributable to the language than it is to the level of detail or abstraction used in the model itself.

Factors Affecting Simulation Speed—The simulation speed is directly affected by the level of detail that is simulated. The main levels of detail can be distinguished as follows:

• functional-level description, describing in abstract terms the functional behavior of the system;
• architectural-level description, including details on hardware structure and resources; and
• register-level description, including details on the behavior of the fundamental logic elements (registers and gates), with details on normalized timing.

		Click here to get your listing up.