A number of projects out there are building clockless chips. There is now even a commercial clockless chip designed for embedded systems:
formatting link
In what ways do you think, it will affect current embedded-systems programming techniques? I figure that computing upper bounds for execution times will be a pain now. And I hope that there are legacy interfaces for PWM, timers etc. But what about in-circuit debugging? What about compilers? Will there be additional burden when programming them? Will it remain the same at the assembly level?
"Clockless" is a poor word to choose. Better is Self paced, or granular clocked - what has gone is the global CPU clock. A Clock will still be connected to the Timers/UART/PWM modules, and even (optionally) to the CPU itself ( see below).
There are actually two, ARM9 and 80C51 : More info is at
formatting link
formatting link
This second one has a very good example of the same code's Icc/EMC/Joule footprints.
Not really more than before - all those branches in SW, make SW hard to define bounds on anyway.
Of course. Just because the core is async, does not mean time has gone away
Why should that change at all ? - these core are the SAME OPCODES. ie They are binary comppatible, in the true sense of the term.
If you look at the Async 80C51, they have a BIT to choose between Async, and clock-paced. You use the latter for code where time-path matters (rare, but important - eg Bit-bang Dallas 1 wire interfaces), and the Async for the rest.
In many cases, code will get easier to write, as you will not need to skip into/out-of IDLE, or change clock gears, to save power.
When the core is done, it self-sleeps.
If you are doing a JNB Flag,$ wait, then only that opcode is 'alive'. Supported with a tiny cache, only a small, local area of the die needs to be alive at all.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.