Verständnisproblem hinsichtlich Simulation <-> Synthese

[ZZZ (Gast)]

Ich habe eine Simulation, in der ich einige Signale nicht in der 
sensitivity list aufgeführt hatte mit dem Ergebnis, daß die entstehenden 
Schaltungen in der Simulation wie erwartet funktionierten - alos z.B. 
auf ein bestimmtes Signal nicht reagierten.

Ein Beispiel:

  process (var1, var2)
  begin  -- process
    if var1 = '0' then
    output <= var2 & var3;
  else 
    output <= var2 & var4;
  end if;
  
  if var2 = '0' then
    marker <= var3 & var4;
  else 
    marker <= var1 & var1;
  end if;
  end process;

Das Ziel ist, daß der Ausgang nur dann mit einem neuen var3 oder auch 
var4 aktualisiert wird, wenn sisch var1 oder var ändern und nicht, wenn 
var3 alleine sich ändert. In der Simulation funktioniert das, aber die 
Synthese macht etwas anderers und kümmert sich nicht darum, daß die 
sensitivity ist nicht gefüllt ist.

Ist das normal so und richtig ?

[Falk B. (falk)]

@ ZZZ (Gast)

>Ich habe eine Simulation, in der ich einige Signale nicht in der
>sensitivity list aufgeführt

Tststs, das sollte man lassen. Das ist BESTENFALLS in Testbenches OK, 
aber nie und nimmer in synthetierbarem Code.

>Das Ziel ist, daß der Ausgang nur dann mit einem neuen var3 oder auch
>var4 aktualisiert wird, wenn sisch var1 oder var ändern und nicht, wenn
>var3 alleine sich ändert.

Schön und gut, aber für sowas braucht man einen Speicher in Form eines 
FlipFlops oder Latch, wobei letztere besser nicht verwendet 
werden. Und das wird dann auch anders im VHDL beschrieben.

> In der Simulation funktioniert das, aber die
>Synthese macht etwas anderers und kümmert sich nicht darum, daß die
>sensitivity ist nicht gefüllt ist.

Das ist normal, die Sensitivity List wird nur vom Simulator korrekt 
ausgewertet, der Synthesizer macht nur nen Check, meckert, und 
implementiert am Ende so, als ob alle relevanten Signale in der 
Sensitvity List drinnen stehen würden.

MFG
Falk

[ZZZ (Gast)]

Das dachte ich mir. Die Konstrukte entstammen nämlich ursprünglich aus 
einer Testumgebung. Mein Ziel ist natürlich, daß sich die Simulation des 
synthetisierbaren Codes exakt so verhält, wie später auch der Code im 
Xilinx sein wird, damit gültige Aussagen gemacht werden können.

Habe das jetzt umgeschrieben, aber festgestellt, daß sich alles ziemlich 
in den clocks verschiebt. Kann man das irgendwie schneller machen ?

process (clock, output_alt)
begin
   if rising_edge(clock) then
    var2_alt <= var2_neu;      -- merken
    var3_alt <= var3_neu;
    var4_alt <= var4_neu;
    
    if (var2_alt != var2_neu) then  -- var2 anders als vorher ?
      if var1 = '0' then
          output <= var2_alt & var3_alt;
      else 
          output <= var2_alt & var4_alt;
      end if;
    else
      output <= output;      -- nichts ändern
    end if;

    var3_ganz_alt <= var3_alt;
    var4_ganz_alt <= var4_alt;
    
    if var2 = '0' then
      marker <= var3_ganz_alt & var4_ganz_alt;
    else 
      marker <= var1_ganz_alt & var1_ganz_alt;
    end if;

  end if;
  
  output_neu <= output_alt;
  
end process;

Ich habe jetzt 4 clocks mehr und es stimmt von der Funktion her, bin 
aber nicht zufrieden. Vor allem die vielen zusätzlichen Signale machen 
mir Sorgen. Wenn ich den ganzen Code so umschreiben muss, bin ich 
Weihnachten noch nicht ferig.

[Xenu (Gast)]

Inwiefern machen Dir die zusätzlichen Signale Sorgen?

[Falk B. (falk)]

@ ZZZ (Gast)

>einer Testumgebung. Mein Ziel ist natürlich, daß sich die Simulation des
>synthetisierbaren Codes exakt so verhält, wie später auch der Code im
>Xilinx sein wird, damit gültige Aussagen gemacht werden können.

Das Ziel hat wohl jeder Digialdesigner ;-)

>Habe das jetzt umgeschrieben, aber festgestellt, daß sich alles ziemlich
>in den clocks verschiebt. Kann man das irgendwie schneller machen ?

???


>process (clock, output_alt)

Getaktete Prozesse sind nur vom Takt abhängig, ggf. asynchrones Reset. 
Also output_alt raus.

>begin
>   if rising_edge(clock) then
>    var2_alt <= var2_neu;      -- merken
>    var3_alt <= var3_neu;
>    var4_alt <= var4_neu;

Unsinn. Wir habe hier VHDL, nicht C.

>    if (var2_alt != var2_neu) then  -- var2 anders als vorher ?
>      if var1 = '0' then
>          output <= var2_alt & var3_alt;
>      else
>          output <= var2_alt & var4_alt;
>      end if;
>    else

OK.

>      output <= output;      -- nichts ändern

Dito, auch Unsinn. Sowas musst man in der guten alten ABEL Zeit 
schreiben. Bei VHDL ist es überflüssig.

>Ich habe jetzt 4 clocks mehr

???
Du hast einen Takt. Oder redest du von Signalen?

> und es stimmt von der Funktion her, bin
>aber nicht zufrieden. Vor allem die vielen zusätzlichen Signale machen
>mir Sorgen. Wenn ich den ganzen Code so umschreiben muss, bin ich
>Weihnachten noch nicht ferig.

Der alte Code hat entweder eine andere Funktion als du denkst, oder er 
ist nie synthetisiert worden.

MfG
Falk

[ZZZ (Gast)]

Ich hatte das etwas gekürzt, daher kann das gfs nicht so synthetisiert 
werden. Es geht mir auch ums Prinzip.

Das mit dem alt und neu musste ich machen, da die Interpretation der 
Signale ja immer zeitversetzt erfolgt und so die falschen Signale 
zusammengefügt wurden.

[Gast (Gast)]

Was passiert mit Signalen, die zwar in der Liste stehen, jedoch nirgends 
im process verwendet werden? Die sind doch in jedem Fall unbedeutend.

[Falk B. (falk)]

@ Gast (Gast)

>Was passiert mit Signalen, die zwar in der Liste stehen, jedoch nirgends
>im process verwendet werden? Die sind doch in jedem Fall unbedeutend.

NEIN! Die Simulation reagiert dann darauf und durchläuft den Prozess. 
Das kann bei Testbenches unerwünscht sein, für die Schaltung ist es 
egal.

MFg
Falk

[ZZZ (Gast)]

Das wäre meine nächste Frage gewesen, was denn mit einer Überfüllung 
ist, also mehr Signalen in der Liste. Würde z.B. ein Prozess, in dem 
eine Variable hochgezählr wird mehrfach angetriggert, wenn sich eine der 
Variablen der s-Liste ändert, er aber sonst nicht zusätzlich ausgeführt 
würde?

Könnte das Ergebnis der Simulation auch in diesem Fall von der Funktion 
des synthetisierten Schaltung weglaufen ?

Offenbar ja. Dann dürften also auch nicht mehr Signale drin sein ?

Damit kann ich ja dann eigentlich davon ausgehen, daß aus Sicht der 
Vergleichbarkeit von Simulation und Synthese die sensitivity Liste 
ausnahmsmlos immer! vollständig sein muss aber auch nicht überfüllt sein 
darf, um zu gewährleisten, dass die Simulation 100% stimmig ist ?

[Klaus F. (kfalser)]

Das Problem entschärft sich, wenn man nur 2 verschiedene Arten von 
Prozessen verwendet und sauber zwischen ihnen trennt.
- Getaktete Prozesse, die nur auf Clock (und ev. Reset) reagieren.
Diese erzeugen Flipflops und werden immer so beschrieben

process (Clk, Reset) is
begin  -- process
    if Reset = '1' then                 -- asynchronous reset (active 
high)

    elsif rising_edge(Clk) then         -- rising clock edge

    end if;
end process;

- Kombinatorische Prozesse, bei denen ALLE Signale, welche auf der 
rechten Seite von "<=" auftauchen, in die Sensitivity List gehören

process (A, B, C) is
begin  -- process
   D <= A and B;
   E <= C or A;
end process;

Und Variablen solltest Du besser vermeiden, bis Du VHDL besser 
beherrschst.

Klaus

[Falk B. (falk)]

@ Klaus Falser (kfalser)

>Und Variablen solltest Du besser vermeiden, bis Du VHDL besser
>beherrschst.

Schöner Satz, sollte glatt in einen Wikiartikel.

MFG
Falk

[ZZZ (Gast)]

Habe eigentlich keine Variablen - jedenfalls da nicht.
Danke aber erstmal.