Zephyrnet-logotyp

Hantera förbehandlade filer i en hårdvaru-IDE – Semiwiki

Datum:

Sedan flera år tillbaka har jag träffat AMIQ EDA medgrundare Cristian Amitroaie varannan månad för att diskutera branschens tillstånd, nyckeltrender inom design och verifiering och hur de hjälper till att underlätta och påskynda chiputvecklingen. Jag märkte en intressant ny funktion som nämns i deras senaste pressmeddelande, så jag frågade Cristian om mer information. Detta ledde till en livlig och intressant diskussion.

De flesta designers och verifieringsingenjörer skriver sin kod i SystemVerilog nuförtiden, men det finns undantag. Vissa drar fördel av högnivåsyntesverktyg (HLS) för att designa i SystemC eller andra språk lite mer abstrakt än SystemVerilog. Andra skriver på sina egna språk och använder anpassade verktyg för att generera SystemVerilog-filerna som används för simulering, formell verifiering, syntes och andra steg i utvecklingsprocessen.

Cristian sa att de ibland ser en mellanväg där ingenjörer skriver kod som i första hand är SystemVerilog men som också innehåller "preprocessor"-satser på etablerade språk som Perl och Pythons Jinja2-bibliotek, eller på proprietära språk. De använder skript för att bearbeta dessa filer och generera de rena SystemVerilog-filerna för resten av flödet. Jag frågade Cristian hur användningen av förprocessorer förändrar hur ingenjörer använder en integrerad utvecklingsmiljö (IDE).

Jag lärde mig att användare av AMIQ EDA Design and Verification Tools (DVT) IDE-familjen vill ha tillgång till alla sina favoritfunktioner även när de redigerar filer med förprocessorkod. AMIQ EDA-teamet utvecklade smart heuristik för att möjliggöra fullständiga IDE-funktioner vid redigering av sådana filer, precis som de gör med ren SystemVerilog. Dessa funktioner inkluderar navigeringshyperlänkar, autokomplettering, upptäckt av fel i farten, snabbkorrigeringar, refaktorering och alla avancerade funktioner som DVT IDE-användare är beroende av.

Det här var spännande för mig. Vi pratar om att "förstå" filer med blandade språk, inte riktigt något någon kompilator lätt kan smälta. För att vara säker på att jag får det rätt och att detta är på riktigt bjöd Cristian in Zeljko Zurzic, teamledaren som koordinerade utvecklingen av denna förmåga, för att förklara hur det fungerar. Han sa att allt användare behöver göra är att informera DVT IDE om mappningen mellan filerna som innehåller preprocessor-satser ("p-fil") och de genererade filerna ("g-fil").

Detta görs med hjälp av dedikerade kompilatordirektiv som stöder olika användningsfall. Till exempel finns det ett sätt att berätta för DVT IDE-kompilatorn "ta reda på motsvarande p-fil från g-filens rubrikkommentar." När detta är gjort redigerar användarna bara sina p-filer som om det inte finns något speciellt med dem. On-the-fly inkrementell kompilering kommer att flagga alla SystemVerilog-fel när de skriver, hyperlänkar tar dem runt koden, autokomplettering och refaktorering fungerar bra, de kan begära olika diagram, etc.

De sektioner som innehåller förprocessorkod är märkta så att användarna vet att de kommer att omvandlas till SystemVerilog-kod. I DVT Eclipse IDE de kan se hur kod genereras genom att använda inspekteringsvyn; i DVT IDE för VS-kod de kan "kika" förvandlingarna. DVT IDE kan konfigureras för att automatiskt köra förbearbetningsskriptet när förprocessorkoden ändras. Användare kan enkelt jämföra ap-fil med motsvarande g-fil om så önskas.

Zeljko gav tre skärmdumpar som visar denna nya förmåga i aktion. Den första nedan visar en fil i DVT Eclipse IDE som innehåller en Jinja2-förprocessorsats. Trots närvaron av denna icke-SystemVerilog-kod kan användaren dra fördel av den kraftfulla "Visa författare"-funktionen för att snabbt förstå hur en variabel drivs. Kompileringsfel och varningar visas i den vänstra kolumnen på displayen.

Förprocessor 1

Skärmdumpen nedan visar samma fil i DVT IDE för VS Code, visar kompilatorproblemen i den vänstra kolumnen och möjliggör användning av autokomplettering. Detta visar hur även de mest avancerade DVT-funktionerna är tillgängliga i kod med preprocessor-satser.

Förprocessor 2

Zeljko betonade att IDE kontrollerar den genererade SystemVerilog-koden, vilket är viktigt eftersom det kan finnas ett fel i en preprocessor-sats eller en bugg i förbearbetningsskriptet. Skärmdumpen nedan visar just ett sådant exempel. Den genererade SystemVerilog-koden innehåller en variabel som inte definierades i källfilen. DVT IDE visar kompileringsfelet, p-filen och den genererade koden i g-filen.

Förprocessor 3

Att titta på g-filerna kan vara till hjälp vid felsökning, men slutsatsen är att användare arbetar direkt med p-filerna, analyserar och redigerar dem med en kraftfull IDE. G-filerna är taggade som "skrivskyddade" och användare kommer att varnas om de ändras. Jag blev glad att höra detta; vi vet alla att det är en riktigt dålig idé att göra manuella ändringar i alla filer som kommer att skrivas över av en kodgenereringsprocess.

Slutligen betonade Cristian att hela poängen med denna nya funktion är att användare kan redigera kod med preprocessor-satser precis som om det vore ren SystemVerilog. Att göra detta möjligt har varit en betydande ansträngning driven av ett fåtal nyckelkunder som förlitar sig på förprocessorbaserade flöden. Jag tackade Zeljko och Cristian för deras förklaringar och deras tid.

Om du vill lära dig mer om att använda förprocessorfiler eller någon aspekt av AMIQ EDA-lösningarna kan du besöka dem i monter 107 på Design and Verification Conference and Exhibition (DVCon) USA i San Jose, Kalifornien den 5 mars och 6 mars.

Läs också:

2024 Outlook med Cristian Amitroaie, grundare och VD för AMIQ EDA

Använda Linting för att skriva felfri testbänkskod

AMIQ: Firar 20 år inom konsultverksamhet och EDA

Dela det här inlägget via:

plats_img

Senaste intelligens

plats_img