Arm brengt chipontwerp met Armv9-cores voor auto's uit

Arm komt met een aantal nieuwe chipontwerpen die specifiek voor auto's zijn bedoeld. Het gaat om een 'Automotive Enhanced'-editie van eerdere Neoverse V3-architectuur. Het gaat onder andere om architectuur op basis van Armv9-cores.

Het is voor het eerst dat op Armv9 gebaseerde technologie beschikbaar komt voor automotive. Het gaat om de Cortex A720AE en de A520AE. Die eerste is volgens het bedrijf bedoeld voor zogenaamde ‘software-defined vehicles’ of SDV’s, auto’s waarbij nieuwe functionaliteiten worden toegevoegd via de software. Het tweede soc-ontwerp is voornamelijk bedoeld voor applicaties waarbij efficiënt stroomverbruik nodig is.

Naast de op Armv9 gebaseerde ontwerpen brengt het bedrijf ook voor het eerst een serverchiparchitectuur naar auto's. Het gaat om de Neoverse V3AE, een aangepaste versie van de derde generatie van de Neoverse-socs die het bedrijf eerder dit jaar uitbracht. Die cpu's zijn volgens het bedrijf voornamelijk bedoeld om zelfrijdende auto's en auto's met Advanced Driver Assistance Systems of ADAS aan te sturen.

Arm komt ook nog met een derde, 64bit-cpu-ontwerp. Dat is de Cortex-R82AE, waar het verder weinig details over geeft. Tot slot brengt het bedrijf ook nog een variant van zijn vijfde generatie Mali-gpu uit 2023 uit, de Mali-C720AE. Die is bedoeld om beelden te verwerken die auto's opslaan voor zelfrijdende systemen.

Arm wil in de toekomst meer inzetten op hardware voor auto's. Het bedrijf wil onder andere het Compute Subsystem- of CSS-platform, dat het eerder voor de derde generatie Neoverse-architectuur uitbracht, ook beschikbaar maken voor deze nieuwe autochips. Daarmee kunnen chipfabrikanten de Neoverse-architectuur in hun eigen hardware integreren. Arm verwacht dat platform in 2025 uit te kunnen brengen.

Reacties (26)

[Balance]

Arm lanceert niet elk jaar automotive IP ontwerpen, zoals het met consumenten (Cortex) en server (Neoverse) CPUs doet. De vorige keer was in september 2020, toen bracht het de Arm Cortex-A78AE cpu, Mali-G78AE gpu en Arm Mali-C71AE vision processor uit. Daarvoor kwam de A76AE in september 2018.

Deze release laat duidelijk zien dat Arm wilt uitbreiden. Want:

• Voor het eerst brengt Arm niet één enkel CPU-ontwerp uit, maar drie.
  • Een kleine, in-order CPU zoals de Cortex-A520AE kan enorm ruimte efficiënt zijn en kan achtergrondtaken gemakkelijk draaien.
  • De Cortex-720AE is een superscalar out-of-order CPU ontwerp, maar nog steeds redelijk stroom en ruimte efficiënt. Daarom zal deze de bulk van het werk verrichten op de meeste ontwerpen.
  • Een Neoverse-V chip is bijzonder interessant, dit zijn de krachtigste serverchips die ze hebben. Blijkbaar is er, naast krachtige GPUs, NPUs, en VPUs, ook behoefte aan een krachtige CPU om de boel aan te sturen.
• Mali-C720AE is ook interessant, dit is compleet nieuw IP! Er is geen "normale", niet AE-tegenhanger. Als ik hem vergelijk met de voorganger (de Mali-C71AE), gaat de maximale resolutie per camera van 4096x2560 naar 8192x4608. Nog steeds zijn er 4 real-time camera's ondersteund, of 16 "virtuele", waarbij de resolutie over meerdere camera's verdeeld is. Verder is de throughput van maximaal 1200 naar 1500 megapixels per seconde verhoogd.
• Verder is de komst van een realtime-processor heel interessant. Die kan cruciale taken uitvoeren met gegarandeerde latency - iets duurt dus nooit langer dan een bepaalde limiet. Vooral voor aansturing lijkt me dat nuttig, bijvoorbeeld het elektronisch regelen van gebruikersinput (pedalen, stuur). Omdat deze nu ook 64-bit is en met de AE-variant alle certificaties heeft, kun je je platform nu volledig 64-bit bouwen.

Oftewel, dit ziet er uit als een serieuze uitbreiding van Arm zijn automotive ambities. Ben benieuwd wanneer ze met een automotive NPU komen!

[Reactie gewijzigd door Balance op 26 juli 2024 16:22]

[GarBaGe]

"De Arm Cortex-R82AE is een realtime processor voor functionele veiligheid, die 64bit-computing naar realtime processing brengt"
huh?!?
Zijn alle processors niet standaard realtime processors?
Ik zit in mijn hoofd met een context waarbij realtime doorgaans slaat op het OS en programmeer taal (dus software, niet hardware), waarbij belangrijke systeem events asap worden afgehandeld.

[latka]

Real time betekent maar 1 ding: alles heeft een maximale tijd die het duurt. Dus een de tijd tussen een interrupt ontvangen en de interrupt handler uitvoeren is maximaal X en nooit meer. Ook niet als de cache van de cpu leeg is of als er net een moeilijke berekening plaatsvind (delen oid). Dus realtime is voornamelijk een hardware ding. Een realtime os op een niet realtime cpu is vrij zinloos.

[laurxp]

De truc hier is dat de processor ontworpen is om zowel realtime code (dus code die gegarandeerd binnen een bepaald timeframe taken uitvoert) als traditionele niet-realtime code (zoals bijvoorbeeld Windows of Linux: alles draait met best-effort, maar je pc kan net zo goed hangen als iets 100% cpu vraagt) tegelijkertijd op dezelfde processor uit te voeren.

Het is voor mij alleen niet helemaal duidelijk wat ze daar nou precies voor doen - volgens mij kom je namelijk al een heel eind door het RT-gedeelte een dedicated core en memory range te geven. Wellicht is er het risico dat een DMA-transfer van de traditionele code de RT-code in de weg zit ofzo?

[MSalters]

Nee, Linux heeft al een hele tijd real-time extensies. En zelfs Windows hangt niet wanneer een doorsnee proce 100% CPU vraagt.

En ja, je kunt inderdaad een hele core aan een RT-subsystem verspillen. Maar als je een context switch in <1 ms kunt doen, dan kun je RT taken van X ms en een deadline >X+1 ook schedulen op een gewone core. Memory ranges reserveren is niet echt nodig. RT taken alloceren hun geheugen standaard vantevoren, dus die hoeven niet in een reserved range te zoeken.

[laurxp]

Je hebt niks aan de (vrij experimentele) RT patches voor Linux als je een automotive RTOS moet draaien, denk bijvoorbeeld aan AUTOSAR. Windows is hier compleet zinloos, want het geeft geen enkele garantie op de executie-tijd van je taken. Wellicht dat je muis gewoon nog beweegt, maar reken er maar niet op dat alle taken daadwerkelijk aan bod komen.

Je kan inderdaad gaan klungelen met context switches op een enkele processor, maar als het gaat om safety-critical toepassingen is het veel aantrekkelijker om er dedicated hardware voor te gebruiken. Er zijn simpelweg te veel bewegende delen, en het is in de praktijk eigenlijk niet te doen om te bewijzen dat het schakelen altijd goed gaat. En als je het niet kan bewijzen, dan kan je ook niet voldoen aan de veiligheidseisen voor gebruik in bijvoorbeeld auto's.

Traditioneel gebruik je gewoon een aparte processor voor je RTOS en voor je niet-kritieke taken, maar met deze nieuwe ARM-core kan dat dus in een enkele chip.

[rvt1]

Je kunt prima realtime specificaties hebben waar niet alle CPU’s aan kunnen voldoen. Maaaar, in basis zicht realtime alleen iets over de zekerheid van de timings. Als voor jouw specificatie 1seconde hard realtime per tick is, dan kan dat prima werken. Als dat nu 100us moet zijn met meer dan een core dan kan dat anders zijn.
Er zal wel wat meer achter het marketing print praat zitten natuurlijk, geen enkele engineer zal daar zomaar intrappen dus de specs er maar even bij pakken…

[Jan Onderwater]

De claim is "Arm Cortex-R82AE: The highest-ever performing real-time processor for functional safety which delivers 64-bit computing to real-time processing for the very first time"
Het brengt 64 bits real time processing, zegt Arm, vind het een wat vreemde claim
Het process is real time, itt batch processing,
Wellicht bedoelen ze real time computing, of hebben ze een automotive eigen definitie.
https://en.wikipedia.org/wiki/Real-time_computing

[P5ycho]

'asap' is natuurlijk niet echt een term die goed past bij realtime.
Afhankelijk van de eisen die je stelt zou het best zo kunnen zijn dat je ook eisen moet gaan stellen aan de hardware.
Als je moet garanderen dat je binnen een bepaalde tijd een bepaalde respons kunt geven dan wil je misschien garanties voor het fetchen van data uit memory, validiteit van data in je cache, respons van peripherals op de bus, etc.

[bramseltje]

Na het nieuwsbericht van ARM zelf gelezen te hebben, vermoed ik dat ze iets anders bedoelen...

Arm Cortex-R82AE: The highest-ever performing real-time processor for functional safety which delivers 64-bit computing to real-time processing for the very first time

Hier bedoelen ze waarschijnlijk dat ze de eerste zijn die een 64bits platform inclusief safety functies* aanbieden, voor gebruik in real-time processing (zoals nodig voor hulpsystemen).

Blijft vreemd dat ze het een 'real-time processor' noemen, aangezien ik toch aan mag nemen dat elke processor in real-time zijn instructies uit voert

Voor wat meer context vanuit het 'automotive' domein: w: Functional Safety

[Reactie gewijzigd door bramseltje op 26 juli 2024 16:22]

[komododraak]

Altijd leuk als je CPU zuinig is maar.. in je auto die iedere week 80KWh gebruikt is dat niet zo relevant lijkt mij

[kroegtijger]

Behalve dan dat deze uit je accessoires-accu wordt gevoed en niet uit de accu van je aandrijflijn. Accessoires-accu's zijn bij EV"s vaak maar heel klein (je hoeft er immers geen startmotor mee aan te slinger oid). Regelmatig dat EV's dan ook met een lege accu hiervan staan. Zat rij-bereik, maar geen mogelijkheid je auto aan te zetten omdat alle bijkomstige elektronica de accu plat heeft getrokken.

De meeste auto's kunnen hun accessoires-accu weer bijladen vanuit de accu van de aandrijflijn, maar dat is in de meeste gevallen niet continue. Vaak dat slechts enkele keren per week wordt gecontroleerd of daar noodzaak toe is. Dergelijke processoren worden over het algemeen niet uit gezet, en dus kan een processortje dat een hoop verbruikt net genoeg zijn om de accu wel degelijk plat te trekken. Een energie-zuinige processor heeft daarom wel degelijk zin.

[procyon]

Phantom drain is anders nog steeds een ding. Stel dat je boordcomputer tijdens een actief alarmsysteem 200 watt gebruikt, dan is dat echt substantieel verbruik op een dag. Zeg (ruim 4kW/h)

Zuinigere hardware is echt heel erg nodig. Als ARM hierin kan helpen in toekomstige automodellen dan scheelt dat letterlijk gigawatts aan sluipverbruik.

[MSalters]

Volgens mij is het vrij normaal dat ADAS CPU's uitgezet worden als de auto niet rijdt. Het is Driver Assistance, tenslotte. Bij een geparkeerde, stilstaande auto wil je alleen maar een klein real-time processortje hebben draaien, voor een alarmsysteem en de sleutels. Dat heeft geen OS of andere complexiteit nodig; dat kan prima in 100mW tegenwoordig.

[komododraak]

aha. vandaar. wonderlijk dat ze niet automatisch de EV accu gebruiken als de 2e accu onder de 20% komt. dat moet echt eenvoudig te maken zijn.

[remcoVer]

Je kunt laag verbruik ook vertalen naar gevraagde koelvermogen. Automotive betekend: werken in een range van -40 tot +105 graden, en ook nog een 80/80. Dus 80 graden Celsius bij 80% relatieve luchtvochtigheid. Dus als je een zuinig chip hebt is het makkelijker om over een groter omgevingsgebied te werken.

note: temperatuur range aangepast.

[Reactie gewijzigd door remcoVer op 26 juli 2024 16:22]

[Vaevictis_]

Dit is een directe reactie op NVidia die ook een SoC heeft edge computing voor automotive. Er komt veel vraag naar die soort chips om autonoom rijden mogelijk te maken zoals realtime beeldherkenning met AI.

Aangezien dit onderdeel is van een safety systeem zal dit dus NIET vanuit de 12V accu worden gevoed. @kroegtijger

[bramseltje]

Ik wilde graag meer lezen, bijvoorbeeld in de aankondiging van ARM zelf. Helaas is het artikel alleen voorzien van een linkje naar een ouder t.net nieuwsbericht, dus voor de andere luie mensen:https://newsroom.arm.com/...omotive-technologies-2024

[proatjeboksem]

Zou je over jaar of wat dan ook bij xda-developers een nieuwe rom voor je auto kunnen vinden?
Als de fabrikant de auto niet meer ondersteunt oid?

En hopelijk maken ze die dingen met universele stekkers/aansluiting vast in de auto, dat je ook na een paar jaar nog kunt upgraden naar ARMvhoger

[bzzzt]

Wie gaat de rekening betalen als je een ongeluk krijgt omdat iemand vergeten is de remfunctie te implementeren in zo'n rom?

[The Zep Man]

Wie gaat de rekening betalen als je een ongeluk krijgt omdat iemand vergeten is de remfunctie te implementeren in zo'n rom?

Wie gaat de rekening betalen als je een ongeluk krijgt omdat je je eigen ICE onderhoudt en vergeet om de auto te voorzien van voldoende remvloeistof?

[proatjeboksem]

Goeie vraag. En wat mag je wijzigen aan een automotive pc?
Alleen entertainment en luxe functies?

We gaan het beleven, denk ik.

aanvulling: leuk filmpje dat ik ooit zag over iemand die zijn smart zelfrijdend had gemaakt
met https://www.comma.ai/openpilot
https://www.youtube.com/watch?v=Te4AhlRXnLw

[Reactie gewijzigd door proatjeboksem op 26 juli 2024 16:22]

[bzzzt]

Goeie vraag. En wat mag je wijzigen aan een automotive pc?
Alleen entertainment en luxe functies?

Zelfs daar zijn standaarden voor. Bijvoorbeeld geen film afspelen op het scherm voor de bestuurder wanneer de auto rijdt. Dat soort functionaliteit moet gekeurd worden voordat een auto de weg op mag.

[iqcgubon]

Wordt het gemiddelde infotainment systeem dan ook wat sneller? Dat lijkt soms op een Pentium III te draaien.

[desyco]

Dus vanaf nu ook iedere x-aantal maanden een upgrade van je auto-software ? Totdat de auto end-of-support is (euh... softwarematig ; de hardware zou nog perfect kunnen rijden).
Ik heb hier nog een telefoon liggen (vergelijk het met de auto's van 20 jaar geleden)... OK, dat was pulse-dial (zoals die auto : zonder enige elektronica)... maar die werkt NU nog ! De Cisco-telefoon in ons bedrijf van 20 jaar geleden... (gemakkelijk 10 keer zo duur) die ligt al meer dan 10 jaar op de digitale vuilnisbelt ! Niet omdat hij niet meer werkte, maar omdat de telefoniecentrale er niet meer kon (lees 'mocht') mee werken.

En... die fabrikant van die telefoons van 20 jaar geleden, die mag al lang failliet zijn gegaan ; die telefoon werkt nog steeds. Het is niet de eerste keer dat een producent van elektronicamateriaal failliet gaat en dat al de (connected) toestellen hierdoor end-of-life worden...

Dat zijn zaken die ik niet wil voorhebben met een (dure) auto !!!
Hoe minder (vooral connected) software, hoe beter !