What software is used for the ASIC design

Hardware emulation accelerates the design of network ASICs

The advanced simulation for network ASICs slows down the entire design process. In the past, Cisco used its own verification concept for each new IC. To save effort and time, the company worked closely with its supplier, Mentor Graphics, to standardize a method that could be applied to multiple designs.

The switch to a standardized emulation approach was particularly beneficial for the bring-up process for large chips and systems. The core ASIC team at Cisco deals, among other things, with ASIC applications for switching networks in companies and universities. The Catalyst 9000 series is one of the most successful product lines from Cisco.

The team uses the emulation to identify hard-to-find deep cycle errors. Without emulation, such errors are ultimately implemented in the silicon - and then troubleshooting becomes extremely costly. The set goal is to detect all errors by emulation and to achieve one hundred percent coverage before tape-out by combining formal verification simulation and hardware emulation. If this goal is achieved, the time-to-market will be reduced.

Performance testing challenges

The challenges start with the performance tests of bandwidth and latency, as these cause long simulation runtimes. Because development and runtimes are far too long, it is difficult to check interactions between several chips in complex systems with a simulation. As the interfaces continue to evolve, the design verification teams have spent a lot of time developing drivers and monitoring functions. Some network protocols, such as PTP 1588, Link Pause and Priority Flow Control (PFC), are very simulation-intensive, which means that the runtimes for a final result are extremely long.

Network ASICs tend to be complex designs, which means more time is required for code and functional coverage. In addition, the verification of the new network standards requires additional test bench components. Ultimately, the co-verification of hardware and software is also a challenge, in which the actual software runs on the hardware before tape-out.

Simulation is essential for block level verification and basic integration testing. However, as the size of the design increases, the simulation performance deteriorates, especially in systems with multiple ASICs. A simulation is not enough to master the challenges.

Background to the verification process

There are a few terms that need to be defined in connection with the verification process. The terms backdoor and frontdoor initialization indicate how the content is loaded or extracted from memory. A frontdoor flow means that the data about the design is loaded into memory and moved out of memory. A backdoor flow means that data is loaded into and moved out of the memory not via the design, but via a test bench or software. Test engineers often want to pre-load data into memory or extract it from memory at the end or during a test run. A backdoor flow is often used for this.

Cisco uses backdoor initialization for simulation in more than 90 percent of all tests. Front door verification is not ideal for simulation. Front door initialization is necessary when the software configures the ASIC and runs production software.

Veloce emulation environment

EckDaten

Optimized emulation helps design teams achieve a high level of reliability before tape-out of the network ASICs. Completing the software before the silicon bring-up is a great advantage. As a rule, the time-to-market can be significantly shortened with an emulation. For Cisco, emulation through left-shift is a very good addition to the verification strategy. A quick bring-up, a sophisticated compilation and complete transparency are decisive here.

To cope with these ASIC design requirements, Cisco verification engineers introduced the Veloce2 emulator from Mentor Graphics. The emulation runs a thousand times faster than the simulation and the runtime does not deteriorate with increasing design size.

Unlike an FPGA system, the Veloce-based emulation environment offers complete transparency when debugging. Compiling and executing individual steps works in a similar way to simulation; therefore, it is very easy to use. For example, many verification components, especially scoreboards, checkers and functional cover points, can be reused in the emulation.

The simulation is used for the design bring-up. The multi-unit-level verification in the simulation alone is a good approach to bring the first packets to the chip level. The emulation helps to find deep cycle errors that would otherwise only take a lot of time to identify, as well as when executing real software, performing chip-level performance tests and verifying at the system level. The emulation is also useful for line rate tests, for flow control and Internet mix tests (IMIX). In the emulation, pause and data path tests as well as load balancing can be carried out efficiently.

Functional verification

With regard to functional verification, Cisco has implemented a number of important points. A test bench for the front door initialization was developed. Cisco ported all of its C ++ / SystemC checkers and the simulation checks, including the real-time checks, to the emulator. The Ethernet Packet Generator Monitor (EPGM) from Mentor is also used to generate Ethernet and various other packets.

The workflows that Cisco implemented to create the design include:

  • Select a model from the model library with the specifications of the memory model that was selected for the tape-out.
  • TCAM, SRAM models must be synthesized to those supported by Veloce2.
  • minimal adjustments in timing and PLL
  • Identify parts of the design that are not being emulated, such as design-for-test logic (DFT). Certain parts can be ignored by configuration by the compiler and are omitted for the emulator.

The topics of the test bench include:

  • Creation of a suitable Transactor for Veloce for the configuration of the ASICs
  • Use of the EPGM to send and analyze the Ethernet packets
  • Creation of checks for the end of the simulation in SystemC and C ++
  • Synthesize the functional coverage for the emulator

The most important functions for debugging the design are:

  • EPGM analysis window
  • Transactor trigger for signal acquisition
  • other custom trigger for signal generation
  • Hardware-implemented assertions and monitoring functions that can be generated. These critical assertions are exceptions that have been thrown and can automatically generate signals for debugging.
  • full signal uploads

Virtual solution for network ASICs

Cisco worked with Mentor for several years on EPGM, a virtual solution for network ASICs. This supports multicore models and offers scalable performance. It has a TCL-based interface with which complex test cases and predefined triggers for signal acquisition can be created quickly. EPGM recently added a Mutable Port Group, which is a super port mode that allows a single build to support multiple port modes. This eliminates the need to create multiple builds for all possible configurations of the chip.

During the debugging analysis, users receive statistics for each stream, for example the EPGM records and outputs the bandwidth, latency, all frames and all errors (out-of-sequence, CRC and preamble errors). In addition, custom checkers and rate monitors are implemented in the ASIC.

The acceleration of the simulation can vary depending on the size of the ASIC and the application. A simulation with front door initialization takes about 6000 minutes. With the emulation, the simulation could be shortened to 30 minutes. With complex ASICs tens of thousands of front door writes run. With an optimized flow using Mentors Inbound Streaming, it takes less than five minutes. The simulation alone would normally take several days.

With this runtime performance, Cisco can process 40 packets per minute in a simulation for a specific configuration. More than 600,000 packages per minute are possible in an emulation - that's 15,000 times faster than with a simulation.

Transferring experience to other tasks

The knowledge acquired can also be used for other verification tasks. The topics of pre-silicon software development, multi-chip system verification and the usability of silicon and pre-silicon power analysis are of particular interest here. For example, users can now boot the unchanged operating system during pre-silicon software development and run applications on the actual ASIC before tape-out. This application is particularly beneficial for diagnostic and system software teams.

It was important for Cisco to develop and validate diagnostic software that would be used prior to tape-out. Likewise, new verification functions had to be validated in hardware with the latest system software before the tape-out. The diagnostic, kernel and application software teams can now quickly start debugging thanks to the emulation platform.

Multi-chip verification is another area of ‚Äč‚Äčapplication. Complex, modular systems have supervisor and line cards with multiple ASICs that communicate with each other. These are scalable systems and trying to verify them in a simulation is a big challenge.

Bringing up the silicon and making it usable are also possible applications. When the chip comes back, the team runs several tests and an ASIC qualification to validate the silicon. When the silicon is back in the laboratory, the emulation immediately offers a head start. Presilicon power analysis is an area supported by Mentor that Veloce user Cisco is currently investigating in more detail.

Future verification flows should standardize the regression and coverage analysis. Such a process requires some changes to the standard functional coverage flow, where coverage is to be synthesized and mapped in the design.