IEEE.STD_LOGIC_ARITH.ALL obsolete

[Dirk (Gast)]

Hallo,

ich schreibe gerade an meiner Bachelor-Thesis und in diesem zusammenhang 
würde ich gerne in meiner Arbeit darauf hinweisen das 
IEEE.STD_LOGIC_ARITH.ALL obsolet ist. (Schreibt zumindest der gute 
Lothar Miller ;) ) Dafür bräuchte ich natürlich irgendwie eine Quelle. 
Schön wäre da natürlich irgendwas offizielles.

Weiß jemand wo von offizieller Seite her steht, dass die "gerne noch 
verwendeten Quasi-Industrie-Standards der Synopsis-Lib [..] schon 
geraume Zeit obsolete" (Zitat Lothar Miller  :D ) sind?

Vielen Dank
Dirk H.

[Mathi (Gast)]

Das steht in den Büchern von Peter Ashenden. Und er ist Mitglied in 
diversen IEEE-Gremien betreffend VHDL...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> ... das IEEE.STD_LOGIC_ARITH.ALL obsolet ist.
> (Zitat Lothar Miller  :D )
Ein schönes Zitat....
Sagen wir mal so: für mich ist sie obsolote, weil herstellerabhängig und 
doppeldeutig. Mein Anhaltspunkt ist der, dass im Kopf der 
numeric_std.vhd folgendes steht:
-- Copyright 1995 by IEEE. All rights reserved.
Das ist eine vom IEEE genormte Library.

In der std_logic_arith.vhd steht dagegen:
-- Copyright (c) 1990,1991,1992 by Synopsys, Inc.  All rights reserved. 
--

Das allerwichtigste aber ist:
MAN RECHNET NICHT MIT UNEINGESCHRÄNKTEN VEKTOREN.
Denn die std_logic_arith.vhd allein reicht ja nicht aus. Es muß dann 
immer noch dazu gesagt werden, ob mit der Vektorarithmetik signed oder 
unsigned gemeint ist. Siehe dazu z.B. den 
Beitrag "Re: Problem mit FSM"

Und dort findet sich auch der erhobene Zeigefinger ( nicht meiner ;-)
http://www.mikrocontroller.net/articles/Rechnen_in_VHDL#Schlecht:_Direktes_Rechnen_mit_std_logic_vector

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Mathi schrieb:
> Das steht in den Büchern von Peter Ashenden.
Bzw. es steht nichts zur std_logic_arith in seinen Büchern ...  :-o

[Duke Scarring (Gast)]

@Dirk:

Ein Quelle, aber nicht direkt offiziell:
http://www.eda.org/comp.lang.vhdl/FAQ1.html#4.11

Duke

[Dirk (Gast)]

Hallo,

ich habe jetzt mal etwas zu dem Thema in meiner Thesis geschrieben (ist 
an unserer Hochschule dringend nötig). Was sagt ihr denn dazu?

An dieser Stelle soll darauf hingewiesen werden, dass nur Funktionen aus 
den Bibliotheken IEEE.STD LOGIC 1164 und IEEE.Numeric STD (IEEE 1076.3) 
genutzt werden, was generell zu empfehlen ist. Die häufig verwendeten 
Synopsis Bibliotheken (STD LOGIC ARITH, STD LOGIC UNSIGNED) sollten 
möglichst nicht verwendet werden (siehe [18]), da sie weder
herstellerunabhängig sind, noch der strengen Normung einer 
internationalen Organisation unterliegen. Außerdem geht aus einer 
Berechnung selbst nicht das tatsächlich resultierende Bitmuster hervor, 
da es je nach eingebundener Bibliothek (signed oder unsigend) 
unterschiedlich ist.

Grüße
Dirk H.

[Dirk (Gast)]

..ich sollte mich Zwecks Editierung mal hier anmelden +duck+..

kleiner Nachtrag: Quelle[18] ist der von Duke gepostete Link 
(http://www.eda.org/comp.lang.vhdl/FAQ1.html#4.11)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> ... tatsächlich resultierende Bitmuster hervor ...
Das kannst du bedenkenlos verallgemeinern:
... tatsächlich resultierende Ergebnis hervor ...

Und das letzte ist ist nur ein sein kann   ;-)

[... (Gast)]

Von mir aus:

LIBRARY IEEE;
use IEEE.std_logic_1164.all;
--use IEEE.std_logic_unsigned.all;
--use IEEE.std_logic_arith.all;
use IEEE.NUMERIC_STD.ALL;

[FPGAaaaah (Gast)]

Also ich habe in meinem VHDL-Code folgende Libraries entfernt:
STD_LOGIC_ARITH
STD_LOGIC_UNSIGNED

und dafür die NUMERIC.STD hinzugefügt und bei der Synthese in icecube2 
(nutzt Synopsis Synthese Tool) gabs eine Fehlermeldung, wegen der 
folgenden Zuweisung:
cnt <= cnt + 1;

cnt ist ein std_logic_vector.

[Lua (Gast)]

FPGAaaaah schrieb:
> cnt ist ein std_logic_vector.

Genau das ist das Problem.
cnt sollte dann vom typ unsigned (oder signed) sein.

[FPGAaaaah (Gast)]

Achso. Ja stimmt, sehe ich auch gerade! Danke!

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

Ich hab zu dem Thema mal meine Lieblingszusammenfassung angehaengt. :-)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Hier gibt's das Original und ein paar Worte in Richtung "real":

http://www.lothar-miller.de/s9y/archives/14-Numeric_Std.html

;-)

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

Lothar M. schrieb:
> Hier gibt's das Original und ein paar Worte in Richtung "real":
>
> http://www.lothar-miller.de/s9y/archives/14-Numeric_Std.html
>
> ;-)

Ahhhh, Danke! :-)

[pittiplatsch (Gast)]

> http://www.lothar-miller.de/s9y/uploads/Bilder/Usage_of_numeric_std.jpg
----------------------------------------------------------------------^^ 
^

Das kann man so nicht stehen lassen!

[Unbeteiligter (Gast)]

noch ne Quelle:
https://insights.sigasi.com/tech/deprecated-ieee-libraries/

[Klaus S. (kschleisiek)]

FPGAaaaah schrieb:
> Also ich habe in meinem VHDL-Code folgende Libraries entfernt:
> STD_LOGIC_ARITH
> STD_LOGIC_UNSIGNED
>
> und dafür die NUMERIC.STD hinzugefügt

Ich habe mich auch zunächst verwirren lassen, dass NUMERIC_STD die 
ultima ratio ist. Bis ich versucht habe, alten Code mit den Synopsys 
Bibliotheken zu portieren. Das will man wirklich nicht. Und dann ist mir 
klar geworden, wie man damit umgehen kann:

Man nimmt primär erstmal SIGNED oder UNSIGNED. Das macht ganz viel 
sinnvolles operator overloading. Diese Bibliotheken fallen aber auf die 
Nase, wenn es irgendwo eine Sequenz gibt, die eigentlich die 
gegenteilige "Polarität" braucht. Dann kommt NUMERIC_STD zu Hilfe, weil 
man sich das dann präzise zusammenbasteln kann - was üblicherweise zu 
langen, schwer lesbaren Zeilen führt - aber es geht ohne weitere 
Verrenkung und das ganz präzise.

Seitdem sehen meine Header so

LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.STD_LOGIC_SIGNED.ALL;
USE IEEE.NUMERIC_STD.ALL;

oder so aus

LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.STD_LOGIC_UNSIGNED.ALL;
USE IEEE.NUMERIC_STD.ALL;

Fazit: Es ist ziemlich dämlich, die Synopsys-Bibliotheken als veraltet 
zu bezeichnen. Kann ich mir aber für einen Akademiker, der keinen Code 
ans Laufen bringen muss, gut vorstellen ;)

[Gustl B. (-gb-)]

Die USE IEEE.STD_LOGIC_SIGNED.ALL; und USE IEEE.STD_LOGIC_UNSIGNED.ALL; 
kannst und solltest du auch weglassen. Trotzdem kannst du weiterhin 
unsigned und signed verwenden.

--------------

Aber ich habe auch eine Frage:
VHDL kennt auch ohne Zusatzpackages integer. Gibt es da auch "native" 
Konvertierungsfunktionen und kann man mit denen rechnen? Ohne die 
numeric_std oder sonst was zu nutzen.

[Klaus S. (kschleisiek)]

Gustl B. schrieb:
> Die USE IEEE.STD_LOGIC_SIGNED.ALL; und USE IEEE.STD_LOGIC_UNSIGNED.ALL;
> kannst und solltest du auch weglassen. Trotzdem kannst du weiterhin
> unsigned und signed verwenden.

Danke für den Hinweis. Das gilt aber nur für zukünftigen Code. Insofern 
ist das "veraltet" wohl doch wahr.

Mein alter Code nutzt aber nur STD_LOGIC_VECTOR - und das auf 
NUMERIC_STD zu portieren - nein, das will man sich nicht antun.

[Gustl B. (-gb-)]

Klaus S. schrieb:
> Mein alter Code nutzt aber nur STD_LOGIC_VECTOR - und das auf
> NUMERIC_STD zu portieren - nein, das will man sich nicht antun.

Das musst du auch nicht, denn STD_LOGIC_VECTOR wird durch die 
IEEE.STD_LOGIC_1164 abgedeckt. Sollte also problemlos gehen. Du musst 
deinen Code nur umschreiben wenn du direkt mit den std_logic_vectors 
gerechnet hast, dafür hast du nämlich die IEEE.STD_LOGIC_ARITH 
verwendet.

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

Klaus S. schrieb:
> Fazit: Es ist ziemlich dämlich, die Synopsys-Bibliotheken als veraltet
> zu bezeichnen. Kann ich mir aber für einen Akademiker, der keinen Code
> ans Laufen bringen muss, gut vorstellen ;)

Der Punkt ist nicht, dass die veraltet sind und man sie deshalb nicht 
nehmen sollte. Der Punkt ist, dass die nicht ordentlich standartisiert 
sind und man deshalb zwangslaeufig Kompatibilitaetsprobleme bekommt. Ein 
Artikel das der leicht verstaendlich herunterbricht ist hier zufinden:

https://insights.sigasi.com/tech/deprecated-ieee-libraries/

BTW: STD_LOGIC_SIGNED / STD_LOGIC_UNSIGNED und NUMERIC_STD zu mischen, 
ist so ziemlich der unguenstigste Weg den du gehen kannst.

Ich sehe auch nicht wo das Problem in der Verwendung von NUMERIC_STD 
liegt. Viel einfacher kann man mit Signeds, Unsigneds und Integers kaum 
arbeiten. Hast du vielleicht ein paar konkrete Beispiele was dich zu 
diesem Schritt veranlasst? Dann koennen vielleicht ein paar der 
erfahreneren VHDLer hier aus dem Naehkaestchen plaudern was ihre 
Alltagsloesungen sind. :-)

[Duke Scarring (Gast)]

Klaus S. schrieb:
> Seitdem sehen meine Header soLIBRARY IEEE;
> USE IEEE.STD_LOGIC_1164.ALL;
> USE IEEE.STD_LOGIC_SIGNED.ALL;
> USE IEEE.NUMERIC_STD.ALL;
> oder so ausLIBRARY IEEE;
> USE IEEE.STD_LOGIC_1164.ALL;
> USE IEEE.STD_LOGIC_UNSIGNED.ALL;
> USE IEEE.NUMERIC_STD.ALL;
Da hast Du Dir was tolles ausgedacht! (Achtung, ironisch gemeint!)

Der Spaß geht dann los, wenn mehrere Entwickler am Code arbeiten oder 
vorhandener Code von ehemaligen Entwicklern weitergenutzt werden soll.
Der eine nutzt den slv als signed und in der andere Entwickler in der 
nächsten entity als unsigned. Und manchmal wird auch unsigned genommen, 
obwohl die Werte definitiv signed sind (und umgekehrt).

Deine Submodulsimulation geht problemlos durch den Regressiontest, weil 
die den richtigen Input bekommt. Ob die Gesamtsystemsimulation Fehler 
zeigt, ist ungewiss, da dort z.B. nur ein Bruchteil der Testvektoren 
durchgespielt wird.

Ich habe mal in einem größeren recht DSP-lastigen Projekt die 
Bibliotheken glattgezogen und alle std_logic_signed/std_logic_unsigned 
rausgeschmissen. Dank Versionskontrollsystem und Testbenches war das 
Thema relativ schnell abgehackt.

Duke

[Klaus S. (kschleisiek)]

Duke Scarring schrieb:
> Der Spaß geht dann los, wenn mehrere Entwickler am Code arbeiten oder
> vorhandener Code von ehemaligen Entwicklern weitergenutzt werden soll.
> Der eine nutzt den slv als signed und in der andere Entwickler in der
> nächsten entity als unsigned.

Vorbemerkung: In meinem Fall ist es glaube ich noch schwieriger. Erstens 
war ich ja zunächst mal Hardwerker mit viel TTL-Erfahrung. Und dann sehr 
misstrauisch, was die Synthesizer (vor 25 Jahren) angeht. Und deshalb 
habe ich zwar VHDL geschrieben, aber mental weiterhin Gates verbaut. Und 
habe dann langsam mit NATURAL und INTEGER rumhantiert bei Countern. Aber 
SIGNED und UNSIGNED habe ich erst vor 3 Jahren wahrgenommen.

Problem: microCore ist ein Stackprozessor mit Forth als Assembler. D.h. 
die Datenleitungen sind stark vernetzt und bleiben selten innerhalb 
einer Entity. Wenn ich also slv durch z.B. unsigned ersetze, dann hat 
das gleich weiterreichende Folgen. Dazu kommt, das manche Datenpfade 
manchmal signed, manchmal unsigned und manchmal wirklich slv sind je 
nachdem, welche Instruktion ausgeführt wird.

Der Code ist hier: 
https://github.com/microCore-VHDL/microCore/tree/master/vhdl
Und ein Struktogramm der Entities auf Seite 4 hier:
https://github.com/microCore-VHDL/microCore/blob/master/documents/uCore.pdf

Ich bin sehr daran interessiert, den Code zu verbessern, weil er 
öffentlich als IP verbreitet wird und deshalb auch ein Vorbild sein 
sollte.

Heute habe ich wieder einmal versucht, STD_LOGIC_SIGNED/_UNSIGNED 
loszuwerden, aber bereits bei dem einfachen Fall von uAdd.vhd wurde es 
so schwierig, dass ich es wieder gelassen habe. Von uCntrl.vhd und 
uCore.vhd will ich gar nicht erst reden.

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

Klaus S. schrieb:
> Heute habe ich wieder einmal versucht, STD_LOGIC_SIGNED/_UNSIGNED
> loszuwerden, aber bereits bei dem einfachen Fall von uAdd.vhd wurde es
> so schwierig, dass ich es wieder gelassen habe. Von uCntrl.vhd und
> uCore.vhd will ich gar nicht erst reden.

Ich hab dir mal nenn PR fuer uAdd.vhd geschickt. Habs allerdings nicht 
getestet.

[Theor (Gast)]

Klaus S. schrieb:
> [...] microCore ist ein Stackprozessor mit Forth als Assembler.
> [...]

Hi Klaus,
sehr interessant. Danke für den Link.

[Martin S. (strubi)]

Tobias B. schrieb:
> BTW: STD_LOGIC_SIGNED / STD_LOGIC_UNSIGNED und NUMERIC_STD zu mischen,
> ist so ziemlich der unguenstigste Weg den du gehen kannst.

In der Tat. Das Thema hatten wir schon zigfach...
Das Synopsys-Geraffel ist naemlich von Seiten Xilinx auch schon mal 
anders interpretiert worden, wie der momentane Status ist, will ich gar 
nicht wissen.
Das fuehrte dazu, dass signed extensions, wie sie bei MIPS oder RISC-V 
Alltag sind, unterschiedlich ausgelegt werden.
Oder mal wieder den Klassiker auspacken:

resize(unsigned(x), n)

vs

unsigned(resize(x, n))

fuer ein signed x

Dukes Kommentar oben ist zudem zu unterschreiben. Wer std_logic_arith 
mit impliziter Konversion nutzt, sorgt irgendwann dafuer, dass der DSP 
falsch rechnet und isim/xsim was anderes ausspuckt als der 
'Gold-Standard' GHDL.
Leider, leider muss man trotzdem ab und an noch fuer eine Menge 
Legacy-Murks (auch noch vom Platzhirsch X, der sich nicht an den 
Standard haelt) die -ieee-synopsys-Flags aktivieren.

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

Martin S. schrieb:
> Leider, leider muss man trotzdem ab und an noch fuer eine Menge
> Legacy-Murks (auch noch vom Platzhirsch X, der sich nicht an den
> Standard haelt) die -ieee-synopsys-Flags aktivieren.

Das ist leider wahr. Aber Xilinx "loest" das Problem, indem sie die 
neuen Cores praktisch nur noch in Verilog ausliefern. Zum Kotzen.

Ich muss gestehen: Seit ich GHDL fuer Regression Tests einsetze, wird 
auch oefters mal auf ein Verilog-only Xilinx Core verzichtet, sofern es 
die Komplexitaet zulaesst den in endlicher Zeit selbst zu entwickeln. 
Und ganz cool finde ich da die Kunden, welche bereit sind die 
Entwicklung zu bezahlen, aber sich nicht davor straeuben die Cores frei 
zu machen.

Das wird Xilinx zwar herzlich wenig jucken, aber es ist Balsam fuer die 
Seele. :-D

[Klaus S. (kschleisiek)]

Tobias B. schrieb:
> Ich hab dir mal nenn Pull Request fuer uAdd.vhd geschickt.

Hier mal etwas gekürzt der Originalcode:

...
USE IEEE.STD_LOGIC_unsigned.ALL;

ENTITY uAdd IS PORT (
   cin      : IN  STD_LOGIC;
   ladd_x   : IN  STD_LOGIC_VECTOR(data_width   DOWNTO 0);
   ladd_y   : IN  STD_LOGIC_VECTOR(data_width   DOWNTO 0);
   ladd_out : OUT STD_LOGIC_VECTOR(data_width+1 DOWNTO 0)
); END uAdd;

ARCHITECTURE inference OF uAdd IS
BEGIN

ladd_out <= ('0' & ladd_x) + ('0' & ladd_y) + cin;

END inference;

Und hier der von Tobias überarbeitete Code:

...
USE IEEE.numeric_std.ALL;

ENTITY uAdd IS PORT (
   cin      : IN  STD_LOGIC;
   ladd_x   : IN  STD_LOGIC_VECTOR(data_width   DOWNTO 0);
   ladd_y   : IN  STD_LOGIC_VECTOR(data_width   DOWNTO 0);
   ladd_out : OUT STD_LOGIC_VECTOR(data_width+1 DOWNTO 0)
); END uAdd;

ARCHITECTURE inference OF uAdd IS

SIGNAL add_ladd_x : unsigned(ladd_out'range);
SIGNAL add_ladd_y : unsigned(ladd_out'range);

BEGIN

add_ladd_x <= resize(unsigned(ladd_x), add_ladd_x'length);
add_ladd_y <= resize(unsigned(ladd_y), add_ladd_y'length);

ladd_out <= std_logic_vector(add_ladd_x + add_ladd_y + cin);

END inference;

Hmtja. Das ist dann zwar standardisierter Code, aber ich finde ihn 
umständlich und schlecht lesbar. Auf die Lösung war ich auch schon 
gekommen und hatte sie als "too cumbersome" verworfen.

Wenn es aber tatsächlich stimmt, dass mit der Originalversion 
verschiedene Synthesizer und P&Rs abweichende Resultate erzeugen, dann 
muss es halt sein. Ich habe bisher immer mit Synplify gearbeitet und der 
Code lief schon auf Lattice XP2, Actel A3PE, Altera CycloneII, Xilinx 
XC2S und in allen Fällen hatte sich microCore bei mir gemeldet und brav 
seinen coretest.fs absolviert.

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

Ich finde das ehrlich gesagt garnicht unnoetig kompiliziert. Die ersten 
beiden Zeilen bereiten deine Signale darauf vor, dass du die 
Vektorbreite vergroesserst, um das mit dem Ueberlauf in Griff zu 
bekommen und die dritte ist dann ein Einzeiler fuer die Addition.

Du kannst das auch alles in eine Zeile packen, wie es im urspruenglichen 
Code war und fleissig casten. Spaetestens wenn du uAdd auf signed 
umstellen magst, wirst aber sehen, warum der weg mit den resize 
Funktionen aeussert wichtig ist. ;-)

Das ist leider auch ein bisschen die Krux beim FPGA entwickeln. Den 
reinen Hardware Leuten fehlen die Konzepte/Patterns aus der Software und 
bei den Software Leuten ist es umgekehrt. Deshalb wuerde ich oefters mal 
in Open Source Projekten nachschauen, was die so machen und sich 
inspirieren lassen.

Allgemein sieht man an dem Projekt, dass der Code extrem altbacken ist 
und viele Features von VHDL garnicht genutzt werden um den Code klar 
lesbar und elegant zu halten. Ein ordentliches Refactoring ist da 
wirklich zu empfehlen (vorausgesetzt es steht eine Regression Pipeline), 
ist ja zum Glueck jetzt nicht soooo maechtig, dass einen das erschlaegt 
alles.

[Klaus S. (kschleisiek)]

Tobias B. schrieb:
> Ich finde das ehrlich gesagt garnicht unnoetig kompiliziert.

Es ist leider kompliziert, aber noch leiderer nicht unnötig. Ich finde 
den alten Code einfacher zu lesen. Sind ja auch weniger Zeilen. Und 
solange ich hier keinen Erfahrungsbericht sehe, WARUM und WO der Code 
durch Nutzung von STD_LOGIC_SIGNED.ALL von manchen Synthesizern 
fehlinterpretiert wird, werde ich das beibehalten.

> Du kannst das auch alles in eine Zeile packen, wie es im urspruenglichen
> Code war und fleissig casten.

Das wird dann vollends unleserlich. Die zwischengeschaltete 
Faktorisierung finde ich da schon sinnvoll.

> Spaetestens wenn du uAdd auf signed
> umstellen magst, wirst aber sehen, warum der weg mit den resize
> Funktionen aeussert wichtig ist. ;-)

Es ist schon ein signed als auch ein unsigned Addierer. Das hängt nur 
von der Interpretation durch die Software ab (in Forth gibt es dafür < 
und u< für den Größenvergleich). Und statt des resize finde ich, dass es 
('0' & ladd_x) völlig klar macht, das hier im Grunde eine unsigned 
Addition stattfindet. Aber wenn man die oberste (Carry) Stelle weglässt, 
ist der Rest eine klassische 2er-Komplement Addition.

> Allgemein sieht man an dem Projekt, dass der Code extrem altbacken ist.

Ja, ich habe mich viele Jahre lang auf VHDL-93 eingeschränkt, bis ich 
vor kurzem gemerkt habe, dass ich mir dadurch das Leben unnötig schwer 
mache. Ich hatte den Synthesizern nicht getraut, die vor 25 Jahren noch 
wirklich lustige Fehler produzierten.

> Ein ordentliches Refactoring ist da
> wirklich zu empfehlen (vorausgesetzt es steht eine Regression Pipeline).

Das Factoring stimmt schon, da bin ich durch Forth bestens trainiert. 
Aber was zum Teufel ist eine "Regression Pipeline"?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Klaus S. schrieb:
> Und solange ich hier keinen Erfahrungsbericht sehe, WARUM und WO der
> Code durch Nutzung von STD_LOGIC_SIGNED.ALL von manchen Synthesizern
> fehlinterpretiert wird, werde ich das beibehalten.
Sieh dir den Beitrag "std_logic_vector auf integer umwandeln" oder 
den Beitrag "Änderung des Gehäuses erzeugt Compilation Fehler" oder den 
Beitrag "Re: vector mit 0 initalisieren" an.
Da gibts noch mehr derartige Threads, aber inzwischen gewöhnen sich die 
Professoren die numeric_std an, so dass nicht mehr jedes Semester ein 
paar Studenten mit ähnlichen Problemen hier aufschlagen.

> Es ist schon ein signed als auch ein unsigned Addierer.
Dann ist im Prinzip die simple Erweiterung vorne mit '0' aber falsch.
Korrekt müsste das bei dir dann so aussehen:

ladd_out <= (ladd_x(data_width) & ladd_x) + (ladd_x(data_width) & ladd_y) + cin;

> statt des resize finde ich, dass es ('0' & ladd_x) völlig klar macht
Wenn du unbedingt die numeric_std und deren Werkzeuge nicht verwenden 
willst, dann verwende sie einfach nicht. Du musst nicht krampfhaft nach 
Ausreden suchen, warum du das gut findest.

> statt des resize finde ich, dass es ('0' & ladd_x) völlig klar macht
Und zudem wesentlich weniger Codezeilen braucht...
Aber dann musst du dir auch die Frage stellen, warum da ein Addierer 
überhaupt in ein eigenes Modul gesteckt wird, wenn dann nur 1 Zeile die 
Arbeit verrichtet? Die eine Zeile hätte sicher noch eine Ebene höher 
Platz gefunden.

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

Klaus S. schrieb:
> Es ist leider kompliziert, aber noch leiderer nicht unnötig. Ich finde
> den alten Code einfacher zu lesen. Sind ja auch weniger Zeilen. Und
> solange ich hier keinen Erfahrungsbericht sehe, WARUM und WO der Code
> durch Nutzung von STD_LOGIC_SIGNED.ALL von manchen Synthesizern
> fehlinterpretiert wird, werde ich das beibehalten.

Damit tust du deinem Projekt halt mal so richtig keinen Gefallen. 
Schliesslich willst du doch sicherstellen, dass das ganze mit moeglichst 
vielen Toolchains kompatibel ist.

Ein weiteres Problem koenntest du haben, wenn Leute ein Code Review 
machen um zu entscheiden ob der IP Core den eigenen Qualitaetstandards 
genuegt. Ich spreche da mal aus der Medizintechnik, in der man Cores 
ohne Probleme als SOUPs einsetzen kann (auch in Klasse C), man 
allerdings bewerten soll ob die gewuenschte SOUP den 
Qualitaetsanspruechen genuegt. Wenn ich jetzt eine solche atrix 
aufstellen muesste zu Qualitaetsbewertung, dann waere da sehr 
wahrscheinlich ein Punkt mit drin, dass die Verwendung von obsoleten 
Bibliotheken vermieden wird.

Die ehtliche Frage die du dir vll. auch stellen musst: Ist es wirklich 
kompliziert oder ist es einfach nur eine Gewoehnungsfrage? Die FPGA 
Fraktion ist da bekannt dafuer (zumindets habe ich es in meinem 
Berufsleben bisher so kennengelernt), da stur veralteten Pragmatismen zu 
folgen (was sicher auch der Vergangenheit und dem schlechten Support des 
VHDL Sprachumfans in den Entwicklungstools geschuldet ist).

Aber ich will da jetzt auch nicht allzuviel kritisieren. Dein Core - 
dein Bier. ;-)

Tobias B. schrieb:
> Spricht auch stark dafuer, dass der Core nicht via Regressiontests
> validiert wird. Spaetestens da haette es auffallen muessen.

Das sind einfach nur Regression Tests. Das Wort Pipeline hat sich in 
meiem Sprachschatz eingebuergert, weil ich das ganze praktisch nurnoch 
via Gitlab CI laufen lasse. Das ist aber sicher nicht allgemeiner 
Sprachschatz, daher sorry fuer die Verwirrung.

Lothar M. schrieb:
>> Es ist schon ein signed als auch ein unsigned Addierer.
> Dann ist im Prinzip die simple Erweiterung vorne mit '0' aber falsch.
> Korrekt müsste das bei dir dann so aussehen:

Genau das hatte ich gemeint, mit meiner obigen Aussage, dass er 
spaetestens beim Umstieg auf signeds froh sein wird die resize Funktion 
zu verwenden.

Spricht auch stark dafuer, dass der Core nicht via Regressiontests 
validiert wird. Spaetestens da haette es auffallen muessen.

[Martin S. (strubi)]

Tobias B. schrieb:
> Wenn ich jetzt eine solche atrix
> aufstellen muesste zu Qualitaetsbewertung, dann waere da sehr
> wahrscheinlich ein Punkt mit drin, dass die Verwendung von obsoleten
> Bibliotheken vermieden wird.

Das ist eigentlich das erste, was mein 'DRC' bei third party Cores 
macht. Wenn ich mich recht entsinne, haben auch schon Leute an 
entsprechenden Language-Server-Plugins (auf Basis von GHDL) gebastelt, 
damit das gleich in der IDE angemahnt wird.

Der Gag an 'korrektem' VHDL ist ja grade, dass explizit dasteht, was 
gemacht wird. Die paar Keywords mehr sind wirklich Gewohnheitsfrage, wie 
man sich bei Verilog halt merken muss, wie die impliziten 
Konversionsregeln sind (auch da gibt's haessliche Szenarien). Wenn die 
Geschwaetzigkeit nervt, schreibt man sich halt eine Funktion.

Das Problem ist bei einer geschlossen verifizierten CPU, die keine 
signed extension macht, ev. nicht so kritisch, aber bei einer 
komplexeren DSP-Pipe, die allenfalls noch per C++-HLS generiert wird, 
eben schon. Da muss man u.U. jede einzelne Stage (formal) verifizieren, 
sonst wird die Fehlersuche spaeter richtig lustig. Da es kaum ein Tool 
geben duerfte, was das automatisch erledigt, ist das traurige Fazit in 
der Tat oft: Reimplementieren (aber nicht in V*).

Klaus S. schrieb:
> Und
> solange ich hier keinen Erfahrungsbericht sehe, WARUM und WO der Code
> durch Nutzung von STD_LOGIC_SIGNED.ALL von manchen Synthesizern
> fehlinterpretiert wird, werde ich das beibehalten.

Ich fuerchte, es laeuft anders: Wenn du fuer einen weiteren Core um 
Akzeptanz wirbst, musst du einem gewissen Erwartungshorizont genuegen, 
sonst gucken sich gebrannte HDL-Kinder das schlicht nicht an, auch wenn 
die besten Alleinstellungsmerkmale vorliegen sollten.
Die Erfahrungsberichte sind nunmehr hier von ca. 2005-2008, vielleicht 
findest du in den Xilinx-Foren noch ein paar ungeloeschte Rants betr. 
floating_point cores (nicht standardkonformes Coregen-Obfuskat, muss so 
ISE v12 gewesen sein). Die Synthese lieferte das 'richtige' Ergebnis, 
die Verifikation per GHDL sagt: Mismatch (inkorrektes Design). Aber 
Totschweigen ist Trumpf...deswegen klebt wohl dieser resize-Bug auch bis 
heute noch im 'upstream' VHDL-Konverter von MyHDL fest.

Kann sein, dass das heutzutage alles korrekt laeuft und xsim es jetzt 
auch richtig macht, aber eben: Gebranntes Kind sagt: Never ever again.

[Klaus S. (kschleisiek)]

Lothar M. schrieb:
> Sieh dir den Beitrag "std_logic_vector auf integer umwandeln" oder
> den Beitrag "Änderung des Gehäuses erzeugt Compilation Fehler" oder den
> Beitrag "Re: vector mit 0 initalisieren" an.

Danke! Damit ist der Fall klar: Verschiedene Entwicklungssysteme/Parser 
verarbeiten die Bibliotheken unterschiedlich. Und ich hatte geglaubt, 
dass die in der Reihenfolge, in der sie hingeschrieben sind, durchsucht 
werden bis zum ersten passenden Match. Offenbar nicht immer. Mit 
Synplify und ModelSim hatte ich da keine Schwierigkeiten.

Seufz, ich werde meinen gesamten Code überarbeiten und nur noch NUMERIC 
benutzen.

Und herzlichen Dank an Tobias, Lothar und Martin für eure Geduld, es mir 
beizubiegen.

>> statt des resize finde ich, dass es ('0' & ladd_x) völlig klar macht.
> Dann ist im Prinzip die simple Erweiterung vorne mit '0' aber falsch.
> Korrekt müsste das bei dir dann so aussehen:
>

> ladd_out <= (ladd_x(data_width) & ladd_x) + (ladd_x(data_width) & 
> ladd_y) + cin;
>

Neinein, das war schon richtig. Diese angeklebten '0'en sind für die 
Ermittlung des Divisions-carrys im Prozessor nötig. Dafür findet sich 
später in uCntrl.vhd:

ALIAS add_sign        : STD_LOGIC IS ladd_out(data_width-1);
ALIAS add_carry       : STD_LOGIC IS ladd_out(data_width  );
ALIAS div_sign        : STD_LOGIC IS ladd_out(data_width  );
ALIAS div_carry       : STD_LOGIC IS ladd_out(data_width+1);

Und diese unsigned-Erweiterung mit einem resize zu erzeugen, ist auch 
ok. Da wird aber niemlas etwas auf "signed" umgestellt, wenn ich nämlich 
nur die Bits ladd_out(data_width-1 DOWNTO 0) nehme, dann rechnet das 
korrekt sowohl signed als auch unsigned - es hängt lediglich von der 
Interpretation durch die Software und die Nutzung von Carry und Overflow 
ab. In Forth gibt es dafür z.B. zwei Vergleichsoperatoren: < hantiert 
mit signed, u< mit unsigned Operanden, die sich auf dem völlig typfreien 
Stack befinden.

> Aber dann musst du dir auch die Frage stellen, warum da ein Addierer
> überhaupt in ein eigenes Modul gesteckt wird, wenn dann nur 1 Zeile die
> Arbeit verrichtet? Die eine Zeile hätte sicher noch eine Ebene höher
> Platz gefunden.

Das hat den Grund, dass ich die höhere Ebene (uCntrl.vhd) invariant 
halten will gegenüber projektspezifischen Bedingungen. uAdd.vhd habe ich 
eingeführt, als ich eine 32-bit Version von microCore auf Actel A3PE 
implementiert habe. Der Addierer, den Synplify inferenziert hatte, war 
der Bottleneck in der Timinganalyse, und ich musste mir eine schneller 
IP für den Addierer zusammenklicken.

Tobias B. schrieb:
> Die ehtliche Frage die du dir vll. auch stellen musst: Ist es wirklich
> kompliziert oder ist es einfach nur eine Gewoehnungsfrage?

Ich finde es nicht kompliziert, ich finde es geschwätzig. Insofern eine 
Gewöhnungsfrage. Aber VHDL ist sowieso eine Sprache für 10-Finger 
Blindtipper ;)

> Spricht auch stark dafuer, dass der Core nicht via Regressiontests
> validiert wird. Spaetestens da haette es auffallen muessen.

Der Regressionstest für microCore findet sowohl in Simulation als auch 
Real mit dem Programm coretest.fs statt. Da fällt entweder eine 
Fehlernummer heraus, oder ein ok. Und in der Simulation wird ein Bit des 
Ctrl Registers gesetzt, wenn alles ok ist. Dafür müssen bei langsamer 
Technologie (A3PE) 300 usec simuliert werden.

[udok (Gast)]

Klaus S. schrieb:
>> Ich finde das ehrlich gesagt garnicht unnoetig kompiliziert.
>
> Es ist leider kompliziert, aber noch leiderer nicht unnötig. Ich finde
> den alten Code einfacher zu lesen. Sind ja auch weniger Zeilen. Und
> solange ich hier keinen Erfahrungsbericht sehe, WARUM und WO der Code
> durch Nutzung von STD_LOGIC_SIGNED.ALL von manchen Synthesizern
> fehlinterpretiert wird, werde ich das beibehalten.

Dem schliesse ich mich 100% an.
Ich verwende lieber die Synopsys Libs, als die numeric_std.
Meiner Meinung nach ist der Code damit kompakter und besser lesbarer.

Auf Asic Ebene gibt es praktisch nur Synopsys, und alle
FPGA Toolchains verwenden meines Wissens intern Synopsys.

[Christoph Z. (christophz)]

udok schrieb:
> Auf Asic Ebene gibt es praktisch nur Synopsys,
Das sollte heissen: Auf Asic Ebene gibt es praktisch nur Synopsys, 
Cadence und Mentor

> und alle FPGA Toolchains verwenden meines Wissens intern Synopsys.

Das sollte heissen: und fast alle FPGA Toolchains können Synopsys 
verwenden wenn man eine Lizenz hat. Xilinx, Intel und NanoXplore nutzen 
intern eigene Synthesizer, Quicklogic nutzt Yosys, Lattice und Microchip 
nutzen Synopsys.

Was Achronix und Effinix nutzen müsste ich jetzt noch herausfinden.

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

Martin S. schrieb:
> Das ist eigentlich das erste, was mein 'DRC' bei third party Cores
> macht. Wenn ich mich recht entsinne, haben auch schon Leute an
> entsprechenden Language-Server-Plugins (auf Basis von GHDL) gebastelt,
> damit das gleich in der IDE angemahnt wird.

Ah stark. Ist der offen? Falls ja, waere es (oder ist es schon) eine 
Option daraus ein Code Climate Image zu machen? Auch mit Hinblick 
richtung Gitlab. ;-)

Klaus S. schrieb:
> Seufz, ich werde meinen gesamten Code überarbeiten und nur noch NUMERIC
> benutzen.
>
> Und herzlichen Dank an Tobias, Lothar und Martin für eure Geduld, es mir
> beizubiegen.

Gern geschehen und immer wieder. :-)

Vielleicht ist es auch nicht allzuviel Arbeit. Ist ja alles offen, vll 
bekommst du ja ein paar PRs. Doch davor wuerde ich unbedingt empfehlen 
einen modernen Style und Design Guide anzulegen. Und falls deine 
Regression Tests nicht automatisiert ablaufen, das noch zu 
automatisieren.

Klaus S. schrieb:
> Neinein, das war schon richtig. Diese angeklebten '0'en sind für die
> Ermittlung des Divisions-carrys im Prozessor nötig. Dafür findet sich
> später in uCntrl.vhd:ALIAS add_sign        : STD_LOGIC IS
> ladd_out(data_width-1);
> ALIAS add_carry       : STD_LOGIC IS ladd_out(data_width  );
> ALIAS div_sign        : STD_LOGIC IS ladd_out(data_width  );
> ALIAS div_carry       : STD_LOGIC IS ladd_out(data_width+1);
> Und diese unsigned-Erweiterung mit einem resize zu erzeugen, ist auch
> ok.

Dann ist mein Vorschlag aber evtl. nicht wirklich gut. Dann empfiehlt es 
sich dann, einen speziellen Satz Funktionen zu entwickeln, der genau auf 
diese Eigenheiten des Prozessors zurechtgeschnitten ist. Sonst musst du 
falls du einen Bug findest oder was anderes abaendern moechtest wieder 
den kompletten Code durchforsten und anpassen.

Klaus S. schrieb:
> Ich finde es nicht kompliziert, ich finde es geschwätzig. Insofern eine
> Gewöhnungsfrage. Aber VHDL ist sowieso eine Sprache für 10-Finger
> Blindtipper ;)

Daran gewoehnt man sich, bzw. kann einem mit der richtigen IDE einiges 
abgenommen werden. Ich bevorzuge Sigasi, viele anderen Emacs. Da gibts 
glaube ich auch schon ein paar tolle Beitraege hier im Forum.

Klaus S. schrieb:
> Der Regressionstest für microCore findet sowohl in Simulation als auch
> Real mit dem Programm coretest.fs statt. Da fällt entweder eine
> Fehlernummer heraus, oder ein ok. Und in der Simulation wird ein Bit des
> Ctrl Registers gesetzt, wenn alles ok ist. Dafür müssen bei langsamer
> Technologie (A3PE) 300 usec simuliert werden.

Fuer die Simulation wuerde ich dir noch empfehlen, diese zu 
automatisieren. Ich nimm dafuer gerne VUnit und GHDL in einem Docker 
Container, das ist auch am Anfang einer "CI" Karriere noch ueberschaubar 
simpel. Strubi kennt da noch ein paar modernere Konzepte, hat er hier 
auch mal irgendwo vorgestellt. :-)

[Martin S. (strubi)]

udok schrieb:
> Auf Asic Ebene gibt es praktisch nur Synopsys, und alle
> FPGA Toolchains verwenden meines Wissens intern Synopsys.

Auch wenn dem so waere: Kein Grund 'broken by design' zu verwenden.
Die Syn*-Tools klammern ja die korrekte Umsetzung von numeric_std nicht 
aus.

Christoph Z. schrieb:
> Lattice und Microchip
> nutzen Synopsys.

Bei Lattice kann man zwischen Synplify und der hauseigenen LSE waehlen.
Und fuer [ECP5, ICE40] kommt yosys dazu.

[Martin S. (strubi)]

Tobias B. schrieb:
> Ah stark. Ist der offen? Falls ja, waere es (oder ist es schon) eine
> Option daraus ein Code Climate Image zu machen? Auch mit Hinblick
> richtung Gitlab. ;-)

Code Climate hab ich keine Erfahrung mit. Der Check laeuft noch ueber 
XML-output der Analyse von GHDL im Browser, Beispielausgabe: 
https://hackfin.gitlab.io/xhdl/# (kannste eigene XML-Files draufziehen).
Fuer jeden DRC-Geschmack gibt's ein entsprechendes Style-Sheet. Da die 
XML-Ausgabe aber moeglicherweise irgendwann verwaist, ist der neue 
Schrei das Language-Server-Interface (pyghdl), musste mal den 
gitter-Chat des GHDL-Projekts durchsuchen.

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

Martin S. schrieb:
> Der Check laeuft noch ueber
> XML-output der Analyse von GHDL im Browser, Beispielausgabe:
> https://hackfin.gitlab.io/xhdl/# (kannste eigene XML-Files draufziehen).
> Fuer jeden DRC-Geschmack gibt's ein entsprechendes Style-Sheet. Da die
> XML-Ausgabe aber moeglicherweise irgendwann verwaist, ist der neue
> Schrei das Language-Server-Interface (pyghdl), musste mal den
> gitter-Chat des GHDL-Projekts durchsuchen.

Super, vielen Dank. Mal schauen was es da alles zu entdecken gibt. Das 
GHDL diesen --file-to-xml Switch hat wusste ich garnicht. Da tun sich 
ploetzlich ja ganz neue Moeglichkeiten auf. :-D

[Klaus S. (kschleisiek)]

Tobias B. schrieb:
> Vielleicht ist es auch nicht allzuviel Arbeit. Ist ja alles offen, vll
> bekommst du ja ein paar PRs. Doch davor wuerde ich unbedingt empfehlen
> einen modernen Style und Design Guide anzulegen. Und falls deine
> Regression Tests nicht automatisiert ablaufen, das noch zu
> automatisieren.

<schweißabwisch>. So, nach ca. 15 Std. Arbeit sind alle 
Synopsislibraries weg, nur noch 1164 und NUMERIC_STD sind übrig - und es 
funktioniert sogar noch. Für zukünftige solcher Übungen empfehle ich 
folgende Strategie:

1. Überall die Libraries auf 1164 und NUMERIC_STD umstellen.
2. Alles, was Adressen sind, von STD_LOGIC_VECTOR auf UNSIGNED ändern.
3. Dann im Simulator compilieren. Das produziert vieleviele 
Fehlermeldungen, die man in der Compilationsreihenfolge der vhd-Files 
einzeln "austreten" und mit UNSIGNED, to_UNSIGNED, SIGNED, to_UNSIGNED, 
to_INTEGER, STD_LOGIC_VECTOR und RESIZE verzieren kann.

Mich beschleicht der Verdacht, dass es sinnvoll ist, sämtliche 
STD_LOGIC_VECTOR Signale in UNSIGNED umzuändern. Das wird wahrscheinlich 
weniger verstreute Casts und Konvertierungen erfordern.

Gibt's da bereits Erfahrungen?

An den Tests arbeite ich noch, dass das eine einzige Testsuite wird, die 
im Batch abläuft. Die Schwierigkeit, zu der ich noch keine Lösung kenne: 
Für einzelne Tests des Debug-Interface (reines VHDL), muss der 
Programmspeicher immer wieder mit unterschiedlichen Programmen 
initialisiert werden. Das mache ich bisher so, dass ich mit jedem 
Programmwechsel den Simulator neu starte, so dass der Programmspeicher 
immer wieder neu initialisiert wird. Wenn ich das aber im Batch ablaufen 
lasse, starte ich nicht neu - das könnte ich wahrscheinlich auf der 
TCL-Eben erledigen, aber dann funktioniert es nur für ModelSim. ????

[Martin S. (strubi)]

Klaus S. schrieb:
> Mich beschleicht der Verdacht, dass es sinnvoll ist, sämtliche
> STD_LOGIC_VECTOR Signale in UNSIGNED umzuändern. Das wird wahrscheinlich
> weniger verstreute Casts und Konvertierungen erfordern.
>
> Gibt's da bereits Erfahrungen?

Sinnvoll: Dort wo man in der CPU eine n-bit-Zahl nutzt, macht `unsigned` 
einfach weniger Stress, siehe auch 
http://www.jandecaluwe.com/hdldesign/counting.html

Erfahrungen: Was GHDL angeht, laufen `unsigned`-Signale etwas flotter 
und entsprechend memory-sparender in der Simulation, trotzdem bekommst 
du eine Warnung falls uninitialisierte Werte (std_logic: 'U') einen 
undefinierten Wert bei einer Operation erzeugen sollten ('X').

Klaus S. schrieb:
> An den Tests arbeite ich noch, dass das eine einzige Testsuite wird, die
> im Batch abläuft. Die Schwierigkeit, zu der ich noch keine Lösung kenne:
> Für einzelne Tests des Debug-Interface (reines VHDL), muss der
> Programmspeicher immer wieder mit unterschiedlichen Programmen
> initialisiert werden

State of the Art: In Circuit Emulation. Damit loesen sich eine Menge 
Szenarien elegant auf und das Debugging/Testing ist minimal-invasiv.
Im Grunde genommen lasse ich alle Verifikationstests nur noch ueber 
(virtualisierte) JTAG/TAP Interfaces oder RAM mit Software-Hintertuer 
laufen, fuer RISC-V laeuft das auch in der Cloud via GHDL/ghdlex, kann 
bei Interesse mehr Pointer liefern (alles OpenSource).
Der Gag ist dann, wenn's in die harte Verifikation mit unzaehligen 
Testvektoren geht, dass derselbe Lock-Step-Test fuer Simulation wie auch 
fuer die HW-Implementierung nutzbar ist.

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

Klaus S. schrieb:
> <schweißabwisch>. So, nach ca. 15 Std. Arbeit sind alle
> Synopsislibraries weg, nur noch 1164 und NUMERIC_STD sind übrig - und es
> funktioniert sogar noch. Für zukünftige solcher Übungen empfehle ich
> folgende Strategie:

Respekt! Du wirst es nicht bereuen. :-)

Klaus S. schrieb:
> Gibt's da bereits Erfahrungen?
>
> An den Tests arbeite ich noch, dass das eine einzige Testsuite wird, die
> im Batch abläuft. Die Schwierigkeit, zu der ich noch keine Lösung kenne:
> Für einzelne Tests des Debug-Interface (reines VHDL), muss der
> Programmspeicher immer wieder mit unterschiedlichen Programmen
> initialisiert werden. Das mache ich bisher so, dass ich mit jedem
> Programmwechsel den Simulator neu starte, so dass der Programmspeicher
> immer wieder neu initialisiert wird. Wenn ich das aber im Batch ablaufen
> lasse, starte ich nicht neu - das könnte ich wahrscheinlich auf der
> TCL-Eben erledigen, aber dann funktioniert es nur für ModelSim. ????

Schau dir mal VUnit an:

https://vunit.github.io/

Das ist genau das was du brauchst um die Testsuite aufzuziehen.

[Klaus S. (kschleisiek)]

Klaus S. schrieb:
> Mich beschleicht der Verdacht, dass es sinnvoll ist, sämtliche
> STD_LOGIC_VECTOR Signale in UNSIGNED umzuändern. Das wird wahrscheinlich
> weniger verstreute Casts und Konvertierungen erfordern.

Das hat nochmal 3 Stunden gekostet und zu einer DEUTLICH gesteigerten 
Lesbarkeit geführt :) Viele Verzierungen waren überflüssig geworden. Der 
Lesbarkeit halber habe ich auch noch folgende beiden Funktionen ins 
Package gesteckt:

   FUNCTION  u_to_s(v : IN UNSIGNED) RETURN SIGNED IS
   BEGIN
      RETURN signed(std_logic_vector(v));
   END;

   FUNCTION  s_to_u(v : IN SIGNED)   RETURN UNSIGNED IS
   BEGIN
      RETURN unsigned(std_logic_vector(v));
   END;

Die Namen gefallen mir noch nicht wirklich, aber sonst ist es das Jetzt!

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

Wenn du unsigneds nach signeds casten musst, hast du aber ein 
prinzipielles Problem. In welcher Anwendung tritt den so ein Fall auf?

Kleiner Nachtrag:

Die Konvertierung nach std_logic_vector brauchst du nicht. Damit hast du 
eigentlich nichts gewonnen als direkt die signed() und unsigned() 
Funktion zu verwenden.

[Jonas B. (jibi)]

>Die Konvertierung nach std_logic_vector brauchst du nicht. Damit hast du
>eigentlich nichts gewonnen als direkt die signed() und unsigned()
>Funktion zu verwenden.

Und die Fehlersuche macht es auch nicht gerade einfacher, ohne die X'sen 
und U'sen...

[Klaus S. (kschleisiek)]

Tobias B. schrieb:
> Wenn du unsigneds nach signeds casten musst, hast du aber ein
> prinzipielles Problem. In welcher Anwendung tritt den so ein Fall auf?

Der Datenstack ist typfrei und als UNSIGNED angelegt. Wenn ich jetzt ein 
"abs" machen will, muss ich das so machen: <stack> <= 
unsigned(abs(signed(<stack>)));

> Die Konvertierung nach std_logic_vector brauchst du nicht. Damit hast du
> eigentlich nichts gewonnen als direkt die signed() und unsigned()
> Funktion zu verwenden.

Wie schön. Diese Wege (signed <-> unsigned) fehlen demnach in Lothar 
Millers Schaubild. Wie ich bisher überhaupt fundierte Erläuterungen zu 
den Funktionen noch nicht gefunden habe. Und da ist der Sourcecode der 
NUMERIC_STD leider auch nicht hilfreich, da tauchen die Casts gar nicht 
drin auf. Wo stecken die denn?

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

Klaus S. schrieb:
> Der Datenstack ist typfrei und als UNSIGNED angelegt. Wenn ich jetzt ein
> "abs" machen will, muss ich das so machen: <stack> <=
> unsigned(abs(signed(<stack>)));

Aber sollte so ein Datenstack nicht aus einem neutralen Datentyp 
bestehen? Rein aus der Modellbetrachtung her, wuerde ich den daher nur 
als std_logic_vector anlegen und erst wenn ich den Daten eine Bedeutung 
zuweise dann den Cast auf den Zieltyp durchfuehren. Aber da stecke ich 
auch nicht genug drin um mir eine vernuenftige Meinung bilden zu 
koennen.

Klaus S. schrieb:
> Und da ist der Sourcecode der
> NUMERIC_STD leider auch nicht hilfreich, da tauchen die Casts gar nicht
> drin auf. Wo stecken die denn?

  subtype unsigned is (resolved) unresolved_unsigned;
  subtype signed is (resolved) unresolved_signed;

Zeile 81 und 82. Das sind Casts wie sie VHDL bereitstellt und keine 
Funktion!

Leg dir am besten mal das Buch "The Designer's Guide to VHDL" von Peter 
Ashenden zu. Das ist sowas wie die Referenz Bibel zum Thema VHDL. Die 
dritte Auflage ist die aktuellste.

[Christoph Z. (christophz)]

Tobias B. schrieb:
> Schau dir mal VUnit an:
>
> https://vunit.github.io/
>
> Das ist genau das was du brauchst um die Testsuite aufzuziehen.

Jepp, das wäre auch mein Vorschlag gewesen. Wir machen noch nicht viel 
damit, aber hat sich auch jetzt schon ausgezahlt.

Dann kann Klaus auch endlich den Multicore Prozessor in seinem PC nutzen 
und diese Simulationen mit unterschiedlichem Programmspeicher parallel 
ausführen lassen (Pro Instanz eine Modelsim Lizenz nötig und sonst GHDL) 
:-)

[Klaus S. (kschleisiek)]

Tobias B. schrieb:
> Aber sollte so ein Datenstack nicht aus einem neutralen Datentyp
> bestehen? Rein aus der Modellbetrachtung her, wuerde ich den daher nur
> als std_logic_vector anlegen und erst wenn ich den Daten eine Bedeutung
> zuweise dann den Cast auf den Zieltyp durchfuehren.

Nein, nix STD_LOGIC_VECTOR. Würde ich als überflüssig bezeichnen. Warum? 
Da müssen wir die Binärarithmetik betrachten. Egal, ob signed oder 
unsigned, in beiden Fällen ist der Addierer identisch. Der Unterschied 
ist nur, wie das oberste Bit interpretiert wird. Bei UNSIGNED als Beginn 
der höheren Zahlenraumhälfte, bei SIGNED als negative Zahlenraumhälfte.

Unterschiede gibt es nur wenige. Beim Rechtsshiften haben wir 
arithmetischen und logischen Shift, und das RESIZE und der Vergleich (<, 
>) sind sehr unterschiedlich. Und einen Überlauf detektiert man bei 
unsigned mit Carry, bei signed mit Overflow. Das war's aber wohl schon.

Insofern ist es sinnvoll, UNSIGNED statt STD_LOGIC_VECTOR zu nutzen, 
weil die sich bei der Logik identisch verhalten. Darüberhinaus 
beherrschaft UNSIGNED aber auch die Arithmetik mit natürlichen Zahlen, 
so dass man im Endeffekt viel weniger Casten muss. Ich sehe das ja jetzt 
an microCore. Da musste ich jetzt ähnlich selten Casten, wie früher bei 
altbackener Nutzung von STD_LOGIC_VECTOR unter STD_LOGIC_UNSIGNED.ALL.

[Klaus S. (kschleisiek)]

Jonas B. schrieb:
> Und die Fehlersuche macht es auch nicht gerade einfacher, ohne die X'sen
> und U'sen...

Puh, das hat mir reichlich Adrenalin verschafft. Aber nein, so ist es 
nicht, auch UNSIGNED und SIGNED werden mit 'U' (un-initialized) und 'X' 
(ungültiges Ergebnis) markiert. INTEGER und NATURAL werden mit 0 
initialisiert.

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

Klaus S. schrieb:
> Nein, nix STD_LOGIC_VECTOR. Würde ich als überflüssig bezeichnen. Warum?
> Da müssen wir die Binärarithmetik betrachten. Egal, ob signed oder
> unsigned, in beiden Fällen ist der Addierer identisch. Der Unterschied
> ist nur, wie das oberste Bit interpretiert wird. Bei UNSIGNED als Beginn
> der höheren Zahlenraumhälfte, bei SIGNED als negative Zahlenraumhälfte.

Ok alles klar.

Ich bin auch noch davon ausgegangen dass die Daten im Datenspeicher 
komplett generisch sind und nicht unbedingt als Zahl nterpretiert werden 
muessen, z.B. ASCII Chars oder aehnliches.

Klaus S. schrieb:
> Puh, das hat mir reichlich Adrenalin verschafft. Aber nein, so ist es
> nicht, auch UNSIGNED und SIGNED werden mit 'U' (un-initialized) und 'X'
> (ungültiges Ergebnis) markiert. INTEGER und NATURAL werden mit 0
> initialisiert.

Das ist richtig. (Un)signeds sind auch nichts anderes als std_logic 
Arrays, von daher war die Aussage von Jonas auch nicht korrekt. Bei 
Integers waere das allerdings richtig gewesen.

[Klaus S. (kschleisiek)]

Klaus S. schrieb:

>> Mich beschleicht der Verdacht, dass es sinnvoll ist, sämtliche
>> STD_LOGIC_VECTOR Signale in UNSIGNED umzuändern. Das wird wahrscheinlich
>> weniger verstreute Casts und Konvertierungen erfordern.
>
> Das hat nochmal 3 Stunden gekostet und zu einer DEUTLICH gesteigerten
> Lesbarkeit geführt :)

Hier zum Abschluss noch eine Modifikation der Vorgehensweise bei der 
Umstellung:

1. Überall die Libraries auf 1164 und NUMERIC_STD umstellen.

2. In allen Files alle STD_LOGIC_VECTOR in UNSIGNED ändern.

3. Dann im Simulator compilieren. Das produziert viele Fehlermeldungen, 
die man in der Compilationsreihenfolge der vhd-Files einzeln "austreten" 
und mit UNSIGNED, to_UNSIGNED, SIGNED, to_UNSIGNED, to_INTEGER und 
RESIZE verzieren kann.

Direkt alle STD_LOGIC_VECTORen rauszuwerfen produziert deutlich weniger 
Fehlermeldungen als beim Vorgehen wie in 
Beitrag "Re: IEEE.STD_LOGIC_ARITH.ALL obsolete" vorgeschlagen.