FPGA-ASIC conversion: is automatic an option? - Embedded.com

FPGA-ASIC conversion: is automatic an option?


FPGA-to-ASIC conversion doesn’t get a lot of press. For many teams who design-in an FPGA, conversion to a cost- and power-saving ASIC is at best an afterthought. Let’s ship this thing, and then we can worry about cost reduction. But having an effective path to an ASIC may be vital to a successful design’s product life. And understanding on the front end of the design just how that conversion will occur can save much pain and sorrow later.

Not every design needs a migration strategy. In some designs the FPGA eats an insignificant portion of the cost and energy. In others, the Moore’s Law treadmill on which FPGA vendors must run routinely spins off enough cost savings to satisfy the system’s life-cycle needs. In still other cases, the FPGA vendor’s own conversion program will meet the need.

That still leaves a significant number of designs for which—should sales leap or competition pounce—the presence of an FPGA on the board will become a handicap. A few years ago quite a number of second-tier ASIC vendors and Structured-ASIC companies vied to serve this need, primarily with various flavors of gate arrays in mature processes. Today, the list is shorter, with Atmel, On Semiconductor, and KaiSemi coming up in search results.

Kai who? In a conversation with KaiSemi CEO Gal Gilat and VP of marketing and sales Tomer Kabakov at the Embedded Systems Conference last week, the heritage and value proposition of the company became more clear.

KaiSemi’s roots are in ASIC vendor Orbit Semiconductor, which focused on smaller gate arrays and FPGA conversions. In a bid to move upstream, Flextronics–the assembly giant–purchased Orbit. But the move apparently caused acute indigestion. Flextronics reconsidered its love of the semiconductor industry, and in 2005 AMI Semiconductor absorbed the FPGA conversion group as part of an acquisition of Flex’s semiconductor operations. After On Semiconductor acquired AMI in 2007, the FPGA conversion team in Israel quietly slipped out the back door and formed KaiSemi, although On continues to offer conversion services.

KaiSemi remains primarily focused on FPGA conversion, although the venture also offers ASIC-to-ASIC and DSP-to-ASIC services. Using a variety of processes from 90nm to 500nm, the company claims the ability to convert most current FPGA designs to drop-in ASIC replacements, using what KaiSemi calls an automated conversion process.

Automated is a loaded word. Kabakov explained that the flow begins with a design review. The customer provides a frozen FPGA netlist and SDF file; functional test vectors; pin definitions, including electrical requirements; and a checklist of additional information such as timing constraints, clock frequencies, and test strategy. All these the KaiSemi team examines.

Kabakov noted that there are two strong indicators of the convertability of a netlist: the successful operation of the design in production, and the completeness of the test-vector set. Beyond that, the review looks for known conversion obstacles, such as asynchronous blocks or multi-Gigabit I/Os.

Once everyone is happy, KaiSemi runs their conversion tool. A run takes 12 to 24 hours, depending of course on the original design size, Kabakov said. The tool transforms the FPGA netlist into a cell-based ASIC netlist using a proprietary set of libraries developed by KaiSemi for the purpose. This is not a simple mapping of look-up tables, muxes, and registers into cells, Kabakov emphasized. The tool infers logic functions from the FPGA netlist and attempts to map them into functional blocks from the libraries. KaiSemi also attempts to map third-party IP blocks directly rather than through netlist conversion.

The approach not only should produce better results for a random-logic netlist, but it addresses two of the hardest problems in conversion: block RAM and DSP blocks. The tool examines the configuration of block RAM and its wrapper in the FPGA netlist, infers the actual RAM function the design uses—a small multiport, say, or a large FIFO with over/underflow flags—and instantiates the correct function in the ASIC netlist. There is no attempt to replicate the block RAM itself.

Similarly, the tool examines the netlist’s use of FPGA DSP blocks and infers an optimized data path. Usually, Kabakov said, the cell-based netlist in KaiSemi’s older processes can keep up with the maximum clock rate the customer is actually applying to the nominally far faster DSP block in the FPGA.

The flow moves from translation to formal and functional netlist verification, and from there to a conventional ASIC back-end flow: scan/test insertion, resimulation, and physical design. Kabakov claimed that by translating netlists, rather than resynthesizing RTL, KaiSemi stayed closer to the original design and substantially shortened the front-end design time. But by inferring intent from the netlist, the tool escapes slavishly duplicating the FPGA-specific fine structure of look-up tables, registers, and hard-function blocks. It is a formidable claim, but given the legacy of the team one has to take it seriously. And it is a claim that gives some meaning to that very slippery word, automatic.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.