4 ms·

No, still true - you’re never going to beat the determinism, size, and power of a few flops and some logic to drive a common interface directly compared to a fu

No, still true - you’re never going to beat the determinism, size, and power of a few flops and some logic to drive a common interface directly compared to a full core with architectural state and memory. E.g., just to enter an interrupt is 10-15 odd cycles, a memory access or two to set a pin, and then 10-15 cycles again to restore and exit. Additionally, micros have to be much robust electrically than a cutting edge (or even 14 nm) CPU/GPU and available for extended (decade) timespans so the economics driving the shrink are different. Small, fast cores have eaten the lunch of e.g. large dedicated DSP blocks for sure but those are niche cases where the volume is low so eventually the hardware cost and cost to develop on weird architectures costs more than running a general purpose core.

fidotron 2y ago
> No, still true - you’re never going to beat the determinism, size, and power of a few flops and some logic to drive a common interface directly compared to a full core with architectural state and memory. But you must know what you intend to do when designing the MCU, and history shows (and some of the questioning here also shows) that this isn’t the case. As you point out expected lifespans are long, so what is a designer to do? The ESP32 case is interesting because it comes so close, to the point I believe the RMT peripheral probably partly inspired the PIO, thanks to how widely it has been used for other things and how it breaks. The key weakness of the RMT is it expects the conversion of the data structures to be used to control it to be prepared in memory already, almost certainly by the CPU. This means that to alter the data being sent out requires the main app processor, the DMA and the peripheral to be involved, and we are hammering the memory bus while doing this. A similar thing occurs with almost any non trivial SPI usage where a lot of people end up building “big” (relatively) buffers in memory in advance. Both of those situations are very common and bad. Assuming the tiny cores can have their own program memory they will be no less deterministic than any other sort of peripheral while radically freeing up the central part of the system. One of the main things I have learned over the years is people wildly overstate the cost of computation and understate the cost of moving data around. If you can reduce the data a lot at the cost of a bit more computation that is a big win.
- awjlogan 2y ago
  > But you must know what you intend to do when designing the MCU, and history shows (and some of the questioning here also shows) that this isn’t the case. As you point out expected lifespans are long, so what is a designer to do? Designers do know that UARTs, SPIs, I2C, timers etc will be around essentially forever. Anything new has to be so much faster/better, the competition being the status quo and its long tail, that you would lay down a dedicated block anyway. I think we'll disagree, but I'm not convinced by many of the cases given here (usually DVI on an RP2040...) as you would just buy a slightly higher spec and better optimised system that has the interface already built in. Personal opinion: great fun to play with and definitely good to have a couple to handle niche interfaces (e.g. OneWire), but not for majority of use cases. > A similar thing occurs with almost any non trivial SPI usage where a lot of people end up building “big” (relatively) buffers in memory in advance. This is neither here nor there for a "PIO" or a fixed function - there has be state and data somewhere. I would rather allocate just what is needed for e.g. a UART (on my weapon of choice, that amounts to a heady 40 bits local to the peripheral written once to configure it, overloaded with SPI and I2C functionality) and not trouble the memory bus other than for data (well said on data movement, burns a lot and it's harder to capture). > Assuming the tiny cores can have their own program memory they will be no less deterministic than any other sort of peripheral while radically freeing up the central part of the system. Agreed, only if it's dedicated to a single function of course otherwise you have access contention. And, of course, we already have radically freed up the central part of the system :P Regardless, enjoyed the conversation, thank you!
  - fidotron 2y ago
    > Regardless, enjoyed the conversation, thank you! Likewise, very much so!
kragen 2y ago
If you have a programmable state machine that's waiting for a pin transition, it can easily do the thing it's waiting to do in the clock cycle after that transition. It doesn't have to enter an interrupt handler. That's how the GA144 and the RP2350 do their I/O. Padauk chips have a second hardware thread and deterministically context switch every cycle, so the response latency is still less than 10–15 cycles, like 1–2. I think old ARM FIQ state also effectively works this way, switching register banks on interrupt so no time is needed to save registers on interrupt entry, and I think the original Z80 (RIP this year) also has this feature. Some RISC-V cores (CH32V003?) also have it. An alternate register bank for the main CPU is bigger than a PWM timer peripheral or an SPI peripheral, sure, but you can program it to do things you didn't think of before tapeout.

fidotron 2y ago

> No, still true - you’re never going to beat the determinism, size, and power of a few flops and some logic to drive a common interface directly compared to a full core with architectural state and memory. But you must know what you intend to do when designing the MCU, and history shows (and some of the questioning here also shows) that this isn’t the case. As you point out expected lifespans are long, so what is a designer to do? The ESP32 case is interesting because it comes so close, to the point I believe the RMT peripheral probably partly inspired the PIO, thanks to how widely it has been used for other things and how it breaks. The key weakness of the RMT is it expects the conversion of the data structures to be used to control it to be prepared in memory already, almost certainly by the CPU. This means that to alter the data being sent out requires the main app processor, the DMA and the peripheral to be involved, and we are hammering the memory bus while doing this. A similar thing occurs with almost any non trivial SPI usage where a lot of people end up building “big” (relatively) buffers in memory in advance. Both of those situations are very common and bad. Assuming the tiny cores can have their own program memory they will be no less deterministic than any other sort of peripheral while radically freeing up the central part of the system. One of the main things I have learned over the years is people wildly overstate the cost of computation and understate the cost of moving data around. If you can reduce the data a lot at the cost of a bit more computation that is a big win.

awjlogan 2y ago
> But you must know what you intend to do when designing the MCU, and history shows (and some of the questioning here also shows) that this isn’t the case. As you point out expected lifespans are long, so what is a designer to do? Designers do know that UARTs, SPIs, I2C, timers etc will be around essentially forever. Anything new has to be so much faster/better, the competition being the status quo and its long tail, that you would lay down a dedicated block anyway. I think we'll disagree, but I'm not convinced by many of the cases given here (usually DVI on an RP2040...) as you would just buy a slightly higher spec and better optimised system that has the interface already built in. Personal opinion: great fun to play with and definitely good to have a couple to handle niche interfaces (e.g. OneWire), but not for majority of use cases. > A similar thing occurs with almost any non trivial SPI usage where a lot of people end up building “big” (relatively) buffers in memory in advance. This is neither here nor there for a "PIO" or a fixed function - there has be state and data somewhere. I would rather allocate just what is needed for e.g. a UART (on my weapon of choice, that amounts to a heady 40 bits local to the peripheral written once to configure it, overloaded with SPI and I2C functionality) and not trouble the memory bus other than for data (well said on data movement, burns a lot and it's harder to capture). > Assuming the tiny cores can have their own program memory they will be no less deterministic than any other sort of peripheral while radically freeing up the central part of the system. Agreed, only if it's dedicated to a single function of course otherwise you have access contention. And, of course, we already have radically freed up the central part of the system :P Regardless, enjoyed the conversation, thank you!
- fidotron 2y ago
  > Regardless, enjoyed the conversation, thank you! Likewise, very much so!

kragen 2y ago

If you have a programmable state machine that's waiting for a pin transition, it can easily do the thing it's waiting to do in the clock cycle after that transition. It doesn't have to enter an interrupt handler. That's how the GA144 and the RP2350 do their I/O. Padauk chips have a second hardware thread and deterministically context switch every cycle, so the response latency is still less than 10–15 cycles, like 1–2. I think old ARM FIQ state also effectively works this way, switching register banks on interrupt so no time is needed to save registers on interrupt entry, and I think the original Z80 (RIP this year) also has this feature. Some RISC-V cores (CH32V003?) also have it. An alternate register bank for the main CPU is bigger than a PWM timer peripheral or an SPI peripheral, sure, but you can program it to do things you didn't think of before tapeout.