Forum: FPGA, VHDL & Co. Vivado Warnung signed cast


von Achim (Gast)


Lesenswert?

Hallo Zusammen,

ich versuche gerade einen bram mit signed-Werten zu initialisieren, aber 
Vivado (2019.1) bestraft mich (wenn g_signed_init true ist) mit der 
Warnung "[Synth 8-5825] expecting unsigned expression". Seht ihr da 
einen Fehler?

1
type t_ram_type is array (0 to 2**12 - 1) of std_ulogic_vector(15 downto 0);
2
3
  function f_ram_init return t_ram_type is
4
    variable v_init : t_ram_type;
5
  begin
6
    for i in t_ram_type'range loop
7
      if g_signed_init then
8
        v_init(i) := std_ulogic_vector(to_signed((i * (2**16-1) / (2**12-1)) - (2**15), 16));
9
      else
10
        v_init(i) := std_ulogic_vector(to_unsigned((i * (2**16-1) / (2**12-1)), 16));
11
      end if;
12
    end loop;
13
    return v_init;
14
  end f_ram_init;

Danke und viele Grüße
Achim

von Gustl B. (-gb-)


Lesenswert?

Warum auch immer eine Variable?! Das ist keine Programmiersprache, mach 
doch ein Signal draus und wieso std_ulogic_vector und nicht 
std_logic_vector? Aber egal.

(i * (2**16-1) / (2**12-1)) - (2**15)
und
(i * (2**16-1) / (2**12-1))

Die Ergebnisse davon sollten ganze Zahlen sein. Wenn nicht verwende real 
(use ieee.math_real.all; ).

Edit:
Bei t_ram_type'range von 2**12 gehen Die Werte dann entweder von -2**15 
bis +2**15 oder von 0 bis 2**16 in Abhängigkeit von g_signed_init.

Bei t_ram_type'range von 2**12 ist der Schritt von einem Wert zum 
nächsten Wert immer 2**16/2**12=2**4=16. Du könntest also auch 
schreiben:
-2**15+i*16
und
i*16

WARNUNG!
Das sollte alles zur Zeit der Synthese fest sein, und nicht irgendwie im 
FPGA dynamisch erzeugt werden sollen, dann wird da nämlich sicher kein 
BRAM verwendet sondern extrem viel Logik. Schleifen in VHDL sind etwas 
komplett anderes als in Software.

: Bearbeitet durch User
von Achim (Gast)


Lesenswert?

Hallo,

> Das ist keine Programmiersprache

Das ist mir bewusst, ich mache den Job nicht erst seit gestern ;)

> Warum auch immer eine Variable?!

Das ist (aus meiner Erfahrung) gängige Praxis und wird, wenn ich mich 
nicht irre, sogar im Xilinx Synthesis Guide so vorgeschlagen. Ich hätte 
ein Generate mit einem Signal machen können, aber das macht a) keinen 
Unterschied und b) hat es mit der Fragestellung nichts zu tun.

> wieso std_ulogic_vector und nicht std_logic_vector

Ich arbeite, wenn ich es nicht bewusst anders benötige (zB Tristates), 
immer mit ulogics. Imo ist es sogar "richtiger", weil zwei Treiber auf 
einem Signal mmn nicht aufgelöst sein müssen. Es erleichtert mir die 
Arbeit.

Ob mit real gerechnet und auf int gecastet oder direkt mit Integer 
gerechnet macht keinen Unterschied. Das Ergebnis ist auch richtig, ich 
wundere mich nur über die Warnung.

Viele Grüße
Achim

von Gustl B. (-gb-)


Lesenswert?

Achim schrieb:
> Das ist mir bewusst, ich mache den Job nicht erst seit gestern ;)

Na dann bist du wohl gerade nur nicht angemeldet. Sorry für die 
Belehrungen. Ich verwende immer Signale und STD_LOGIC. Aber gut, ausser 
dem was ich geschrieben habe ist mir nichts aufgefallen.

Achim schrieb:
> Ob mit real gerechnet und auf int gecastet oder direkt mit Integer
> gerechnet macht keinen Unterschied.

Wusste ich nicht, ich würde da den Cast einbauen.

Achim schrieb:
> Das Ergebnis ist auch richtig, ich
> wundere mich nur über die Warnung.

Es funktioniert also wie gewünscht? Bei Vivado gab es schon in früheren 
Versionen Fehler, das würde ich dann ignorieren.

von Duke Scarring (Gast)


Angehängte Dateien:

Lesenswert?

Achim schrieb:
> Vivado (2019.1) bestraft mich (wenn g_signed_init true ist) mit der
> Warnung "[Synth 8-5825] expecting unsigned expression". Seht ihr da
> einen Fehler?
Nö. ModelSim sieht da auch keinen Fehler:
1
$ vcom ram_test.vhd
2
Start time: 10:13:45 on Sep 24,2019
3
vcom ram_test.vhd
4
Model Technology ModelSim SE-64 vcom 10.6c Compiler 2017.07 Jul 26 2017
5
-- Loading package STANDARD
6
-- Loading package TEXTIO
7
-- Loading package std_logic_1164
8
-- Loading package NUMERIC_STD
9
-- Compiling entity ram_test
10
-- Compiling architecture test of ram_test
11
End time: 10:13:45 on Sep 24,2019, Elapsed time: 0:00:00
12
Errors: 0, Warnings: 0

Vivado würde ich da nicht als VHDL-Referenzumsetzung betrachten.


Gustl B. schrieb:
> Warum auch immer eine Variable?!
In der Initfunktion für einen ROM/RAM ist das vollkommen in Ordnung.


> wieso std_ulogic_vector und nicht std_logic_vector? Aber egal.
Mach ich auch immer so (außer bei tri-states, die nach außen gehen). Da 
meckert schon der VHDL-Compiler, wenn man Signalausgänge miteinander 
verknotet und man muß nicht in der Simulation die 'X' suchen...


Duke

von Achim (Gast)


Lesenswert?

Duke Scarring schrieb:

> Nö. ModelSim sieht da auch keinen Fehler

Danke für's Testen!

Es bleibt jetzt so und die 99+ Warnungen werden wohl oder übel 
ignoriert. Im Moment bin ich echt ein bisschen genervt von Vivado - 
neuerdings (hab vorher immer mit 2016 gearbeitet) verbietet es die 
Division von physical (time) types. Damit ist ein guter Teil meiner 
Bibliotheksfunktionen für die Katz bzw kann ich erstmal abschreiben, was 
der Simulator ausgerechnet hat :-/

Wie auch immer - das ursprünglich Thema ist erstmal erledigt. Danke an 
euch!

Viele Grüße
Achim

von Gustl B. (-gb-)


Lesenswert?

Achim schrieb:
> Im Moment bin ich echt ein bisschen genervt von Vivado -
> neuerdings (hab vorher immer mit 2016 gearbeitet) verbietet es die
> Division von physical (time) types.

Was meinst du damit?

In der Testbench:
signal test: integer range 0 to 1000:=0;
test <= 100ns/5ns;

In der Simulation steht da korrekt 20 drinnen.

Aber:
Einige Projekte die vorher mit 2018.3 problemlos das Timing geschafft 
haben und auch fehlerfrei auf der Hardware laufen schaffen jetzt das 
Timing nicht.
(Eine Division die vorher in einem Takt lief schafft das jetzt nicht 
mehr.)
Es werden mit Vivado 2019.1 sogar etwas mehr Ressourcen verwendet als 
mit 2018.3. Gleicher Code, nur den Projektordner kopiert. Und das 
komplett ohne Xilinx IPs.

Gut wenn ich das Projekt nur stumpf kopiere wird weiterhin im neuen 
Vivado die Vivado 2018 Strategy verwendet. Das Timing wird hier 
schlechter und es braucht mehr Ressourcen. Jetzt habe ich auf die Vivado 
2019 Strategy umgestellt und es ist schon deutlich besser. Das Timing 
wird eingehalten (aber nicht so gut wie bei 2018.3) und es braucht 
gegenüber Vivado 2018.3 sogar etwas weniger Ressourcen. 9% weniger FFs.

: Bearbeitet durch User
von Achim (Gast)


Lesenswert?

Gustl B. schrieb:
> In der Simulation steht da korrekt 20 drinnen.

Klar, ein Simulator muss das können. Aber probiere mal das gleiche durch 
die Synthese zu schicken...

Bei ISE hatte ich damit nie Probleme und mit den "älteren" Vivado 
Versionen musste man noch aufpassen, weil intern mit (wenn ich mich 
richtig erinnere) max 32 Bit gerechnet wurde und ein Überlauf nicht 
abgefangen wurde. Jetzt wird's schlicht nicht mehr unterstützt und das 
finde ich schon ärgerlich :-/

Viele Grüße
Achim

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.