2 ms·
On-chip flash would still be susceptible to whether the CPU uses burst accesses or other weird microarchitectural details. The former manifests as the 8th or 16
by AlotOfReading 4y ago
On-chip flash would still be susceptible to whether the CPU uses burst accesses or other weird microarchitectural details. The former manifests as the 8th or 16th instruction having slightly higher real latency, for example. This sort of stuff is endless, which is why stuff like TFA that gets around the issue by simply removing the data dependencies before they ever get to the hardware is a better general approach if you're not going to do ASICs.
- kragen 4y agoSlightly higher real latency? Are you talking about asynchronous CPUs like the GreenArrays GA144? Or saying that if you're running off the internal RC oscillator the clock speed will vary because the supply voltage varies depending on memory access patterns? Or by "slightly higher real latency" do you mean that an instruction will take 2 clock cycles instead of 1 or 3 cycles instead of 2? I don't think any of those are true on things like the ATMega328 AVR8 mentioned above or the Padauk PMS150C. Maybe you mean something else? Bitbanging protocols with tight timing requirements using cycle-accurate code is still a thing people routinely do on small microcontrollers, and it wouldn't work if instruction timing was as unpredictable as you're saying. Nevertheless, I agree that removing data-dependent branches is a better way to close timing leaks.