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
@Stefan Helmert: Du hast gar keinen synchronen Clock implementiert. Das was dort beschrieben ist, stellt wohl mehr ein transparentes Latch dar.
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.)
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.