Hallo zusammen, fuer eine bestehende Schaltung (B) mit einem FPGA und frei verfuegbaren 16 digitalen Ein- und Ausgaengen soll eine zweite Schaltung (A) mit spezieller Auswertelogik entwickelt werden, welche mittels einer Parallelschnittstelle mit der bestehenden Schaltung kommunizieren soll. Ich moechte also eine Parallelschnittstelle fuer eine Kommunikation zwischen zwei FPGAs entwickeln und habe dafuer pro Seite jeweils 16 Bit Eingaenge und 16 Bit Ausgaenge zur Verfuegung (siehe Schematik) Die Verbindung erfolgt ueber ein ca. 0,5 m langes geschirmtes 78-poliges Flachbandkabel, bei dem jede zweite Leitung auf Masse gelegt ist. Besonderes Augenmerk moechte ich auf eine hohe Uebertragungsrate legen (Takt bei 5 – 8 MHz). Nun zu meinen bisherigen Ueberlegungen: Da ich jeweils 16 Eingaenge und 16 Ausgaenge zur Verfuegung habe dachte ich, dass hier ein Vollduplex-Betrieb realisierbar ist: Bit-Nr. Signal-Bezeichnung Funktion/Bedeutung Bit 15 : Strobe Daten sind gueltig (valid) Bit 14 : Status 6 Status (ACK, NAK BUSY, ERR, etc) Bit 13 : Status 5 Status (ACK, NAK BUSY, ERR, etc) Bit 12 : Status 4 Status (ACK, NAK BUSY, ERR, etc) Bit 11 : Status 3 Status (ACK, NAK BUSY, ERR, etc) Bit 10 : Status 2 Status (ACK, NAK BUSY, ERR, etc) Bit 9 : Status 1 Status (ACK, NAK BUSY, ERR, etc) Bit 8 : Status 0 Status (ACK, NAK BUSY, ERR, etc) Bit 7 : Daten 7 Nutzdaten: Datenbit 7 Bit 6 : Daten 6 Nutzdaten: Datenbit 6 Bit 5 : Daten 5 Nutzdaten: Datenbit 5 Bit 4 : Daten 4 Nutzdaten: Datenbit 4 Bit 3 : Daten 3 Nutzdaten: Datenbit 3 Bit 2 : Daten 2 Nutzdaten: Datenbit 2 Bit 1 : Daten 1 Nutzdaten: Datenbit 1 Bit 0 : Daten 0 Nutzdaten: Datenbit 0 Mit jeder steigender Taktflanke von Strobe sollen also 8 Bit Nutzdaten (Bit 0 bis Bit 7) und 7 Bit Statusdaten (Bit 0 bis Bit 14) uebertragen werden. Wie ein beispielhafter Kommunikationsablauf im einzelnen aussehen soll habe ich graphisch im Anhang aufgezeigt. Empfangsseitig sollen dann die einzelnen Nutzdaten (Daten 0 bis Daten 7) in ein komplettes Telegramm zusammengesetzt werden. Etwa so: Frei Adressen Daten CRC | 8 Bit | 32 Bit | 32 Bit | 8 Bit | Nun meine Fragen: Habt ihr mir noch Tipps /Anregungen, was ich dringend beruecksichtigen sollte? Was ist fuer die Ausgangstreiber zu beachten? Welchen koennte man empfehlen? Bei der bestehenden Schaltung kann ich leider keine Aenderung vornehmen, es kann jedoch zur Signalanpassung je Port eine aktive Terminierung mit 110 Ohm zugeschalten werden. Ist die Leitungsfuehrung kritisch anzusehen, bzgl. der Laufzeiten? Vielen Dank schon mal, Shottky
Angehängte Dateien:
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.
FPGA-Pongo schrieb im Beitrag #4146462: > Was Du da bauen wilst, kann man sequenziell in ein > Protokoll packen und 3fach redundant per USB verschicken. Das ist zwar Unsinn (USB definiert z.B. auch den physical Layer und Du hast sowiesu nur eine Destination) aber in einem Punkt hat er schon recht: Bei 8MHz würde man eher eine serielle Übertragung (z.B. SPI) benutzen. Grüße Andreas
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,
Shottky schrieb: > Hättest du mir aber noch einen Link dazu? loool SCNR ... Da versteht jemand Ironie nicht ... Sowas soll's auch geben :)
Shottky schrieb: > 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. 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 ...
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.
Shottky schrieb: > 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. 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)
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.