Xilnx scheint sich komplett auch Zynq und AXI einzuschießen, habe ich den Eindruck. Selbst die kleinsten Schaltungsfunktionen werden auf Busse gestopft und zentral verarbeitet. Macht das Sinn? Ich habe mir mal angesehen, welche Verzögerungen auf dem AXI-Interface entstehen und wie lange es dauert, bis man nach einer Buszuteilung ein Datum von einem Slave erfragen kann. Da vergehen schon mal 10 - 15 Takte, bis das Datum eingesammelt ist. Besonders bei hohen Bandbreiten und Informatinsdichten ist das meines Erachtens eine gewaltige Systembremse. Die Haupteigenschaft von FPGAs, echt parallel zu arbeiten und von einem Punkt ein IF anzusprechen, während ein anderer Punkt ein ganz anderes IF mit ganz anderer Bandbreite abfrühstückt, wird verschenkt! Das Ergebnis der Problematik: Designs mit 4 AXI-Bussen, 6 AXI-Mastern und 24 AXI-Slaves und einem Umfang, der ein 70 Euro-FPGA erfordert, statt ein kleines FPGA für ein Drittel. Ist da nicht auch viel Strategie der Herstellers dabei?
> Das Ergebnis der Problematik: Designs mit 4 AXI-Bussen, 6 AXI-Mastern > und 24 AXI-Slaves und einem Umfang, der ein 70 Euro-FPGA erfordert, > statt ein kleines FPGA für ein Drittel. > > Ist da nicht auch viel Strategie der Herstellers dabei? Irgendwie müssen die ihre großen Bausteine vollbekommen. Was noch hinzukommt. Ich weiß nicht wie man einen einfachen AXI Slave selber schreibt. Und man ist wieder Abhänging vom Hersteller.
Markus W. schrieb: > Xilnx scheint sich komplett auch Zynq und AXI einzuschießen, habe > ich > den Eindruck. Selbst die kleinsten Schaltungsfunktionen werden auf Busse > gestopft und zentral verarbeitet. Macht das Sinn? Ich habe mir mal > angesehen, welche Verzögerungen auf dem AXI-Interface entstehen und wie > lange es dauert, bis man nach einer Buszuteilung ein Datum von einem > Slave erfragen kann. Da vergehen schon mal 10 - 15 Takte, bis das Datum > eingesammelt ist. Besonders bei hohen Bandbreiten und Informatinsdichten > ist das meines Erachtens eine gewaltige Systembremse. Nun, in der Regel verarbeitet ein FPGA riesige Datenströme unidirektional, also zum Beispiel von PCIe in einen DDR3-RAM, dafür viele Daten parallel und das ganze sehr schnell. Wenn du ständig die Richtung umschaltest bedeutet das in der Regel sowieso einen erheblichen Performance-Verlust, was die Datenrate angeht, da solche Datenpfade massiv gepipelined sind, um die Datenraten zu erreichen. Wenn du nun ständig die Richtung änderst, musst du erstmal die eine Pipeline leeren und dann die andere wieder füllen. Das macht alles Latenz, die sich in der bidirektionalen Datenrate dann negativ auswirkt. Insofern also nicht wirklich verwunderlich, dass AXI4 da auch nur mit Wasser kocht. Zudem gibt es noch AXI4-Lite, was eine abgespeckte Version von AXI4 darstellt und gerade für Slaves gedacht ist, die keine besonderen Anforderungen an Datenrate, sondern vielleicht eher an Latenz haben. Wenn du also einen GPIO-Slave oder sowas hast, dann kann man da auch durchaus AXI4-Lite verwenden. Wobei ich hier keine genauen Messungen gemacht habe, was Latenzen angeht. > Die Haupteigenschaft von FPGAs, echt parallel zu arbeiten und von einem > Punkt ein IF anzusprechen, während ein anderer Punkt ein ganz anderes IF > mit ganz anderer Bandbreite abfrühstückt, wird verschenkt! Nun, in der Regel will man das Verhalten gar nicht wirklich haben, sondern es gibt eine zentrale Kontrollinstanz (sei es ein Prozessor oder eine Statemachine), die irgendwo Register setzt und dann die Peripherieblöcke arbeiten lässt. Will man so ein Verhalten dennoch haben, dann hat man auch mit anderen Bussen mehrere getrennte Instanzen des Busses. Insofern verstehe ich hier nicht ganz, was genau AXI da schlimmer als andere macht. > Das Ergebnis der Problematik: Designs mit 4 AXI-Bussen, 6 AXI-Mastern > und 24 AXI-Slaves und einem Umfang, der ein 70 Euro-FPGA erfordert, > statt ein kleines FPGA für ein Drittel. Wenn du in dem Design 6 Master und 25 Slaves hast, dann hast du ja wohl eine Architektur umgesetzt, bei der zentral Dinge gesteuert werden. Wie willst du das anders lösen, als mit Bussen und eventuell sogar mehreren Instanzen eines bestimmten Bus-Typs? Und wie gesagt, für Peripherien, welche keine Anforderungen an Datenraten haben: AXI4-Lite! Da gibt es dann auch eine AXI2APB-Bridge und APB ist im Prinzip Wishbone, nach einer handvoll Gattern und ein paar anderen Signalnamen... > Ist da nicht auch viel Strategie der Herstellers dabei? Da ist vermutlich auch ein wenig was dran, wobei mir ein solch allgemeiner Bus, der dann überall verwendet wird deutlich lieber ist, als ein System, bei welchem jede Peripherie ihre eigene Frickel-Schnittstelle hat. René D. schrieb: > Was noch hinzukommt. Ich weiß nicht wie man einen einfachen AXI Slave > selber schreibt. Und man ist wieder Abhänging vom Hersteller. Also erstmal ist AXI keine Erfindung von Xilinx, sondern von ARM als Teil der AMBA Spezifikation. Und da auch andere namhafte Hersteller ihre FPGA SoCs auf ARM-Cores aufbauen bist du hier also nicht abhängig von nur einem Hersteller. Vielleicht, wenn du die IP-Cores des jeweiligen Hersteller verwendest, aber dann bist du sowieso bereits von dem Hersteller abhängig. Weiterhin ist es durchaus möglich sich einen AXI-Slave selbst zu bauen, zumindest einen AXI4-Lite. Dazu gibts auch Doku im Internet, einfach mal Google fragen. Und falls das zu schwer sein sollte, kann man sich auch wie gehabt einfach Wishbone-Slaves bauen und dann die - zugegebenermaßen ein wenig übertriebene - Kette von AXI4-Lite über APB nach Wishbone verwenden. Also alles halb so schlimm.
Interessant! Ich dachte bisher, der AXI sei ein einfacer Prozessorbus, an den man wie ein RAM ansdocken und alles anschließen kann.
Mit der Bezeichnung AXI ist es nicht getan. Besonders wenn man sich noch AXI Stream Standard sich angeschaut. Diese Verbindung ist klein und wahnsinnig simpel, aber standardisiert. Einen memory mapped AXI 4 slave zu bauen ist nicht ohne. Als ip Anbieter mMn notwendig, ansonsten aber oft vermeidbar.
AXI-Neuling schrieb: > Falk B. schrieb: >> AXI ist KEIN Bus!!! > > Sondern? Eine Punkt-zu-Punkt Verbindung. Man kann also lediglich zwei Teilnehmer miteinander direkt verbinden. In einem System mit mehreren Teilnehmern wird das so gelöst, dass es spezielle Interconnects gibt, welche dann als Mux fungieren. Hin und wieder (wie auch von mir in meinem Beitrag oben) wird ein solches AXI System mit Interconnects inkorrekterweise als Bussystem bezeichnet, da es dann ähnliche Aufgaben wie ein echter Bus erfüllen kann.
Ich war mal auf einer Schulung zur exteren Speicheranbindung. Da gab es eine möglichkeit den Speicher mit einem rudimentären Bus anzuschließen oder mit einem AXI interface. Das AXI Interfache brauchte noch mal einen deutliche Resourcenverbrauch. Seit dem habe ich AXI nicht mehr angeschaut. Als Punkt zu Punktverbindung habe ich Fifos in meinen Design bzw. melde mit einem busy flag Stau als flow control und das funktioniert super. Leider kein Standard.
Mh. M. schrieb: > AXI-Neuling schrieb: >> Falk B. schrieb: >>> AXI ist KEIN Bus!!! >> >> Sondern? > > Eine Punkt-zu-Punkt Verbindung. Man kann also lediglich zwei Teilnehmer > miteinander direkt verbinden. ... > Hin und wieder (wie auch von mir in meinem Beitrag oben) wird ein > solches AXI System mit Interconnects inkorrekterweise als Bussystem > bezeichnet, da es dann ähnliche Aufgaben wie ein echter Bus erfüllen > kann. Doch, doch Point 2 Point kann auch als Bus bezeichnet werden. Macht beispielweise die Wishbone Spec so . Wishbone ist ein SoC-Bus der in den Topologien "Shared bus" aber auch "Point2 Point" über Crossbar switsches realisiert werden kann: https://en.wikipedia.org/wiki/Wishbone_(computer_bus) Oder PCI und PCIe. Beides werden üblichererweise an Peripherie-Busse bezeichnet, wobei letzteres ein reines P2P System, ersteres dagegen als Shared bus ist.
René D. schrieb: > Als Punkt zu Punktverbindung habe ich Fifos in meinen Design bzw. melde > mit einem busy flag Stau als flow control und das funktioniert super. > Leider kein Standard. Aber schon sowas wie AXI-Lite-Lite. Wenn ich das richtig verstanden habe, besteht AXI aus drei (asynchronen) FIFOs. Einen zum Daten schreiben, einen zum Daten lesen und einen für die Kommandos (lesen/schreiben/???). Wenn die Daten nur in eine Richtung fließen (müssen), dann bleibt nur noch ein FIFO übrig... Duke
schau mal in die Spezifikation, Google "AMBA® AXI™ and ACE™ Protocol Specification" Das sind 300 Seiten..dabei wird das wird FIFO nur als Beispiel und weniger als 5 mal erwähnt. Im Fazit geht es nicht um FIFOs. Auch ist das rein synchron von der Spec. Asynchron wird's erst durch FIFOs oder spezielle Komponenten mit AXI-Interface.
Mh. M. schrieb: > Man kann also lediglich zwei Teilnehmer > miteinander direkt verbinden. In einem System mit mehreren Teilnehmern > wird das so gelöst, dass es spezielle Interconnects gibt, welche dann > als Mux fungieren. Gemeint ist sicher das hier: http://www.xilinx.com/products/intellectual-property/axi_interconnect.html Wie effektiv ist das dann noch? Ich glaube Xilinx "verschaukelt" uns mit diesem Axi: https://www.axi.com/de/
Videoprozessierer schrieb: > > Wie effektiv ist das dann noch? Da ein Vergleich zwischen AXI und (dem Vorgänger) AMBA bezüglich Effizienz: http://www.design-reuse.com/articles/24123/amba-ahb-to-axi-bus-comparison.html Vielleicht mal mit dem Performance Monitor selbst das Optimum herauskitzeln: http://www.xilinx.com/support/documentation/ip_documentation/axi_perf_mon/v5_0/pg037_axi_perf_mon.pdf http://www.xilinx.com/support/documentation/application_notes/xapp1219-system-performance-modeling.pdf Dort ein Vergleich von verschiedenen SoC-Bussen (aber kein AXI, wohl zu neu damals) https://www.engr.colostate.edu/~sudeep/research/ppt/commbook_chap3.ppt MfG,
Moin, ich denke mal, dass der ganze Komplexitäts-Wahnsinn automatisch mit den ARM-Cores eingeschleppt wurde. Schlussendlich will man ein möglichst robustes Tool, mit dem sich die Cores zusammenstöpseln lassen (oder vielleicht will es Xilinx für seinen Zielpublikum so). Das ganze war ja schon einmal dagewesen mit QSys/Avalon, was ja bis zu einem gewissen Grad auch per Klick akzeptabel funktioniert, ähnlich tut's der lm32 SDK auf Wishbone-Basis. Das wird immer nur dann zum Problem, wenn man was versucht, was der Hersteller nicht vorsieht, oder schlicht ungetestet blieb. Deswegen sehe ich ehrlich gesagt immer noch nicht ein, warum man einen aufwendigen Interconnect braucht, der zudem noch logikfressende Muxer "Faktor zwei" gegenüber der Wishbone-Lösung instanziert und plötzlich die Bandbreite in die Knie geht, und man eigentlich keine Möglichkeit mehr hat, optimierend einzugreifen. Das machen IMHO die diversen Untergrund-SoC-Generatoren auf XML-Basis o.ä. etwas eleganter, bzw. fährt man mit einer Bridge für seine eigenständige Wishbone-Peripherie besser. Schade, dass die Hersteller mit IP-XACT einfach nicht in die Pötte kommen.. Grüsse, - Strubi
Strubi schrieb: > Das ganze war ja schon einmal dagewesen mit QSys/Avalon, was ja bis zu > einem gewissen Grad auch per Klick akzeptabel funktioniert, Das Avalonzeug gab es aber auch schon zu den alten Quartuszeiten, oder?
Ich muss es nun nochmal aufwärmen! Ich wollte gerade einen etwas aufwändigeren Filter aufsetzen, den man nicht mehr gut per Hand bauen kann und stelle fest, dass sowohl CIC als auch FIR nur noch als AXI-Version angeboten werden. (Vivado 2015.4). Habe ich was verpasst? Kann ich kein natives Interface mehr haben?
Scheint so. Das ist die Xilinx-Politik, aber die gibt es schon einige Jahre. Die nativen Schnittstellen sind "böse", AXI-AXI über alles . . . ;-)
Naja, Axi Streaming für die Filter usw.. ist zwar ärgerlich aber trotzdem sehr simpel anzusprechen. Obacht beim Reset, der ist auch intern Low aktiv....
AXI-Streaming würde ich schon als natives Interface bezeichnen. Statt read/write heißt das Signal halt valid.
Die Verwaltung des AXI-Zeugs bringt doch sicher wieder Timing-Verzug und löst sich auch bei Nichtnutzung garantiert nicht in Wohl gefallen auf, nehme ich an. Es dürfte also Platz kosten. Mir scheint das AXI-Getue eine Mischung aus Faulheit und Politik. Die machen es sich einfach und der Kunde soll dann umständliche Cores benutzen, der er nur mit der Spezialsoftware bearbeiten kann und die dann irgendwann mal teuer wird - während immer mehr FPGA-Fläche verschwendet wird, um größere FPGAs verkaufen zu können.
M. W. schrieb: > Die Verwaltung des AXI-Zeugs ... > ... dürfte also Platz kosten. Das kann gut möglich sein! Die Benutzung solche pauschaler und universeller Interfaces bringt immer Verwaltung mit und verhindert gleichzeitig eine optimierte individuelle Lösung. Das ist halt das Problem von Standardisierung. Man muss es ja nicht nutzen, dann bleibt es eine vor sich hindümpelde Totgeburt. Ich nenne nur als Beispiel das vor 10 Jahren als DAS kommende Interface für VHDL-Cores gehypte "Wunschknochenzwischengesicht". > Mir scheint das AXI-Getue eine Mischung aus Faulheit und Politik. Die > machen es sich einfach und der Kunde soll dann umständliche Cores > benutzen, Daher baue ich meine Cores, Interfaces und vor allem auch solche Sachen wie Timinggeneratoren, DDSen und eben besonders auch die Filter in nativem VHDL. Das kann ich jederzeit portieren. > nur mit der Spezialsoftware bearbeiten kann und die > dann irgendwann mal teuer wird - während immer mehr FPGA-Fläche > verschwendet wird, um größere FPGAs verkaufen zu können. Also ganz ehrlich: Wenn ICH der Marktstratege bei Xilinx wäre, würde ich das auch ganz genau das machen! Was will man erwarten? Genau so macht man Geld: Anfüttern mit kostenlosen Proben, Interesse wecken, unmerklich abhängig machen und wenn der Kunde nicht mehr davon lassen kann, die Preise erhöhen. So machen es alle: Die Smartphonehersteller, die App-Entwickler, die Zigarettenindustrie und die Crack-Dealer :-)
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.