Need Emulation Now? You’ve Got It

Did you know that the way companies use hardware emulation has changed?

Until recently, companies had no choice but to house their emulators in a lab and hard wire them (using lots of wires) to other supporting hardware and workstations dedicated to a single project at a time. The emulator and its set up was accessible to users at only that location and switching between projects was difficult and time consuming.

For these reasons, an emulator often sat idle. Any project scheduling of an emulator was done manually by allocating fixed time slots to project teams. This was an inherently inflexible and inefficient way to manage a very valuable resource, especially for global teams. And as the use models for emulators expanded, the demand for a simpler, more flexible way to make emulation widely available throughout a company at all times became more acute.

Figure 1: As emulators have evolved, the need for specialized job scheduling has become imperative.

The initial response was to manage an emulator as a corporate-wide shared resource in a datacenter. This is how most emulators are utilized today. Unfortunately, standard job management software, such as LSF and Sun Grid, does not allow companies to take full advantage of emulator resources and capabilities. These approaches treat emulators like any other hardware in a datacenter. The truth is, emulators are far more complex and specialized than general purpose systems. Every emulation job is different in terms of size, duration, verification requirements and priority.  So efforts to meet demand have fallen short.

To satisfy the high demand for greater utilization of emulation resources, Mentor developed the Veloce Enterprise Server App, a fully-integrated solution for complete, transparent access to emulation resources for concurrent projects worldwide. It significantly enhances emulator use by delivering advanced features like suspend-resume-relocate, high prioritization, and large job scheduling as well as access to utilization statistics over a period of time.

Understanding how a datacenter-based emulator works starts by looking at how an emulator is built. An emulator begins with a chassis. The chassis is equipped with a number of slots to support a number of boards — aka AVBs. The more boards, the more capacity and the more users running emulation concurrently. For example, a single chassis can support up to 2 billion gate designs and 128 simultaneous users.

When an emulator is used as a datacenter resource the capacity (number of boards) in the emulator becomes a shared resource, and effective job scheduling software is needed to “share” the emulation resource. In a datacenter environment, job scheduling software is just as important as the capacity of the emulator.

So how can all of these users be accommodated while maximizing the productivity and quality of verification?

The answer is relatively simple. The app allows job management software to understand how to manage an influx of emulation jobs. It serves as an interface between job management software and the emulator hardware platform.

The Veloce ES App recognizes the configuration of the emulator and the requirements of the emulation job in the queue at any given time. It also knows what a piece of hardware can do, and where there is flexibility in the system. For example, it knows how many emulation boards are available, where they are, and what can be done with them. It uses this intelligence to distribute the design over different AVBs and even multiple emulators.

Figure 2: System flexibility minimizes idle hardware by distributing individual designs across emulation boards in several ways.

Verification engineers simply upload their emulation jobs using normal job submission commands. Once a job is in the queue, the app identifies the best possible resource to run the job. Once resources become available, the job is dispatched and the resource is marked as busy. The job runs and the verification engineer gets the results. When a job is completed, the next job in the queue is started. Bottom line: No emulator downtime and no human interaction or communication is needed.

The notion of “no downtime” is reinforced by a capability called suspend-resume-relocate. Suspend and resume substantially increases emulator utilization as advanced blocking of resources is not needed. In other words, the app enables the scheduling of low priority jobs without sacrificing performance or capacity for higher priority jobs.

Figure 3: The suspend-resume use flow.

Typically, jobs immediately go on the emulator if resources are available to run them. When a high-priority job needs to run immediately, the app saves the entire state space of the job currently running on the emulator and suspends it in order to run the higher priority job. When the high-priority job is completed, the emulator resumes the suspended job from the exact timeframe where it was suspended. This also gives users the flexibility to either resume a suspended job on the same emulation hardware or relocate the verification run to similar hardware that is immediately available.

The approach enables 24×7 utilization of emulation resources by verification teams worldwide, allowing companies to greatly reduce the total cost of ownership. It also ensures maximum use of the entire infrastructure by providing a robust, efficient, and scalable job scheduling solution that matches the most appropriate resources with the needs of the workload. And it supports efficient management of the emulator resources and minimizes added cycles. Consequently, users typically see a 20% increase in emulation capacity.

Now that’s a better way to emulate!