Putting Co-Verification to Work: Ascend Communications Relies on Seamless from Mentor Graphics to Quickly Bring a Switch Design to Market

by Jamie Pierce

Principal hardware engineer, Ascend Communications

At Ascend Communications, our designs are targeted at the demanding networking business. We provide solutions that span the access, edge and core layers of the wide area network (WAN). My division, Core Switching, produces frame relay and ATM switches used by long-distance and local exchange carriers, or Internet service providers (ISPs).

Designing for these markets is quite challenging. Not only are these products extremely complex—incorporating multiple sophisticated processors—but they must be completed on compressed schedules to ensure we make the most of extremely short market windows.

Creating a cutting-edge networking application on a tight schedule doesn’t leave much room for error. The more we can verify up front the better. To more effectively deal with the pressures and demands of designing these advanced applications, we recently decided to adopt a co-verification strategy using Mentor Graphics’ Seamless Co- Verification Environment (CVE)™.

Why Co-Verify

In most designs, especially those with 16- or 32-bit microprocessors, the real software and integration debugging can only begin after the hardware is built and prototyped. True, a hardware simulator can be used earlier in the design cycle for system debug, but it usually isn’t much help. With a typical throughput of 10 instructions per second, a simulator is much too slow to generate meaningful performance data.

Consequently, the only alternative for system integration is to wait for the hardware prototype. However, delaying integration that long usually doesn’t give the design team enough time to adequately address the numerous performance issues that usually surface. Fearful of missing critical delivery dates, the team often fixes hardware problems in the software. Unfortunately, only so much can be done in software and these types of fixes often result in compromised functionality or reduced performance.

Co-verification is a new approach that enables designers to integrate and examine system performance before the hardware is a physical reality. It creates an integration environment that runs the software on a virtual prototype of the hardware. As a result, large amounts of software can now be verified before hardware prototype.

Using co-verification, the design team can uncover system problems much earlier in the design cycle, when the software and hardware components are still fluid and easily modified. Issues can be quickly addressed, sometimes cutting the lengthy integration task in half. Just as importantly, the number of expensive and time-consuming design iterations can be reduced. This is especially compelling for designs that include large ASICs. Co-verification will reveal limitations in an ASIC design before fabrication, eliminating one or maybe even more turns.

In addition, designers have a much greater level of visibility into the inner workings of the application using co-verification than can be obtained with a real prototype. All aspects of the system’s performance can be exhaustively explored in detail and from every possible angle. The team can also quickly perform what-if scenarios, since the hardware and software descriptions can be readily modified and the virtual prototype updated and re-simulated. The overall result is dramatically reduced integration and test times without compromising system performance.

How It Works

To create a virtual prototype for simulation, a co-verification environment closely weaves together the debug and development environments for the hardware and software. It carefully synchronizes the software and hardware simulators and provides system-wide debug features such as setting breakpoints in both the software and hardware domains.

Just as importantly, to deliver the requisite hardware simulation throughput needed to support software execution, it sustains execution speeds at least a thousand times faster than traditional simulation products. For example, compared to the 1 to 5 instructions per second achieved with today’s logic simulation, Seamless ran as fast as 20,000 instructions per second.

Seamless achieves its remarkable efficiency with a number of patented optimization techniques that speed co-simulation by reducing the load of software operations on the logic simulator. One such innovation is a memory image server that can process general system operations—such as instruction fetch and memory read/writes—10,000 times faster than a logic simulator. As a result, designers can trade off between resolution and performance without sacrificing accuracy. The tool does this by maintaining accurate time synchronization and data coherence between the two domains, while also reducing the activity that flows between them.

The Decision to Co-Verify

We decided to try co-verification over a year ago, when one of our design teams was developing new frame and IP switching cards for our multi-service CBX 500 ATM switch. This design incorporates five processors as well as numerous FPGAs and memory. What made it particularly challenging was the fact we were incorporating a new processor type for frame traffic management, Motorola’s PowerPC 603. This processor had to interface with the I960s from Intel—a processor we had used extensively before.

As everyone knows, the first time through with a different processor is never an easy task. We wanted to reuse as much software and hardware as possible, but it was necessary to create a sizable amount of new code for the PowerPC 603. We also anticipated having to iron out a fair number of code and interface issues between the different processors. But being on a very tight schedule, we couldn’t afford the risk of tracking down all the problems during the prototype stage.

To streamline the overall system integration, the software team wanted to test the boot-ROM code before the actual hardware was ready. That required booting an I960 that would then load shared memory with the boot code for the PowerPC 603. With the boot code loaded, the team could then fully test and debug the power-up hardware diagnostics along with the detailed hardware diagnostics, all before system integration. Testing this code before hardware was available required a virtual prototype to co-verify a portion of the hardware and software design.

After evaluating several different co-verification environments, we selected Mentor Graphics’ Seamless for two reasons. First, Seamless did not require that the software engineers modify their code for the simulation. Our engineers had enough work to do without having to worry about tailoring the software for the co-verification. And second, we were also impressed with Mentor Graphics’ support infrastructure, including their extensive library of simulation models.

Paradigm Shift

This being our first attempt at co-verification, combined with the fact that co-verification is a new concept, we had to make some interesting adjustments—some expected and others not—in our design flow and practices.

Our simulation environment was composed of a motherboard design with daughter cards, all represented by a hierarchical Verilog netlist. It also included Verilog-XL for hardware simulation and a mix of internal and third-party models. Seamless simulated this subsystem by integrating software and hardware simulation and debug tools. It incorporated Microtec’s XRAY-Sim™ for software simulation and debug.

The first and most fundamental shift was bringing the hardware, software and diagnostic teams together much earlier in the design cycle than we had in the past. Overall, working together as a systems team early in the project was a big benefit. The active participation of all the groups moved us beyond the functional specification to actual daily, detailed interaction. This helped eliminate misunderstandings between the different teams at a point where it was much easier to make adjustments.

One aspect of working together that caused us to change how we do things was putting together a diagnostic team much earlier than usual. Typically, that team is brought on board closer to the time when the prototype is scheduled to arrive. As our diagnostic people were not planning on working on this project for another few months, we had to adjust to get the engineers in place. Going forward, we now schedule our resources differently to accommodate this shift.

The first concrete action item in our co-verification was the preparation by the hardware engineers of the hardware description for the simulator. This involved another change in perspective. Our engineers have done extensive board-level simulation, including multiple boards tied together, but this type of simulation was different. Starting with the Verilog netlist, they had to flesh out every detail to ensure the co-verification would predict the actual performance. In board-level simulations, portions of the board design had been left out because their performance was already verified. But for co-verification, the hardware team had to describe each and every piece of the board to support the merging of software and hardware simulation. This forced our engineers to reorganize their priorities, as they found pieces that were missing from the model. Although this part took more time than expected, it helped us to tighten up our methodology and enforced thoroughness.

Once the hardware description was accomplished, we passed the virtual prototype over to the software and diagnostic engineers. The five members of that team then ran boot code, power-up diagnostics and the detailed diagnostics. The software team was intensely interested in tracking the interaction between the I960 and PowerPC 603, especially since there is an endian difference between the two processors. They were concerned there would be byte swapping or endian misunderstanding. The diagnostic and firmware engineers, on the other hand, wanted to test out their firmware as this was the first time they were writing for the PowerPC 603.

One adjustment made by the software and diagnostic engineers was acclimating use to the thoroughness of the simulation. Accustomed to quickly executing code on their workstations or running it on the actual hardware, they were surprised at the time needed to co-verify. The hardware team, in contrast, was used to this type of simulation and actually thought the co-verification throughput was quite good. The co-verification also used more computing resources than anticipated, requiring 150 MB or more, depending on the size of the netlist.

Impressive Results

By the time the code checkout was complete a significant number of design errors had been isolated and corrected—24 software errors and five hardware errors to be exact! For example, some of the hardware problems uncovered by Seamless revealed that the data bus released too soon when accessing the UART, and the I/O region strobed twice on write cycles. What’s more, the wrong section of the data bus was latched by the memory mapped device. A request signal was also generated incorrectly. Catching these problems early on enabled the hardware team to modify the motherboard while it was still in design, without seriously impacting the design schedule.

There was one problem in particular that would have definitely required a board turn if it had been discovered during hardware prototype—the boot PROM interface did not match the reset configuration of one of the processors. One of the processors in the design read eight bytes at reset. But the original boot PROM interface provided only one byte. To remedy the incompatibility, an eight-byte buffer was added to the board. This was easy enough to do since the board was still in layout. But it would have been a painful, time-consuming task if the board had already been prototyped.

Besides saving the design team a costly board turn, the long-term results of using Seamless were impressive. The diagnostics were ready when the hardware went to the lab. Once in the lab, the board came up quickly with no errors—hardware or software—in the portion of the design validated with co-verification. As a result, the customer was able to avoid a lengthy prototype turn and get through system integration significantly ahead of schedule.

Co-Verification Converts

Our experience in using co-verification was extremely positive. It definitely accelerated the process of successfully completing this demanding design, minimizing the impact of incorporating a new processor. Although there were some aspects that we did not anticipate, those were to be expected with a change in design practices of this magnitude. We are convinced of the effectiveness of co-verification, and plan to use it in future switch designs. As we move forward, our development schedules and plans will take co-verification into account in terms of the hardware simulation model, engineering power and compute resources.

Sidebar: Co-Verification Considerations

When making a decision to adopt co-verification, keep these things in mind:

Pick a solution that:

• requires no changes to the hardware or software
• has the requisite throughput and performance
• supports a large range of models
• has an established and seasoned support staff
• works with a heterogeneous mix of EDA tools

Expect these changes in design practices:

• assembling the software team much earlier in the design cycle
• creating a complete, detailed hardware simulation
• allocating more memory resources to support co-verification