Hallo,
ich habe das Problem, dass das die Post-Fit Simulation sich nicht so
verhält wie ich mir das vorstelle. Wenn rst=1 ist dann stimmt das
Ergebnis, es ist 0. Aber wenn rst von 1 auf 0 wechselt, dann müsste y
immer noch 0 bleiben, doch es wechselt auf 1. Das paradoxe ist jedoch,
dass in der Behavieral Simulation alles richtig ist (y bleibt 0). Wie
kann das sein?
------------------------------------------------------------------------
----------
-- Company:
-- Engineer:
--
-- Create Date: 20:06:01 01/06/2007
-- Design Name:
-- Module Name: counter - Behavioral
-- Project Name:
-- Target Devices:
-- Tool versions:
-- Description:
--
-- Dependencies:
--
-- Revision:
-- Revision 0.01 - File Created
-- Additional Comments:
--
------------------------------------------------------------------------
----------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
entity counter is
port(clk,rst : in bit;
y: out bit_vector (3 downto 0));
end counter;
architecture Behavioral of counter is
begin
P1: process(clk,rst)
variable c,d,e: bit_vector (3 downto 0);
begin
if (rst = '1') then c:="0000"; e:="0000";
elsif (clk = '1') then c:=e;
else e:=d;
end if;
case c is
when "0000" => d:="0001";
when "0001" => d:="0011";
when "0011" => d:="0010";
when "0010" => d:="0110";
when "0110" => d:="0111";
when "0111" => d:="0101";
when "0101" => d:="0100";
when "0100" => d:="1100";
when "1100" => d:="1101";
when "1101" => d:="1111";
when "1111" => d:="1110";
when "1110" => d:="1010";
when "1010" => d:="1011";
when "1011" => d:="1001";
when "1001" => d:="1000";
when others => d:="0000";
end case;
y<=c;
end process P1;
end Behavioral;
AUA!
Was soll denn das?
Versuchs mal damit
entity counter is
port (clk : in std_logic;
rst : in std_logic;
y: out std_logic__vector (3 downto 0));
end counter;
architecture Behavioral of counter is
signal d: std_logic_vector(3 downto 0);
begin
P1: process(clk,rst)
begin
if (rst = '1') then
c:="0000"; e:="0000";
elsif rising_edge(clk = '1'then
case d is
when "0000" => d:="0001";
when "0001" => d:="0011";
when "0011" => d:="0010";
when "0010" => d:="0110";
when "0110" => d:="0111";
when "0111" => d:="0101";
when "0101" => d:="0100";
when "0100" => d:="1100";
when "1100" => d:="1101";
when "1101" => d:="1111";
when "1111" => d:="1110";
when "1110" => d:="1010";
when "1010" => d:="1011";
when "1011" => d:="1001";
when "1001" => d:="1000";
when others => d:="0000";
end case;
end process P1;
y <= d;
end Behavioral;
1.) Die Formatierung ist wichtig um Fehler zu erkenen.
2.) Man braucht für einen lumpgen Zähler nicht 3 Variablen.
3.) Mit Variablen sollte man sparsam umgehen und sie nur verwenden, wenn
man sie wirklich braucht.
MfG
Falk
master slave prinzip. Ich habe mitlerweile mit clk'event das ganze
abgeändert und nur ein latch genommen, das geht. Aber mir geht nicht in
den Kopf warum der code hier oben nicht geht, obwohl er doch ansich
richtig sein müsst. Weshalb, wechselt y schon nach der HL-Flanke von rst
auf "0001"?
Ich habe das Design jetzt noch mal mit Quartus II version 6.1
ausprobiert und da wird es auch korrekt simuliert. Nur mit der Xilinx
ISE 8.2i klappt es nicht.
Kann es denn auch ein Fehler im Compiler von Xilinx sein?
@ Stefan Helmert
>master slave prinzip. Ich habe mitlerweile mit clk'event das ganze>abgeändert und nur ein latch genommen, das geht. Aber mir geht nicht in
LATCHES (zustandsgesteuert) sind böse! FlipFlops (flankengesteuert) sind
gut!
>den Kopf warum der code hier oben nicht geht, obwohl er doch ansich>richtig sein müsst. Weshalb, wechselt y schon nach der HL-Flanke von rst
Es ist Murks. Da sollte man dem Compiler nicht übel nehmen, wenn er
murks synthetisiert. Ausserdem ist es möglich, dass du in deiner
testbensch noch ein Problem hast. Ist aber egal, weil der Code sowieso
nix taugt.
MFG
Falk
Ich habe selbst herausgefunden, dass das Designe nicht gut ist. (längere
Verzögerungszeiten, mehr Produktterme und register genutzt) Das
flankengesteuerte Designe funktioniert anstandslos. Nur eben diese
zustandsgesteuerten Latches machen Probleme. Mir ging es nicht mehr
darum ob das Designe gut oder schlecht ist, sondern nur noch den Fehler
zu finden. Ich habe jetzt mal ein paar post-fit simulations mit
unterschiedlichen Devices gemacht und herausgefunden, dass abhängig vom
Device es zu unterschiedlich (fehlerhaften) Ergebnissen kommt. Bei den
xc9572LX passierte das was ich am Anfang beschrieben habe. Beim xc9572VX
kommt nicht ma ein definiertes Signal heraus. Bei den neueren Devices:
Coolrunner-II, Virtex... geht es anstandslos, so wie das Designe
arbeiten müsste.
Ich bin davon überzeugt, dass ein (guter) Compiler ein schlechtes
Designe richtig übersetzen sollte! Wenn er es nicht kann, sollte er
lieber einen Fehler melden, anstatt Misst zu übersetzen! Ein Programm
wofür man kein Geld bezahlt sollte wenigstens richtig funktionieren!
Nichtsdestotrotz ist die ise 8.2i heute gleich ein paar mal abgestürzt.
Ich habe außerdem eine art "buglist" gefunden:
http://www.mikrocontroller.net/articles/Xilinx_ISE:_Hinweise_zu_Versionen
Trotzdem Danke für die Hilfe. Probiert ruhig auch einmal aus wann die
ise was falsch macht.
@Stefan Helmert
>flankengesteuerte Designe funktioniert anstandslos. Nur eben diese>zustandsgesteuerten Latches machen Probleme. Mir ging es nicht mehr>Weshalb man sie ganz einfach nicht benutzt. Das war füher mal brauchbar, >heute
nicht mehr.
>Ich bin davon überzeugt, dass ein (guter) Compiler ein schlechtes>Designe richtig übersetzen sollte! Wenn er es nicht kann, sollte er
Das macht XST schon. Nur dass eben das physikalische Timing bei CPLDs
und FPGAs verschieden ist. Und KEIN Tool ist perfekt, schon gar nciht
bei zweifelhaftem VHDL.
>lieber einen Fehler melden, anstatt Misst zu übersetzen!
Nööö, rein formal ist der Code ja OK. Und ich bin sicher, dass XST
wenigstens ne Warnung ausspuckt, denn solche Sachen wie Latches, Gated
clocks etc. erkennt er und warnt.
>Ein Programm wofür man kein Geld bezahlt sollte wenigstens richtig >funktionieren!
???? Dr Satz ist SEHR merkwürdig? Passt aber 100% auf die Geiz ist Geil
Generation.
>Nichtsdestotrotz ist die ise 8.2i heute gleich ein paar mal abgestürzt.
Dem Update-Wahn habe ich schon vor laaaanger Zeit entsagt. Ich arbeite
im Hobbybereich mit 4.2, die sie relativ klein und läuft.
MFG
Falk
Synthesizing Unit <counter>.
Related source file is C:/Data/work/VHDL/test_cnt/cnt_latch.vhd.
WARNING:Xst:737 - Found 4-bit latch for signal <c>.
WARNING:Xst:737 - Found 4-bit latch for signal <e>.
Found 16x4-bit ROM for signal <d>.
Summary:
inferred 1 ROM(s).
inferred 8 Latch(s).
Unit <counter> synthesized.
Sag ich doch, XST gibt zwei Warnungen aus. Der Fehler liegt eindeutig
VOR der Tastatur. ;-)
MFG
Falk
Ich wusste garn nicht, dass man da so genau aufpassen muss was man
programmiert, denn bis jetzt habe ich nach dem Motto programmiert: Der
Compiler wird schon was draus machen und wenn die komprimierte ise8.2i
schon 970MB groß ist, dann muss da doch soviel Intelligenz drin stecken,
dass problemlos alles gut übersetzt wird, vor allem wenn quartus den
Code auch für CPLDs fehlerfrei übersetzt. Anders ausgedrückt: Unter
bestimmten Umständen muss man halt auch solchen Code schreiben der
zustandsgesteuert arbeitet, z.B. bei schieberegistern und zählern, die
bei jeder Flanke eine Anderung
zeigen sollen.
Ich habe diese Warnungen zwar gelesen, aber da sowieso fast immer
Warnungen ausgegeben werden, auch bei funktionierendem Code, habe ich
sie nicht ernstgenommen - vor allem weil sie nicht wie Warnungen,
sondern wie Feststellungen klingen.
Was bedeuten eigendlich diese beiden Warnungen?
>WARNING:Xst:737 - Found 4-bit latch for signal <c>.>WARNING:Xst:737 - Found 4-bit latch for signal <e>.
@Stefan Helmert
>Ich wusste garn nicht, dass man da so genau aufpassen muss was man>programmiert, denn bis jetzt habe ich nach dem Motto programmiert: Der>Compiler wird schon was draus machen und wenn die komprimierte ise8.2i
;-) So jung und naiv war ich auch mal. Is lange her.
>schon 970MB groß ist, dann muss da doch soviel Intelligenz drin stecken,>dass problemlos alles gut übersetzt wird, vor allem wenn quartus den
Masse != Klasse.
Und "intelligent" ist Software sowieo nicht.
>Code auch für CPLDs fehlerfrei übersetzt. Anders ausgedrückt: Unter
XST übersetzt auch fehlerfrei! Quartus ist bestenfalls grosszügiger im
Umwandeln von Murks in brauchbares Design.
>bestimmten Umständen muss man halt auch solchen Code schreiben der>zustandsgesteuert arbeitet, z.B. bei schieberegistern und zählern, die>bei jeder Flanke eine Anderung zeigen sollen.
Irrtum! Man muss vor allem erstmal ein paar Grundlagen der
Digitaltechnik sich zu Gemüte führen. Und danach VHDL.
Dein VHDL Code zeigt grundlegene Wissenslücken auf. Die gilt es erstmal
zu schliessen, dann kannst du VIELLEICHT über VHDL Compiler urteilen.
>Ich habe diese Warnungen zwar gelesen, aber da sowieso fast immer>Warnungen ausgegeben werden, auch bei funktionierendem Code, habe ich>sie nicht ernstgenommen - vor allem weil sie nicht wie Warnungen,>sondern wie Feststellungen klingen.
Das nennt man Erfahrung.
Was bedeuten eigendlich diese beiden Warnungen?
>WARNING:Xst:737 - Found 4-bit latch for signal <c>.>WARNING:Xst:737 - Found 4-bit latch for signal <e>.
Das was da steht. Es wurde 2 4-Bit Latches erzeugt, welche
zustandsgesteuert sind. Das ist im allgemeinen unerwünscht und führt bei
unsachgmässer Ansteuerung zu Problmem.
MfG
Falk
Wodurch werden eigendlich die Flipflops flankengesteuert? Ist dafür ein
Kondensator am pegelgesteuertem Eingang? Also, wodurch das FF nur 10ns
lang einen Impuls bekommt, sozusagen beim Ansteigen des eingangspegels?
Oder wird die flankensteuerung durch ein MasterSlaveprinzip innerhalb
des FF realisiert? Warum funktioniert mein schlechtes Design mit allen
anderen CPLD/FPGA-Typen (Coolrunner, Virtex) nur nicht mit den xc95..?
Sind die xc95.. vielleicht so aufgebaut, dass sie Probleme mit der
Zustandssteuerung haben? Oder optimiert der Compiler aufgrund der
Architektur da anders? Ich besitze leider noch keinen CPLD, aber könnte
der sich wiederum anders verhalten als der Simulator?
Ich habe im Datenverarbeitungstechnikunterricht gelernt, dass es diese
Zustandssteuerung gibt und sie auch für andere zwecke praktisch
angewandt wird. So wird bei zustandsgesteuerten Master-Slave-FF der
letzte Eingangszustand an den Ausgang weitergegeben, während bei
flankengesteuerten nur der wärend der fallenden Taktflanke in das erste
FF übernommene Signal bei steigender Flanke an den Ausgang gelangt.
@ Stefan Helmert
>Wodurch werden eigendlich die Flipflops flankengesteuert? Ist dafür ein>Kondensator am pegelgesteuertem Eingang? Also, wodurch das FF nur 10ns
Nix Kondensator, das ist doch kein Bastlermurks.
>lang einen Impuls bekommt, sozusagen beim Ansteigen des eingangspegels?>Oder wird die flankensteuerung durch ein MasterSlaveprinzip innerhalb>des FF realisiert? Warum funktioniert mein schlechtes Design mit allen
Ja, im wesentlichen sind es zwei Latches, die sich gegenseitig
verriegeln.
Hochgradig asynchron, aber mit Know How!
>anderen CPLD/FPGA-Typen (Coolrunner, Virtex) nur nicht mit den xc95..?
Läuft es WIRKLICH in realer Hardware oder sieht nur die Simulation so
aus, wie du sie dir in deinem falschen Verständnis als richtig
betrachtest?
>Sind die xc95.. vielleicht so aufgebaut, dass sie Probleme mit der>Zustandssteuerung haben? Oder optimiert der Compiler aufgrund der
Nein, nicht dass ich wüsste.
>Architektur da anders? Ich besitze leider noch keinen CPLD, aber könnte>der sich wiederum anders verhalten als der Simulator?
Ahhhhh, er beginnt zu denken. Bravo!
>Ich habe im Datenverarbeitungstechnikunterricht gelernt, dass es diese>Zustandssteuerung gibt und sie auch für andere zwecke praktisch>angewandt wird. So wird bei zustandsgesteuerten Master-Slave-FF der>letzte Eingangszustand an den Ausgang weitergegeben, während bei>flankengesteuerten nur der wärend der fallenden Taktflanke in das erste>FF übernommene Signal bei steigender Flanke an den Ausgang gelangt.
Schau dir mal die Grundlagen zu State Machines an. Dort gibts keine
Latches, nur flankengesteuerte FlipFlops. Das hat seinen Grund.
MFG
Falk
>Läuft es WIRKLICH in realer Hardware oder sieht nur die Simulation so>aus, wie du sie dir in deinem falschen Verständnis als richtig>betrachtest?
Nein, nur die Simulation sieht gut aus.
Schau es dir an! Ich hatte übrigens noch ein paar Ausgänge dazu gemacht
die die Zustände der Variablen anzeigen, das hat aber keinen Einfluss
auf das Ergebnis. (Hab ich ausprobiert.)
wave.JPG
(310 KB)
