Page 10
www.us-
tech.com
TechWaTch
Hardware Emulation Rules for Software Developers
By Dr. Lauro Rizzatti, Verification Consultant
and not hardware emulation. That is changing. The versatile hardware em- ulator is gaining a more widespread reputation for being able to ensure that the embedded system software works correctly with the underlying hardware. It is becoming a shared re- source between hardware and soft- ware teams to accelerate hardware/ software integration ahead of first sil- icon. This is important, as the ratio of software developers is greater than hardware engineers on a chip project. Through the years, hardware
W
emulation has been used for hard- ware verification of ASIC and SoC (system-on-chip) designs, and its use is growing. Hardware emulation’s speed of execution can be up to six or- ders of magnitude faster than a hardware-description-language (HDL) simulator, reducing the de- sign debug process without con- straining design sizes. Among the
hen software developers hear the word emulation, they of- ten think software emulators
largest SoC designs are processor and graphics chips, and Ethernet switch and router chips. All of them approach or even surpass the half- billion ASIC-equivalent gate mark. These are designs that would thwart an HDL simulator.
Executing Embedded Software Never has hardware/software
co-verification been more important, as embedded software becomes a large component of an already com- plex SoC design. For designs that use an operating system, such as Linux, booting it is a bare minimum. But Linux already exists and it is not code that designers have to write. However, it does have to be cus- tomized to the system with memory maps and drivers that take a simple system call and cause it to do real work on real hardware. Booting an OS typically gets the
10/3/17 9:29 AM Page 1
designer to the starting line. The software that does the real work can only start when the OS has been suc-
DC-3 Series
DC-1 Series DC-2 Series
cessfully loaded. Attempting to verify such applications would simply stretch the runtime way beyond the OS boot time. In addition, the designer has to
test multi-threaded programs. For some systems, the multiple “threads” are actually turned into multiple processes running independently on different cores, with or without an OS. Packet processing is probably the best example of this. It typically consists of a pipeline of processors, each of which performs a specific piece of the packet processing func- tionality in turn. All of the threads or processes have to work together seamlessly, passing data around as necessary and swapping contexts. Simulation farms, a popular re-
source, are not adequate to execute embedded software. Embedded soft- ware needs to be processed in paral- lel and cannot be split between sub- sets, all of which takes several billion sequential cycles. Hardware emula- tion can easily handle a sequential process and is unaffected by design sizes. At speeds of several hundreds of kilohertz or megahertz, it can boot Linux in less than one hour. Integrating newly-designed hard -
ware with newly-coded software should be done as early as possible to resolve bugs. It ensures software and hardware are verified concurrently to confirm that they interact correctly. It can be used as soon as the de-
New!
• DC-2A/2B Series
HiQP Series • DC-1 Series • 120-370 VDC input voltage range • 5-300 VDC regulated isolated outputs
High Input Voltages Up to 900 VDC • Up to 300 watts output power
DC-DC Converters
• 350-1200 VDC input voltage range • 5-300 VDC regulated isolated outputs • Up to 300 watts single & dual outputs
• DC-3 Series • 300-900 VDC input voltage range • 3.3-300 VDC regulated isolated outputs • HiQP Series • 125-475 VDC input voltage range • 24-200 VDC regulated isolated outputs
• Up to 50 watts single & dual outputs • Up to 50 watts output power
DC-DC CONVERTERS VISIT OUR EXCITING NEW WEBSITE:
www.picoelectronics.com
ALL MODELS AVAILABLE WITH EXPANDED OPERATING TEMPERATURES SELECTED MILITARY SCREENING • CUSTOM DESIGNS
PICOELECTRONICS, Inc. 143 Sparks Ave., Pelham, New York 10803
Call Toll Free 800-431-1064 • FAX 914-738-8225 E Mail:
info@picoelectronics.com
sign register transfer level (RTL) code is stable to uncover difficult-to- find hardware bugs that require many millions of verification cycles. It can trace a software bug into the hardware or a hardware bug in the software’s behavior with the neces- sary speed, performance and capaci- ty to handle complicated debugging scenarios, something no other verifi- cation tool can do.
Unaffordable Shortcuts Virtual platforms are becoming
an increasingly popular way of test- ing software ahead of actual hard- ware. For general-purpose applica- tions, those not requiring intricate interaction with the hardware, virtu- al platforms are an effective way of testing application software way be- fore silicon or even RTL availability. However, the strength of a vir-
tual processor is also its weakness: It can execute software quickly because it abstracts out much of the execu- tion detail. Such abstraction is ac- ceptable for higher-level code or ap- plications. For code that touches the hardware, such as drivers, designers cannot afford to take that shortcut. Virtual platforms are utterly inade- quate for proving that the chip is working because they eliminate the
chip’s details. To verify the interaction of em-
bedded software with the underlying hardware, a cycle-accurate representa- tion of the design is needed to be able to trace a bug anywhere in the SoC. A hardware emulator offers an accurate functional representation of the de- sign, before the silicon is ready for test- ing. The emulated design is based on an actual silicon implementation, even though it is not timing accurate. Functional verification and sys-
tem validation are hardware emula- tion strengths. It is used to verify the
Never has hardware/soft- ware co-verification been
more important, as embed- ded software becomes a large component of an al- ready complex SoC design.
hardware and software work as in- tended and validate that the system meets or exceeds the specification. Software programmers are us-
ing it to validate embedded software — applications, diagnostics, drivers, operating systems and software-driv- en tests, all with a need to process hundreds of millions, even billions of cycles. This is extending its use across the entire SoC development cycle.
Hardware emulation gives soft-
ware developers full, 100 percent vis- ibility into the hardware design, nec- essary to quickly trace bugs any- where in the design.
Not to be Confused Verifying the combination of
hardware and embedded software is estimated to consume about 70 per- cent of the project cycle. This verifi- cation task is also the most challeng- ing one to perform, so hardware em- ulation is a great benefit. This co-ver- ification process can improve product quality and shave months off a proj- ect development schedule. The makeup of an SoC project
team has changed through the years and now comprises both software de- velopers and hardware engineers. Combining the two disciplines offers a way to differentiate the product and give it a technological edge. Both groups have come to value hardware emulation’s ability to verify hard- ware and software at the same time. No one will confuse software emula-
tion and hardware emulation again. Contact: Mentor, A Siemens
Business, 8005 SW Boeckman Road, Wilsonville, OR 97070 % 503-685-7000 E-mail:
tessent@mentor.com Web:
www.mentor.com r
December, 2017
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68 |
Page 69 |
Page 70 |
Page 71 |
Page 72 |
Page 73 |
Page 74 |
Page 75 |
Page 76 |
Page 77 |
Page 78 |
Page 79 |
Page 80 |
Page 81 |
Page 82 |
Page 83 |
Page 84 |
Page 85 |
Page 86 |
Page 87 |
Page 88 |
Page 89 |
Page 90 |
Page 91 |
Page 92
