gh_fifo_sync_sr: loadless signals?

[Burkhard K. (buks)]

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. (Firma: www.elpra.de) (ttobsen)]

Welchen FPGA verwendest du? Und kannst du vielleicht mal das komplette 
Design hochladen?

Und btw:

use IEEE.std_logic_unsigned.all;
USE ieee.std_logic_arith.all;

Besser nicht, nimm numeric_std!

[Burkhard K. (buks)]

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.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

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.html
Beitrag "IEEE.STD_LOGIC_ARITH.ALL obsolete"

[Burkhard K. (buks)]

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?

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

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