Parallele Schnittstelle zwischen zwei FPGAs implementieren

Im Grossen und Ganzen hast Du richtig gedacht, aber es wird nicht 
funktionieren. Die Synthese wird sich partout weigern, für die 
"gewaltige" Datenrate von 8MHz einen FPGA zu erzeugen. Laut neuester 
EU-Verordnung dürfen FPGAs erst ab einer Bandbreite von wenigstens 
100Mbps eingesetzt werden. Darunter dürfen nur AVRs genutzt werden. 
Parallele Verbindungen sind erst ab 1Gbps erlaubt weil man darunter auch 
ETH machen kann.

Generell ist die Verschwendung von 8 Leitungen für vollkommen nutzlose 
strobe-Signale wie Du es machst, verboten.

Das war das Wort zum Freitag vom Pongo!

Mal im Ernst: Was Du da bauen wilst, kann man sequenziell in ein 
Protokoll packen und 3fach redundant per USB verschicken. Praktisch 
brauchst Du zwischen den FPGAs 2 serielle Busse mit 2 DIF-Leitungen - 
also nix full duplex, oder so. Das sind dann 4 Leitungen.

Seriell mit differentiellen Treiber (LVDS) wäre wohl wirklich das Mittel 
der Wahl, damit erreichst du gut die rund 100Mbps, die du anstrebst.

Wenn du es parallel implementieren willst: du verschenkst bei jedem 
Transfer die Hälfte der Bits. Nutze halb so viel Leitungen und 
transportiere nicht so viele X ;-)

Außerdem sehe ich keinen Takt, der den Datentransfer synchronisiert. 
Woher weiß denn das rechte FPGA, wann die Daten vom linken FPGA gerade 
umschalten? Am "Strobe" kann es das offensichtlich nicht festmachen, der 
ist in deinem Beispiel die ganze Zeit auf 1.

Hallo zusammen,

erst einmal vielen Dank für eure Antworten!

FPGA-Pongo schrieb im Beitrag #4146459:
> Im Grossen und Ganzen hast Du richtig gedacht, aber es wird nicht
> funktionieren. Die Synthese wird sich partout weigern, für die
> "gewaltige" Datenrate von 8MHz einen FPGA zu erzeugen.
Und wenn die Kommunikation in einem SoftCore realisiert wird?

> Laut neuester EU-Verordnung dürfen FPGAs erst ab einer Bandbreite von wenigstens
> 100Mbps eingesetzt werden. Darunter dürfen nur AVRs genutzt werden.
> Parallele Verbindungen sind erst ab 1Gbps erlaubt weil man darunter auch
> ETH machen kann.
Bei der Implementierung handelt es sich nicht um eine kommerzielle 
Entwicklung. Die Schnittstelle "werkelt" auch nur zwischen den beiden 
Schaltungen und ist nach außen nicht erreichbar.
Hättest du mir aber noch einen Link dazu?

Achim S. schrieb:
> Seriell mit differentiellen Treiber (LVDS) wäre wohl wirklich das Mittel
> der Wahl, damit erreichst du gut die rund 100Mbps, die du anstrebst.
Das Problem ist, dass ich die bestehende Schaltung (B) nicht 
schaltungstechnisch modifizieren kann. Hier sind lediglich umschaltbare 
(3,3V / 5V) digitale Eingänge bzw. Ausgänge mit optionaler aktiver 
Terminierung vorhanden.

Achim S. schrieb:
> Wenn du es parallel implementieren willst: du verschenkst bei jedem
> Transfer die Hälfte der Bits.
Ja das stimmt. Es könnte evtl. eine weitere Möglichkeit bestehen, in dem 
ich das Strobe-Signal über eine separate Leitung führe. Dann könnte man 
pro Strobe 16 Bit Nutzdaten übermitteln. Das muss ich noch prüfen.

Achim S. schrieb:
> Nutze halb so viel Leitungen und transportiere nicht so viele X ;-)
Auch eine Idee, aber ich habe exakt 16 Ein- und 16 Ausgänge zur freien 
Verfügung. Also kann ich auf jeden Fall alle Leitungen beanspruchen. 
Dadurch hätte ich auch noch eine gewisse Reserve.

Achim S. schrieb:
> Außerdem sehe ich keinen Takt, der den Datentransfer synchronisiert.
> Woher weiß denn das rechte FPGA, wann die Daten vom linken FPGA gerade
> umschalten? Am "Strobe" kann es das offensichtlich nicht festmachen, der
> ist in deinem Beispiel die ganze Zeit auf 1.
Ja du hast Recht, das habe ich nicht exakt im "Kommunikations_Ablauf" 
skizziert. Der Datentransfer soll über Strobe synchronisiert werden: 
Daten u. Status (Bit 0 – Bit 14) sollen angelegt werden. Danach wird für 
einen Taktzyklus Strobe angelegt, um die Daten bei Flankenwechsel zu 
übernehmen.

 

Moin,

Hallo Shottky, schicke mal deinen Ironiedetektor ins Kalibrierlabor. Der 
muss mal wieder richtig eingestellt werden :)



Grüße,

Mampf F. schrieb:
> Was mich ja noch interessiert hätte ... Wie weit sind die FPGAs räumlich
> denn voneinander getrennt?
>
> Wundert mich, dass da bisher noch niemand gefragt hat ...

Weil es schon im Eingangspost steht.

nicht"Gast" schrieb:
> Hallo Shottky, schicke mal deinen Ironiedetektor ins Kalibrierlabor. Der
> muss mal wieder richtig eingestellt werden :)
oh man...
kalibriert.

Mampf F. schrieb:
> Was mich ja noch interessiert hätte ... Wie weit sind die FPGAs räumlich
> denn voneinander getrennt?
Die Verbindung erfolgt ueber ein ca. 0,5 m langes geschirmtes 78-poliges
Flachbandkabel, bei dem jede zweite Leitung auf Masse gelegt ist.

Mampf F. schrieb:
> Mmhmmm ... ihr verwendet aber kein fertiges ATA100-Flachbandkabel dafür,
> oder? (Die 80pol Flachbandkabel, die es für die 100MHz IDE-Schnittstelle
> gab und auch immer jeden 2ten Pin Masse hatten)
Das hier soll verwendet werden:
http://www.meilhaus.de/me-ak-d78,i6.htm

Uber sowass kricht man noch 27MBAUD LVTTL hinweg, aber 100MBAUD kann man 
sicherlich vergessen. Klartext: 5 ... 8 MBAUD kein problem mit richtige 
terminirung aber 25% der verfugbaren bandbreite is dan auch wohl 
beansprucht (soweit zum thema ironie). 110 ohm serielle terminierung 
scheint mir zuviel, wenn es wirklich 0.1 zoll flachband kabel ist dann 
is die impedanz einzele leiter 95...115 ohm. Davon muss die treiber 
ausgangimpedanz hinabgezogen werden (50 ohm?) bleiben 65 ohm fur 
serielle abschluss vorzugsweise beim treiber, aber an empfangerseite ist 
auch moglich.

ich wurde fur die 16 bits (in einer richtung) 1 STROBE, 1ACK, und 14 
DATA
gebruachen. protocol: (1) warte bis ACK='0', (2) set DATA, (3) setup 
delay (4) STROBE='1', (5) daten lesen, (6) ACK='1', (7) STROBE='0', 
usw...

Dann kan mann beim debuggen (mit logicanalyzer) genau sehen wann data 
angeboten und gelesen sind.

Zum thema datenbreitte: die 14 bits koenen 14*K daten sein, aber dann 
ist die "framing" (was ist der anfang denn von die 14K) ein mogliches 
problem.

vielleicht ist 14-bit instructionen mit embedded data eine einfache 
loesung? zb:
<6-bit instruction>,<8-bit data>
damit kannst du auch dein "Telegram" mit lesen/schreiben, und actieveren

Das Kabel scheint mir nicht ideal für diese Anwendung. Muss es das 
unbedingt sein?

Frage in die Runde: Welche anderen Verbindungen wären hier zu 
bevorzugen? Ich habe kürzlich Cameralink gemacht. Das Kabel ist sehr 
gut, man kann ein Vielfaches der benötigten Bandbreite. Allerdings ist 
es schweineteuer, da speziell.

Noch zum Thema "Masse"

Die Massen vom Kabel muessen am Treiber und Empfanger Seite gut 
angeschlossen sein. Am besten fur jedes Signal auch eine eigene Masse, 
sonnst gibts SSO aerger (SSO = Simultaneous Switching Outputs). Dass 
bemerkt man beim testen: wenn mehre Signale alle gleichtzeitig '1' 
werden. (oder all '0') gibts data errors.

Ohne gute Masse, und sowieso wenn's EMC arm sein muss (warum ist das 
Kabel denn abgeschirmt???), dann kannst Du anstat 16 bits signale, auch 
einfach 8 bits signale gebrauchen wobei jedes Bit ein Inverse hat. Am 
besten am Emfaengerseite mit 150 ohm pro bit terminiert wenn twisted 
pair kabel pro bit, oder 110 ohm pro bit bei verwendung von "normales" 
parallel kabel. Auch ohne Terminierung am Empfaengerseite ist es noch 
immer besser (pseudo-)differentiel zu arbeiten, da die Summe von allen 
Stroeme in einer Stelle gleich 0 ist. Damit sind SSO und EMC Probleme 
auch minimal.