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 on heterogeneous SoCs.
Discuss opportunities for improvement and alignment if that can reduce development effort / cost / risk for ECU development.
...
- Presentation of one option for IPC (Cortex-R7 to Cortex-A5x cores) : Thomas Bruss (Renesas)
- Discussion of presentation
- Further discussion, driven by the questions below.belo
Minutes/Findings
- "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.
- 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.
- Gunnar: Challenge to all: Figure out needed stakeholders to come together to make the agreements.
Next week:
- Apologies: Stephen, Bernhard, Adam,
- Conclusion: Restart meeting series next year, with this topic and other Deep Dive topics
Discussion questions:
Factors affecting choice
What factors affect the choice of IPC?
- Technology / optimization?
- Tier-1 preference (previous experience)?
- Silicon Vendor preference?
- Why is a certain choice preferred?
Are there any standard ways that can be agreed upon?
Is IC-COM a standard? AUTOSAR preferred choice?
Are there others?
Does AUTOSAR have specific choices, and how does that apply on non-AUTOSAR systems?
Is diversity/fragmentation of IPC choice a challenge for efficient development?
What (if anything) is preventing simply agreeing on one choice?
Detailed operation
...
Relationship to (other parts of) SW stack?
Flexibility (available implementation) towards upper and lower protocols (think OSI-stack).
Are higher-level protocols layered on top of the simple communication, or or not? How does the choice of low-level IPC affect that?
In relation to connecting downward to hardware, what are the implementation challenges?
...
Does it depend on particular hardware features (hardware-supported mailboxes, dual-port memories, com. buses,...?)
(E.g. if you choose A, then you have simple integration of technologies 1, 2, and 3, but for choice B available integrations are more limited)
CPU architecture differences?
- RISC-V, Arm, SH, ...
Applicability
- Communication between different cores on an SoC.
- Inter-ECU? Between SoCs / CPUs.
E.g. shared PCI network,
Full network (Ethernet)