Mentor’s Charley Selvidge has been thinking that the operating system of a hardware emulator is a natural evolution of the way software systems are built for emulators
Source: EE Times
Charley Selvidge, chief engineering manager at Mentor, a Siemens Business, has an unassuming and modest demeanor that belies a sharp intellect and professorial ability to explain complex concepts in easy-to-understand terms.
All of this comes in handy as he explains the landscape of hardware emulation, something about which he knows a thing or two. In the late 1990s, Charley was a founder of Virtual Machine Works, which was located a stone’s throw from MIT in Cambridge, Massachusetts. VMW, as it was known, was acquired by IKOS Systems in 1998, which subsequently became part of Mentor in 2002.
Through all the changes, including a cross-country move to California, Charley kept designing new and improved emulators. He is the mastermind behind the latest version of the Veloce Emulation Platform, a data center-friendly emulation platform called Veloce Strato.
Lately, Charley has been thinking that the operating system of a hardware emulator is a natural evolution of the way software systems are built for emulators.
To illustrate, he uses the analogy of a computer system. “In the early days of computing, computers didn’t have operating systems. Programmers quickly determined that it would be useful to have standard software sit between the low-level operations of the computer hardware and the high-level tasks or programs that they wanted to run on the computer.” A layered approach would provide a consistent set of services and make it easier to produce applications and programs, avoiding the need to reinvent or reproduce common underlying capabilities, like opening files or other interactions with the computer.
He moves his analogy to emulators and notes: “They consist of a hardware execution platform at the bottom for running a model of a digital chip and a set of application-oriented tasks to run on the emulator.” These tasks often have high-level objectives, such as characterizing the amount of power a chip is consuming or processing a software application that runs on a processor inside the chip. In either case, the entire chip needs to be considered as part of the task.
Undeniably, he adds, these are high-level and complex tasks routinely performed by an emulator. A set of intermediate services standard to emulation inside of an operating system could insulate high-level tasks from the low-level, machine-specific details associated with emulation.
For this reason, Charley affirms, operating systems are an interesting concept for an emulator.
Hardware and software scalability in hardware emulation
All emulators are based on some kind of modeling component; that is, a device that can model a piece of a chip. A multitude of these modeling components are assembled together in a small, medium, or large number to build systems of various sizes. On top of this underlying hardware is a software compilation system. An emulation compiler reads in a database or model of an integrated circuit and writes out a datasteam that configures the array of modeling components in the emulator to form an image of the chip.
Typically, integrated circuits are designed via computer programs that execute a description of the circuit written in one of a few computer languages, generically called hardware description languages (HDLs). The most commonly used HDLs are Verilog, SystemVerilog, and VHDL. The circuit description defines the behavior of the circuit. These descriptions are synthesized into a real integrated circuit and compiled into a model that runs on an emulator.
According to Charley, with a model for a chip, the designer would load it onto the emulator, a machine-specific task performed by the emulator’s OS software. The OS performs several other tasks, including running and stopping the clocks, accessing design visibility data, or applying stimulus to the emulated model and collecting its responses. It should be noted, he adds, that the functional design verification task consists of writing data into the device, extracting data from it, deciding if it is correct, and interacting with it.
These basic tasks are common to most higher-level jobs an emulator can execute. He offers a few examples, including characterizing power, running software, and a number of other activities. They, in turn, bring into play various elements of the underlying services to perform them. Charley offers extracting visibility data to establish power consumption as an example. That involves running the design in a testing environment, pulling out the data, processing it, and feeding it into more software for power computation.
Scaling software complexity is a dimension of scaling and another good example. It is helpful to have an OS to provide a basic set of functions and services used by more complex tasks managed at a higher level of abstraction — in other words, the way computer programming works. Charley adds, “Designers don’t want to program in assembly language. They don’t want to have to write their own file service routines. Instead, they use compilers and standard capabilities like file service access.”
The second aspect of scaling for an emulator’s OS is its ability to model devices of wide-ranging sizes. At one end of the spectrum, a designer might choose to model one intellectual property (IP) block that could be small and fit in a small set of emulation’s hardware resources. At the opposite end of the spectrum, a designer could model a full system-on-chip (SoC) design, such as a CPU or a large internet switch chip. This creates a set of software-oriented challenges to develop software capabilities tuned to handle small models as well as large models.
“It is harder to manage large designs, but even more challenging to develop the right tradeoffs to span a wide range of sizes,” he allows. Once software challenges are tamed, it would be helpful to store the solution into a standard place. That place is in an OS.”
Providing services inside of an OS for features such as visibility can support capabilities tuned to small designs as well as large designs without designers knowing what might be behind the capability to scale efficiently.
“In both of these dimensions, an OS is a relevant software organizational strategy for developing an emulator’s software,” says Charley.
Hardware emulation apps
All this leads Charley to a new wrinkle for hardware emulation. It is joining the world of “apps,” like PCs or mobile phones, facilitated by implementing services used by those apps in much the same way software works for those consumer devices.
When dealing with application-specific problems such as “apps” and developing software to solve them, it helps to have lower-level services packaged in a way that software doesn’t need to be written to accomplish those tasks. Those services can be provided in an accessible form by an OS via a set of application programming interfaces (APIs), an approach for higher-level applications to get to underlying services.
By implementing this type of software organization — meaning an OS and apps — designers can stabilize the OS software and define an effective and consistent set of APIs. This approach offers an efficient method to develop apps without concern for the lower-level details and to work across different generations of the hardware emulation platform.
Another aspect of using an OS is its ability to insulate higher-level software elements like apps from changes in the underlying hardware by providing adaptation layers that offer transparency. With this approach, designers can build apps that don’t change as the hardware platform evolves, protecting the original investment and leveraging it into the future. Instead of recreating old software to work on new platforms, designers can invest energy to create new software that works across multiple generations of platforms.
“An OS and “app” software organization approach like this is unique and advantageous to designers,” he concludes. And with that, we leave Charley to go back to thinking about operating systems and, perhaps, the next-generation hardware emulator. Meanwhile, we’re left to consider the possibilities for hardware emulation of the future.
Dr. Lauro Rizzatti is a verification consultant and industry expert on hardware emulation (www.rizzatti.com). Previously, Dr. Rizzatti held positions in management, product marketing, technical marketing, and engineering. He can be reached at lauro@rizzatti.com.