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.
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.
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?
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....
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 :-)
