Simulation Design Data Center Brings Good Evangelism to Verification Engineers

Today, more and more designs are being carried out at the system level, which is unprecedented. What makes this happen is hardware simulation technology. Hardware emulation allows the use of register transfer level (RTL) source code as a model, but at the same time provides sufficient processing power to support system-level work, especially when it comes to software development or running software workloads.

Therefore, hardware simulation has replaced the RTL simulator that has flourished for more than 30 years, and has become the focus of attention. It should be noted that I am not here to encourage everyone to abandon the RTL simulator. In the hardware verification process of the early design phase, the RTL simulator is of course the first choice and is unparalleled. It can quickly compile a design page, with some degree of interactive "what-if" analysis, and with no limited tools, no other tools can match it.

This is true for intellectual property (IP) modules. However, for system integration and system verification testing, software simulation is too slow and impractical in the case of simultaneous testing of hardware and software. Need a data point? We assume that a 100 million equivalent gate ASIC runs at 100 MHz and a design team attempts to simulate its real data for one second. We might as well assume that the simulator is running at 100Hz, which would take 1 million seconds -- 277 hours, or 11 days. In contrast, a hardware emulator running at 1MHz requires only 100 seconds. My assumption ends here.

But this solution is costly, so the simulation data center has emerged and is widely favored by verification engineers. To create a simulation design data center that can serve many verification engineers and software developers around the world, the following three conditions must be met. The system must support:

● Very powerful design capacity and multiple concurrent users

● Remote access

● Resource management

Let's discuss each one in detail.

Meet design capacity and multi-user needs

The design dimensions push the distribution curve up to hundreds of millions of ASIC equivalent gates. In extreme cases, some designs have exceeded 1 billion. Usually, IP blocks reach tens of millions of gates. At the same time, the design team is expanding the number of software developers, which is much larger than the number of hardware designers. In a company with such a diverse design community, a hardware simulation platform with tens of billions of gates and 24/7 operation is required.

At present, the largest hardware simulation platform can provide a capacity limit of several billion gates, enough to create the largest design ever, but still can not meet the needs of a large company. Processing embedded software requires running billions of cycles in sequence. If the speed is 1MHz, it takes 1,000 seconds to run a billion cycles. If a single design consumes all of the simulation resources, the design task will monopolize the entire hardware emulator during runtime, and all other users will not be available during this time. This situation can take hours.

This problem can be solved in two ways. The first method is that the architecture of the hardware emulation platform needs to support multiple concurrent users to share the emulation resources, but it should be noted that no process can monopolize the entire platform capacity. The second method is to build a simulation factory consisting of several hardware simulation platforms. This approach will be favored by simulator vendors.

For example, Mentor Graphics' Veloce2 supports approximately 2 billion gates in its dual Maximus platform for up to 128 simultaneous users. The exact number of users is also related to the design size, and Veloce2 Maximus can support any combination of the above (Figure 1).

Figure 1. Typically, multiple concurrent users have different design capacity requirements.

The hardware architecture of Veloce2 has been redesigned from the ground up to avoid patching together multiple individual chassis. Similar to a computer server, it consists of multiple racks with logic boards, power supplies, and connection backplanes. It also includes Advanced Verification Boards (AVBs), power shelves, and matrix boards that connect the various AVBs with active switches. All in all, the system is stable and reliable. A dual Maximus platform can meet the capacity needs of any company, whether it's a large single design or a batch of users who need multiple design sizes.

remote access

Remote access brings the end of a popular simulation resource configuration model that has dominated the validation field for more than 30 years. In the in-circuit emulator (ICE) mode, the design to be tested (DUT) mapped in the hardware emulator is connected to the target system on which the actual chip is standby.

The target system may include a large number of physical devices. Unfortunately, direct connection is not possible due to the huge gap in processing speed between fast target systems and actual devices, and the relatively slow design within the hardware simulator may be only two or three orders of magnitude.

Basically, a speed adapter is required to connect to allow a high clock frequency chip to adapt to a low clock frequency hardware emulator. The choice of speed adapter should be based on different design and interface types of the target system, such as PCI Express, USB and Ethernet. ICE is very good for actual traffic flow scenario testing, such as verifying that the SATA disk drives included in the design work effectively.

In addition, saving and restoring is also challenging in ICE mode involving physical targets. Suppose the user has a disk drive connected to the DUT mapped in the hardware emulator and tries to save the DUT state. Because the disk drive continues to spin and its state cannot be saved, users cannot perform this task using the built-in capabilities of the hardware emulator.

Remote access makes the hardware emulator a shared resource that can be used by many users and groups in an extremely wide geographical area. Many of them may even be located at the other end of the globe, separated from us by more than a dozen time zones. In order to accomplish this task, the ICE mode requires a team of technicians to continuously and continuously plug and unload speed adapters for each user and each design, which is completely unrealistic.

If ICE can't be implemented, is there any other way to support remote access? The answer is yes. This method is often referred to as "targetless simulation", which uses a software test environment to replace the physical test bench. In the simplest case, it may be based on a synthesizable test platform that eliminates the association with the outside world to achieve full speed simulation.

However, an integrated test platform limits the creativity and flexibility of the designer. On the other hand, non-integrable test platforms, especially those written in hardware verification language (HVL), need to be implemented using a software emulator, and also require a programming interface language (PLI) interface to connect to the hardware emulator running the DUT. . These factors will affect the performance of the platform.

But we can still try to solve this problem.

In the late 1990s, IKOS (acquired by Mentor Graphic in 2002) pioneered the shifting of bit-level interfaces that drive DUTs in test platforms to reusable stand-alone units. Any interface is a synthesizable protocol-based state machine or bus function model.

This approach has two major benefits. First, test programs can be written in a few lines of code at a higher level of abstraction. This makes it easier to write and faster to execute, and the speed of the bus function modules mapped into the hardware emulator is also significantly improved. IKOS refers to the bus function module as transactors and the new simulation mode as co-modeling.

TBX for test platform acceleration is a transaction-based verification model and an emerging industry trend. Users do not need to supervise the plug-in speed adapter when switching between different designs or when new users log in. This model lays the foundation for remote access.

Three emulator vendors -- Cadence Design Systems, Mentor Graphics, Synopsys -- support remote access via a transaction-based approach. A vendor created a virtual verification environment that is equivalent to a virtual lab, similar to a physical lab, but built with virtual appliances. The virtual lab incorporates three technologies: hardware emulation, transaction-based verification, and ICE goals.

A set of virtual devices includes a software stack running on the primary workstation, and the primary workstation communicates with the protocol IP running on the hardware emulator using the transaction executor interface. This bundling brings a protocol solution where the user can verify the IP at the device driver level and validate the DUT with the actual software and device drivers themselves (Figure 2).

Figure 2. USB 3.0 mass storage can be modeled as a virtual peripheral in a simulated environment.

The virtual lab is functionally equivalent to the ICE target solution, but with the removal of the cable and hardware adapters, because the virtual appliance uses the existing verification software IP to communicate with the specific protocol RTL design IP and DUT on the hardware emulator. Virtual devices have the following advantages over hardware ICE targets:

● Easy to use remotely. Because as long as the collaborative module host is installed, the virtual device can be installed without connecting additional hardware to the hardware emulator.

● More flexibility. A single hardware accelerator resource can be shared by multiple design teams because the DUT running on the hardware emulator does not require a cable connection and has fewer partition restrictions.

● The visibility of the target protocol software stack running on the function controller can be defined without specific access to specialized hardware.

● Visibility/traceability of the target protocol function controller core can be defined by simple IP protection of the submitted RTL source code, and the monitor and checker are running to facilitate access to the standard bus.

The virtual environment allows users to debug embedded software through virtual debug interface (JTAG) probes without the need for physical JTAG probes. The advantage of the probe using the JTAG protocol is that it is usually not affected by the slow clock frequency of the hardware emulator. When connecting a physical device to a virtual design running in a hardware emulator, the clock frequency and data frequency need to be reduced to match the speed of the design in the hardware emulator. With virtual JTAG, the hardware emulator can be stopped at any time, and there is no need to worry about interference with the software debugger when the clock frequency changes.

The downside is that the JTAG connection has an impact on the state of the design being debugged. An alternative to JTAG probe technology is to use a trace-based system to enable program debugging running on the hardware emulator. The basic processor tracker provides a list of all events that occur in the processor.

A vendor provides an offline software debugging tool for simulation. This offline software debugging tool is based on a tracker that includes a traditional debugger view of the processor state and performs all symbol table and processor state decoding. Due to the use of tracking technology, it does not affect or interfere with the operation of the system in operation. After the simulation process is completed, it can be run out of the playback database and run at speeds up to 100 MIPS.

Complex resource management

More and more companies developing embedded systems have larger teams of hardware designers and embedded software developers, often located around the world or in different continents. To serve such a business, the hardware emulator platform requires sufficient design capabilities and remote control, but meeting these two requirements is still not enough. There is also an extremely delicate need for advanced resource management.

Any modern simulation system consists of a motherboard that is interconnected by a backplane in the chassis. Multiple chassis are connected and the design capability is expanded to more than one billion gates. To attract development teams, these resources must be managed automatically.

From the early stages of the development cycle to the final system integration and delivery phase, the design team needs to handle a lot of simulation work day and night. Includes IP, subsystem, and hardware-level verification tasks at the entire system level, as well as any form of embedded software verification, from software verification routines to drivers, operating systems, applications, and diagnostics. Some steps require limited capacity, while others require full design capabilities. Moreover, this is only for a single design project. Often, large companies have dozens of design projects at the same time, although only a few projects can eventually be put into production. So the situation is more complicated.

Let's take the example of Mentor Graphics' Veloce2 again. Its fully expanded dual Maximus configuration includes eight Quattro chassis, each containing 16 motherboards. Such a platform can support up to 128 concurrent users. Real-time reallocation of various resources (AVBs) may be required at work. If you want to perform these tasks manually, it will be a nightmare (Figure 3).

Figure 3. Mentor Graphics' Veloce2 Maximus platform can support up to 128 concurrent users.

In addition, to improve efficiency, the resource manager must adopt a job scheduling priority mechanism because some jobs may have higher priority. Platform Computing's Load Sharing Facility (LSF) for job scheduling may be able to schedule work priorities, but the functionality remains to be improved.

And the job priority can change at any time, which makes the situation more complicated. When higher priority work requirements are implemented immediately, there must be a design that supports the “pause/resume” feature to stop the current process at any time (Figure 4).

Figure 4. The Pause/Resume feature queues and prioritizes work.

Compared to a decade ago, the reliability of hardware emulators has been greatly improved, but still can not be called perfect. Because hardware often fails, it is critical to avoid any downtime in the hardware emulator when this happens, otherwise it will affect the final delivery time. The resource manager must isolate the failed motherboard without forcing the design to recompile on the motherboard. It's also important to track the use of hardware emulators, including routine maintenance schedules, operational diagnostics, and reporting results.

in conclusion

Modern simulation-based verification methods require a remote server factory for dozens of hardware and software engineers to validate increasingly complex designs.

To improve efficiency, the hardware emulation server must be designed from the ground up with a modular approach that does not require extensive cable use for capacity expansion. The overall capacity must be sufficient to support the largest design project with transparent management of billions of gates and dozens of concurrent users.

When submitting multiple simulation jobs at the same time, the queuing program should be used to process according to the priority of the work without disturbing the server. Users should avoid the details of work processing and compilation design adjustments caused by hardware dependencies.

The top priority for simulation vendors is to improve the reliability of hardware simulation through fault protection mechanisms. In theory, the simulation server should also be energy-saving and environmentally friendly, and can be adjusted to suit the laboratory environment.