o better ensure the quality of packet-over-Sonet (POS) designs-such as switches and routers--it is important to test the design’s hardware and software content with real network traffic at the system level early in the design cycle. This has historically been a difficult proposition because of the speed differences between POS data streams and the emulator’s run-time performance.

But a new POS emulation solution, offered by Quickturn and Spirent Communications Inc. (Calabasas, Calif.), has solved that problem by delivering verification speeds 1,000 to 10,000 times faster than simulation/acceleration, thus significantly cutting the performance gap. This enables a shorter verification cycle and delivers higher quality products to market faster than ever before.

A key challenge when using emulation to verify a networking design has been the need to interface a network tester’s output, which is used to generate and test real-time networking traffic, to an emulation system, often running up to 1 MHz. While rate adapters have beenused in emulation environments, none had been available to bridge the significant gap between full-speed packet-over-Sonet and emulation-speed POS. This is because there are no flow-control mechanisms for Sonet traffic.

But this new solution, developed by Quickturn and Spirent Communications’ SmartBits division, involved redesigning the tester specifically for emulation output. This was done by stripping out the framer and optical interface, then connecting the slower internal packet interface in the tester to a rate adapter, which directly connects to the emulator.

This enables the transmission and reception of packet streams at emulation speed, while also supporting Layers 2 through 7 protocol testing, and is reconfigurable to support different OC-xx rates. This dramatically reduces the time required to verify a design, making it possible to perform verification with a real-world data stream rather than with a software-based testbench. In addition, this solution provides powerful debugging tools to record any signal within the device under test.

While Internet Protocol historically could not operate at very high speeds or provide quality of service, today’s new POS-based products break the old performance limitations of IP, scaling up from OC-3 to OC-48, with OC-192 and even OC-768 speeds just around the corner. It is essential that developers of new POS products get it right the first time.

The most crucial components are typically custom networking ASICs and network processors that drive POS terabit routers and switches. They require functional testing and hardware/software systems integration to verify their performance prior to tapeout. Larger systems, such as switches that support multiple protocols, including POS, often consist of multiple ASICs with up to 100 million gates. More specialized products typically are based on a single ASIC whose complexity varies from a half million to 10 million gates. The complexity of the verification process is increased by the fact that many of these systems support multiple interfaces and protocols.

Traditional simulation methods have great difficulty meeting all these verification requirements. What’s more, until recently, real silicon was the only way to perform system-level verification. This approach has the substantial advantage of providing real-time performance. But real silicon is costly to manufacture, often requiring several spins for verification purposes, and can take months to deliver. Another disadvantage of real silicon is that it does not provide access to internal nodes, making it difficult to debug the problem.

In-circuit emulation allows designers to quickly create a hardware model of a chip design using proprietary emulation software that maps the design onto reprogrammable circuitry. This approach is faster than traditional software simulation. Emulation speeds are typically on the order of 10,000 to a million times faster than event-driven simulation, making it possible to verify overnight the functionality of designs with 100 million gates. Just as important, emulation produces a functional equivalent of the actual silicon that can be plugged into real boards and run real software.

But emulating a POS design isn’t a simple task. The key challenge is interfacing the emulator with POS data traffic. One solution involves loading files of vector data, such as the input and output data from simulation tools, into the register of the emulated design. The preloaded data in the register is compared with the output when the RTL code is executed. The solution is simple to implement but limited in terms of the testing that can be performed because it eliminates the possibility of stress testing and interfacing with real-world networking traffic.

Another concern is that the preloaded vector data itself may be incorrect. This approach also puts a limitation on the debugging process since designers can debug only at the signal vectors level.

This raises the question: Why not simply interface the emulator with a commercial network tester typically used later in the design process after silicon is delivered?

The problem is that, while emulators are dramatically faster than alternative verification methods, they are still an order of magnitude slower than real-world networking equipment. To perform emulation, engineers must slow down the "real world" to the speed of the emulator. Developers of emulation equipment have created rate adapters to interface and slow down real-time data. To implement this solution, testers must generate packet streams with very low data rates. The rate adapter then converts full-speed POS at a low data rate to emulation speed.

The conceptual architecture, in which the designed test solution interfaces with an external host with application software, is outlined in figure 2. The broad range of standard test suites was originally intended for use at real-world speeds. In the modified emulation version of the tester, the main functionality is in the flexible reprogrammable block, which allows the packet interface to be adapted for different needs. This includes a generation of multiple emulation data rates that represent real-life standard speeds, such as OC-12, OC-48, OC-192, and OC-768.

The ability to reprogram extends to a number of POS-type interfaces, including but not limited to POS-PHY, SPI and Utopia for frame-based systems. As the POS traffic is a fairly recent phenomenon, several standardization bodies have issued their own specifications for the interfaces, raising a need for the adaptation of tester interfaces. Multiple interfaces may be supported through multiple functional blocks; for example, the physical POS test cards may be parallel connected through the emulated design under test. Future standards can be programmed easily into the interface block.

From an end-user perspective, this solution allows users to access application-specific functionality of commercial testers prior to tapeout. Users can execute preconfigured generic software applications with test sets, API programming libraries, and script centers. There is a wealth of features, including test capabilities of OSI layers 2 - 7, performance tests of a POS design under typical or extreme traffic load conditions, and final regression tests.

In addition, designers can test the control plane protocols, analyze the impact of data forwarding, or perform high-load data- plane testing while simultaneously stress-testing routing protocols. Low-layer tests such as sequence tracking per stream, latency-type measurements, frame-check sequences (FCS) and data-integrity validation can also be performed. The type of test capabilities emanating from a tester specifically intended to stress test a certain type of traffic will exceed by many fold the capability of traditional pre-silicon verification methods, such as preloaded memory vectors or interactive testbenches, and will give the designer another point of reference.

Interfacing a proven test instrument to an emulator provides a number of key benefits.

The first is a dramatic reduction in the amount of time required for design verification. Instead of analyzing 60,000 packets in one week, an emulator running at a speed of 1 MHz can accomplish the same task in 20 seconds; in a week it can analyze 1.5 billion packets. It’s worth noting that emulation performance does not degrade with gate size or increased gate activity.

Emulation also provides a powerful hardware-based logic analyzer, consisting of a matrix of switches, that allows for recording any signals in the circuit being emulated, including I/O. In a typical implementation, up to 64 signals can be multiplexed to each logic analyzer pin on the chip, although, of course, the time sequencing required to accomplish this level of multiplexing takes a toll on logic analyzer speed. The user can manage this tradeoff by selecting any number of signals, up to 64, to multiplex through each pin.

The event detectors that are used to trigger the logic analyzer are also built into the silicon, avoiding the need to route the signals outside the chip. At any point in time, emulators can determine the current state of every signal in the entire design being tested. With the built-in logic analyzer, designers can move probes instantly, avoiding lengthy delays. The probe switch matrix can reassign signals to logic analyzer pins at run-time, eliminating what is usually the most time-consuming step of the debugging process --waiting for the recompile to finish. The debug logic is independent of the design and is completely controlled at run-time.

The use of custom FPGAs or processors makes it possible to build in the capability to support "design experiments" that set, force and release any storage element–such as a flip-flop or register– without recompiling. For example, at run-time the flip-flop or register can be initialized to 1 or 0, locked at 1 or 0, or released to its natural state.

During debugging, designers frequently have a hunch what is causing a problem and need a way to confirm it. Usually, the best way is to force signal values to change in the same way the proposed fix would. Instead of adding a gate to turn off a signal at a certain time, you simply run the emulator to that point and force the signal to zero to see whether that really fixes the problem. Another use for the design experiment capability is to block an area of the circuit with a bug, before fixing it, so other areas can be debugged.