12 mei 2025·8 min
Het licentiemodel van Arm: CPU‑IP opschalen via ecosysteemfit
Hoe Arm groeide door CPU‑IP te licentiëren voor mobiel en embedded — en waarom software, tools en compatibiliteit soms belangrijker zijn dan het bezit van fabs.
Hoe Arm groeide door CPU‑IP te licentiëren voor mobiel en embedded — en waarom software, tools en compatibiliteit soms belangrijker zijn dan het bezit van fabs.
Arm is niet invloedrijk geworden door kant-en-klare chips te leveren. In plaats daarvan schaalt het bedrijf door CPU‑ontwerpen en compatibiliteit te licentiëren — de bouwstenen die andere bedrijven in hun eigen processors kunnen opnemen, in hun eigen producten, volgens hun eigen productieschema's.
"CPU‑IP‑licenties" betekent in wezen dat je een beproefd set blauwdrukken verkoopt plus het juridische recht om ze te gebruiken. Een partner betaalt Arm om een bepaald CPU‑ontwerp (en verwante technologie) te gebruiken en integreert dat vervolgens in een grotere chip die ook grafische eenheden, AI‑blokken, connectiviteit, beveiligingsfuncties en meer kan bevatten.
De taakverdeling ziet er zo uit:
In halfgeleiders kan "betere productie" een sterk voordeel zijn — maar dat is vaak tijdelijk, duur en moeilijk te vertalen naar veel markten. Compatibiliteit daarentegen stapelt zich op. Wanneer veel apparaten een gemeenschappelijke basis delen (instructieset, tools, OS‑ondersteuning), profiteren ontwikkelaars, fabrikanten en klanten van voorspelbaar gedrag en een groeiend softwareaanbod.
Arm is een duidelijk voorbeeld van hoe ecosysteemfit — gedeelde standaarden, toolchains en een groot partnernetwerk — waardevoller kan worden dan het bezit van fabrieken.
We houden de geschiedenis op hoofdlijnen, leggen uit wat Arm precies licentieert en laten zien hoe dit model zich verspreidde over mobiele en embedded producten. Daarna ontleden we de economie in gewone termen, de afwegingen en risico's, en sluiten we af met praktische platformlessen die je ook buiten chips kunt toepassen.
Voor een korte preview van de bedrijfsmechanica: kijk naar the-licensing-economics-plain-english-version.
Arm verkoopt niet "chips" in de gebruikelijke zin. Wat het verkoopt is toestemming — via licenties — om Arm intellectueel eigendom (IP) in chips te gebruiken die andere bedrijven zelf ontwerpen en fabriceren.
Het helpt om drie lagen te scheiden die vaak door elkaar gehaald worden:
Arms licenties bevinden zich grotendeels in de eerste twee lagen: de regels (ISA) en/of een kant-en-klare CPU‑ontwerp (core). De licentienemer bouwt de volledige SoC daaromheen.
De meeste gesprekken vallen grofweg in twee modellen:
Afhankelijk van de overeenkomst krijgen licentienemers doorgaans RTL (hardwareontwerpcode), referentieconfiguraties, documentatie, validatie‑materiaal en engineeringondersteuning — de ingrediënten die nodig zijn om te integreren en een product te leveren.
Wat Arm gewoonlijk niet doet, is chips fabriceren. Dat deel wordt door de licentienemer en hun gekozen foundry plus packaging/testpartners afgehandeld.
Chipproductie is duur, traag en vol met "unknown unknowns." Een licentiemodel schaalt omdat het veel bedrijven in staat stelt een CPU‑ontwerp te hergebruiken dat al gevalideerd is — functioneel, elektrisch en vaak zelfs in siliconen. Hergebruik vermindert risico (minder verrassingen laat in het schema) en verkort de time‑to‑market (minder ontwerpen vanaf nul, minder bugs om op te lossen).
Een moderne CPU‑core is een van de moeilijkste blokken om goed te krijgen. Als er een bewezen core beschikbaar is als IP, kunnen partners hun moeite richten op differentiatie:
Dat creëert parallelle innovatie: tientallen teams kunnen verschillende producten bouwen op dezelfde basis, in plaats van te wachten op de roadmap van één bedrijf.
Bij een verticaal geïntegreerde aanpak ontwerpt één bedrijf de CPU, ontwerpt de SoC, valideert die en levert de uiteindelijke chip (en soms ook de apparaten). Dat kan uitstekende resultaten opleveren — maar opschaling wordt beperkt door de engineeringbreedt e van die ene organisatie, toegang tot productie en vermogen om veel niches tegelijk te bedienen.
Licentiëring keert dat om. Arm focust op de herbruikbare "core"‑problemen, terwijl partners concurreren en specialiseren rond die basis.
Naarmate meer bedrijven compatibele CPU‑ontwerpen leveren, investeren ontwikkelaars en toolleveranciers zwaarder in compilers, debuggers, besturingssystemen, libraries en optimalisaties. Betere tools maken het makkelijker om het volgende apparaat te leveren, wat de adoptie weer verhoogt — een ecosysteem‑vliegwiel dat één chipmaker moeilijk in zijn eentje evenaart.
Mobiele chips ontwikkelden zich onder strenge beperkingen: kleine apparaten, geen ventilatoren, beperkte oppervlakte om warmte kwijt te raken en een batterij waarvan gebruikers verwachten dat die de hele dag meegaat. Die combinatie dwingt CPU‑ontwerpers om energie en thermiek als eersteklas vereisten te behandelen, niet als bijzaak. Een telefoon kan niet langdurig extra watts gebruiken zonder warm te worden, te throttlen en de batterij leeg te trekken.
In die omgeving is de winnende maatstaf geen ruwe benchmarkroem — het is performance per watt. Een CPU die op papier iets langzamer is maar weinig stroom verbruikt, kan een betere gebruikerservaring bieden omdat hij snelheid kan vasthouden zonder oververhitting.
Dat is een belangrijke reden dat Arms licentiemodel in smartphones aansloeg: de ISA en coreontwerpen van Arm sloegen aan bij het idee dat efficiëntie het product is.
Arms CPU‑IP‑licenties losten ook een marktvraag op: telefoonfabrikanten wilden variatie en concurrentie tussen chipleveranciers, maar konden zich geen gefragmenteerde softwarewereld veroorloven.
Met Arm konden meerdere chipontwerpers verschillende mobiele processors bouwen — met hun eigen GPU's, modems, AI‑blokken, geheugencontrollers of energiebeheerstrategieën — terwijl ze compatibel bleven op CPU‑niveau.
Die compatibiliteit was belangrijk voor iedereen: app‑ontwikkelaars, OS‑leveranciers en toolmakers. Als het onderliggende doel consistent blijft, verbeteren toolchains, debuggers, profilers en libraries sneller — en kost het minder om te ondersteunen.
Smartphones werden in enorme aantallen verscheept, wat de voordelen van standaardisering vergrootte. Grote volumes rechtvaardigden diepere optimalisaties voor Arm‑gebaseerde chips, stimuleerden bredere software‑ en toolondersteuning en maakten Arm‑licenties de "veilige standaard" voor mobiel.
In de loop van de tijd hielp die terugkoppeling CPU‑IP‑licenties om beter te concurreren dan benaderingen die vooral op één bedrijf zijn productievoordeel leunden in plaats van op ecosysteemcompatibiliteit.
"Embedded" is geen enkele markt — het is een verzamelnaam voor producten waarin de computer ingebouwd is: huishoudelijke apparaten, industriële controllers, netwerkapparatuur, automotive systemen, medische apparaten en een enorme reeks IoT‑hardware.
Wat deze categorieën gemeen hebben, gaat minder over features en meer over beperkingen: strakke energiebudgetten, vaste kostendoelen en systemen die voorspelbaar moeten functioneren.
Embedded producten worden vaak jarenlang verkocht, soms tien jaar of langer. Dat betekent dat betrouwbaarheid, beveiligingspatching en leveringscontinuïteit net zo belangrijk zijn als piekprestaties.
Een CPU‑basis die compatibel blijft over generaties vermindert churn. Teams kunnen dezelfde softwarearchitectuur behouden, libraries hergebruiken en fixes terugporten zonder alles opnieuw te schrijven voor elke nieuwe chip.
Wanneer een productlijn lang na lancering onderhouden moet worden, wordt "het draait nog steeds dezelfde code" een zakelijk voordeel.
Het gebruik van een veelgebruikte Arm‑instructieset over veel apparaten maakt werving en operatie eenvoudiger:
Dit is vooral nuttig voor bedrijven die meerdere embedded producten tegelijk uitrollen—elk team hoeft het platform niet opnieuw uit te vinden.
Embedded portfolio's hebben zelden één "beste" apparaat. Ze kennen tiers: goedkope sensoren, midrange controllers en high‑end gateways of automotive compute‑units.
Het ecosysteem van Arm laat partners cores kiezen (of hun eigen core ontwerpen) die bij verschillende energie‑ en prestatiedoelen passen terwijl ze vertrouwde softwarefundamenten behouden.
Het resultaat is een coherente productfamilie: verschillende prijspunten en capaciteiten, maar compatibele ontwikkelworkflows en een soepeler upgradepad.
Een goede fabriek kan chips goedkoper maken. Een sterk ecosysteem kan het goedkoper maken om producten te bouwen, leveren en onderhouden.
Wanneer veel apparaten een compatibele CPU‑basis delen, is het voordeel niet alleen performance‑per‑watt — het is dat apps, besturingssystemen en ontwikkelaarsvaardigheden overdraagbaar zijn tussen producten. Die overdraagbaarheid wordt een zakelijk actief: minder tijd om te herschrijven, minder onverwachte bugs en een grotere pool van engineers die de tools al kennen.
Arms langetermijnstabiliteit van ISA en ABI betekent dat software die voor één Arm‑apparaat is geschreven vaak blijft werken — soms met alleen een hercompilatie — op nieuwere chips en siliconen van andere leveranciers.
Die stabiliteit verlaagt verborgen kosten die zich over generaties opstapelen:
Zelfs kleine veranderingen tellen mee. Als een bedrijf van "Chip A" naar "Chip B" kan overstappen zonder drivers te herschrijven, de hele codebasis opnieuw te valideren of het team opnieuw op te leiden, kan het leveranciers sneller wisselen en op schema leveren.
Compatibiliteit gaat niet alleen over de CPU‑core — het gaat over alles eromheen.
Omdat Arm breed wordt ondersteund, komen veel derdepartijcomponenten "kant-en-klaar": crypto‑libraries, video‑codecs, ML‑runtimes, netwerkstacks en cloud‑agent SDK's. Silicon‑leveranciers leveren ook SDK's, BSP's en referentiecode die bekend aanvoelen voor ontwikkelaars die eerder op andere Arm‑platforms hebben gewerkt.
Productieschaal kan de eenheidsprijs verlagen. Ecosysteemcompatibiliteit vermindert de totale kosten — engineeringtijd, risico en time‑to‑market — vaak nog meer.
Arm‑licenties gaan niet alleen over het verkrijgen van een CPU‑core of een instructiesetarchitectuur. Voor de meeste teams is de doorslaggevende factor of ze vanaf dag één snel kunnen bouwen, debuggen en uitbrengen. Daar stapelt de diepte van het ecosysteem van tooling stilletjes over de tijd op.
Een nieuwe chipleverancier kan een geweldige microarchitectuur hebben, maar ontwikkelaars vragen nog steeds basale dingen: kan ik mijn code compileren? Kan ik crashes debuggen? Kan ik prestaties meten? Kan ik testen zonder hardware?
Voor Arm‑platforms is het antwoord meestal "ja" omdat de tooling breed gestandaardiseerd is:
Dankzij CPU‑IP‑licenties brengen veel verschillende bedrijven Arm‑compatibele chips uit. Als elk daarvan een unieke toolchain vereiste, zou elke nieuwe leverancier aanvoelen als een compleet nieuw platformport.
In plaats daarvan betekent Arm‑compatibiliteit dat ontwikkelaars vaak bestaande buildsystemen, CI‑pipelines en debugworkflows kunnen hergebruiken. Dat vermindert de "platformtax" en maakt het makkelijker voor een nieuwe licentienemer om ontwerpposities te winnen — vooral in mobiele processors en embedded systemen waar time‑to‑market telt.
Tooling werkt het beste wanneer de softwarestack er al is. Arm profiteert van brede ondersteuning in Linux, Android en een scala aan RTOS‑opties, plus gangbare runtimes en libraries.
Voor veel producten verandert dat chip‑bring‑up van een onderzoeksproject in een herhaalbare engineeringtaak.
Als compilers stabiel zijn, debuggers vertrouwd en OS‑poorten bewezen, itereren licentienemers sneller: vroegere prototypes, minder integratieverrassingen en snellere releases.
In de praktijk is die snelheid een groot deel van waarom het Arm‑licentiemodel schaalt — CPU‑IP is de basis, maar tools en softwaretoolchains maken het op schaal bruikbaar.
Arms model betekent niet dat elke chip hetzelfde is. Het betekent dat partners beginnen vanaf een CPU‑basis die al "past" bij de bestaande softwarewereld, en vervolgens concurreren op hoe ze de rest bouwen.
Veel producten gebruiken een breed compatibele Arm‑CPU‑core (of cluster) als algemene motor, en voegen dan gespecialiseerde blokken toe die het product definiëren:
Het resultaat is een chip die vertrouwde besturingssystemen, compilers en middleware draait, maar toch uitblinkt op performance‑per‑watt, functies of stuklijstkosten.
Zelfs wanneer twee leveranciers vergelijkbare CPU‑IP licentiëren, kunnen ze uit elkaar groeien via SoC‑integratie: geheugencontrollers, cachegroottes, energiebeheer, camera/ISP‑blokken, audio‑DSP's en hoe alles on‑die is verbonden.
Deze keuzes beïnvloeden het daadwerkelijke gedrag — batterijduur, latentie, thermiek en kosten — vaak meer dan een klein verschil in CPU‑snelheid.
Voor telefoonmakers, apparaatmerken en industriële OEMs verlaagt een gedeelde Arm‑softwarebasis vendor‑lock‑in. Ze kunnen van leverancier wisselen (of dubbellevering toepassen) terwijl ze grotendeels dezelfde OS, apps, drivers en ontwikkeltools behouden — en zo vermijden ze een "product herschrijven"‑scenario als levering, prijs of prestaties veranderen.
Partners differentiëren ook door referentieontwerpen, gevalideerde softwarestacks en bewezen bordontwerpen te leveren. Dat vermindert risico voor OEMs, versnelt regelgevings‑ en betrouwbaarheidswerk en verkort time‑to‑market — soms doorslaggevend tegenover een iets betere benchmarkscore.
Arm schaalt door ontwerpblauwdrukken (CPU‑IP) te verspreiden, terwijl foundries schalen door fysieke capaciteit (wafers) te leveren. Beide maken veel chips mogelijk, maar ze stapelen waarde op verschillende manieren.
Een moderne chip passeert typisch vier partijen:
Arms schaal is horizontaal: één CPU‑basis kan vele chipontwerpers in veel productcategorieën bedienen.
Omdat Arm niet produceert, zitten partners niet vast aan één productiestrategie. Een chipontwerper kan een foundry en proces kiezen die bij de klus passen — een balans tussen kosten, energie, beschikbaarheid, verpakkingsopties en timing — zonder dat de IP‑leverancier een fabriek hoeft te "heruit te rusten."
Die scheiding stimuleert ook experimenten. Partners kunnen verschillende prijspunten of markten targeten terwijl ze op een gedeelde CPU‑basis bouwen.
Foundry‑schaal wordt beperkt door fysieke uitbreidingen en lange planningscycli. Als de vraag verschuift, is het toevoegen van capaciteit niet direct.
IP‑schaal is anders: zodra een CPU‑ontwerp beschikbaar is, kunnen veel partners het implementeren en daar produceren waar het zinvol is. Ontwerpers kunnen vaak productie verplaatsen tussen foundries (afhankelijk van ontwerpkeuzes en overeenkomsten) in plaats van vast te zitten aan één fab‑roadmap. Die flexibiliteit helpt bij het beheren van leveringsrisico's — ook als de productiesituatie verandert.
Arm verdient vooral op twee manieren: voorafgaande licentiekosten en lopende royalty's.
Een bedrijf betaalt Arm voor het recht een bepaald CPU‑ontwerp (of onderdelen ervan) in een chip te gebruiken. Deze vergoeding dekt deels het werk dat Arm al deed — het ontwerpen van de CPU‑core, het valideren ervan, het documenteren en het bruikbaar maken voor veel chipteams.
Denk eraan als betalen voor een bewezen motordesign voordat je begint met autoassemblage.
Zodra chips in echte producten gaan — telefoons, routers, sensoren, apparaten — kan Arm een kleine vergoeding per chip (of per apparaat, afhankelijk van de overeenkomst) ontvangen. Hier schaalt het model: als het product van een partner populair wordt, profiteert Arm mee.
Royalty's stemmen ook prikkels af:
Royalty's belonen brede adoptie, niet alleen één grote deal. Dat stimuleert Arm om te investeren in de onopvallende dingen die adoptie vergemakkelijken — compatibiliteit, referentieontwerpen en langdurige ondersteuning.
Als klanten weten dat software en tools blijven werken over meerdere chipgeneraties, kunnen ze productroadmaps met minder risico plannen. Die voorspelbaarheid vermindert portingskosten, verkort testcycli en maakt het eenvoudiger producten jaren te ondersteunen — vooral in embedded systemen.
Een eenvoudige stroom kan tonen:
Arm → (licentie) → Chipontwerper → (chips) → Apparaatfabrikant → (verkochte apparaten) → Royalty's terug naar Arm
Een door licenties gestuurd ecosysteem kan sneller schalen dan één bedrijf dat alle chips zelf bouwt — maar je geeft ook wat controle op. Als je technologie een basis wordt die door veel partners wordt gebruikt, hangt je succes af van hun uitvoering, hun productkeuzes en hoe consistent het platform zich in de praktijk gedraagt.
Arm levert niet de uiteindelijke telefoon of microcontroller. Partners kiezen proceselementen, cachegroottes, geheugencontrollers, beveiligingsfuncties en energiebeheer. Die vrijheid is het doel — maar het kan kwaliteit en gebruikservaring ongelijk maken.
Als een apparaat traag voelt, oververhit raakt of slechte batterijduur heeft, geven gebruikers zelden het specifieke "core" de schuld. Ze geven het product de schuld. Inconsistentie kan na verloop van tijd de waargenomen waarde van het onderliggende IP ondermijnen.
Hoe meer partners aanpassen, hoe groter het risico dat het ecosysteem in "gelijk-maar-different" uitvoeringen afdrijft. De meeste softwareportabiliteit blijft bestaan, maar ontwikkelaars kunnen op randgevallen stuiten:
Fragmentatie toont zich vaak niet op ISA‑niveau, maar in drivers, firmwaregedrag en platformfeatures rond de CPU.
Een ecosysteemmodel concurreert op twee fronten: alternatieve architecturen en interne ontwerpen van partners. Als een grote klant besluit een eigen CPU‑core te bouwen, kan het licentiemodel snel volume verliezen. Evenzo kunnen geloofwaardige concurrenten nieuwe projecten aantrekken door eenvoudigere prijzen, nauwere integratie of een snellere weg naar differentiatie te bieden.
Partners zetten jarenlange planning in op een stabiel platform. Duidelijke roadmaps, voorspelbare licentietermen en consistente compatibiliteitsregels zijn essentieel. Vertrouwen hangt ook af van goed beheer: partners willen zekerheid dat de platformeigenaar niet onverwacht van koers verandert, toegang beperkt of hun vermogen om te differentiëren ondermijnt.
Arms verhaal herinnert eraan dat schalen niet altijd betekent "meer fabrieken bezitten." Het kan ook betekenen dat je het anderen gemakkelijk maakt compatibele producten te bouwen die toch concurreren op eigen doelen.
Ten eerste: standaardiseer de laag die het meeste hergebruik creëert. Voor Arm is dat de instructieset en core‑IP — stabiel genoeg om software en tools aan te trekken, maar evoluerend in gecontroleerde stappen.
Ten tweede: maak adoptie goedkoper dan overstappen. Duidelijke voorwaarden, voorspelbare roadmaps en goede documentatie verlagen de frictie voor nieuwe partners.
Ten derde: investeer vroeg in de "saaie" enablers: compilers, debuggers, referentieontwerpen en validatieprogramma's. Dit zijn de verborgen multipliers die een technische specificatie veranderen in een bruikbaar platform.
Ten vierde: laat partners differentiëren bovenop de gedeelde basis. Als de basis compatibel is, verschuift concurrentie naar integratie, energie‑efficiëntie, beveiliging, verpakking en prijs — gebieden waar veel bedrijven kunnen winnen.
Een bruikbare softwareanalogie: Koder.ai past een vergelijkbare platformles toe op applicatieontwikkeling. Door de "fundamentlaag" te standaardiseren (een chatgestuurde workflow ondersteund door LLM's en een agentarchitectuur) terwijl teams nog steeds broncode kunnen exporteren, deployen/hosten, eigen domeinen gebruiken en terugrollen via snapshots, vermindert het de platformtax van het uitbrengen van web/mobile/backend apps — net zoals Arm de platformtax verlaagt van het bouwen van chips op een gedeelde ISA.
Licentiëring en ecosysteembouw zijn vaak de betere keuze wanneer:
Verticale integratie is vaak sterker wanneer je strikte controle over levering, opbrengst of een nauw verbonden hardware/software‑ervaring nodig hebt.
Als je nadenkt over platformstrategie — API's, SDK's, partnerprogramma's of prijsmodellen — bekijk meer voorbeelden in /blog.
Compatibiliteit is krachtig, maar geen vanzelfsprekendheid. Ze moet verdiend worden door consistente beslissingen, zorgvuldige versievoering en voortdurende ondersteuning — anders brokkelt het ecosysteem af en verdwijnt het voordeel.
Arm licentieert meestal CPU intellectueel eigendom (IP)—ofwel de instructiesetarchitectuur (ISA), een klaar-om-in-te-integreren CPU-coreontwerp, of beide. De licentie geeft je juridische rechten plus technische leveringen (zoals RTL en documentatie) zodat je je eigen chip daaromheen kunt bouwen.
De ISA is het contract tussen software en hardware: de instructietaal die machinecode gebruikt. Een CPU-core is één concrete implementatie van die ISA (de microarchitectuur). Een SoC (system-on-chip) is het volledige product dat CPU-cores plus GPU, geheugencontrollers, I/O, radio's, beveiligingsblokken enz. bevat.
Een core-licentie laat je een door Arm ontworpen CPU-core integreren in je SoC. Je doet vooral integratie, verificatie en systeemontwerp rond een bewezen CPU-blok.
Een architectuurlicentie stelt je in staat je eigen CPU-core te ontwerpen die de Arm-ISA implementeert, zodat deze Arm-compatibel blijft terwijl je meer controle hebt over microarchitectuurkeuzes.
Veelvoorkomende leveringen zijn:
Omdat CPU-IP herbruikbaar is: zodra een coreontwerp gevalideerd is, kunnen veel partners het parallel integreren in verschillende producten. Die herbruik vermindert risico (minder verrassingen laat in het traject), versnelt schema's en laat elke partner focussen op wat uniek is—zoals energiebeheer, cachegrootte of aangepaste accelerators.
Productievoordeel helpt bij stuksprijs en soms prestaties, maar het is duur, cyclisch en moeilijk toepasbaar op elk nichemarktsegment.
Ecosysteemcompatibiliteit verlaagt de totale productkosten (engineeringtijd, portering, tooling, onderhoud) omdat software, vaardigheden en derdencomponenten overdraagbaar zijn tussen apparaten. Over meerdere generaties kan die "rewrite-tax" dominant worden.
Mobiele apparaten hebben strikte beperkingen op energie en thermiek: duurzame prestaties wegen zwaarder dan korte pieken. Het model van Arm maakte ook concurrentie mogelijk zonder softwarechaos—meerdere leveranciers konden verschillende chips leveren (GPU/modem/NPU-keuzes, integratiestrategieën) terwijl de CPU/softwarebasis compatibel bleef.
Embedded producten hebben vaak lange levenscycli (jaren) en vereisen stabiel onderhoud, veiligheidsupdates en leveringscontinuïteit.
Een consistente CPU/softwarebasis helpt teams om:
Dat is waardevol wanneer je apparaten lang na lancering moet blijven ondersteunen.
Volwassen tooling verkleint de “platformtax.” Voor Arm-doelen kunnen teams meestal rekenen op gevestigde compilers (GCC/Clang), debuggers (GDB/IDE-integraties), profilers en OS-ondersteuning (Linux/Android/RTOS). Dat betekent snellere bring-up, minder verrassingen in toolchains en sneller itereren zelfs vóór de definitieve silicon beschikbaar is.
Gewoonlijk via twee inkomstenstromen:
Als je een gerichte opsplitsing wilt, zie de tekst over the-licensing-economics-plain-english-version.
Je krijgt gewoonlijk geen gefabriceerde chip—fabrikage wordt door de licentienemer en hun foundry verzorgd.