WP_Term Object
    [term_id] => 65
    [name] => Menta
    [slug] => menta
    [term_group] => 0
    [term_taxonomy_id] => 65
    [taxonomy] => category
    [description] => 
    [parent] => 36
    [count] => 5
    [filter] => raw
    [cat_ID] => 65
    [category_count] => 5
    [category_description] => 
    [cat_name] => Menta
    [category_nicename] => menta
    [category_parent] => 36
    [is_post] => 1

Why Embedded FPGA is a New IP Category?

Why Embedded FPGA is a New IP Category?
by Eric Esteve on 07-14-2017 at 12:00 pm

Yes, embedded FPGA is clearly an IP function, or design IP, and not a software tool or anything else. The idea to embed an FPGA block into an ASIC is not new, I remember the discussions we had in the ASIC marketing team when I was working for Atmel, back in 2000. What is new is the big interest for eFPGA in the semiconductor industry, even if a company like Menta is now 10 years old and propose today the 4[SUP]th[/SUP] version of their eFPGA product.

We can see two main approaches for the eFPGA offering: The first comes from an FPGA vendor, who decide to “cut” an FPGA block in a standard FPGA product and deliver this as a FPGA IP. The other approach is to design from scratch a family of eFPGA IP, all based on the same architecture but of various size. In the first case, the FPGA block will be based on cells designed specifically to build the FPGA parent product, or full custom cells. Full custom cells have been designed using the design rules of a specific technology node developed by a specific foundry. If your design targets this precise node and this precise foundry, no problem. Now, when the eFPGA block has been designed to be an IP, it also can be based on full custom cells targeting a specific node/foundry, but not necessarily.

Menta has taken another approach, design their eFPGA IP based on standard cells. Obviously, the design is still linked with a specific node/foundry, but we will see how it makes a difference when the ASIC embedding the eFPGA IP targets a different node/foundry.

Let’s have a look at the numerous benefits offered by the integration of an eFPGA IP into an ASIC, compared with an ASIC based solution, an FPGA based solution, or a mixed of two, ASIC plus FPGA standard product.

The pure ASIC solution will always be the less expensive, offering higher performance and lower power consumption. But, if you need flexibility, to support evolving standard or to adapt neural network algorithms after running a learning phase, to take a few examples, you would need to re-spin the ASIC. Re-spin is just prohibitive, in terms of development cost and Time-to-Market. OK, let’s go to an FPGA solution!

The FPGA technology is fully flexible as the device is (infinitely) re-configurable and this is one of the reasons why FPGA have been widely adopted in networking or communication (base stations) applications, to name a few. This flexibility is not for free, in term of power consumption and device cost. The device configuration, including internal interconnections, is usually loaded at start-up in SRAM memory, leading to an extra power consumption on top of the internal logic. Some FPGAs are supporting very complexes applications, leading to high power consumption… and high device ASP, several $100’s, if not $1000’s.

That’s why it could be a good option to integrate the stable logic functions into an ASIC and complete the design with a smaller FPGA. This solution will probably lead to a cheaper total cost of ownership, especially if the ASIC maybe be reused from a previous generation. In this case, one drawback may come from the power dissipated in the interfaces between the ASIC and the FPGA, usually multiple I/Os based on high speed SerDes (10 Gbps) to support the high bandwidth requirement of networking or data center. The other drawback is probably the total cost of the two devices.

Now, if your architecture is based on a large ASIC plus a companion FPGA, needed to bring flexibility, you should consider the embedded FPGA solution. When the FPGA logic is embedded in the SoC, the communication between the eFPGA and the SoC is made through internal signals with two main consequences. At first, you may use as many signals to interface the eFPGA, as you are no more limited by the chip size (I/O limited FPGA). But the most important gain is the much lower power consumption of internal signaling compared with external I/O, function of the capacitance. To evaluate the cost benefit, you will need to think in term of total cost of ownership, adding the IP license price to the SoC NRE, as well as the royalty paid to Menta, but I am sure that in 95% of the cases, this single chip solution cost will be lower than the SoC plus FPGA.

Let’s come back to the eFPGA technology and evaluate the impact of the selected vendor on the Time-to-Market. The eFPGA IP from Menta is unique, and for two reasons: the FPGA logic is based on standard cells and not on full custom designed cells, and the FPGA configuration is stored in registers instead of SRAM. To design an eFPGA block on a specific node, Menta is using pre-characterized, validated cells, even if the IP is delivered as a hard macro (GDSII) to guarantee the timing and functionality in any case.

If a customer, for any reasons, has to target a technology node (or a foundry) where the Menta eFPGA is not yet available, the process is simple. Menta must port the IP, using already validated cells, on the new node, and run IP qualification. If you compare this process with a complete redesign and qualification of all the full custom cells to port the eFPGA IP, and IP qualification, no doubt that the Menta approach is offering a faster Time-to-Market when selecting a new node/foundry. And safer as well, as the risk is minimized when using standard cells.

As far as I am concerned, I really think that the semiconductor industry will adopt eFPGA when adding flexibility to a SoC is needed. The multiple benefits in term of solution cost and power consumption should be the drivers, and Menta is well positioned to get a good share of this new IP market.

From Eric Esteve from IPnest