Hughes Network Systems Accelerates Time-to-Market of a Next-Generation Satellite Packet Processor

Niklas Molin, Firmware Design Engineer Joe Zanotelli, Senior Technical Manager of VLSI Jingxing Yue, ASIC Hardware Design Engineer Shuqing Zhao, ASIC Verification Engineer Hughes Network Systems

Introduction

This paper details an effort to verify a broadband-over-satellite ground communications terminal. The total size of the ASIC was seven million gates, including six Tensilica? Xtensa? configurable processor cores. Our design team focused on the packet processor in the downlink channel, which was comprised of one Xtensa and approximately 500,000 logic gates. To verify and debug the RTL code we developed for the packet processor, we used the Seamless? hardware/software co-verification environment from Mentor Graphics? and Specman Elite? from Verisity? for automated testbenching.

Project Goals

The primary goal was to fully verify the functionality and accuracy of the downlink channel prior to tape-out of the ASIC. We implemented the functionality that constitutes the channel in both hardware and firmware, necessitating the co-simulation of the two domains. We also wanted a real-world test of the channel, requiring a sophisticated packet generator that could mimic the structure and mix of the packets expected from the satellite. By simulating the downlink channel's complete functionality and applying a realistic stream of packets, we hoped to avoid lengthy debug of the physical ASIC and eliminate costly respins.

Ground Terminal ASIC Overview

The ASIC consisted of ten functional blocks connected via an on-chip, 128-bit Sonics backplane. The main datapath consisted of three blocks, each with its own Xtensa core: the uplink channel, downlink channel, and SSC router/switch. The other three Xtensa cores were dedicated to handling exceptions and higher-level protocols. The ASIC also contained PCI and Ethernet interfaces. The uplink and downlink channels had a raw data rate of approximately 400 megabits, resulting in a user data rate in the tens of megabits range.

Downlink Packet Processor Architecture

The design of the packet processor was based on a four-stage pipeline consisting of interleaved hardware and software functions. This was a major reason for using co-verification, as we could not simulate the complete pipeline without it. The Cyclic Redundancy Check (CRC) and encryption/decryption functions were implemented in hardware. We created and ran firmware on one of the Xtensa cores to perform packet segmentation and reassembly. The packet processor could handle thousands of frames in parallel. Two frames were held in local memory at any given time, with the remainder stored in external SDRAM. Search-tree hardware sped the retrieval of packets for processing by the four-stage pipeline.

Speeding Simulation with Seamless Memory Optimizations

The packets were generated by Verisity's Specman Elite and applied to the design as it was simulated using Seamless. To speed software execution, access to the instruction and data RAMs was optimized using the Seamless Coherent Memory Server. This enabled us to process over 1300 packets in less than 30 minutes.

Design Errors Exposed by Co-Verification

Hardware/software co-verification provided a level of visibility into our design that enabled us to debug an external bus controller error that we would not have found otherwise. The de-queuer bus bandwidth was too low, causing the hardware buffers to back-up and overflow because the CPU dominated the bus. While this could have been detected with RTL simulation, it would have taken too long to debug. The hardware and firmware teams typically toss a problem like this over the wall several times before it gets resolved, with each toss consuming about two weeks. Using RTL simulation, we would have run out of time before conclusively isolating the cause of the error, forcing us to make assumptions in order to make tape-out. With Seamless, our hardware and firmware engineers literally sat at the same workstation and were able to debug and correct the problem in a matter of hours. When the ASIC taped out, we were certain that the problem was fixed and the ASIC was production-ready.

We also discovered that a hand-off on the initialization of an encryption register was not occurring. Instead, in the middle of doing a calculation, our firmware would initialize a register. Debugging the search engine firmware would have been almost impossible without a software debugger. On the other hand, debugging these problems in the physical system-on-chip (SoC) would have been just as impossible due to lack of visibility into the hardware. Seamless provided excellent debug visibility early in the design flow, allowing us to debug the error using its software debugger and a virtual prototype of the hardware.

Another hardware problem was discovered in our hardware decryption engine, but it was too close to tape-out to fix. Seamless not only discovered the problem but also enabled us to develop and verify a firmware workaround before the chip came back. Using Seamless, we validated that sending an empty packet cleared the error.

Packet Generation with Specman Elite

Verification of the downlink packet processor was another big challenge, because the processor received many different types and sizes of packets and frames. This would be almost impossible to verify using a traditional tool because those tools can handle only a very limited subset of all possible packets and subsystems. We used Specman Elite because it handles behavior of this complexity while expanding functional coverage metrics. We ran Specman Elite dynamically, generating packets based on the software configuration of the chip. This was only possible due to the tight integration of Specman Elite with Seamless. By linking Specman Elite with Seamless, we could easily see what type of packet was generated and trace the packet through hardware, software, and back.

We used Verisity's e verification language to describe the packet and frame structure and to generate the packets and frames. We generated 1000-2000 packets and 200 frames. The frame size varied from 1 to 20 packets - 10 times what we were able to do with our previous C-based packet generator. With the C environment, it took two people - one hardware engineer and one software engineer - a month to create the generator, which still had significant limitations. With Specman Elite, this only took five days, and we even found a design error that was missed using the C generator.

Specman Elite enabled us to take advantage of verification reuse. We wrote an e testbench for a sub-block and then reused it at the block level. Then we reused the block-level testbench for the system-level tests.

We also found bugs that might not have been found using other verification environments. For example, we put a CRC into a packet that fully exposed a problem in both our firmware and hardware. Specman Elite overloaded the packet only to discover that the satellite dropped the packet. We hadn't thought to test for this particular problem. Specman Elite flushed out the problem and Seamless made it easy to debug. If we had waited until the chip came back, it would have taken a month to debug the problem with a team of 30 people waiting around, only to learn the chip had to be respun.

Conclusions

The primary value of co-verification proved to be its hardware/software debug capability. This class of interface problem has historically taken weeks to resolve with many over-the-wall iterations between the hardware and software teams. A hardware and firmware engineer were able to isolate and fix these errors in an hour or two by sitting down together and running Seamless.

Because of its speed and its ability to co-simulate hardware and software, Seamless allowed us to validate more of the design. As a result, we had a high degree of confidence that we were taping out a working design. Seamless exposed hardware errors in the RTL code we developed that were not detected by logic simulation. Without Seamless, we would have been forced by schedule constraints to tape-out without this level of confidence and hope for the best. In this case, we would have had to respin the ASIC.

Specman Elite's random packet generation proved extremely valuable as well. Specman Elite generated a wider range of packets, with less effort, than our home-built generator, exposing a design error that would have resulted in dropped packets in the ASIC. Specman Elite increased the number of packets we were able to verify by 10X. It also found bugs that we could not have found otherwise.

The combination of Seamless and Specman Elite was exceptionally flexible and extremely powerful in finding errors. We were able to isolate and fix all the errors, resulting in first pass success with our silicon. Based on our experience, we will be using this combination of tools on future projects.