Hardware Emulation to Debug Networking Chips

Networking chips are among the most complex and largest on the market. It's a good bet, then, that the chips powering the most sophisticated networks around were debugged with hardware emulation. A further bet would be that they had bug-free tape out and first-silicon success.

Content Dam Lw Online Articles 2016 07 Lauro Rizzatti Figure 2 2

Designing and verifying integrated circuits (ICs) may be the hardest and most difficult piece of the puzzle when it comes to producing electronics devices, whether they are targeted for consumer use or to drive the network. Engineering teams devise all sorts of verification procedures and strategies to ensure first-silicon success.

Networking chips are among the most complex and largest on the market. Ethernet switch chips routinely measure 500 million or more application specific IC (ASIC)-equivalent gates through the use of ports and for expanded throughput and decreased latency. Improvements to a data center's network security increase the gate count, as do enhancements to packet transmission features.

On the verification side, one tool is emerging as the most thorough and versatile of all: the hardware emulator, a 30-year old finding richly deserved widespread acceptance. Engineering teams especially like its ability to debug and functionally verify both the hardware design and the embedded software, a benefit no other verification tool can claim. Additionally, it has four to five orders of magnitude better performance than hardware description language (HDL) simulators, the longtime go-to debugging tool.

Pricing is more competitive, too. At a price of more than $10 per gate in the 1980s, only high-end graphics and processor engineering teams could justify the cost. Hardware emulators are now priced at less than one cent per gate.

It's a good bet, then, that the chips powering the most sophisticated networks around were debugged with hardware emulation. A further bet would be that they had bug-free tape out and first-silicon success.

Applying hardware emulation

Simply put, hardware emulation mimics the behavior of the design under test (DUT). A stimulus is applied to the DUT mapped inside the emulator, and the emulator processes the DUT's response to validate the design will work as intended. Hardware emulation can manage Ethernet traffic in and out of the DUT at more than 1 million packets per minute in a 1-TB Ethernet switch, while a hardware description language (HDL) simulator has the bandwidth for about 1,000 packets per day.

One long-used mode for debugging chips is in-circuit emulation (ICE), where a physical target system drives the DUT in the emulator via speed adapters. Another, transaction-based emulation or acceleration mode, works with a virtual target system that runs the DUT in the emulator through verification intellectual property (VIP). Simulation testbench acceleration mode uses a register transfer level (RTL) testbench to drive the DUT in the emulator via a program language interface (PLI). Yet another, embedded software acceleration mode, is suitable for system-on chip (SoC) design and enables software code to execute on the DUT processor in the emulator. In some cases, engineering teams mix modes –– processing embedded software with a virtual testbench driving the DUT through VIP, for example.

An example of hardware emulation

Not long ago, an engineering team used hardware emulation to debug and functionally verify a 700 million ASIC-equivalent gate Ethernet switch SoC design with a 128-port interface and a variable bandwidth of 1/10/40/100/120 Gbps.

Hardware emulation was selected over an HDL simulator for a variety of reasons, including long simulation runs and an estimated 18 hours to configure the design for simulation. A simulation run for one packet of data would add an additional two hours or about 1,000 packets per day in a simulation farm, an unacceptable number when the goal was more than a million packets per day.

Team members, both hardware designers and software developers, chose the transaction-based emulation mode to be able to test the design with real traffic. They wrote tests at high levels of abstraction in the SystemVerilog language that were converted from high-level commands to bit-level signals as VIP, synthesizable state-machine functional blocks that implement interface protocols.

Because VIP is controlled by software, the engineering team built a smart, flexible, and reusable verification environment. Off-the-shelf VIP is available for communication protocols such as Ethernet, USB, PCIe, memory accesses, JTAG ports, digital cameras, and LCDs.

The engineering team selected the transaction-based emulation mode versus the ICE mode. ICE is popular because it can test the DUT with real-world traffic, but was impractical in this application for several reasons. The design had 128 ports, which meant 128 Ethernet testers. ICE would need one Ethernet tester per port, making a direct connection between Ethernet traffic at gigahertz speed and hardware emulation at several megahertz unmanageable (see Figure 1). To accommodate ICE mode, a FIFO or speed-rate adapter also would have been inserted to adjust the tester's fast speed to the low speed of the hardware emulator, adding 128 Ethernet speed adapters and extra cables.

Lauro Rizzatti Figure 1
Figure 1. Using ICE to debug and functionally verify a 128-port, 1/10/40/100/120-Gbps Ethernet switch would require 128 Ethernet testers or one Ethernet tester and one speed-rate adapter per port, adding 128 Ethernet speed adapters and extra cables.

Moreover, the random nature of the real world would make the ICE mode testing environment unpredictable, as bugs show up at different time stamps or not at all in ensuing runs. Only one local user at a time could use the hardware emulator as remote access would require someone manually connecting the 128 Ethernet testers to the 128 Ethernet speed-rate adapters and then to the emulator. When a new user with different setup requirements would log in, all those testers, adapters, and cables would have to be disconnected and the new setup put in place.

The transaction-based emulation mode offered increased predictability for finding a bug by repeatedly running emulation (Figure 2). Ethernet testers were modeled in software running under Linux on a workstation connected to the emulator. The model was an accurate representation of the actual physical tester, based on production-proven VIP. A virtual tester included an Ethernet Packet Generator and Monitor (EPGM) that generated, transmitted, and monitored Ethernet packets within the DUT.

Content Dam Lw Online Articles 2016 07 Lauro Rizzatti Figure 2 2
Figure 2. The engineering team used the transaction-based emulation mode to debug and functionally verify the design of an Ethernet switch SoC with a 128-port interface and a variable bandwidth of 1/10/40/100/120 Gbps.

Perhaps equally as important, the engineering team was able to expand hardware emulation into an enterprise-wide emulation resource to support multiple concurrent users possibly residing in different time-zones all over the globe, a cost-effective solution for the budget-conscious engineering department. Some time-to-market pressures were relieved as well, as verification engineers around the globe were continuously debugging the design.

The engineering team was pleased once it analyzed the final results after first-silicon success. The hardware emulator configured the SoC design in 10 minutes and processed 3.5-million packets per minute on 32 ports. The network chip is in volume production and the hardware emulator is hard at work debugging and functionally verifying the next design.

Dr. Lauro Rizzatti is a verification consultant and industry expert on hardware emulation. Previously, Dr. Rizzatti held positions in management, product marketing, technical marketing, and engineering.

More in Design & Manufacturing