3 ms·

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 i

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)
- MootWoop 12y ago
  Yes I'm the author, and no problem :-) If you find HDLs awful, I'd be curious to know what you think of our language, Cx. Maybe we can continue this conversation somewhere else?
  - pjc50 12y ago
    Running short on time. I have a laundry list of Verilog replacement suggestions on another machine somewhere. Brief observations on Cx: Based on C. Two objections: (1) why not SystemC? (2) why C when the non-HDL world is trying to get as far from C as possible? My personal prejudice would be for functional rather than imperative style. AFAIK nobody is seriously attempting this outside of academia: http://essay.utwente.nl/59482/ http://essay.utwente.nl/59482/ Saw an example with "new" and "import" which are kinda Java flavoured. "new" feels wrong for hardware: no allocation or gc! Plus points for ngDesign. Another plus point for trying to get hardware designers to use git rather than clearcase or other abominations. Good that you're leaning on the verification angle. I spent a decade in an EDA startup. It was a tough market but interesting work. Good luck!
    - poseid 12y ago
      I think a nice approach to describe HW + visual systems is kind of patterns. Similar to what is done in this project to describe waveforms: http://wavedrom.com/ http://wavedrom.com/
    - MootWoop 12y ago
      Thanks for your feedback and encouragement! I'll try to shine some light on Cx. This comment has become a bit of a rant as a consequence, I hope you'll forgive me :) Cx is not so much C-based as C-like, and the difference is subtle but real. It's a dedicated language looking like C (and yes, a bit like Java) rather than something based on C, because bending an existing language backwards and using a small subset of it just doesn't feel right. Same reason why not SystemC: SystemC is your typical design-by-committee/the-enterprise horror, it's verbose, and it's just a tiny, weird subset of C++ with a lot of templates. How do you know what you're supposed to use to get something "synthesizable"? Another big problem with SystemC, just like any HDL, almost all of them are mainly simulation languages. We created something C-like to have something that most people would find easy to start using; the C-like "curly" syntax is familiar to any developer (even JavaScript uses that). Same reason to go with imperative rather than functional: it's the paradigm that most people are comfortable using (not to mention that functional programming is not really a good metaphor for what happens in hardware - after all, a state machine is a sequence of things that modify state). The article you linked shows an interesting approach, but I believe it will remain a niche, kind of like functional programming in software (possibly even more so given the large difference in abstraction level). Yes the "new" may seem surprising at first, yet it has the same meaning it has in other languages: it creates a new instance of an object, it's just that instances are created and connected at compile time rather than at runtime. We could have done without it, but I've found myself confused about what goes first in VHDL and Verilog enough times that I felt it was needed :-) I think I will write a blog post on this, and link it on Hacker News one of these days! And if you want to have a chat, just send me an email or a PM on our forum.
- cordite 12y ago
  Updating wirelessly is also a possibility, not for ASICs, but BT low energy can make it feasible if you do something like a mesh network. Of course, that means if one device is susceptible, others networked may be too. I don't really have a solution, but if you are interested in playing around with that kind of concept, here's something you can probably start with. [1] The battery lasts about a year or more, supposedly, with a typical watch-kind battery. It isn't too hard to update and it has a few sensors on it already. [1]: https://punchthrough.com/bean/ https://punchthrough.com/bean/

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)

MootWoop 12y ago
Yes I'm the author, and no problem :-) If you find HDLs awful, I'd be curious to know what you think of our language, Cx. Maybe we can continue this conversation somewhere else?
- pjc50 12y ago
  Running short on time. I have a laundry list of Verilog replacement suggestions on another machine somewhere. Brief observations on Cx: Based on C. Two objections: (1) why not SystemC? (2) why C when the non-HDL world is trying to get as far from C as possible? My personal prejudice would be for functional rather than imperative style. AFAIK nobody is seriously attempting this outside of academia: http://essay.utwente.nl/59482/ http://essay.utwente.nl/59482/ Saw an example with "new" and "import" which are kinda Java flavoured. "new" feels wrong for hardware: no allocation or gc! Plus points for ngDesign. Another plus point for trying to get hardware designers to use git rather than clearcase or other abominations. Good that you're leaning on the verification angle. I spent a decade in an EDA startup. It was a tough market but interesting work. Good luck!
  - poseid 12y ago
    I think a nice approach to describe HW + visual systems is kind of patterns. Similar to what is done in this project to describe waveforms: http://wavedrom.com/ http://wavedrom.com/
  - MootWoop 12y ago
    Thanks for your feedback and encouragement! I'll try to shine some light on Cx. This comment has become a bit of a rant as a consequence, I hope you'll forgive me :) Cx is not so much C-based as C-like, and the difference is subtle but real. It's a dedicated language looking like C (and yes, a bit like Java) rather than something based on C, because bending an existing language backwards and using a small subset of it just doesn't feel right. Same reason why not SystemC: SystemC is your typical design-by-committee/the-enterprise horror, it's verbose, and it's just a tiny, weird subset of C++ with a lot of templates. How do you know what you're supposed to use to get something "synthesizable"? Another big problem with SystemC, just like any HDL, almost all of them are mainly simulation languages. We created something C-like to have something that most people would find easy to start using; the C-like "curly" syntax is familiar to any developer (even JavaScript uses that). Same reason to go with imperative rather than functional: it's the paradigm that most people are comfortable using (not to mention that functional programming is not really a good metaphor for what happens in hardware - after all, a state machine is a sequence of things that modify state). The article you linked shows an interesting approach, but I believe it will remain a niche, kind of like functional programming in software (possibly even more so given the large difference in abstraction level). Yes the "new" may seem surprising at first, yet it has the same meaning it has in other languages: it creates a new instance of an object, it's just that instances are created and connected at compile time rather than at runtime. We could have done without it, but I've found myself confused about what goes first in VHDL and Verilog enough times that I felt it was needed :-) I think I will write a blog post on this, and link it on Hacker News one of these days! And if you want to have a chat, just send me an email or a PM on our forum.
cordite 12y ago
Updating wirelessly is also a possibility, not for ASICs, but BT low energy can make it feasible if you do something like a mesh network. Of course, that means if one device is susceptible, others networked may be too. I don't really have a solution, but if you are interested in playing around with that kind of concept, here's something you can probably start with. [1] The battery lasts about a year or more, supposedly, with a typical watch-kind battery. It isn't too hard to update and it has a few sensors on it already. [1]: https://punchthrough.com/bean/ https://punchthrough.com/bean/