Konvertera mellan FPGA-modeller - hur tänka gällandes IO?

[Illuwatar]

Jag skulle behöva lite hjälp i hur man tänker när det gäller IO-pinnarna på en FPGA. Jag är van vid att tänka "MCU" och har inga större problem att gå mellan olika modeller och märken. Men FPGA'er är fortfarande ett litet mysterium för mig trots Minimig-bygget.

Och det är just vad det handlar om - Minimig. Jag håller på med att ta fram en ny modell av denna där jag vill växla upp till en större FPGA. Själva kortet skall däremot krympas så mycket det bara går.

Så, tanken är att gå från en Spartan-# XC3S400-4PQ208 till en Spartan-3E XCS500-4PQ208. Den sistnämnda är den största Xilinx som går att handlöda (208 pinnars FPQ), därefter kommer det bara BGA.

Det jag måste då göra är att mappa om pinnarna på den mindre FPGAn till den större. Det jag inte vet är hur pass generella IO-pinnarna är och hur mycket som man kan påverka i "mjukvaran" (det blir till att kompilera om kärnan också förstås). Det jag kan se är att 3E-modellen har fyra banker jämtemot 3-modellens 8. I gengäld är antalet IO per bank mycket större på 3E. Tittar jag på Minimig-schemat så används alla pinnar med namn IO_någonting. Dessutom verkar det som en del av pinplaceringen beror på var benen sitter för att få layouten på kortet snyggt. Den större FPGAn har fler IO, så det är i alla fall ingen risk att de inte räcker.

Jag hoppas någon med FPGA-kunskaper har lite tid att förklara hur det fungerar - du behöver inte göra själva IO-mappningen, den fixar jag bara jag får tankegången förklarad på ett bra sätt.

[rehnmaak]

I princip behöver man bara ta hänsyn till att klockor ska in på de globala klockpinnarna. Sedan brukar jag undvika att använda konfigurationspinnarna till annat än konfigurering.

[RDX*]

Jag tittar också lite smått på XCS500E, men hur är det med de digitala differentiella pinnarna? Kan man använda p och n-pinnen var för sig eller måste man använda dom som ett par?

[rehnmaak]

Det går bra att köra diff-pinnarna var för sig.

[Andax]

Är du osäker kan du ju börja med att sätta upp projektet i ISE och definiera din UCF så som du tänkt dig och se om du kan syntetisera en bitfil med den valda pinouten.

[blueint]

Se till att ev klockor får GCLK linjerna.
Minimig använder i endast 3.3V LVTTL rakt vad jag vet. Så det är bara å möblera om efter behag. Se dock upp med "IP" pinnarna på Spartan-3E, då dom är dedikerade ingångar och inte kan driva något.
Konfigurationspinnar får man förstås låta bli. Och så se till att det är avkopplat ordentligt enligt pyramid modellen. Det är därför det finns så många spänningsmatningspinnar, så att transienter kan hanteras bra. Genom keramkapacitanser placerade inom ca 3 cm.

P-N differens är bara aktuellt att ta i beaktning när man använder differentiellt mode.

Ett sätt att skilja koden från den aktuella hårdvaran kan vara så här:

module top( pinne0, pinne1 );
input pinne0;
output pinne1;

projektet prj( .pinne0(pinne0), .pinne1(pinne1) );
endmodule

projektet( pinne0, pinne1);
input pinne0;
output pinne1;
..
endmodule

Så kan man ändra i top() så att man kan låta huvudfunktionen vara oförändrad.

Edit: exempel

[Illuwatar]

Får tacka för tipset Andax - att jag inte tänkte på detta...

Har nu suttit och mappat om alla pinnar till 500E och lyckats få den igenom ISE-kompileringen och fått fram en bin-fil. Så nu gäller det att få till själva kretskortet också.

Jag passade på att möblera om anslutningarna för RAM-delen då jag tänker skippa ursprungs-setupen med två 512k x 16 och ersätta dessa med en enda 1024k x 16 för att spara fysisk plats. För att få en enkel layout flyttade jag runt lite på FPGAns pinnar (de har sina fördelar dessa magiska kretsar). Synd bara att 500E måste ha dessa Input-only-pinnar - jag hade hellre sett riktig IO i stället på dessa också.

Edit: Utnyttjandegraden hos 500E av Minimig original:

Kod: Markera allt

Selected Device : 3s500epq208-4 

 Number of Slices:                    3032  out of   4656    65%  
 Number of Slice Flip Flops:          3050  out of   9312    32%  
 Number of 4 input LUTs:              4743  out of   9312    50%  
    Number used as logic:             4521
    Number used as Shift registers:     13
    Number used as RAMs:               209
 Number of IOs:                        135
 Number of bonded IOBs:                134  out of    158    84%  
 Number of BRAMs:                       12  out of     20    60%  
 Number of MULT18X18SIOs:                2  out of     20    10%  
 Number of GCLKs:                        3  out of     24    12%  
 Number of DCMs:                         1  out of      4    25%  

Alla IO-pinnar gick åt, det är bara ett antal IP (input only) kvar...

Frågan är om 68k-softcore som beskrivs på www.amiga.org får plats i 500E tillsammans med OCS-kärnan. I så fall skulle det bli många IO över (men då tar väl FPGAn slut i stället).

[Andax]

En förbättring som man skulle kunna göra om man har pinnar över är att koppla in ett minne till parallellt och försöka få till en framerate converter. Det börjar ju bli ont av skärmar som klarar synca på 50 Hz. Jag fick släpa fram min gamla CRT-monitor för att testa min minimig.

[Illuwatar]

En variant vore att dumpa analog RGB helt och köra ut LVDS eller DVI. Det skulle dock kräva att man lägger in en RGB->LVDS/DVI omvandlare i FPGAn. Dessutom ryker S-Video på köpet...

Andax - skulle man inte kunna tweaka Amber-modulen i FPGAn så den matar ut dubbla frames per bild (100Hz)? Fast det kanske inte hjälper, då 100Hz är för mycket för många TFT-skärmar. Idealet vore att få ut 60Hz VGA utan att behöva gå NTSC-linjen.

Quick Edit: någon som vet en _bra_ on-line kurs i Verilog. Känns som detta behövs...

[blueint]

TFT skärmar tar väl det mesta i vertikal refresh?

[Andax]

Illuwatar, det skulle ju gå att mata ut med dubbla frame-rate via en fix i amber. Dock behöver man ändå mellanlagra framen i ett minne för återläsning med dubbla hastigheten.
Nu används ju internt fpgaminne för att buffra en rad för dubbla horisontalraten men det minnet räcker ju inte vid dubblering av vertikalraten.
Att använda det befintliga minnet till en extra buffring går inte eftersom det inte går att klämma in tillräckligt många skriv och läs cykler tidsmässigt. Speciellt inte eftersom Dennis redan utnyttjar dubbla cykler för att kunna hantera fast-ram emuleringen.

Blueint, de flesta TFT-skärmar klarar sync ner till 56 Hz, vilket är märkligt tycker jag.

[denli]

Frågan är om 68k-softcore som beskrivs på www.amiga.org får plats i 500E tillsammans med OCS-kärnan. I så fall skulle det bli många IO över (men då tar väl FPGAn slut i stället).

Enligt Tobiflex tar TG68-koden i nuvarande form 70% av FPGA:n på Minimig 1.x (XC3S400).