Back in the good old days of semiconductors (meaning more than one to two decades ago), following Moore’s Law down the process geometry curve gave digital semiconductor companies not only increased logic density, but also lower operating voltages. Five volt supply requirements became 3.3 volts, then 2.5 volts and then 1.8 volts and so on. Since power is partly a function of voltage, the lower supply voltages meant that power consumption per unit of functionality fell accordingly and for a while all was good and right in the world.
However, with the advent of deep sub-micron process geometries and their resulting super-slim gate oxide thicknesses, leakage currents began to creep up and make life more and more difficult for chip designers. At the same time, demand for mobile devices increased exponentially causing consumers to demand dramatically lower device-level power consumption to gain increased batter life.
This dilemma has forced chip architects and designers to get creative. Certain circuit design and layout techniques can mitigate the leakage issue, but not nearly enough to solve the problem completely. To dramatically reduce power consumption, engineers have had to attack the problem more comprehensively. I’ll use QuickLogic’s new EOS 3 Sensor Processing Platform as an example.
In addition to the circuit design techniques mentioned above, we used three main approaches to reduce power consumption. The first was to “harden” certain key functions (see https://www.quicklogic.com/eos for a list) that we knew most users would want, as embedding these functions will always be more power efficient than implementing them in programmable logic. The second was to provide a specialized processor (in the form of our Flexible Fusion Engine) which is more power efficient than a general purpose MCU. The third was to design our sensor algorithms to minimize power consumption through optimal design partitioning across the platform’s M4-F Cortex processor, Flexible Fusion Engine, other embedded functions, and general-purpose programmable logic.
This holistic approach (circuit, architecture, embedded functionality, and efficient algorithm implementation) is the only way to achieve the dramatic level of power reduction required by OEMs to support their most advanced applications and by end customers to support their demanding battery life expectations. Thus a broad system-level approach based on a deep engineering understanding of how the devices works in real applications yields a comprehensive solution which in turn yields lower power consumption and a longer battery life. In other words, knowledge truly is reduced power.
Nice explanation. Two questions. Is “Tim” with Quicklogic and is anybody buying this alternative technology? Sounds like OEM’s should be beating a path to Quicklogic’s door!
Dr. Saxe, could you provide the voltage levels lower than the 1.8V you mentioned in your post, and what current industry on-chip voltage levels are, including the EOS S3?
Also, I’m interested in how you are able to have a “programmable” clock frequency? Isn’t that just a choice between pre-set clock frequency “options”? What are those options?
In the 65nm to 40nm range the typical on-chip operating voltage is 1.0v to 1.2v. Frequently these voltages are derived from a high voltage, such as 1.8V, using on chip regulators.
We use a frequency generator that uses a 32,768Hz clock as a reference. Therefor it can produce any frequency between about 2.1MHz and 81MHz that is an exact multiple of 32.786kHz. So yes, it is choosing between “options”, but there are 24,000 such options.
Thank you, Dr. Sax.
24,000 possible settings? That is amazing. I was expecting 3 or 4 to maybe 10 settings. That obviously is “tunable” to the exact minimum setting needed to do the job effectively. Go up a notch if a bit more code is added. I believe the 32kHz was the original speed of the S1, if I remember correctly. You have come a long way with the EOS S3. This chip should be a big winner in the market over the next year. Good luck to you all at QuickLogic.
I imagine that one speed setting can be set when processing the data from one sensor, and a different speed when processing another. This makes perfect sense, as monitoring blood pressure is much less intensive than processing audio. The more I see and hear of the EOS S3 design, the more I like it.