Ist ein massiv paralleler Datenbus im FPGA sinnvoll?

Klaus schrieb:

> ich habe hier 4 ADC mit 16 Bit und je 1MSample Datenrate. Die Daten
> sollen durch einen FPGA verarbeitet werden. Filtern, Mischen, teilweise
> FFT.

> FPGA (Spartan 6)

PCB oder Kabel? Taktfrequenz auf dem Parallelbus? Länge?

Zu erwartende Problem sind Übersprechen und zeitlicher Signalversatz 
zwischen den Einzelleitungen (skew). Bei einem Msample sollte das aber 
beherrschbar sein. Bei der dimensionierung der Stütz-C an den FPGA-Pins 
spielt die Anzahl gleichzeitig schaltender Ausgänge eine Rolle. Aber 1 
MHz sollte kein Problem sein. Zum Vergleich: der alte PCI 1,0 von 1991 
läuft mit 33MHz und 32 parallenen Daten/Adresse.

MfG,

Fpga Kuechle schrieb:
> PCB oder Kabel? Taktfrequenz auf dem Parallelbus? Länge?

Im FPGA ein Kabel ziehen???

mar IO schrieb:
> Fpga Kuechle schrieb:
>> PCB oder Kabel? Taktfrequenz auf dem Parallelbus? Länge?
>
> Im FPGA ein Kabel ziehen???

Nein, zwischen FPGA-(Board) und ADC-(board)

MfG,

Klaus schrieb:
> Filtern, Mischen, teilweise
> FFT.
>
> Ist des sinnvoll die Daten im FPGA seriell zwischen den einzelnen
> Einheiten zu übertragen?

Wenn du deine 4 ADC-Daten sauber in deine 'Einheiten' nacheinander 
fuettern kannst, dann brauchst du auch nur ca. 1/4 der Logik im FPGA. 
Wenn du viel Platz hast kannst du natuerlich auch alles 4x einbauen und 
brauchst keine Synchronisierung.
Probier's doch einfach aus, ist doch nur ein bisschen umverdrahten und 
instantiieren im top-level...

Fpga Kuechle schrieb:
> mar IO schrieb:
>> Fpga Kuechle schrieb:
>>> PCB oder Kabel? Taktfrequenz auf dem Parallelbus? Länge?
>>
>> Im FPGA ein Kabel ziehen???
>
> Nein, zwischen FPGA-(Board) und ADC-(board)
>
> MfG,

Habe ich etwas anders verstanden.

Der FX3 hat einen 16 bzw. 32bit breiten Datenbus. >> ergo das geht gut

Ich hatte mal ein Spartan3 Projekt mit 6 RAM-Bänken à 16bit Daten + 
24Bit Adressen + Steuerleitungen. Alles parallel. Machte in Summe über 
256 Leitungen und lief einwandfrei mit 66MHz.

Wichtig dabei war:
1. Zusammengehörende Signale (z.B. alle Bits eines Datenbus) in den 
gleichen IOB packen, sonst wird das Laufzeitverhalten im FPGA 
suboptimal.
2. Leiterbahnlängen gleich lang halten.

> 1. Zusammengehörende Signale (z.B. alle Bits eines Datenbus) in den
> ,gleichen IOB packen

In einem IOB passt nur ein bit, gemeint ist wohl eher gleiche io_Bank. 
Xilinx empfiehlt einen lauf ohne Location constraint, da sich der placer 
dann die pins schon optimal raussucht. danach das PCB designen.

MfG

Falk Brunner schrieb:
> Reseven sind schön und gut, Übertreibung nur selten

Reserven bedeuted: Man weiss recht gut was man tut und baut sich noch 
etwas Luft ein (==Angstfaktor). Uebertreibung bedeuted in aller Regel: 
Ich spezifiziere einfach mal das Maximum; sollen sich andere damit 
rumschlagen...

Falk hat recht. Reserven kann einen Board Respin bedeuten, aber dann 
weisst du auch warum und wieso. Uebertreibung kann bedeuten: Es 
funktioniert, aber ich weiss nicht warum

Christoph Z. schrieb:
> berndl schrieb:
>> Reserven bedeuted: Man weiss recht gut was man tut und baut sich noch
>> etwas Luft ein (==Angstfaktor). Uebertreibung bedeuted in aller Regel:
>> Ich spezifiziere einfach mal das Maximum; sollen sich andere damit
>> rumschlagen...


Nunja hier (Spartan-6) hat man durch die IO-delay elemente einige 
reserven im FPGA mit denen man PCB-Längenunterschiede ausgleichen kann. 
Also Nix mit zwangsläufig nötigen PCB-Respin.
http://www.xilinx.com/support/documentation/user_guides/ug381.pdf S.70

So ist das halt mit den Angstfaktor: Vor lauter panik schätzt man seine 
Freiheitsgrade geringer ein und eröffnet auf neuen Teilgebieten 
Materialschlachten nur weil man sich dort ein wenig besser auskennt.

MfG,

Falk Brunner schrieb:
> Da es sowieso getaktet ist kann man problemlos FlipFlips in den IOBs
> nutzen, sowohl rein als auch raus, was das Timing total relaxt.

Oh ja, das sollte man tunlichst machen (heisst beim Spartan glaub ich 
"Pack IOB").
Das war auch eine Lektion, die ich auf die ganz harte Tour lernen mußte 
;)

KennIch schrieb:
> Nunja hier (Spartan-6) hat man durch die IO-delay elemente einige
> reserven im FPGA mit denen man PCB-Längenunterschiede ausgleichen kann.
> Also Nix mit zwangsläufig nötigen PCB-Respin.

naja, es geht ja nicht nur um z.B. Laufzeiten externer Signale. Es geht 
auch um so sachen wie z.B. Spannungsversorgung (Leistung und Sequence 
beim einschalten), DeCaps, Pads fuer Signale von denen man nicht so 
genau weiss ob man sie jetzt braucht. Evtl. einen Absatz in den gefuehlt 
tausenden von Seiten Dokumentation uebersehen und dein Board tut halt 
nicht. Und dann faengt der Aerger richtig an...

Und einfach funktionierende Eval-Board Schaltungen zu uebernehmen ist 
halt sehr oft ueber's Ziel hinaus geschossen und damit teuer.