Forum: FPGA, VHDL & Co. Vivado Simulation


von Gustl B. (-gb-)


Lesenswert?

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
von Tobias (. (Gast)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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
von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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
von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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.

von Gustl B. (gustl_b)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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
von Gustl B. (-gb-)


Lesenswert?

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
von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

Hmmm, VUit hat einen Pull Request fuer SPI Support:

https://github.com/VUnit/vunit/pull/425

Vielleicht den pushen, statt selber basteln?

von Duke Scarring (Gast)


Lesenswert?

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
von Gustl B. (-gb-)


Lesenswert?

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.

von Christian R. (supachris)


Lesenswert?

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...

von Gustl B. (-gb-)


Lesenswert?

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.

von Martin S. (strubi)


Lesenswert?

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

von Markus F. (mfro)


Lesenswert?

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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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.

von Martin S. (strubi)


Lesenswert?

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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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

von Gustl B. (-gb-)


Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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

von Gustl B. (-gb-)


Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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

von Christoph Z. (christophz)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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 ...

von Christoph Z. (christophz)


Lesenswert?

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.

von berndl (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.