Ich verwende zwei synchrone FiFos (Wegen der Portabilität
gh_fifo_sync_sr.vhd aus der OpenCores GH-Lib) als "Verzögerungsleitung"
(512x16 Bit, zwei Kanäle). Die FiFos werden mit einer erwarteten Warnung
(signal "empty" unconnected) synthetisiert. Gemapped wird der FiFo von
ISE auf RAMB18E1. Dabei irritieren mich im Map-Report, PAR-Report,
DRC_unrouted etc. jeweils 40 Warnungen über "loadless Signals" für jede
FiFo-Unit (Mram_ram_mem1_RAMD_O bis Mram_ram_mem40_RAMD_O, siehe
angehängte Textmeldungen).
Wie ist das möglich - es müssen doch alle Speicherelemente durchlaufen
werden? Oder enthält das Mapping mehr als nur die benötigten 512
RAM-Zellen? Wie muss ich diese Warnungen bewerten? (Tatsächlich gibt es
solche "loadless" Warnungen auch noch für anderen Speicher im Block RAM
- hat das evtl. gar nicht unmittelbar mit den FiFos zu tun?)
Tobias B. schrieb:> Welchen FPGA verwendest du? Und kannst du vielleicht mal das komplette> Design hochladen?
Artix7-100. Das Design ist noch lange nicht komplett, aber bereits jetzt
recht sehr umfangreich, da wird sich kaum jemand außer mir durchwühlen
wollen. Das Modul in dem der FiFo angesteuert wird (implementiert eine
Sliding DFT) sowie die Dateien für dessen TB (tb_sDFT.vhd) habe ich
angehängt (hoffentlich nichts vergessen).
Was mir nicht in den Kopf will - bei einem FiFo muss doch ein Signalwort
immer den ganzen Speicher durchlaufen, wie ist es da möglich, dass
Speicherelemente ausgelassen werden? In der Testbench ist zu sehen, dass
das einmal initialisierte FiFo nach jedem "write" voll ist, also 512
Worte gespeichert werden.
> Besser nicht, nimm numeric_std!
Mach ich so in meinem Code. Fremde Module, die lediglich std_logic und
std_logic_vector<> im Interface verwenden, fasse ich nicht an.
Am besten waere das komplette Design zu zippen, so dass man es direkt
starten kann und sich mal anschauen kann was da genau passiert. Wenn ich
jetzt jede Datei einzeln runterladen muss und ein neues Projekt
erstellen, ist das nicht mehr nebenei gemacht und die Lust zu helfen
sinkt deutlich.
Am besten waere es ein Minimalbeispiel zu machen.
Burkhard K. schrieb:>> Besser nicht, nimm numeric_std!> Mach ich so in meinem Code. Fremde Module, die lediglich std_logic und> std_logic_vector<> im Interface verwenden, fasse ich nicht an.
Das eine hat mit dem anderen nichts zu tun. Es gibt gute Gruende auf
std_logic_arith und std_logic_unsigned zu verzichten. Einfach mal die
Diskussionen zu dem Thema hier im Forum durchwuehlen.
Ein bisschen Lesestoff zu dem Thema gibt es hier:
https://www.nandland.com/articles/std_logic_arith_vs_numeric_std.htmlBeitrag "IEEE.STD_LOGIC_ARITH.ALL obsolete"
Wenn ich https://www.xilinx.com/support/answers/22088.html richtig
deute, ist das von mir vermutete Problem wohl gar keins. Offensichtlich
werden nicht alle Anschlüsse eines BELs (oder wie das Element auf dem
Fabric korrekt heißen mag) benötigt und daher auch nicht geroutet. Warum
Map meint, diesen Hinweis mit Severity "WARNING" versehen zu müssen,
steht auf einem anderen Blatt.
Tobias B. schrieb:> Das eine hat mit dem anderen nichts zu tun. Es gibt gute Gruende auf> std_logic_arith und std_logic_unsigned zu verzichten.
Klar - aber auch ein Grund "proven" Legacy-Code - der "Klarheit" wegen -
umzuschreiben?
Burkhard K. schrieb:> Wenn ich https://www.xilinx.com/support/answers/22088.html richtig> deute, ist das von mir vermutete Problem wohl gar keins. Offensichtlich> werden nicht alle Anschlüsse eines BELs (oder wie das Element auf dem> Fabric korrekt heißen mag) benötigt und daher auch nicht geroutet. Warum> Map meint, diesen Hinweis mit Severity "WARNING" versehen zu müssen,> steht auf einem anderen Blatt.
Da geht es um MGTs. Aber prinzipiell war das die Intention fuer die
Projekt Dateien, dann kann man das mal genauer nachschauen was er nicht
anschliesst und dann sieht man auch warum.
Burkhard K. schrieb:> Tobias B. schrieb:>> Das eine hat mit dem anderen nichts zu tun. Es gibt gute Gruende auf>> std_logic_arith und std_logic_unsigned zu verzichten.>> Klar - aber auch ein Grund "proven" Legacy-Code - der "Klarheit" wegen -> umzuschreiben?
In dem Fall ja, gerade wenn man wert auf Portierbarkeit zwischen FPGA
Tools und Vendor Tools legt. Ausserdem laeuft die Aenderung ja durch die
CI Kette durch und deine Unit Tests sagen dir ob die Aenderung den Code
gebrochen hat oder nicht.
Und wenn es eine solche KEtte nicht gibt, wuerde ich den Code niemals
als "proven" deklarieren. ;-)
Eine eigene Frage?
Dieser Thread ist über 6 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
gh_fifo_sync_sr_1.png
(150 KB)
