Source: Embedded Systems Engineering
It wasn’t all that long ago when hardware engineers and embedded software developers saw no common ground. It was all but the semiconductor world’s version of “Men are from Mars, Women are from Venus.”
While they may have been the same gender, worked for the same company and attended the same college in the same university, these developers and engineers were planets apart. Hardware and software groups were managed separately and worked in isolation, using different tools and methodologies. They spoke different languages, worked in different areas and didn’t understand the interactions between the two disciplines. Worse yet, neither was able to comprehend their debugging domains. They wasted valuable project time traveling between the two planets to identify and fix problems. Talk about wasted time travel!
Figure 1. Once worlds apart, embedded software developers and hardware engineers are seeing their “planets” come into alignment. Courtesy Wikipedia.
That had to change as embedded design got more complex. At the same time, there was increasing emphasis on verifying that the systems’ embedded software and hardware would work together as the specification described. Change did come about as individual hardware and software groups became one project team and began verifying simultaneously the hardware and software portions of a system-on-chip (SoC) design—practicing what’s now known as hardware/software co-verification.
No Time to Wait for Working Silicon
The change happened with the move to hardware emulation and I credit it for aligning two disparate design planets. The hardware-assisted verification tool is able to find any kind of design bug –– save analog since emulation requires a digital representation of the design –– and can trace bugs across the software and the hardware platform.
It was an inevitable change, however, because the earlier that software development can begin, the more likely the embedded hardware will succeed. Programming software for embedded design can take longer than the chip design, and with unyielding time-to-market pressures project teams can’t wait for working silicon before starting software development.
An SoC design is rife with complexity. It includes embedded microprocessors, running operating systems, drivers and numerous applications with several millions of lines of code. The chip is comprised of logic blocks to accelerate processing of data, such as digital signal processing, image processing or packet identification and routing. The chip connects to peripherals and physical interfaces appropriate to its target application. Verifying each hardware block and validating the embedded software impose specific requirements on the tools and methodologies.
As for executing a vast amount of embedded software, the chip processor requires speed as billions of cycles are needed to obtain meaningful results. Embedded software development mandates the use of software debuggers. Logic blocks need accurate simulation with access to waveforms. Peripherals require accurate simulation as well to verify the interaction between device drivers and peripherals and the efficient transfer of data in and out of the chip.
In the past, hardware developers relied on hardware description language (HDL) simulators, great for hardware debug in the early stages of the design cycle when the design is at the block level. They haven’t kept pace and now run way too slowly on designs of tens or hundreds of million gates. Hardware emulation can handle designs of several hundreds of million gates or even a couple billion gates and provide the desired level of accuracy, speed and visibility.
Embedded software developers validated their code using instruction-set simulators (ISSs) that are not cycle-accurate and don’t support interfaces to custom register transfer level (RTL) blocks.
Transactors have eliminated much of these challenges and made hardware/software co-verification possible. By raising the level of abstraction of peripheral interfaces from the cycle/bit-level to the transaction level, transactors can simplify the description of data exchange between an SoC and its peripherals.
Hardware transactors are a viable alternative to the traditional in circuit emulation (ICE) driven by a target system. Unlike ICE, hardware transactors benefit from being controlled by software, which allows for a flexible and adaptable verification environment, impossible in ICE. They eliminate speed adapters, remove all hardware dependencies and run verification of corner cases at the same speed of execution of ICE, if not faster.
But transactors come with a string attached. They need a testbench in place of a target system. This was the case until Mentor Graphics introduced VirtuaLAB. VirtuaLAB is an innovation based on transactors that replaces the physical target system with a functionally equivalent virtual target system, i.e., a software implementation of ICE applications. Unlike hardware-verification testbenches that are not understood by software developers, VirtuaLAB allows for creating user scenarios and environments well understood by software designers.
Furthermore, VirtuaLAB supports multiple concurrent users without the massive burden of ICE hardware that such deployment would entail. Think of 20 software engineers accessing concurrently their DUTs, where each design would need its own target system and a set of ICE speed adapters. With VirtuaLAB 20, software-based virtual ICE target systems and interfaces would replace a bulky and impractical hardware setup.
With this approach, project teams can use hardware emulation remotely. Hardware emulation as a remote resource for R&D groups residing all over the globe is a trend welcomed by project teams. Emulation design data centers filled with emulation enterprise servers and a centralized team of experts can support a multitude of users in different geographies and time zones. The servers can manage any combination of small and large designs, up to more than one billion gates.
Hardware emulation includes a hardware debugging environment, which performs at close to the speed of a software development board and can be controlled in software. It’s also a software development environment that maximizes flexibility, analysis and reuse. It reduces the cost of developing SoCs and the two formerly disparate planets are able to work together with relative ease to debug SoC designs.
While it didn’t take a best-selling book to highlight the differences between hardware developers and embedded software designers, it seemed impossible that their two planets would ever orbit near each other. That changed with the accessibility of hardware emulation.
Dr. Lauro Rizzatti is a verification consultant. He was formerly general manager of EVE-USA and its vice president of marketing before Synopsys’ acquisition of EVE. Previously, he held positions in management, product marketing, technical marketing and engineering. He can be reached at lauro@rizzatti.com