FIR Filter aus CoreGen einbinden

[Micha (Gast)]

Hallo zusammen,
ich glaube ich bin mitlerweile ein gutes Stück weiter als noch vor ein 
paar Wochen. Trotzdem habe ich noch einige Probleme mit dem Core 
Generator.
Ich habe mir den fir_compiler_v5_0 vorgenommen und versucht einzubinden. 
Mein Quellcode sieht derzeit wie folgt aus:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity FilterTM is -- Hier werden die Ausgangsports definiert.
  port (  clk        : in     std_logic; -- Clock Eingangssignal
       din       : in      std_logic_vector(15 downto 0); -- Signal vom A/D Wandler
       dout       : out   std_logic_vector(13 downto 0) -- Signal zum D/A Wandler
     );
end FilterTM;

architecture Behavioral of FilterTM is

signal rfd          : std_logic; -- Daten schreiben für fir_compiler
signal rdy          : std_logic; -- Daten fertig berechnet für fir_compiler

component fir_compiler_v5_0
  port (
  clk: in std_logic;
  rfd: out std_logic;
  rdy: out std_logic;
  din: in std_logic_vector(15 downto 0);
  dout: out std_logic_vector(13 downto 0));
end component;

begin


F1 : fir_compiler_v5_0
    port map (
      clk => clk,
      rfd => rfd,
      rdy => rdy,
      din => din,
      dout => dout);


end Behavioral;

rfd und rdy werden noch nicht benutzt. Im Macro Search Path, habe ich 
den entsprechenden Pfad angegeben. Leider bekomme ich folgende Warnings:

WARNING:Xst:2036 - Inserting OBUF on port <dout<0>> driven by black box 
<fir_compiler_v5_0>. Possible simulation mismatch.

Für dout<0> bis dout<13>

Sowie jede Menge von diesen Warnings:
WARNING:NgdBuild:443 - SFF primitive 'F1/blk00000003/blk0000005d' has
   unconnected output pin

Dazu habe ich im CoreGen folgendes im Anhagng befindliches Bild gesehen. 
Ich vermute, das bedeutet tatsächlich, das die entsprechenden Ports 
nicht connected sind.

Kann mir hier jemand weiter helfen?

Danke euch

[Thomas R. (Firma: abaxor engineering) (abaxor)]

Micha schrieb:
> WARNING:Xst:2036 - Inserting OBUF on port <dout<0>> driven by black box
> <fir_compiler_v5_0>. Possible simulation mismatch.


Das Makro wird erst während Ngdbuild eingebunden, darum ist diese 
Warnung normal.

>
> Für dout<0> bis dout<13>
>
> Sowie jede Menge von diesen Warnings:
> WARNING:NgdBuild:443 - SFF primitive 'F1/blk00000003/blk0000005d' has
>    unconnected output pin

Das kann auch ohne folgen sein.

Benutzt dein FIR-Filter einen DSP-Core? Wird das Design gebaut? Wie viel 
benutzte DSP-Cores gibt Map an?

Tom

[Micha (Gast)]

Hallo Tom,

ich benutze einen Spartan 3 FPGA, keinen DSP.

Gruß

PS:

> WARNING:Xst:2036 - Inserting OBUF on port <dout<0>> driven by black box
> <fir_compiler_v5_0>. Possible simulation mismatch.

Diese Warnings habe ich jetzt unter Kontrolle bekommen. Ich habe die vom 
CG generierten Files einfach in das Hauptverzeichnis gelegt und den 
Macro Search Path wieder entfernt.

[Duke Scarring (Gast)]

Micha schrieb:
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
Die Bibliotheken brauchst Du hier gar nicht.

Außerdem siehe: Beitrag "IEEE.STD_LOGIC_ARITH.ALL obsolete"

Duke

P.S.: Die Warnungen würde ich erstmal ignorieren. Läuft die 
Simulation/Testbench ordentlich?

[Thomas R. (Firma: abaxor engineering) (abaxor)]

Micha schrieb:
> ich benutze einen Spartan 3 FPGA, keinen DSP.

Aktuelle FPGAs besitzen DSP-Cores, dein Spartan 3 hat jedoch nur 
Multiplizierer an Bord.

Tom

[Micha (Gast)]

> P.S.: Die Warnungen würde ich erstmal ignorieren. Läuft die
> Simulation/Testbench ordentlich?

Hallo Duke,

wenn ich die Testbench starte, bekomme ich folgende Warnings:

WARNING:HDLCompiler:89 - "xxx" Line 67: <fir_compiler_v5_0> remains a 
black-box since it has no binding entity.
WARNING:Simulator:648 - "xxx" Line 67. Instance fir_compiler_v5_0 is 
unbound

Sie startet zwar, gibt auch was auf den Eingang, der Ausgang bleibt aber 
undefiniert.

Danke

[Bego (Gast)]

Thomas Reinemann schrieb:
> Micha schrieb:
>
>> ich benutze einen Spartan 3 FPGA, keinen DSP.
> Aktuelle FPGAs besitzen DSP-Cores, dein Spartan 3 hat jedoch nur
> Multiplizierer an Bord.
Heissen die bei X nicht immer hochtrabend DSPs"? :-)

Beim S3A DSP zumindest heissen sie so, beinhalten aber auch nicht 
wirklich mehr, als Multiplizierer und etwas Adder-Gedöhns.

Im Xilinx-User-Forum wird gerade philosophiert, wie denn DSP-Elemente in 
der Zukunft aussehen sollten/könnten, um sie leistungsfähiger zu machen. 
Gfs möchte sich jemand dran beteiligen.

Duke Scarring schrieb:
> Micha schrieb:
>> use IEEE.STD_LOGIC_ARITH.ALL;
>> use IEEE.STD_LOGIC_UNSIGNED.ALL;
> Die Bibliotheken brauchst Du hier gar nicht.
Duke, die haut einem xilinx gerne immer wieder rein, besonders, wenn man 
mit System Generator arbeitet. Auch die Anschlüsse der Cores sind sowas 
von obsolete, weil sie einerseits Vektor-basiert laufen (also mit x 
downto 0) mit Bezug zum Vollvektor andererseits das Tool alles auf 1 
normiert. (Auch Phasen / Winkel!!!!!)

Da wird das Durcheinander soagr noch vergrössert und der Mischmasch mit 
alten und neuen Bibs gefördert, statt einfach auf INTEGER und 
Winkelgrade zu 360 Grad zu normieren. Ich habe Xilinx selber schon vor 
über 6 Jahren den Vorschlag gemacht, die Winkel im Sysgen so zu 
bezeichnen und entweder auf Festkomma/Integer mit 360° oder im FP auf 
-PI/+PI einzustellen, was den Anwendungen, in denen FFTs, DDS und NCOs 
verwendet werden viel näher käme. Nix da, man benutzt weiter auf der 
HW-Seite das volle Binärformat und hat dann beim Übergang auf Grade die 
Rundungsfehler.

>FIR Filter aus CoreGen
Hast Du mal die TB laufen lassen, die miterzeugt wird? dort steht der 
Anschlss und die Triggerung drin.

Setze mal Dein "signal rfd          : std_logic; "  auf := '1'; !

den ready kannst du ignorieren, der Latenz-Versatz ist immer derselbe.

[Duke Scarring (Gast)]

Micha schrieb:
> wenn ich die Testbench starte, bekomme ich folgende Warnings:
>
> WARNING:HDLCompiler:89 - "xxx" Line 67: <fir_compiler_v5_0> remains a
> black-box since it has no binding entity.
> WARNING:Simulator:648 - "xxx" Line 67. Instance fir_compiler_v5_0 is
> unbound
Da fehlen noch die generierten Simulationsmodelle im Simulationsprojekt. 
Schau mal im Coregenordner, ob Du was passendes findest. Bei vielen 
Cores wird auch eine readme.txt erzeugt, wo drin steht, welche Datei 
wofür generiert wurde.

Duke

[Duke Scarring (Gast)]

Bego schrieb:
> Duke, die haut einem xilinx gerne immer wieder rein, besonders, wenn man
Hmm. Für mich sah die im EIngangspost erwähnte filterTM nach händischem 
Code aus.

> mit System Generator arbeitet. Auch die Anschlüsse der Cores sind sowas
> von obsolete, weil sie einerseits Vektor-basiert laufen (also mit x
> downto 0) mit Bezug zum Vollvektor andererseits das Tool alles auf 1
> normiert. (Auch Phasen / Winkel!!!!!)
Ansonsten stimme ich Dir zu. Entweder traut sich bei Xilinx niemand den 
Code nochmal anzufassen, oder es sitzt da ein (ganz) alter Hase, nach 
dem Motto: Das haben wir schon immer so gemacht!
:-/

Duke

[Micha (Gast)]

Hallo nochmal,
meine Simulation will einfach nicht laufen (keine Rückgabe des Filters). 
Mag vieleicht mal jemand drüber schaun? Ich habe meinen kompletten 
Ordner angehangen. Das x bei Projekt x steht für den x-ten Versuch.


Diese Warnungen von oben haben sich geklärt.
> WARNING:NgdBuild:443 - SFF primitive 'F1/blk00000003/blk0000005d' has
>    unconnected output pin
Die nicht verbundenen Pins, scheinen sich auf Output Ports zu beziehen, 
welche nicht genutzt werden. Im CoreGen kann man zum Beispiel per Haken 
"ND" aktivieren. Das würde dann wohl auf solche Ports gegeben.

Danke

Gruß

[Weltbester FPGA-Pongo (Gast)]

Da ist ja nicht viel dran, was sollte da nicht laufen?

Ich glaube, Du clockst ständig neue Daten rein, hast aber den Core nicht 
auf pipelined gestellt.