mikrocontroller.net

Forum: FPGA, VHDL & Co. interne bidirektionale Busse


Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich habe vor in einem FPGA ein SoC (System on a Chip) zu realisieren.
Da verschiedene Cores (CPU-Core, DRAM-Controller, IO-Logik etc.) intern 
im FPGA realisiert sind, müssen sie ja durch einen internen Bus 
verbunden werden. CPU's haben ja so gut wie immer einen bidirektionalen 
Datenbus, welcher dann FPGA-intern wäre.
Nachdem was ich hier gelesen habe sind einige Leute der Meinung interne 
bidirektionale Busse wären schlecht und man handelt sich dabei nur 
Probleme ein bzw. sie wären gar nicht möglich.
Ist das so? Wenn ja wie will man denn dann die CPU interfacen?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Martin (Gast)

>Nachdem was ich hier gelesen habe sind einige Leute der Meinung interne
>bidirektionale Busse wären schlecht und man handelt sich dabei nur
>Probleme ein bzw. sie wären gar nicht möglich.

Das ist auch so. ;-)

>Ist das so?

Ja.

> Wenn ja wie will man denn dann die CPU interfacen?

Mit zwei unidirektionalen Bussen?

MfG
Falk

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber dadurch verbraucht man ja mehr Logik. Wäre es denn technisch 
überhaupt möglich interne bidirektionale Busse zu verwenden? Gibt es 
überhaupt FPGA-internen TRISTATE?

Mfg Martin

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Martin (Gast)

>Aber dadurch verbraucht man ja mehr Logik.

Nöö. Denkst du, ein bidirektionaler Bus läuft ohne Steuerung?

> Wäre es denn technisch
>überhaupt möglich interne bidirektionale Busse zu verwenden?

Kaum, weil . . .

> Gibt es überhaupt FPGA-internen TRISTATE?

Alle moderen FPGAs (Spartan3 und neuer) haben gar keine interen 
Tristates mehr. Die letzten waren Spartan-II. Interne 
Tristate-Beschreibungen werden automatisch vom Compiler in reine Logik 
umgewandelt.

MFG
Falk

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tri-State geht in einem FPGA afaik nicht. Ich hab jetzt schon mehrmals 
gesehen, dass ein OPB-Bus implementiert wird. Das ist nicht allzu 
aufwendig und hat ganz brauchbar funktioniert.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie kann den TRISTATE durch Logik ersetzt werden? Glaube mit einem 
Multiplexer, aber wie funktioniert das genau?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Martin (Gast)

>Wie kann den TRISTATE durch Logik ersetzt werden? Glaube mit einem
>Multiplexer,

So in der Art.

MfG
Falk

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst es als Tristate Bus in VHDL hinschreiben, und es wird ein 
nicht-Tristate Bus draus gemacht (vom Synthesizer). Das ist aber nicht 
immer optimal, weil es einen beliebig guten Logik-Minimierer erfordern 
würde.

Von Hand geht es so, mit nur Uni-Leitungen:

- Bus-Enable geht von allen Mastern zum Arbiter und vom Arbiter zu den 
Slaves

- der Arbiter wählt aus allen Mastern einen Master aus, der "darf". Alle 
reinen Master->Slave Signale gehen von allen Mastern in Muxe, die vom 
Arbiter gesteuert werden. Heraus kommen unidirektionale Signale, die in 
die Slaves laufen. Beispiele: Adressleitungen (*), Byte-Enable oder 
Bus-Size.

- (*) Die Adressleitungen werden teilweise Dekodiert, um genau einnen 
angesprochenen Slave auszuwählen. Dieser bekommt Enable, die anderen 
nicht. Die Slave-lokalen Adressleitungen werden  an alle Slaves gelegt. 
Ansehen tut es sich nur er enable-te Slave.

- Die Bi-Datenleitungsbündel werden in zwei Uni-Datenleitungsbündel 
geteilt, eins für Lesen (Slave->Master) und eins für Schreiben 
(Master->Slave). Das fürs Schreiben wird nach Mastern gemuxt wie die 
Adressleitungen. Das für Lesen kommt aus jedem Slave einmal, diese 
werden je nach Slave-Enable in ein einziges Bündel gemuxt und dieses an 
alle Master gelegt; ansehen tut es sich nur derjenige Master, dem der 
Arbiter das "okay" gegeben hat.

Die Details variieren zwischen den verschiedenen on-Chip Bussen.

Autor: Clemens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meines Wissens darf man bei den Tools von Lattice und Altera keine 
Bidirektionalen Busse im Chip intern in VHDL schreiben => Bringt Errors! 
Bidirektionale IOs funktionieren nur im Top-Level!
Abgesehen davon wirst du bei deinem Vorhaben sicher >=5k Logik verwenden 
je nach dem was du sonst noch alles einbauen willst und da dürfte so ein 
8,16,32 - bit Bus was du wahrscheinlich(??) verwenden willst sicher nur 
einen ganz kleinen Teil belegen.

Ist aber ein richtig großes Vorhaben Respekt

Autor: Chefingenieur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieh Dir mal die SPECs beim Altera SOPC builder an: Die Busse dort sind 
streaming interfacces, alles unidirektional. Das ist das Schnellste!

Autor: der mechatroniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei uns an der Uni wurde die Verwendung von internen bidirektionalen 
Bussen, warum auch immer, gelehrt. Irgendwie hab ich da aber nie 
wirklich geglaubt, daß das gut sein soll.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ der mechatroniker (Gast)

>Bei uns an der Uni wurde die Verwendung von internen bidirektionalen
>Bussen, warum auch immer, gelehrt.

Theorie und Praxis . . .

MfG
Falk

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist seltsam. Unser Prof hat uns nicht nur einmal angewiesen, uns um 
tristate zu drücken so lange es geht, weil die eigentlich nur Probleme 
machen. Die einzige Daseinsberechtigung sieht er off-chip, weil es eben 
den geringsten Verdrahtungsaufwand bedeutet.

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von der Hardwareseite aus: Ich schätze mal, ein interner Tristate Bus 
wäre langsamer als eine unidirektionale Verbindung (größere Kapazität). 
Dazu kommt dann noch, dass dieser dann an einer bestimmten Stelle auf 
dem FPGA liegt, was den Place&Route-Prozess wiederum ziemlich behindert. 
Zuguterletzt passieren beim Experimentieren mit VHDL auch mal Fehler; 
die externen Bustreiber überleben das oft (begrenzte max. Stromstärke), 
die internen würden sich sofort einschmelzen.

Von der Programmierseite aus: Da die neuen FPGA eh keine drauf haben, 
und unsereins sich nur mit der Verwendung, nicht der Entwicklung von 
FPGAs, beschäftigt, ist es für uns besser in VHDL gleich hinzuschreiben 
was am Ende auch da sein soll. Und das ist dann eben ein 
unidirektionaler "Bus".

Autor: Kjhgf Dassd (cfd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein bidirektionaler Datenbus ist auch deshalb uneffizient, weil 
besondere Vorsicht dabei geboten ist, dass keine Kurzschlüsse bei der 
Datenübertragung entstehen, wenn der eine eine HIGH Pegel und der andere 
einen LOW Pegel erzwingt. Dafür sind extra Takte nötig. Außerhalb von 
einem Chip macht so ein Kurzschluss nicht so viel aus, weil nach außen 
hin der Strom begrenzt wird. Ich glaub ich hab mal gelesen, in einem 
Chip ist das viel kritischer, weil da die Leitungen kleiner sind... Die 
gehen dann sofort kaputt, wenn sie nicht extra gesichert sind.

Konkret heißt das, dass wenn auf einen bidirektionalen Bus 2 Einheiten 
drauf zugreifen. z.B. Einheit1 und Einheit2, die Einheit1 etwas sendet 
und die Einheit2 sofort darauf antworten will, ein Zwischen Takt 
eingebaut werden muss, wo Einheit1 den Bustreiber abschaltet und nichts 
gemacht wird:

1 Takt: Einheit1 schreibt auf den Bus, Einheit 2 liest
2 Takt: Einheit1 schaltet seinen Bus Treiber aus. <- Zwischentakt, keine 
Datenübertragung
3 Takt: Einheit2 schreibt auf den Bus, Einheit 1 liest

Würde Einheit2 schon im zweiten Takt antworten, kann es sein, dass sie 
schon auf den Bus schreibt, obwohl Einheit1 den Bustreiber noch nicht 
abgeschaltet hat, weil sich nicht genau vorhersagen lässt, was zuerst 
passiert. (Theoretisch schon... hängt natürlich von den 
Syntheseergebnissen ab...)

Beim PCI-Bus heißen diese extra Takte Turnaround-Cycles. An diese Takte 
wird oft nicht gedacht, obwohl sie wichtig sind...

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es braucht aber keine Turnaround-Zyklen wenn das Timing entsprechend 
genau vorgegeben ist.

Sender 1 schaltet max. X ns nach der Taktflanke die Bustreiber ab,
Sender 2 schaltet min. Y ns nach der Taktflanke die Bustreiber an.

Y-X: Sicherheitsabstand, um z.B. Temperaturschwankungen auszugleichen.

> weil sich nicht genau vorhersagen lässt, was zuerst
> passiert. (Theoretisch schon...

Innerhalb einer gewissen Spanne von Parametern (z.B. Temperatur) kann 
man es vorhersagen.

> hängt natürlich von den
> Syntheseergebnissen ab...)

Jegliches Verhalten der Schaltung hängt von den Syntheseergebnissen 
ab... wozu bräuchte man sie sonst?

Autor: cfd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, geht wohl offensichtlich auch ohne Turnaround Cycles, wenn man sich 
um das genaue Timing kümmert. Hab gerade entsprechende Informationen im 
Internet gefunden... Der PCI Bus ist halt nicht mehr das Neuste und 
meine Kenntnisse wohl auch nicht... :-)

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.