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.
Wie kann den TRISTATE durch Logik ersetzt werden? Glaube mit einem Multiplexer, aber wie funktioniert das genau?
@ Martin (Gast) >Wie kann den TRISTATE durch Logik ersetzt werden? Glaube mit einem >Multiplexer, So in der Art. MfG Falk
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
Sieh Dir mal die SPECs beim Altera SOPC builder an: Die Busse dort sind streaming interfacces, alles unidirektional. Das ist das Schnellste!
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... :-)
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.