design flow

System-on-a-chip integration creates new verification problems, like using models written in different languages and accounting for very deep submicron parasitic effects, as well as exacerbating others, like mixing analog and digital circuits and analyzing complex hardware-software interactions. Thus sharing information among multiple simulators to solve those problems becomes a critical enabler for design verification.

Recently, a design team at the Cardiac Rhythm Management Division of St. Jude Medical faced these difficult design verification issues on a project that integrated a three-chip system onto a single chip.

For the project, the team verified the hardware functionality and the cell-level details using multiple simulators coupled together for the first time. The multisimulator approach eliminated unnecessary manual steps in the design process, thereby reducing the time to tape-out, and it helped the designers uncover numerous design issues presented by creating a single-chip implementation.

Figure 1	Single-chip pacemaker
The Trilogy pacemaker comprises analog and digital blocks and embedded software. Previously a three-chip design, it was integrated onto a single 0.35-µm chip.

One of the specific benefits of the approach is that it brought the whole team together and improved the appreciation of design problems at the system level because everyone was using the same tool set and flow. Another benefit is that it leveraged the investments that the team had made in simulation tools and training. The new skills required to use multisimulation could be learned in a day and the designers were able to continue using the existing commercial tools that the company owned.

Cardiovascular products

St. Jude Medical develops, manufactures, and distributes medical devices for the global cardiovascular market. The company services patients and its physician customers worldwide with products and services, including heart valves, cardiac rhythm management systems, and specialty catheters.

More commonly known as pacemakers and defibrillators, cardiac rhythm management systems are complex electromechanical devices that are implanted in the human body to control the rhythm of the heart. Pacemakers rely on intricate circuitry, small physical size, and ultralow-power design to provide reliable, long-term support for their human hosts. St. Jude Medical's team depends on accurate and thorough design verification to identify potential circuit problems and to optimize power consumption.

To minimize power consumption, reduce package size, and maximize the reliability of the company's next-generation Trilogy pacemaker, the design team took an existing multichip design, improved it, and retargeted it to a system-on-a-chip implementation (see Figure 1). The new pacemaker design integrates many common technologies, including a microprocessor core, control logic, on-chip SRAM, low-level analog sensors, and telemetry circuitry. Since both analog and digital information is processed simultaneously, the design is inherently mixed-signal.

Figure 2	Successive refinement with multisimulation
Firmware in the program SRAM stimulated RT-, gate-, and transistor-level models through multiple simulation as the design was refined to a single-chip implementation.

In the original three-chip design, analog, digital, and memory functions were isolated on separate pieces of silicon. Verification was done using multiple simulators separately for each chip: an event-driven simulator for the logic and memory and an analog simulator for the sensors and telemetry circuit. The designers compared the results from each chip manually to determine if the interface requirements between the chips were being met, but the real testing of the system had to wait until a laboratory prototype was ready.

Complete presilicon debugging needed

It wasn't economically feasible or technically possible, however, to use hardware prototypes to debug the single-chip implementation. Instead, the design had to be completely debugged before going to silicon, requiring simultaneous verification of all the system components and therefore simultaneous use of multiple simulators.

As with any significant design project, a strategy for developing the design concepts into a final implementation is crucial. The same is true when multiple simulators are used. To integrate the three-chip system onto a single chip and verify correct operation, the team developed a top-down, successive-refinement design strategy (see Figure 2). The strategy required the development of a system-level functional model that could then be refined block by block until a final physical description had been verified and was ready for tape-out.

The level of refinement of a particular block, in terms of the simulation model, was determined by the design objectives. If a particular portion of the design was critical to meeting one or more of the objectives, it was analyzed down to the transistor level. If a portion, such as a block of control logic, had little impact on the design objectives, it was modeled at the gate or RT level. At all stages of the design verification process, multiple simulation was required to incorporate all levels of the design description.

Design objectives

The chip was to be implemented with a 0.35-µm CMOS process. The design objectives were a clock frequency of 32 kHz, a supply voltage of 2.5 V, and a power consumption of just 30 µW.

Clock frequency is a critical design parameter because it affects the overall performance of the pacemaker, as well as the power consumed and the potential for interference with other electronic devices. Supply voltage is a function of both the process technology targets and the available battery technology. Finally, power consumption determines the interval between battery changes. In an implanted device, changing the batteries is an involved surgical procedure, so a precise understanding of the power consumption is critical. The design goal of 30 µW translates into a usable battery life of seven years.

Figure 3	Multisimulator configuration
A standard commercial RTL/gate-level simulator and circuit simulator from different vendors were used simultaneously, connected by a commercial simulation backplane. With this setup, both simulators are active at run time, and design information is shared in real time.

Since the design required high capacity in terms of the number of devices being simulated, as well as high accuracy in both analog signal and power analysis, a combination of an event-driven logic simulator and a transistor-level simulator are used. The team chose Verilog-XL from Cadence for the RTL and gate-level and Powermill from Synopsys for the transistor-level simulation and used them together, simultaneously connected by the Simmatrix Electrical Simulation Backplane from Precedence (see Figure 3).

Using multisimulation with successive refinement

Previously, the team had written HDL netlists or captured circuit-level structural schematics and used them to model a design in either the event-driven or the circuit simulator. Using multisimulation, the process is very similar. Again, both HDL and transistor-level descriptions of the design were created.

Instead of the typical netlisting or compilation process used by a single simulator, however, the HDL and transistor descriptions were partitioned by Precedence's Simprism multisource partitioner. Partitioning splits the design into subdescriptions to be simulated by either the HDL or the circuit simulator. Using a set of text commands for the partitioner, each designer was able to create different partitions to verify compliance with each of the design objectives. For example, an RTL netlist partitioned to Verilog was coverified with an extracted layout partitioned to Powermill.

During a simulation run, either one or both of the simulator user interfaces can be active. This capability was important because some members of the team are experts with circuit simulation and some are more familiar with gate-level simulation. One of the valuable features of the multisimulation methodology is that, to benefit, each designer doesn't need to be an expert in all the simulators being used.

Since the chip is a large design that required close attention to circuit details in many blocks, simulation performance was a concern. Whenever a circuit simulator and logic simulator are used simultaneously, the simulation execution time has the potential to be determined largely by the circuit simulator.

Figure 4	Simulator transfer function
A transfer function enables the simulators to share information. It converts device resistance into logic strength and vice versa.

The Verilog-XL and Powermill combination provided a means to directly trade off full-chip simulation performance and accuracy. At the block level, simulation performance can be controlled through the choice of the design partition. The larger the percentage of the partition in the circuit simulator, the slower but more accurate the simulation. However, as the design moves from the conceptual stage to final implementation, flexibility in the choice of the partition decreases.

When the partition was fixed, the Simmatrix technology provided another level of control over the performance-accuracy trade-off: Events at the partition boundary influence the evaluation of the circuit matrix in the circuit simulator. The Simmatrix backplane allows the designer to "dial in" the resolution at the partition boundary down to a fraction of a millivolt for enhanced accuracy or adjust it higher to increase simulation speed.

In addition to creating subblocks in the design, the partitioning process instantiates interface models on each net that crosses a partitioned boundary. These interface models provide a translation between logic state and strength representations used in the event simulator and the device gate-drain resistance used in the circuit simulator (see Figure 4). To ensure accuracy, the interface model must be calibrated to the process technology. Calibration is done once for the target technology at a given supply voltage and temperature.

One critical element of the successive-refinement methodology is a mechanism for verifying that the results of the refinement process are moving toward the design goals. In the case of a system-on-a-chip implementation, many factors--circuit topology, process parameters, parasitics, and unplanned design block interactions--all act simultaneously on the design, making it impossible to get correct simulation results by isolating the block the designers were working on at the time.

Since the chip executes a software program, it made sense to use the actual program stored in the SRAM as the system-level test bench. Multisimulation enabled the team to use hardware/software coverification to evaluate each refinement of the hardware against the actual application program that the final product would be executing.

Analyzing the entire system on a chip

Migrating and re-engineering the three-chip design to a single chip using multisimulation uncovered a number of opportunities for design optimization. Using the top-down successive-refinement design strategy, the team modeled and analyzed each block as part of the full-chip simulation.

The sensor interface includes an accelerometer that monitors a person's physical activity by measuring small voltage variations in an external sensor. The sensor can detect accelerations from 10 milli-g to 2 g and incorporates a switched-capacitor low-pass filter with a 0.7-Hz cutoff. The sensor interface, which is analog and susceptible to external noise sources, can be accurately characterized only at the transistor level. The multisimulation environment provided actual stimulus and response to the sensor from the rest of the pacemaker system and allowed the design team to optimize the power down to 500 nW.

The 8-bit microprocessor, including both datapath and PLA, used approximately 15,000 transistors. Because of the level of activity in the transistors, the microprocessor offers one of the highest potentials for power optimization when implemented in the single-chip system.

Analyzing the microprocessor in the context of the rest of the pacemaker system using multisimulation provided the opportunity to observe its performance with real stimuli in terms of both logic vectors and timing. This analysis gave new insight into the peak and average current demands over many processor cycles.

For example, the original design suffered from overlapping conditions in the PLA clock that caused unnecessary feed-through current spikes on the driven logic (see Figure 5). This condition hadn't been detected using event-driven simulation on the microprocessor when it was part of a separate chip in the three-chip pacemaker system. Observing the PLA operating under actual stimulus from the RAM, control logic, and other elements of the pacemaker using multisimulation, the design team was able to reduce the PLA's power consumption by 15 percent. Since the PLA originally consumed nearly 50 percent of the total power budget for the microprocessor, the reduction made a significant contribution to achieving the aggressive goal of a total power consumption of 30 µW.

Two SRAM blocks store information for the pacemaker, one for data and one for the program. In the multisimulation environment, these blocks were characterized at the transistor level to identify critical timing for the data and control lines. The timing information was then used to tune a behavioral model of the memory to get the highest level of system simulation performance. The model of the program SRAM provided test bench stimuli in the multisimulation session. The actual pacemaker program instructions stimulated Verilog-XL and Powermill with real op codes to expose issues that might show up in the system-on-a-chip implementation.

Figure 5	Power spikes
While modeling the PLA under real operating conditions generated by the instructions in the program SRAM, multisimulation showed that clock rise and fall times caused feed-through power spikes. Optimizing the driver strength reduced the power consumption of the PLA 15 percent.

The telemetry block uses only about 3,000 transistors. Although it's inherently a mixed-signal block, its function could be characterized using HDL constructs. Both the analog front end and the digital protocol codec were initially modeled at the transistor level. From the transistor-level characterization, the design team built a behavioral model to maximize the multisimulation performance.

The data acquisition interface block manages the interaction between the heart and the microprocessor. Its mixed-signal circuitry includes switched-capacitor filters and an 8-bit algorithmic A/D converter. Because of the critical nature of the circuitry of this block, its 30,000 transistors were modeled at the transistor level only.

Deep-submicron effects

Migrating the three-chip implementation to a single chip at very deep submicron geometries presented several new design issues. Most of them had to do with block interactions resulting from VDSM parasitics that caused coupling between signals and devices. The successive-refinement methodology worked particularly well for detecting those effects. For example, in addition to optimizing the power consumption of the microprocessor core, the team was able to detect two race conditions that hadn't been identified when the microprocessor was simulated with a stand-alone logic simulator, as well as to solve issues with incompatible voltage ratios that arose when previously separate functional blocks were connected directly together on the same substrate.

Using the top-down successive-refinement methodology and multiple simulators simultaneously, the team successfully developed the single-chip implementation, which required more than 2 million transistors. All design goals were met or exceeded with working silicon from the first prototype runs.

Use of the multisimulation technique could be even more beneficial for many other applications. The pacemaker design team is about one quarter hardware engineers. The other three quarters develops the software that is loaded into the program SRAM. Although the successive-refinement methodology using multisimulation allowed the team to do hardware/software coverification, most of the software development process still happened after the hardware prototype was available. However, the same multisimulation technique could be applied to parallelize the hardware and software development processes to allow hardware/software codesign by adding an instruction-set simulator to the logic and circuit simulators. This level of multisimulation analysis could permit further power optimizations related to profiling the execution of prototype software on the system simulation model, as well as speeding the delivery of the combined hardware and software product to market.

Andre Walker is the director of IC development in the Cardiac Rhythm Management Division of St. Jude Medical in Sylmar, Calif. He has over 13 years' experience developing low-power ASICs.

Kevin Jorgensen was formerly at Precedence, Inc. in Santa Clara, Calif., which was recently acquired by Mentor Graphics Corp. He has more than 13 years' experience as a mixed-signal designer, author, and EDA marketing executive.

To voice an opinion on this or any Integrated System Design article, please email your message to miker@isdmag.com.

integrated system design  May 1998