Ich will einen Bus an eine Soft-CPU anstricken. Da das Timing des Busses auf die State Maschine einen sehr großen Einfluss hat, wollte ich den Bus jetzt festlegen. Schon mehrfach umgebaut und es kommt wieder was neues raus. Sofern brauche ich eine Spec auf die es jetzt zuschneide, sonst drehe ich mich im Kreis. Den Bus wollte ich nicht neu erfinden und dachte, ich nehme den Wishbone und fertig ist der Lack. Na ja so toll ist die Spezifikation auch nicht und muss mich dem Thread anschließen. Beitrag "Wishbone für Dummies?" Die weiteren Standarbusse die mir angeschaut habe, sind der AMPA und der Avalonbus. Fange ich mit dem Single Buszugriff an. Der ist noch sehr standardisiert und ist bei allen Bussen bis auf die Signalnamen gleich. Der Zugriff teil sich in eine Address- und Datenphase. Bei APB (AMPA) wird das Ack nicht vom Slave bestätigt,sondern als Erkennung der Datenphase benutzt. Das Signal kann aber von einem Wrapper ohne Probleme erzeugt werden.
Angehängte Dateien:
-
single.png
11 KB
Angehängte Dateien:
-
pipeline.png
19 KB
Ich habe vergessen zu sagen, ich habe eine Adressleitung (32bit) und zwei Datenleitungen (2x 32bit) für in und out Richtung. Und ich habe ein One Master System. Da entfällt schon mal der Arbiter. Single Transfers brauchen zwei Takte und damit ist nur noch die Hälfte der möglichen Datenrate möglich. Bursts sind auch nur aneinandergehängte single Transfers. Bis auf ein paar Außnahmen kein Geschwindigkeitsvorteil. Deshalb wollte ich keine Bursts nutzen. Jetzt gibt es den pipeline Bustransfer. Die Gültigkeit Daten und Adressleitungen sind versetzt. Der Wishbone hat sowas als Signalspiel. Nur gibt es ein Stall als Rückmeldung und ein Ack. Zwei Rückmeldungen sind doch Überflüssig? Wenn ich kein ACK habe kann ich nicht den nächsten Adresswert auf den Bus geben. Das ACk kommt zum Unterschied zum single Transfer, wenn gar kein keine Daten mehr auf dem Bus sind. Das sind zwei verschiedene Behandlungen in der Statemaschine. Alles zu kompliziert. Entweder hätten mehr Beispiele in die Wishbone spec hineingehört, um den Sinn des Singalspieles zu verstehen. Also meine Erkenntnis sagt, das eine sinnvolle Statemaschine dem abgebildete Timing entspricht. Das ACK ist allerdings asynchron auf dem sich der Slave zurückmeldet. Zwei Fragen? a) Gibt es ein Problem bei diesem asynchronen Signal? b) Kann ich mit einfachen Mitteln bestehende Slaves nutzen? c) hat einen anderen Vorschlag? d) Oder in der Bus Welt sind Burst Transfers ganz wichtig? B ist ein schwierige Frage weil ich die Menge nicht konkretisieren kann. Es gibt eben keinen allgemeinen Standard in der Buswelt. Tipps, Ratschläge und Erfahrung sind jetzt gefragt. Ich hoffe auf interessante Diskussionsrunde.
Mir gefällt dieses asynchrone Ack gar nicht... Sieh dir doch einfach mal das PCI Timig an (nur das Timing, nicht die Pegel), das funktioniert weltweit sehr gut. Und dann kommt dir der Wishbone auch nicht mehr so seltsam vor.
lkmiller schrieb: > Sieh dir doch einfach mal das PCI Timig an (nur das Timing, nicht die > Pegel), das funktioniert weltweit sehr gut. Und dann kommt dir der > Wishbone auch nicht mehr so seltsam vor. Ich habe den PCI Bus überflogen.. Der hat keine getrennte Daten und Adressleitungen. Das ist nicht ganz was ich suche. Die Burst Geschichte schaue ich mir noch mal beim PCI an. Ich habe zufällig das Buch PCI Bus demystified.
René D. schrieb: > Ich habe den PCI Bus überflogen.. > Der hat keine getrennte Daten und Adressleitungen. Das ist doch kein Problem: trenn die Leitungen doch einfach auf. Das Prinzip ist das selbe: du hast einen komplett synchronen Bus, bei dem jegeliche zustände nur an der nächsten Takflanke interessieren. Natürlich schaffst du damit keine solchen Quasi-Zero-Cycle-Reads, wie du sie skizziert hast... > d) Oder in der Bus Welt sind Burst Transfers ganz wichtig? Kommt darauf an, was man damit machen will. Daten, die sowieso nur zusammen interessant sind (Streams, Audio, Video, Bilder) sind Kandidaten für Bursts. Zugriffe auf Register (Status, Config, Control...) eher nicht. Also: was soll DEIN Bus können? Denn es macht wohl echt nur Sinn, einen eigenen Bus auszudenken, wenn man ein spezielles Problem hat. René D. schrieb: > Ich habe zufällig das Buch PCI Bus demystified. Das ist gut und das Geld wert.
Lothar Miller schrieb: > Also: was soll DEIN Bus können? Denn es macht > wohl echt nur Sinn, einen eigenen Bus auszudenken, wenn man ein > spezielles Problem hat. Ja genau das habe ich. Ich habe eine Mips CPU mit 5 stage pipeline. Havard Architektur. Um die Sache optimal zu halten, müssen die Daten-Ram Daten schnell hinein und auch weg. Sonst hätte ich mir die ganze Optimierung sparen können. Wenn z.B. der Single Read alles wieder ausbremst. Ich habe auch nicht alles erklärt. Der Pipelinezugriff hat die Möglichkeit, dass mit jedem Takt Adressen und Daten übertragen werden. Das Signal we_o zeigt die Richtung an. Von der Sache brauche ich die Zusatzsignale Frame oder cycle nicht einmal. für ein Singlemaster System nur Ballast.
> Lothar Miller schrieb:
Lothar danke für deinen Tipp nochmal den Wishbone anzuschauen.
AMPA bescheibt einen "CPU Bus" AHB und einen Peripherie Bus APB.
Der Wishbone dagegen hat alles in eine Spec nieder geschrieben und nicht
zwischen diesen beiden Bussen unterteilt. Die Daten Zugriffe Pipeline
und Burst sind auch inkompatibel.
Wenn man den Wishbone Pipeline als Highspeed bus betrachtet und einen
zweiten Low speed bus mit einer bridge eine Subbus anhängt, kann auf dem
Subbus die anderen Timings gefahren werden.
René D. schrieb: > Single Transfers brauchen zwei Takte und damit ist nur noch die Hälfte > der möglichen Datenrate möglich. Das ist eine Frage der Sichtweise. Wenn man Datenrate auf dem Bus = Taktfrequenz * Bitbreite rechnet stimmt das. Wenn ein Buszugriff aber ein paar Takte dauert, stimmt die Rechnung so nicht mehr. Außerdem setzt das auch voraus, das alle Slaves alle Daten in einem Takt liefern könnnen müssen. > Bursts sind auch nur aneinandergehängte single Transfers. Bis auf ein > paar Außnahmen kein Geschwindigkeitsvorteil. Deshalb wollte ich keine > Bursts nutzen. Nein. Bursts sind nicht nur ein paar single Transfers. Wenn der Wishbone Burst macht, wird die Übertragung nur einmal initialisiert und dann kommt nicht nur ein Datenwort (wie beim single Transfer) sondern entsprechend mehrere. Damit fällt der Overhead der Initialisierung weg. Das muß aber sowohl vom Master als auch vom Slave unterstützt werden. > Nur gibt es ein Stall als Rückmeldung und ein Ack. Zwei Rückmeldungen > sind doch Überflüssig? Wie erkennst Du, wenn Du auf nicht existierende Adressen/Slaves zugreifst? Wenn kein Ack, aber dafür ein Stall kommt, weißt Du, das der Slave etwas länger braucht. René D. schrieb: > Um die Sache optimal zu halten, müssen die Daten-Ram Daten schnell > hinein und auch weg. Sonst hätte ich mir die ganze Optimierung sparen > können. Wenn z.B. der Single Read alles wieder ausbremst. Dafür wurde der Cache erfunden. Spätestens wenn der interne BRAM nicht mehr reicht, bist Du auf externen Speicher angewiesen. Und egal ob QDR-SRAM oder DDR3-SDRAM, latenzfrei bekommst Du die Daten bei beiden nicht. > Von der Sache brauche ich die > Zusatzsignale Frame oder cycle nicht einmal. für ein Singlemaster System > nur Ballast Die werden dort von der Synthese mit sehr hoher Wahrscheinlichkeit auch rausoptimiert. René D. schrieb: > AMPA bescheibt einen "CPU Bus" AHB und einen Peripherie Bus APB. AMBA [1] beschreibt in der aktuellsten Version (4) einen ganzen Zoo von Bussystemen: u.a. ACE, AXI, AHB, APB, ATB Wobei ACE und AXI relativ neu sind. Die englische Wikipedia beschreibt in Kurzfassung die wichtigsten Eigenschaften [2]. Duke [1] http://www.arm.com/products/system-ip/amba/amba-open-specifications.php [2] http://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_Architecture
>Single Transfers brauchen zwei Takte und damit ist nur noch die Hälfte >der möglichen Datenrate möglich. Mit sep. Adressleitungen (und ein paar Steuerleitungen) geht das mit nur 1 Takt. In diesem Fall bringen auch Bursts nichts mehr. Wenn allerdings weniger Leitungen zur Verfügung stehen, können Bursts erhebl. Beschleunigung bringen (bsp.weise durch lesen/schreiben langer zusammenhängender Daten-Pakete.
Duke Scarring schrieb: >> Nur gibt es ein Stall als Rückmeldung und ein Ack. Zwei Rückmeldungen >> sind doch Überflüssig? > Wie erkennst Du, wenn Du auf nicht existierende Adressen/Slaves > zugreifst? > Wenn kein Ack, aber dafür ein Stall kommt, weißt Du, das der Slave etwas > länger braucht. Der Trick ist gut. an so etwas habe ich nicht gedacht. Ich kenne von einigen CPUs den Interrupt Memory error. Die Interrupt service Routine hat bei mir einen Reset ausgeführt.
Duke Scarring schrieb: > René D. schrieb: >> AMPA bescheibt einen "CPU Bus" AHB und einen Peripherie Bus APB. > AMBA [1] beschreibt in der aktuellsten Version (4) einen ganzen Zoo von > Bussystemen: u.a. ACE, AXI, AHB, APB, ATB Das für René interessanteste Protokoll aus dem AMBA Zoo ist vermutlich AHBLite. Eine auf single-master Betrieb abgespeckte Version von AHB, die auch in den Cortex-M Prozessoren verwendet wird. -- Marcus
Marcus Harnisch schrieb: > Das für René interessanteste Protokoll aus dem AMBA Zoo ist vermutlich > AHBLite. Eine auf single-master Betrieb abgespeckte Version von AHB, die > auch in den Cortex-M Prozessoren verwendet wird. AHBLite ist vermutlich was ich schon immer wollte. Der Tipp war richtig gut. Ich wusste doch, es waren schon vor mir schlaue Leute auf der gleichen Spur. Besonders AHBLite Spec Figure 3-5 Mutiple Transfers hat es mir angetan. Das ist mein bereits oben vorgestelltes pipeline. Mal sehe was ich noch endecke in der Spec.
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.