mikrocontroller.net

Forum: FPGA, VHDL & Co. Verbindung zwischen mehreren Spartan3 Boards


Autor: Erik E. (ikendes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin leider nur Informatiker und habe von echter Hardware nur wenig 
Ahnung, daher hier meine Frage:

Für mein Studium muss ich mehrere FPGAs miteinander verbinden, um ein 
Busprotokoll zu testen. Zur Verfügung stehen mir mehrere AVNET Spartan 3 
Development Boards: 
http://www.em.avnet.com/ctf_shared/evk/df2df2usa/S...

Ich habe im Internet schon einiges gefunden: Von der gehelfsmäßigen 
Umfunktionierung des RS232 Interfaces für mehr als 2 Geräte, der 
optischen Übertragung mittels LEDs und Sensoren, bis zu in den FPGAs 
integrierten PULLUPs mit Open Drain Anschlüssen, ...
Ein ähnliches Problem (I2C) ist hier im Forum auch schon des öfteren 
beschrieben, allerdings auf einem für mich noch zu hohem Level.
Das ganze sollte möglichst sicher zu bauen sein, so dass selbst bei 
einer falschen Konfiguration der Businterface kein Schaden an den Boards 
entsteht. Ausserdem so störsicher, dass keine Fehlerkorrektur im 
Protokoll notwendig wird. Um 3-4 Boards zu verbinden wird eine 
Gesamtlänge von min. 0,5m benötigt.

Und nochmals kurz:
Wie sieht die Realisierung der Hardware eines Busses zwischen mehreren 
FPGA Boards aus?

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und nochmals kurz: Wie sieht die Realisierung der Hardware eines Busses
> zwischen mehreren FPGA Boards aus?
Wie schnell sollen die Daten übertragen werden?

Autor: Erik E. (ikendes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Businterface läuft veraussichtlich mit max. 16,5MHz, aber die Daten 
werden für das Oversampling auf der anderen Seite jeweils 8 Takte 
gehalten, sprich sie werden effektiv mit ca. 2MHz versendet.

Aber diese Werte kann ich ja nach belieben wählen, sollten nur nicht zu 
langsam werden.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Erik E. (ikendes)

>Das Businterface läuft veraussichtlich mit max. 16,5MHz, aber die Daten
>werden für das Oversampling auf der anderen Seite jeweils 8 Takte
>gehalten, sprich sie werden effektiv mit ca. 2MHz versendet.

So ein Unsinn.

>Aber diese Werte kann ich ja nach belieben wählen, sollten nur nicht zu
>langsam werden.

Unsinn die 2.

Mach mal ne ordentliche Aussage zu Takten, Datendurchsatz, Busbreite, 
Maste/Slave etc. oder vergiss es und bleib bei deiner Software.

MFG
Falk

Autor: Erik E. (ikendes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also:

Das gesamte Design wird mit einer 66 MHz Clock betrieben.
Allerdings ist dies würd den von mir geschriebenen Prozessorkern etwas 
zu schnell, daher wird dieser per DCM mit clk/4 betrieben, was nach 
meiner Rechnung zu einem Takt von 16,5 MHz führt.
Dieses Takt schafft das Businterface auch, daher hatte ich geschrieben:

Max. 16,5 MHz.

Das Busprotokoll hält allerdings jedes Bit 8 Takte lang auf dem Bus. 
Daher werden die Daten effektiv mit max. 16,5 / 8 = 2,0625 MHz auf den 
Bus gelegt. Daraus ergibt sich eine ungefähre Datenrate von MAXIMAL 
2MBit/s.
Dies ist allerdings ein Maximalwert, der durch den Prozessorkern 
vorgegeben wird. Sollte dies absolut zu schnell sein, kann ich das 
System auch mit jedem beliebigen Takt betreiben.
Leider hilft mir der Hinweis "Unsinn" nicht wirklich weiter. Der Grund 
warum dies Unsinn ist, hätte mir deutlich mehr geholfen.

Busbreite: Ganz klar mein Fehler hatte ich oben vergessen: Es handelt 
sich um einen seriellen Bus. Sprich: eine einzige Leitung.
An dieser Stelle taucht dann natürlich auch die Fragen auf: In wie weit 
muss ich eine GND Leitung dazulegen? Bei der optischen Übertragung 
natürlich nicht, bei der Beschaltung als Wired-And vermutlich schon. Das 
ist aber wieder ein Punkt an dem ich auf Hilfe hoffe. Abgschirmtes 
Kabel? Wie schon gesagt: Bin leider nur Informatiker und habe von 
Elektronik leidlich wenig Ahnung.

Master/Slave gibt es nicht, da es sich um eine synchrone zeitgesteuerte 
Übertragung handelt. Sprich: Die unterschiedlichen Geräte 
synchronisieren sich miteinander und bekommen jeweils ein festes 
Zeitfenster, in dem sie Daten übertragen dürfen. Lediglich für diese 
Synchronisierung dient ein Chip als Zeitgeber, auf den sich die anderen 
synchronisieren.

Und nein, ich mache Informatik, aber schreibe keine Software. Ich 
schreibe einen eigenen Prozessorkern, Businterface,...
Bei Testen bekomme ich dann allerdings ein Problem. Kann ich bei 2 FPGA 
Boards noch locker den vorhandenen RS232 Anschluss mit einem 
Nullmodemkabeln nutzen, geht dies bei der Verbindung von mehr als 2 
Board nur noch regelwidrig, da dazu die logische Null nicht mehr durch 
-5V sondern durch 0V dargestellt wird. Dies ist für einen Testaufbau 
leider nicht akzeptabel.

Um es nochmals deutlich zu machen, hatte ich hier eher auf einen Tip 
wie:

Beschalte einen 1. Pin als PULL UP.
Beschalte einen 2. Pin als Open Drain.

Führe nun ein Kabel mit der Impedanz ???? (????) von Pin 1 zu Pin 2 und 
zu den weiteren Boards und deren Pin 2.

Betreibe dies mit maximal ????? KBit/s.

ODER

Das geht nicht so einfach, leg einfach an jedem Board einen Pin als 
Ausgang und 2 als Eingang für die Signale der beiden anderen Boards an 
und verschalte diese intern. Das ist einfach sicherer.

Das sind zwei meiner NAIVEN ANSÄTZE. Da ich (nochmals) keine Ahnung 
habe.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> An dieser Stelle taucht dann natürlich auch die Fragen auf: In wie weit
> muss ich eine GND Leitung dazulegen?
Ja nun, ein Bezugspotential brauchst du schon... :-o

Du hast IMHO 2 Freiheitsgrade:
1. das Medium (elektrisch, optisch...)
2. das Protokoll (Handshake, Start, Ende, Busarbitrierung...)
wobei Punkt 2 schon irgendwie (wenigstens teilweise) festzuliegen 
scheint.

2 MHz kannst du über einen "normalen" Draht ohne weiters über 50cm 
bekommen. Am einfachsten ist eine eine Punkt zu Punkt-Verbindung. Mit 
Multimaster-Bussen ( CAN, RS485 & Co) ist immer auch ein 
Verwaltungsaufwand verbunden: wer bekommt wann von wem den Bus 
zugeteilt.

Hast du dir schon mal irgendwelche seriellen Datenprotokolle angesehen? 
Es gibt viele davon. In deinem Fall liegt SPI auf der Hand...

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ALso wenn du es ganz einfach haben willst, verschalte alle FPGAs als 
Ring z.B. mit RS232 bzw. da du eh gleiche Spannungspegel hast kannst du 
die Transiver auch rauslassen, gib jedem Datenpaket die Addresse des 
Ziel FPGAs mit und den Quell FPGAs.

Wenn QuellID = Eigene ID:
 -> Paket verwerfen
sonst:
 wenn ZielID = EIgene ID
  -> Paket auswerten
 sonst
  -> weiterleiten an nächsten FPGA

Als Kabel nimmst du dann einfaches Nullmodemkabel. Wenn du es ganz edel 
haben willst kannst du natürlich die Signale auch differientiell 
übertragen falls dein Spartan3 Board hat zumindes LVDS Treiber nach dem 
PDF...

Autor: Erik E. (ikendes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für diese Hilfe schonmal.

> Du hast IMHO 2 Freiheitsgrade:
> 1. das Medium (elektrisch, optisch...)
> 2. das Protokoll (Handshake, Start, Ende, Busarbitrierung...)
> wobei Punkt 2 schon irgendwie (wenigstens teilweise) festzuliegen
> scheint.

Das Protokoll liegt absolut fest und existiert bereits als Verilogmodul.
D.h. mein Ansatzpunkt ist ein Verilogmodul mit einem Sendeausgang und 
Empfangseingang (jeweils 1 Bit). Dann habe ich noch mehrere FPGA 
Developmentboards (siehe obigen Link). Und mein Problem besteht mal ganz 
grob gesagt nur noch aus dem Stück Draht, das ich zwischen die FPGA 
Boards klemmen muss. Also dem 1. Freiheitsgrad.

>> An dieser Stelle taucht dann natürlich auch die Fragen auf: In wie weit
>> muss ich eine GND Leitung dazulegen?
> Ja nun, ein Bezugspotential brauchst du schon... :-o

Ist mir klar, deshalb habe ich ja auch nicht einfach versucht und Stück 
Draht an einen Pin des FPGA-Boards zu stecken, sondern hier nach Hilfe 
gesucht. :-)
Ausgangspunkt sind hierbei wieder mehrer FPGA-Boards mit jeweils einem 
eigenen Trafo... und schon fangen wieder meine Probleme an: Muss ich 
bereits diese Trafos durch Zusammenschalten eines Pols der 
Sekundärseite...
oder kann ich einfach GND von FPGA1 an GND von FPGA2 hängen ohne dass es 
kracht?


> 2 MHz kannst du über einen "normalen" Draht ohne weiters über 50cm
> bekommen. Am einfachsten ist eine eine Punkt zu Punkt-Verbindung. Mit
> Multimaster-Bussen ( CAN, RS485 & Co) ist immer auch ein
> Verwaltungsaufwand verbunden: wer bekommt wann von wem den Bus
> zugeteilt.

Also war die Angabe von 2 MHz kein totaler Unsinn?

> Hast du dir schon mal irgendwelche seriellen Datenprotokolle angesehen?
> Es gibt viele davon. In deinem Fall liegt SPI auf der Hand...

Ja, habe ich. Aber wie schon gesagt, das Protokoll ist vorgegeben.

Solangsam verstehe ich aber, warum mich zuerst keiner Verstanden hat.
Hier etwas genauer mein Problem:

Ich habe 3 FPGA-Board mit jeweils einem Sendeausgang für mein Bussignal. 
Wie bekomme ich diese 3 Signale so auf eine einzige Leitung, dass selbst 
bei einem Fehler des Busprotokolls keine Schäden entstehen?

Mir sind bisher folgende Möglichkeiten bekannt:
Wired-AND
Optische Übertragung
aber vermutlich gibt es noch weitere Möglichkeiten.

Das Prinzip der beiden obigen Systeme ist mir klar. Ich habe nur 
(typisch Student) keine Ahnung von der konkreten Realisierung.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> oder kann ich einfach GND von FPGA1 an GND von FPGA2 hängen ohne dass es
> kracht?
Das würde ich erwarten. Genaues kann dir nur der Schaltplan verraten...

> Ich habe 3 FPGA-Board mit jeweils einem Sendeausgang für mein Bussignal.
> Wie bekomme ich diese 3 Signale so auf eine einzige Leitung, dass selbst
> bei einem Fehler des Busprotokolls keine Schäden entstehen?
Schalte einfach einen 100 Ohm Widerstand an den Sender-Ausgang, dann 
geht nichts kaputt. Interessant dürfte allerdings werden, wie du die 
zusammengewürfelten Daten wieder auseinanderbekommst... :-/

> Mir sind bisher folgende Möglichkeiten bekannt:
> Wired-AND
Üblicherweise ist es so, dass der sendende Teilnehmer den Bus bekommt. 
die anderen (potentiellen) Sender schalten ihren Ausgang hochohmig.

Autor: Erik E. (ikendes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Mir sind bisher folgende Möglichkeiten bekannt:
>> Wired-AND
> Üblicherweise ist es so, dass der sendende Teilnehmer den Bus bekommt.
> die anderen (potentiellen) Sender schalten ihren Ausgang hochohmig.

Das wäre noch kein Wired-AND:

Die einfachste Realisierung erreicht man mit einer Busleitung, die über 
einen PULLUP Widerstand auf das hohe Potential (logische Eins) gesetzt 
wird.
Die Datenleitungen werden dann als OPEN DRAIN daran angeschlossen, die 
die Busleitung dann aktiv auf das niedrige Potential (logische Null) 
ziehen.
Beim Spartan 3 kann ich Ausgangspins sowohl als PULLUP, als auch als 
OPEN DRAIN Treiber schalten, also dies durchaus möglich sein.

Im Schaltplan nachsehen geht dabei leider nicht, da ich ja genau diesen 
Teil noch realisieren muss.


@ Läubi

LVDS Treiber wären ein Lösung für mein Problem mit dem 
Potentialausgleich, lösen aber nicht das Problem der Buscontention bei 
einem Protokollfehler.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wollte nicht ein Wired-And beschreiben, sondern sagen:
Du wirst mit einem richtigen Wired-And (also Pullup zum inaktiven Pegel 
und Transistoren zum aktiven Pegel) nicht zuverlässig auf deine Baudrate 
kommen. Nimm die "übliche" Vorgehensweise, dass einer der Busteilnehmer 
aktiv den Bus treibt, und die anderen solange still sind. Damit bei 
einer Buskollision nichts kaputtgeht, schaltest du Serienwiderstände in 
die Ausgangsleitungen.

> LVDS Treiber wären ein Lösung für mein Problem mit dem Potentialausgleich
Nein. Denn der Gleichtakt-eingangsbereich von LVDS-Eingänge reicht nur 
maximal bis zu der jeweiligen Versorgungsspannung. Auch hier ist eine 
GND-Verbindung zwingend nötig.

> lösen aber nicht das Problem der Buscontention bei einem Protokollfehler.
Du machst es dir gern unwahrscheinlich schwer, oder?


Ein kurzer und guter Tipp aus der Praxis:
Schließ die Dinger einfach zusammen, da geht nichts kaputt.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deswegen sage ich ja du sollst dir nen Ring aufbauen... dann kann es 
keine Kollisionen geben, und deine Pakete sind (bei geeigenter 
Steuerung) maximal n/2 lang unterweges wobei n die Anzahl Busteilnehmer 
sind. also in deinem Fall von 3 Boards also immer in einem "Zyklus".

Autor: Erik E. (ikendes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Deswegen sage ich ja du sollst dir nen Ring aufbauen...

Geht leider nicht, da ich keine Pakete habe sondern die Daten immer bei 
allen anderen FPGA ankommen müssen. Ein Ring ist auch ansonsten 
problematisch, da das ganze Protokoll zeitgesteuert ist. D.h. jedes FPGA 
hat sein festes Zeitintervall in dem es senden darf. Daher kann ich auch 
keine weitere Logik hinzufügen.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nagut dann halt einfach die Zieladresse rausnehmen und schon kommt es 
bei allen an ;)
Wenn es festgelegte Intervalle gibt/geben soll wäre vieleicht sowas wie 
Token Ring ne Überlegung wert.

Autor: Erik E. (ikendes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ich Trottel!

Klar geht ein Ring. O Mann, man muss sich nur Tage lang unnötige 
Gedanken machen...

Wie Lothar schon geschrieben hat:
> Du machst es dir gern unwahrscheinlich schwer, oder?

Danke für den Gedankenanstoß.
Ich schalten die einfach über RS232 als Ring hintereinander.

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Ring bei 3 Teilnehmern ist für mich ein vollständig besetzter Graph 
:>

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.