VHDL - 'Warnung' vom Synthesetool (Synplify) unverständlich

[Andreas R. (anrera)]

Hallo bin neu hier und habe gleich mal eine Frage.

Es geht um eine Fehlermeldung vom Synthesetool Synplify - genauer geht 
es um Synplify Pro I-2014.03M-SP1 aus der aktuellen Microsemi IDE 
(Libero 11.5 SP2).

Kann mir vielleicht jemand sagen, was die Warnung:

@W: CL269 : State error detection not built

bedeutet ? Ich habe bei aller I-Net Recherche nichts dazu gefunden und 
vom Support noch keine Antwort.

Konkret steht im Logfile:

post processing for work.testprojekt.arch_testprojekt
@W: CL269 :"D:\test\test2\hdl\Test.vhd":42:11:42:11|State error 
detection not built
@N: CL275 :"D:\test\test2\hdl\Test.vhd":42:11:42:11|Possible don't care 
specified as next state in others or default clause, or failure to 
extract state machine
@END

Der VHDL-Code dazu:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
-- library proasic3;

entity Testprojekt is port
  (

  CLK80 : in    std_logic;  -- Takt
  Reset : in    std_logic;  -- Reset

  out_z            : out   std_logic_vector (1 downto 0);

  out0             : out   std_logic; 
  out1             : out   std_logic; 
  out2             : out   std_logic; 
  out3             : out   std_logic
  );
end Testprojekt;
  
architecture ARCH_Testprojekt of Testprojekt is 

  signal z         : integer range 0 to 3;
 
  signal out_vec   : std_logic_vector(3 downto 0);

begin
  
  P1: process (CLK80, Reset) is
  begin
    if Reset = '0' then
      z <= 0;
      out_vec <= b"1111";

    elsif rising_edge(CLK80) then
      if (z = 3) then
        z <= 0 after 2 ns;
      else
        z <= z + 1 after 2 ns;
      end if;

      case z is
        when 1 =>
          out_vec <= b"0001";
        when 2 =>
          out_vec <= b"0010";
        when OTHERS =>
          out_vec <= b"1001";
       end case;

 --     if (z = 1) then
 --       out_vec <= b"0001";
 --     elsif ( z = 2) then
 --       out_vec <= b"0010";
 --     else
 --       out_vec <= b"1001";
 --     end if; 

    end if;
  end process P1;

  out_z <= std_logic_vector(to_unsigned(z, out_z'length));

  out0 <= out_vec (0);
  out1 <= out_vec (1); 
  out2 <= out_vec (2);
  out3 <= out_vec (3);

end ARCH_Testprojekt;

Die Zeile 42 ist die 'case z is' Anweisung.
Ersetze ich den 'case ... end case' Teil durch den - auskommentierten - 
'if ... endif' Teil, dann gibt es diese Warnung nicht.

Wo ist - an dieser Stelle - der wesentliche Unterschied zwischen 'case' 
und 'if' ?

Bitte nicht wundern, das obige ist aus einem größeren Zusammenhang 
rauskopiert und zusammengestrichen.

Danke schon mal ...
Andreas

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

Welche Optionen hast du für den Zustandsautomaten eingestellt? Irgendwas 
mit "failsafe FSM"?

> b"0001"
Das 'b' ist hier nicht nötig.

> z <= 0 after 2 ns;
Mein tipp: keine symbolischen Verzögerungszeiten in synthetisierbaren 
Modulen. Siehe den Beitrag "Re: Frage zu VHDL und FlipFlop" 
und den Beitrag "Re: Simulation - Bei Abtastung anliegendes Signal übernehmen"

Verwende bitte in Zukunft die [vhdl] Tags wie knapp über der Eingabebox 
unter "Wichtige Regeln - erst lesen, dann posten!" beschrieben.

[Andreas R. (anrera)]

Hallo,

Lothar M. schrieb:
> Welche Optionen hast du für den Zustandsautomaten eingestellt? Irgendwas
> mit "failsafe FSM"?

Ah jetzt ja.
Jetzt weiss was ich falsch gemacht habe.

Unter 'High Reliability' git es eine Checkbox
'Preserve and Decode Unreachable States - (FSM, counters, Sequential 
Logic)'
wenn ich die nicht anwähle erscheint die Warnung auch nicht mehr.
Gleichzeitig wird dann auch z(1) wegoptimiert

Post processing for work.testprojekt.arch_testprojekt
@N: CL177 :"D:\test\test2\hdl\Test.vhd":31:4:31:5|Sharing sequential element z.
@W: CL260 :"D:\test\test2\hdl\Test.vhd":31:4:31:5|Pruning register bit 1 of z(1 downto 0)  
@END

Sprich, dass Tool weisst mich mit der Warnung darauf hin, dass ich zwar 
die Verwendung einer 'sicheren FSM' angefordert habe, aber keine 
Mechanismus für die Sicherung implementiert habe. Richtig ?

Offenbar scheint das Synthesetool ein 'if .. then .. else' Konstrukt 
nicht als FSM zu erkennen.

Danke für den Denkanstoß ...

Gruß,
Andreas

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

Andreas R. schrieb:
> Danke für den Denkanstoß ...
Wenn du shcon beim Nachdenken bist: du brauchst so eine sichere FSM 
nicht. Sie kostet nur und bringt nicht viel:
Beitrag "WHEN OTHERS in einer FSM"

Am allerwichtigsten ist das Eintakten von asynchronen Eingängen und 
Signalen.

[Andreas R. (anrera)]

Lothar M. schrieb:
>  du brauchst so eine sichere FSM nicht.

Ein Kollege meinte, dass die bei den EMV-Tests und dabei speziell bei 
den ESD-Tests (Entladung bis 8 kV) solche Effekte prinzipiell auftreten 
können.
Ist jetzt nicht mein Fachgebiet, aber das Gerät darf dabei wohl weder 
endgültig kaput gehen (klar !) noch per Fremdeingriff wieder in Betrieb 
gesetzt werden müssen (also nicht 'Stecker ziehen/Resetknopf drücken). 
D.h. also, dass das Gerät entweder unbeindruckt bleibt, selbsttätig 
einen Neustart vornimmt, mindestestens aber einen als 'Sicher' 
dokumentierten Zustand annimmt.
Nun ist es - in meinem Fall - so, dass das FPGA mit einen 
Mikrokontroller
kommuniziert. Dort kann dann per Software der Neustart des FPGA's 
ausgelöst werden. Deshlab kann ich wohl tatsächlich auf die 'sichere 
FSM' verzichten ...

Danke nochmal,
Andraes

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

Andreas R. schrieb:
> Deshlab kann ich wohl tatsächlich auf die 'sichere FSM' verzichten ...
Ja nun, die "sichere FSM" sichert ja sowieso nicht die korrekte 
Reihenfolge der Transistionen. Sie sichert nur, dass beim Erreichen 
eines ungültigen Zustandes in einen Default-Zustand gesprungen wird. 
Wenn ich z.B. eine binär codierte FSM mit 3 Bits und 8 gültigen 
Zuständen habe, dann kann die FSM beliebig Amok laufen, weil ja alle 8 
möglichen Zustände gültig sind...

Das wissen nur die Meisten nicht oder sie wollen es nicht wahrhaben.

[Werktätiger (Gast)]

Andreas R. schrieb:
> Gleichzeitig wird dann auch z(1) wegoptimiert
> Post processing for work.testprojekt.arch_testprojekt
> @N: CL177 :"D:\test\test2\hdl\Test.vhd":31:4:31:5|Sharing sequential
> element z.
> @W: CL260 :"D:\test\test2\hdl\Test.vhd":31:4:31:5|Pruning register bit 1
> of z(1 downto 0)
> @END

Die WQegoptimierung sollte man sich genau anschauen, IMHO  braucht deine 
FSM z(1) weil Du immer noch 4 Zustände hast (counter von 0 bis 3). Das 
ich nur bei 2 Zuständen der out_vec ändert ist dabei irrelavent.

Andreas R. schrieb:
> Sprich, dass Tool weisst mich mit der Warnung darauf hin, dass ich zwar
> die Verwendung einer 'sicheren FSM' angefordert habe, aber keine
> Mechanismus für die Sicherung implementiert habe

Njein, ich sehe es eher so das deine FSM als 2bit binärcounter komplett 
ausdekodiert ist es also keine Zustände gibt in der die FSM hängen 
bleibene kann und somit es auch keinen Error-states gibt.

Gruß,

[Andreas R. (anrera)]

Hallo,

Lothar M. schrieb:
> Wenn ich z.B. eine binär codierte FSM mit 3 Bits und 8 gültigen
> Zuständen habe, dann kann die FSM beliebig Amok laufen, weil ja alle 8
> möglichen Zustände gültig sind...

Das ist ja nun logisch.
Eine (nach der Optimierung) voll auskodierte binäre zählende Maschine 
ist da nicht betroffen.
 Allerdings ist es ja nun so, dass die binär auskodierte Maschine - 
aufgrund der komplexeren En-/Decoder-Logik - auch die langsamste 
Variante darstellt, während die 'One-Hot'-Kodierung das Mittel der Wahl 
ist wenn es darum geht, Signallaufzeiten und damit letztendlich die 
Taktrate des Systems zu optimieren. Und dann kodiert man (bzw. läßt 
kodieren) 8 Zustände eben in 8 Bit und ein 'Bitkipper' kann beliebige 
Folgen haben.
Die zusätzliche 'Überwachungslogik' läuft in diesem Fall vollkommen 
asynchron, d.h. diese beeinflußt die Geschwindigkeit der Maschine i.d.R. 
nicht.

Werktätiger schrieb:
> Die WQegoptimierung sollte man sich genau anschauen, IMHO  braucht deine
> FSM z(1) weil Du immer noch 4 Zustände hast (counter von 0 bis 3)

Ich vermute mal, dass FSM z(1) (mit Logik) direkt als Ausgangsport 
Verwendung findet. Dann bekommt dieses FF eben den Namen des Ports und 
das eigentliche z(1) verschwindet zumindest dem Namen nach ...

Gruß,
Andreas

[Duke Scarring (Gast)]

Andreas R. schrieb:
> während die 'One-Hot'-Kodierung das Mittel der Wahl
> ist wenn es darum geht, Signallaufzeiten und damit letztendlich die
> Taktrate des Systems zu optimieren.
Wobei ich noch nie ein Problem mit Laufzeiten der FSM-Kodierung hatte...

Duke

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

Andreas R. schrieb:
> Allerdings ist es ja nun so, dass die binär auskodierte Maschine -
> aufgrund der komplexeren En-/Decoder-Logik - auch die langsamste
> Variante darstellt, während die 'One-Hot'-Kodierung das Mittel der Wahl
> ist wenn es darum geht, Signallaufzeiten und damit letztendlich die
> Taktrate des Systems zu optimieren.
Das ist der Stand des letzten Jahrtausends. Ich zwinge niemals einer 
FSM eine bestimmte Codierung auf. Die Tools optimieren das ganz von 
allein...

Und wenn eine FSM nur mit einer bestimmten Codierung (OneHot, Gray, 
Binär,...) "zuverlässig" läuft, dann ist da garantiert der Wurm drin.

> Die zusätzliche 'Überwachungslogik' läuft in diesem Fall vollkommen
> asynchron, d.h. diese beeinflußt die Geschwindigkeit der Maschine i.d.R.
> nicht.
Sie muss sie unbedingt beeinflussen, weil sie ja in die FSM 
eingreift und einen "Rücksprung" auf den Defaultstate erzwingen kann.

[Andreas R. (anrera)]

Lothar M. schrieb:
> Die Tools optimieren das ganz von allein...

Begehe ich jetzt einen Denkfehler wenn ich sage, dass das Synthese-Tool 
keine Vorstellung davon haben kann, welche Signallaufzeiten in der 
realen Zielhardware auftreten ?
Das Synthese-Tool kann also bestenfalls pauschal optimieren.

Duke Scarring schrieb:
> Wobei ich noch nie ein Problem mit Laufzeiten der FSM-Kodierung hatte...

Also ich rede von einem Actel/Microsemi A3P mit einer FSM 
'Betriebsfrequenz' von 80 Mhz und Betriebstemperaturen von +85°C im 
worst case.
Aus der Timing-Analyse:
Gatterlaufzeiten typ. 600 ps , Signallaufzeiten zw. 0.8 - 2 ns.
Da kann man sich ausrechnen, dass zwischen 2 Flipflops einer FSM nicht 
mehr als 5-6 Logikelemente liegen dürfen.

Gruß,
AnReRa

[Nase (Gast)]

Andreas R. schrieb:
> Lothar M. schrieb:
>> Die Tools optimieren das ganz von allein...
>
> Begehe ich jetzt einen Denkfehler wenn ich sage, dass das Synthese-Tool
> keine Vorstellung davon haben kann, welche Signallaufzeiten in der
> realen Zielhardware auftreten ?
> Das Synthese-Tool kann also bestenfalls pauschal optimieren.
Ja, begehst du.
Der Zustandsautomat ist synchron zu einem Takt. Damit steht die maximale 
Signallaufzeit eindeutig fest.
Das Synthese-Werkzeug kann sich nun aussuchen, wie viel Aufwand es 
betreiben möchte, um den Automaten unter Einhaltung aller Constraints in 
das FPGA zu bekommen. Meistens geht das mit One-Hot am leichtesten...

Andreas R. schrieb:
> Da kann man sich ausrechnen, dass zwischen 2 Flipflops einer FSM nicht
> mehr als 5-6 Logikelemente liegen dürfen.
Genau.
Das muss man sich aber nicht ausrechnen, sondern dafür hast du ein 
Synthese-Werkzeug gekauft. Das rechnet i.d.R. schneller und genauer :-)


Insgesamt habe ich aber Schwierigkeiten mit diesem 
Safe-Implementation-Kram für Zustandsautomaten. Wenn ich mir davon eine 
Besserung erhoffe, dann heißt das ja im Umkehrschluss, dass ich 
möglicherweise erwarte, dass Flipflops umkippen. Dafür ja überhaupt der 
Auwand: Damit der Automat auch bei gekippten Flipflops (a.k.a. 
ungültigen Zuständen) wieder in die Hufe kommt.
Wenn ich aber schon damit rechne, dass Flipflops kippen, hab ich andere 
Probleme. Dann kippen die nämlich auch in Zählern und anderswo...

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

Nase schrieb:
> Dann kippen die nämlich auch in Zählern und anderswo...
Das ist den Wenigsten richtig bewusst: jeder noch so schäbige Zähler ist 
eine komplette FSM mit Weiterschaltlogik und Pipapo.

[Nase (Gast)]

Lothar M. schrieb:
> Nase schrieb:
>> Dann kippen die nämlich auch in Zählern und anderswo...
> Das ist den Wenigsten do richtig bewusst: jeder noch so schäbige Zähler
> ist eine komplette FSM mit Weiterschaltlogik und Pipapo.

Ja, und was daran noch schlimmer ist: Weil den wenigsten das bewusst 
ist, kann man so einen Zähler locker leicht erhängen.
Wenn der z.B. nämlich auf einmal einen Wert annimmt, der nirgendwo 
verarztet wird.

[Duke Scarring (Gast)]

Andreas R. schrieb:
> Da kann man sich ausrechnen, dass zwischen 2 Flipflops einer FSM nicht
> mehr als 5-6 Logikelemente liegen dürfen.
Völlig richtig. Aber ich betreibe meine FSM's nicht zum Selbstzweck. Die 
sollen ja auch noch was tun. Und da kommen die Logikelemente eher bei 
'der Arbeit' zusammen, als bei der Kodierung des Zustandes.

> Begehe ich jetzt einen Denkfehler wenn ich sage, dass das Synthese-Tool
> keine Vorstellung davon haben kann, welche Signallaufzeiten in der
> realen Zielhardware auftreten?
> Das Synthese-Tool kann also bestenfalls pauschal optimieren.
Wenn man als Synthetisierer nur den Schritt vom VHDL zu LUT und FF 
betrachtet, ja dann geht es nur pauschal. Der Synthetisierer kennt nur 
die Gatterdurchlaufzeiten und kann bestenfalls eine Abschätzung für die 
Signallaufzeiten zwischen den Gattern geben.
Die genauen Laufzeiten stehen erst nach Place & Route fest.

Duke