I denna artikel diskuterar Ralph Zak från Synopsys hur man gör för att få ut maximal effekt av emuleringssystem i utvecklingsprojekt för en SoC.
Vad har ändrats i sättet att använda emulering?

Under många år användes emulatorer för att ta simulerad RTL-kod och mappa den som “tidigt kisel” i programmerbar hårdvara, för att sedan köra den tillsammans med mjukvara samtidigt som den var ansluten till en fysisk miljö.

Målet var att bli mer säker på att SoC:n faktiskt skulle fungera som önskat innan man gick över till kisel. Denna verifieringsmetod kallas in-circuit emulering, eller ICE. Eftersom emulatorn vid ICE arbetar mycket långsammare än den anslutna fysiska miljön, kräver varje systemgränssnitt oftast en mekanism som buffrar data för att hastighetsmässigt matcha emulatorn med omgivningen. I sådana miljöer, där den konstruktionsspecifika hårdvaran begränsar verifieringssmiljön, är i princip varje emulator upplåst för ett enda projekt.

För att få ut maximal effekt av dagens emulatorer krävs det andra tillvägagångssätt än man använt tidigare. Det kräver virtuella testmiljöer och optimering av verifieringsflödet genom en bättre blandning av verifieringsmetoder. Virtuella testmiljöer förenklar användarmodellen för dagens komplexa systemkretsar samt ökar tillgängligheten

Det har skett ett stort skifte från ICE till transaktionsbaserad accelererad verifiering i vilken den emulerade enheten som testas (DUT) interagerar med sin virtuella miljö vid väldigt höga hastigheter. Den huvudsakliga drivkraften för detta är det ständigt ökande antalet externa gränssnitt på en SoC. En SoC i en surfplatta, mobiltelefon, eller digital-TV kan idag ha över 20 externa anslutningar och köra alla möjliga periferifunktioner och kommunikationsprotokoll.

Transaktionsbaserad
En transaktionsbaserad verifieringsmetodik erbjuder många fördelar jämfört med en emuleringsmetodik baserad på ICE. Eftersom hela konstruktionen är innesluten i sin hårdvara och tillhörande dator krävs varken målkort, externa kablar, level-shifters eller hastighetskonverterare (speed bridges). Istället byggs den externa miljön upp som en grupp av transaktionsmodeller (transactors) där varje SoC-gränssnitt är representerat av en modell. T ex PCle, USB, tangentbord, LCD-displayer och kamerasensorer. Transaktorgränssnittet, som kommunicerar på hög abstraktionsnivå och med vilket användaren bygger upp sina testbänkar, är modellerat i C-kod (Fig 1).

Fig 1. Varje transaktionsingång som kommunicerar med de olika periferienheterna på en hög abstraktionsnivå är modellerad i C-kod.
Klicka här för större bild

Transaktionsmodeller i emulatorer (Verification IP, VIP) består generellt sett av tre element. I kärnan finns ett syntetiserbart protokollsspecifikt element, vanligtvis en BFM (bus functional model) eller fullständig IP-implementation som är placerad i emulationshårdvaran tillsammans med testobjektet. För att optimera systemets prestanda har avancerade system såsom ZeBu dedikerat resurser till dessa element (Fig 2). I normala tvåvägsdataflöden är kommunikationen mellan värden (host) och testobjektet i emulatorn transaktionsbaserad, vilket maximera systemets prestanda. Nedströms i flödet översätter protokollblocket signaler på transaktionsnivå till signaler på kretsanslutningsnivå som sedan kan tolkas av testobjektets protokollspecifika fysiska gränssnitt.

Fig 2. Den del som konverterar högnivåkommandon till bitnivåprotokoll är mappad som hårdvara i emulatorns RTB-arkitektur.
Klicka här för större bild

En välkonstruerad emulator kan rymma dussintals protokollspecifika transaktorer. Fördelen med transaktionsbaserad verfiering är att all samverkan mellan testobjektet och den externa testmiljön är konfigurerbar med mjukvara samt nerladdningsbar till emulatorn. Att flytta systemet från ett block till ett annat, eller att testa flera block parallellt, eller till och med att flytta från en SoC-konstruktion till en annan, kan göras genom konfiguration av mjukvara varifrån som helst i ett nätverk. Systemet, som är tillgängligt som en nätverksresurs, erbjuder betydligt mer flexibilitet och ett högre värde än om det hade använts till ICE-baserad verifiering.

Rätt metodik vid rätt tillfälle
En viktig faktor när det kommer till att få ut det bästa ur en emulator är att använda en blandning av olika verifieringsmetoder som alla är lämpliga i olika stadier av ett projekt. I ett tidigt skede av konstruktionen används högnivåmodeller i ESL-verktyg (Electronic system level tools) för att göra avvägningar och för att optimera olika delar av konstruktionen. Eftersom en stor del av dagens SoC består av block som återanvänds från tidigare konstruktioner eller är licenserade från tredje part, finns det ofta en stor mängd RTL-kod tillgänglig väldigt tidigt i projekten.

I sådana fall kan man utnyttja en hybrid mellan ESL och emuleringsmiljö för att möjliggöra att RTL-modeller används i emulatorn och att konstruktionens block används i ESL-verktygen.

Full insyn i RTL-koden i emulatorn kan visa sig att vara extremt användbart då det kommer till att identifiera olika implementationsproblem i RTL-block samtidigt som olika konstruktionsalternativ utforskas.

När RTL-koden är komplett testas generellt sett blocknivåkonstruktioner till en början genom simulering. När de olika blocken blir tillräckligt fria från buggar, t ex max en ny bugg hittad per dag, brukar användarna byta från tester på blocknivå till en emulator. Där görs mer omfattande tester vid hastigheter som inte går att nå med simulering. I detta skede brukar man introducera firmware i konstruktionen för att verifiera att interaktionen mellan hårdvaran och mjukvaran fungerar som den ska.

Efter att ha simulerat de första regressionstesterna på hela SoC:n går många team snabbt över till att göra emuleringstester där antalet realtidscykler då dramatiskt ökar. I detta skede används vanligtvis tidiga versioner av drivrutiner och annan lågnivåmjukvara. Detta gör att testandet kan börja röra sig mot realistiska systemtestscenarion.

När RTL-konstruktionen är tillräckligt stabil, är det dags att ge mjukvaruutvecklarna tillgång till emulatorn. Dessa har troligtvis tidigare använt sig av icke-cykliska ESL-modeller vid utvecklingen. Det kan också vara effektivt att erbjuda mjukvaruteamen helt FPGA-baserade prototyper, som t ex Synopsys HAPS-system, för att påskynda deras utvecklingsarbete.

Slutsats blir att den bästa effekten av emulatorer fås genom att:
* använda lämpliga virtuella testmiljöer för att förenkla användarmodellen och öka tillgängligheten
* använda den mest lämpliga verifieringsmetoden vid varje tillfälle för att optimera hela verifieringsflödet
Ralph Zak, Synopsys Inc

Filed under: FPGA