EQUIVALENCE VERIFICATION OF FPGA AND STRUCTURED ASIC IMPLEMENTATIONS

Joachim Pistorius, Mike Hutton, Jay Schleicher, Mihail Iotov, Enoch Julias, Kumara Tharmalingam

Altera Corp. 101 Innovation Drive San Jose, CA 95134

email: {jpistori,mhutton}@altera.com

ABSTRACT

Structured ASICs have recently emerged as a mid-way between cell-based ASICs with high NRE costs and FPGAs with high unit costs. Though the structured ASIC fabric attacks mask and other fixed cost it does not solve verification, particularly physical verification issues with ASICs or logic errors missed by simulation which would require re-spins. These can be avoided by testing in-system with an FPGA and migrating the FPGA design to a closely coupled structured ASIC fabric. Here we describe a practical methodology for a fast, push-button, and thorough verification approach tying an FPGA prototype to a matching structured-ASIC implementation for cost-reduction. Our focus is the equivalence verification between the respective revisions of a design, including netlist, compiler settings, macro-block parameters, timing constraints, pin layout and resource count.

1. INTRODUCTION

A structured ASIC consists of a base array of hard blocks such as RAM and I/O along with a regular logic fabric. Most mask layers are pre-designed leaving only a few mask layers for the user functionality. This reduces the cost and simplifies the verification as compared to standard-cell ASICs. Previous work in this area has described via-programming steps [1], [2], [3], issues in designing the routing architecture [4], and power consumption tradeoffs [5], [6]. Alternative proposals described fabrics based on simple NAND and AND cells [7]. Other work involves investigation of the transistor-level implementation of specific cells for Via-Programmable Gate Arrays (VPGAs) [8] and the CAD tools for mask-programmable devices [9]. Structured ASICs are now explored or manufactured by several companies including Altera, AMI, ChipX, eASIC, Faraday [10], Fujitsu, NEC [11] and Virage [12]. A Field-Programmable Gate Array (FPGA) also has a generic logic fabric along with hard blocks such as RAM, DSP, I/O, and dedicated clock networks. SRAM based FPGAs provide the ability to prototype and test in-system

with arbitrary re-programming of the configuration bits. Combining these solutions can result in a risk mitigating design flow: prototype, test and even initially ship a design using an FPGA then migrate that design to a structured ASIC implementation for volume production. This, however, assumes a straightforward equivalence between the two implementations, not just for logic, but for physical components such as PLLs, I/O buffers and transceivers and their effect on power, signal integrity and other issues required for practical replacement of the FPGA by an ASIC. The authors of [13] argued that the best method consists of tying the difficult-to-verify blocks of the structured ASIC base array to physically identical blocks in a pin and package compatible FPGA, and gave a structured ASIC fabric description and a synthesis flow with the goal to facilitate the verification and the migration path. Here we describe the corresponding verification process which achieves the overall goal of a seamless migration. Challenges include not just netlist verification but functional, physical, timing and engineering change order (ECO) issues in maintaining the flow. Our contribution is in the overall methodology rather than in the algorithmic aspects of formal verification. Section 2 introduces the compatible FPGA and structured ASIC architectures. Section 3 describes the verification engine, Section 4 gives empirical results, and we conclude in Section 5.

2. MIGRATION PATH

Figures 1-4 show the correspondence between the FPGA and the structured ASIC as described in [13]. Figure 1(top) shows the floorplan of an Altera Stratix® II FPGA [14]. Note that our methodology also applies to other FPGAs. DSP blocks and adaptive logic modules (ALM) of look-up tables (LUT), flip-flops (FF), adder arithmetic, and DSP are re-synthesized and mapped onto so called HCell Macroswhich are library cells built with basic blocks (HCells) in the structured ASIC fabric. We define a 1:1 functional mapping between logic functions in the FPGA fabric and HCell Macros in that library. Figure 2 shows this mapping and Figure 3 gives examples of two possible HCell macros for one 4-LUT function and one clearable DFF.

1-4244-1060-6/07/$25.00 ©2007 IEEE. 423

LUT FF

DSP

ALM

HCell Macros

PLL

Tx/Rx

RAM

I/O

Structured-ASICBase Array

FPGA

Fig. 1. FPGA and structured ASIC architecture

HCell Macro

HCell Macro

HCell Macro

ALM

6-LUT

+LUT

LUT

+LUT

LUT

ALM

6-LUT

+LUT

LUT

+LUT

LUT

Fig. 2. FPGA logic cell to HCell macro mappingCLK

1

D 0

CLR

0

0 1

CLK

10

QCLR

010

A

B 0C 1

D

01 1

Y

4-Input Function Normal DFF

Fig. 3. Examples for HCell macros

The 1:1 mapping guarantees identical anchor points and cell names between the LUTs and FFs in the FPGA and the HCell macros in the structured ASIC. For all other blocks (phase-locked loops (PLL), transceivers, RAM, I/Os and clocking), we propose a physical 1:1 mapping – identical schematic, layout, and fabrication process for the block as shown in figure 4. Hence, the verification of these blocks can be restricted to their connectivity and configuration. The motivation for this choice is that the verification of those blocks is a very difficult problem. For instance, the verification that two different PLL implementations have

I/Os

FPGA StructuredASIC

I/Os1-1 Match

PLLs PLLs1-1 Match

RAMs RAMs1-1 Match

DSP Custom Block DSP MacrosFunctional Match

FPGA Registers Register Macros1-1 Functional Match

I/O I/OI/OFPGA Comb Logic Comb Logic MacrosFunctional Match

Clocks & Control Signals

Clocks & Control Signals1-1 Functional Match

I/Os

FPGA StructuredASIC

I/Os1-1 Match

PLLs PLLs1-1 Match

RAMs RAMs1-1 Match

DSP Custom Block DSP MacrosFunctional Match

FPGA Registers Register Macros1-1 Functional Match

I/O I/OI/OFPGA Comb Logic Comb Logic MacrosFunctional Match

Clocks & Control Signals

Clocks & Control Signals1-1 Functional Match

Fig. 4. Block level matching the same functionality requires new clocking, jitter, signal integrity checking, etc. without physical equality in the periphery there is a significant barrier to seamlessly replacing the FPGA prototype with a pin-compatible ASIC in a reasonable turn-around time. For a detailed description of the synthesis flow as well as all aspects related to the architectural choices, their implementations and the related limitations see [13]. One important point to mention is that the structured ASIC implementation is more than 10X smaller than the FPGA, so area in the structured ASIC is dominated by hard blocks, meaning that any area inefficiencies introduced in the architecture to improve verification are tiny when measured against the overall cost reduction achieved.

3. REVISION COMPARISON TOOL

Figure 5 shows the parallel compilation for the FPGA and the structured ASIC revisions of a design. Synthesis is common and is part of our tool-set [13]. For place & route we use vendor tools for the FPGA and commercial ASIC tools for the structured ASIC. We define a revision of a design as the collection of timing and mode assignments, configuration, placement and routing information, cell names, connectivity and functionality. The equivalence verification between revisions needs to be thorough and robust to avoid re-spins of the structured ASIC. It also has to be fast and easy to provide for inevitable ECO. In fact, our approach targets the parallel development of both implementations treating them as one virtual device and allowing repeated desktop iterations before the project definition is finalized. This is the biggest advantage of our approach since the design can be tested in system using an FPGA, ECOs can be applied easily, and the time from the decision to go into production with a structured ASIC to tape-out and device production is significantly reduced. Equivalence between the two revisions is checked at multiple levels. Our focus is on the verification of the post

424

SynthesisTech. Mapping

Place & Route

AssemblerProgramming

SynthesisTech. Mapping

Place & Route

Layout GenerationEquivalenceChecking

BlockEquivalence

Checking

Post P&R DesignEquivalenceVerification

RTL Design

Post P&RDatabase

ProgrammedNetlist

Post P&RDatabase

Layout

MigrationInformation

FPGA Revision Structured ASICRevision

Fig. 5. Parallel FPGA and ASIC compilation

Migration Compatibility- Project Settings- Assignments

Post P&R DBStructured ASIC

Post P&R DBFPGA

Functional Equivalence- Node Matching- Connectivity- Logic Verification

Resource Usage- I/O Properties- Global Resources- Block Configuration

EquivalenceVerification Report

Fig. 6. Revision comparison toolplacement and routing implementations. Our tool, shown in Figure 6, can be divided into three phases. We need to ensure a compatible migration path (design files, settings, assignments, and constraints), resource usage and block configuration, and finally design equivalence (netlist connectivity and functional equivalence).

3.1. Project Equivalence

Though basically straightforward, the first aspect of the flow needs to consider the many compatibility and legality

aspects of the migration between revisions; e.g. pin placements, types, and other configurations must be compatible for goal of chip substitution. Design and project files must be compatible, placement, routing and timing analysis must be current, and all ECOs applied equally to the FPGA and structured ASIC revisions. Instance-specific assignments, e.g. timing constraints or multi-cycle/false-path exclusions between register pairs, are not checked by commercial verification tools. This is a major challenge, because instance-specific assignments refer to the respective instances by name. Therefore, it is critical for both revisions to use the same names for blocks and signals wherever possible. Given the 1:1 register name equivalence guaranteed by our own synthesis tool, identical timing assignments on registers in both the project definition and the RTL source code can be asserted as identical between revisions. Also, assignments on the placement of registers or hard blocks such as RAM or I/O must be identical, as must assignments of clocks to global clock networks or PLLs, and assignments allowing the merging of PLLs and other resources such as RAM slices into RAM blocks of a compatible type. None of these are particularly difficult to check, but the existence of this step speaks to the overall goal that the parallel development of both implementations is done in a single project and on the designer’s desktop rather than by an ASIC house. The simplicity is dependent on the synthesis restrictions guaranteeing 1:1 register and anchor-point correspondence.

3.2. Resource Equivalence

Given compatibility of the project and the FPGA to base array, we check that the resources are used identically. This includes for instance I/O configuration and assignments to global routing resources such as the clock network present in both fabrics. These assignments and configurations can be made by either the designer or by the compilation tools. I/O Properties: Configurable I/O standards and properties are a requirement for both FPGAs and structured ASICs which target the same base array for multiple users and applications. For socket replacement to be feasible, we require complete pin compatibility between the two devices: I/O placement and I/O-standards must be identical, current drive-strength, capacitive load, power-up level and features such as termination or pull-up resistors must be used identically. This again relies on the physical correspondence in the underlying implementation, without which the simple configuration check would require signal integrity and many other analyses. Global Resource Assignment: Further assignments to be checked involve those made by the tools, such as the promotion and assignment of certain signals such as clock and reset signals to global routing resources, and the assignment of logical PLL implementations to physical

425

PLL locations. This verification is dependent on the paradigm of having multiple revisions of the same virtual target device. Block Configuration: Basic building blocks of structured ASICs such as RAM, PLLs, and smaller blocks such as delay chains are configured either by the designer or by the tool chain. For example, a RAM can be used in different width and depth combinations and a PLL can have multiple configurations and dynamic modes. For each RAM block we verify connectivity, registering and global signal usage, and settings such as width and depth. Further configuration issues such as read-during-write and clocking must also be identical. Bit-slices of logical RAM must be verified for initial content and physical implementation. Sometimes a block configuration change is desired, e.g. when the structured ASIC will use a higher clock frequency. The optimal PLL configuration for the higher frequency is often different from the optimal configuration for the lower frequency e.g. with respect to bandwidth and jitter transfer. In that case, we allow replacing the PLL design unit with a modified design unit for the structured ASIC revision. Both compilations need to satisfy their respective timing requirements. In addition the differences in PLL configuration are reported for inspection by the designer. Note that not all parameters are expected to change. For example the clock multiplication rates and the phase shifts are still expected to be identical in this particular case. However, the phase might need adjustment in other cases such as when the clock insertion delay differs. The same mechanism can be used by IP cores that need to specify a certain PLL phase offset that may be different between the two revisions.

3.3. Functional Equivalence

The final step is to verify functional equivalence of the designs in the two revisions. This consists of three aspects: identification of anchor points, connectivity checks and logical equivalence of combinational cones. Node Matching: During the first phase as many compare points as possible are matched, either by names and block type or by connectivity. Matching by name is made easy by the name conservation for most blocks during the migration. Mapping by connectivity requires two blocks to have the same type, the same configuration, and the same input connectivity in both revisions. Non-combinational nodes that don’t have a corresponding counterpart in the other revision are considered as being the cause of non equivalence between the two netlists. The remainder of the comparison is limited to matching nodes. Connectivity: The second phase consists of a connectivity check. This connectivity check compares the support set and the fanout set of every matching compare point by simply doing a backward and forward search in the netlist starting with the node in question and finishing when

ADDER

DOUT

SUMOUTCOUT

SIG1

SIG2

Structured ASIC

ADDER

DOUT

SUMOUTCOUT

GND

SIG1SIG2

A

B

C

LUT mask!C&A | C&B

FPGA

Fig. 7. Different block implementations

DOUT

CLK

DINSDATA

SLOAD SCLR ACLR

ALOAD

0

1

Fig. 8. FPGA register block diagrammatching compare points or non-combinational nodes are found. Nodes with different connectivity in the two netlists are considered causing the non equivalence of the two netlists, because we assert that mapped compare points implement the same functionality. Even with the simplification of common anchor points, there are still a number of complications for even a simple connectivity check. One example is illustrated in Figure 7, where we determine the support set of DOUT in the presence of register and adder packing in the FPGA arising from shared gates in the FPGA logic cell implementation. The DOUT port of the structured ASIC implementation only connects to SIG1 whereas in the FPGA implementation the same DOUT also connects to SIG2. The LUT however implements a MUX with a constant ‘0’ select line. Therefore, DOUT does not functionally depend on SIG2, even though it is on the input to the node. These synthesis artifacts are typical of FPGA tools in the generation of arithmetic logic. The only solution to this problem is to check whether the output of a node is functionally dependent on a certain input whenever a connectivity mismatch is detected. Another example is the following: In the FPGA, LUTs are abundant and synthesizing a LUT to implement logic ‘1’ or ‘0’ is common. In the structured ASIC however, physical connections to the power rails are often used instead. Sometimes the connection is removed in either revision if this represents the default behavior. All those configurations are functionally equivalent and should not be flagged as being different connectivity. For example it is equivalent if the SCLR port of the register in Figure 8 is driven by a LUT implementing logical ‘0’, by an inverter driven by a logical ‘1’, by a connection to the GND power rail, or if the port is just unconnected. These and other issues are typical of a number of additional verification steps required to supplement basic cone traversals and support set calculations.

426

Logic Verification: Logical functionality checks are performed for every compare point with the same connectivity. We use the basic fact that two logic functions are equivalent when their representation as a reduced-ordered binary decision diagram (ROBDD or just BDD) is isomorphic under the condition that the support sets of the two functions have the same order [14]. Note that the functions that need to be compared have only very few inputs. This is guaranteed by construction since HCell Macros correspond to only 6-LUTs. Thus the BDDs are always of reasonable size. Furthermore, the comparison is limited to matching points with the same connectivity. Therefore, we are guaranteed to have the same support set and any difference reported is indeed caused by different logic functionality. We also explored a different approach that skipped the connectivity check altogether. The advantage is that we don’t have to handle any special case described in the previous section. However, we are no longer guaranteed to have the same support set. For example, the support set of signal A in the FPGA netlist might be composed of signals C, D, E, and F whereas it is composed of signals B, D, F, G, H and J in the structured ASIC netlist. Before constructing the BDD, we have to put them in the same order. We do this by first extracting the common support subset in the same order (D, F) and appending the non common FPGA support subset (C, E) followed by the non common structured ASIC support subset (B, G, H, J). For the example above we obtain the support set (D, F, C, E, B, G, H, J). Signal A has the same functionality in both revisions if it is independent of the non common support subset (C, E, B, G, H, J), and if the function depending on the common support subset (D, F) is equivalent. Though it is straightforward to construct BDDs by analyzing the LUT masks of combinational functions, there are a few challenging problems. An interesting configuration appears when a register (see Figure 8) is placed with an unrelated LUT into an LE in the FPGA revision. The Stratix II device family [14] allows a combinational function to be placed with an unrelated register whenever there is an unused LUT input to drive it’s data-in. This is typically synthesized by setting the SLOAD to ‘1’ and connecting the registers data input connection to SDATA, because the DIN port cannot be connected in this configuration. Our equivalence check must take compare the functionality of the signal on the DIN port of the register in the structured ASIC implementation with the functionality of the signal driving the SDATA port in the FPGA implementation. Figure 8 illustrates another particular configuration. Let the signal on the SDATA port be ‘0’ and the signal driving the SLOAD port be A in the FPGA revision. The structured ASIC revision might be implemented in the same way. However, it is also equivalent if signal A drives the SCLR port on that register.

0

20000

40000

60000

80000

100000

120000

Design

LE N

umbe

r

0

1000

2000

3000

4000

5000

6000

Kbi

ts o

f RA

M

LE count

Memory amount

Fig. 9. Design characteristics

4. EXPERIMENTAL RESULTS

To our knowledge, there is no comparable tool with which to perform the standard quantitative comparison. Commercial equivalence checkers such as Synopsys Formality or Cadence LEC could eventually cover the part of the functional verification step described in section 3.3, but not the steps described in sections 3.1 and 3.2. Even then, they would require a significant effort for keeping track of synthesis optimizations and providing guidance without which comparing an FPGA and ASIC netlist would result in thousands of mismatches. This is not a tool deficiency but an issue in the flow because the tool cannot discern designer intent on truly different logic. Comparing different synthesis outputs would make migration a complete re-design; and this ignores physical verification of PLLs and I/O blocks not verified by standard tools. Here, we present a few problems with design setup and with the early use of the compilation flow discovered by our tool. We also show that the tool and methodology are effective and efficient in verifying the equivalence of the two post placement and routing databases. For our experiments we used 100 industrial designs containing IP blocks and having between 2000 and 115,000 FPGA logic elements (LE), up to 550 9-bit DSP blocks, 5.6 Mbits of RAM and from 0 to 6 PLLs (see Figure 9). Every column represents a particular design. We compiled these designs for the FPGA, migrated all constraints such as e.g. timing constraints or location and pin assignments to the structured ASIC revision, compiled the designs targeting the structured ASIC and finally compared the post placement and routing data bases using our verification tool shown in Figure 5. The experiment was run on PCs with processor performances between 860MHz and 3GHz. To gauge the tool’s efficiency we use a relative comparison by reporting the percentage of compilation time and peak memory usage. The results in Figure 10 show that, on average, the verification tool required only 4.6% of the total runtime while its average peak memory was within 43% of the overall compilation.

427

0%

5%

10%

15%

20%

25%

30%

35%

40%

Design

Perc

ent o

f tot

al ru

ntim

e

0%

20%

40%

60%

80%

100%

120%

140%

Perc

ent o

f pea

k m

emor

y

Runtime

Peak memory requirement

Fig. 10. Runtime and peak memory requirementsThis represents an order of magnitude better than would be expected of a stand-alone formal verification tool. The tool also discovered several design specific problems as well as issues with compilation tools during the early evaluation. These are not functional differences, but rather arise from architectural requirements. For example, a few designs contained encrypted IP blocks with conditional assignments specific for the FPGA implementation. Those assignments couldn’t be migrated to the structured ASIC leading to different design implementations. Other designs contained instance specific assignments embedded in the RTL source code in form of attributes attached to registers. Those operations weren’t migrated as instance specific assignments from the FPGA to the structured ASIC revision even though this was one of the fundamental requirements for the 1:1 FF equivalence paradigm. Another issue concerned name changes on non-combinational blocks caused by either ECO or specific physical synthesis operations. The result was that timing assignments could not be migrated to the structured ASIC revision resulting in differing timing assignments flagged by our tool. Though there are many practical issues to consider, our tool’s ability to find such detailed issues in the migration flow illustrates the robustness of the overall approach.

5. CONCLUSIONS AND FUTURE WORK

In this paper we presented a methodology for equivalence verification between FPGA and structured ASIC revisions of a base design. The primary aspects of this methodology are the 1:1 correspondence of the FPGA and ASIC physical blocks to facilitate electrical verification, and the verification engine which ensures logical correctness. Register and combinational cone boundaries and name conservation guarantee greatly simplified verification that can be performed on a designer’s desktop, rather than by an ASIC design services provider. This research has since been implemented in Altera’s Quartus® II as the Stratix II to HardCopy® II verification

flow. Using this fabric and flow, a designer can prototype in-system with an FPGA on their board and then migrate to a pin-compatible structured ASIC for cost reduction without the need for costly physical verification or ASIC re-spins due to physical, logical or timing mismatches.

6. REFERENCES

[1] C. Patel, A. Cozzie, H. Schmit and L. Pileggi, “An Architectural Exploration of Via Patterned Gate Arrays”, in Proc. ISPD 2003, pp. 184-189.

[2] K. Tong, V. Kheterpal, V. Rovner and L. Pileggi, “Regular logic fabrics for a via patterned gate array (VPGA)”, in Proc. CICC 2003.

[3] L. Pileggi, et al., “Exploring Regular Fabrics to Optimize the Performance-Cost Trade-Off”, in Proc. DAC 2003, pp. 782-787.

[4] V. Kheterpal, A.J. Strojwas and L. Pileggi, “Routing Architecture Exploration for Regular Fabrics”, in Proc. DAC 2004, pp. 204-207.

[5] R. Reed Taylor and H. Schmit, “Enabling Energy Efficiency in Via-Patterned Gate Array Devices”, in Proc. DAC 2004, pp. 874-877.

[6] R. Reed Taylor and H. Schmit, “Creating a Power-aware Structured ASIC”, in Proc. ISLPED 2004, pp. 74-77.

[7] B. Hu, H. Jiang, Q. Liu and M. Marek-Sadowska, “Synthesis and Placement Flow for Gain-Based Programmable Regular Fabrics”, in Proc. ISPD 2003, pp. 197-203.

[8] Y. Ran and M. Marek-Sadowska, “On Designing Via-Configurable Cell Blocks for Regular Fabrics”, in Proc. DAC 2004, pp. 198-203.

[9] N. Shenoy, J. Kawa and R. Camposano, “Design Automation for Mask Programmable Fabrics”, in Proc. DAC 2004, pp. 192-197.

[10] K-C Wu and Y-W Tsai, “Structured ASIC, Evolution or Revolution”, in Proc. ISPD 2004, pp. 103-106.

[11] T. Okamoto, T. Kimoto and N. Maeda, “Design Methodology and Tools for NEC Electronics’ Structured ASIC ISSP”, in Proc. ISPD 2004, pp. 90-96.

[12] D. Sherlekar, “Design Considerations for Regular Fabrics”, in Proc. ISPD 2004, pp. 97-102.

[13] M. Hutton, R. Yuan, J. Schleicher, G. Baeckler, S. Cheung, K.K. Chua, H.K. Phoon, “A Methodology for FPGA to Structured-ASIC Synthesis and Verification”, in Proc. DATE 2006 Designers’ Forum, pp. 64-69.

[14] D. Lewis et al., “The Stratix II Logic and Routing Architecture”, in Proc. FPGA 2005, pp. 14-20.

[15] R.E. Bryant, “Graph-Based Algorithms for Boolean Function Manipulation” IEEE Trans. Computers, C-35(Aug. 1986), 677-691.

428