Xilinx IP-Cores per VHDL instantiieren möglich?

[Simon L. (dfgh)]

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:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

LIBRARY xfft_v9_0_10;
USE xfft_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:

can not find <xfft_v9_0_10> in library <xfft_v9_0_10>.
Please ensure that the library was compiled, 
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...

[Valko Z. (hydravliska)]

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

[Da D. (dieter)]

Simon L. schrieb:
> liefert er einen Fehler

Wer ist er? ModelSim? Vivado? Der Nachbar von neben an?

[Simon L. (dfgh)]

Vivado markiert mir den Fehler direkt im Quelltext (also auch schon ohne 
Simulation, Synthese etc. durchgeführt zu haben)

[Simon L. (dfgh)]

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.

[Weltbester FPGA-Pongo (Gast)]

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.

[VHDL hotline (Gast)]

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.

[Simon L. (dfgh)]

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)

LIBRARY xfft_v9_0_10;
USE xfft_v9_0_10.xfft_v9_0_10;

ENTITY myEntity IS
  generic(
      FFTlen : integer
  );
  PORT (
      --ports
  );
END myEntity;
ARCHITECTURE meineFFT_arch OF meineFFT IS
  COMPONENT xfft_v9_0_10 IS
    GENERIC (
        -- generics
    );
    PORT (
        --ports
    );
  END COMPONENT xfft_v9_0_10;
BEGIN
    fftinst : xfft_v9_0_10
    GENERIC MAP (
        -- mapping...
        C_NFFT_MAX => FFTlen,
        -- mapping...
    )
    PORT MAP(...);

    ..............
    Mach etwas tolles mit dem FFT-Block
    ..............

END meineFFT_arch;

[VHDL hotline (Gast)]

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.

[Christian R. (supachris)]

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.

[Simon L. (dfgh)]

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!

[Simon L. (dfgh)]

Hier noch die Namen der benötigten Libraries für xFFT_v9_0_10:

xfft_v9_0_10
axi_utils_v2_0_2
c_shift_ram_v12_0_9
c_reg_fd_v12_0_2
c_mux_bit_v12_0_2
c_addsub_v12_0_9
xbip_addsub_v3_0_2
xbip_dsp48_addsub_v3_0_2
xbip_dsp48_wrapper_v3_0_4
floating_point_v7_0_12
xbip_pipe_v3_0_2
mult_gen_v12_0_11
cmpy_v6_0_11
xbip_utils_v3_0_6