Eksempler på utforming av store FPGA-prosjekter. Om å dokumentere prosjekter for plis. assosiativ hukommelse. Organisering, samplingsmetode, forskjeller fra adresseminne

Tenk deg at prosessoren, i stedet for å utføre et spesifikt sett med instruksjoner, skal bygges om for hvert program og gjøre algoritmen direkte til maskinvare. Det er slik FPG-er fungerer. I dagens artikkel vil jeg forklare hvordan dette til og med er mulig og introdusere deg for ulike FPGA-designmetoder.

For å komme i gang må du forstå litt om den digitale logikken i hvordan ASIC-er fungerer, men det er veldig vanskelig og dyrt å starte med dem, og det er bedre å begynne med FPGA-er i stedet.

Hva er FPGA?

FPGA står for feltprogrammerbare portarrayer (brukerprogrammerbare portmatriser, FPGA). I et mer generelt tilfelle kalles de FPGA - programmerbare logiske integrerte kretser.

Ved hjelp av FPGA kan du i ordets rette forstand designe digitale mikrokretser mens du sitter hjemme med et rimelig feilsøkingskort på bordet og utviklerprogramvare for flere tusen grønne rubler. Men det er også gratis alternativer. Merk: det er å designe, ikke å programmere, for ved utgangen vil vi få en fysisk digital krets som utfører en viss algoritme på maskinvarenivå, og ikke en prog for prosessoren.

Det fungerer som følger. Det er et ferdig kretskort med et sett med grensesnitt som er koblet til en FPGA-brikke installert på kortet, noe sånt som et så kult datasenterkort eller dette feilsøkingskortet for trening.

Inntil vi konfigurerer FPGA, er det rett og slett ingen logikk inne i brikken for å behandle data fra grensesnittene, og derfor vil selvfølgelig ingenting fungere. Men som et resultat av designet vil det bli opprettet fastvare, som, etter å ha lastet inn i FPGA, vil skape den digitale kretsen vi trenger. På denne måten kan du lage en 100G Ethernet-kontroller som vil motta og behandle nettverkspakker.

En viktig funksjon ved FPGA er muligheten til å rekonfigurere. La oss si at nå trenger vi en 100G Ethernet-kontroller, og om en uke kan det samme kortet brukes til å implementere fire uavhengige 25G Ethernet-grensesnitt.

Det er to ledere innen FPGA-brikkeprodusenten på markedet: den velkjente Intel og Xilinx. De kontrollerer 58 og 42 % av markedet. Grunnleggerne av Xilinx oppfant sin første FPGA-brikke tilbake i 1985. Intel kom inn på markedet ganske nylig - i 2015, og absorberte Altera, som ble grunnlagt samtidig med Xilinx. Altera- og Xilinx-teknologiene ligner på mange måter, det samme er utviklingsmiljøer. Oftere enn ikke har jeg jobbet med Xilinx-produkter, så ikke bli overrasket over å se henne konstant nevnt i artikkelen.

FPGA-er er mye brukt i ulike felt: forbrukerelektronikk, telekomutstyr, akseleratorkort for bruk i datasentre, robotikk, ASIC-prototyping. Jeg skal gå gjennom et par eksempler nedenfor.

Vi skal også se på teknologien som gir maskinvarekonfigurasjon, gjøre oss kjent med designprosessen og analysere et enkelt eksempel på implementering av en maskinvareteller i Verilog-språket. Hvis du har et FPGA-debug-kort, bør du kunne replikere dette selv. Hvis det ikke er noe brett, kan du fortsatt bli kjent med Verilog ved å simulere driften av kretsen på datamaskinen.

Hvordan en FPGA fungerer

FPGA-brikken er den samme tilpassede ASIC-brikken, som består av de samme transistorene som brukes til å sette sammen flip-flops, registre, multipleksere og andre logiske elementer for konvensjonelle kretser. Selvfølgelig er det umulig å endre rekkefølgen på tilkoblingen til disse transistorene. Men arkitektonisk er mikrokretsen bygget på en så utspekulert måte at du kan endre vekslingen av signaler mellom større blokker: de kalles CLB - programmerbare logiske blokker.

Du kan også endre logikkfunksjonen som CLB utfører. Dette oppnås på grunn av det faktum at hele brikken er gjennomsyret av konfigurasjonsminneceller Statisk RAM. Hver bit av dette minnet kontrollerer enten en slags signalbyttenøkkel, eller er en del av sannhetstabellen til en logisk funksjon som CLB implementerer.

Siden konfigurasjonsminnet er bygget ved hjelp av statisk RAM-teknologi, for det første, når FPGA-en er slått på, må mikrokretsen konfigureres, og for det andre kan mikrokretsen rekonfigureres nesten et uendelig antall ganger.

CLB-ene ligger i en svitsjematrise som definerer forbindelsene for inngangene og utgangene til CLB-ene.

Ved hvert skjæringspunkt av ledere er det seks brytertaster kontrollert av sine egne konfigurasjonsminneceller. Ved å åpne noen og lukke andre, er det mulig å gi ulik veksling av signaler mellom CLB-er.

CLB består veldig enkelt av en blokk som definerer en boolsk funksjon av flere argumenter (det kalles en oppslagstabell - Look Up Table, LUT) og en trigger (flip-flop, FF). I moderne FPGA-er har LUT seks innganger, men figuren viser tre for enkelhets skyld. LUT-utgangen mates til CLB-utgangen enten asynkront (direkte) eller synkront (via en FF-flip-flop som kjører på systemklokken).

Det er interessant å se på prinsippet for LUT-implementering. La oss si at vi har en boolsk funksjon y = (a & b) | ~c. Dens skjematiske representasjon og sannhetstabell er vist i figuren. Funksjonen har tre argumenter, så den tar 2^3 = 8 verdier. Hver av dem tilsvarer sin egen kombinasjon av inngangssignaler. Disse verdiene beregnes av FPGA-fastvareutviklingsprogrammet og skrives til spesielle konfigurasjonsminneceller.

Verdien til hver av cellene mates til inngangen til LUT-utgangsmultiplekseren, og inngangsargumentene til den boolske funksjonen brukes til å velge en eller annen funksjonsverdi. CLB er den viktigste FPGA-maskinvareressursen. Mengden CLB i moderne FPGA-brikker kan variere og avhenger av brikkens type og kapasitet. Xilinx har CLB-krystaller fra rundt fire tusen til tre millioner.

I tillegg til CLB er det en rekke viktige maskinvareressurser inne i FPGA. For eksempel maskinvaremultiplikasjons-akkumuleringsblokker eller DSP-blokker. Hver av dem kan multiplisere og addere 18-biters tall hver syklus. I avanserte krystaller kan antallet DSP-blokker overstige 6000.

En annen ressurs er interne minneblokker (Block RAM, BRAM). Hver blokk kan lagre 2 KB. Den totale kapasiteten til slikt minne, avhengig av krystallen, kan nå fra 20 KB til 20 MB. I likhet med CLB-er er BRAM- og DSP-blokker koblet sammen med en svitsjingsmatrise og gjennomsyrer hele brikken. Ved å koble sammen CLB-, DSP- og BRAM-blokkene kan svært effektive databehandlingsskjemaer oppnås.

Fordeler med FPGAer

Den første FPGA-brikken laget av Xilinx i 1985 inneholdt bare 64 CLB-er. På den tiden var integreringen av transistorer på brikker mye lavere enn den er nå, og "løs logikk"-brikker ble ofte brukt i digitale enheter. Det var separate brikker for registre, tellere, multipleksere, multiplikatorer. For en spesifikk enhet ble det laget et eget trykt kretskort, som disse lavintegrerte mikrokretsene ble installert på.

Bruken av FPGA gjorde det mulig å forlate denne tilnærmingen. Selv en 64 CLB FPGA sparer plass på det trykte kretskortet, og tilgjengeligheten av rekonfigurasjon la til muligheten til å oppdatere funksjonaliteten til enheter etter produksjon under drift, som de sier "i felten" (derav navnet - feltprogrammerbar portarray ).

På grunn av det faktum at enhver digital maskinvarekrets kan opprettes inne i FPGA (hovedsaken er at det er nok ressurser), er en av de viktige bruksområdene til FPGA-er prototyping av ASIC-brikker.

ASIC-utvikling er veldig kompleks og kostbar, kostnadene ved feil er svært høye, og spørsmålet om testing av logikk er kritisk. Derfor var et av utviklingsstadiene, selv før arbeidet med den fysiske topologien til kretsen startet, dens prototyping på en eller flere FPGA-brikker.

For ASIC-utvikling utgis spesialkort som inneholder mange sammenkoblede FPGA-er. Mikrobrikkeprototypen opererer med mye lavere frekvenser (kanskje titalls megahertz), men sparer penger på å identifisere problemer og feil.

Imidlertid er det etter min mening mer interessante anvendelser av FPGA-er. Den fleksible strukturen til FPGA tillater implementering av maskinvarekretser for høyhastighets og parallell databehandling med muligheten til å endre algoritmen.

La oss tenke på den grunnleggende forskjellen mellom CPU, GPU, FPGA og ASIC. CPU-en er universell, du kan kjøre hvilken som helst algoritme på den, den er den mest fleksible, og den er den enkleste å bruke på grunn av det store antallet programmeringsspråk og utviklingsmiljøer.

På samme tid, på grunn av allsidigheten og sekvensiell utførelse av CPU-instruksjoner, reduseres ytelsen og strømforbruket til kretsen øker. Dette skjer fordi for hver nyttig aritmetisk operasjon utfører CPU-en mange tilleggsoperasjoner relatert til lesing av instruksjoner, flytting av data mellom registre og hurtigbuffer og andre bevegelser.

På den andre siden er ASIC. På denne plattformen er den nødvendige algoritmen implementert i maskinvare på grunn av direkte tilkobling av transistorer, alle operasjoner er kun relatert til utførelsen av algoritmen, og det er ingen måte å endre den på. Derfor den maksimale ytelsen og det laveste strømforbruket til plattformen. Men det er umulig å omprogrammere ASIC.

Til høyre for CPU er GPU. Opprinnelig ble disse brikkene designet for grafikkbehandling, men brukes nå til generell datautvinning. De består av tusenvis av små datakjerner og utfører parallelle operasjoner på en rekke data.

Hvis algoritmen kan parallelliseres, vil det på GPU være mulig å oppnå betydelig akselerasjon sammenlignet med CPU. På den annen side vil sekvensielle algoritmer implementeres dårligere, slik at plattformen er mindre fleksibel enn CPU. For GPU-utvikling må du også ha spesielle ferdigheter, kjenne til OpenCL eller CUDA.

Til slutt, FPGA. Denne plattformen kombinerer effektiviteten til ASIC-er med muligheten til å endre programmet. FPGAer er ikke universelle, men det er en klasse med algoritmer og oppgaver som vil vise bedre ytelse på dem enn på CPUer og til og med GPUer. Kompleksiteten i utviklingen for FPGA er høyere, men nye utviklingsverktøy gjør dette gapet mindre.

Den avgjørende fordelen med FPGA er muligheten til å behandle data i takt med ankomst med minimal responsforsinkelse. Tenk deg som et eksempel en smart nettverksruter med et stort antall porter: når en Ethernet-pakke kommer til en av portene, må mange regler sjekkes før du velger en utgangsport. Det kan hende du må endre noen felt i pakken eller legge til nye.

Ved å bruke FPGA kan du løse dette problemet umiddelbart: bytene til pakken har akkurat begynt å komme til mikrokretsen fra nettverksgrensesnittet, og overskriften blir allerede analysert. Bruken av prosessorer her kan redusere hastigheten på prosessering av nettverkstrafikk betydelig. Det er klart at du kan lage en tilpasset ASIC-brikke for rutere som vil fungere mest effektivt, men hva om reglene for behandling av pakker må endres? Bare FPGA kan hjelpe deg med å oppnå den nødvendige fleksibiliteten kombinert med høy ytelse.

Dermed brukes FPGAer der høy prosessytelse, raskest responstid og lavt strømforbruk er nødvendig.

FPGA i skyen

I cloud computing brukes FPGA-er for rask telling, nettverkstrafikkakselerasjon og tilgang til datamatriser. Dette inkluderer også bruk av FPGA for høyfrekvent handel på børser. FPGA-kort med PCI Express og et optisk nettverksgrensesnitt produsert av Intel (Altera) eller Xilinx settes inn i serverne.

FPGA-er er flotte for kryptografiske algoritmer, DNA-sekvenssammenligning og vitenskapelige oppgaver som molekylær dynamikk. Microsoft har lenge brukt FPGA-er for å akselerere Bing-søketjenesten, i tillegg til å organisere Software Defined Networking i Azure-skyen.

Maskinlæringsboomen har heller ikke gått utenom FPGA. Xilinx og Intel tilbyr FPGA-baserte verktøy for arbeid med dype nevrale nettverk. De lar deg få FPGA-fastvare som implementerer et bestemt nettverk direkte fra rammeverk som Caffe og TensorFlow.

Dessuten kan du prøve alt dette uten å forlate hjemmet ditt og bruke skytjenester. Hos Amazon kan du for eksempel leie en virtuell maskin med tilgang til et FPGA-kort og eventuelle utviklingsverktøy, inkludert maskinlæring.

FPGA på kanten

Hva annet er interessant å gjøre på FPGA? Hvorfor gjør de ikke bare det! Robotikk, ubemannede kjøretøy, droner, vitenskapelige instrumenter, medisinsk utstyr, brukermobilenheter, smarte sikkerhetskameraer og så videre.

Tradisjonelt ble FPGA-er brukt til digital behandling av endimensjonale signaler (og konkurrerte med DSP-prosessorer) i radarenheter, radiosignalsendere. Med den økende integrasjonen av brikker og økende ytelse, har FPGA-plattformer blitt stadig mer brukt for høyytelses databehandling, for eksempel for å behandle todimensjonale signaler "på kanten av skyen" (edge ​​computing).

Dette konseptet er lettest å forstå ved å bruke eksemplet med et trafikkanalysekamera med skiltgjenkjenning. Du kan ta et kamera med muligheten til å overføre video over Ethernet og behandle strømmen på en ekstern server. Etter hvert som antallet kameraer øker, vil også belastningen på nettverket øke, noe som kan føre til systemfeil.

I stedet er det bedre å implementere skiltgjenkjenning på en kalkulator installert direkte i videokameraets kropp og overføre skilt til skyen i tekstformat. For å gjøre dette kan du til og med ta relativt rimelige laveffekts FPGA-er for å klare deg med et batteri. Samtidig er det fortsatt mulig å endre logikken til FPGA, for eksempel når du endrer standarden for skilt.

Når det gjelder robotikk og droner, er det i dette området spesielt viktig å oppfylle to betingelser - høy ytelse og lavt strømforbruk. FPGA-plattformen passer perfekt og kan spesielt brukes til å lage flykontrollere for droner. UAV-er lages allerede som kan ta avgjørelser på farten.

FPGA prosjektutvikling

Det er forskjellige nivåer av design: lav, blokk og høy. Det lave nivået innebærer å bruke språk som Verilog eller VHDL, hvor du kontrollerer utviklingen på registeroverføringsnivå (RTL). I dette tilfellet danner du registre, som i en prosessor, og definerer logiske funksjoner som endrer dataene mellom dem.

FPGA-kretser opererer alltid med visse klokkehastigheter (vanligvis 100-300 MHz), og på RTL-nivå definerer du oppførselen til kretsen innenfor en systemklokke. Dette møysommelige arbeidet resulterer i de mest effektive kretsene når det gjelder ytelse, FPGA-formressursforbruk og strømforbruk. Men her kreves seriøse ferdigheter i kretsløp, og prosessen er ikke rask med dem.

På blokknivå kobler du i utgangspunktet sammen ferdige store blokker som utfører visse funksjoner for å få funksjonaliteten til system-on-chip (system-on-chip) du trenger.

På et høyt designnivå vil du ikke lenger ha kontroll over dataene ved hver klokkesyklus, i stedet vil du konsentrere deg om algoritmen. Det finnes kompilatorer eller oversettere fra C og C++ til RTL-nivå, for eksempel Vivado HLS. Det er ganske smart og lar deg oversette en bred klasse av algoritmer til maskinvarenivå.

Hovedfordelen med denne tilnærmingen fremfor RTL-språk er utviklingshastigheten og spesielt algoritmetesting: C++-kode kan kjøres og verifiseres på en datamaskin, og det vil være mye raskere enn å teste algoritmendringer på RTL-nivå. Selvfølgelig må du betale for bekvemmelighet - kretsen kan vise seg å ikke være så rask og ta mer maskinvareressurser.

Ofte er vi klare til å betale denne prisen: hvis du bruker oversetteren riktig, vil effektiviteten ikke lide mye, og det er nok ressurser i moderne FPGA-er. I vår verden med en kritisk tids-til-marked-indikator, viser dette seg å være berettiget.

Ofte må alle tre utviklingsstilene kombineres i ett design. La oss si at vi må lage en enhet som vi kan bygge inn i en robot og gi den muligheten til å gjenkjenne objekter i en videostrøm – for eksempel veiskilt. La oss ta en videosensorbrikke og koble den direkte til FPGA. For feilsøking kan vi bruke en HDMI-skjerm, også koblet til FPGA.

Rammer fra kameraet vil bli overført til FPGA via et grensesnitt som er forhåndsbestemt av sensorprodusenten (USB fungerer ikke her), behandlet og vist på skjermen. For å behandle rammer trenger du en rammebuffer, som vanligvis er plassert i et eksternt DDR-minne montert på et kretskort ved siden av FPGA-brikken.

Hvis produsenten av videosensoren ikke gir grensesnitt IP for FPGA-brikken vår, må vi skrive den selv på RTL-språket, telle klokker, biter og bytes i samsvar med spesifikasjonen for dataoverføringsprotokollen. Forprosess, DDR-kontroller og HDMI IP-blokker, vi vil mest sannsynlig ta ferdige og ganske enkelt koble til grensesnittene deres. Og HLS-blokken, som utfører søk og behandling av innkommende data, kan vi skrive i C ++ og kringkaste ved hjelp av Vivado HLS.

Mest sannsynlig trenger vi fortsatt en form for ferdiglaget trafikkskiltdetektor og klassifiseringsbibliotek, tilpasset for bruk i FPGA. I dette eksemplet gir jeg selvfølgelig et sterkt forenklet designflytskjema, men det gjenspeiler logikken i arbeidet riktig.

Vurder designbanen fra å skrive RTL-kode til å få en konfigurasjonsfil til å laste inn i FPGA.

Så du skriver RTL-kode som implementerer skjemaet du trenger. Før du tester den på ekte maskinvare, må du sørge for at den er riktig og løser det nødvendige problemet. Til dette brukes RTL-modellering i en simulator på en datamaskin.

Du tar kretsen din, kun representert i RTL-kode så langt, og setter den på en virtuell benk, hvor du bruker sekvenser av digitale signaler til kretsinngangene, registrerer utgangsdiagrammer, tidsavhengigheter til utgangssignalene og sammenligner med de forventede resultatene. . Vanligvis finner du feil og går tilbake til å skrive RTL.

Videre mates den logisk verifiserte koden til inngangen til synthesizer-programmet. Den konverterer tekstbeskrivelsen av kretsen til en koblet liste over digitale elementer fra biblioteket som er tilgjengelig for den gitte FPGA-brikken. Denne listen vil vise elementer som LUT-er, triggere og koblinger mellom dem. På dette stadiet er elementene ennå ikke knyttet til spesifikke maskinvareressurser. For å gjøre dette, må du pålegge begrensninger (Begrensninger) på kretsen - spesifiser spesielt hvilke fysiske I / O-pinner på FPGA-brikken som er koblet til de logiske inngangene og utgangene til kretsen din.

Disse begrensningene krever også at du spesifiserer med hvilke klokkehastigheter kretsen skal fungere. Utdataene fra synthesizeren og constraint-filen blir gitt til Implementation-prosessoren, som blant annet håndterer Place and Route.

Plass-prosessen binder hvert ennå upersonlige element fra nettlisten til et spesifikt element inne i FPGA-brikken. Deretter begynner ruteprosessen å fungere, som prøver å finne den optimale tilkoblingen av disse elementene for den tilsvarende konfigurasjonen av FPGA-svitsjematrisen.

Sted og rute opererer basert på begrensningene vi har pålagt kretsen: I/O-pinner og klokkehastighet. Klokkeperioden har en veldig sterk effekt på implementeringen: den må ikke være mindre enn tidsforsinkelsen på de logiske portene i den kritiske kretsen mellom to påfølgende flip-flops.

Ofte kan ikke dette kravet oppfylles umiddelbart, og da er det nødvendig å gå tilbake til startstadiet og endre RTL-koden: prøv for eksempel å redusere logikken i den kritiske kjeden. Etter at implementeringen er fullført, vet vi hvilke elementer som er hvor og hvordan de er koblet sammen.

Først etter det starter prosessen med å lage en binær FPGA-fastvarefil. Det gjenstår å laste den inn i ekte maskinvare og sjekke om den fungerer som forventet. Hvis det oppstår problemer på dette stadiet, betyr det at modelleringen var ufullstendig og på dette stadiet ble ikke alle feil og mangler eliminert.

Du kan gå tilbake til simuleringsstadiet og simulere en unormal situasjon, og hvis dette ikke fungerer, i ekstreme tilfeller, leveres en feilsøkingsmekanisme direkte i den kjørende maskinvaren. Du kan spesifisere hvilke signaler du vil spore over tid, og utviklingsmiljøet vil generere en ekstra logisk analysatorkrets som plasseres på brikken ved siden av designkretsen din, kobler til signalene av interesse og lagrer verdiene deres over tid. De lagrede tidsdiagrammene for de ønskede signalene kan lastes ned til en datamaskin og analyseres.

Mens det var ferier laget jeg et lite prosjekt på Verilog, som jeg hadde lyst til å prøve lenge.

Essensen av prosjektet er som følger: en rask (relativt, selvfølgelig) ADC med to kanaler og et parallellgrensesnitt (14-16 biter per kanal) er koblet til FPGA. FPGA leser data fra ADC og lagrer dem i en buffer (dets interne BRAM-minne). Når bufferen er full, stopper lesingen og den eksterne enheten (mikrokontrolleren) kan lese dataene fra bufferen via SPI-grensesnittet. Du kan også konfigurere noen parametere via SPI (dette vil bli diskutert i neste innlegg).

Prosjekttest (klikkbart bilde).

Synteseresultat for Cyclone IVE

Jeg syntetiserte resultatet i Quartus II, for FPGA av Cyclone IVE-familien (EP4CE6E22A7). Dette er en av de enkleste og rimeligste FPGAene i QFP144-pakken for 6272 logiske elementer. Brikken har en minnekapasitet på 30K * 9 bits. Brukerpinner - 92.

brikke EP4CE6E22A7
logiske elementer - 301 (5 %)
pinner - 41 (45 %)
minne - 65536 biter (24%)
verste fall frekvens (125 C) - 151 MHz.

Minne 8 KB, dette er faktisk bufferen hvor dataene skrives. Med to kanaler på 16 bit, blir det 32 ​​biter per sample, og 2048 sampler. Jeg bestemte meg for at dette ville være nok, selv om bufferen kan utvides til og med til hele volumet.

Frekvensen er ganske tilfredsstillende, jeg forventet at det ville være en klokkefrekvens på 50 MHz, og en ADC på 25 MHz. Det vil si at det oppnås en tredobbel margin i frekvens.

Antallet logiske elementer er ganske ubetydelig for en slik FPGA, dvs. du kan, om du ønsker, feste mye annet der, spesielt siden det er så mange som 51 pinner igjen.

Det er en nyere Cyclone 10-familie.

Synteseresultat for Cyclone 10

Vi velger brikken 10CL006YE144C8G. Den har samme antall porter (6272) som Cyclone 4-versjonen og samme mengde minne (30K x 9). Dekselet er det samme som QFP144, det er enda færre brukerpinner - 89.

brikke 10CL006YE144C8G
logiske elementer - 289 (5 %)
pinner - 41 (46 %)
minne - 65536 biter (24%)
den verste frekvensen (85 C) er 145,5 MHz.

Det er merkelig at prosjektet har blitt mer kompakt når det gjelder logiske elementer. Det vil si at med samme logiske kapasitet vil et mer komplekst prosjekt passe inn i Cyclone 10. Alt annet er omtrent på samme nivå.

Et rimelig spørsmål dukker opp: er det mulig å spare penger ved å installere en annen FPGA eller CPLD?

La oss prøve FPGA MAX10.

Synteseresultat for MAX 10

Her kan leseren (hvis han er i emnet) utbryte: nei, sånn er det ikke! MAX-familien er CPLD, ikke FPGA, og å forvirre disse konseptene er åpenbar uprofesjonalitet!

Men takket være innsatsen til Intel-markedsførere (vet alle at vi snakker om Intel-brikker?), har MAX10-familien blitt til en FPGA, selv om den har et internt ikke-flyktig konfigurasjonsminne, som enhver CPLD.

Så vi velger en brikke, for eksempel 10M02SCE144A7G (2304 LE, 101 GPIO, 12Kx9 BRAM), QFP144-pakke.

brikke 10M02SCE144A7G.
logiske elementer - 298 (13 %)
pinner - 41 (41 %)
minne - 65536 biter (59 %)
verste fall frekvens (125 C) - 153 MHz.

Vi ser at de absolutte indikatorene forble praktisk talt de samme, bare graden av krystallfylling økte, noe som er forståelig - 2304LE versus 6272 LE.

Kan MAX II brukes?

Nå er spørsmålet: er det mulig å bruke noen veldig billige CPLD, for eksempel MAX II? Alt er mer komplisert her. De har ikke BRAM-minne, dvs. du trenger også en ekstern rask SRAM.

For å koble til SRAM vil det selvfølgelig være behov for ekstra logikk. Hvis vi bruker 4K x 16 minne, vil vi trenge ytterligere 16 pinner for data, 12 for adresse og 3 for kontroll (/cs, /we, /oe), for totalt 31 ekstra pinner.

Logikken vil også øke i størrelse. Det er vanskelig å si nøyaktig hvor mye, men det vil ikke passe inn i CPLD på 240 LE i utgangspunktet, men kanskje det vil passe inn i 570 LE.

Vi velger CPLD EPM570 i QFP100-pakken. Vi trenger kun 72 pinner, dekselet har 76 pinner for GPIO, dvs. skal være nok til alt, men det er allerede veldig lite rom for utvidelse.

Fordeler med denne løsningen: muligens lavere pris (selv med en ekstra SRAM-brikke), ulemper: større kretskompleksitet og kortareal.

Utstedelsespris

Her er det jeg fant med efind. Mikrokretser er litt forskjellige, men tallet og bokstaven på slutten er ytelsesindeksen og temperaturområdet (kommersielt). Siden vi har en tredobbel margin i frekvens, er disse tallene absolutt ikke viktige for oss.

EP4CE6E22C8N - 456.55 R (Promelectronics, EKB, detaljhandel)
10CL006YE144C - 754,71 (Det femte elementet, St. Petersburg, engros)
10M02SCE144C8G - 456 R (Elitan, Ekb, engros)
EPM570F100C5N - 368 R (Hitech, St. Petersburg) + minne (CY7C1021DV33-10ZSXI, SRAM 1MBIT 10NS 44TSOP) - 92,51 R (Industriell elektronikk, EKB, detaljhandel)

Selvfølgelig kan du finne billigere, dette er bare utsalgspriser i butikken, men forholdet vil være omtrent det samme.

Det kan sees at CPLD-alternativet ikke vinner på noen måte prismessig, samtidig som det har mange ulemper. Resten av alternativene er omtrent likeverdige, bortsett fra at Cyclone 10 fortsatt er litt dyrere og få personer har den på lager. Dette er imidlertid en helt ny familie, så langt har ikke alle distributører tatt den med.

Personlig liker jeg best alternativet MAX 10. Det har én fordel: ingen grunn til å laste FPGA-konfigurasjonen ved oppstart. I Cyclone 4-varianten må du laste inn FPGA-konfigurasjonen, noe som kan gjøres enten ved å bruke en ekstra konfigurasjonsminnebrikke eller ved å bruke en mikrokontroller. Det er et tredje alternativ: flash via JTAG og fjern aldri strømmen fra brikken. Jeg hørte at noen gjorde dette, jeg vet ikke om det er en spøk eller ikke, men jeg vil definitivt ikke gjøre det.

Imidlertid har varianten med Cyclone 4-fastvare gjennom mikrokontrolleren en fordel: muligheten til å oppdatere FPGA-fastvaren gjennom brukergrensesnitt: USB, Ethernet, etc.

Et annet ikke-trivielt alternativ er mulig: ikke installer en mikrokontroller i det hele tatt, men flash en innebygd prosessor inn i FPGA. Men dette er ikke et veldig godt alternativ, kanskje fordi. dette vil definitivt kreve ekstern ROM og RAM, samt minst en USB-bro. Det er ikke nødvendig å bevisst nekte dette alternativet, selvfølgelig, men det virker for meg vanskeligere å implementere enn med en mikrokontroller.

Om hvilke funksjoner denne fastvaren utfører, vil jeg skrive i neste innlegg.

BRUKER FPGA I MODERNE ENHETER

Tupikov Pavel Andreevich

5. års student, Institutt for kunst OmSTU, Russland, Omsk

I dag brukes programmerbare logiske integrerte kretser (FPGA-er) i økende grad i ulike moderne enheter, dette skyldes det faktum at FPGA-er har betydelige fordeler i forhold til konvensjonelle digitale mikrokretser. Disse fordelene inkluderer:

· Forbedret ytelse av produktet.

· Prisen på produktet er redusert.

Reduserte dimensjoner på produktet.

Produktets pålitelighet øker (antall diskrete mikrokretser reduseres)

Produktfleksibiliteten øker (FPGA kan alltid omprogrammeres)

FPGA-arkitekturen har en kompleks struktur (fig. 1)

Figur 1. Den interne strukturen til FPGA

Som det fremgår av figur 1, består hoveddelen av FPGA av programmerbare logiske blokker og programmerbare interne forbindelser.

Selve prosessen med å programmere (fastvare) FPGA består i dannelsen av de nødvendige forbindelsene mellom inngangene og utgangene til enheten.

Til dags dato er det to verdensledende innen produksjon av FPGA-er i verden. Dette er amerikanske firmaer Xilinx og Altera.

Hvert selskap tilbyr sin egen CAD for arbeid med FPGA-er. Xilinx tilbyr Xilinx Software Development Kit (SDK). Altera tilbyr Max+Plus II og Quartus II, samt ModelSim-simuleringssystemet.

For å lage fastvareprogrammer brukes vanligvis språk for å beskrive driften av utstyr, følgende språk er de vanligste i dag:

Verilog HDL.

VHDL-språket er det vanskeligste å lære, men samtidig har det de største evnene på funksjons- og atferdsnivåene for abstraksjon, men det har mindre evner på det strukturelle abstraksjonsnivået sammenlignet med Verilog HDL, VITAL-biblioteket var utviklet for å utvide mulighetene til VHDL-språket (fig. 2).

Figur 2. Abstraksjonslag Verilog Og VHDL

Et eksempel på driften av Verilog HDL-språket er et program implementert på CYCLONE III EP3C5E1444C8N FPGA på Mini-DiLab-stativet, hvis generelle visning er vist i fig. 3.

Figur 3. Oversikt over brettet Mini - DiLab

Dette programmet implementerer sekvensiell svitsjing av led0-led7 lysdioder, med valget mellom å legge til "lys"-bevegelsen ved å bruke pba- og pbb-knappene, samt kontrollere byttehastigheten ved hjelp av bryterne sw0, sw1.

//Programtekst

modul prosjekt( produksjon ledet, input clk_25mhz, input pba, input pbb,

input sw);

// Destinasjon for interne forbindelser til prosjektet

metalltråd s1;

metalltråd s2;

metalltråd s3;

// Kalle andre filer (subrutiner) koblet til prosjektet

Tr tr_1 (.out(s2), .set(pba), .res(pbb));

Teller teller_1 (.q(s1), .clk(clk_25mhz), .up(s2));

Mx mx_1 (.a(s3), .in(s1), .load(sw));

Dc3_8 dc3_8_1 (.out(led), .in(s3));

endemodul// programslutt

Subrutine tr

modul tr(ut, sett, res); // Lag et program

// I/O-oppdrag

produksjonreg ute;

input sett;

input res;

// initialisering

første

begynne

ute<= 1"d0;

// Hovedprogramkode

alltid @(negedge sett eller negedge res)

begynne

hvis(~(sett))

ute<= 1"d1;

ellers

ute<= 1"d0;

endemodul // Slutt på programmet

Subrutineteller

modul teller(con, q, clk, opp); // Programstart

produksjonreg lure;

produksjon q = con;

input opp, klk;

// Hovedprogramkode

alltid @(posedge klk)

begynne

hvis(clk)

hvis(opp)

Lure<= con - 1"d1;

ellers

Lure<= con + 1"d1;

endemodul// Slutt på programmet

Subrutine mx (multiplekser)

modul mx( output.reg en, input i, input laste);

// Hovedprogramkode

alltid @*

begynne

sak(laste)

2"b00: a = i;

2"b01: a = i;

2"b10: a = i;

2"b11: a = i;

endekasse

endemodul // Slutt på programmet

Subrutine dc3_8 (multiplekser)

modul dc3_8(ut, inn); // Programstart

// I/O-oppdrag

output.reg ute;

inngangsledning i;

// Hovedprogramkode

alltid @*

begynne

sak(i)

3"d0: ut = 8"b11111110;

3"d1: ut = 8"b11111101;

3"d2: ut = 8"b11111011;

3"d3: ut = 8"b11110111;

3"d4: ut = 8"b11101111;

3"d5: ut = 8"b11011111;

3"d6: ut = 8"b10111111;

3"d7: ut = 8"b01111111;

endekasse

endemodul // Slutt på programmet

Programmet ble implementert i CAD Quartus II.

Etter kompilering av programmet genererte kompilatoren ingen feil eller merknader i programmet knyttet til analysen og syntaksen til programmet (fig. 4).

Figur 4. Prosjektmeldingsvindu

Kommentarene fra kompilatoren indikerer fraværet av en lisens for Quartus II (gratisversjonen av programmet ble brukt til opplæring) og fraværet av filer som er nødvendige for å modellere prosjektet.

RTL Strukturen til dette prosjektet er vist i fig. 5.

Figur 5. Prosjektgjennomføring ( RTL struktur)

Som vist i fig. 6 i dette programmet brukes bare en liten del av funksjonene til denne FPGAen.

Figur 6. En del av FPGA involvert i prosjektet

Konklusjoner: Programmerbare logiske integrerte kretser brukes i mange enheter. For å lære å jobbe med dem, er det nødvendig å introdusere i utdanningsprogrammet for spesialiteter relatert til design og konstruksjon av radio-elektronisk utstyr kjennskap til maskinvarebeskrivelsesspråkene (Verilog HDL og VHDL).

Bibliografi:

1. Grushevitzky R.I. Designe systemer basert på mikrokretser av programlogikk / R.I. Grushevitzky, A.X. Mursaev, E.P. Dystert. St. Petersburg: BHV Petersburg, 2002. - 608 s.

2. Kolomov D.A. Datastøttede designsystemer fra Altra MAX+plus II og Quartus II. Kort beskrivelse og veiledning / D.A. Kolomov, R.A. Myalk, A.A. Zobenko, A.S. Filippov. M.: IP RadioSoft, 2002. - 126 s.

3. Maxfield K. FPGA-design. Forløpet til en ung jagerfly. / K. Maxfield. M.: Forlag "Dodeka-XXI", 2007. - 408 s. (oversettelse fra engelsk).

65 nanometer er neste mål for Zelenograd Angstrem-T-anlegget, som vil koste 300-350 millioner euro. Bedriften har allerede sendt inn en søknad om et mykt lån for modernisering av produksjonsteknologier til Vnesheconombank (VEB), rapporterte Vedomosti denne uken, med henvisning til Leonid Reiman, styreleder for anlegget. Nå forbereder Angstrem-T å lansere en linje for produksjon av brikker med en 90nm topologi. Betalinger på det forrige VEB-lånet, som det ble kjøpt for, starter i midten av 2017.

Beijing kollapset Wall Street

Viktige amerikanske indekser markerte de første dagene av det nye året med et rekordfall, milliardær George Soros har allerede advart om at verden venter på en gjentakelse av 2008-krisen.

Den første russiske forbrukerprosessoren Baikal-T1 til en pris av $60 lanseres i masseproduksjon

Baikal Electronics-selskapet i begynnelsen av 2016 lover å lansere den russiske Baikal-T1-prosessoren verdt rundt $60 til industriell produksjon. Enheter vil være etterspurt hvis denne etterspørselen er skapt av staten, sier markedsaktørene.

MTS og Ericsson skal i fellesskap utvikle og implementere 5G i Russland

PJSC "Mobile TeleSystems" og Ericsson signerte avtaler om samarbeid i utvikling og implementering av 5G-teknologi i Russland. I pilotprosjekter, inkludert under verdensmesterskapet i 2018, har MTS til hensikt å teste utviklingen til den svenske leverandøren. Operatøren vil i begynnelsen av neste år starte en dialog med Tele- og om utformingen av tekniske krav til femte generasjon mobilkommunikasjon.

Sergey Chemezov: Rostec er allerede et av de ti største ingeniørbedriftene i verden

I et intervju med RBC svarte sjefen for Rostec, Sergey Chemezov, brennende spørsmål: om Platon-systemet, problemene og utsiktene til AVTOVAZ, interessene til State Corporation i farmasøytisk virksomhet, snakket om internasjonalt samarbeid under sanksjonspress, import substitusjon, omorganisering, utviklingsstrategier og nye muligheter i vanskelige tider.

Rostec er «beskyttet» og griper inn på laurbærene til Samsung og General Electric

Representantskapet i Rostec godkjente "Utviklingsstrategien frem til 2025". Hovedoppgavene er å øke andelen høyteknologiske sivile produkter og ta igjen General Electric og Samsung i sentrale økonomiske indikatorer.

Artikkelen forsøker å bestemme sammensetningen av den medfølgende dokumentasjonen for de utviklede digitale modulene for programmerbare logiske integrerte kretser (FPGA). Denne medfølgende dokumentasjonen må gis av utviklerne til forbrukeren/kunden for vellykket videre bruk av den utviklede digitale modulen i deres prosjekter på stadiet for utforming av digitale enheter på FPGA.

Introduksjon

Så, hva slags designdokumentasjon bør spørres fra utvikleren hvis selskapet eller kundebedriften eller en annen utvikler i fremtiden vil bruke en "utenlandsk" utviklet enhet i sine prosjekter? Denne artikkelen kan tjene som et "jukseark" for først å utstede referansevilkårene for utvikling av en digital enhet for FPGA-er, og deretter be utvikleren om designdokumentasjon for en allerede utviklet digital enhet. Basert på tidligere erfaring med designdokumentasjon, bruker en virksomhet eller et firma vanligvis følgende standarder og forskrifter:

• GOST 2.102-68 ESKD. Typer og fullstendighet av designdokumenter.
• GOST 15.101-98. System for utvikling og produksjon av produkter. Prosedyren for å utføre forskningsarbeid.
• GOST R 15.201-20-00. System for utvikling og produksjon av produkter. Produkter til industrielle og tekniske formål. Prosedyren for utvikling og produksjon av produkter.

Som regel var disse en fastvarefil og et program (en beskrivelse av en digital enhet i VHDL / Verilog eller et sett med digitale kretser utviklet i en kretsredigerer ved bruk av digitale logiske bibliotekelementer, som flip-flops, registre, tellere, dekodere osv.) på CD eller DVD og programmeringsinstruksjoner. Og det er det.

Forfatteren sto for eksempel overfor følgende problem. En av de ansatte utviklet en kompleks multi-modul digital enhet. Jeg beskrev alle modulene i VHDL, og så på syklogrammene for driften av disse modulene og den digitale enheten som helhet på et godt og dyrt oscilloskop. Han kjente ikke til Test Bench-filer og om muligheten for å gjennomføre simuleringer eller visste ikke hvordan de skulle skrives, det var forresten heller ingen kommentarer til prosjektet og til beskrivelsene av modulene. Situasjonen kan bli enda verre hvis modulene er representert av digitale kretser designet i en skjematisk editor ved hjelp av bibliotekelementer. Det er her en av hovedulempene ligger: bortsett fra utvikleren selv, er det usannsynlig at noen andre vil forstå denne digitale enheten, spesielt hvis prosjektet er multi-modul, og beskrivelsen av hver modul er mer enn 100 linjer eller mer enn én skjerm. Så hvis en annen utvikler ønsker å introdusere en slik allerede utviklet digital enhet for FPGA i en ny utvikling eller et nytt prosjekt, må han igjen bruke tid på å utvikle denne digitale enheten.

Historie om designproblemet for FPGA-er

For øyeblikket er FPGA-markedet et av de mest dynamisk utviklende. FPGA-er brukes i mange grener av teknologi. For øyeblikket er det ingen entydig metodikk som tilfredsstiller alle maskinvareutviklere for å få FPGA-konfigurasjonen fra den funksjonelle modellen til enheten på systemnivå. Den mest populære tilnærmingen til å løse dette problemet er bruken av IP-kjerneteknologi (Intellectual Property Cores). IP-kjerner er ferdige komponenter som lar deg enkelt inkludere dem i ditt eget prosjekt for å lage et mer komplekst system. Denne tilnærmingen har en betydelig ulempe - vedlegget av IP-kjerner til den elementære basis. Hver IP-kjerne er optimalisert for en spesifikk serie brikker fra en spesifikk produsent, noe som i betydelig grad svekker muligheten for å overføre allerede opprettede enheter fra en elementbasis til en annen. Den lukkede naturen til kommersielle CAD-arkitekturer gjør det umulig å legge til dine egne funksjonelle enhetsmodeller på systemnivå for å få enhetsmodeller på registeroverføringsnivå (RTL) på grunnlag av dem. Utviklingen av en digital modul utføres i form av en digital krets tegnet i en kretseditor ved hjelp av produsentens innebygde CAD-bibliotek av grunnleggende kretselementer, som flip-flops, dekodere, tellere, addere, etc.

En annen populær tilnærming som tillater overgangen fra en funksjonell modell på systemnivå til en enhetsmodell på nivå med registeroverføringer, er bruken av systemnivådesignspråk (SLDL). Slike språk inkluderer SystemC, Handel-C, VHDL, Verilog, System Verilog. Den største fordelen er uavhengighet fra maskinvaregrunnlaget som enheten skal implementeres i.

På den ene siden, når du bruker IP-kjerneteknologien, mottar maskinvareutvikleren en løsning av høy kvalitet, men strengt knyttet til maskinvaregrunnlaget som enheten er implementert i. På den annen side, når du bruker maskinvarebeskrivelsesspråk på systemnivå, er enhetsimplementeringen maskinvareuavhengig. Av det foregående følger det at det for tiden er viktig å bruke felles bruk av digitale moduler i maskinvarebeskrivelsesspråket og IP-kjernene til produsenten (Xilinx, Altera, Actel, etc.) og tredjepartsutviklere for å øke hastigheten prosessen med å designe digitale moduler. Ved bruk av digitale moduler fra tredjepartsprodusenter er det noen ganger mangel på informasjon i den medfølgende dokumentasjonen.

Gir informasjon om den utviklede digitale modulen for FPGA

Avhengig av metodikken for å oppnå FPGA-konfigurasjonen i henhold til funksjonsmodellen til enheten på systemnivå, kan utvikleren skille mellom følgende typer digitale moduler for FPGA:

• Programvare - en utviklet digital modul, overført til forbrukeren i form av en beskrivelse i maskinvarebeskrivelsesspråket (VHDL, Verilog) eller/og utviklet i Schematic Editor for videre bruk i programmer for automatisert syntese av logiske kretser og optimalisert mht. funksjonelle parametere.
• Fastvare - en digital modul utviklet av et tredjepartsutviklerselskap, som kalles IP-kjernen, overført til forbrukeren i form av en logisk krets (nettliste) basert på logikkelementbiblioteket til FPGA-produsenten og optimalisert med tanke på funksjonalitet og elektriske parametere.

På stadiet av dokumentasjonsutvikling, basert på personlig erfaring, er det nødvendig å utstede, i tillegg til den vanlige designdokumentasjonen og spesifikasjonene, utført i samsvar med GOST 15.101, GOST 15.201, GOST 2.102, GOST 2.114, dokumentasjon for alle typer modeller (system, logikk, kretsløp) opprettet på stadiene av design av digitale enheter på FPGA-er.

Med andre ord bør settet med designdokumentasjon for en digital enhet for FPGA-er, i tillegg til fastvarefilen, programmeringsinstruksjoner og prosjektet registrert på CD/DVD, også inkludere medfølgende dokumentasjon.

Bord. Liste over støttedokumentasjonsseksjoner

Her er en liste over seksjoner (tabell) som bør inkluderes i den medfølgende dokumentasjonen av prosjektet til en digital modul for FPGAer. For hver seksjon vises tegn på behovet for å inkludere seksjonen i settet med dokumenter:

• "O" - obligatorisk levert del;
• "R" - seksjon anbefalt for levering.

Anbefalte filformater for å sende inn støttedokumentasjon er MS Word, PDF (beste format), HTML. Beskrivelsesfiler i maskinvarebeskrivelsesspråk (VHDL, Verilog) og/eller de som er utviklet i Schematic Editor leveres etter behov av CAD-designprogramvaren. Et unntak kan være tilleggsbestemmelsen i grafisk format (JPEG, BMP) av digitale kretsfiler utviklet i Schematic Editor.

Generell informasjon

Denne delen beskriver den generelle informasjonen om den utviklede digitale modulen i form av en beskrivelse:

• funksjonsdiagram og dets bestanddeler av blokker/deler;
• tilbakestille signaler, synkronisering;
• anvendte grensesnitt;
• kontrollregistre;
• timing diagram;
• programmering.

Formål og omfang

Formålet med den digitale modulen, omfanget av dens anvendelse bestemmes.

Spesifikasjoner

En beskrivelse av de viktigste tekniske egenskapene er gitt, for eksempel ytelse, strømforbruk for en bestemt FPGA-brikke, antall porter okkupert, typen FPGA-brikke som brukes. I tillegg er FPGA-produsenten brukt i utviklingen av den digitale CAD-modulen og programvaren som brukes til modellering og verifisering, angitt. For alle programmer som brukes, er versjon og installerte oppdateringer angitt. En grafisk representasjon av den digitale modulen i form av en "svart boks" med betegnelse på eksterne innganger / utganger er gitt og en kort beskrivelse av deres formål er gitt.

Beskrivelse av tilbakestillingssignaler

Detaljert informasjon om tilbakestillingssignaler er gitt:

• Liste over eksterne og interne tilbakestillingssignaler.
• Tidsparametere og tidsdiagrammer for tilbakestillingssignaler.
• Kretser for generering av interne tilbakestillingssignaler, hvis noen er inkludert i den digitale modulen.
• Relasjoner til andre signaler (spesielt synkroniseringssignaler).

Beskrivelse av synkroniseringssignaler

Detaljert informasjon om synkroniseringssignaler er gitt:

• beskrivelse av eksterne synkroniseringssignaler;
• tidsparametere for synkroniseringssignaler;
• beskrivelse av interne synkroniseringssignaler og skjemaer for deres dannelse;
• tidsforhold mellom synkroniseringssignaler fra forskjellige kilder;

Beskrivelse av grensesnitt

Funksjonene for bruk av alle grensesnitt som er en del av den utviklede digitale modulen, fortrinnsvis enhetlig for å organisere interaksjon med andre noder i systemet på en brikke, er gitt. I tillegg er det gitt en Internett-kobling til en fullstendig beskrivelse av standardgrensesnittet, eller beskrivelsen av selve grensesnittet. For øyeblikket aksepteres grensesnitt til AMBA, PLB, Wishbone-bussen som enhetlige grensesnitt for digitale moduler.

Tidsdiagrammer

Den nødvendige informasjonen er gitt for å organisere datautveksling gjennom grensesnitt og andre innganger/utganger til den digitale modulen: grafisk representasjon av tidsdiagrammer, beskrivelse av dataoverføringsprotokoller, krav til eksterne signaler påført den digitale modulen (varighet, frekvens, etc.) og annen informasjon.

Beskrivelse av kontrollregistre

En beskrivelse av alle kontrollregistrene til den digitale modulen er gitt. En typisk beskrivelse av kontrollregisteret inneholder navnet på registeret, adressen til registeret i det interne adresserommet, startverdien etter at tilbakestillingssignalet er fjernet, typen tilgang (lese / skrive), en beskrivelse av den interne Enger.

Strukturelt (funksjonelt) diagram

Et bilde av den interne strukturen til forbindelsene til de viktigste interne nodene / blokkene til den digitale modulen, samt deres korte tekstbeskrivelse er gitt. I tillegg er det gitt en beskrivelse av de viktigste interne blokkene til den digitale modulen. Formålet med dette dokumentet er å gi forbrukeren den informasjonen som er nødvendig for å forstå prinsippene for driften av den digitale modulen.

Antall beskrevne blokker og omfanget av beskrivelsen bestemmes av utvikleren av den digitale modulen. Fortrinnsvis tilsvarer minimumsantallet av beskrevne moduler antallet elementer i det strukturelle (funksjonelle) diagrammet til den digitale modulen.

En typisk beskrivelse av innendørsenheten inneholder:

• blokk tildeling;
• strukturelt (funksjonelt) blokkskjema (om nødvendig);
• driftsmoduser og algoritmer;
• tidsskjemaer for arbeid;
• organisering av enhetsledelse;
• organisering av kommunikasjon med andre enheter;
• annen informasjon.

Programmeringsveiledning

Gir all nødvendig informasjon om programmeringsprosessen ved å bruke CAD-en til produsenten av den digitale modulen i FPGA, de nødvendige verktøyene for utvikling og feilsøking av programvare og programvarebiblioteker.

FPGA-modell eller familie, produsent

For fastvare for en digital modul er FPGA-produsenten, FPGA-modellen eller -familien og dens hastighetsegenskaper angitt. For den digitale programvaremodulen er det gitt informasjon om hvor mye ressurser som er okkupert, kravene til den anvendte FPGA.

Representasjon av en digital modul for logikkdesign

Artikkelen diskuterte vanskelighetene med å bruke et «utenlandsk» prosjekt om VHDL – mangelen på passende retningslinjer for navngivning og skriving av programmer. Det ble også gitt generelle instruksjoner om navn, god oppførsel for å skrive programmer og retningslinjer for syntese. Disse problemene bør diskuteres så detaljert som mulig med utvikleren hvis du i fremtiden planlegger å fortsette å utvikle eller oppgradere på egen hånd før han begynner å utvikle RTL-modellen til den digitale modulen på FPGA. Dette gjelder spesielt for typen programvare digital modul på FPGA. Den samme delen av artikkelen beskriver de generelle kravene til hele prosjektet til den utviklede digitale modulen på FPGA. Her er problemstillingene du bør være oppmerksom på når du utarbeider mandat for utvikling av en digital modul på FPGA, og dette gjelder spesielt overføring av arbeidsresultater.

RTL-modell

En digital modul beskrevet i et syntetisert undersett av Verilog- eller VHDL-språket eller/og utviklet i Schematic Editor er beregnet for bruk på FPGA-logikksyntesestadiet. Leveres for programvare i form av et sammensatt prosjekt av en digital modul i CAD-systemet til FPGA-produsenten. For den digitale fastvaremodulen leveres RTL-modellen under en egen avtale.

I tillegg til RTL-modellfiler overføres følgende:

• Instruksjoner for bruk av modellen.
• Beskrivelse av minneblokkene som er inkludert i modellen, inkludert type minne, størrelse, antall minneblokker, hierarkisk navn på minneblokken.
• Beskriver hvordan du lager forhåndsbygde kjerner når du bruker programmer til å lage dem (for eksempel CoreGenerator for Xilinx ISE). I mangel av beskrivelser kan det være restriksjoner på redesign og bruk på grunn av teknologi og produsentavhengighet.
• Ved bruk av en mikroprosessor fra en produsent (for eksempel fra Altera - Nios-prosessor; fra Xilinx - Microblaze, PowerPC-mikroprosessorer), kreves en beskrivelse av prosessen med å konfigurere prosessorkjernen og dens periferi.
• Et sett med tester (Test Bench-filer) for å verifisere og simulere en digital modul skrevet i Verilog eller/og VHDL eller/og System Verilog.
• Eventuell annen tilleggsinformasjon.

Logisk modell

Modellen er en nettliste beskrevet ved bruk av Verilog- eller VHDL-språk i grunnlaget for FPGA-produsentens bibliotek og leveres for Digital Module Firmware.

I tillegg til de logiske modellfilene overføres følgende:

• Instruksjoner for bruk av denne modellen.
• Et sett med tester (Test Bench-filer) for å verifisere og simulere en digital modul skrevet i Verilog eller/og VHDL eller/og System Verilog.
• En veiledning for å arbeide med et sett med tester for modellering og verifisering av en digital modul.
• Eventuell annen tilleggsinformasjon.

Designgrenser

Designbegrensningene er gitt som en fil som beskriver et sett med begrensninger pålagt en digital modul når den er inkludert i system-on-chip logikkmodellen. Dette settet inkluderer begrensninger for synkroniseringssignaler (klokkebegrensninger), tidsbegrensninger (tidsbegrensninger), begrensninger på samspillet mellom den digitale modulen og andre moduler, og driftsforholdene til den digitale modulen. Synopsis Design Constraints (SDC) eller FPGA-produsentens CAD-format foretrekkes.

En eksempelliste over begrensninger for synkroniseringssignaler:

• tidsdiagram (klokkebølgeform);
• klokkefrekvens ustabilitet (Jitter);
• klokkefaseendring;
• varighet av byttetider (overgangstider);
• tidsdiagrammer for avledede klokkesignaler (genererte klokkebølgeformer);
• annen tilleggsinformasjon.

Et sett med begrensninger for synkroniseringssignaler er obligatorisk for programvare og fastvare for digitale moduler.

Eksempelliste over tidsbegrensninger:

• tidspunktet for forekomst av signaler ved inngangene (ankomsttider ved innganger);
• tidspunktet for opptreden av signaler ved utgangene (påkrevde tider ved utgangene);
• flersykkelveier;
• falske stier (Falske stier);
• varigheten av datasignalets overgangstider;
• annen tilleggsinformasjon.

Konklusjon

Den gitte sammensetningen av den medfølgende dokumentasjonen for de utviklede digitale modulene for FPGAer leveres etter avtale mellom forbruker og utvikler. Oftest gir utvikleren bare en digital modul, beskrevet i VHDL, Verilog, System Verilog og / eller utviklet i en skjematisk editor. Angående tilleggsdokumentasjon er utviklerens svar som oftest følgende: «Den digitale modulen fungerer, så ta den og bruk den. Det er ikke noe vanskelig å beskrive kretsen på maskinvarespråket: du vil finne ut av det selv."

Etter forfatterens mening kan du forstå hva som helst, alt avhenger av ønsket og tiden brukt, og tiden brukt på å forstå et "fremmed" prosjekt på en allerede utviklet digital modul er direkte proporsjonal med opplevelsen av å beskrive utstyr i VHDL, Verilog og kunnskap digital og mikroprosessor kretsløp. Dette kan unngås hvis du i utgangspunktet er enig med utvikleren om sammensetningen av den medfølgende dokumentasjonen, da blir bruken av den digitale modulen i prosjektet enklere, og implementeringen vil gå raskere.

Oppsummert vil forfatteren merke seg at når man formulerer en oppgave for utvikling av en digital enhet på en FPGA, bør man følge anbefalingene gitt i artikkelen, da vil det ikke være noen problemer ved gjenbruk eller oppgradering av en tidligere utviklet digital enhet.

Litteratur

1. Denisov A. Flere tips for utforming av digitale enheter på VHDL for FPGA // Komponenter og teknologier. 2009. Nr. 12.
2. GOST 2.102-68 ESKD. Typer og fullstendighet av designdokumenter.
3. GOST 2.114-95 ESKD. Spesifikasjoner.
4. GOST 15.101-98. System for utvikling og produksjon av produkter. Prosedyren for å utføre vitenskapelig forskningsarbeid.
5. GOST R 15.201-20-00. System for utvikling og produksjon av produkter. Produkter til industrielle og tekniske formål. Prosedyren for utvikling og produksjon av produkter.