Zero bugs is the goal for every embedded task
EE Times: Latest News Zero bugs is the goal for every embedded task | |
Lauro Rizzatti (10/04/2004 9:22 AM EDT) URL: http://www.eetimes.com/showArticle.jhtml?articleID=48800552 | |
It is not uncommon for today's embedded systems to feature thousands to millions of lines of code, and the number of software engineers on the design team — and their associated development budget — now often equals or exceeds that of their hardware counterparts. The limitations of conventional verification solutions mean that around half of all embedded-systems development projects come in months behind schedule, and less than half of all designs meet their original feature and performance objectives.
Without sufficiently detailed verification, the lost market share and revenue associated with late product introduction can be immense. Even worse, the costs associated with the bad publicity that would arise from releasing a product that intermittently fails in the field are incalculable. A new class of hardware emulation solutions is needed to better address the needs of today's embedded-system hardware and software engineers.
Software developers and hardware engineers use different performance metrics. Software developers rate speed by instructions per second, whereas hardware engineers measure the pace of execution in cycles per second or hertz. Since most embedded processors execute roughly one instruction per cycle, a million instructions per second (Mips) equates to 1 million cycles/s (megahertz).
One common verification option used by software developers is the software-based instruction-set simulator (ISS), which features a high-level behavioral model of the processor (usually written in C/C++). An ISS typically executes at about 10 Mips or 10 MHz, when used in standalone mode without any other part of the design.
A standalone ISS provides great visibility into what the software is doing. However, in order for a verification solution to be really useful to software engineers, it must allow them to develop and verify everything from the system initialization routines and hardware abstraction layer, through the real-time operating system and its associated device drivers, all the way up to the embedded application code itself.
As such, the entire design must be modeled either at the RTL or at a higher level of abstraction. If the whole design but the processor is modeled at the RTL, the ISS is coupled to a software simulator or a hardware emulator, which handles the peripherals and the rest of the design. Unfortunately, the coupling of an ISS to an HDL simulator causes dramatic performance degradation to no more than 20 kHz due to the switching between the ISS and the RTL at every cycle. Higher performance of at most 500 kHz can be reached by interfacing the ISS to a traditional emulation system.
If the verification system simulates at anything less than around 10 MHz, then it's of no use for software developers in the context of an edit-compile-run-debug cycle, and when running on a modern, off-the-shelf, high-end PC, an ISS coupled to even an emulator falls well below this level.
The idea behind a software virtual-prototyping platform is to model the entire system at a very high level of abstraction. The level of abstraction is such that an entire system-on-chip (SoC) can be simulated at an equivalent rate of 10 to 40 MHz on a modern, high-end, off-the-shelf PC, which is 20x to 2,000x the performance of a traditional ISS.
This approach can therefore be very useful for the early development of embedded software prior to any RTL becoming available. Also, this technique provides a useful way to develop non-timing-critical portions of the design, such as the graphical user interface. However, these virtual platforms trade off accuracy for speed, which means they are of limited use when it comes to detecting and identifying subtle problems in the hardware/software integration.
Furthermore, many embedded systems run in a real-time mode, in which the correctness of computations not only depends on their logical results, but also on the times at which those results are produced. This means that the highest-quality verification has to be performed using the RTL, because this provides the closest representation possible to the actual silicon. Changing a single line of RTL code typically requires reverification of the entire design, but this level of detail is not available in the software virtual-prototyping platform.
Hardware emulators
The maximum speed a traditional hardware emulator can achieve typically ranges between 200 and 500 kHz, and this assumes that everything (including the testbench) is represented in the emulator or that the input/output is connected to a real-world (physical) system environment. If the testbench is running in a software simulation, the emulator's speed slows down to between 5 and 20 kHz.
These speeds do allow the simulation to run for sufficient cycles to be of use to hardware design engineers, but they are of little use to software engineers, who may require the ability to simulate hundreds of millions of clock cycles. Furthermore, traditional emulation solutions are limited in their abilities to address the requirements of real-time embedded-system designs.
To achieve the required simulation speeds but avoid the costs associated with traditional hardware emulators, many design teams opt to create an in-house FPGA-based prototype for their design. The common perception is that this is an inexpensive solution, because the final board for a 1M ASIC gate design can typically be produced for around $10,000.
However, developing such a board demands a high level of expertise and can require the same amount of engineering time and resources as developing the main design. Although such boards can provide the required speeds of 20 to 30 MHz for quite small designs, they almost invariably provide limited visibility into the hardware. The restricted hardware debug capability associated with this poor visibility can result in weeks or months of additional development time, which directly equates to lost market opportunities.
Zero bugs
With regard to real-time embedded systems, these new platforms provide a transaction-level interface (based on the Accelera industry standard) that allows the design to be tested in the context of its real-world environment. And the affordable nature of these solutions (around $30,000) makes it possible to equip each engineer with his or her own board, which dramatically speeds the development of the embedded-software portion of the design.
As one example of the use of such a platform, consider a Memory Stick that plugs into the USB port of a PC. Although relatively recent, such devices have quickly become tremendously popular for keeping useful data at hand and for moving data between computers. To the computer (and the user), the Memory Stick appears to be a standard PC file system.
Inside the Memory Stick (behind the scenes), however, in addition to the flash memory itself there is an SoC featuring a microprocessor core with associated embedded software. This SoC is tasked with interfacing with the main PC via its USB connection and making the Memory Stick appear to be a standard file system. This requires the device's hardware and software to be co-verified under real-time conditions so as to ensure an extremely robust implementation.
Lauro Rizzatti (lauro@eve-team.com) is general manager of EVE-USA (San Jose, Calif.).and vice president of marketing at the French parent company, EVE.
| |
All material on this site Copyright © 2005 CMP Media LLC. All rights reserved. Privacy Statement | Your California Privacy Rights | Terms of Service | |