Hallo, in den meisten Fällen ist es ja gar nicht erwünscht mehrere Treiber an einem Signal zu haben, std_ulogic wäre also sicherer, weil man in diesem Fall gleich eine Fehlermeldung bekommt. Warum verwenden fast alle trotzdem std_logic? Gewohnheit/Kompatibilität zu kaputten Synthesetools? Gruß Andreas
Gast
#576420
OK, also nur wegen Kompatibilität zu kaputten Synthesetools. Danke.
Gast
#576762
> Warum verwenden fast alle trotzdem std_logic? Gewohnheit/Kompatibilität zu > kaputten Synthesetools? m.E. weil es verdammt viele benutzen (dann muss es ja richtig sein) und es keine Compiler Errors zB. in Modelsim gibt - eben nur in der Simulation einige 'X'; sprich Bequemlichkeit. Wenn man damit aber nichts anfangen kann und die 'X' Zustände in non-Bus Systemen ignoriert (da man mit std_logic simuliert), wird der CPLD/FPGA eben warm ... Viele Grüße Olaf
Gast
#577292
> weil es verdammt viele benutzen (dann muss es ja richtig sein)
Und wenn alle anderen von der Brücke springen ... (eh schon wissen).
Wenn ich nicht mehrere Treiber auf ein Signal haben will, dann nehm ich
std_ulogic. Folglich gibt's dann nur in der Top-Level Entity für
bidirektionale Signale std_logic. Aktuelle Synthesetools haben damit
kein Problem!
Gast
#579531
Ich habe gerade festgestellt dass beim Webpack 8.1 ein signal<=signal+1; nur geht wenn es ein std_logic_vector ist, mit std_ulogic gehts nicht. Steckt da was dahinter, oder ist das eher ein Bug? Randy
Das hängt wohl eher damit zusammen, daß Du die arithmetischen Funktionen aus den package std_logic_unsigned oder std_logic_signed verwendest. Diese sind mit einem Parameter vom Type std_logic_vector definiert. Man sollte aber sowieso nicht mit std_logic_vectoren rechnen, besser das package numeric_std und die Typen unsigned und signed verwenden. Klaus
Basieren die Typen signed/unsigned nicht wiederum auf std_logic_vector (ohne u)?
Die Typen signed und unsigned aus numeric_std basieren auf std_logic (ohne vector, ohne u).
Gast
#579849
Da blicke noch einer durch ... Wenn ich jetzt das numeric package verwende, wie definiere ich dann mein internen ports auf den niederem Ebenen? Mit std_logic_vector oder doch mit "u" ?
Für die Ports verwendet man ab besten std_(u)logic oder
std_(u)logic_vector, für die interne Berechnung unsigned/signed.
In der Architecture wird dann das innere Signal an das äusere
zugewiesen, mit einem Cast, so ähnlich wie im folgenden.
entity foo is
port {
..
fff : out std_logic_vector(..),
..
}
end entity;
architecture foo_arch of foo is
signal ffu : unsigned(fff'range);
begin
...
..
fff <= std_logic_vector(ffu);
end foo_arch;
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.