FPGA cluster, noen med erfaring?

[Melkekartong]

Hei!

 

Har smått om sen begynt å interessere meg for kryptografi, deriblant også knekking av koder. Tenkte på (lang) sikt å bygge en FPGA cluster, noe lignende som feks copacobana.

 

Bare å bygge/lodde kretskortet ser ut ut til å være et rent helvete, for ikke å snakke om programmeringen! På tross av dette lurer jeg på om noen av dere har tips til hvor man begynner en slik ferd? Har litt erfaringer innen elektronikk, programmering og mikrokontrollere fra tidligere.

 

Det er mye info å ta til seg via google, men hadde vært greit å komme i kontakt med noen som faktisk har greie på dette :-)

[Dr_VingTor]

Å lodde opp noe slikt du linker til for hånd trur jeg du kan glemme med mindre du har veldig fancy loddeutstyr tilgjengelig... Tipper en der vil slite med å rette dårlige loddinger og ende opp med å kaste bort mange penger (håndlodding av BGA pakker er ikke enkelt, krever litt utstyr, samt at selve kretskort designet er vanskelig(ere)).

 

Trur jeg ville satset på ferdige små FPGA kits som kan kobles sammen, starte med et og få noe kryptering til å fungere på det, så eventuelt utvide med flere kits. Har selv gjort RSA kryptering på en FPGA i et fag jeg tok på NTNU, men vil ikke påstå at jeg er flink på kryptografi av den grunn (men kjenner til noe av problemstillingene du kanskje vil ha).

 

Et kort som kan være interessant er kanskje dette: http://papilio.cc/index.php?n=Papilio.Papilio men finnes mange andre som kan være godt egnet. Selv har jeg et Altera DE1 FPGA kort, men kan ikke si at det blir mye brukt.

[Melkekartong]

Okai Skal sjekke ut.

 

 

Ifht lodding har jeg en del utstyr, blant annet reflow ovn, varmluftsloddestasjon etc tilgjengelig.

Kretskort får jeg etset, feks gjennom batchpcb.com

Endret 26. juli 2011 av Melkekartong

[kurrant]

Jeg ville først kjøpt meg et utviklingskortog jobbet med algoritmene på en enkelt FPGA, for å få kontroll på dette. Når dette er på plass, er det eventuelt mulig å utvide med en cluster, men i den sammenheng er det jo interessant å spørre hvilket budsjett du har.

 

Før du i det hele tatt bør tenke på cluster, er det mye lettere å kjøre en enkelt veldig kraftig FPGA, for eksempel xilinx virtex 6. Disse koster imidlertid rundt 15000 kroner stykket, uten at jeg har sjekket nøyaktig.

 

Hvis du har mye penger, tid, og god kompetanse på PCB-layout og generell elektronikk, er det mulig en clusterløsning er noe å gå etter. Du bør imidlertid være klar over at kretskort for flere høyhastighets-FPGAer er langt ifra en triviell ting hverken å designe, produsere, eller montere.

 

Det er mulig å montere BGA-kretser i reflow-ovn, men det kan ta litt prøving og feiling for å få riktig temperaturprofil. Det kan også bli vanskelig å verifisere at alle loddingene er i orden.

[Melkekartong]

Hovedmålet mitt med denne tråden er først og fremst å finne ut hvor realistiske mål jeg bør sette meg, både med tanke på økonomi, tidsbruk, krav til kompetanse, forskjellige teknikker etc.

 

Jeg er student, så budsjettet kan være noe begrenset, men om dette er noe jeg får dreisen på kan det være noe jeg over tid vil kunne være villig til å bruke en god slump penger på. Det kan også være at jeg inviterer andre til å delta i ei prosjektgruppe og at vi da forsøker å få tak i sponsormidler.

 

Grunnen til at jeg først og fremst tenker cluster er at jeg da tilegner meg kompetansen for å kunne utvide "etter behov", samtidig som jeg sakte, men sikkert kan utvide kapasiteten. Som nybegynner tror jeg det fort kan bli at en FPGA til 16000 støver ned på hylla. I så fall er det greit å heller ha kjøpt inn en drøss med billige FPGAer som ikke nødvendigvis har kostet like mye.. Samtidig er det greit å kunne ha friheten til å prøve/feile. En plan på sikt kan derfor være å utvikle et solid rammeverk for en clusterordning og deretter utvide ettersom økonomien tillater det.

 

 

kurrant, du nevner utfordringen i å designe kretskort for flere høyhastighetsFPGAer. Er dette med tanke på kvaliteten på kretskortet (for mye/lite etset bort) eller støy/frekvenser som på høyfrekvente radiokort? Eller at det simpelthen blir et rent helvete å lage et fornuftig rammeverk for det hele når feks 100 FPGAer skal kunne jobbe sammen, kommunisere med PC ++?

[Dr_VingTor]

kurrant, du nevner utfordringen i å designe kretskort for flere høyhastighetsFPGAer. Er dette med tanke på kvaliteten på kretskortet (for mye/lite etset bort) eller støy/frekvenser som på høyfrekvente radiokort? Eller at det simpelthen blir et rent helvete å lage et fornuftig rammeverk for det hele når feks 100 FPGAer skal kunne jobbe sammen, kommunisere med PC ++?

 

Har du laget kretskort før? Har du kunnskap om signal overføring? Inngangs- og utgangs-impedans, og hvordan få dette til å stemme overens med impedans på baner du lager på kretskort? Bølgeforplantning og refleksjoner? Dette er nok noe av det du bør ha litt kunnskaper om når det kommer til et slikt design. Et digital signal er ikke et digital signal når banene blir over en viss lengde, og når du snakker om å lage en cluster, så vil jeg anta at banene fort blir lange.

Bare se på et hovedkort for en PC, og se hvordan banene er rutet, der kan du se at de ofte snirkler seg fram og tilbake for å få rett lengde osv...

 

Du nevner høyfrekvente kort, slik som for radio, men å ta utgangspunkt i frekvensen på et signal kan i mange tilfeller være veldig feil. Det du bør ta utgangspunkt i er hvor raskt et signal endres (slewrate), altså hvor bratte flankene er på det digitale signalet. Hvor bratt flanken er vil være avgjørende for de faktiske frekvenskomponentene i signalet (tenk Fourier transform av firkant puls), og dermed være med på å bestemme hvor lang en bane på et kretskort kan være før impedans mismatch får stor betydning. Altså hvor lang en bane kan være før den må behandles som en transmisjonlinje. Denne lengen kan være under 10cm. Nå om du har en parallell data buss du skal lage, så vil du også ha problemer med meta-stabilitet (også ellers, men mye verre her), og for å sørge for at klokkeflanken kommer på rett tidspunkt i forhold til data. Bare på grunn av dette vil jeg nok ha brukt en seriell kommunikasjon mellom FPGAene, fortrinnsvis LVDS hvis du skal overføre mye data, noe som setter store krav til kretskort design. Ser du på nye hovedkort og hvordan PCI express er rutet, så gir det en indikasjon.

 

Her er linker til noe du bør se litt på:

http://www.altera.com/technology/signal/board-design-guidelines/sgl-bdg-index.html

http://www.altera.com/literature/hb/stx2/stx2_sii52012.pdf

http://www.altera.com/literature/an/archives/an075.pdf

http://www.altera.com/literature/an/an315.pdf

http://focus.ti.com/lit/an/scaa082/scaa082.pdf

 

I bunn og grunn så har Altera, TI, og Xilinx mange gode dokumenter som beskriver hvordan et godt kretskort lages, mye mulig de har guidelines for de forskjellige FPGAene også. Absolutt et must å sjekke ut.

 

Du bør nok også lese litt på diverse synkronisering logikk for å implementere på FPGAene da du må håndtere meta-stabilitet på et eller annet tidspunkt. Jeg implementerte et enkelt SPI interface på en FPGA for kommunikasjon med en AVR, og alt der er dette noe du må ha full kontroll på.

 

Ikke for så skremme deg bor fra dette altså, kult prosjekt om du har noe å bruke det til, men kretskort designene blir fort en like stor oppgave som resten.

[Melkekartong]

Jeg har laget kretskort før, men har aldri tatt hensyn til slikt. Det har funka og da har jeg vært fornøyd Though det ikke har vært noen særlig kompliserte kretser og om jeg begir meg ut på et eventyr så blir det ei bratt lærekurve.

 

Har raskt sjekket linkene dine og de gir mening, så det er noe jeg skal sette meg nærmere inn i Er nok greit å gjøre det ordentlig hvis dette blir noe jeg investerer noe penger i :-)

 

Tankene jeg har i hodet mtp synkronsiering er mye som de har tenkt på copacobana. Programmere alle FPGAer i ett, dele ut arbeidsområde til hver prosessor og deretter polle hver enkelt i et valgt intervall.

[asicman]

Dersom du ikke har mye erfaring med HDL språk, FPGA'er og implementasjon av krypteringsalogritmer i FPGA/ASIC eller et sterkt ønske om å gjøre et PCB nivå design så mener jeg du begynner i helt feil ende.

 

Dersom du ønsker å utforske algoritmer og FPGA implementasjoner bør du starte med utforsking av disse i Matlab o.l. og deretter simulering av disse i HDL. Dersom du ikke kan SystemVerilog og/eller VHDL bør du også lære deg dette i hovedsak via simulering. Du bør også sette deg inn i verktøyene til FPGA leverandørene underveis, f.eks. Quartus fra Altera, ISE/PlanAhead fra Xilinx osv. så du kan teste implementasjonen din underveis for timing problemer o.l.

 

Når du får en formening av hvordan arkitekturen din ser ut, kan du begynne å tenke på implementasjon. Forhåpentligvis kommer du opp med en skalerbar arkitektur. Når du forstår hva denne krever av FPGA og andre hardware ressurser kan begynne å tenke på å lage kretskort. Men først ville jeg gjort som «kurrant» sier. Kjøpt et utvikler kort som har mest mulig hardware ressurser som du planlegger å bruke i ditt design. Bruk dette til å gå opp løypa. Du kan da teste en mindre del av designet ditt på et billig utviklerkort med liten FPGA så kan du se om det er mest hensiktsmessig å skalere det opp til en stor FPGA eller lage et PCB design med mange FPGA'er. Typisk vil det være billigere å kjøpe noe ferdig framfor å lage det selv hvis du bare skal ha noen få. Antatt at du får noe som passer for ditt bruk.

 

Hvordan får du data? Fra PCIe, SATA, Ethernet, USB, osv? Hvor mye minne trenger du? Hvordan fordeles dette hvis du trenger å bruke flere FPGA'er? Dersom du skal bruke flere FPGA'er hvordan skal disse kommunisere? Hvor følsom er algoritmen og implementasjonen din for latency? Er det en systolic array implementasjon? Felles klokkedomene? Kanskje du bør bruke en source synchronous interface mellom FPGA'ene. Eller har latency mindre å si og du trenger høy båndbredde mellom FPGA'ene? Da bør du kanskje heller bruke SERDES'ene i FPGA'ene. Trenger du en fairness protokoll? osv. osv.

 

Mange av disse spørsmålene bør du finne ut av lenge før du lager PCB, helst via simulering siden du har full observerbarhet av designet ditt under simulering. Du bør også lage deg flere testbenker underveis som verifiserer at designet ditt er funksjonelt korrekt. Disse bør du sørge for at er selvsjekkende (evt. at de sjekkes i mot Matlab simueringene dine) slik at de kan kjøres når som helst for å verfisere at du ikke har ødelagt noe eksiterende funksjonalitet etterhvert som designet utvikler seg.

 

Hvis du ikke har gjort PCB design av DDR3 interfacer og høyhastighets SERDES interfacer som PCIe o.l. så kan det være en stor utfordning i seg selv som ofte innebærer analog SPICE simulering o.l. Det å designe strømforsyning til disse kretsene krever også en del kunnskap. Hvis du ikke har denne kunnskapen kan det ofte være enklest å starte med en kopi av refereranse-designet til FPGA leverandørene. Når du kjøper et uviklerkort får du vanligvis med skjema og PCB database (verktøyavhengig, ofte OrCAD) som du kan ta utgangspunkt i.

Endret 1. august 2011 av asicman

[Dr_VingTor]

Tankene jeg har i hodet mtp synkronsiering er mye som de har tenkt på copacobana. Programmere alle FPGAer i ett, dele ut arbeidsområde til hver prosessor og deretter polle hver enkelt i et valgt intervall.

 

Ok, men var ikke det jeg tenkte på...

 

Du må tenke på hvordan klokkesystemet ditt er. Har du en felles klokkekilde for alle FPGAene, eller har hver FPGA sin lokale klokke kilde? Uansett hva du velger her vil du potensielt støte på meta-stabilitets problemer som må løses. Slike problemer er veldig vanskelig å se i RTL simulering, så du må bare vite at du kan ha meta-stabilitet på gitte steder og designe for å håndtere dette.

http://w2.cadence.com/whitepapers/cdc_wp.pdf

http://www.gstitt.ece.ufl.edu/courses/eel4712/lectures/metastability/276202.pdf

http://www.fpga4fun.com/CrossClockDomain.html

 

Søk litt på "Clock domain crossing", eventuelt less på timing generelt.

[asicman]

Akkurat. Det var derfor jeg spurte om han hadde felles klokkedomene eller ikke. Har han DDR3 osv. så har disse vanligvis egne klokkedomener. Det er flere dokumenterte metoder for å redusere sannsynligheten for meta-tilstander (dobbeltklokking av register, synkronisering o.l.) men han vil sannsynligvis trenge en flow-control kontroll protokoll (FIFO, back-pressure) på arkitekturnivå også for å ungå overrun/underrun som følge av forskjellige hastigheter på producer/consumer.

 

Der er riktig at man ikke kan simulere meta tilstander og klokke domene kryssing i RTL simulering, men det finnes lint type verktøy for å hjelpe til å kjenne igjen disse som f.eks. Spyglass. Mange EDA verktøy er dyre, men det kan være at han kan få tilgang til disse via universitetet hvor han studerer.

[Jee]

Jeg vet at dere to, hvertfal du Dr_VingTor har god greie på kretskortutlegg. Selv så skal jeg nå lære meg dette skikkelig. Vet dere om noen bøker, eventuelt noen artikler på nettet som dere kan anbefale meg? Jeg ser at du Dr_VingTor har henvist til noen linker, men jeg vil gjerne forsikre meg om at dette er godt nok for meg, før jeg pløyer igjennom alle sidene. Jeg skal være med på å lage kretskortutlegg til et embedded system, så jeg har noe å lære meg.

[Jee]

Leser igjennom pdfene som er henvist til, er mye nyttig aa finne der

[Thomas_st]

Du kan jo også ta en tur til EEVblog, video #193 ser spesielt relevant ut. Har ikke sett akkurat den selv, men har sett en del andre videoer der - informativt og underholdende. David L. Jones er en flink fyr

Forumet der er også bra, noen har skikkelig peiling.

[asicman]

Jee: Kanskje du burde starte en ny tråd om kretskortutlegg? Du får sikkert bedre svar og kommentarer om du forsøker å presisere hva du ønsker å lære og kanskje litt mer om hva slags kort du ønsker å legge ut og hva slags hastigheter og type interfacer det er snakk om.