synchronzähler - codefehler (vhdl)

[Stefan Helmert (Gast)]

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?

[Falk (Gast)]

Ohne Code ist das a bissel schwer zu beurteilen.

MFG
Falk

[Stefan Helmert (Gast)]

------------------------------------------------------------------------ 
----------
-- 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;

[Falk (Gast)]

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

[Manne (Gast)]

@Stefan Helmert:

Du hast gar keinen synchronen Clock implementiert. Das was dort 
beschrieben ist, stellt wohl mehr ein transparentes Latch dar.

[Stefan Helmert (Gast)]

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"?

[Stefan Helmert (Gast)]

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?

[Falk (Gast)]

@ 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

[Stefan Helmert (Gast)]

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.

[Falk (Gast)]

@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

[Falk (Gast)]

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

[Stefan Helmert (Gast)]

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>.

[Falk (Gast)]

@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

[Stefan Helmert (Gast)]

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.

[Falk (Gast)]

@ 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

[Stefan Helmert (Gast)]

>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.)