Completely predictable instruction timing - Page 1
Forum section: electronics / general

author: djnz
author_rank: Regular Contributor
timestamp: May 04, 2025, 03:15:22 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: May 04, 2025, 03:44:47 pm
content: Z80 and many others of that era

author: jnk0le
author_rank: Regular Contributor
timestamp: May 04, 2025, 03:46:48 pm
content: 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 bussesEDIT: not to mention the XMOS barrel processors, designed for implementing software peripherals. Where even the IDE can calculate the timmings of your code.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 04, 2025, 04:21:39 pm
content: 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.

author: amwales
author_rank: Regular Contributor
timestamp: May 04, 2025, 04:34:37 pm
content: You can do reliable cycle counting with the 16bit dsPIC, very few gotchas, very well documented.

author: tooki
author_rank: Super Contributor
timestamp: May 04, 2025, 08:03:13 pm
content: Quote from: djnz on May 04, 2025, 03:15:22 pmI’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.

author: tggzzz
author_rank: Super Contributor
timestamp: May 04, 2025, 08:20:34 pm
content: Quote from: djnz on May 04, 2025, 03:15:22 pmXMOS 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 enablescalculationofhardrealtime behaviour; none of thismeasure and hopeyou ran across the worst case crap!eThat gives FPGA-like determinism.BTW, you don't need an RTOS either; the fundamentals interprocess communication and scheduling are implemented in hardware.

author: tggzzz
author_rank: Super Contributor
timestamp: May 04, 2025, 08:26:09 pm
content: Quote from: SiliconWizard on May 04, 2025, 04:21:39 pmXMOS xCORE are modern and not simple: 32 cores per 4000MIPS chip. Buy them at DigiKey.https://www.digikey.co.uk/en/supplier-centers/xmosNo pipeline.No cache.No interrupts.RTOS implemented in Silicon.What more could you want for hard realtime embedded?

author: jpanhalt
author_rank: Super Contributor
timestamp: May 04, 2025, 08:33:29 pm
content: Quote from: djnz on May 04, 2025, 03:15:22 pmFor 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.

author: radiolistener
author_rank: Super Contributor
timestamp: May 04, 2025, 09:12:03 pm
content: Quote from: djnz on May 04, 2025, 03:15:22 pmZero 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.

author: tggzzz
author_rank: Super Contributor
timestamp: May 04, 2025, 09:32:59 pm
content: Quote from: jpanhalt on May 04, 2025, 08:33:29 pmHow 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.

author: jpanhalt
author_rank: Super Contributor
timestamp: May 04, 2025, 10:58:29 pm
content: Quote from: tggzzz on May 04, 2025, 09:32:59 pmDefine 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.

author: tggzzz
author_rank: Super Contributor
timestamp: May 04, 2025, 11:15:18 pm
content: Quote from: jpanhalt on May 04, 2025, 10:58:29 pmModern: 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 includeseverything, including the effects of interrupts, caches, branches.The XMOS xCORE hardware/software architecture allows the IDE tocalculatethat 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.

author: David Hess
author_rank: Super Contributor
timestamp: May 05, 2025, 04:11:39 am
content: 8/16 bit PIC and 8 bit ARV have fixed instruction timing.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: May 05, 2025, 04:19:24 am
content: Quote from: djnz on May 04, 2025, 03:15:22 pmA 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.

author: jpanhalt
author_rank: Super Contributor
timestamp: May 05, 2025, 04:29:03 am
content: Quote from: djnzQuote from: tggzzz on May 04, 2025, 11:15:18 pmHow 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.

author: Kleinstein
author_rank: Super Contributor
timestamp: May 05, 2025, 06:40:24 am
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: May 05, 2025, 06:58:22 am
content: Quote from: jpanhalt on May 05, 2025, 04:29:03 amHow about finding out the more important question, and answering that?https://en.wikipedia.org/wiki/XY_problem

author: gerbay
author_rank: Regular Contributor
timestamp: May 05, 2025, 07:04:22 am
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: May 05, 2025, 07:15:12 am
content: Quote from: gerbay on May 05, 2025, 07:04:22 amNot true for the XMOS xCORE processors. The IDE does the instruction timing calculation accurately, without running code andhopingyou spotted the worst case.Those MCUs do indeed have some of the advantages of FPGAs, without the pain.

author: djnz
author_rank: Regular Contributor
timestamp: May 05, 2025, 07:21:37 am
content: @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?

author: westfw
author_rank: Super Contributor
timestamp: May 05, 2025, 08:20:03 am
content: QuoteUm. 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.)

author: Siwastaja
author_rank: Super Contributor
timestamp: May 05, 2025, 08:47:15 am
content: Quote from: westfw on May 05, 2025, 08:20:03 amNot 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 theintendedapplications, 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."

author: guenthert
author_rank: Frequent Contributor
timestamp: May 05, 2025, 09:02:48 am
content: 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.

author: iMo
author_rank: Super Contributor
timestamp: May 05, 2025, 09:15:44 am
content: Quote from: djnz on May 04, 2025, 03:15:22 pmAll PIC ucontrollers except the pic32 line..Leapsecond site says less than 2ps jitter..http://www.leapsecond.com/pic/picdiv.htm

author: Kleinstein
author_rank: Super Contributor
timestamp: May 05, 2025, 09:20:04 am
content: The AVRs / PICs and many other simple CPUs use some minimal pipeling or at least prefetch. The pipeline is however very simple and not real pipeling stall is possible. It can complicate the timing for a few instructions, like conditional branches. These may well take a different time whether the branch is taken or not. For the use this has not major consequence as one has different program branches and this different code anyway. AFAIK with the AVRs some complex instruction with pointer increments can in some cases (carry over to high byte) also take an extra cycle. So these instructions would have to be avoided.For the ARM and similar processors it mainly gets complicated with a clock faster than the flash memory access and some buffers to accelerate the memory access most of the time. This gives hard to predict / calculate delays. Just the pipeline stall is still predictable and compilers may take it into account for optimization - so still doable, though a bit complicated. DMA can also mix up the timing totally as it can delay memory access. Similar interrupts tends to complicate things as there can be extra delay depending on the command executed when the interrupt happens.With the more powerfull µCs like the ARM based µCs one would use the timer hardware for exact timing. Quite some things can be done via direct signals between pheriphery parts (like comparator triggers timer) - the details and what works an what does not work still depends on the µC model.In some areas one can use the timer HW to resync the code execution, e.g. to compensate for the interrupt jitter.For may DIY MS ADC I have done both versions: the AVR version via cycle counting in ASM code and the STM32L051 version with coupled timer and comparator perphery. Both ways work, with there limitations.Realtime as in RTOS is a different thing - this is to provide a guaranteed maximum reaction time, but not clock accurate timing.

author: Berni
author_rank: Super Contributor
timestamp: May 05, 2025, 10:41:11 am
content: Quote from: djnz on May 05, 2025, 07:21:37 amPipelining is not what causes this.Even an 8bit AVR is pipelined, that's how it can do 1 instruction per clock cycle. It just means that there are multiple instructions "in flight" trough the CPU core where each instruction might be at a different stage of execution. This just helps keep more of the CPUs logic busy, but doesn't actually introduce extra latency. Only place extra latency shows up is when branching since this means flushing the pipeline. However the latency jump is constant, so this just shows up by branch instructions often needing 4x or even more cycles to execute.When things get funky is Superscalar architecture CPUs.These are capable of executing more than 1 instruction per clock cycle and this opens a whole new can of worms. Obviously you can't simultaneously execute two instructions that both access outside memory since the memory bus can only do 1 operation per cycle (also memory tends to run at a slower clock than the CPU core at these advanced high performance CPUs). But if all the other instructions move internal CPU registers then they can all execute simultaneously without problem, that is unless you perhaps tried to do too many ADD instructions and the core ran out of ALUs to perform the addition on, so some won't execute parallel...etc So this makes the relationships so complex that it is infeasible to document exact timing behavior.The smaller ARM cores used in MCUs are often not superscalar and the slower ones are so slow that you can run RAM at identical clock to the core (hence no cache needed). Those have well predictable instruction timings. Faster ones need a cache because the memory subsystem can't scale as fast as CPU cores can. Often these caches can be simply turned off (but heavily impacts performance)If you have an application with very strict cycle accurate timing requirements then just plonk down a small MCU to handle it, leave the rest of the heavy lifting to a separate high performance MCU. If you need combined cycle accurate high performance, then a MCU is the wrong solution, use a more specialized chip like XMOS (mentioned above, they are nice indeed) or a FPGA.

author: gerbay
author_rank: Regular Contributor
timestamp: May 05, 2025, 11:37:45 am
content: As long as there are conditional branches in the code we write, counting instructions is meaningless. You may be right for very small codes, but for large real-time systems, counting instructions makes no sense.

author: mikerj
author_rank: Super Contributor
timestamp: May 05, 2025, 01:05:52 pm
content: Quote from: gerbay on May 05, 2025, 11:37:45 amNot true, provided the total cycle time for branch and no branch conditions is consistent then you can write cycle accurate isochronous code. This was a core concept of PIC programming back in the day when coding for an application in which every instruction counted.

author: gerbay
author_rank: Regular Contributor
timestamp: May 05, 2025, 01:47:15 pm
content: Quote from: mikerj on May 05, 2025, 01:05:52 pmI already mentioned that it could be for small codes. You are talking about PIC MCUs or equivalent MCUs. You can continue to count instructions in such MCUs. Today, even MCUs have switched to superscalar architecture. ARM Cortex-M7 can be given as an example. There is no point in counting instructions in such an MCU. If determinism is tried to be achieved by counting instructions, I think the system design is not very good.

author: mtwieg
author_rank: Frequent Contributor
timestamp: May 05, 2025, 03:25:04 pm
content: Quote from: tooki on May 04, 2025, 08:03:13 pmQuote from: PCB.Wiz on May 05, 2025, 04:19:24 amYeah depending on what assumptions one makes, any MCU/CPU can be considered perfectly deterministic. It's unclear what the OP is actually asking for.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 05, 2025, 03:47:21 pm
content: We don't quite know, this is kind of a recurring topic, though, and so we are assuming that the underlying reason is always the same: deterministic execution time for real-time systems. Maybe it's not what it is about this time.Otherwise, the answer keeps pretty much being the same:- Fully exact and predictable execution time per individual instruction is often not per se required to meet hard real time requirements. Bounded execution time is (and even so, there can be schemes that can accomodate a given piece of code not to fully complete and yet meet deadlines, as long as said code can be interrupted with no unacceptable consequence...)- There are otherwise devices that make it "easier": either those simple, cycle-accurate CPUs, or XMOS processors as tggzzz mentioned. Or FPGAs / similar. The Parallax Propeller processors are also an interesting (although much less powerful) alternative to XMOS processors, for anyone curious.As gerbay said, depending on the reason the question is asked, it may be the wrong question. Here, we don't know.But if the OP doesn't yet know about them, I suggest looking at XMOS and Propeller processors, to get to know something different that may be more in the direction of what they have in mind, apart of course from implementing custom sequential logic on FPGA/programmable logic or silicon directly.

author: Berni
author_rank: Super Contributor
timestamp: May 05, 2025, 07:30:29 pm
content: Quote from: gerbay on May 05, 2025, 01:47:15 pmDon't think anyone instruction counts the flow around an entire application.Usually you are only interested in the timing within one small walled off piece of code. Like maybe a bitbang routine where you need precise timing only while the function is executing, so you can turn off interrupts and just count whatever is inside that function. Or you might be interested in the timing of an interrupt handler, so you know X cycles elapse between a timer firing and a certain line of code executing.Not all ARM MCUs are complex enough to be superscalar. There are still plenty of smaller Cortex M chips that are focused on being small simple and low power. There performance is not the focus, so they stick to simple sequential pipelines. Also those are the ones that are slow enough where RAM is fast enough to keep up with the CPU so a cache is not needed.Interrupt entry latency is also usually constant on these simpler ARMs. Or some bigger chips even have a feature to artificially increase the latency of interrupt entry to the worst case scenario, this makes interrupt timing a consistent number of cycles at the expense of some performance. Another trick on the bigger chips is placing the timing critical code into a memory area that is closer to the CPU (some chips have a small amount of "tightly coupled RAM" that is fast enough to run at full CPU speed, hence no cache needed)So you can get cycle accurate timing with modern chips if you pick carefully, but yeah once you go to the highest performance chips it is not there, the chips simply wouldn't be able to run at those high performance levels without caches and similar tricks.

author: tggzzz
author_rank: Super Contributor
timestamp: May 05, 2025, 09:55:14 pm
content: Quote from: gerbay on May 05, 2025, 11:37:45 amConditional branches are irrelevant to the point. You are interested in the maximum time between two points, by whichever path is the slowest.The number of bytes in the system is irrelevant. What matters is the timing requirements (guaranteed latency or statistical latency) and the mechanisms used to satisfy the requirements.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: May 05, 2025, 11:28:55 pm
content: Quote from: djnz on May 05, 2025, 07:21:37 amOr, you take the route of the PI PICO and use a PIO state engine microcode.Some details of that are a little frustrating - they have no wait on edge and no single clock granular (time-out + wait on edge)

author: tooki
author_rank: Super Contributor
timestamp: May 06, 2025, 06:33:37 pm
content: Quote from: Siwastaja on May 05, 2025, 08:47:15 amI think that's a bit of an exaggeration.For the extremely critical applications, there are so-called "hard real-time" OSes, which by definition are the ones whose timing is completely deterministic.

author: tggzzz
author_rank: Super Contributor
timestamp: May 06, 2025, 06:43:14 pm
content: Quote from: tooki on May 06, 2025, 06:33:37 pmOr rather the timing is guaranteed to be withinspecified bounds, without exception - and definitely without statistics such as mean (ugh!) or 95th percentile etc.

author: Kleinstein
author_rank: Super Contributor
timestamp: May 06, 2025, 07:20:43 pm
content: Things like a real time OS can usually not guarantee absolute clock cycle stable reaction times. This is a thing that need either speciallized periphery hardware or a suitable CPU with fixed execution times and speciallized ASM code - so usually not using an OS, or if at all an code part that comed with the OS and would fully occupy the CPU for that task.It gets rather tricky to get more than one job done under to constraints of cycle accurate timing from the code (it is possible, but tricky as all cases need to take the same number of cycles).The real time OS things are more like guarantee something like 1 µs or 10 µs response time, but this would usually still be hundreds of clock cycles. Normal compilers can also not generate code with a defiend run time they more like try to optimize for a fast execution, and don't create code for a specific delay / speed. In some cases a simulator could simulate the actual time needed, so one could check code for a defined run time.

author: gerbay
author_rank: Regular Contributor
timestamp: May 06, 2025, 07:31:27 pm
content: Quote from: Kleinstein on May 06, 2025, 07:20:43 pmSo can we say that companies that pay for rtos like vxworks, integrity, lynxos, qnx, pikeos are paying for nothing?

author: nctnico
author_rank: Super Contributor
timestamp: May 06, 2025, 07:46:38 pm
content: Quote from: gerbay on May 06, 2025, 07:31:27 pmThey are not paying for nothing but the fact is an RTOS is still software and even though we have GHz microcontrollers nowadays, software response time is still in the microseconds range. And for many realtime applications that can be more than good enough. When people read realtime, some immediately jump to nano-second or even pico-second time accuracy while in many cases the actual requirements are in the milli-second range.What an RTOS typically brings to the table are device drivers, protocol stacks, an organised way to deal with processes and messaging between them. Although you have to research whether an RTOS is a good fit for your project. Wrongly applied, an RTOS can make things worse instead of better. A typical failure is having too many seperate processes which then smother the whole system with thread concurrency and synchronisation issues.

author: iMo
author_rank: Super Contributor
timestamp: May 06, 2025, 07:54:51 pm
content: Afaik avr/pic/dspic/msp430/cortex_M0_M0+ are in-order exec models, thus predictable and clock precise.CM7 (and perhaps M3/M4..) may use dual pipe-lining (and mostly in-order exec but not sure with M7) and pic32MX/MZ series may use (or it is using) out-of-order execution which may cause issues. And when talking lowest jitter any onchip PLL based clock will always be worse than clocking them from an external quality oscillator..PS: I spent my "youth"counting cycles with pics, there were even some tools generating complex asm structures with many loops for generating any precise frequencies or periods/duty cycles (I have here several counters and LC meters built around clock precise pics).PS: Also using onchip oscillators is not the best solution when chasing jitter. The crystal oscillator could be modulated by the internal mcu's noise (and it is in practice). So best is to use an external oscillator driving the mc's clock input hard (like the canned oscillators or special designs).

author: tggzzz
author_rank: Super Contributor
timestamp: May 06, 2025, 09:31:21 pm
content: Quote from: Kleinstein on May 06, 2025, 07:20:43 pmIt is helpful to have an MCU where every peripheral has an associated counter, noting the clock cycle on which an input occurred, and specifying the clock cycle on which the next output should occur. If you also have language support for the peripheral/counter pair, then it becomestrivialto specify cycle accurate i/o at the application task level.xC plus xCORE MCUs have that.Why don't all other MCUs? Because they haphazardly accreted features with no overall hardware-plus-software conceptual design. And that's a manifestation of the unnatural division between hardware and software mentality/skillsets.QuoteThat is only true with traditional (i.e. old fashioned) MCUs. Some modern embedded multi-core MCUs simply dedicate one core to each task.That removes the need for interrupts. If the cores don't have caches, then you achieve timings that can becalculatedwithout executing the code. Providing that worst case timing is shorter than the i/o requirements, then you haveguaranteedhard realtime performance.Don't settle for the imperfections of the past; demand more for the future

author: tggzzz
author_rank: Super Contributor
timestamp: May 06, 2025, 09:37:59 pm
content: Quote from: iMo on May 06, 2025, 07:54:51 pmDo they have any form of cache? Data, instruction, TLB, etc? If so, all bets are off.Do they have and use interrupts? If so, all bets are off.QuoteDepends on the cause and scale of the jitter. If the jitter is introduced by the software (e.g. cache misses, interrupts) or synchronisation across clock boundaries, then the jitter will be in quanta of one clock cycle.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 07, 2025, 05:26:38 am
content: Quote from: tooki on May 06, 2025, 06:33:37 pmProving my point: you now have to add that extra qualifier "hard" to convey that message.RTOS in modern-day usage usually just means "OS", just like "LDO" means "linear regulator" for many. That is why I found tggzzz's "RTOS implemented in silicon" such funny remark, as it is totally detached from the reality people expect from RTOS'es; basically tggzzz just wanted to say "real time implemented in silicon", and not "operating system implemented in silicon". And yet most people mean just "operating system".The #1 reason to use an RTOS is the same as using any general purpose OS: to be able to slap together large pieces of existing code, including black box libraries, which depend on concepts like blocking function calls, time-slicing threading and so on. And in most cases people could not care less about any real-time guarantees, or understand how to prove anything about it.

author: Berni
author_rank: Super Contributor
timestamp: May 07, 2025, 06:08:35 am
content: Quote from: tggzzz on May 06, 2025, 09:37:59 pmThe simpler MCUs still run the same way as old 8051s 6802s..etc All the execution is deterministic because they can clock the whole chip (including RAM and peripherals) from the same clock. Even larger MCUs can work if they are not superscalar architecture and the core has access to fast enough non cached RAM.Interrupts also are perfectly fine if you need cycle accuracy. If you need a cycle accurate area in the main thread then just disable interrupts for that area (often CPUs even have a dedicated instruction for that). Or even better use the interrupts as part of your cycle counting. You usually see interrupt latency documented in the datasheet, so you can know how many cycles there are between the interrupt firing and the first line of the interrupt handler executing, then count on from there. This is actually often the best way to do stuff since you can have a hardware timer kick off your interrupt at a precise point in time, then just cycle count from there on.But yeah if you have a project that absolutely requires cycle accurate timing to work, then you better pick a chip that is designed to do it, not just happens be able to do it somewhat if massaged just right. There are MCUs with mini CPLDs for timing(Cypress), MCUs with programmable state machines in IO (Pi Pico), MCUs with timing focused architecture (XMOS), or just straight up programmable logic (CPLD/FPGA) where you can do any crazy timing thing you want (even sub cycle timing with tricks).

author: Kleinstein
author_rank: Super Contributor
timestamp: May 07, 2025, 06:45:48 am
content: Interrupt latency is usually only an upper bound. Depending on the command just executed when the interrupt happens, the exact timing can vary. Things like a return from a subroutine often takes more than 1 cycle and the current instruction is usually completed before jumping to the interrupt. With more complex CPUs memory wait states or caches can also cause variability. So there is a few cylces of variability in the delay when an interrupt is started.For cycle accurate interrupts one usually needs to add some sync code, that waits depending on a hardware timer that triggered together with the ISR. Alternatively the output action would use a hardware timer that started with the same signal as the ISR. It is usually not the code that needs to be cycle accurate, but the resulting output or it is about the difference in time measurements.With a fast µC and high clock speed a few clock cylces are not much - maybe in the 10 ns range. However clock cycle accurate means that the timing (especially the output) is fixed to the 10 ps or so range. So quite a step down in jitter.

author: tooki
author_rank: Super Contributor
timestamp: May 07, 2025, 07:00:15 am
content: Quote from: Siwastaja on May 07, 2025, 05:26:38 amFair enough!The impression I get is that nowadays, applications that need truly cycle-by-cycle deterministic behavior just use an FPGA.

author: Andy Chee
author_rank: Super Contributor
timestamp: May 07, 2025, 07:53:40 am
content: Quote from: djnz on May 04, 2025, 03:15:22 pmI’m having trouble understanding the distinction between no. of cycles, and your definition of instruction completion. To me, they are one in the same.On another note, many moons ago I dabbled with Ubicom/Scenix/Parallax’s SX28 microcontroller, which relied on a software peripheral approach.Getting software UART, I2C, and PWM modules to work happily with each other, would almost be impossible without cycle determinism.

author: tggzzz
author_rank: Super Contributor
timestamp: May 07, 2025, 08:11:57 am
content: Quote from: Siwastaja on May 07, 2025, 05:26:38 amI make a strong distinction between the OS (of whatever sort) and the libraries used with it. Frequently the availability of high quality libraries is more important than the specific ordinary or soft realtime OS - and can be used to select the OS. Ditto language and libraries.I also make a strong distinction between "realtime" and "hard realtime". Perhaps that is a consequence of my having implemented both hard and soft realtime applications. Not realising the distinction is a failure of education and/or imagination.

author: tggzzz
author_rank: Super Contributor
timestamp: May 07, 2025, 08:19:08 am
content: Quote from: Berni on May 07, 2025, 06:08:35 amAgreed, but having the same clock is not strictly necessary.QuoteThat can work in special cases. It obviously depends on the length and proportion of the section where interrupts are disabled, and the required interrupt latency.QuoteYup.There are many ways to skin a cat. It is the engineer's responsibility to know the strengths/weaknesses of the individual approaches, and to choose the appropriate one for the task in hand. Too many people have only been taught about hammers, and don't realise screws exist for a reason

author: tggzzz
author_rank: Super Contributor
timestamp: May 07, 2025, 08:27:12 am
content: Quote from: tooki on May 07, 2025, 07:00:15 amI prefer to characterise the problem based on input->output jitter and minimum latency, computational complexity, amount of (parallel) computation, and ease of development plus modification. Sometimes conventional software is clearly sufficient, sometimes FPGAs are obviously necessary.The grey area between the the two is interesting, as is blending the two in a particular implementation. Hence I like xCORE and Zync, for different reasons

author: tggzzz
author_rank: Super Contributor
timestamp: May 07, 2025, 08:39:11 am
content: Quote from: Andy Chee on May 07, 2025, 07:53:40 amIn general parallel hardware up to and including multicore MCUs is easy to implement and has been done many times over the decades. Software is a different issue, and is where things become unpleasant.A key point about the xCORE+xC+toolchain is that they are all designed together. Hence they work together seamlessly and the whole is more than the sum of the parts. That makes writing deterministic hard realtime highly parallel software applications much more tractable - and even fun. Example: a task's input/output is a message from/to either another task or a peripheral. I.E. there is,correctly, no fundamental distinction between implementing functionality in hardware or software. Uniquely, that is carried through hardware, the language, and the toolchain.

author: nctnico
author_rank: Super Contributor
timestamp: May 07, 2025, 10:35:18 am
content: Quote from: tooki on May 07, 2025, 07:00:15 amThat is not necessary for as long as your application doesn't need functions beyond the abilities of a standard microcontroller. DSP applications have been done for decades and these need precise timing for ADC/DAC interfaces to maintain the exact samplerate. UART and SPI buffering are also very common features. More recently it is also possible to use DMA to move data and timers to trigger events (like DAC updates or ADC sample points) and some PWM modules have extensively programmable state machine able to do cycle-by-cycle current limiting. All these features relax the requirements towards the software. It is much easier for software to implement a requirement 'this needs to be done before time expires...' compared to 'this needs to be done at this exact point in time'.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 07, 2025, 11:17:07 am
content: Quote from: tooki on May 07, 2025, 07:00:15 amYeah, or, tggzzz's beloved XMOS stuff, which, fair enough, is a pretty neat concept and product line, sure.Some of us just give more value of avoiding locked-in single-vendorconcepts, for which nothing even similar appears on any other manufacturer, no matter how good it may be.Then again, truly needing cycle-level determinism within the whole application is exceedingly rare; I don't remember ever thinking "oh, now this xcore thing would come handy!" And all other MCUs can easily give worst-case processing within 1% or so; or +/- a few instructions, depending on details like flash accelerator / icache / branch prediction miss, synchronization across clock barriers, or maybe DMA competing for the RAM access. It is worth noting that ondesktop computing CPUs, things like these have massive impact; going from register to L1 cache might be a few times of performance loss, then to L2 cache some other hundreds of %, then to main DRAM again an order of magnitude, not to mention disk. But on microcontrollers, it's a question of if jump takes 2 or 3 cycles, not that if it takes 2 or 200 cycles. And if your critical control piece which has 1000 cycles worth of instructions has ten branches, then the question is whether it takes 1000 or maybe 1010 cycles. And if data cache is available, it has the same latency as internal RAM anyway, so people don't use it. (It has different purpose, see below.)You have toseriouslytry to program microcontrollers such that they usually work but sometimes failbecause of icache or branch prediction miss, the instruction timing jitter caused by those mechanisms is just so small.But sure, tggzzz is completely right that these things exist, just blowing the significance out of proportion (plus adding misleading stuff, like mentioning TLBs which do not exist on microcontrollers, and does this repeatedly like any good troll no matter how many times he is proven wrong; for him, all CPUs are microcontrollers, specifically mentioning Cortex-A application processor series). Or data cache which no one uses in timing-critical microcontroller projects because they are designed for external RAM and no one uses external RAM except for special cases like, let's say, graphics.But yeah, this exact thread is perfect for tggzzz's argument and I'm happy for him. The question was hypothetical, and XMOS istheanswer this time.

author: tggzzz
author_rank: Super Contributor
timestamp: May 07, 2025, 04:13:28 pm
content: Quote from: Siwastaja on May 07, 2025, 11:17:07 amVendor lockin has to be considered, but it isnecessarywith manymanyother components - and accommodated.QuoteCan you guarantee tight hard realtime timing while also doing computation and USB or ethernet comms? Over-specifying the processor by a factor of, say, 1000 is "inelegant".QuoteIn some of my applications, a miss is as good as amilelawsuit.QuoteUm. Would you like to rephrase that, not only to make it more comprehensible and but also to avoid "there's no such thing as a trueScotsmanMCU" debatesArm devices can indeed have TLBs, e.g. the A9 processors inside Zync FPGAs.https://stackoverflow.com/questions/30530300/measurement-of-tlb-effects-on-a-cortex-a9#40875169QuoteIt was a good hypothetical question, because it exposes limitations and choices that need to be made.

author: gerbay
author_rank: Regular Contributor
timestamp: May 07, 2025, 05:36:44 pm
content: Comparing the application processor with the microcontroller, it turns out that XMOS is more deterministic.. interesting..

author: Siwastaja
author_rank: Super Contributor
timestamp: May 07, 2025, 05:58:25 pm
content: Quote from: tggzzz on May 07, 2025, 04:13:28 pmOf course. You would know that if you had tried, any embedded programmer worth their salt can do it no worries. This is why we have peripherals, pre-emptive interrupts and interrupt priorities. There is no need to overspecify anything by factor of 1000. I often tend to run things at 70% CPU utilization or so.On the other hand, XMOS would be seriously underutilized by design most of the time. (Which I don't think as any kind of issue, though. Silicon is cheap nowadays.)Event-driven is the key. Even Javascript youngsters understand this. Just like OnClick you have a function being called, similarly OnOvercurrent you trigger a function. Within 50ns for example guaranteed by silicon. Yes, it might be just 30ns instead if the interrupt controller decides to add tail-chain optimization. This is the jitter we are talking about.Then again, if your definition of "tight hard realtime" (lol, we can keep adding adjectives) means that it's wrong to sometimes finish 100ns "too early", before the deadline, then sure, you need XMOS or FPGA. Another case is special snowflake high-speed interfaces for which there is no peripheral available and which are high-speed enough, or very sensitive to even <10ns of jitter, so that a microcontroller won't cut it. Then you use FPGA, helper CPLD, or - maybe XMOS.QuoteYet, XMOS is nearly nonexistent in fields like automotive or medical - instead, they mostly use those "good old" CPUs, and you would be horrified how inelegant the processes can be. The key is in a lot of testing. Yes, in the real world, quality is really tested into the product, which you don't like, and I don't like either.QuoteWhich, again, is not a microcontroller*, but we know for you it doesn't matter. As long as there exists any kind of CPU which has TLBs, then microcontrollers have TLBs. We know that. For the rest of us, the concepts of reality and truth are defined differently.*) ARM CPUs are divided by naming convention to microcontroller and application CPU series, -M and -A respectively.QuoteI fully agree, and it's nice to have this discussion once again this time it being completely on-topic!

author: gerbay
author_rank: Regular Contributor
timestamp: May 07, 2025, 06:22:21 pm
content: Quotealso ARM has -R series;-R cores are optimized for hard real-time and safety-critical applicationsQuote

author: Siwastaja
author_rank: Super Contributor
timestamp: May 07, 2025, 06:39:42 pm
content: Quote from: gerbay on May 07, 2025, 06:22:21 pmYes. They are even further away from the "simple" microcontrollers; more like those application processor with features added on top allowing them to also do tight hardcore very hard realtime, while still doing stuff like run the usual linux kernel. I'm sure tggzzz would hate them with passion, and to be fair they are one step further from the "KISS" principle, sure.The feature list isn't that special coming from microcontroller side - but if you look at it from the opposite direction, coming from "application" / general purpose desktop computing CPUs then sure it makes the difference of being able to meet realtime needs or not, while still being quite performant.XMOS feels elegant due to its simplicity, but it seems to not cater to real-world needs of today's software development flow. It's basically just gazillion of parallelized "PICs" bitbanging or polling giving huge MIPS numbers for marketing. You need to design the whole software from scratch to this design paradigm. It's much more than just a simple vendor lock-in. It meanscomplete re-writeof everything, as algorithms need to be designed around this concept.

author: tggzzz
author_rank: Super Contributor
timestamp: May 07, 2025, 07:07:34 pm
content: Quote from: Siwastaja on May 07, 2025, 06:39:42 pmWhy would I hate them? Horses for courses.Notice that cars are becoming ever more complex, unreliable and outright dangerous, e.g. lane assist software swerving the car in front of oncoming traffic.https://www.which.co.uk/news/article/car-tech-features-you-could-live-without-axlAN5K2Q5K7https://www.which.co.uk/news/article/lane-assist-tech-steers-popular-family-car-towards-oncoming-traffic-during-which-testing-afXHU1t7gttCMemo to self: find out if insurance is valid if I turn those mis-features off; some newly-added Ts&Cs requireverycareful reading and understanding.QuoteNot quite; that's definitely an overstatement.They are nothing like PICs.Number crunching algorithms remain unchanged, and can be lumps of C code.But there are some long overdue (IMNSHO!) changes in the way ofthinkingabout applications and structure. That's bound to be hard for some people, but comes naturally to others.Start bypresumingparallelism, and make use of it. That is an unavoidable necessity since nowadays processing power is limited by leakage currents and power dissipation. The only way forward is multicore. Start dealing with that.Given parallelism, a key issue is efficient communication between parallel processes. It always has been an issue, but has been obscured by the previous stunning increases in processor power. Comms is dealt with by CSP's messages sent over channels. Other languages and processors have seen the light, e.g. Go and TMS320. The inter-process comms are integrated into the xC language and into the hardware, just as they should be.Once you have efficient comms between processes, you can use them to communicate between cores and peripherals. This conceptual merging of hardware processes and software processes is very powerful; all engineers ought to think in those terms, but most are constrained by their background.Old truism: "organisations constrained to produce products which mirror the org-charts". Newer truism: "products architecture is constrained to mirror the team members' job titles". I was once asked by an HR droid "now are youreallyhardware orreallysoftware", at which point I decided there was no way I would work for that organisation.

author: Andy Chee
author_rank: Super Contributor
timestamp: May 08, 2025, 01:09:16 am
content: Quote from: tggzzz on May 07, 2025, 08:39:11 amLike I said, the SX28 does not have hardware peripherals. Getting a bit-banged UART, bit-banged I2C, and bit-banged PWM to work together, was like voodoo!

author: Siwastaja
author_rank: Super Contributor
timestamp: May 08, 2025, 06:01:11 am
content: Quote from: tggzzz on May 07, 2025, 07:07:34 pmYes. And such lane assists would run e.g. on said Cortex-R CPUs. And I can assure you that their malfunctions have nothing to do with caches, TLBs or timing jitter, and everything to do with the complexity of the algorithms (specifically image processing, always correctly recognizing where the lane is) themselves.

author: tggzzz
author_rank: Super Contributor
timestamp: May 08, 2025, 08:31:44 am
content: Quote from: Siwastaja on May 08, 2025, 06:01:11 amI didn't actually say that caches/interrupts are the source of those malfunctions.I presume, without evidence, that there are some forms of limited ML being making the decisions. Either way, cars are becoming more and unpredictably dangerous, and can no longer be held up as paragons of reliable engineering.No, I'm not looking forward to replacing my 20yo car; I'll have to do alotof research before I select a replacement.I'm wondering whether I should wander into a Tesla showroom and ask the currently underemployed salesmen to take me for a ride along back roads using the full self driving "beta" thing, while I watch how the car responds to potholes, poor road margins, and semi-blind chicanes.

author: jfiresto
author_rank: Frequent Contributor
timestamp: May 08, 2025, 09:24:33 am
content: Quote from: Andy Chee on May 07, 2025, 07:53:40 amI remember studying that part, for a design, and soon recognizing two likely race conditions in the interrupt handling, one of which they acknowledged. I tend to the notion the issues were addressed through marketing, by promoting its speed and "software peripherals".

author: tggzzz
author_rank: Super Contributor
timestamp: May 08, 2025, 09:36:20 am
content: Quote from: Andy Chee on May 08, 2025, 01:09:16 amI have no knowledge of that device, but your observation is completely unsurprising.When I used the xCORE+xC, everything like that just worked as expected. I was gobsmacked. Time from receiving board to first iteration of my hard realtime application working: <1 dayThe performance was also exactly as definedbeforethe hardware arrivedI was a very happy camper.8 cores were used for USB comms including debugging, the rest operated completely independently. Debugging is trivial: apart from the usual single-stepping and breakpoints, printf() sends a message to the "USB cores" and the application task continues.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 09, 2025, 08:23:21 am
content: Quote from: tggzzz on May 08, 2025, 09:36:20 amI believe this. Traditional microcontroller approach with peripherals is weird in the sense that many if not most vendors design terrible peripherals. For example, something trivial like UART or SPI, youshouldget it running in <2 hours the first time, but with companies like ST it can take a day or two when you discover overly complicated, poorly documented or outright silicon-buggy peripheral hardware.Then again, when you see well though out peripherals, using them is a breeze. nRF52 is a good example of easy-to-use peripherals the design of which makes sense, with consistent events -> tasks routing, consistent simple DMA (no more messing with polling or interrupting on status flags), and absence of fancy special features no one needs but which cause mental overload and bugs elsewhere.

author: nctnico
author_rank: Super Contributor
timestamp: May 09, 2025, 01:43:27 pm
content: It always surprises me why ST microcontrollers are so popular. They are about the worst where it gets to peripherals and documentation. Some customers insist on using the STM32 devices because they think the parts are cheap and they sell millions of units (NOT!) and thus completely lose sight of the higher NRE costs and longer time to market. NXP is so much better in that aspect. Right now I'm working on a project with a big iMX8 SOC from NXP which has a Cortex-M4 microcontroller core next to it. Even though the whole thing is insanely complex at first glance, getting the UART going with the Cortex-M4 core was as easy as on their small ARM microcontrollers. Good documentation and simplicity go a long way.

author: tggzzz
author_rank: Super Contributor
timestamp: May 09, 2025, 02:11:51 pm
content: Quote from: Siwastaja on May 09, 2025, 08:23:21 amUnfortunately the reason is simple: the unnatural conceptual split between hardware and software. That's not only wetware skillsets and attitudes, but also corporate design/manufacturing.Hardware companies/engineers think software is easy, can be bolted on as an afterthought, and can fix up any hardware bugs and impedance matches. Software companies/engineers don't understand hardware, and treat it as an incomprehensible black box.It is rare to find people and companies that have a decent theoretical and practical understanding of both.BTW, the first seriously buggy chip I came across was an interrupt controller c1983. In retrospect there was a big orange flag waving over it: it was version G.

author: jfiresto
author_rank: Frequent Contributor
timestamp: May 09, 2025, 04:45:12 pm
content: Quote from: tggzzz on May 09, 2025, 02:11:51 pmThe developers of the first seriously buggy chip I had to deal with, boasted they had designed it on a bunch of white boards. I did not learn about that until years later when they donated the white boards and an heroic tale to a national history museum – as an important advance in chip making! Fortunately, so many people suffered that part's design that a quietly competent competitor came out with an improved alternative that dropped right in.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 09, 2025, 05:47:24 pm
content: Quote from: nctnico on May 09, 2025, 01:43:27 pmPopularity itself drives popularity. I have used, and will keep using ST microcontrollers. When I first started using them, I did not do good analysis if something else would be easier or better. I got some because they were popular; I had heard the name; a lot of interesting-looking parts were available at distributors and they did not cost much. And once you are accustomed to the poor documentation and their "style" of design, you can manage it. Then getting more of the same crap is a decent choice, because it's nottoocrappy to seriously drive people to reconsider. There almost always is a workaround for everything; they are capable parts; the issue really is that you sometimes waste a day or two extra on stupid things which should not exist, but it's still lost in the noise (projects usually have timescales in years).Good cost, large portfolio of parts and good availability are real factors, too.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 09, 2025, 06:08:44 pm
content: And a very wide offer in ultra-low-power MCUs too.

author: uer166
author_rank: Super Contributor
timestamp: May 09, 2025, 06:57:59 pm
content: Quote from: nctnico on May 09, 2025, 01:43:27 pmST parts tend to be more complicated but also more flexible/capable than a lot of competition. They also have something for almost any use case, from the tiniest sub-$1 parts, to mixed signal DSP MCUs, to full-on MPUs running Linux. NXP have large holes in their portfolio, so if you're designing a large system with a bunch of needs and want to stay within one vendor/dev environment, ST is a safe choice.Where else can I get like 7 UARTs, a bunch of ADCs/DACs, flexible/variable clocking, and enough RAM/Flash to do graphics all at once?

author: uer166
author_rank: Super Contributor
timestamp: May 09, 2025, 06:59:02 pm
content: Quote from: SiliconWizard on May 09, 2025, 06:08:44 pmThere's lower power options that aren't ST, but I don't think there's anything that approaches theamountof functionality you get with something like a STM32U5 at the given power consumption.

author: David Hess
author_rank: Super Contributor
timestamp: May 09, 2025, 08:23:25 pm
content: Older ARM microcontrollers, generally operating at 50 MHz and slower, can have predictable instruction timing. Without caches, the clock speed is limited by the cycle time of the integrated Flash ROM and static RAM.