I FPGA-design betyr timing alt

Verktøy og teknikker finnes som kan hjelpe deg til med å oppnå timing-målene. Dette er den komplette artikkelen som ble innledet i Elektronikk nr 4/2015, side 20.

Publisert Sist oppdatert

Denne artikkelen er 2 år eller eldre

Av Angela Sutton, Staff Product Marketing Manager, FPGA Synopsys
Paul Owens, Corporate Applications Engineer, FPGA Synopsys

Når FPGA-designet ditt ikke møter timing-målene, er ikke årsaken helt åpenbar. Løsningen ligger ikke bare i implementeringsverktøyets evne til å optimalisere designet slik at det møter timingmålsettingen, men også designerens evnet til å spesifisere målene på forhånd og diagnostisere og isolere timingproblemer nedstrøms. Designere har nå tilgang til visse tips og triks som kan hjelpe deg til å sette opp klokker; sette timingbegrensninger korrekt gjennom å bruke verktøy som Synopsys Synplify Premier, og så finstille parametrene slik at de møter ytelsesmålsettingene i ditt Xilinx FPGA-design.

Det finnes flere måter å angripe problemstillingen på, blant annet:

  • Bedre designoppsett, som komplette og nøyaktige timingbegrensninger og klokkespesifikasjoner.
  • Tidsbesparende designteknikker som nøyaktig RTL-koding for bedre ytelsesresultater og gruppering av deler av designet som representerer den største ytelsesutfordringen, for å redusere iterasjonertid når designet senere skal finjusteres.
  • Korrelasjon av syntese og “place and route”-timing for å levere bedre timingkvalitet i resultatene  (timing quality of results – QoR) og timing-avslutning.

 La oss ta en nærmere kikk på noen av disse teknikkene i alle tre kategorier, og undersøke hvordan de kan brukes for å oppnå timingmålsettingene.

Trinn 1: Bedre designoppsett
Mest igjen for pengene får du ved å spesifisere korrekte og komplette designbegrensninger. Begrensningene viser hensikten med designet og ytelsesmålene til synteseverktøyet. Når designet er blitt syntetisert vil disse begrensningene og informasjon om kritiske baner bli videresendt automatisk til verktøyet Vivado Design Suite place and route (P&R) for ytterligere å sikre at timingkravene blir møtt.

Synteseverktøyet kan assistere deg i forbindelse med den utfordrende oppgaven å sette opp begrensninger før syntesen:

  1. Identifisér klokker
  2. Identifisér og etablér klokkegrupperinger og -relasjoner
  3. Begrens klokken
  4. Begrens innganger og utganger i designet
  5. Definér flersyklusbaner og falske baner

Du vil trenge å sjekke at du har begrenset designet tilstrekkelig og komplett uten å ha overbegrenset det. Overbegrensning vil resultere i lengre kjøretider, og potensielt rapportere falske kritiske baner. Vær sikker på å spesifisere flersyklus- og falske baner og sett begrensninger på avledede klokker

(define_path_delay, define_false_path).

 Oppsett av en initiell begrensningsfil for Vivado-flyt
Siden et begrensningsoppsett kan være skremmende, kan synteseprogrammet hjelpe til med en initiell begrensningsmal med basisbegrensninger og syntaks som et utgangspunkt. For eksempel, kjør TCL-verktøyet i Synplify synteseprogram for å lage en initiell FDC-fil for et spesifikt desgin:

TCL:  create_fdc_template

Figur 1 viser et eksempel på begrensningsfilen (.fdc) som denne prosessen genererer. I dette eksemplet kan du se at nøkkelelementer, som deklarasjon av klokke, klokkegruppe (klokkerelasjoner) og forsinkelser ved inn- og utgang, er blitt ivaretatt.

Best praksis for begrensningsoppsett i Vivado Design-flyt
Når begrensninger skal settes opp i Vivado Design Suite, sørg for at følgende blir gjort:

  • Definér alle primærklokker på inngangsporter eller nett koblet til inngangsporter.
  • Definér klokker på utgangspinnene til den sorte boksen.
  • Definér genererte klokker i nettet.
  • Ikke definér portklokker.
  • Gjør riktige klokkebegrensninger: Ikke begrens for mye, og sørg for at ikke-relaterte (asynkrone) klokker plasseres i separate klokkegrupper.
  • Definér tidsunntak, som falske baner eller flersyklusbaner.

 Hint: I Vivado Design Suite bør klokkebegrensninger legges så nær klokkekilden som mulig, ikke på BUFG som var tilfelle i Xilinx ISE Design Suite.

Sikre at begrensningene er korrekte
Vi anbefaler fire verifikasjonsteknikker for begrensninger under oppsettfasen. For å gi deg en idé over hvilke typer begrensningssjekk som er verdt å gjøre, la oss se på kontroller som Synplify-programmet utfører.

 

Kjør først en “syntakssjekk”— det vil si en rask sjekk av begrensningene, inkludert de innebygde kommandoene “get_XX” og “all_XX”, for å avsløre og rydde opp i eventuelle syntaksfeil i begrensningen. Disse feilene vil dukke opp i en loggfil som kan hyperlinkes tilbake til feilen manuelt og forklarer feilen, og foreslår en reparasjon. Bruk TCL-kommandoen check_fdc_query. Kjør så en “syntesesjekk” for å finne maskinvarerelaterte feil som feilaktig kodede flip-flops. Disse feilene rapporteres i en separat fil.

Deretter, kjør basis “rask syntese” som sjekker problemer med klokkeoppsettet, inkludert erklært, avledet og infererte klokker. Rask syntese gjør at du kan gjøre en sjekk av klokkeoppsettet, fordi den genererer både en klokkerapport og en timing-rapport som gjør eventuelle problemer med klokkeoppsettet synlig. Visse synteseverktøy tillater at du kan kjøre syntese i “rask” modus, og som slår av enkelte synteseoptimaliseringer av hensyn til den raske kjøretiden. I Synplify Premier gjøres dette med kommandoen:

 set_option –fast_synthesis 1

Syntesekompilatoren vil lage en oppsumert klokkesynteserapport med informasjon om infererte klokker som du kan bruke til å identifisere, definere og begrense klokker.

For det fjerde, kjør en full begrensningssjekk (constraints check). Denne kontrollen ser etter problemer med begrensningsoppsettet med klokkerelasjoner, ikke-begrensede start/sluttpunkter, ikke-låste I/O og I/O uten begrensninger.

En full begrensningssjekk vil også se etter riktig applikasjon med begrensninger og navnforekomster. For eksempel vil den flagge timing-begrensninger som er lagt på ikke-eksisterende eller feil type argumenter og objekter. Verktøyet genererer så en detaljert rapport over begrensninger som ikke kan brukes og hendelser ikke funnet, slik at begrensningsfilen kan korrigeres. Synplify synteseverktøy vil kjøre disse kontrollene automatisk i syntese “premap”-fasen, eller du kan kjøre begrensningskontroll i begynnelsen av syntesen med følgende TCL-kommando:

TCL: project -run constraint_check

Å kjøre disse basiskontrollene identifiserer mulige feil tidlig i syntesefasen og forbedrer resultatkvaliteten (Figur 2).

 

 

Så snart syntesen er kjørt, sørg for å analysere timing ettersynteserapporten, siden den kan gi viktig informasjon. For eksempel, når man bruker Synplify programvare, kan en “systemklokke” under startklokkeseksjonen i timing-rapporten indikerer at noen av I/O’ene dine ikke er begrenset. Grensesnittinformasjonen i denne rapporten vil vise om dette er tilfelle eller ikke.

Trinn 2: RTL-kodestiler og justering av kritiske baner
For å konvergere bedre timing, anbefaler vi at du bruker visse kodestiler for tilstandsmaskiner, RAM, math/DSP-funksjoner, klokketrær og skiftregistre. Resultatet vil bli en forbedret timing QoR (quality of result - resultatkvalitet), fordi synteseverktøyet er bedre i stand til å identifisere en implementasjon som bruker FPGA primitive byggeblokker.

 

I tillegg vil disse kodestilene gjøre at du unngår å lage unødvendig logikk, som låsforekomster, les/skriv kontrollogikk for RAM og logikk som kunne ha vært pakket inn i en DSP primitiv. Selv om det er skrevet mye om dette, er kjernegeneratoren i synteseverktøyet et viktig element å ta hensyn til. For eksempel inkluderer Synplify en SynCore IP-veiviser som autogenererer nødvendig RTL kodestil for byte-aktivert RAM. Andre IP-generatorer, som Xilinx IP Catalog, Synopsys’ Synphony Model Compiler eller Synopsys’ DesignWare coreTools og DesignWare Building Blocks, kan også kjelpe deg med å konfigurere IP, utføre flere DSP- og matematiske funksjoner, og skape gode RTL kodestiler. Dersom du koder manuelt, husk på følgende:

Figur 1 – En initiell Synplify syntese begrensningsfil ved inngangen tar vare på basis klokkeoppsett og krav til I/O-begrensninger. Begrensningen vil bli framannotert til Vivado place and route-verktøyet.

For tilstandsmaskiner (finite state machines)

  • For Xilinx-flyt, bruk en synkron “reset” for å sette maskinvaren i en gyldig tilstand etter oppstart, eller reset maskinvare under drift.
  • Separér sekvensielle blokker fra “alltid kombinerte blokker”.
  • Tildel en variabel for neste tilstand for alle mulige (tilstedeværende) tilstander.

For blokk-RAM

  • Kod synkron RAM der det er mulig, siden disse generelt vil kjøre med høyere klokkefrekvenser.
  • Plassér RAM-kode i en separat modul for enklere avlusing på nettlistenivå.
  • Før beslutning om å bruke RAM med en spesfikk reset-tilstand, dobbelt port eller aktivert RAM, eller asymetrisk RAM, se anbefalt kodestil og sjekk om interferens er støttet. Hvis ikke, kan nettlisten ende opp med å skape mer kontrollogikk.
  • Ikke les fra samme adresse du skriver til i samme klokkesyklus.
  • Når alt annet slår feil, bruk en attributt (syn_ramstyle for Synplify) for å tvinge inn implementasjon av små RAM til registre, slik at RAM-ressurser frigjøres til bruk i mer tidskritiske- eller større RAM.

For DSP-blokker
Du kan bruke disse primitivene til å implementere filtre og matematiske funksjoner som tellere, adderere, multiplikatorer, subtraktorer og lignende.

  • Plassér DSP-kode i en separat modul for enklere avlusing på nettlistenivå.
  • Når alt annet slår feil, bruk en attributt (syn_ dspstyle for Synplify i Vivado Design Suite) for å tvinge implementasjonen.

For SRL
Du kan pakke skiftregistre til en select_SRL Xilinx SRL primitiv eller implementere dem i registre.

  • Pakking skjer automatisk. For skiftregisterkjeder vil Synplify alltid etterlate siste register i kjeden utenfor den pakkede select_srl for å optimalisere timing QoR.
  • Når alt annet slår feil, bruk syn_srl- style attributten til å kontrollere hvordan SRL er implementert.

For klokketrær

Figur 2 – Å kjøre syntaks, syntese og så begrensningskontroll er en metode for å finne tidlige begrensning- og klokkeoppsettfeil, slik at du kan oppnå resultatkvaliteten i timingen raskt.
  • Siden disse ikke automatisk blir vist under syntesen, er det anbefalt at du oppretter faselåste sløyfer (PLL), klokkegeneratorer eller klokkemultipleksere i din RTL.
  • Tidsbegrensningene i inngangsklokken til PLL’en vil automatisk generere avledet tidsbegrensning på PLL’ens utgangspinner.

For å få en bedre oversikt over klokkebegrensninger, undersøk dem i en skjemaleser. For eksempel kan Synplifys HDL Analyst-verktøy kjøre et filter på klokketreet som lar deg observere og avluse klokketrær og klokkebegrensninger (Figur 3).

Bruke modularitet til å forbedre ytelsen i kritiske baner
Visse deler av designet kan være mer tidskritiske enn andre, og du kan trenge å justere og trinnvis forbedre deler som ikke har bra nok ytelse. En av teknikkene du kan bruke for raskere justering under RTL- og nettlistfasen involverer å isolere kritiske baner inne i en enkelt blokk eller delprosjekt, som du så kan repetere trinnvis for å forbedre den. I tillegg kan du tvinge Vivado place and route-verktøyet til å plassere elementene nær hverandre for å sikre enda bedre timing QoR. Muligheter du har tilgjengelig under syntesen og som tillater denne modulariteten, inkluderer:

  • Før syntesen, spesifiser en RTL-partisjon (i Synplify vil dette være kalt et “compile point”) eller lag et hierarkisk delprosjekt.
  • Post-syntese, isolér (eksport) som et delprosjekt bare den delen av designet som ikke har nok ytelse ved å bruke hierarkisk programstyringsflyt. Gjenta, fiks og kombinér resultatet tilbake.
  • Få synteseprogrammet til å kommunisere til Vivado place and route-verktøyet at det plasserer kritiske baner på samme silisium på en multi SLR-komponent, som Virtex-7 2000T FPGA, for å unngå krysset SLR-forsinkelse.
Figur 3 — Avlus klokketrær og klokkebegrensninger ved å bruke en skjemaleser som peker ut klokketrærne.

 

Trinn 3: Oppnå endelig timing-avslutning

Generell timing kan rapporteres etter syntesen og etter plassering og ruting (Figur 4). For eksempel tillater Synplify at du rapporterer spesifikke deler av designet ved å bruke en TCL-kommando (report_timing). For å forbedre timing-QoR ytterligere, anbefaler vi at du korrelerer post-syntese og post P&R timingresultater, spesifikt slakkmarginer for et gitt start- og endepunkt på timingens kritiske baner. I Synplify Premier synteseprogram kan du for eksempel vise post-syntese og P&R timingrapporten ved siden av hverandre, for å avlese timing-resultatene.

Korrelasjonsverktøyet gjør sammenligning av status på endepunkter, startpunkter og ønsket perioder, vist ved siden av hverandre. Baner rapporteres mot sluttklokken. Baner der pre- og post P&R-timing ikke korrelerer godt innenfor din spesifiserte “slakkmargin”, vil bli flagget som “korrelasjon mismatch” slik at du kan ta tak i problemet. En typisk aksjon vil være å spesifisere såkalte “rute”-begrensninger i synteseverktøyet som tetter timing banebegrensninger kun under syntesefasen. Her er et eksempel:

FDC Constraints inngangsfil til syntesen:

set_clock_route_delay {c:clka} 1.4

Disse begrensningene får syntesen til å “arbeide hardere” for å møte timingytelsen i disse banene, og resulterer i bedre korrelasjon og QoR.

Det fine med tidskorrelasjonsfunksjonen er at du kan gå helt inn for å se den eksakte banen som skaper problemer. For eksempel ved å endre antall baner du ønsker vist ved hvert endepunkt. Du kan søke etter spesifikke klokker eller hendelser av interesse og få deres timingbaner presentert. Klokker blir også sammenlignet og presentert for ytterligere assistanse i tidskorrelasjon (se Figur 5 under).

 

Som du ser er det visse skritt du trenger å ta for å oppnå bedre timing-ytelse innenfor rimelig tid i Vivado Design Suite. Metodikken vi har presentert vil gripe inn i klokke- og begrensningsoppsett tidlig, samtidig som man får en rekke teknikker for å justere og korrelatere timing i ditt design og dets RTL for å oppnå rask timing-avslutning.

For mer informasjon og eksempler, besøk http://www.synopsys.com/fpga

Figur 4 – Du kan generere timing-rapporter for å avluse spesifikkenoder i designet.
Figur 5.
Powered by Labrador CMS