In order to build a first-class system-on-a-chip design factory that could meet our customers' fast time-to-market demands we realized we had to revolutionize the way we did design to significantly shorten the design process.

The solution involved looking carefully at the tools and methodologies we were using and standardizing on ADS, our ASIC Design System. Our objectives in establishing ADS were threefold: to provide a design system capable of handling highly complex ASICs; to differentiate the design system through the introduction of library elements; and to differentiate the design system through the introduction of "best-in-class" commercial tools.

ADS is used throughout the entire design process, from system-level entry and simulation in C, to hardware/software co-design through to hardware implementation. A critical part of this process involves putting effort into creating a detailed system specification that is used throughout the design process to allow repeated testing of hardware versus software throughout the development cycle. This methodology requires an investment in the early stages of the design cycle, but it pays back at the end.

We use the CoWare N2C design system, and the methodology it provides in our design process. It aids in the development of a comprehensive system specification, which can be animated and validated for the functionality required.

N2C allows the engineer to describe the architecture and make trade-offs through a C-language-simulation environment. Different processes are defined in C, as is the interface channel between the processes. The only microprocessor core supported by CoWare today is the ARM 32-bit RISC, but one, or several processes, can be mapped, on to the ARM core and the optimum trade-off found.

The hardware C parts can be refined, at the moment by converting them manually to VHDL or Verilog. Designs can be cosimulated between C, Verilog or VHDL at the register transfer level (RTL) and the ARM instruction set simulator (ISS). Once the RTL code is synthesized into gates, the CoWare cosimulation engine can be run again.

CoWare has the same capabilities as Seamless or Eagle but adds on top of that the C language interface, which is important for architectural simulation and trade-off, with a downward path toward implementation. One feature in CoWare, which we are not using, is the capability to synthesize automatically the hardware-software interface including device drivers, hardware interface logic, interrupts and mapped I/O. The idea is to base the whole development on an executable specification as the common reference for hardware and software teams. System partitioning can be optimized at the final definition of this executable specification.

By initially using the C language for developing both the hardware and software specification and test benches, the hardware model is available up-front for our software-design team. In addition, the C specification optimizes simulation speed. For example, in a cell-phone design, the C hardware model used only three seconds compared with eleven days of RTL simulation. We then compile the software C to run on the processor ISS and the hardware is translated manually into VHDL.

We can, however, use the same C test bench to validate that the conversion was successful. We are looking at using C-to-VHDL converters. CoWare has an RTL-C to VHDL converter. Major CAD vendors are working on behavioral C to VHDL synthesis tools.

Initial use of C specification also means that design re-use is much easier, as the completed system specification from the first design can be delivered to a second design team to work on the next-generation product. We use the design reuse capabilities to build a complete family of parts — for example, a variety of ASSPs for IDSN communication. Our designs often consist of more than 80 percent reusable elements, significantly speeding the design process and improving our overall quality.

In addition to the ARM core, we have a number of licensed and native microcontroller and DSP cores as well as access to Inventra library of virtual components (VCs) from Mentor Graphics. As a member of the board of the Virtual Socket Interface alliance (VSI) we want to promote a market place for IP exchange which allows complex systems-on-a-chip using mix-and-match of VCs from different companies.

We have developed an IP browser and library setup that is suitable for both hard and soft IP. The browser allows the engineer to select an IP block that the browser will copy into the ADS project structure. For all soft IP cores the browser will copy the RTL Verilog or VHDL code, synthesis script, test insertion script and a set of self-testing test benches. The whole set of related scripts and code allows the engineer to map the soft IP into the selected technology

For hard IP the instantiation of the VC in both Verilog and VHDL is copied into the ADS project structure. We have an IP socketization team, which creates and validates all the needed views of the hard IP. Therefore all paths to related views — C simulation model, Synopsys library view, Verilog/VHDL wrapper for C model, test vectors and so on — are generated. Simulating and verifying a piece of hard IP is as transparent, on a library level, as using an AND gate.

The final goal is to have a fully compliant VSI library structure and view-naming scheme. We are, therefore, following the VSI standardization effort closely. The biggest problem is that qualification and generation of the many different views of the IP is manual work. There are no tools for helping with this. But the advantage is that under ADS, we're able to do true hardware/software co-design.

We can test the software on the most accurate model available at that time in the development cycle. Every time a lower-level model becomes available, it replaces its predecessor as a reference for the testing of the software. Before we switch to a new lower-level model, we validate it with its predecessor. This can include more than simply running the software on both and comparing the results.

Along this flow, we'll decide which model must be considered as the executable specification, or "golden" reference. This cannot be the lowest-level model, as the lowest-level model will be too slow.

One of the greatest benefits of co-design is the ability to create virtual prototypes in C and C plus VHDL. Before the existence of ADS we had to wait to get a hardware model until RTL coding was complete. But hardware simulation is often too slow to be practical for system-on-a-chip designs.

Virtual prototypes are key to enabling much-faster time-to-market with better-quality results. Under the "old" way, a typical embedded-system project schedule would extend far beyond the hardware completion date as the software was debugged and modified to work with the hardware once it was produced.

By using the full capabilities of the hardware/software codesign methodology, we're able to develop and debug the software along with the hardware, moving in the completion date by two or three months in some cases. Codesign should be consistently used for all projects. Otherwise, an investment was made, but the payback of identifying problems earlier in the design cycle wasn't achieved.

It's very important that the hardware or software teams are not allowed to skip this step even under the time pressure that usually rises close to project end. The biggest circuit designed to date includes logic equivalent to 750,000 NAND-gates, 80 RAMs and 20 clocks. It's clear that if a clean synchronous style isn't used, the simulation part takes forever. Static timing analysis (STA) must be used during the whole design flow including sign-off. We are currently working with Synopsys on a solid STA/RTL-based sign-off flow.

The back-end does not show any limitations; the Avant! place and route and Mentor Calibre tools perform very well. As a result, ADS has been instrumental in helping us with our main objective: to get new designs out faster than ever before. But there are still challenges.

We still need more effective tools for formal verification to compare two models at different abstraction levels such as C versus VHDL and VHDL versus gates. The few formal-verification tools that attempt this are not really mature and do not always give us the best results. Formal-verification tools are limited to comparisons at the gate level, at the RTL level, or between the two levels. No tools exist to compare behavioral VHDL, Verilog or C with RTL or gate-level net-lists. So C to VHDL or Verilog conversion has to be checked by running test benches. Test benches are only as good as the engineer who writes them and there is no 100-percent compliancy check.

Power estimation also is not accurate enough. It allows gate-level estimations but including macros, such as RAM and ROM generators and IP cores, makes automatic estimation inaccurate. And we also need an easier way to plug new processors into the CoWare N2C environment.

Analog design is largely separate from digital design. We have a separate design environment called MADE, based on Cadence DFII, Mentor Eldo, Eldo-Verilog simulation tools and several in-house written verification tools.

In June 1999 we will bring out an integrated version of MADE running under ADS, which will give a seamless interface between high-performance analog block design and complex digital design. The limitation with the current system is the non-optimal interface. Analog blocks have to be exported from MADE to ADS for layout and digital blocks have to be imported from ADS into MADE for mixed-mode simulation.

Ultimately, our customers benefit from ADS in two major ways. First, they get their products designed faster. The software debug and integration can start much sooner because of the hardware/software co-design approach. Second, they get a much better quality design. The best architectural selection is made possible at the very start through C simulation and system partitioning. The top-down design environment provides full validation of the hardware/software interface.