Moin, wenn ich in der Simulation interne Signale zufügen möchte bekomme ich dauernd diese Meldung: ERROR: [Labtools 27-1832] create_wave_config not a supported tcl command in labtools hardware mode. Default wave configurations are automatically created when triggering an ILA core. Was bedeutet die und was soll das? Ich verwende keinen ILA und habe keine JTAG Hardware angeschlossen. Ich will nur simulieren. Bis vor dem letzten Synthese Durchlauf gab es diese Fehlermeldung nicht. Edit: Jetzt habe ich mal alle IPs auf Global statt Out of context per IP gestellt und es funktioniert. Sehr seltsam. Was hat das mit der Fehlermeldung zu tun?
:
Bearbeitet durch User
Wo hast du sie durch welchen Befehle hinzugefügt? Vom Vivado meine ich mich dunkel zu erinnern, gibt es ein "mark debug". Das markiert aber für einen ILA. Da ich so einen automatischen Quatsch nicht benutze, habe sich solche Probleme nicht. Ich habe mir von Anfang an angewöhnt, alles vom ModelSIM aus zu machen. Klappt bestens. Ohne Scriptmist und Xilinx-Gedöhns. Ist alles nur Klickibunti für Spielkinder.
Tobias N. schrieb: > ModelSIM Habe ich nicht, glaube ich zumindest. Tobias N. schrieb: > Wo hast du sie durch welchen Befehle hinzugefügt? Gar nicht, ich habe inder GUI die Simulation gestartet. Normalerweise sind da dann alle SIgnale aus der Testbench drinnen. Will man interne Signale des UUT sehen, muss man die hinzufügen. Das habe ich mir Rechtsklick auf das Signal und "Add to Wave Windows" versucht. ABer hat sich wohl erledigt. Ich weiß zwar nicht wieso, aber wenn ich die Simulation starte scheint es Glückssache ob es Fehler gibt oder nicht. Also es hat schon mehrmals geholfen nur die Simulation zu schließen und neu zu öffnen. Das sieht für mich alles sehr verbuggt aus. Kann man mit GHDL und GTK Wave auch Xilinx IP simulieren? Oder so Blöcke wie IDELAY2? Ich vermute leider nein, habe es aber auch noch nicht getestet.
Ach man, den nächste Bug: Ich ändere was am VHDL, baue ein neues Signal ein und starte die Simulation ... und da taucht das nicht auf. Ja, die Datei ist im Vivado Project Manager unter Design Sources und wenn ich drauf klicke sehe ich im Editor auch den aktuellen Stand. Muss ich jetzt neuerdings immer die Synthese durchlaufen lassen damit die Simulation aktuell ist? Ich habe jetzt mal Incremental Dingens ausgemacht ... mal gucken. Edit: Ja, hat glaube ich geholfen. Also in den Simulationssettings "Enable Incremental Compilation" ausschalten. Kann aber mal wieder nur Zufall sein, dass der Fehler jetzt weg ist.
:
Bearbeitet durch User
Gustl B. schrieb: > Kann man mit GHDL und GTK Wave auch Xilinx IP simulieren? Oder so Blöcke > wie IDELAY2? Ich vermute leider nein, habe es aber auch noch nicht > getestet. Jep, das geht. Du musst die Unisim mit GHDL kompilieren und dann einfach verwenden. GHDL liefert sogar fertige Skripte mit um dir das abzunehmen. https://github.com/ghdl/ghdl/blob/master/libraries/vendors/README.md Kleiner Edit: Es gehen natuerlich nur IPs die in der Unisim / Unimacro drinnen sind. Verschluesselte Xilinx IPs sind natuerlich nicht moeglich. :-(
:
Bearbeitet durch User
Gustl B. schrieb: > Muss ich jetzt neuerdings immer die Synthese durchlaufen lassen damit > die Simulation aktuell ist? Ich habe jetzt mal Incremental Dingens > ausgemacht ... mal gucken. Simulierst du die Netzliste? Dann ist doch klar, dass du nicht alle Signale siehst, da wird schliesslich einiges wegoptimiert oder reduntante Signalnamen eindeutig benannt.
Ne die normale Verhaltenssimulation. Aber es geht ja jetzt wie früher mit 18.3. Am VHDL editieren und dann die Simulation neu laufen lassen. Ohne Synthese oder so. Und die neues Signale tauchen auf.
Ich habe noch eine Nachfrage: Ihr kannt das bestimmt, man hat eine Platine, da sitzt ganz viel Zeug drauf und eben auch ein FPGA. Das FPGA steuert viele externen Bausteine über verschiedenste Schnittstellen. Baut ihr dann diese externen Bausteine für die Testbench in HDL nach? Ich mache das gerade ... und es ist doch sehr mühsam jeden Stein mit allen Registern und deren vielen Funktionen nachzubauen.
Gustl B. schrieb: > Baut ihr dann diese externen Bausteine für die Testbench in HDL nach? > Ich mache das gerade ... und es ist doch sehr mühsam jeden Stein mit > allen Registern und deren vielen Funktionen nachzubauen. Sowohl als auch. Haengt ganz von der Funktionalitaet des Bausteins ab. Fuer viele komplexe Sachen gibt es zum Glueck auch Modelle von den entsprechenden Herstellern (z.B. SDRAM oder Flash Speicher). Im Prinzip musst du hauptsaechlich die Schnittstelle abbilden und nicht das innere der externen Bausteine. Wenn man da mal eine gute Sammlung hat, kann man da immer wieder darauf zugreifen. Bei manchen genuegt es auch einfach nur eine ganz einfache Entity zu erstellen (z.B. SPI / I2C Devices wie Temepratursensoren) und dann mit einer anderen Methodik zu verifizieren, z.B. PSL. Da ich viel mit VUnit mache, greife ich auch gerne auf fertige Schnittstellen zurueck (sind zum Teil etwas buggy, aber wenn man die fixt, landet die Korrektur relativ schnell in deren Repo). Das gute beim erstellen von Simualtionsmodellen ist, dass die viel schneller gemacht sind, da man aus dem vollen VHDL Topf schoepfen kann und nicht auf Synthetisierbarkeit achten muss.
:
Bearbeitet durch User
Tobias B. schrieb: > Das gute beim erstellen von Simualtionsmodellen ist, dass die viel > schneller gemacht sind, da man aus dem vollen VHDL Topf schoepfen kann > und nicht auf Synthetisierbarkeit achten muss. Ja stimmt. Klar gibt es da ein paar Standardschnittstellen, aber die haben dann doch irgendwelche Eigenheiten. Mal ist der maximale SPI Takt sehr niedrig, mal liegen die Daten zur fallenden Flanke stabil an, ... Konkret habe ich einen https://www.analog.com/media/en/technical-documentation/data-sheets/AD9508.pdf . Und das Problem ist Folgendes: Wenn ich der Hardware Strom gebe wird der Stein über SPI beschrieben. Wenn ich aber kurz Strom wegnehme und neu gebe, dann wird Müll geschrieben - obwohl das FPGA neu konfiguriert. Jetzt habe ich diesen STein samt der Register also in HDL beschrieben und kann in der Simulation die Daten wieder auslesen und überprüfen. Da ist eine Eigenheit im Datenblatt auf Seite 29 in der Mitte Figure 52. t_DV ist zwar angegeben, aber eher kurz mit maximal 15 ns und minimal 0 ns. Wenn ich die Daten mit der fallenden Flanke von SCLK erfassen soll "The readback data is valid on the falling edge of SCLK." wird es also sehr kanpp. Ich erfasse die also jetzt etwas vorher und bekomme das gewünschte Ergebnis. Ich frage mich nur ob meine Herangehensweise normal ist oder ob ein Profi da etwas grundsätzlich anders macht.
:
Bearbeitet durch User
Du musst prinzipiell 2 Dinge unterscheiden: - Debugging - Verifikation Du steckst aktuell in der Debugging Phase fest und da ist es natuerlich schwierig. Da bit du fast auf ein Hersteller Modell angwiesen. Gustl B. schrieb: > Wenn ich der Hardware Strom gebe wird der Stein über SPI beschrieben. > Wenn ich aber kurz Strom wegnehme und neu gebe, dann wird Müll > geschrieben - obwohl das FPGA neu konfiguriert. Kannst du das etwas spezifizieren? "Hardware Strom geben" heisst hier ein gleichzeitiges Power-Up von FPGA und dem AD9508? Ebenso "Strom wegnehmen", ist da auch das gesamte System gemeint oder nur der FPGA? "Muell schreiben" bedeutet hier daten vom FPGA zum AD9508? Dann hat das nicht unbedingt etwas mit dem AD9508 zu tun hat, es sei denn er zieht aktiv die MOSI Leitung runter. Vll. aber das waere vll. besser in einem extra Thread ausdiskutiert? Gustl B. schrieb: > Ich frage mich nur ob meine Herangehensweise normal ist oder ob ein > Profi da etwas grundsätzlich anders macht. Naja, ein Profi geht erstmal ganz anderst an die Problem Analyse ran. In der Regel bestimmt dann der Erfahrungsschatz den weiteren Weg.
Tobias B. schrieb: > Du steckst aktuell in der Debugging Phase fest und da ist es natuerlich > schwierig. Da bit du fast auf ein Hersteller Modell angwiesen. Jo. Mit Stom geben und wegnehmen meine ich die ganze Hardware. Die hat eine USB Buchse und da wird ein und ausgesteckt. Ein Sequenzing habe ich nicht weil ich ja auch Bausteine im Reset halten kann. Das war nur ein Beispiel mit diesem Stein. Ich hatte da einen Fehler gemacht (vermutlich?) und zwar die SPI Transaktion sofort gestartet nach dem FPGA Boot. Und dann auch noch das SPI als Stream. Stimmt also ganz am Anfang vom Stream die erste Adresse nicht, so landen alle Bytes an falschen Stellen. Das Problem ist jetzt gefixt, ich warte nach dem FPGA Boote kurz, währenddessen bekommt der AD9508 einen Reset und nach dem Reset geht es mit dem SPI los. Die Register werden jetzt einzeln nacheinander beschrieben und wieder gelesen. Dazu musste ich aber für die Simulation den AD9508 zu einem Teil nachbauen. Andere Steine habe ich auch nachgebaut, eigentlich fast die ganze Hardware auf dem Board die vom FPGA bespaßt wird. Aber das scheint nach dem was du oben geschrieben hast von der Hardware abzuhängen was man alles in der Testbench bauen muss. Naja, immerhin habe ich so langsam einen netten Fundus aus Bausteinen.
Gustl B. schrieb: > Dazu musste ich aber für die Simulation den AD9508 zu einem Teil > nachbauen. Andere Steine habe ich auch nachgebaut, eigentlich fast die > ganze Hardware auf dem Board die vom FPGA bespaßt wird. Dazu musst du eigentlich nur den SPI Slave nachbauen mit seinem SPI Modus. Die Daten wertest du dann anschliessend seriell in einem Prozess aus, z.B. durch Vergleich mit einem Datensatz aus einer Textdatei. Das ist ein gutes Beispiel fuer ein SPI Standardmodul, was du zur Verifikation dann immer wieder nehmen kannst. Verschiedene SPI Modes werden dann idealerweise durch ensprechende Generics gesetzt. Ich mache sowas z.B. fuer den Startup Prozess von Bildsensoren. Der bekommt auch ueber SPI (oder I2C) seine Registersaetze und zwischen diesen Registersaetzen muessen definierte Pause eingehalten werden. Dafuer habe ich dann z.B. ein Modul welches Daten annimmt und mit einem Textdatei der Form
1 | R 1234 9092 |
2 | P 20000 |
3 | R 1010 1210 |
vergleicht. Der Syntax hier lautet in Prosa: Nach setzen von Register Adresse 0x1234 mit Wert 0x9092 folgt eine Pause von 20000 us. Dann wird wieder ein Register erwartet. Das deckt jetzt relativ simpel ab, ob der Sensor Startup korrekt ablaeuft. SPI Timings wie Setup/Hold Zeiten werden nochmal separat untersucht.
Danke, das ist in der Tat eine gute Idee. Dann baue ich mir mal ein SPI das ich sehr flexibel einstellen kann um es an vielen Stellen verwenden zu können.
Hmmm, VUit hat einen Pull Request fuer SPI Support: https://github.com/VUnit/vunit/pull/425 Vielleicht den pushen, statt selber basteln?
Gustl B. schrieb: > Baut ihr dann diese externen Bausteine für die Testbench in HDL nach? Jein. > Ich mache das gerade ... und es ist doch sehr mühsam jeden Stein mit > allen Registern und deren vielen Funktionen nachzubauen. Für eine LED habe ich z.B. kein VHDl-Modell :-) Aber für DACs und ADCs schon. Im Modell gibt es eine Umleitung in/von Dateien. Die Simulation läßt sich dann schön mit verschiedenen Testfällen oder gar realen (aufgezeichneten) Daten füttern. Auch für die SPI habe ich ein Modell, aber eher nur für das Signalspiel. Das eigentliche Protokoll wird auf höherer Ebene getestet. Im Modell läßt sich auch ganz gut das Timing aus dem jeweiligen Datenblatt checken:
1 | time_check_sck_cycle: process |
2 | variable change: time; |
3 | variable diff : time; |
4 | begin
|
5 | wait until rising_edge(sck); |
6 | change := now; |
7 | wait until rising_edge(sck); |
8 | |
9 | diff := now - change; |
10 | assert diff >= t_cys8 |
11 | report me_c & " SCK cycle time to short: " & image( diff) |
12 | severity error; |
13 | end process; |
14 | |
15 | time_check_lpw_sck: process |
16 | variable change: time; |
17 | begin
|
18 | wait until falling_edge(sck); |
19 | change := now; |
20 | wait until rising_edge(sck); |
21 | |
22 | assert (now - change) >= t_hpws8 |
23 | report me_c & " SCK low pulse width to short" |
24 | severity error; |
25 | end process; |
26 | |
27 | ...
|
Duke
:
Bearbeitet durch Moderator
Danke! Da ist meine Herangehensweise vermutlich noch zu vivadomäßig. Ich verwende da großteils die GUI und baue mir da zu fast jeder meiner HDL Components eine Testbench. Und dann noch HDL Beschreibungen für die externen ICs und noch eine Testbench für das Gesamtsystem.
Gustl B. schrieb: > Danke! Da ist meine Herangehensweise vermutlich noch zu > vivadomäßig. Ich verwende da großteils die GUI und baue mir da zu fast > jeder meiner HDL Components eine Testbench. Und dann noch HDL > Beschreibungen für die externen ICs und noch eine Testbench für das > Gesamtsystem. Kommt immer drauf an was man erreichen will/muss und wie viele Ressourcen man dafür hat. Ich mache bei uns die FPGAs als One Man Show, da simuliere ich zu 90 Prozent auf Modul Ebene. Modelle für externe Chips gibt's auch, aber wie oben schon geschrieben auf das Minimum (Interface...) beschränkt. Das Gesamtsystem wird eher selten simuliert, z.B. bei einem voll gestopften Artix 7 200T mit MGTs macht das auch keinen Spaß. Sowas mache ich nur wenn da ein ganz hartnäckiger Bug ist. Was ich wegen Mangel an Ressourcen kaum mache sind solche selbst checkenden Testbenches, als einzelner Entwickler schafft man das kaum...
OK, ja ich mache das derzeit als Hobby. Daher ja, ich habe schon Zeit um Testbenches zu schreiben, aber ich versuche lieber den Code minimal zu halten damit ich nicht viel testen muss. Christian R. schrieb: > [...] simuliere ich zu 90 Prozent auf Modul Ebene. Mittlerweile mache ich das auch, ein Modul wird erst verwendet wenn es in der Simulation funktioniert. Ein wenig will ich noch dazulernen und gemacht haben (USB3, schnelle SerDes und Zynq) und dann will ich mich damit auch mal fachfremd bewerben. Daher interessiert mich immer so sehr (das nervt vielleicht manchmal) wie das richtige studierte Profis machen. Aber da gibt es wohl große Unterschiede, mir scheint als würde man das Meiste dann erst bei der Arbeit lernen.
Gustl B. schrieb: > Baut ihr dann diese externen Bausteine für die Testbench in HDL nach? > Ich mache das gerade ... und es ist doch sehr mühsam jeden Stein mit > allen Registern und deren vielen Funktionen nachzubauen. Kennste https://www.freemodelfoundry.com/? Da wird man betr. div. Memories schon mal fuendig. Alles andere wuerde ich nicht mehr in plain VHDL nachbauen. Das geht besser mit Software-Co-Simulation, sofern es nicht zwingend aus einem HDL-Guss sein muss. Fuer I2C/SPI-Backends (register) bediene ich mich der herkoemmlichen XML-Techniken um die Registermaps/Treiber daraus zu generieren. Spart ne Menge Tipparbeit. Tobias B. schrieb: > Kleiner Edit: Es gehen natuerlich nur IPs die in der Unisim / Unimacro > drinnen sind. Verschluesselte Xilinx IPs sind natuerlich nicht moeglich. > :-( Die Vivado-Schluessel liegen eigentlich offen im Netz rum, aber gut, es hat immer so'n Gschmaeckle. Mit GHDL und einem 'virtuellen filesystem'-Preload kann man den Kram aber simulieren, dass man sein Recht auf Nicht-Wissen betr. der vernudelten HDL mit reinem Gewissen wahrnehmen kann :-)
Martin S. schrieb: > Kennste https://www.freemodelfoundry.com/? ohne www: https://freemodelfoundry.com Sonst gibt's einen Zertifikatsfehler, der vielleicht den ein oder anderen verschreckt.
Christian R. schrieb: > Was ich wegen Mangel an Ressourcen kaum mache sind solche selbst > checkenden Testbenches, als einzelner Entwickler schafft man das kaum... Ne, eigentlich gar nicht. Den Mehraufwand holt man doppelt und dreifach wieder rein, da die Debug Phase drastisch reduziert wird. Gerade mit Tools wie VUnit wird das ganze auf ein Minimum an Mehrarbeit runtergebrochen. Martin S. schrieb: > Tobias B. schrieb: >> Kleiner Edit: Es gehen natuerlich nur IPs die in der Unisim / Unimacro >> drinnen sind. Verschluesselte Xilinx IPs sind natuerlich nicht moeglich. >> :-( > > Die Vivado-Schluessel liegen eigentlich offen im Netz rum, aber gut, es > hat immer so'n Gschmaeckle. Mit GHDL und einem 'virtuellen > filesystem'-Preload kann man den Kram aber simulieren, dass man sein > Recht auf Nicht-Wissen betr. der vernudelten HDL mit reinem Gewissen > wahrnehmen kann :-) Ahhh, stark. Hast du da vll. ein paar naehere Infos oder ne Seite zum nachlesen? Mir geht es schon gewaltig auf die Nuesse das simpelste Dinge wie den Testimage Generator mit GHDL nicht (offiziell) simulierbar sind.
Es gab hier mal nen Thread (vom 13.3.2016) zu, die langen Arme aus den verunreinigten Staaten sorgen allerdings jeweils fuer eine kurze Lebensdauer. Wer aber will, findet alte Posts bei archive.org oder div. 'Ansichtsmaterial' bei chinesischen Code-Hostern. Ansonsten sollte man die Meinung der Rechtsabteilungen im Zweifelsfalle offenbar respektieren und die Tools nicht verteilen, siehe auch https://github.com/github/dmca/blob/master/2016/2016-08-16-Xilinx.md Ob xlxunprotect.py jetzt eher illegal als hilfreich ist, kann man sich streiten, ueber eine unsinnige Verschluesselung ebenso. Fuer die Fehlersuche in Vendor-Cores sicher hilfreich, wenn man den Kram nutzen muss, wenn nicht, ist mein ehrlicher Fazit: Es ist teils zielfuehrender und nachhaltiger, von dem verstuemmelten und teils unwartbaren vendor-locked Code wegzukommen. Bei so einigen Cores findet man nicht standard-konforme Konstrukte, die in Isim u.U. was anderes machen als im strengen GHDL, aber leider richtig synthetisieren. Das macht dann bei der Portierung auf andere Arch. richtig Aerger. Grade zum Beispiel Testbild-Generator: warum nicht selbermachen? Wenn du schon VUnit einsetzt, ist der Weg zur virtuellen Kamera in der CI per Python/ghdlex/ghdl nicht weit.
Hauptsaechlich wuerde ich mir das mal zu Lehrzwecken anschauen, daher vielen Dank fuer die entsprechenden Stichworte. Martin S. schrieb: > Grade zum Beispiel Testbild-Generator: warum nicht selbermachen? Wenn du > schon VUnit einsetzt, ist der Weg zur virtuellen Kamera in der CI per > Python/ghdlex/ghdl nicht weit. Das ist mir schon klar, ist ja nur ein Beispiel. Xilinx hat halt ein paar IP in dem extrem wenig I steckt und diese trotzdem verschluesselt. Ich kann nunmal nicht fuer jedes Projekt alles neu Programmieren, schon garnicht wenn ein Kunde nicht bereit ist den Aufwand zu bezahlen. Dann nimmt man halt das fertige Zeugs und bau mir ein Tcl Skript das die Cores instantiert und konfiguriert und fertig ist der Lack. Gibt auch noch viel banalere Dinge, wie z.B. den "Divider". Warum sollte ich mir die Muehe machen einen Divider selbst zu machen, zu verifizieren und gegebenfalls noch zu warten? Und wieso muss Xilinx sowas banales verschluesseln? Wenn man das dann durch seine CI Pipeline laufen lassen moechte, steht man halt oft im Regen da, dann muss ich schon wieder ein Modell fuer den Divider schreiben, nur weil der verschluesselt ist. Anderes Beispiel: Video Processing Subsystem. Da rueckt mir Xilinx nichtmal die Register raus, d.h. ich bin sogar darauf angwiesen immer einen Microblaze oder Zynq zu verwenden, damit ich den Treiber habe. Wenn ich aber die FPGA Ressourcen habe, wieso sollte ich dann nicht darauf zurueckgreifen? Gerade wenn ein Kunde nach dem Rapid Prototyping schon zufrieden ist, dann versuche ihm mal zu erklaeren warum jetzt die Kosten anfangen zu explodieren, nur weil du noch eine CI Kette aufbauen musst. Es gibt halt unterschiedliche Szenarien und alles From-Scratch neu und selbst machen ist in der Pauschalitaet genauso schlecht, wie alles aus der Vendor Werkzeugkiste zu nehmen.
Gustl B. schrieb: > Daher interessiert mich immer so sehr (das nervt vielleicht > manchmal) wie das richtige studierte Profis machen. Aber da gibt es wohl > große Unterschiede, mir scheint als würde man das Meiste dann erst bei > der Arbeit lernen. Ja, so sieht's aus. Ich konnte mit meinen Vorlesungsunterlagen zum Thema VHDL in der Praxis fast nix anfangen. Das mag heute ggf. anders sein. Je nach Organisation und Zahl der Entwickler, die sich mit VHDL bzw. FPGA beschäftigen, sieht das auch unterschiedlich aus. Duke
Vielen Dank für die Antworten. Ich sehe schon es gibt noch viel zu lernen und anzugucken in diesem komplexen Themenbereich ... bisher bin ich ganz froh meine Dinge im Vivado Simulator zu sehen. Tja IP oder nicht IP, ich versuche möglichst viel selbst zu schreiben, sehe aber auch, dass man mit anderen Methoden vermutlich schneller ans Ziel kommen würde. Ich habe da tatsächlich etwas Angst, dass ich mit einem AXI System mit DMA und allem etwas die Kontrolle über meine Bits verliere. Und auch, dass ich dann Schwierigkeiten bekomme an das System aus Xilinxblöcken meine eigenen HDL Blöcke ohne AXI anzuschließen. Aber mal gucken. Ein Board mit Zynq steht auf der Wunschliste, da werde ich dann mal ausprobieren wie man eigene HDL so verbindet, dass man dann aus dem Linux heraus mit diesen reden kann.
Gustl B. schrieb: > Ein Board mit Zynq steht auf der Wunschliste Die sind ja leider (noch) nicht wirklich günstig. Ich habe mir mal ein Z-turn von MYIR besorgt, kann es aber nicht weiterempfehlen: - Dokumentation mangelhaft - proprietärer JTAG-Anschluss Wenn man mit der Peripherie was anfangen kann, sind vielleicht ein ADALM-Pluto oder ein Red Pitaya brauchbar. Duke
Duke Scarring schrieb: > Die sind ja leider (noch) nicht wirklich günstig. Ja. Das günstigste ist wohl das https://shop.trenz-electronic.de/de/TE0722-02-07S-1C-DIPFORTy1-Soft-Propeller-mit-Xilinx-Z-7007S-Single-core-16-MByte-Flash?c=238 . Aber eben auch sehr mager ausgestattet. Wenn, dann will ich schon auch Ethernet, DRAM, gerne SDCard und ebenfalls gerne USB und Video out. Gibt es eigentlich eine Übersicht was so an FPGAs draussen in der Industrie verbreitet ist? Und wie oft überhaupt eine CPU verwendet wird und wie oft das FPGA für Gluelogic oder eben sonst wie ohne CPU genutzt wird? Ich habe schon viele Einsteigerprojekte mit NIOS oder Microblaze gesehen. Fast immer lässt sich der gleiche Funktionsumfang auch ohne CPU erreichen. Ausnahmen sind so Dinge wie USB und Ethernet die eben ohne CPU irre komplex würden. Oder ein Dateisystem.
Gustl B. schrieb: > Gibt es eigentlich eine Übersicht was so an FPGAs draussen in der > Industrie verbreitet ist? Umsatzzahlen (in Mio. USD): Actel (2006) 190 Lattice (20xx) 386 Altera (2010) 1954 Xilinx (2015) 2213 Scheint also gekauft zu werden, auch wenn die Zahlen schon etwas älter sind. Duke
Gustl B. schrieb: > Ich habe da tatsächlich etwas Angst, dass ich mit einem AXI System mit > DMA und allem etwas die Kontrolle über meine Bits verliere. Ja, das kann ich nachvollziehen, es ist ja dann auch kein kleines Design mehr. Aber im FPGA hast du wenigstens die Chance zu verstehen wo deine Bits herumwandern, wenn du einen ARM SoC kaufst und den programmierst ist das auch sehr komplex zum Nachvollziehen. > Und auch, dass ich dann Schwierigkeiten bekomme an das System aus Xilinxblöcken > meine eigenen HDL Blöcke ohne AXI anzuschließen. Aber mal gucken. Einfach mal machen, tönt wilder als es in Wirklichkeit ist. Guck dir mal so ein AXI Template an, das dir Vivado generiert, du hast in der Zwischenzeit schon komplizierteres selber geschrieben :-) > Ein Board mit Zynq steht auf der Wunschliste, da werde ich dann mal > ausprobieren wie man eigene HDL so verbindet, dass man dann aus dem > Linux heraus mit diesen reden kann. Wir benutzen hier fleissig das MicroZed von Avnet. Ist ab ca. 120 € zu haben aber schon mit Ethernet/USB/MicroSD Anschlüssen und guter Dokumentation. Einen Xilinx kompatiblen JTAG Adapter brauchst du noch zusätzlich.
Christoph Z. schrieb: > MicroZed von Avnet Das sieht brauchbar aus ... aber http://zedboard.org/sites/default/files/product_spec_images/block_diagram.jpg was sind Multiplexed I/Os? Was das bedeutet ist mir schon klar, aber was bedeutet das in der Realität für den Durchsatz an USB und Ethernet? Und wie ist das mit den verschiedenen Zynq Familien: Leben Zynq 7000 und Zynq Ultrascale+ nebeneinander oder sind die US+ die Nachfolger? Und ... gibt es einen sehr guten Grund (Killerfeature der US+ oder schlimmen Bug der 7000er) die 7000er Serie zu meiden und gleich mit US+ anzufangen? Die 7000er Serie gibt es bei den kleineren Modellen leider nicht mehr im 1,0 mm BGA, die größeren schon, aber das sind dann so viele IOs, dass 6 oder mehr Lagen zwingend werden. Bei US+ gibt es eigentlich nur Modelle mit sehr vielen IOs. Ist aber erstmal egal ... in den nächsten Projekten mache ich erst mal USB3 und ADC mit SerDes mit den Spartan Steinen die ich noch rumliegen habe. Und kaufe mir vielleicht ein ZYNQ Board.
Ein kleiner Verweis auf das TRM Kapitel 2.5: http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf Gustl B. schrieb: > Was das bedeutet ist mir schon klar, aber was > bedeutet das in der Realität für den Durchsatz an USB und Ethernet? Ich schaetze mal, erstmal garnichts. In der Regel ist es als Anfaneger erstmal schwer einen solch maechtigen FPGA wie den Zynq wirklich auszureizen, zumal im Hobby Bereich eher erstmal gespielt und probiert wird. Bis du den Zynq an seine Grenzen bringst, bist du wahrscheinlich shcon so tief drin, dass du im Vorfeld aus den Data Sheets ablesen kannst, welcher FPGA deine Anforderungen erfuellt. Daher einfach mal machen, ein Zedboard oder Zynqberry kosten jetzt nicht die Welt. Da gibt es ganz andere Kaliber bei denen man 5mal nachdenkt bevor man zugreift.
Naja, du hast Recht was den PL Teil angeht, aber USB und Ethernet hängen an den ARM Kernen. Wie man unter Linux eine Netzwerkverbindung auslastet ist mir schon bekannt. Aber gut, stimmt, ich werde da nicht die volle Datenrate benötigen wenn ich mir das erstmal nur angucke. Ja, ich werde mir sowas mal shoppen gehen ...
Gustl B. schrieb: > was sind Multiplexed I/Os? Zuerst: Dedicated I/Os sind PL Pins die genau nur diese eine Funktion können, z. B. das DDR RAM muss genau an diese Pins. Multiplexed I/Os: Da gibt es gewisse Flexibilität, an welchem Pin welche Funktion dranliegt. Das macht es einfacher zum Layouten. Hardware mässig liegt also zwischen den verschiedenen Cores und den Pins noch ein grosser Multiplexer, mit dem dann das Pinout verändert werden kann. Gibt es heute bei diversen grösseren CPUs, kenne das z. B. vom CPU auf dem BeagleBone Black. Hat also nichts mit Durchsatz zu tun. Gustl B. schrieb: > Leben Zynq 7000 und Zynq Ultrascale+ nebeneinander oder sind die US+ die > Nachfolger? Und ... gibt es einen sehr guten Grund (Killerfeature der > US+ oder schlimmen Bug der 7000er) die 7000er Serie zu meiden und gleich > mit US+ anzufangen? Ja, die leben nebeneinander. Wie du schon gemerkt hast, ist der 7000er ein mittleres Eisen (Fabric ist glaub wie beim Artix-7) und der US+ Zynq ist ein dickes Eisen. US+ hat 64 bit ARM Cores und hat (wenn vorhanden) die dickere GPU.
bzgl. AXI (4-lite), schau mal da: https://github.com/Architech-Silica/Designing-a-Custom-AXI-Master-using-BFMs Ist eigentlich nicht schwierig, damit kannst du mal den Simulator fuettern und deinen Design testen. Hab' ich hier auch verwendet und funktioniert. Design war 'halt auf Arbeit', deswegen kann ich den nicht hier posten...
Bitte 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.