Quickly Tracking Bugs as Embedded Software’s Importance In SoC Grows

Enhancing data center network security and packet transmission features has contributed to a rising gate count for networking SoCs, but even in the face of growing complexity, market windows can’t be missed

Source: EECatalog

In the contest for the most complex and largest chips on the market today, the mighty networking chip shares the crown with multicore microprocessors that include integrated graphics.

A single networking system on chip (SoC) integrates all the various components of a router or Ethernet switch and measures half a billion or more application specific integrated circuit (ASIC)-equivalent gates due to more ports, expanded throughput and decreased latency. Improvements to a data center’s network security add to the gate count, as do enhancements to packet transmission features. Redundancy and resiliency to minimize performance degradation because of network congestion, failures and resource exhaustion during maximum utilization, top the list of added functionality and increased complexity.

Getting specialized chips like these to market on time and within a tight budget takes monumental effort and a laser focus on debugging to verify that they will work as specified. No company can afford a mistake for a costly silicon respin that could cause a missed time-to-market opportunity.

What No Other Verification Tool Can Do

To avoid this catastrophe, engineering teams rely on a cadre of verification tools, though the emerging winner in this pageant is hardware emulation with four to five orders of magnitude faster performance than hardware description language (HDL) simulators. Hardware emulation can hunt a bug across the embedded software –– a huge benefit as embedded software’s importance in an SoC grows––and across the underlying hardware, something no other verification tool can do.

Its bandwidth can manage Ethernet traffic in and out of the design-under-test (DUT) at several million packets per minute in a 1k Ethernet switch. Comparatively, a simulator’s bandwidth is about 1,000 packets per day.

Recently, hardware emulation was used to debug an Ethernet switch SoC design with a 128-port interface and a variable bandwidth of 1/10/40/100/120Gbps. The design was close to 700-million ASIC-equivalent gates, which eliminated the use of an HDL simulator. It wasn’t just simulation time, known to be excessively long to the point of being impractical, but also compile time reaching into five hours. Consider that configuring the design in simulation would add another 18 hours and simulation time for one packet of data yet another two hours. Therefore, a simulation farm with several hundred PCs would reach a maximum throughput of about 1,000 packets per day. The project team’s goal was several million packets per day for debug.

Figure 1: Here’s how an ICE-based emulation of an Ethernet switch SoC design with a 128-port interface and a variable bandwidth of 1/10/40/100/120Gbps would be configured.

Hardware emulation was an easy choice. The hardware emulator was used in a virtual mode, a way to test a design with real traffic, to handle multiple users in an enterprise-wide environment. It replaced a physical target system to generate and process real data to and from the DUT through a functionally equivalent software-based test environment. It accomplished the same operations at the same speed as the often-used in-circuit emulation (ICE) mode.

Normally, ICE mode would be deployed because it can test the DUT with real-world traffic and would need one Ethernet tester per port. For this particular design with 128 ports, it would require 128 Ethernet testers. But a direct connection between Ethernet traffic, clocked at gigahertz speed, and a hardware emulation platform that hits one or few megahertz was not possible. To compensate, a speed-rate adapter, or FIFO, would need to be inserted between them to accommodate the tester’s fast speed and the emulator’s low speed. This would add 128 Ethernet speed adapters and extra cables.

The physical setup, as complex as it is, was one of a few drawbacks. The random nature of the real world makes the ICE mode testing environment unpredictable. Bugs show up at different time stamps or not at all in subsequent runs. An inefficient option to be sure. With ICE, only one user at a time can use the hardware emulator, and that individual must be local in order to access it. Remote access would be impractical since it would require someone manually connecting the 128 Ethernet testers to the 128 Ethernet speed-rate adapters, and these to the emulator. When a new user with different setup requirements would login, all those testers, adapters and cables would have to be disconnected and the new setup put in place.

Instead, the virtual approach chosen by the project team moved away from the ICE mode and guaranteed predictability for finding a bug by repeatedly running an emulation session. 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 IP.

The virtual tester included an Ethernet Packet Generator and Monitor (EPGM) that generated, transmitted and monitored Ethernet packets with the DUT. It is able to support up to 64 GMII, XGMII, XLGMII/CGMII, CXGMII, CCMII and CDMII ports per workstation for 1G, 10G, 25G, 40G, 50G 100G, 120G, 200G and 400G respectively. The software performed off-line analysis of the traffic, provided statistics and supported other functions. The interface between the virtual tester and the DUT included one instance of a SystemVerilog interface communicating to a Virtual Ethernet xRTL (extended Register Transfer Level) transactor hooked up to a Null-PHY connected to the DUT. One xRTL transactor was required for each port of any xMII supported type.

Multiple EPGMs were bundled together across multiple workstations to support large port count configurations. High Speed Link (HSL) cards were used to connect co-model channels from workstations to the emulator for configuring a system for best performance, capacity or usability.

Figure 2: A virtual-based emulation of an Ethernet switch SoC design with a 128-port interface and a variable bandwidth of 1/10/40/100/120Gbps would be configured in this manner.


A virtual setup was ideal for this project team to establish an emulation data center as an enterprise-wide emulation resource. It could support multi-concurrent users, essential in backing up a large software-development team such as this one.

Results of this debug effort were impressive. The hardware emulator configured the design in 10 minutes instead 18 hours in HDL simulation and processed 3.5 million packets per minute on 32-ports, instead of one packet per port in two hours.

Hardware emulation has become the core of many verification strategies, as proven by the project team designing a complex Ethernet switch and router. They found a practical solution that serves the entire enterprise.

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.