Need help understanding some issues with QoriQ

[jlawton11]

I want to see if I understand what the overall concept is in the QoriQ product line. I have previously used quite a few PowerPC variants but I wasn't totally familiar with PowerQuicc, and I believe QoriQ is "kind of" designed to replace it using multicore ARM as an option to single-core PowerPC, with probably the intent of phasing out the PowerPC versions over time. The problem I have is the applications I have all require that I demonstrate the capability of absolute determinism of any software, and while I'm not a mindreader, everything I've read says that ARM has been overall quite hostile towards providing support for determinism in the ARM architecture (not part of CMSIS). Further I was thinking about trying to figure out how to get this capability myself, but I believe enabling/disabling processors (say in an SMP system) requires fiddling around with protected firmware, but I believe ARM doesn't release the kernel mode source, just user mode, and I don't really know enough about what their architecture looks like to modify it accurately anyway. And my complaints about this issue isn't just the ranting of a few disgruntled hobbyists, since supporting the software to the highest levels of commercial avionics used on aircraft that are rated to take commercial passengers and freight (RTCA DO-178C Design Assurance Level A) REQUIRES the demonstration of absolute determinism to FAA authorities, and failing to do so doesn't just restrict the availability of NEW avionics software, it seriously compromises the safety profile of any existing products which someone would have to rewrite after the PowerPC-based products have hit EOL, so in the near future we're all gonna be severely hobbled because the suits making decisions at ARM "don't see a significant market" but don't understand the magnitude of their decisions. (And I worked on 4 different projects that were done to DAL A or equivalent using PowerPC, including significant parts of the F-35 fighter jet!) So I'd like to know where all of this is going, and how determinism is going to be kept available for those of us who REALLY need it??

[jlawton11]

Thank you for pointing that out to me, I can see where it is heading although it does seem like "a lot of overkill" for a bare-metal RTOS (Linux, Yocto, hypervisor...!). But while I'm on the topic, people who are consciously passing audio through a computer are very likely trying to do what is called digital signal PROCESSING. When I look at this "application" I can see some elementary signals being generated but mostly "streams" being passed from one port to another. What many people would consider a "useful" software base would be one where there is a time "window" for any stream during which the signal in some stream gets "processed" by one or more CPUs during some interval (the duration of which is certainly a function of the stream's sample rate). I suppose this is POSSIBLE in this system but I don't see any "base interval" measured and defined to be reserved exclusively for such processing specified for this situation, and in its absence it makes me wonder if there even is ANY time left for processing, or if it's all "pre-allocated" for all these subsystems messaging to each other, does anyone happen to know if there is any processing time left to be scheduled, and what fraction of the sample interval that would be?

[kenli]

Perhaps you need to know about our Real-Time Edge software SDK.

[jlawton11]

Thank you for making me aware of this, but this certainly seems like a radically complex collection of elements (Linux, Yocto, hypervisor...!) to implement what only needs to be a "bare-metal" (but strictly deterministic) RTOS. I have read many of the accompanying documents but there's still part of this that isn't coming through for me, most people who are trying to send audio with precision through a computer are attempting to do digital signal PROCESSING, and to that end they are going to need some large fraction of the sampling interval that can be independently allocated in which to do that processing. In the example given it's mostly about passing around EXISTING streams, there is also some generation of some trivially simple streams but there doesn't seem to be any identification of such an interval and how large a fraction of the sampling interval is actually available for processing for a given sample rate. If I can't find such an interval it seems it might be mostly eaten up by all these subsystems communicating with one another, but based on the available information it's impossible to tell. The same issue would apply (albeit with much slower sample rates) for other issues like the jet engine controls for an aircraft that might also need absolute determinism. Do you happen to know roughly what that fraction might happen to be in the cited example say for Harpoon?