Way back in October, we blogged about the differences between our logic cell design and that of competitors in the mobile programmable logic space. I thought I’d take some time to revisit the topic, and go more in depth as to what advantages this offers mobile OEMs.
For comparisons sake, let’s compare QuickLogic against a Lattice mobile programmable logic device, of course using their standard logic cell architecture. For all the reasons discussed in the October blog, our logic cell allows a much greater degree in flexibility of function. Moving that to a real-world scenario, lets say that an OEM wants to employ a programmable logic cell device into their design. We chose five different typical uses of programmable fabric that vary in size; a clock divider, an I2S to PCM bridge, an 11-bit x 11-bit multiplier, a 16550 UART, and a managed NAND Flash Controller. The amount of logic cells required to implement those functions on the programmable device is going to vary — and as you can imagine, the variance isn’t trivial.
As shown in the application note found here, this is what our testing showed:
Essentially, on average, QuickLogic requires less than 50% of the logic cells the competitor does to implement the same technologies.
And, before the shouts of “FIXED!” cascade down from the rafters, here is how we came up with these numbers:
- We started with the two most comparable devices: the QuickLogic PolarPro 3 (1019 logic cells) and the Lattice iCE40LP1K (1280 logic cells).
- We used the exact same RTL, which is not technology dependent
- We generated the design files for both QuickLogic and the Lattice device using that companies standard tools (QuickLogics SpDE version 2013.1.2 and Lattice’s iCECube 2 version 2013.3.23358)
Lets tie all this to customers and how this helps them:
While both our PolarPro 3 and Lattice’s iCE40 have multiple packages available to suit OEMs differing needs for small size and # of I/O, a good point of comparison between the two is QuickLogic’s 2.09 x 2.54mm WLCSP and Lattice’s 2.5 x 2.5mm BGA. Now, say a customer needed two of the 16550 UARTs and a single 11 x 11-bit multiplier for their product:
- On the QuickLogic device, that design would take 593 logic cells, leaving 426 still open for other functions, all in the 2.09 x 2.54mm package
- However, this design isn’t possible on the 1280 logic cell Lattice device, as they would require 1364 logic cells to meet these needs. To be fair, they can meet the requirements with their 2K (or 4K) device — but that device is likely more expensive and/or larger.
Depending on your view of half-full or half-empty, QuickLogic can offer either more functionality per PCB area, or offer the same functionality in a smaller area. Your choice on how you see it — either way, its a distinct advantage for QuickLogic, and one we intend to continue to capitalize on.
4 thoughts on “Effective Logic Cells — Why All Logic Cells Aren’t the Same”
Hi Paul –
Would be interested in your response to this statement —
“Overall, the MCU approach will be the best-performing, most flexible solution for high-end handsets and tablets for several development generations to come, noted Tom Hackenberg, senior analyst for MCUs & microprocessors at IHS.”
Since the “MCU approach” substantially underforms the S1 on both power and flexibility, I am left wondering if the author of this article is even aware of your solution.
Taken from this Digitimes article —
Bob I saw the same thing as you and not even a mention and that is what led me here today.
Who is in charge of PR and same for sales?
I think Kim Jerome and Bob G have a great question. What about this??
Apologies for the delay in answering — I was outside of the country for the last couple of days.
I believe the author is aware of our solution, as FPGA-based solutions are mentioned. However, we respectfully disagree with the authors market assessment of them.
Regarding the quote: MCUs, due to their high horsepower (with the drawback of associated high power consumption), are well suited to random decision making tasks – which is why we proposition our device as way to offload always-on repetitive processing, and keep the random decision making tasks at a higher level (whether it be the AP, or an MCU, given the OEM preference). There is actually a great 3rd party article that was just published today which illustrates this quite well – you can find it at http://www.eejournal.com/archives/articles/20140421-quicklogic/