These are minutes from two meetings on this topic 2021-12-05 and 2021-12-13.
Preparation:
see also HV Project Deep-dive topics for 2021 June and forward
Purpose:
Discuss and share knowledge on the current landscape of low-level IPC (a.k.a. ICC / Inter-chip communication) on heterogeneous SoCs.
Discuss opportunities for improvement and alignment if that can reduce development effort / cost / risk for ECU development.
...
- "It depends on your input requirements"
- (Gunnar): Yes but... how many tradeoffs do we have. How many choices are required? Investigate this deeper...
- Ring-buffer vs. Shared Memory are two methods that were highlighted
Thomas' presentation IVI focused?- Yes, one key described use case was trigger on VBLANK, transfer graphics
- IC-COM
- Little information in the group
- AUTOSAR choice?
- Bosch provided open implementation
- ...uncertain in the group if this is very relevant
- OpenAMP
- Low latency optimized
- For resource constrained e.g. MCUs
- Few queues
- Small shared memory kilobyte-range
- => not for high bandwidth
- RP message
- Thomas' presentation: RP message used a control channel, graphics transfer used a (shared mem) side channel
- Hardware features
- Mailboxes, Dual-port memories
- => Can be used but nowadays you can usually map large RAM areas as shared memory
- Data exchange needs to be orchestrated if using shared memory → hence protocols, like VIRTIO
- Gunnar: Are these shared-memory implementations considering write-protecting the buffer (e.g. Sealing feature in Linux)?
- Stephen: Does this become limited to requiring Linux on both sides?
- Gunnar: I don't know if other OSes implement a similar feature
- José: MiPi. Higher-level protocols exist. Similar to SOME/IP.
- Discussion question: "Is diversity/fragmentation of (low-level) IPC/ICC choice a challenge for efficient development?"
- Stephen: Definitely
- Dan: Generally Linux is enabled first on hardware. When you switch to RTOS you are lagging behind. We are working on combining Linux and RTOS by allowing RTOS to "reuse" certain services from Linux. It could include initializing the hardware, or higher-level services like filesystem access.
- Gunnar: Does Linux drive diversity in the low-level IPC/ICC choice?
- Dan: Usually the hardware brings the diversity
- Gunnar: ... because SVs bring a favorite choice or the actual hardware features?
- José: Programming language differences also matter. Linux can hide the mechanism of communication. Tools create C++ and other high-level language but I prefer C. Frameworks like flatbuffer have better support for other languages than for C.C support but it is not as good as for other languages.
- Gunnar: Understood. I'm guessing on low-level IPC / ICC a lot of the implementations are in kernel-space for Linux, or in RTOS, so this means it is likely written in C (quick mention: Rust coming(?) also in Linux kernel)
- Discussion question: "What (if anything) is preventing simply agreeing on one (few) choice(s)?"
- Stephen: Lack of discussion is one part.
- Bernhard: A lot of safety island focus currently. Implementation challenges may include limited address space (e.g. 32 bit) for some involved cores.
- Bernhard: Further industry feedback needed.
- ... fiunal consensus seems to be that convergence towards one/few standards is worth doing.
- Gunnar: Challenge to all: Figure out needed stakeholders to come together to make the those agreements.
Next week :availability?
- Apologies: Stephen, Bernhard, Adam, at least.
- Conclusion: Restart meeting series next year, with this topic and other Deep Dive topics
...