ASIC vendor eASIC's announcement of a conversion path from their Nextreme structured devices to a fully cell-based ASIC offers an interesting opportunity to reflect on conversion methodologies.
Comparing it to a recent discussion of the KaiSemi conversion flow, which takes a design from an FPGA to a cell-based ASIC, further illuminates some of the important choices that come up in reworking an existing design. The two approaches are conceptually similar, but practically quite different.
Structurally, the design problems the two companies face are similar. KaiSemi converts a working FPGA design into a cell-based ASIC design. Similarly, eASIC converts a Nexstreme or Nexstreme-2 structured device design - which may or may not have originated in an FPGA - into a cell-based design. Both strive to offer a turnkey service in which the customer has to understand very little of the ASIC process beyond RTL verification and timing.
Both conversion problems are defined by the structure of the device being converted. And while the technologies of FPGAs and Nextreme ASICs are very different - one relies on active circuitry to configure interconnect, the other relies on a via layer - the underlying logical structures are quite similar. Both FPGAs and Nextreme devices are essentially arrays of logic cells into which are dispersed embedded memory blocks. The great speed advantage of via-connected wiring over switch-connected wiring allows some differences, however. For example,
FPGAs generally combine a look-up table with one or more registers in each logic cell. Nextreme's architecture has separate blanks of look-up tables and registers. More significantly, most FPGAs offer embedded hard-wired DSP blocks, while eASIC argues they can hit the same throughput - though not the same internal clock rate - as FPGA DSP blocks with their own datapaths implemented in the Nextreme logic fabric. One might expect these detailed differences to cause small differences in design flows, and one would be correct. But there are much larger differences based not in microarchitectures, but in
The philosophical question is concrete: at what level of abstraction should we carry the design from one design flow to the other? KaiSemi's answer is the FPGA netlist level. The company's VP of marketing and sales Tomer Kabakov argues that working from the post-synthesis netlist and timing files preserves both the structure and the timing relationships of the original design, and eliminates the time required for RTL reverification and resynthesis. The approach also has the
advantage of working with a design that is both verified and field-proven.
But there are downsides as well. By netlist level, much information has been refined away about what the designer was trying to do in the first place. Is that little cluster of gates and registers a state machine, a signal-processing pipeline, or an ARM-9? So the KaiSemi team inserts a step into their data-collection process before ASIC design begins: they interview the customer's design team and identify the IP blocks that went into the FPGA design, and what kinds of memory structures the team attempted to emulate in the FPGA RAMs. This discovery process happens at about the time the KaiSemi team is exploring the design and selecting an ASIC library.
The next step for KaiSemi is the heavy lifting: a tool that performs an automatic netlist conversion, taking the parts of the FPGA netlist that have not been previously identified as IP blocks and converting them to ASIC netlists. This process - which can run for 24 hours - attempts to infer complex functional cells when possible, rather than simply doing a rote mapping of FPGA logic elements onto standard-cell patterns.
KaiSemi integrates this converted netlist with separately-synthesized netlists for the IP blocks, and then does a full netlist-level verification. From there, the flow moves into pre-layout analysis and planning, course timing, test insertion, place/route, and design closure, resulting in a tape-out. As is increasingly the case in the industry, KaiSemi uses an equivalence checker to formally verify each
step that modifies the netlist.
In contrast to the KaiSemi flow, eASIC does their conversion at RTL. The
company picks up their customer's RTL design, adds in macros to replace structures - such as memories, phase-locked loops, and I/Os - that are unique to the Nextreme devices, and feeds the whole package, along with SDC timing files, into Synopsys synthesis for an initial pass. This approach bypasses any netlist-level optimizations the customer may have made for the Nextreme architecture. It also allows eASIC to bring in third-party IP at RTL, giving access to synthesis options that wouldn't have been available at netlist level.
A key point here is flexibility. If the customer wants a cost- and power-reduced functional equivalent of an existing FPGA or Nextreme ASIC, the flow is virtually turnkey. "They only have to give us verified RTL and timing files," explains eASIC VP of marketing Jasbinder Bhoot.
But one of the main reasons cost-reduction programs don't get done is that by the time the end-product is ramping, the design requirements have changed. Working at RTL allows the customer to modify logic or interfaces, rethink memory structures, and add new IP blocks.
Integration pressure, for example, may convince the customer to include mixed-signal blocks into the cell-based easicopy ASIC that could not have been implemented in either an FPGA or a Nextreme ASIC. As with KaiSemi, eASIC uses formal verification at each stage to make sure the logic of the design has been preserved. From initial synthesis, the easicopy flow moves through a conventional sequence: test insertion, final synthesis, and physical implementation.
Comparing the two flows, the KaiSemi approach seems to offer somewhat faster time to tape-out by eliminating resynthesis of the full design, although the team still has to synthesize difficult IP blocks. The flow also perhaps offers greater fidelity to the original FPGA. The eASIC flow may take somewhat longer, but it offers - at the cost of more design work by the customer - the opportunity to enhance the design during conversion. And by working from the original RTL, this approach
may stay closer to the designers' intent, less influenced by the particular needs of FPGAs. Different emphases lead to different results.