Security Chip Design Speeds on to Silicon

Security Chip Design Speeds on to Silicon
By Hemanshu Bhatnagar, Neel Das and Satish Anand, Integrated System Design
March 1, 2002 (12:33 p.m. EST)
URL: http://www.eetimes.com/story/OEG20020227S0055

When we founded our company in September 2000, existing ASIC solutions were not keeping pace with the Internet infrastructure buildout, causing a performance bottleneck. So Corrent set out to deliver the fastest Internet Protocol security accelerator in the market. Our goal was to build a design of 7 million gates or more in less than a year. Funding and market dynamics dictated that we execute on time, first time. We had one shot to make it happen.

We were able to deliver a 2.2 million-instance design with the ability to accelerate Internet Protocol Security (IPsec) and Secure Socket Layer (SSL) at gigabit speeds, 14 months from conception.

This article describes the philosophy Corrent adopted and how it was translated into a working flow in such a short time. Specific examples of challenges and workarounds are discussed. Large hierarchical designs like Corrent's present unique challenges to integration, and some of these issues are discussed.

Our first challenge was to quickly find talent with the broad set of necessary skills to implement a quality design. We then focused on putting a methodology in place that everyone would buy into and execute on.

Early on we decided to go with a customer-owned tooling (COT) flow rather than outsource the silicon back-end implementation. Two factors drove this decision: schedule and control. Owning the back-end implementation was key to meeting the schedule while controlling the design process resulted in faster back-end iterations and better control over timing, methodology, resources and quality.

There was, however, the issue of cost. In the short run, the cost of implementing a COT flow was significantly higher than outsourcing. Since Corrent had an aggressive road map of products to be developed in a short time, the initial investment of building the COT infrastructure paid off in future savings. We also saw savings by avoiding costly respins-an intangible benefit of the COT flow that was very difficult to factor into the cost equation. For a startup like Corrent, however, it was a critical decision and one that ultimately enabled our success in getting product out on time.

Once we decided on the COT flow, our next task was to establish a methodology and create an infrastructure to support it. Our development philosophy hinged on making sure that schedule was king; that there is a need to be correct by design; that everything scales; that timing is everything in methodology, and that we must leverage all internal and external resources.

Schedule was the primary driver for our whole organization. We constantly guarded against feature creep-if it was good enough for production, it was good enough to move forward. In cases where a feature was "less than perfect" and fixing it would have delayed the schedule, we worked closely with our customers to derive the best solution. Our marketing team played a critical role here.

Ou r design methodology focused on creating a development environment that could be centrally controlled. For example, all the synthesis scripts for block-level synthesis referred to a common file for timing and other parameters. As a startup, we were building our team while development work was proceeding concurrently. We found the best way to enforce a uniformly consistent methodology was to build it into our development environment. New employees walked into a correct-by-design methodology.

Everything had to be scalable. Our architecture, our verification methodology and our IT organization were all able to support rapid growth and enable lower costs through reuse.

Corrent's modular silicon architecture was designed to scale in terms of performance, crypto algorithms and chip I/O protocols. For example, our architecture allowed us to quickly incorporate support for new I/Os (such as PCI, PCI-X and PL3) without having to change the rest of our design. Similarly, our pipelined sliced architecture allow ed for relatively simple addition of newer encryption algorithms (Fig. 1).

Our goal was to establish a robust, scalable and re-usable verification environment that could grow with the company. We staffed our verification team with outstanding programmers who were also good design (C++, C, Verilog, Perl) programmers. For example, our lead verification engineer had written a full-blown static timing tool in his past life.

In the end, we created a self-checking random-simulation framework that allowed for pushbutton creation of real-life test cases. This framework meant that most of the designers' time was spent debugging rather than creating test cases. Designers could selectively randomize values for chip features and create a self-checking testbench in minutes. Our verification methodology also allowed us to run completely random test cases for days without intervention.

We supplemented our development/verification framework with an IT infrastructure that was scalable, flexible and controlled. Ha ving an IT expert on your staff is worth every penny! We chose Platform Computing Corp.'s Load Sharing Facility (LSF), a software suite that centrally controls distributed computing resources, to manage our compute farms. These farms were populated with the fastest Linux machines available; large Sun servers were used for jobs requiring 64-bit operating systems and large memory, or for applications unavailable on Linux. Whenever possible, we chose Linux for its affordability and speed.

Our methodology focused on single-pass timing closure. One of the first steps was to do all data preparation work up front. The foundry and the library vendor were chosen early on to permit early qualification. The library could be checked for completeness (we discovered it had no integrated clock-gating cells) and spot-checked for timing accuracy with Spice simulations.

Next, we created a baseline tool flow. In this way, the "nuances" of each tool could be exposed and accounted for early in the game. That allowed us t o create the all-important glue (scripts) that enabled the data to flow smoothly back and forth between the tools. Fig. 2 gives a summary of our tools. Fig. 3 shows our five-step high-level integration flow.

Corrent decided early on that a back-end test run was necessary to hammer out the methodology to ensure a successful tapeout of the final chip.

Within three months of forming a team, we taped out Project Squall and completed these key tasks: