Completely predictable instruction timing

[djnz]

This is a bit of a thought experiment / "in theory can we do this" type question. Let's assume that there is zero jitter in our system clock.
 
Are there any processors in which instructions always take the same time to run? I don't mean same number of cycles for each instruction, but rather, a completely predictable amount of time required for any particular instruction to complete (fetch + decode+ execute) irrespective of factors like pipeline stall etc.

[peter-h]

Z80 and many others of that era

[jnk0le]

All AVR8 mcu's were designed exactly like that (and most other 8/16 bitters), but you can do this even on lower end cortex-m/risc-v with 0ws flash, 0ws SRAMs and no DMA bursts stalling your busses

EDIT: not to mention the XMOS barrel processors, designed for implementing software peripherals. Where even the IDE can calculate the timmings of your code.

[SiliconWizard]

Almost anything not using a pipeline nor cache, so that restricts it to old devices these days or niche ultra-simple ones.

But it's still a matter of number of clock cycles.
Time doesn't magically elapse in any other kind of metric than clock cycles in a CPU, at least in a conventional digital CPU.

[amwales]

You can do reliable cycle counting with the 16bit dsPIC, very few gotchas, very well documented.

[tooki]

This is a bit of a thought experiment / "in theory can we do this" type question. Let's assume that there is zero jitter in our system clock.
 
Are there any processors in which instructions always take the same time to run? I don't mean same number of cycles for each instruction, but rather, a completely predictable amount of time required for any particular instruction to complete (fetch + decode+ execute) irrespective of factors like pipeline stall etc.

I’m not an expert on this, but I think that an instruction on any processor will always take the same amount of time to run, if the system state is identical.

Realistically, I think this is the domain of true real-time OSes. Hence the name. They’re commonly used for systems where absolutely deterministic behavior is required, like safety-critical telematics and avionics.

[tggzzz]

This is a bit of a thought experiment / "in theory can we do this" type question. Let's assume that there is zero jitter in our system clock.
 
Are there any processors in which instructions always take the same time to run? I don't mean same number of cycles for each instruction, but rather, a completely predictable amount of time required for any particular instruction to complete (fetch + decode+ execute) irrespective of factors like pipeline stall etc.

XMOS xCORE processors up to 32 cores 4000MIPs/chip do that. Buy them at DigiKey.

The toolsystem does more. The IDE will tell you the exact timing of all the flow control paths between here and there. That enables calculation of hard realtime behaviour; none of this measure and hope you ran across the worst case crap!e

That gives FPGA-like determinism.

BTW, you don't need an RTOS either; the fundamentals interprocess communication and scheduling are implemented in hardware.

[tggzzz]

Almost anything not using a pipeline nor cache, so that restricts it to old devices these days or niche ultra-simple ones.

But it's still a matter of number of clock cycles.
Time doesn't magically elapse in any other kind of metric than clock cycles in a CPU, at least in a conventional digital CPU.

XMOS xCORE are modern and not simple: 32 cores per 4000MIPS chip. Buy them at DigiKey. https://www.digikey.co.uk/en/supplier-centers/xmos

No pipeline.
No cache.
No interrupts.
RTOS implemented in Silicon.

What more could you want for hard realtime embedded?

[jpanhalt]

Are there any processors in which instructions always take the same time to run? I don't mean same number of cycles for each instruction, but rather, a completely predictable amount of time required for any particular instruction to complete (fetch + decode+ execute) irrespective of factors like pipeline stall etc.

For whether any MCU's always takes the same amount of time for any instruction, I don't know. But the time for various instructions is always defined and is predictable.  If you want to write isochronous code, regardless of branches, you may want to resort to Assembly.  In that language, at least with Microchip devices, it is quite easy to do.

[radiolistener]

This is a bit of a thought experiment / "in theory can we do this" type question. Let's assume that there is zero jitter in our system clock.

Zero jitter clock is impossible, it don't exist. All real-world clock sources exhibit some amount of timing variation, commonly referred to as jitter, which is typically characterized using RMS (Root Mean Square) or peak-to-peak values in the picosecond or femtosecond range.

However, the jitter introduced by general-purpose processor or FPGA GPIOs is often significantly higher. This is due to factors such as internal bus contention, variable instruction timing, and lack of dedicated clock routing. As a result, such sources often exhibit worse jitter performance than even low-cost oscillators based on digital synthesizers and PLL's.

[tggzzz]

Are there any processors in which instructions always take the same time to run? I don't mean same number of cycles for each instruction, but rather, a completely predictable amount of time required for any particular instruction to complete (fetch + decode+ execute) irrespective of factors like pipeline stall etc.

For whether any MCU's always takes the same amount of time for any instruction, I don't know. But the time for various instructions is always defined and is predictable.  If you want to write isochronous code, regardless of branches, you may want to resort to Assembly.  In that language, at least with Microchip devices, it is quite easy to do.

How long does it take to load a register from memory?
Will it take the same time the next time that instruction is executed?
Your answer should include the effects of caches (data, TLB, etc) and interrupts.

Hint: it is not possible with most modern processors.

[jpanhalt]

Are there any processors in which instructions always take the same time to run? I don't mean same number of cycles for each instruction, but rather, a completely predictable amount of time required for any particular instruction to complete (fetch + decode+ execute) irrespective of factors like pipeline stall etc.

For whether any MCU's always takes the same amount of time for any instruction, I don't know. But the time for various instructions is always defined and is predictable.  If you want to write isochronous code, regardless of branches, you may want to resort to Assembly.  In that language, at least with Microchip devices, it is quite easy to do.

How long does it take to load a register from memory?
Will it take the same time the next time that instruction is executed?
Your answer should include the effects of caches (data, TLB, etc) and interrupts.

Hint: it is not possible with most modern processors.

Define modern.   

Refer to pages 461-462 of this: (http://ww1.microchip.com/downloads/en/DeviceDoc/PIC16-L-F15324-44-data-sheet-40001889B.pdf).  Those timings are accurate.  None are ambiguous.  They define what you need to consider if there are branches.  Interrupt latency is also consistent, but if you want isochronous code, you need to consider that.

[tggzzz]

 

Are there any processors in which instructions always take the same time to run? I don't mean same number of cycles for each instruction, but rather, a completely predictable amount of time required for any particular instruction to complete (fetch + decode+ execute) irrespective of factors like pipeline stall etc.

For whether any MCU's always takes the same amount of time for any instruction, I don't know. But the time for various instructions is always defined and is predictable.  If you want to write isochronous code, regardless of branches, you may want to resort to Assembly.  In that language, at least with Microchip devices, it is quite easy to do.

How long does it take to load a register from memory?
Will it take the same time the next time that instruction is executed?
Your answer should include the effects of caches (data, TLB, etc) and interrupts.

Hint: it is not possible with most modern processors.

Define modern.   

Refer to pages 461-462 of this: (http://ww1.microchip.com/downloads/en/DeviceDoc/PIC16-L-F15324-44-data-sheet-40001889B.pdf).  Those timings are accurate.  None are ambiguous.  They define what you need to consider if there are branches.  Interrupt latency is also consistent, but if you want isochronous code, you need to consider that.

Modern: how about up to 4000MIPS, 32 core, scalable, 32 bit.

I'm not going to bother to look at the details of yet another me-too processor.

In hard realtime systems you are concerned with how long it take to get from this instruction to that instruction, in the worst case. That includes everything, including the effects of interrupts, caches, branches.

The XMOS xCORE hardware/software architecture allows the IDE to calculate that without running the code. Yes, that is - uniquely - possible. (Key point: no caches, with 32 cores interrupts aren't necessary)

Does the microchip IDE calculate that? Down to the processor cycle? No.

[David Hess]

8/16 bit PIC and 8 bit ARV have fixed instruction timing.

[PCB.Wiz]

This is a bit of a thought experiment / "in theory can we do this" type question. Let's assume that there is zero jitter in our system clock.
 
Are there any processors in which instructions always take the same time to run? I don't mean same number of cycles for each instruction, but rather, a completely predictable amount of time required for any particular instruction to complete (fetch + decode+ execute) irrespective of factors like pipeline stall etc.

A slightly confused question.

All silicon I know of, will inherently take a fixed time to fetch + decode+ execute, it is other factors like time to deliver the opcode to the CPU fetch unit, and in the case of interrupts, time to complete other instructions.

One simple technique for 8-bit MCU's to get a jitter free interrupt delay, is to always sit in IDLE before the interrupt arrives.
That removes the finish-current-opcode effect.

8 bit MCUs tend to have less-variable memory pathways than more complex MCUs, but even lowly 8-bit MCUs can sometimes come with alignment changes that can affect the time taken to get a complete opcode. ie if you recompile the code and the alignment moves in memory, the measured time can change.

In theory, you could design MCU that de-jittered interrupts by always taking the longest opcode time to respond, but I've not seen a MCU that does that.

 

[jpanhalt]

Are there any processors in which instructions always take the same time to run? I don't mean same number of cycles for each instruction, but rather, a completely predictable amount of time required for any particular instruction to complete (fetch + decode+ execute) irrespective of factors like pipeline stall etc.

I'm not going to bother to look at the details of yet another me-too processor.

How about sticking to the question that was asked?  For that, the answer is yes.  You may need to look outside your limited realm of experience.

@djnz,
Going past the thought experiment, in my experience when such timing is critical, a clocked interrupt can be used to even timings out. 

[Kleinstein]

Simpler CPUs and µCs have a predictable, fixed timing. I have used this for the AVR based multislope ADC that really depends on the timing. It is still extra effort to write the code in ASM and get the same run-time over different cases. This kind of excludes interrupts.

Modern, fast CPUs tend to use chaches and similar to accelerate memory access and this kind of breaks the predictablity. Also DMA can add delay at unpredictable times, especially if initiated from IO parts. Pipelines make things more complicated as the speed depends on the instructions before - it can still be reasonable predictable and repeatable.

One a few ps scale there can be additional jitter from the CPU internal state effecting the exact delays (relative to the clock) for outputs.
As an example, for the atmel mega48 µC I saw a small (roughly 10s of ps range) effect of ADC clock on the IO output timing.
Similar FPGAs have minor coupling that can cause additional jitter or delay modulation from internal signals.

[tggzzz]

Are there any processors in which instructions always take the same time to run? I don't mean same number of cycles for each instruction, but rather, a completely predictable amount of time required for any particular instruction to complete (fetch + decode+ execute) irrespective of factors like pipeline stall etc.

I'm not going to bother to look at the details of yet another me-too processor.

How about sticking to the question that was asked?  For that, the answer is yes.  You may need to look outside your limited realm of experience.

@djnz,
Going past the thought experiment, in my experience when such timing is critical, a clocked interrupt can be used to even timings out.

How about finding out the more important question, and answering that?
https://en.wikipedia.org/wiki/XY_problem

[gerbay]

Real-time is completely dependent on your timing and jitter requirements. For many applications, modern CPU/MCU performance is sufficient for real-time requirements. Jitter is always present and it depends on how precise you measure. Nowadays, calculations are no longer done by counting instructions. Timing and jitter measurements are made to meet timing requirements. In applications where CPU/MCUs are not sufficient (relatively few), you may need to use FPGAs or special ASIC chips.

[tggzzz]

Real-time is completely dependent on your timing and jitter requirements. For many applications, modern CPU/MCU performance is sufficient for real-time requirements. Jitter is always present and it depends on how precise you measure. Nowadays, calculations are no longer done by counting instructions. Timing and jitter measurements are made to meet timing requirements. In applications where CPU/MCUs are not sufficient (relatively few), you may need to use FPGAs or special ASIC chips.

Not true for the XMOS xCORE processors. The IDE does the instruction timing calculation accurately, without running code and hoping you spotted the worst case.

Those MCUs do indeed have some of the advantages of FPGAs, without the pain.

[djnz]

@tggzzz: I had read about XMOS previously on this forum - makes sense that a company focusing on audio applications will want something like this. Thanks

@radiolistener: I understand that zero jitter is not possible (Heisenberg says "hi") hence the initial prologue of "this is a thought experiment".

I was reading more about ARM Cortex-M and was wondering where 8/16 bit processors still had a technical edge (not cost / availability / program complexity etc.) over more complex ARM processors. That is what prompted this question. If you have a pipelined processor how do you "even out" the timing difference between a a smoothly flowing pipe vs a stalled / bad data filled one? AVR8 and PIC16 are both pipelined so how do they have predictable timing?

I was thinking that an unpipelined processor like the original 8051 / (or perhaps Z80 as peter-h says)  could definitely have this predictability, but does any pipelined processor have it?

If the ultimate goal is timing predictability, do you just poison all cache / pipelines with lots of NOPs before the interesting parts happen to force everything to operate at the same (but slowest) speed?

[westfw]

I think this is the domain of true real-time OSes. Hence the name. They’re commonly used for systems where absolutely deterministic behavior is required, like safety-critical telematics and avionics.

Um.  I was very nonplussed to discover that "Real Time OS" does not necessarily imply "fast" or "deterministic"; usually it just means "guaranteed latency less than some quantum (that is much larger than a single instruction cycle.)"  I particularly remember a competitor in the IP routing business touting their fancy RTOS-based router that could always route a packet in "less than a millisecond."  Which I though was pretty awful, since we were switching packets MUCH faster than that.  Except... only "most of the time", and we couldn't make any similar guarantee.  (And in fact someone made a PhD thesis out of analyzing the variability of packet switching times...)

I think that many DSPs can provide deterministic timing.

It's possible that many "modern" processors are also deterministic, or can be configured to be deterministic.  But it seems that most of the time, something is not well documented enough to do this in reality.  (In particular, the exact behavior of "flash accelerators" and caching is frequently not well described.)

[Siwastaja]

Um.  I was very nonplussed to discover that "Real Time OS" does not necessarily imply "fast" or "deterministic"; usually it just means "guaranteed latency less than some quantum (that is much larger than a single instruction cycle.)"

Not even that. "Real-time OS" is really one of those meaningless marketing wank terms (like low drop-out regulator or low-noise amplifier), which gives you some idea about the intended applications, but no more than that. Definitely it does not mean anything specific in how it's implemented, or what kind of timing guarantees it exactly gives. IOW, something being called an RTOS is enough to make it an RTOS.

I kinda liked how tggzzz used this term to coin this gem of marketing:
"RTOS implemented in Silicon."

 

[guenthert]

   The king-of-the-hill XMOS products have been mentioned, but for hobbyist the TI Sitara chips might be of interest as they are used on the Beagle Boards and offer two 32bit programmable realtime units (PRU) running next to the ARM chip.  Cheaper is the old, odd, breadboard-friendly Parallax Propeller (P8X32A), cheaper yet the recent Raspberry Pico (RP2040, RP2350) with its, admittedly limited, PIO "state machines". 

   All those allow precise timing with cycle granularity.  Information regarding jitter less than a cycle is much harder to come by.

[iMo]

Are there any processors in which instructions always take the same time to run?.

All PIC ucontrollers except the pic32 line..

Leapsecond site says less than 2ps jitter..

http://www.leapsecond.com/pic/picdiv.htm