Why the OS is the Hub of a Hardware Emulator

The OS shields the software from the hardware and assures the compatibility of any new and old software with any new or old hardware platform

For more than a decade, I have been following the practice of upgrading my laptop every three years. I do so for more than one reason. After three years of intense use, subjected to the wear and tear of international travel, a laptop gets tired. New generations of hardware run faster, consume less energy, and weigh less. Also, new displays have higher resolutions — an attribute that tops my list of features.

The mandatory criteria for supporting the upgrade is that the suite of application software I have gathered over time must run, no matter what the underlining hardware is. This is made possible by the operating system (OS). It is the OS, with its embedded drivers, that shields the application software from the hardware and assures the compatibility of any new and old software application with any new or old hardware platform.

Hardware emulators are a unique type of special-purpose compute engines that are designed and built to perform one task, albeit with a multitude of angles — design verification of digital electronic systems. With a special OS, they verify the functionality of a design without taking into account its timing behavior. They do so at speeds 100,000 to 1,000,000 times faster than any HDL (hardware description language) simulator.

They are versatile in deployment since they can accommodate any test environment one can think of before silicon availability. Test environments range from the real target system to an equivalent virtual target system to any testbench (no matter how complex) to embedded software — and any combination of the above. Some commercial emulators enable software developers to debug software offline. This is similar to the methodology used by hardware engineers who use waveforms generated by the emulator for offline hardware debug.

They support assertions, monitors, and checkers; they can track functional coverage; and they can perform power analysis and power estimation. They are an ideal vehicle for software bring-up, security checking, hard/soft error recovery, integration/validation of IPs and memories, and can even accomplish performance characterization and system stress.

Compared with earlier generations, today’s emulators have advanced in several directions. A case in point is the ability to be shared among several concurrent users, including hardware designers, verification engineers, firmware engineers, and software developers. Combined with remote accessibility, their raw performance and deployment versatility can be made available in any place of the world where there is an SoC design team. Obviously, this plays a significant role in a return-on-investment (ROI) analysis.

Figure 1: Modern hardware emulators support multiple concurrent users from anywhere in the world.

Still, emulators are subject to peculiarities inherent to hardware systems. Installing and testing an emulation platform may take days, which is a far cry from the minutes typically needed for a software application. Major upgrades and re-configurations follow the same pattern. Sometimes, a large company may elect to move the emulator to a different site, or maybe even to another continent. This would lead to a downtime of several weeks, if not a month or more.

Unlike software-based verification tools, emulators require maintenance that can be scheduled if preventive, such as system software upgrades, minor hardware replacements, and re-configurations. It would cause unplanned downtime when corrective, such as hardware failures, A/C malfunctions, and an electrical power breakdown.

Ideally, all of this should be taken into account by a hardware emulator’s OS to enhance convenience, increase simplicity, and amplify ROI.

Starting with the underling hardware, an OS should shield any version of the emulator — including any future generations — from the application software. Any applications, such as co-modeling, transaction-based verification, functional coverage, and power analysis — along with any other application developed in the future, whether aiming at hardware verification, software testing, or system validation — may run on any later generations of the emulator.

Figure 2: An OS shields any application from the underling hardware emulator.

Additionally, an OS should enable enterprises to build an emulation datacenter combining any generation of emulation platform to ensure highest ROI.

In a multi-user environment, the OS should administer the emulator resources efficiently and automatically and integrate with existing IT workload management solutions. Multiple concurrent jobs would be queued according to user priorities and resource availabilities, without bottlenecks stemming from oddities in the hardware architecture. Automatic job suspension (due to temporary unavailability of co-modeling resources or I/O targets, for example) and resumption would assure high efficiency.

Automatic relocation of jobs within the emulator resources to accommodate new jobs with larger capacity needs would increase the utilization of the platforms. A dashboard ought to graphically report the queuing status of each job.

Equally as important, software upgrades, hardware re-configurations, and all operations scheduled in the preventive maintenance would be simplified, thereby limiting the downtime of the emulator. Users would not need to be re-trained, and workflows and scripts would not need to be re-written since the OS would manage all operations automatically and transparently.

Moreover, machine data would be collected to provide analytics, and graph historical and geographical usage.

These features and benefits would maximize the ROI on capital investments and make the development of a sophisticated OS a “must have” for hardware emulation.

One such OS is Veloce OS3 — a new operating system supporting Mentor Graphics’ Veloce emulation platform.

As my every three-year upgrade confirms, a laptop OS — like that of a hardware emulator’s OS — must be able to support all version of application software.

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, Lauro held positions in management, product marketing, technical marketing, and engineering. He can be reached at lauro@rizzatti.com.