Vivado-Post-Synthesis Simulation liefert falsche Werte

[Empa (Gast)]

Hey,
ich muss mich bezüglich meiner Diplomarbeit in VHDL einarbeiten. Leider 
hatten wir nie etwas in der Richtung gehabt, also musste ich es mir 
selber beibringen.
Nun habe ich Code für ein VGA Controller geschrieben, welcher leider 
nicht funktionierte. Also reduzierte ich die komplexität auf nur einen 
einfachen Counter, welcher nach 2 sekunden die LEDS toogelt. Lauft 
Behavior Simulation funktioniert das alles ohne Problem. Leider machen 
die Post-Synthesis und Post-Implemantation Simulation nicht mit (daher 
beim aufspielen auf den FPGA passiert auch nichts außer dem standard 
Leuchten). Habe auch schon eine andere Software fürs Simulieren probiert 
ohne Erfolg
Könnte mir bitte einen Stoß in die richtige Richtung geben bzw. mir 
sagen warum das nicht funktioniert?
Sitze jetzt schon nen Stück dran und verzweifle langsam...

FPGA: Zynq-7000 series (Zedboard)
Suite: Vivado 2013.3 / ModelSim zur überprüfung


PS: Hier habe ich schon gepostet jedoch konnte keiner helfen aber evt 
sind Fragen die ihr habt dort beantwortet 
http://www.computerbase.de/forum/showthread.php?t=1301303

    library IEEE;
    use IEEE.STD_LOGIC_1164.ALL;
     
     
    use IEEE.NUMERIC_STD.ALL;
     
     
     
    entity ClockLED is
    Port (
    --CLK : in std_logic; -- only in non-Simulation
    LEDS : out std_logic_vector(7 downto 0)
     
    );
    end ClockLED;
     
    architecture Behavioral of ClockLED is
     
    type state_LEDS is (CNT1, CNT2, SETLEDS); -- defines the states
    signal state_LED : state_LEDS;
     
    signal LEDACTIVE : std_logic_vector(7 downto 0) := "11100011";
    signal SUM:integer range 0 to 2000005 := 0;
    signal CLK: std_logic;
     
    begin
     
    ---------------CLK Simulation------------
    process
    begin
    wait for 500 ns;
    CLK <= '1';
    wait for 500 ns;
    CLK <= '0';
    end process;
     
     
    -------------Counter and toogle--------------
    process(CLK)
    begin
     
    if rising_edge(CLK)THEN
     
     case state_LED is
      When CNT1 =>
       if SUM>2000000 then
        state_LED<=SETLEDS;
       else
        SUM <= SUM+1;
     
       end if;
     
      When SETLEDS =>
       SUM<=0;
       LEDACTIVE<= not LEDACTIVE;
       state_LED<=CNT1;

      When others =>
       state_LED<=CNT1;

      end case;

     end if;
    end process;

    LEDS<=LEDACTIVE;
     
    end Behavioral;

[pks (Gast)]

Hallo,

Vergiss das mit der PostXY-Simulation mal. In der Regel brauchst Du die 
nicht. Wichtig ist erstmal, dass:
1. Die Logik-Simulation funktioniert (tut sie ja)
2. Du alle IOs und Clocks richtig constraint hast
3. Das Synthese-Tool keine Fehler auswirft

Ich vermute jetzt Dein Problem eher bei 2.

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

Empa schrieb:
> Leider machen die Post-Synthesis und Post-Implemantation Simulation
> nicht mit (daher beim aufspielen auf den FPGA passiert auch nichts außer
> dem standard Leuchten).
Ja, ist klar.
In ein synthetisierbares VHDL-Modul gehört keine Takterzeugung mit "wait 
for 500 ns;" Wie soll denn das in Hardware umgesetzt werden können? 
Welches Bauteil soll der Synthesizer da hernehmen? Die legendäre 
500ns-Verzögerungsleitung?


Richtig: er hat keines, und deshalb ignoriert er einfach die gesamte 
Takterzeugung. Heraus kommt: eine dauerleuchtende LED.

Wenn ein "wait for" synthetisierbar wäre, könnte man eine LED mit
"LED <= not LED after 500 ms;" zum Blinken bringen:
http://www.lothar-miller.de/s9y/archives/80-Hello-World!.html

[Empa (Gast)]

Die IOs sind alle richtig constraint, da die LEDS funktionieren. Habe 
sie auch mit den SWS ein/aus geschaltet. Soweit klappt das ganz gut.

Die Clocks dürfte auch richtig gehen. Habe mal ein Bild von der 
Einstellung angehängt.

[pks (Gast)]

Lothar Miller schrieb:
> Ja, ist klar.
> In ein synthetisierbares VHDL-Modul gehört keine Takterzeugung mit "wait
> for 500 ns;" Wie soll denn das in Hardware umgesetzt werden können?

Ups, den code hab ich mir gar nicht wirklich angeschaut :)
Was macht denn ISE überhaupt damit? Gibts da keine Meldung?

[Empa (Gast)]

Die CLK erzeugung ist ja nur für die Simulation. Wenn ich den Code auf 
den FPGA bringe, wird natürlich ein richtiger Clock von der IO PLL 
angelegt.

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

Empa schrieb:
> Die CLK erzeugung ist ja nur für die Simulation.
Das geht aber normalerweise anders...
Dafür schreibt man üblicherweise eine Testbench, die den Prüfling als 
Komponente einbindet und stimuliert.

> Wenn ich den Code auf den FPGA bringe, wird natürlich ein richtiger
> Clock von der IO PLL angelegt.
Nicht einfach ein Takt von einem Takteingang? Wozu die PLL?

[Empa (Gast)]

Bei vivado hat man einen eigenen IO PLL. Diesen Clock kann man dann über 
devider verändern. Oben haben ich ein Bild gepostet, in dem man dies 
erkennen kann.

Das mit der extra testbench, wie auf deiner Homepage, werde ich 
implementieren.

[Empa (Gast)]

Anbei der aufbau der Schaltung. Hier ist jetzt der extra clock dran und 
es wird nichts mehr simuliert(aus dem Code entfernt). Aber die 
Post-Synthesis toogelt einfach den Ausgang nicht.

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

Empa schrieb:
> Bei vivado hat man einen eigenen IO PLL. Diesen Clock kann man dann über
> devider verändern.
Aber irgendwo muss ein Oszillator angeschlossen sein. Das Vivado (oder 
eher das FPGA) saugt sich den Takt ja nicht aus den Knochen...

[Empa (Gast)]

Es sind 2 Oscillatoren drauf.
Die PS section hat einen mit 33.3333 Mhz
Die PL section hat einen mit 100 Mhz

[Empa (Gast)]

habe eben auch mal den Counter auf den LEDS ausgang geschaltet ist aber 
konstant auf 0 geblieben. Liegt also vermutlich am Takt.

[Fpgakuechle K. (Gast)]

deiner statemachine fehlt die initialisierung, das mindeste ist

signal state_LED : state_LEDS := CNT1;

der state CNT2 ist zwar definiert, wird aber nie benutzt.

MfG,

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

Empa schrieb:
> Die PS section hat einen mit 33.3333 Mhz Die PL section hat einen mit
> 100 Mhz
Würde mir sehr zu denken geben, dass das so gar nicht zu den Zahlen im 
Beitrag "Re: Vivado-Post-Synthesis Simulation liefert falsche Werte" passt...

Empa schrieb:
> Liegt also vermutlich am Takt.
Sehr wahrscheinlich. Du kannst auch einfach mal den Takt an einem Pin 
ausgeben und mit einem Oszi kontrollieren, ob da was kommt.

[Fpgakuechle K. (Gast)]

U.U. hast du einen port und ein signal gleichen namens, nämlich clk.

für eine simulation "erzeugt" man keinen Takt in dem Modul, sondern 
ausserhalb der top-level entity.

MfG.

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

Fpga Kuechle schrieb:
> deiner statemachine fehlt die initialisierung, das mindeste ist
> signal state_LED : state_LEDS := CNT1;
Das macht der Synthesizer von sich aus: er nimmt bei uninitialisierten 
Signalen den linkesten Wert der Typdefinition. Die Verhaltenssimulation 
würde diesen Fehler aber aufzeigen...

[Empa (Gast)]

Leider habe ich gerade kein Osci da :(
Werde mir eins nächste woche ausleihen.

Die Osci auflistung steht hier
http://www.zedboard.org/sites/default/files/ZedBoard_HW_UG_v1_3.pdf
Seite 3

[Fpgakuechle K. (Gast)]

Empa schrieb:
> Anbei der aufbau der Schaltung. Hier ist jetzt der extra clock dran und
> es wird nichts mehr simuliert(aus dem Code entfernt). Aber die
> Post-Synthesis toogelt einfach den Ausgang nicht.

Der port FCKL_RESET0_N ist ein unbeschalteter Eingang??

[Empa (Gast)]

ja ich benutzte derzeit den Reset nicht.

[123 (Gast)]

Empa schrieb:
> ja ich benutzte derzeit den Reset nicht.

Solltest du vielleicht. Der Reset ist laut Bezeichnung "active low", 
d.h. das Modul ist immer im Reset.

[Empa (Gast)]

Prinzipiell kann ich diese ja nur abfragen und nicht ändern.
Wird das regestriert wenn ich den abhole?

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

Empa schrieb:
> Prinzipiell kann ich diese ja nur abfragen und nicht ändern.
> Wird das regestriert wenn ich den abhole?
Wen? Wie? Wo?
Besorg dir mal das Buch "VHDL-Synthese" in der nächsten Bücherei...

Empa schrieb:
> Leider habe ich gerade kein Osci da :(
> Die Osci auflistung steht hier
Bitte niemals das selbe Wort für ganz was anderes verwenden, ohne vorher 
den Kontext geklärt zu haben. Das verwirrt nur unnötig!

[Weltbester FPGA-Pongo (Gast)]

Empa schrieb:
> ich muss mich bezüglich meiner Diplomarbeit in VHDL einarbeiten. Leider
> hatten wir nie etwas in der Richtung gehabt, also musste ich es mir
> selber beibringen.
Das finde ich aber reichlich seltsam. Die meisten Studenten lernen doch 
Digitaltechnik und werden im Zuge dessen auch mit den einschlägigen 
Beschreibungssprachen bekannt gemacht. Bei mir ist das schon 20 Jahre 
her und heute ist das definitiv nicht anders.

Da VHDL Stand der Technik ist, hätte ich die Erwartungshaltung, dass 
jeder Studi, der sich mit Digittechnik befasst, genau das lernt und 
diejenigen, die das nicht haben, nicht ausgerechnet eine DA anfertigen, 
bei der das abverlangt wird.

Wie kommt's, dass Du nun auf eine solche DA gestossen bist / wurdest?

[Empa (Gast)]

Nunja wir hatten ja Digitaltechnik sowie Computerarchitektur. Beides 
habe ich mit einer 1.3 abgeschlossen, habe also aufgepasst. Problem war 
jedoch, das unser Prof. von DIgitaltechnik das im 6 semester in 
Computerarchitektur drannehmen wollte. Jedoch hat er die FH gewechselt 
und der neue Prof. war nur aushilfe mäßig da und hat natürlich was 
anderes drangenommen... Desswegen setzte ich mich derzeit erneut in die 
Vorlseungen bei wieder einen neuen Prof. rein...
So war das bei uns auch bei anderen Fächern. Extrem frustrierend...

[Grendel (Gast)]

Bei uns hatte damals zwar nicht andauernd der Prof. gewechselt (der 
Dozent war sowieso nur ein Herr Doktor und der Übungsleiter nur 
Dipl-Ing. ;-) ) aber wirklich viel VHDL kam auch nicht dran - wenn man 
wollte(!) dann waren es zwei Vorlesungen sonst wars nur eine wo aber zu 
75% Konzepte und Architektur im Vordergrund standen...
da musste man schon direkt ein Projekt in der passenden Arbeitsgruppe 
mitmachen um mehr Praxis zu erhalten.

Also so ungewöhnlich ist das nicht.

[Marten W. (goldmomo)]

Lass dich bloß nicht verrückt machen :-)

Schau einfach mal in der Top-Level Entity ob bei deiner PLL auch alle 
Eingänge gesetzt sind (bzw. Poste sie mal, vielleicht auch die 
Warning/Error-Ausgaben). Das Pin-Assignment kann ja nicht so falsch sein 
(siehst ja, dass die LEDs deinen Default-State anzeigen).