|
Anzeige
|
Wishbone-Bus als VHDL-Record
Gast
#3281173
Servus, gibts hier jemanden, der Records verwendet um Wishbone(oder andere) Busse übersichtlicher darzustellen? Falls ja, wie geht ihr mit unterschiedlichen Busbreiten um? Für jede Breite ein eigenes Record definieren? Meines Wissens kann ich einem Record ja keine Parameter übergeben. Oder irre ich mich? Gruß Vielleicht so (im Package)? Der Record ist natürlich nicht Wishbone, aber so von der Art her...
Gast
#3282142
pks schrieb: > gibts hier jemanden, der Records verwendet um Wishbone(oder andere) > Busse übersichtlicher darzustellen? Ja. > Falls ja, wie geht ihr mit unterschiedlichen Busbreiten um? Für jede > Breite ein eigenes Record definieren? Nein. Einfach nur die benötigten Bits verwenden. Es ist ja kein Problem, wenn ich z.B. auf den UART einen 32-Bit Zugriff mache und nur die unteren 8 Bit lese oder schreibe. Welche Busbreiten willst Du denn verwenden bzw. verbinden? Duke
Gast
#3282173
Duke Scarring schrieb: > Nein. Einfach nur die benötigten Bits verwenden. > > Es ist ja kein Problem, wenn ich z.B. auf den UART einen 32-Bit Zugriff > mache und nur die unteren 8 Bit lese oder schreibe. Wo Du recht hast... :-) Aber mal zur eigentlichen Definition - muss mann für Ein- und Ausgänge separate Records definieren oder kann man irgendwie mischen?
Gast
#3282190
Kann man, kommt aber nicht jedes Synthese- oder Simulationstool damit klar. Duke Scarring schrieb: > Nein. Einfach nur die benötigten Bits verwenden. Was die Typisierung ad absurdum führt. MMn nur geeignet für Kenner der fehlerfreien Programmierung...oder Verilog-Anhänger, die sinds ja gewöhnt. pks schrieb: > Für jede Breite ein eigenes Record definieren? Meines Wissens kann ich > einem Record ja keine Parameter übergeben. Oder irre ich mich? Du kannst Sie manchmal noch generisch machen, z.b. "natural range <>" und über den Instantiierung die tatsächliche Breite angeben. bei einem Unterelement eines Record klappt das jedoch nicht.
Gast
#3282404
Array of Recordarray schrieb: > Duke Scarring schrieb: >> Nein. Einfach nur die benötigten Bits verwenden. > > Was die Typisierung ad absurdum führt. Warum? Mich nervt es ohnehin immer, wenn Entwickler Adressbits wegschneiden. Leider denken FPGA-Entwickler fast immer in Wort-Adressen, was ich sehr unschön finde, weil es auch softwareseitig die Adressen von der Datenbusbreite abhängig macht. Auch in der Simulation finde ich es deutlich schöner, wenn ich immer weiß, dass die Addresse die ich sehe eine Byte-Adresse ist. Ich gebe schließe also auch die LSBs immer an jedes Modul an und verwende sie dann intern eben nicht.
Gast
#3282484
Es ging nicht um Addressen, sondern um Daten. Dass das problematisch ist stellt sich dann heraus, wenn jemand anderes sieht das ein 32 Bit Datenbus in ein Modul reingeht, letzteres aber nur 8 Bit davon verwendet. Oder es fällt einem später nicht auf, dass z.b. eine Addition einen Überlauf generiert, weil man nur 8 Bit kann, aber bis 9 gerechnet hat. Das Modul X müsste dann, um so einen Fall abzufangen, schauen ob auf Bit 8-31 etwas übertragen wird.... und dann? Einen Fehler ausgeben? Was wenn Bit 8-15 von Modul Y genutzt werden, welches ebenfalls den kompletten Bus empfängt? Beste Lösung: schon der Compiler haut es dir um die Ohren. Die Minute mehr Schreibaufwand schafft Klarheit und erspart stundenlanges Debuggen später.
Gast
#3282491
Ok, allerdings verwende ich eigentlich immer 32 Bit Datenbus. Und wenn ein Modul einen Wb-Port mit z.B. 8-Bit Datenbreite hat, gehört meiner Meinung nach eh eine Bridge (32<->8) dazwischen, weil es eigentlich nicht der gleiche Bus-Typ ist. Ich habe für dich ein Beispiel. Als Busvorlage habe ich den AHB lite Bus genutzt. Lite steht für ein Single Core Bus. Ich habe den Reset und den Clock nicht in den Record aufgenommen, Wenn ich die Signale in dem Record mitgeführt hatte, waren die Fit-Ergebnisse schlechter. Ich habe hier mein Record in der der angehangen Datei. HWDATA und HWDATA1 sind gleichwertige Signale nur um ein Takt verschoben. Das war für ein ein paar existierende Slaves notwendig. Als Beispiel hänge ich dir noch einen Kopf der Datei eines SPI-SLave an. Hier siehst du wie der Bus angebunden wird.
Gast
#3290123
Sieht übersichtlich aus. Könnte mir so gefallen. Es fehlen einfach ein paar praktische Codeschnipsel in der HDL-Welt. Ist auch sicher aus deiner CPU? Conrad schrieb: > Ist auch sicher aus deiner CPU? Ja stammte. aus der Mais CPU. Hallo, ich sehe dass da sich jemand mit dem AHB-Bus befasst hat. Mich würde mal folgendes intressieren: hat jemand ein Beispiel für einen AXI-Slave in VHDL? Das ist ja, wie der AHB, auch so ein ARM-Bus. Ich hab auf OpenCores was gefunden, ist allerdings in Verilog, und ich verstehe keine einzige Zeile davon :-) Ich möchte eigentlich nur einen "ganz einfachen" AXI Slave, den ich mit einem ARM Prozessor, der ein AXI Master Interface hat, anbinden kann. Gruss: Tobias Tobias Plüss schrieb: > Hallo, > ich sehe dass da sich jemand mit dem AHB-Bus befasst hat. > Mich würde mal folgendes intressieren: > > hat jemand ein Beispiel für einen AXI-Slave in VHDL? Das ist ja, wie der > AHB, auch so ein ARM-Bus. Ich hab auf OpenCores was gefunden, ist > allerdings in Verilog, und ich verstehe keine einzige Zeile davon :-) > Ich möchte eigentlich nur einen "ganz einfachen" AXI Slave, den ich mit > einem ARM Prozessor, der ein AXI Master Interface hat, anbinden kann. > > Gruss: Tobias Ich habe kein AXI-Slave für dich. Vielleicht hilft es dir den Code besser zu verstehen. AXI ist ein Stream Bus. Da werden FIFOs eingesetzt, um den die Daten zu Puffern. Der Busslave verarbeitet die Daten dann wann es Ihm passt. So grob als Busidee. René D. schrieb: > AXI ist ein Stream Bus. Da werden FIFOs eingesetzt, um den die Daten zu > Puffern. Nö. AXI ist eine Sammlung von Protokollen. Eigentlich nur zwei grundsätzlich verschiedene. "Der" AXI ist genaugenommen gar kein Bus sondern ein PtP handshaking Protokoll zwischen genau einem Master und einem Slave interface. Ganz traditionell werden hier Bursts verschiedener Länge und Transfervarianten unterschieden. AXI Lite ist nur eine stark eingeschränkte und vereinfachte Version von AXI. AXI Stream ist tatsächlich ein Streaming Protokoll und enthält daher nicht mal Adressen. Ob FIFOs eingesetzt werden oder nicht ist nichts worum sich der AXI Standard kümmern würde. Generell bleibt die Implementierung des Standards dem Anwender überlassen. Hier mal ein Link zu meinem ex-AG: http://www.doulos.com/knowhow/arm/Migrating_from_AHB_to_AXI Gruß Marcus Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
