Hårdvaruemulering

Ikos NSIM-64 hårdvarusimuleringsaccelerator.

I integrerad kretsdesign är hårdvaruemulering processen att imitera beteendet hos en eller flera hårdvarudelar (typiskt ett system under design) med en annan hårdvara, vanligtvis ett emuleringssystem för specialändamål . Emuleringsmodellen är vanligtvis baserad på ett hårdvarubeskrivningsspråk (t.ex. Verilog ) källkod, som kompileras till det format som används av emuleringssystemet. Målet är normalt felsökning och funktionsverifiering av systemet som designas. Ofta är en emulator tillräckligt snabb för att kopplas in i ett fungerande målsystem istället för ett ännu inte byggt chip, så hela systemet kan felsökas med livedata. Detta är ett specifikt fall av in-circuit emulering .

Ibland kan hårdvaruemulering förväxlas med hårdvaruenheter som expansionskort med hårdvaruprocessorer som hjälper till med mjukvaruemulering, såsom äldre dotterkort med x86-chips för att tillåta x86-operativsystem att köras på moderkort i olika processorfamiljer.

Introduktion

Den största delen av återspinn och steg i kiselkretsar beror åtminstone delvis på funktionsfel och buggar som oavsiktligt introducerats i RTL -stadiet av designprocessen. Därför är omfattande funktionsverifiering nyckeln till att minska utvecklingskostnaderna och leverera en produkt i tid. Funktionell verifiering av en design utförs oftast med hjälp av logisk simulering och/eller prototypframställning på fältprogrammerbara grindmatriser ( FPGA). Det finns fördelar och nackdelar med var och en och ofta används båda. Logisk simulering är enkel, exakt, flexibel och låg kostnad. Emellertid är simulering ofta inte tillräckligt snabb för stora konstruktioner och nästan alltid för långsam för att köra applikationsprogramvara mot hårdvarudesignen. FPGA -baserade prototyper är snabba och billiga, men tiden som krävs för att implementera en stor design i flera FPGA:er kan vara mycket lång och är felbenägen. Ändringar för att åtgärda konstruktionsfel tar också lång tid att implementera och kan kräva förändringar av kortets ledningar. Med traditionella leverantörsverktyg har FPGA-prototyper liten felsökningskapacitet, att sondera signaler inuti FPGA:erna i realtid är mycket svårt, och att kompilera om FPGA:er för att flytta sonder tar för lång tid. Detta förändras med framväxten av mer avancerade FPGA-prototypfelsökningsverktyg som tar bort begränsningar för signalsynlighet. Den vanliga kompromissen är att använda simulering tidigt i verifieringsprocessen när buggar och korrigeringar är frekventa, och prototyper i slutet av utvecklingscykeln när designen i princip är klar och hastighet krävs för att få tillräcklig testning för att upptäcka eventuella kvarvarande buggar på systemnivå . FPGA-prototyper är också populärt för att testa programvara.

Simuleringsacceleration kan till en viss grad åtgärda prestandabristerna med simulering. Här mappas designen till en hårdvaruaccelerator för att köras mycket snabbare och testbänken (och eventuell beteendedesignkod) fortsätter att köras på simulatorn på arbetsstationen. En kanal med hög bandbredd och låg latens ansluter arbetsstationen till acceleratorn för att utbyta signaldata mellan testbänk och design. Enligt Amdahls lag kommer den långsammaste enheten i kedjan att avgöra vilken hastighet som kan uppnås. Normalt är detta testbänken i simulatorn. Med en mycket effektiv testbänk (skriven i C eller transaktionsbaserad) kan kanalen bli flaskhalsen. I vissa fall kan en testbänk på transaktionsnivå mata lika mycket data till designen som emuleras som "live" stimulans.

In-circuit-emulering förbättrar något av FPGA-prototypers implementeringstider och ger en omfattande, effektiv felsökningskapacitet. Emulering gör detta på bekostnad av körhastighet och höga kostnader ($1M+) jämfört med FPGA-prototyper ($75K). ^{[ enligt vem? ]} Om man tittar på emulering från andra hållet, förbättrar den accelerationens prestanda genom att ersätta "live" stimulans för den simulerade testbänken. Denna stimulans kan komma från ett målsystem (produkten som utvecklas) eller från testutrustning. Med 10 000 till 100 000 gånger simuleringshastigheten gör emulering det möjligt att testa applikationsprogramvara samtidigt som den tillhandahåller en omfattande hårdvarufelsökningsmiljö.

Felsökningssimuleringar kontra emuleringar/prototyper

Det är värt att notera att simulering och prototyping involverar två olika utförandestilar. Simulering exekverar RTL-koden seriellt medan en prototyp exekveras helt parallellt. Detta leder till skillnader i felsökning. I simulering:

Användaren kan ställa in en brytpunkt och stoppa simuleringen för att inspektera designtillståndet, interagera med designen och återuppta simuleringen.
Användaren kan stoppa exekveringen "mid-cycle" så att säga med endast en del av koden exekverad.
Användaren kan se vilken signal som helst i designen och innehållet i valfri minnesplats när som helst.
Användaren kan till och med säkerhetskopiera tid (om de sparat kontrollpunkt(er)) och köra igen.

Med en prototyp:

Användaren använder en logisk analysator för synlighet och kan därför bara se ett begränsat antal signaler som de bestämt i förväg (genom att klippa på sonder). Detta förändras med nya FPGA-prototypverktyg som ger full synlighet till 10 000-tals interna signaler, som Certus.
Målet stannar inte när den logiska analysatorn triggar, så varje gång användaren ändrar sonderna eller triggervillkoret måste de återställa miljön och börja om från början.
Prober läggs till direkt i RTL-designen för att göra specifika signaler tillgängliga för observation. När systemet körs samlar den RTL-baserade sonden som är ansluten till var och en av de instrumenterade signalerna signalens värde vid varje klockcykel. Data lagras i en spårningsbuffert i FPGA-block-RAM. En analysator kopplad till prototypen laddar ner informationen som ger användaren insyn i systemet offline för effektiv felsökning.

Acceleration och emulering är mer som prototyper och kisel när det gäller RTL-exekvering och felsökning eftersom hela designen körs samtidigt som den kommer i kisel. Eftersom samma hårdvara ofta används för att tillhandahålla både simuleringsacceleration och in-circuit emulering, tillhandahåller dessa system en blandning av dessa två mycket olika felsökningsstilar.

Högkvalitativa hårdvaruemulatorer tillhandahåller en felsökningsmiljö med många funktioner som kan hittas i logiska simulatorer, och i vissa fall till och med överträffa deras felsökningskapacitet:

Användaren kan ställa in en brytpunkt och stoppa emulering för att inspektera designtillståndet, interagera med designen och återuppta emuleringen. Emulatorn stannar alltid vid cykelgränser.
Användaren har synlighet till alla signaler eller minnesinnehåll i designen utan att behöva ställa in sonder innan körningen. Även om synlighet tillhandahålls för tidigare tider, kan den tid som den kan visa i det förflutna i vissa fall begränsas till djupet av emulatorns spårminne.
Användaren kan till och med säkerhetskopiera tid (om de sparat kontrollpunkt(er)) och köra igen.
På grund av deras höga kostnad är emulatorer utom räckhåll för många utvecklare, vilket leder till uppkomsten av avancerade FPGA-prototypplattformar och felsökningsverktyg.

Emulering och 2-tillståndslogik

En annan skillnad mellan simulering och acceleration och emulering är en konsekvens av att acceleratorer använder hårdvara för implementering – de har bara två logiska tillstånd – fungerar som kislet kommer när det tillverkas. Detta innebär:

De är inte användbara för att analysera X-state-initiering.
De kan inte analysera hållfasthetsupplösning, eller åtminstone måste detta göras statiskt vid kompilering.
Emulatorer modellerar inte exakt kretstidning, och därför kommer de förmodligen inte att hitta några tävlingsförhållanden eller inställningar och tidsöverträdelser.

Dessa uppgifter utförs korrekt under logisk simulering eller med ett statiskt tidsanalysverktyg .

Emulering kontra prototyping

En viktig traditionell skillnad mellan en emulator och ett FPGA-prototypsystem har varit att emulatorn ger en rik felsökningsmiljö, medan ett prototypsystem har liten eller ingen felsökningskapacitet och används främst efter att designen har felsökts för att skapa flera kopior för systemanalys och mjukvaruutveckling. Nya verktyg som möjliggör full synlighet av RTL-signaler med en liten FPGA LUT-påverkan, tillåter djupt fångstdjup och tillhandahåller multichip- och klockdomänanalys dyker upp för att möjliggöra effektiv felsökning, jämförbar med emulatorn.

Se även

Hårdvaruassisterad virtualisering
Emulator
In-circuit emulator
Gränssnitt för bakgrundsfelsökningsläge
Exempel:
- Mikroprocessoremulator HP 64000 (olika processorer)

Electronic Design Automation For Integrated Circuits Handbook , av Lavagno, Martin och Scheffer, ISBN 0-8493-3096-3 En undersökning av fältet, från vilket sammanfattningen ovan härrörde, med tillstånd.

Vidare läsning