Ich habe aktuell ein Design, in dem ich mehrere FFTs unterschiedlicher
Länge berechnen muss. Um die Latenz möglichst gering zu halten, wollte
ich dafür mehrere xFFT-Cores mit "generate" instantiieren (anhand von
generics konfiguriert), die dann parallel mit Daten gefüttert werden
können.
Leider scheitert es aber schon am einbinden der Library:
1
libraryieee;
2
useieee.std_logic_1164.all;
3
useieee.numeric_std.all;
4
5
LIBRARYxfft_v9_0_10;
6
USExfft_v9_0_10.xfft_v9_0_10;
Mit dem vollem use-Statement (kopiert aus den generierten
Synthese-Dateien des Cores) liefert er einen Fehler und sagt:
1
can not find <xfft_v9_0_10> in library <xfft_v9_0_10>.
2
Please ensure that the library was compiled,
3
and that a library and a use clause are present in the VHDL file
USE xfft_v9_0_10.all wird nicht als Fehler markiert, allerdings findet
er dann den Core auch nicht.
Kennt da irgendjemand von euch eine Lösung?
Zur Not muss ich alle xFFTs von Hand oder per TCL Skript erstellen und
Konfigurieren...
Hi
die Xilinx IPs hast du doch irgendwo schon kompiliert oder nicht? Im
Grunde sind die auch bloss generische Module die du per GENERIC dann für
den eigenen Geschmack konfigurierst.
Du bindest ein Library aber wo ist die? Beim Modelsim kannst du über den
"modelsim.ini" Datei auf Libraries verweissen.
Oder du definierst die FFT als Komponente und dann beim "vsim" Aufruf
verweisst du mittels das "-L" Option welche Library zu durchsuchen wäre.
Die Library musst natürlich in "modelsim.ini" bzw. dein lokales ".ini"
Datei aufgelistet sein.
Gruss
Valko Z. schrieb:> die Xilinx IPs hast du doch irgendwo schon kompiliert oder nicht?
Hier scheint der Hase im Pfeffer begraben zu sein:
*1. Versuch : verschlüsselte VHDL-Dateien hinzufügen*
Was ich bisher an Dateien zum IP-Core gefunden habe sind im Prinzip jede
Menge verschlüsselter tcl-Skripte, die aber mehr mit Konfiguration,
Darstellung und Generierung der Sonstigen "Output Products" zu tun haben
zu scheinen, und einen Ordner
"Vivado\2016.2\data\ip\xilinx\xfft_v9_0\hdl", in dem die verschlüsselten
vhdl-Dateien
xfft_v9_0.vhd (22 KB)
xfft_v9_0_vh_rfs.vhd (ca. 5MB)
liegen.
Das sind meiner Meinung nach die passenden Dateien, die er sucht.
Wenn ich diese naiv einfach mal dem Projekt als "source" hinzufüge,
unterstreicht er mir zwar "USE work.xfft_v9_0_10;" nicht, aber auf der
dritten Instantiierungsebene (wenn ich das mal so nennen darf) findet er
diverse Module nicht mehr, da sie natürlich in "work" und nicht in
"xfft_v9_0_10" liegen.
*2. Versuch: IP-Ordner hinzufügen*
Wenn ich den ganzen IP-Ordner als Repository hinzufüge, bringt mir das
auch nichts, der FFT-Core erscheint dann erwartungsgemäß zweimal im
IP-Catalog.
*3. Versuch: Vorkompilierte Libraries*
Vorkompilierte Libraries habe ich inzwischen auch gefunden (.vdbl und
.vdbx-Dateien), aber sind die nicht nur für die Simulation gedacht? Und
wenn sie doch korrekt sind, wie würde ich sie Vivado bekannt machen?
Wenn ich sie als source hinzufüge, werden sie erstmal unter "unknown"
einsortiert, Vivado scheint mit diesen Dateitype gar nichts anfangen zu
können. Sie liegen auch in einem Ordner für den Simulator.
Der Witz ist ja: Wenn ich per IP-Catalog einen xFFT-Core hinzufüge,
steht in dem vorkonfigurierten Modul, dass man dann instantiieren darf,
offenbar funktionierender VHDL-Code. Kopiere ich diesen Code in eine
eigene VHDL-Datei im selben Projekt, findet er den Core aus der neuen
Datei nicht, aus der alten (generierten und leider schreibgeschützten)
Datei aber schon. Im Prinzip müsste die Library dem Projekt dann also
bekannt sein - ist sie auch, aber irgendwie auch nicht.
Simon, beantworte die Frage, die man Dir stellt!
Geht es um das Simulieren? Dazu gibt es eine SimList.vhdl, die erzeugt
wird.
Geht es um die Synthese? Dann muss die Defaullib eingebunden werden und
der Core mit seinem XCI / VHO.
Simon L. schrieb:> vhdl-Dateien> xfft_v9_0.vhd (22 KB)> xfft_v9_0_vh_rfs.vhd (ca. 5MB)> liegen.>> Das sind meiner Meinung nach die passenden Dateien, die er sucht.
Die brauchst du für die Simulation, daher nehme ich mal an, dir geht es
um Simulation.
Vivado liefert beim Generieren eines Cores unter
<project_path>/<project_name>.ip_user_files/sim_scripts/<simulator>
die Skripte mit, welche die notwendigen Bibliotheken so kompilieren, das
die dann auch vom Simulator gefunden werden.
Ich will das ganze Simulieren und Synthetisieren können. (Zur Not reicht
auch Synthese)
Weltbester FPGA-Pongo schrieb im Beitrag #4625081:
> Geht es um die Synthese? Dann muss die Defaullib eingebunden werden und> der Core mit seinem XCI / VHO.
Das wäre der 'normale' Weg, aber genau das will ich ja nicht. Die
VHO-Datei ist nur das normale Instantiierungstemplate, dass ich nach
der Konfiguration des Cores bekomme, und verweist wiederum auf die
Synthese-Datei xfft_[beliebigername].vhd (die den Core direkt als
Component einbindet) welche aber schreibgeschützt und vorkonfiguriert
ist.
@VHDL hotline:
Ich habe mal nachgeschaut, der entsprechende Ordner ist bei mir
vorhanden aber leer.
Ich habe langsam den Eindruck, dass der Weg, den ich gehen will, einfach
nicht vorgesehen ist...
Nur um das nochmal klarzustellen: Wenn ich per IP-Catalog einen Core
hinzufüge, muss ich ihn direkt konfigurieren und bekomme ein
Instantiation Template z.B. xfft_0.vho.
Normalerweise würde man dass jetzt einbinden.
Ich will aber den Core dynamisch konfigurieren und den Core genauso
ansprechen, wie es das Instantiation Template macht, also (gekürzt)
Simon L. schrieb:> Ich habe mal nachgeschaut, der entsprechende Ordner ist bei mir> vorhanden aber leer.
Da steht erst was drin, wenn du den Core im Projekt über den Standardweg
generiert hast. Ich habe testweise gerade mal so einen FFT-Core bei mir
generiert und finde dann die entsprechenden Skripte.
Simon L. schrieb:> Wenn ich diese naiv einfach mal dem Projekt als "source" hinzufüge,> unterstreicht er mir zwar "USE work.xfft_v9_0_10;" nicht, aber auf der> dritten Instantiierungsebene (wenn ich das mal so nennen darf) findet er> diverse Module nicht mehr, da sie natürlich in "work" und nicht in> "xfft_v9_0_10" liegen.
Dann kompilier das ganze doch in die library xfft_v9_0_10. Allerdings
deuten die generierten Sachen bei mir darauf hin, dass der xfft wiederum
auf andere IPs zugreift, so dass die alle kompiliert werden müssen. Was
und in welche library steht in den entsprechend generierten Skripten.
Ich glaube das ist wirklich nicht vorgesehen. Bei einer PLL würde das
noch gehen, weil da die Primitiven verwendet werden, aber bei sowas
komplexem wie FFT schon nicht.
Ich fürchte da musst du den TCL Weg nehmen, darüber lassen sich ja Cores
bauen. Oder halt die XCO Dateien selbst erzeugen. Nicht schön, aber
wahrscheinlich gangbar.
Ich habe doch noch eine Lösung gefunden:
1) Verschlüsselte Source-Dateien des IP-Cores als Source importieren
2) "Library"-Name in den Source File Properties entsprechend der
gesuchten Library setzen (bei mir also xfft_v9_0_10). Manchmal muss man
den gesuchten Librarynamen etwas kürzen. "_viv" am Ende wird z.B. nicht
benötigt.
3) In der "Hierarchy" "Show only missing Sources" aktivieren (hilft
enorm) und für jede fehlende Source-Datei wieder bei 1) beginnen
Zwischenzeitlich wird das Aktualisieren der Hierarchie schon mal sehr
langsam (offenbar abhängig von der Anzahl der aktuell fehlenden
Sources). Sobald man alle hat ist es aber wieder bedienbar.
Bei der FFT kam dann leider noch ein Fehler aus einer verschlüsselten
Datei*. Wie sich herausstellte fehlte noch eine weitere Library
'xbip_utils_v3_0_6', die von Vivado aber nie als missing source
angemeckert worden war.
Das Design synthetisiert bei mir inzwischen fehlerfrei :-)
Danke für alle eure Beiträge!
*Die Fehlermeldungen bei verschlüsselten Dateien sind echt auf maximale
Unbrauchbarkeit getrimmt: Hallo, da ist ein Fehler aufgetreten, aber ich
verrate dir noch nicht mal den Typ des Fehlers!