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?
@ 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
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
@ 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
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.
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.
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
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.
@ der mechatroniker (Gast)
>Bei uns an der Uni wurde die Verwendung von internen bidirektionalen>Bussen, warum auch immer, gelehrt.
Theorie und Praxis . . .
MfG
Falk
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.
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".
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...
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?
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... :-)
