Juergen Jaeger är Director of Marketing Design Creation and Synthesis Division på Mentor Graphics. Han har över tjugo års konstruktionserfarenhet av hårdvara, programvara och verifiering av asicar och FPGA:er. Han har en BSEE-examen från Fachhochschule Kaiserlautern, Tyskland, och en mastersexamen i datorvetenskap från University of Hagen, Tyskland.

När FPGAer var enklare kretsar var felsökning enbart i system tillräckligt bra. Att göra en re-spin på grund av att specifikationen inte följts var en snabb och enkel process. Livet var enkelt eftersom en re-spin var nästan "gratis". Så är inte längre fallet. Ett företag fick nyligen spendera tre hela månader med att implementera en sent påkommen ändring eftersom konstruktörsteamet fick svårt att möta kraven efter den enda ändringen. Detta är inte något unikt fall. Kostsamma re-spins blir allt vanligare. Uppenbarligen kostade denna re-spin mycket i detta speciella fall. Vid detta tillfälle berodde det på att det var en plattforms-FPGA som konstruerades.

Plattforms-FPGAer är fascinerande processdukter som medför ett stort värde för användaren genom den ökade kapaciteten och de många olika dedicerade resurserna på kretsen såsom minne, kommunikation och DSP. Plattforms-FPGAer möjliggör många nya sätt att använda programmerbar logik på som annars inte varit möjliga. Med dessa möjligheter kommer också nya utmaningar. När man konstruerar för plattforms-FPGAer måste felen upptäckas tidigare i konstruktionscykeln, där kostnaden för att rätta felen är mycket lägre (se bild). Ett sätt att uppnå detta är att använda konvergerande regler för syntes och verifiering och att införa plattformsspecifika konstruktionsflöden.

I ett traditionellt konstruktionsflöde för programmerbar logik där de flesta felen upptäcks i labbet fungerar ett seriellt flöde - från syntes, via place-and-route, till felsökning i systemet. Verifiering är något som det tänks på i efterhand. I det här fallet är syntes med grundläggande mappning av logik via ett pushbutton-flöde och en godtycklig mängd av kretsleverantörens specifika IP godtagbart. Om verifiering överhuvudtaget görs, består det oftast av en enkel testbänk i VHDL eller Verilog eller enbart av test i systemet i labmiljö.

En sådan här enkel ansats blir ineffektiv för plattforms-FPGAer. På grund av den större mängden tillgängligt kisel, den högre komplexiteten och längre tider för iterationer, blir kostnaden för att upptäcka och åtgärda fel i ett sent skede oacceptabla. Ett konstruktionsflöde för plattforms-FPGAer liknar mer de som började användas vid konstruktion av SoC (System on Chip) på slutet av 90-talet, där konstruktion och syntes är tätt kopplat till verifiering vid varje steg i flödet. Eftersom dessa inte längre skall vara separata steg i konstruktionen av en plattforms-FPGA måste metodiken för syntes och verifiering konvergera. Genom att de nedan beskrivna strategierna används kan risken att upptäcka fel i ett sent och kostsamt skede minimeras.

Kontrollera HDL-koden tidigt och ofta

Verktyg för "Design management" hjälper till att kontrollera koden gentemot etablerade regler för kodningsstil som tagits fram antingen av konstruktionsgruppen eller av tillverkarna av de programmerbara kretsarna. Genom att använda dessa verktyg som kontrollerar kodningsstil och syntax flyttas upptäckten av fel fram till ett tidigt stadium i konstruktionscykeln och dyrbar simuleringstid behöver inte längre slösas bort.

Implementera en mer effektiv strategi för funktionell verifiering

Syntesverktyg för plattforms-FPGAer gör mer än att bara generera en nätlista mappad till en viss teknologi. De främsta syntesverktygen har viktiga funktioner som möjliggör insikt i konstruktionen vid varje steg i cykeln. Dessa analysfunktioner kan identifiera potentiella problemområden som till exempel signaler som går mellan olika klockdomäner. Det ställs stora krav på verifiering för att hitta den typen av fel.

Om dessutom traditionell funktionell verifiering används för plattforms-FPGAer blir det ytterst svårt att med rena VHDL- eller Verilogtestbänkar modellera slumpmässig stimuli för att kontrollera att kretsens funktion svarar mot konstruktionens specifikation . Effektiv funktionell verifiering kräver ansatser liknande de som erbjuds av SystemVerilog, som är en förbättring av de funktioner som finns i Verilog.

I tillägg till detta introducerar SystemVerilog "assertions" för att kunna förse konstruktionen med grundläggande regler som beskriver dess förväntade beteende. Om dessa assertions används tillsammans med modellering av stimuli kommer det att dramatiskt öka möjligheten att hitta felen tidigt med funktionell verifiering.

Med ökat antal rader kod för att beskriva en krets ökar också sannolikheten för att oavsiktliga fel introduceras. Användandet av SystemVerilog reducerar antalet rader kod som behövs för att beskriva en given krets, vilket i sin tur medför en potentiell reducering av antalet fel i koden.

Inför ett konsistent, leverantörsoberoende syntes- och verifieringsflöde

Ett konsistent leverantörsoberoende syntes- och verifieringsflöde möjliggör att i en och samma miljö undersöka de möjligheter som arkitekturerna i de olika plattforms-FPGAerna erbjuder. Det reducerar behovet av inlärning av kretsspecifika kodningstekniker och attribut bara för att kunna evaluera en specifik arkitektur. Det eliminerar också den extra tid det tar att lära sig flera konstruktionsmiljöer.

För att hjälpa till att möta specifikationerna har dagens syntesverktyg höjt ribban signifikant jämfört med sina föregångare vad gäller deras möjlighet att på en hög nivå extrahera operatorer. Dessa kan sedan användas för att intelligent utnyttja dedicerade resurser såsom DSP-hårdvara och RAM i kretsar från olika leverantörer. Genom att låta syntesen ta dessa beslut reduceras mängden leverantörsspecifika delar i konstruktionen och migrering och underhåll förenklas.

Lägg mer tid på tidig tids- och prestandaanalys

Är du beredd att vänta tills din konstruktion är funktionellt verifierad, syntetiserad och har gått igenom place-and-route innan du kan se om det valda arbitreringsschemat klarar av den inkommande trafiken? Att tidigt kunna upptäcka problem med genomströmningshastighet kräver en mer djupgående analys av prestanda och timing under syntesprocessen. På liknande vis måste du säkerställa att tidskraven är korrekta innan du slösar bort tid på att möta dessa tidskrav under place-and-route.

Ett oumbärligt vapen i varje verktygssvit för konstruktörer av plattforms-FPGAer är en kraftfull interaktiv syntes- och analysmiljö som går hela vägen från RTL till fysisk implementation. Interaktiva syntestekniker tillåter konstruktören att göra "what-if"-analyser tidigare i konstruktionsflödet. Ett robust syntesmiljö ger också flera olika representationer av konstruktionen: högnivåoperatorer, arkitekturspecifika teknologiceller, etcetera. Genom att ta till vara fördelarna med interaktiv syntes fås en tidigare förståelse av konstruktionen och om den kommer att möta specifikationen eller inte.

Plattformsspecifika flöden reducerar re-spins

Hittills har fokus varit på att hitta fel så tidigt som möjligt i konstruktionscykeln. Emellertid medför den snabbt föränderliga elektronikbranschen att kraven oundvikligen ändras sent i konstruktionscykeln. För att lindra verkan av dessa sena ändringar i specifikationen vid konstruktion av plattforms-FPGAer, bör konstruktören använda avancerade inkrementella konstruktions- och ändringsflöden. Dessa flöden försöker att i så stor mån som möjligt begränsa vidden och effekten av en ändring i specifikationen och därmed öka sannolikheten för att en ändring sent i konstruktionscykeln lyckas.

Att ha ett solitt, konsistent och leverantörsoberoende konstruktions- och verifieringsflöde är kritiskt för alla FPGA-konstruktioner. På samma sätt som en konstruktör väljer den optimala kretsen för en given applikation, måste också rätt verktyg väljas för en given plattformskonstruktion. Nedan följer exempel på detta:

DSP-plattformar kräver verktyg som möjliggör algoritmisk konstruktion på avsevärt högre nivå än RTL. Dessa verktyg använder C/C++ som beskrivning av konstruktionen och levererar en bitkorrekt RTL baserad på restriktioner från användaren. Eftersom dessa verktyg sammanför system och hårdvarudomänerna ser konstruktörerna från båda dessa domäner fördelar. Att konstruera på en hög abstraktionsnivå tillåter "what-if"-analys av arkitekturen hos flera plattforms-FPGAer från olika leverantörer, samtidigt som den optimala implementationen för en arkitektur kan hittas utan att någon RTL-kod skrivs. Dessutom kan också prestandaanalyser göras på varje implementation för att tidigt upptäcka problem med genomströmningshastighet. Ett effektivt flöde speciellt för DSP-plattformar gör att en felfri RTL-kod skapas snabbare.

Plattformar med hög prestanda och hög densitet kräver verktyg som möjliggör avancerad fysisk syntes. I FPGAer domineras fördröjningarna av förbindelser som är arkitekturspecifika. Förutbestämda arkitekturer gör det omöjligt att förlita sig på "floorplanning" för att reducera ledarlängder. Den ideala lösningen är att manipulera konstruktionen med syntes som har kunskap om den fysiska strukturen integrerad med logisk syntes för att lösa tidsproblem. Efter att specifika moduler har optimerats med fysik syntes kan produktiviteten ökas genom att dessa optimerade block kan återanvändas i kommande konstruktioner.

Connectivity plattformar kräver samtidig konstruktion av I/O för både kretskort och FPGA, och signalintegritetsverktyg för höghastighetsanalys och felsökning. Att koppla ihop konstruktionsprocesserna för kretskort och FPGA gör att problem med tilldelning av pinnar kan elimineras tidigare. Verktyg för signalintegritet hjälper till att tidigare finna problem med transmissionsledningar för snabba klock- och datasignaler på kretskortet innan konstruktionen godkänns. Användandet av ett anpassat flöde för "connectivity platforms" hjälper till att reducera risken för extra kostnad för ändringar för både FPGA och kretskort. Höghastighetskommunikation medför ytterligare ett problem: kan man med den valda plattforms-FPGAn och den aktuella mikroarkitekturen för den parallella kommunikationen klara genomströmningshastigheten hos den seriella delen? Liksom för de tidigare diskuterade problemen med genomströmningshastighet kan även här prestandaanalys användas för att hitta problemen tidigare.

Plattformar med inbäddade CPUer kräver en metodik som tillåter inkrementell konstruktion och felsökning under tiden som FPGA, kretskort och mjukvara fortfarande är under utveckling. Att använda en inkrementell metodik kan möjliggöra återanvändning av innehåll på ett referenskort till det första kretskortet. Samtidigt kan mjukvaran utvecklas parallellt med FPGAn. Att i ett tidigt skede ha möjlighet att hitta möjliga problem i interaktionen mellan hårdvara och mjukvara kan reducera kostnaderna för ändringar i FPGAn betydligt. Särskilt om det uppenbarade problemet beror på en brist i hur systemets funktionalitet var partitionerad mellan hård och mjukvara.

Översatt och bearbetat av Lars Gustafsson, Team Leader ASIC/FPGA, Mentor Graphics (Scandinavia)