For the record this seems to be one of those "issues" you either understand why someone can be quite obsessed about it, or else you think it doesn't even merit discussion, and please understand if you're in the latter camp you're clearly part of the problem! Now for the record I'm talking about the kind of "determinism" that is "designed into" RTCA DO-178C Design Assurance Level A (which is the FAA-mandated standard for any software designed to be used for human-rated flight). I was able to stay employed for the better part of a decade helping people build avionics subsystems to DO-178C DAL A, we were doing things like jet engine control using (now) relatively ancient architectures like the single-processor MPC555. I was also sometimes involved writing software to do signal processing with DSPs that had a VLIW-style architecture (56X00 and Shard), and if you can't keep the processing loop size deterministic the net effect is to superimpose hideous amounts of jitter and noise on the computed signal. So pretty much all of the chips I talked about having used are getting pretty "long in the tooth", meantime along comes the ARM RP2040 from Broadcom at a list price of $.70...I guess it has a lot of potential (and certainly the older processors will be rendered totally con-competitive and will disappear) but now more than ever the people doing designs like mine need a deterministic output, ideally it should be "naturally" deterministic but if there exists a mechanism under which you could in effect create "synthetic determinism" (maybe by cutting down to a single processor for some small par of the signal processing window?) you MIGHT be able to salvage some usability out of such an architecture.
The thing about all this is, you wind up having to "be an expert on" a seemingly limitless variety of subjects in order to just make an intelligent discussion out of this! In order to even talk about determinism you need to be able to talk about how many levels of cache are present and how to 'flush" them (because it stands to reason that "dirty" cache is one of the enemies of determinism). Now in the "bad old" days nobody wanted to pay for a license for a "certified" RTOS, so we felt free to run "on bare metal" and write simple interrupt service routines as the need arose. Nowadays people seem to have no trouble getting their hands on an RTOS they didn't write and so can't easily make functional changes to...also these RTOSes were written by people who understood not only the detailled architecture of the chip they were writing it for, but also of the chip's security model, which (for very obvious reasons) is also at least partially proprietary so shrouded in secrecy. I've even perused the website of one Green Hills software, now it's their assertion that SMP is not a reasonable "model" for deterministic processing, they have developed a concept called BMP but everything they do business about is licensed. And there's other considerations, I understand even this smallest of chips has DMA, does that help matters at least from the signal processing standpoint? (The notion of having to become a system security and secure RTOS expert JUST to get some determinism on a project is both galling and frustrating.)
I know it seems as if I've asked a lot of questions here, but really I've just scratched the surface. How does the quest for determinism vary across the various ARM processor families? Are there any open-source RTOSes that have absolute determinism as a goal? Are there any studies of scholarly works that discuss this issue in depth so I can just read it and not have to come in here and bug everybody else? If now why doesn't some heavy-hitter CS school do such a study and publish it?
Thank you for reading this, I've asked these same questions in other forums, and so far there hasn't been enough expertise to warrant a single reply...so sad!
So much depends on what you mean by "deterministic". Most people see CPUs as being deterministic, but when you really dig down into them the might not be.
Sorry, that got cut off...In most modern microcontrollers, the CPU (or CPUs) are only a few of the bus masters on a very busy system bus (or bus matrix). There are also various DMA controllers and maybe USB controllers or other susbsytems doing DMA.All these masters are fighting for access to the bus or buses, as well as access to memories. This can lead to the masters being stalled for some number of cycles waiting for the memory or other bus access to complete.
On top of that, some instructions have variable execution times depending on the system state. For example, on an ARM, the interrupt response out of a sleep state might be shorter than from an executing state.
This all adds to execution jitter which is non-determinism.
If you're threshold to worrying about "determinism" is a microsecond or more then these factors probably do not matter.
However, I have been in situations where a couple of cycles of a 180MHz clock (ie. 12 nanoseconds) could degrade performance. That really stretched "determinism" to its absolute limits.
It is really challenging to try to achieve those levels of determinism using a microcontroller. FPGAs are probably a better bet.
I think I understand where you are coming from, but FPGAs generally aren't used to "do a whole lot of processing", maybe you have a different context in mind but I think you might be referring to the "high-frequency trading" scenarios or something like that. Now in the safety-critical aviation software context I'm referring to, the way things are now "by definition" (in DO-178 DAL A) there is either "absolute determinism" or there isn't, because lack of absolute determinism (ie a perfectly repeatable execution time) in executing a processing loop (essentially without or despite the servicing of ISRs) is the indication of some sort of lack of repeatability indicating the code may have been implemented with some undesired unpredictability included. I'm not here to say this is is a reasonable goal in a multiprocessor environment aboard an aircraft - you could say this standard by definition at this point in time specifically DOES NOT ALLOW multiprocessor implementations, which is a reasonable conclusion, but actually it leaves open the question of what a reasonable "set of options" might be. It's not really "a viable option" to say "look multiprocesssors are now well-established entities, and absolute physical determinism is obviously unrealistic", because the safety-critical community has a hard enough time keeping the flying public safe the way things are, and simply "obsoleting" physical determinism WITHOUT having a workable replacement will result in making the skies quite unsafe in no time at all. (Interestingly over the past 15 years or so the FAA solicited a group of papers known as CAST having to do with topics like this, but I don't recall seeing much published that attempted to resolve where the authors of these papers expect things are going to go.)
What I would like to understand is, there are still quite a few "ways to go" in the embedded context. I'm wondering if you could run all processors wide-open for MOST of the "typical" processing cycle (which for say engine fuel control could be in the several milliseconds), and right at the end shut off all but one (and disable the caches), use this interval possibly with some extra timing HW to "establish synthetic determinacy" and then fire everything up for the next cycle? If it's not TOO impractical maybe that's an option, although I may have read that in many contexts that's almost tantamount to restarting the whole RTOS from scratch and all that "security stuff" which is going to take way too long. Aren't there also some architectures where the processors aren't always trying to access the exact same copy of physical memory? (I recall the old 65xx/68xx microcontrollers where you could have different processors running on alternate clock half-cycles, I'm not holding that up "as a model" (not with modern bus timing!) just saying things like this WERE available once upon a time.) Please understand that all I'm doing here is kind of "spitballing" this for now, I'm hoping there's some kind of "research-level discussion" I can get my hands on so I can get knowledgeable enough to discuss this properly. See what I'm REALLY hoping for is that the "determinism issue" gets enough exposure that the CAPABILITY to resolve this could somehow get "grandfathered into" the inexpensive multiproessors we all get access to so we all have the opportunity to use this capability, whether we use it or not. Or maybe there's a totally DIFFERENT approach involving more of an AMP strategy and some sort of "hypervisor" or a totally different way to go. This is a "Gordian knot" that's going to have to be dealt with because the safety risks of NOT having a usable answer is too great to contemplate, and that's the context in which I'm attempting to discuss the problem.