6 ms·

Integrated Circuit design for the IoT

47 points by MootWoop 12y ago

leppie 12y ago
Author misinterpreted specs... "Each packet has 20 bytes of useful payload and consumes 49 μA at 3 V" That is a manufacture average for some profile, mostly sleeping 99% of the time. The real consumption during broadcast is in the order of 15-20mA for most chip I have seen. Here is a very informative article dealing with power demands of low power devices: www.ganssle.com/reports/ultra-low-power-design.html
- MootWoop 12y ago
  Thanks for the link, indeed it looks quite technical and very complete on the subject. Truth be told I'm far from an expert on power, hence the mistake :-)
- Gurkenmaster 12y ago
  Considering the 1 minute interval wouldn't it be better for the battery to use a clock implemented in hardware that boots the chip everytime it's needed?
  - unwind 12y ago
    That is typically what you do, microcontrollers have timers and low-power mode(s) which keep the timers running even though the processor core isn't executing any instructions.
  - MootWoop 12y ago
    I'm not an expert on power optimization, and I don't know how this is done in micro-controllers. But I would think that the hardware clock would be implemented using integrated analog components (capacitor + resistor circuit) rather than digital logic, to avoid repeatedly switching on and off even just a few transistors.
    - pjc50 12y ago
      Apparently external xtal is marginally best (http://www.microchip.com/forums/m341592.aspx); http://www.microchip.com/forums/m341592.aspx); which makes intuitive sense, given that it's exactly the same scenario as a digital watch. 32khz crystal; driver; counter; comparator. Few hundred tiny transistors. Consumption probably less than battery self-discharge.
    - BostonEnginerd 12y ago
      The power needed to keep the analog comparator going will probably be higher than keeping the 32kHz clock running.
pjmlp 12y ago
Quite right. Maybe the best approach is to use a modern IoT board to prototype the design and then port it to a PIC microcontroler/ASIC for the production design.
poseid 12y ago
Hm.. as hardware becomes a commodity, I don't think that custom designs can beat the commodity price point. What would be helpful, more web/interactive kind of tools to make hardware better accessible. For example, simple power calculators, that would compare the power consumption of an Arduino with special low-power devices. Or, how a 5V system compares to a 3V or 1.2V.
- timthorn 12y ago
  The economics all depends on volumes, of course.
  - poseid 12y ago
    right, and volumens again depend on joining the right hardware platforms/alliances, at least for current semiconductor companies.
  - poseid 12y ago
    but what would be really interesting would be to see open-source hardware development, similar to a Linux kernel
    - MootWoop 12y ago
      exactly, and there are some open-source hardware designs (on sites like OpenCores), but the problem is that with existing hardware description languages very few people are able to reuse and contribute to these. This is why we've created the Cx language, to make it easier to design hardware for developers, and not just hardware designers. We've open sourced the compiler; and we've designed some open-source hardware in Cx, see for example our Ethernet MAC: https://github.com/synflow/ethernet-mac https://github.com/synflow/ethernet-mac
      - poseid 12y ago
        interesting how you generate blocks from the language: http://cx-lang.org/documentation/structure http://cx-lang.org/documentation/structure - I guess visual feedback would make the language attractive to non-HW designers. I gave a small talk once on sharing HW projects in the browser: https://speakerdeck.com/mulderp/sharing-hardware-with-javascript https://speakerdeck.com/mulderp/sharing-hardware-with-javasc... - of course this is a different level, but still, having web/svg kinds of HW representations would be interesting. I guess for HW, good representations of schematics/waveforms are at least as important as he actual HDL, but I might be wrong.
kabouseng 12y ago
Developing an ultra low power design is not a trivial task. It is here where you discover the manufacturer datasheet somehow achieves figures you just for the live of you cannot achieve, even with their reference designs and evaluation kits. You can spend an entire month just adjusting the state of the various pins on your device to shave off uA's, and just when you have hit your power consumption target, you realise your product now doesn't always boot up or suffers from latch up in some circumstances / temperatures. Also this article does not take into consideration that the little CR2032 has internal leakage, your circuit has leakage currents and when transmitting you are suddenly pulling a lot more current out of the battery, so it wouldn't deliver that full 230mAh (but he did say it is hypothetical). Getting even 2 years of operation out of any of the CR range of batteries is already a feat. -edit typo
- joezydeco 12y ago
  The Jack Ganssle article linked in his post (see below) does an excellent job of covering the issues of CR2032 battery performance, parasitic power loss, and etc.
pjc50 12y ago
Why not design your own integrated circuit? Now you too can have the thrill of extra capital and technical risk in your project! It has the added benefits of setting your architecture in stone and preventing any kind of pivot while hindering future expansion. Seriously, you need a good reason to believe you can do better than the chip companies before designing your own ASIC as a commercial project. Low power is not the right end to do this at. The interesting case is when you need moderate computing power for a special task at better compute/watt than general purpose hardware. That's what provoked the wave of bitcoin miner startups.
- MootWoop 12y ago
  You're right, you only consider designing an ASIC if it's guaranteed to be more interesting than other options. Note that the capital and risk are not so high if you use an older, proven technology (like 90nm) which should be more than enough for IoT-like devices. Low power only may not be sufficient in itself to require an ASIC, but as you say it all depends on the computing power that is required. Which for a temperature sensor is close to nothing... I'll need a better example for the next article!
  - pjc50 12y ago
    You're the original author? Sorry about the sarcasm :) A couple of years ago I was involved with a project doing verification of a custom CPU design for IoT purposes based on the 6502. There were a lot of frustrated discussions in the breakroom as we couldn't really see the point of the customness of this technology. Should we tell the client? In the end we didn't and the client went bust before paying our invoice. Yes, the thing about temperature sensors and the like is that they're just a wireless peripheral. Eventually one of the competing standards will win (6lowpan?) and they can be as commoditised as bluetooth headsets. The important thing about IoT is turning a demo gimmick into a value proposition with satisfactory UX. Home automation has been around as a concept for years and remained a niche. There might be a market in custom hardware for "security done right" for IoT. Never mind changing the batteries, I don't want to have to update the firmware in my lightbulbs (or doorlocks!) every few weeks due to exploits. (I could write a whole other post agreeing with you about how HDLs are universally awful)
quarterwave 12y ago
The impedance of free space is (unfortunately) a few hundred ohms. On top of this, the minimum signal voltage of analog integrated circuits is set by unsystematic (random) offsets, which get worse as transistor sizes shrink. It's possible to mitigate these offsets by circuit techniques, but they cannot be eliminated. Near-field radio can break free of the impedance constraint (which applies only to far-field TEM waves), but antenna area sets signal level, as in flux=intensity*area. Why make a tiny chip when the antenna needs to be the size of a quarter? It's not easy to design radio chips for either of these scenarios. Pushing the radio burden onto the DSP consumes power on the digital side, so no easy way out. [Aside: Referring to a recent thread on measurement of the Planck constant, the ratio of the impedance of free space to the Hall resistance turns out to be the dimensionless fine structure constant, alpha. This alpha sets the coupling strength of an electron and photon in the quantum theory of electrodynamics, and the 'Taylor series' for the self-energy of an electron converges because alpha is much less than unity. Feynman diagrams are a way to keep track of terms in that Taylor series, to ensure that the Schrodinger equation is kept consistent with special relativity, etc.]

47 points by MootWoop 12y ago

Author misinterpreted specs... "Each packet has 20 bytes of useful payload and consumes 49 μA at 3 V" That is a manufacture average for some profile, mostly sleeping 99% of the time. The real consumption during broadcast is in the order of 15-20mA for most chip I have seen. Here is a very informative article dealing with power demands of low power devices: www.ganssle.com/reports/ultra-low-power-design.html

MootWoop 12y ago
Thanks for the link, indeed it looks quite technical and very complete on the subject. Truth be told I'm far from an expert on power, hence the mistake :-)
Gurkenmaster 12y ago
Considering the 1 minute interval wouldn't it be better for the battery to use a clock implemented in hardware that boots the chip everytime it's needed?
- unwind 12y ago
  That is typically what you do, microcontrollers have timers and low-power mode(s) which keep the timers running even though the processor core isn't executing any instructions.
- MootWoop 12y ago
  I'm not an expert on power optimization, and I don't know how this is done in micro-controllers. But I would think that the hardware clock would be implemented using integrated analog components (capacitor + resistor circuit) rather than digital logic, to avoid repeatedly switching on and off even just a few transistors.
  - pjc50 12y ago
    Apparently external xtal is marginally best (http://www.microchip.com/forums/m341592.aspx); http://www.microchip.com/forums/m341592.aspx); which makes intuitive sense, given that it's exactly the same scenario as a digital watch. 32khz crystal; driver; counter; comparator. Few hundred tiny transistors. Consumption probably less than battery self-discharge.
  - BostonEnginerd 12y ago
    The power needed to keep the analog comparator going will probably be higher than keeping the 32kHz clock running.

pjmlp 12y ago

Quite right. Maybe the best approach is to use a modern IoT board to prototype the design and then port it to a PIC microcontroler/ASIC for the production design.

poseid 12y ago

Hm.. as hardware becomes a commodity, I don't think that custom designs can beat the commodity price point. What would be helpful, more web/interactive kind of tools to make hardware better accessible. For example, simple power calculators, that would compare the power consumption of an Arduino with special low-power devices. Or, how a 5V system compares to a 3V or 1.2V.

timthorn 12y ago
The economics all depends on volumes, of course.
- poseid 12y ago
  right, and volumens again depend on joining the right hardware platforms/alliances, at least for current semiconductor companies.
- poseid 12y ago
  but what would be really interesting would be to see open-source hardware development, similar to a Linux kernel
  - MootWoop 12y ago
    exactly, and there are some open-source hardware designs (on sites like OpenCores), but the problem is that with existing hardware description languages very few people are able to reuse and contribute to these. This is why we've created the Cx language, to make it easier to design hardware for developers, and not just hardware designers. We've open sourced the compiler; and we've designed some open-source hardware in Cx, see for example our Ethernet MAC: https://github.com/synflow/ethernet-mac https://github.com/synflow/ethernet-mac
    - poseid 12y ago
      interesting how you generate blocks from the language: http://cx-lang.org/documentation/structure http://cx-lang.org/documentation/structure - I guess visual feedback would make the language attractive to non-HW designers. I gave a small talk once on sharing HW projects in the browser: https://speakerdeck.com/mulderp/sharing-hardware-with-javascript https://speakerdeck.com/mulderp/sharing-hardware-with-javasc... - of course this is a different level, but still, having web/svg kinds of HW representations would be interesting. I guess for HW, good representations of schematics/waveforms are at least as important as he actual HDL, but I might be wrong.

kabouseng 12y ago

Developing an ultra low power design is not a trivial task. It is here where you discover the manufacturer datasheet somehow achieves figures you just for the live of you cannot achieve, even with their reference designs and evaluation kits. You can spend an entire month just adjusting the state of the various pins on your device to shave off uA's, and just when you have hit your power consumption target, you realise your product now doesn't always boot up or suffers from latch up in some circumstances / temperatures. Also this article does not take into consideration that the little CR2032 has internal leakage, your circuit has leakage currents and when transmitting you are suddenly pulling a lot more current out of the battery, so it wouldn't deliver that full 230mAh (but he did say it is hypothetical). Getting even 2 years of operation out of any of the CR range of batteries is already a feat. -edit typo

joezydeco 12y ago
The Jack Ganssle article linked in his post (see below) does an excellent job of covering the issues of CR2032 battery performance, parasitic power loss, and etc.

pjc50 12y ago

Why not design your own integrated circuit? Now you too can have the thrill of extra capital and technical risk in your project! It has the added benefits of setting your architecture in stone and preventing any kind of pivot while hindering future expansion. Seriously, you need a good reason to believe you can do better than the chip companies before designing your own ASIC as a commercial project. Low power is not the right end to do this at. The interesting case is when you need moderate computing power for a special task at better compute/watt than general purpose hardware. That's what provoked the wave of bitcoin miner startups.

MootWoop 12y ago
You're right, you only consider designing an ASIC if it's guaranteed to be more interesting than other options. Note that the capital and risk are not so high if you use an older, proven technology (like 90nm) which should be more than enough for IoT-like devices. Low power only may not be sufficient in itself to require an ASIC, but as you say it all depends on the computing power that is required. Which for a temperature sensor is close to nothing... I'll need a better example for the next article!
- pjc50 12y ago
  You're the original author? Sorry about the sarcasm :) A couple of years ago I was involved with a project doing verification of a custom CPU design for IoT purposes based on the 6502. There were a lot of frustrated discussions in the breakroom as we couldn't really see the point of the customness of this technology. Should we tell the client? In the end we didn't and the client went bust before paying our invoice. Yes, the thing about temperature sensors and the like is that they're just a wireless peripheral. Eventually one of the competing standards will win (6lowpan?) and they can be as commoditised as bluetooth headsets. The important thing about IoT is turning a demo gimmick into a value proposition with satisfactory UX. Home automation has been around as a concept for years and remained a niche. There might be a market in custom hardware for "security done right" for IoT. Never mind changing the batteries, I don't want to have to update the firmware in my lightbulbs (or doorlocks!) every few weeks due to exploits. (I could write a whole other post agreeing with you about how HDLs are universally awful)

quarterwave 12y ago

The impedance of free space is (unfortunately) a few hundred ohms. On top of this, the minimum signal voltage of analog integrated circuits is set by unsystematic (random) offsets, which get worse as transistor sizes shrink. It's possible to mitigate these offsets by circuit techniques, but they cannot be eliminated. Near-field radio can break free of the impedance constraint (which applies only to far-field TEM waves), but antenna area sets signal level, as in flux=intensity*area. Why make a tiny chip when the antenna needs to be the size of a quarter? It's not easy to design radio chips for either of these scenarios. Pushing the radio burden onto the DSP consumes power on the digital side, so no easy way out. [Aside: Referring to a recent thread on measurement of the Planck constant, the ratio of the impedance of free space to the Hall resistance turns out to be the dimensionless fine structure constant, alpha. This alpha sets the coupling strength of an electron and photon in the quantum theory of electrodynamics, and the 'Taylor series' for the self-energy of an electron converges because alpha is much less than unity. Feynman diagrams are a way to keep track of terms in that Taylor series, to ensure that the Schrodinger equation is kept consistent with special relativity, etc.]