mikrocontroller.net

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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Achim (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

type t_ram_type is array (0 to 2**12 - 1) of std_ulogic_vector(15 downto 0);

  function f_ram_init return t_ram_type is
    variable v_init : t_ram_type;
  begin
    for i in t_ram_type'range loop
      if g_signed_init then
        v_init(i) := std_ulogic_vector(to_signed((i * (2**16-1) / (2**12-1)) - (2**15), 16));
      else
        v_init(i) := std_ulogic_vector(to_unsigned((i * (2**16-1) / (2**12-1)), 16));
      end if;
    end loop;
    return v_init;
  end f_ram_init;

Danke und viele Grüße
Achim

Autor: Gustl B. (-gb-)
Datum:

Bewertung
-1 lesenswert
nicht 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
Autor: Achim (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Gustl B. (-gb-)
Datum:

Bewertung
-1 lesenswert
nicht 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.

Autor: Duke Scarring (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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:
$ vcom ram_test.vhd
Start time: 10:13:45 on Sep 24,2019
vcom ram_test.vhd
Model Technology ModelSim SE-64 vcom 10.6c Compiler 2017.07 Jul 26 2017
-- Loading package STANDARD
-- Loading package TEXTIO
-- Loading package std_logic_1164
-- Loading package NUMERIC_STD
-- Compiling entity ram_test
-- Compiling architecture test of ram_test
End time: 10:13:45 on Sep 24,2019, Elapsed time: 0:00:00
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

Autor: Achim (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht 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
Autor: Achim (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.