Jump to...

Introduction An SoC Base-Array Architecture The Physical-Verification Problem Hierarchical LVS Verification    Cell Binding    Pin Swapping    Site Cells and Macro Cells Run-Time Results Conclusions References

Introduction

With the cost of a full 0.18 µm reticle set in the range of a quarter of a million dollars, traditional standard-cell ASIC approaches for small- to medium-volume products are no longer cost-effective. Gate-array architectures were very popular for many years since they afforded a means of reducing the NRE through only having to build the "personality" layers. This was especially appealing to small- to medium-volume ASIC purchasers since the NRE could be reduced significantly with a small penalty in die size and performance. FPGAs (Field-Programmable Gate Arrays) have taken over the majority of the smaller volume ASIC business, but are typically not cost-competitive for higher volume manufacturing. Gate-array architectures also had problems meeting the memory requirements as the embedded memory grew and needed to be highly configurable.

AMI Semiconductor, Inc. has been a key player in the ASIC market for over 35 years, and has offered gate arrays in a number of process geometries. To be able to address the high performance and density requirements needed in today's ASIC designs, we developed the XpressArray family of products to address this dilemma. These products employ a gate-array-type approach, but use logic blocks and distributed memory to better meet today's SoC needs, while retaining a late-mask personalization capability. This paper focuses on this type of architecture and the unique problems it presents for physical verification.

An SoC Base-Array Architecture
Back to top

Determining the optimal architecture for a base array to be used in SoC-type ASICs that could be late-mask-programmed required analyzing many trade-offs. The architecture needed to be able to support multi-million-gate logic implementations, embedded memory in a multitude of sizes and configurations, PLLs, DLLs, standard I/O, high-speed differential I/O, flexible pinouts, IP blocks, etc. It also needed to be scalable to support a family of bases with different logic, memory, and I/O requirements.

Rather than being a "sea of gates," the architecture chosen is a distributed logic/memory approach in which small blocks of logic and memory are distributed evenly over the core of the device. The granularity of these blocks is quite small to allow significant flexibility in how the memory is configured. Also included in the core are pre-built PLLs and DLLs, which are also late-mask-programmed. The I/O ring allows any pad site to be a power pad, an input, an output, an I/O, or be combined with adjacent sites for differential I/O. To facilitate testing, all sequential logic elements are wired to enable scan chains. The initial realization of this architecture is shown in Table 1.

Table 1
Initial Realization of the Base-Array Architecture

Logic Gates	1.6M
Memory Bits (Dual-Port Static RAM)	512K
PLLs	2
DLLs	8
I/O Sites	440
Total Devices	~16 million

The Physical-Verification Problem
Back to top

From a DRC (Design-Rule Checking) standpoint, this is a relatively straightforward hierarchical verification problem. The cells need to be checked hierarchically simply because of the large number of devices and the repetitive nature of the design. This is quite easy in the base-array configuration, assuming that the layout does not contain cells placed over the top of other cells at points very high in the hierarchy. The reason for this is that a cell can be checked as a standalone entity and used for every instantiation of that cell if nothing outside the cell overlays it. Once data are placed over that cell, it can no longer be treated as a repetitive cell, but must be dealt with in the context of what crosses it. This is no different than the DRC problems associated with standard-cell circuits where an interconnect crosses the cell placements. The base levels, however, need to be properly structured to prevent too many cells from being expanded up the hierarchy because of other geometries crossing them.

The real issue with verification of the base array is LVS (Layout vs. Schematic). The base consists of hundreds of logic and RAM blocks that are exactly the same. This is similar to trying to LVS-verify a memory, but with the distinct disadvantage that, unlike a memory, none of the blocks are connected. Labeling a multitude of nets for correspondence may well help in checking the base, but these bases will be programmed at some point and will need to be LVS-verified at a level where the correspondence text no longer applies. Once programmed, different correspondence points will become single nets. We need to be able to verify this array of identical blocks both with nothing connected (as a base) and with a variety of interconnections after it is programmed. We need to be able to do this without any manual manipulation of the layout since, once in production use, schedules will be very tight and will not allow time to label each circuit to facilitate verification.

The structure of both the layout and the schematic (netlist) must support hierarchical LVS verification. This seems pretty intuitive, but in the case of a base array the netlist is generated algorithmically, and typically reflects the architecture of the device from a design standpoint, while the layout is typically structured for the most efficient placement of the devices to minimize size. These may well conflict at various levels of the hierarchy. The netlist also needs to be able to be "programmed." This, of necessity, dictates the hierarchy of the netlist since, as opposed to a standard cell circuit or even a traditional gate array, every gate needs to be accounted for in the netlist. All unused gates and memory blocks must be tied off for power and noise concerns, and since the scan chains are pre-wired, the complete scan chains must be reflected properly in the netlist.

I/O are also handled differently in the netlist vs. the layout. While the logic and memory appear similar to standard cells in that the cells are predefined and only the interconnect changes, the I/O cells consist only of unconnected devices that require an overlay (macro cell) to connect the devices properly. All the I/O sites on the layout must have all the devices necessary to build any acceptable I/O cell, but the netlist will only contain the calls to the actual I/O cells used. All unused I/O sites must also be disabled.

The DLLs and PLLs present yet another problem for LVS verification. These are larger blocks that can be programmed in a variety of ways (also via a macro cell). If not used, they must be disabled. Thus, these cells must be treated similarly to the I/O sites in that the layout base cell is altered by what is placed over it.

In the earlier gate arrays, unused devices were simple transistors that weren't connected and could be "filtered" out of the verification. While the layout contained site cells and macro cells, they weren't really considered in verification since the layout and the netlist were both flattened to simple transistors, resistors, etc., and verification was performed at that level. This worked since the complexity was not that great. An initial test case of "flat" LVS using Dracula™ on this new array architecture, however, resulted in a run time of over 15 hours for just the netlist processing—we didn't even get to the layout extraction or the compare stages. Obviously, hierarchical verification is needed.

Next >>

		Click here to get your listing up.