Optimaliseren van pre-silicium softwareontwikkeling

In het huidige, snel evoluerende technologietijdperk is een system-on-chip (SoC) de meest gebruikelijke benadering om aan de behoeften van de markt te voldoen. Een SoC is in feite een processor omringd door functieversnellers en veel I/O voor de bijbehorende randapparatuur die het ondersteunt. Sinds de mobiele datarevolutie in 2002 is het een vereiste geworden om SoC's te gebruiken om de belangrijkste functies die een smartphone definiëren, te vergemakkelijken. Op dezelfde manier zijn SoC's sindsdien het favoriete apparaat geworden voor het maken van 'slimme' consumentenproducten zoals tv's, auto's en de steeds groter wordende Internet-of-Things (IoT)-markt.

De groeiende vraag naar SoC's heeft een zeer competitieve markt gecreëerd. Hierdoor worden SoC's complexer, evolueert de randapparatuur in de SoC's continu en wordt de time-to-market korter. Een cruciaal onderdeel om de complexiteit van SoC-ontwikkeling te evenaren, is de beschikbaarheid van software. Er is weinig ruimte voor fouten en software moet zo snel mogelijk klaar zijn. Om deze uitdaging aan te gaan, moet de softwareontwikkeling worden gestart voordat het SoC-gedeelte beschikbaar is.

SoC-softwareontwikkeling

Traditioneel zou de softwareontwikkeling beginnen nadat het eerste siliciummonster uit de productie was aangekomen. Toen SoC-samples arriveerden, zouden software- en validatieteams hun ontwikkelingsactiviteiten starten en zou een grote SoC-inspanning van start gaan. Teams die aan de SoC werken, zouden van over de hele wereld samenkomen om voor een beperkte tijd onder één dak te zijn om de SoC-oprichting te ondersteunen.

De ontwikkeling van software duurde over het algemeen maanden nadat het eerste exemplaar arriveerde voordat het klaar was voor productie. Ondertussen zou de siliciumvalidatie worden voltooid, wat een beperkte hoeveelheid vertrouwen zou geven om massaproductie voor de bijbehorende producten te starten.

Door de toenemende complexiteit in het SoC-ontwerp zou wat normaal gesproken maanden aan softwareontwikkeling zou vergen zich nu echter kunnen uitstrekken tot jaren voordat de software klaar was voor productie. Het toenemende aantal ondersteunde randapparatuur en de evolutie van die randapparatuur zorgden ook voor hiaten in de materiedeskundigheid. Softwareteams zouden die specifieke leemten moeten opvullen door nieuwe ontwikkelaars te werven met expertise in die domeinen (audio, video, USB, Ethernet, enz.).

Om vroeg in het project productieklare software te kunnen leveren, kan de softwareontwikkeling niet wachten tot het eerste monster silicium beschikbaar is. Er moet een shift-linksbenadering worden gevolgd waarbij de softwareontwikkeling zo vroeg mogelijk begint en, nog beter, op hetzelfde moment dat het SoC-hardwareontwerp begint. Pre-silicium softwareontwikkeling kan ook helpen bij het identificeren van SoC-implementatiebugs en mogelijk de kosten van metal fix of full mask tape-outs verlagen. Er worden verschillende methoden overwogen om aan deze vereisten te voldoen.

Pre-silicium ontwikkelingsbenaderingen

Om softwareontwikkeling te starten vóór SoC-tapeout, kunnen ontwikkelaars een aantal benaderingen gebruiken, zoals softwareprototyping, RTL-testbench, FPGA-kaarten, hardware-emulators, enz. Aangezien deze benaderingen zich doorgaans richten op individuele modules, heeft elk van deze benaderingen zijn eigen uitdagingen, aangezien het doel is om software te ontwikkelen om de hele SOC op te halen in plaats van afzonderlijke modules. Als we het probleem opsplitsen in kleinere modules, is het eerste dat nodig is voordat de ontwikkeling van stuurprogramma's kan beginnen, kennis van elke processor, accelerator of randapparaat die in ontwikkeling is.

Systeem C-modellen

Voor elk IP-adres van de SoC kunnen C-gedragsmodellen worden gebouwd en op deze gedragsmodellen kunnen zelfstandige softwarestuurprogramma's worden getest. Maar deze benadering heeft een aantal problemen. Ten eerste is er een enorme software-inspanning vereist, wat betekent dat een groot softwareteam of een toegewijd modelteam nodig is om de implementatie van het model zelf te ondersteunen. Daarom zou de ontwikkeling van modellen niet kosteneffectief zijn. Ten tweede hangt de nauwkeurigheid van de gedragsmodellen af ​​van de interpretatie van de ontwikkelaar. Elke communicatiekloof tussen de eigenaar van het IP-ontwerp en de modelontwikkelaar kan leiden tot onnauwkeurig gedrag. Dit resulteert in veel verspilde moeite om problemen op te lossen die verband houden met de verkeerde interpretatie van het ontwerp.

RTL-testbank

Om dit onnauwkeurigheidsprobleem aan te pakken, kan een andere benadering worden gevolgd door een Verilog-testbench te gebruiken. De testbench wordt doorgaans ontwikkeld en onderhouden door het SoC-ontwerpteam voor verificatie. De Verilog testbench is gebaseerd op de register transfer language (RTL) specificatie van de SoC, die de volledige SoC vertegenwoordigt, niet slechts enkele IP-blokken. Daarom is het cyclus-tot-cyclus nauwkeurig. Naarmate de RTL zich ontwikkelt, beweegt de testbank mee. Dit zorgt ervoor dat het de meest actuele en nauwkeurige weergave is van de SoC zoals deze in ontwikkeling is. Voor softwareontwikkelingsdoeleinden kan de Verilog-testbench ook worden gebruikt om softwarestuurprogramma's te ontwikkelen.

Software die met deze methode is ontwikkeld, is nauwkeurig en kan de opstarttijd van de software verminderen wanneer SoC-samples na het fabricageproces arriveren. Maar er is een probleem met deze benadering. Omdat de Verilog testbench cyclus nauwkeurig is, is hij erg traag. Software ontwikkelen in een dergelijke omgeving is mogelijk, maar het zal extreem traag zijn om te ontwikkelen en te debuggen. Het kan maanden duren om met deze methodiek een driver te ontwikkelen. Verilog-testbench kan bruikbaar zijn door veel eerder te beginnen - waardoor in wezen de hoeveelheid tijd die nodig is in pre-silicium wordt vergroot om rekening te houden met de lage snelheid van de oplossing (maar hangt af van de beschikbaarheid van testbench). In een alternatieve benadering kan een ander softwareteam deze methodologie gebruiken (alleen werkend aan pre-siliciumontwikkeling) - waardoor het aantal benodigde bronnen in wezen toeneemt, waardoor dit probleem niet wordt opgelost dat vergelijkbaar is met het probleem met de C-gedragsmodelmethode.

In de praktijk kunnen we geen onnauwkeurige of lange ontwikkelingscycli accepteren, noch kunnen we de extra kosten accepteren die nodig zijn om het aantal resources te dupliceren of te vergroten om een ​​normale ontwerpcyclustijdlijn te behouden. Daarom moeten we een andere benadering van de ontwikkeling van pre-siliciumsoftware overwegen. Deze benadering omvat emulatie van elk SoC IP-blok op een veldprogrammeerbare poortarray (FPGA).

FPGA-prototypes

Moderne FPGA's zijn redelijk snel en aangezien de FPGA's zijn opgebouwd uit RTL, zijn ze cyclus-tot-cyclus nauwkeurig. Met toenemende ontwerpcomplexiteit hebben IP-blokken veel meer poorten dan jaren geleden. Jaren geleden werden FPGA's beperkt door het aantal ASIC-poorten, wat betekende dat het niet mogelijk was om grotere logische blokken in een enkele FPGA te passen. Het is nu mogelijk om voor elk blok een FPGA te bouwen en daarop een stuurprogramma te ontwikkelen dat snel en nauwkeurig is.

Deze methodologie is sneller en vereist niet dat softwareteams hun tijd vroeg besteden. Omdat het met elk afzonderlijk IP-blok werkt in plaats van met het volledige geïntegreerde SoC-ontwerp, beperkt deze benadering de software om volledige ontwikkeling op SoC-niveau uit te voeren. Het laat integratiedetails weg van hoe verschillende IP-blokken samen functioneren. Hoewel deze methode de inspanning voor het opvoeden zal verminderen, zijn er dus nog steeds hiaten omdat relevante SoC-integratiedetails ontbreken. Deze methode zou een acceptabele benadering kunnen zijn voor afgeleide SoC's, die een beperkt aantal wijzigingen hebben, maar niet de gewenste volledige dekking hebben die vereist is voor SoC-softwareontwikkeling.

klik voor grotere afbeelding

Figuur. Synopsis van pre-silicium softwareontwikkelingsoplossingen. (Bron:Nitin Garg)

SoC-emulators

Om het probleem van nauwkeurigheid, snelheid en dekking aan te pakken, zou een robuustere benadering kunnen worden gevolgd, waarbij gebruik wordt gemaakt van SoC-emulators. Er zijn veel in de handel verkrijgbare SoC-emulators die zeer grote en complexe SoC's kunnen emuleren. SoC-emulators zijn gebaseerd op RTL, dus ze zijn nauwkeurig, en ze zijn 100 keer sneller dan de Verilog-testbench, waardoor ze veel beter zijn voor softwareontwikkeling. Omdat ze redelijk snel zijn, kunnen volledige OS-overdracht en ontwikkeling van stuurprogramma's in een redelijke tijd worden uitgevoerd. SoC-emulators kunnen de hele SoC schalen, dus softwareontwikkeling is beter aangepast aan de uiteindelijke productie-SoC.

Het gebruik van SoC-emulators voor de ontwikkeling en het ontwerp van pre-siliciumsoftware vermindert de tijd en moeite die nodig is om de software op te zetten, omdat het de algehele ontwikkelingslacunes kan wegnemen of verkleinen. Software kan ook worden gedebugd met behulp van standaard JTAG-tools op een SoC-emulator. Emulators kunnen worden gebruikt voor meerdere taken, zoals ROM-ontwikkeling en -verificatie, firmware- en OS-ontwikkeling en verificatie op IP- of SoC-niveau. Een ander interessant kenmerk van SoC-emulators is dat ze de SoC kunnen koppelen aan echte componenten zoals die op een ontwikkelbord. Het is bijvoorbeeld mogelijk om een ​​echt of virtueel NAND-apparaat aan te sluiten op de SoC in een emulator en ROM, OS-stuurprogramma's en dergelijke te ontwikkelen.

SoC-emulators bieden veel meer mogelijkheden dan andere benaderingen voor softwareontwikkeling. Emulators kunnen de SoC gelijktijdig koppelen met UART, I2C, verschillende beeldschermen, opslagapparaten, PCIe-apparaten, connectiviteitsapparaten zoals Ethernet en Wi-Fi en opnameapparaten zoals camera's en sensoren. Met andere woorden, SoC-emulators kunnen een echt ontwikkelbord vertegenwoordigen, dus men kan een compleet raamwerk zoals Android naar voren brengen en een complete use-case uitvoeren voordat de SoC wordt opgenomen. Het opstarten van Android en het decoderen van een paar videoframes op de SOC-emulator kan bijvoorbeeld een paar uur duren, maar kan erg handig zijn bij het analyseren van de SOC-prestaties.

Vanwege de groeiende beschikbaarheid van randapparatuur op een SoC, is SoC-emulatie ook erg handig voor prestatiebenchmarking, wat de zwakke punten in het ontwerp vóór tape-out kan benadrukken. Deze functionaliteit kan risico's of daaropvolgende tape-outs verminderen die verband houden met niet-geïdentificeerde prestatietekortkomingen in de SoC. SoC-emulators maken het ook mogelijk om de SoC te koppelen aan een FPGA van derden of een soft-model indien nodig voor IP van derden.

Het debuggen van een probleem na de aankomst van het SoC-voorbeeld is ook handig met een emulator, aangezien het hetzelfde besturingssysteem, dezelfde stuurprogramma's en hetzelfde framework gebruikt als de echte hardware. Vaak is het nodig om problemen die in het silicium zijn waargenomen te repliceren naar de emulators, zodat het op signaalniveau kan worden onderzocht. Het gebruik van dezelfde software tussen emulator en silicium zorgt voor een snellere en nauwkeurigere reproductie van de problemen en geeft volledige toegang tot de details in de chip.

Door de verschillende SoC-softwareontwikkelingsbenaderingen te vergelijken, is het gebruik van SoC-emulators een betere keuze vanuit een pre-siliciumontwikkeling en post-silicium debug-perspectief. De kosten voor softwareteams om SoC-emulators te gebruiken, lijken misschien duur. Maar de bijdragen die SoC-emulators leveren door productiesoftware eerder beschikbaar te maken en risico's en kosten te helpen verminderen, kunnen van onschatbare waarde blijken te zijn als we kijken naar de impact op de time-to-market-doelstellingen. Andere benaderingen voor softwareontwikkeling hebben niet dezelfde dekking, wat riskant is en mogelijk een grotere inzet van softwareteams vereist. Alle factoren in aanmerking genomen, kan het gebruik van andere benaderingen voor softwareontwikkeling dan SoC-emulators in vergelijking veel duurder blijken te zijn.

Figuur 2. Vergelijkende uitvoeringssnelheid van elke oplossing. (Bron:Nitin Garg)

Volgens de wet van Moore verdubbelt het aantal transistors elke twee jaar in een geïntegreerde schakeling (IC) vanwege de toegenomen functionaliteit van de IC. De meeste op ARM gebaseerde 64-bits SoC's hebben tegenwoordig 100-300 miljoen logische poorten. Van de huidige SoC-softwareontwikkelingsbenaderingen hebben SoC-emulators bewezen de behoeften van softwareontwikkelingsteams op te schalen en te ondersteunen die worden geconfronteerd met de uitdagingen die gepaard gaan met de toenemende complexiteit van SoC's in de huidige competitieve markt.

Referenties

1. Trimberger, Stephen M. "Drie tijdperken van FPGA's." IEEE Xplore Full-Text PDF: 2015, ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7086413.
2. BRUNET, JEAN-MARIE. "Waarom moderne SoC-ontwerpen emulatie omarmen." Ingesloten computerontwerp , 5 sept. 2018, embedded-computing.com/embedded-computing-design/why-modern-soc-designs-embrace-emulation.
3. "Soc-emulatie." Soc-emulatie , 2019, www.aldec.com/en/solutions/hardware_emulation_solutions/co-emulation–soc-emulation.
4. "Meer componenten op geïntegreerde circuits proppen." http://www.cs.utexas.edu/ , 2006, cs.utexas.edu/~fussell/courses/cs352h/papers/moore.pdf.