www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Design - Faustregeln


Autor: Pat Rik (patrik)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,
ich versuche einen Spartan3E XC3S500E auf dem StarterKit mit Xilinx ISE
10.1 zu programmieren. Im Anhang ist eine Schaltung zu finden, die einen 
digitalen Signal (Low=0V, High=3.3V) liefert. Das Signal ist cca. 7ms 
High und dann cca. 70ms Low und das wiederholt sich. Und ich möchte den 
FPGA so programmieren, dass ich auf einem anderen Pin eine 'Kopie' von 
diesem Eingangssignal bekomme. Das Eingangssignal bereitet mir aber 
grosse Kopfschmerzen und bringt den FPGA durcheinander.
Ich habe folgendes versucht:

proc: process(clk, reset)
begin
  if reset = '1' then
    CHANGED_SIGNAL <= '0';
    fsm_p <= wait_for_start_p;
  elsif clk'event and clk = '1' then
    case fsm_p is
      when wait_for_start_p =>
        if SIGNAL_ORIG = '1' then
          CHANGED_SIGNAL <= '1';
          fsm_p <= process_neutral;
        end if;
      when process_neutral =>
        if SIGNAL_ORIG = '0' then
          CHANGED_SIGNAL <= '0';
          fsm_p <= inj_p_debounce;
        end if;
      when inj_p_debounce =>
        fsm_p <= wait_for_start_p;
    end case;
  end if;
end process;


Wenn ich das an Osci anschliesse, dann bleibt ab und zu mal das
Ausgangssignal 'hängen'. Es kopiert das Eingangssignal nicht, sondern 
bleibt ab und zu mal eine ganze Periode(77ms) auf High oder Low und dann
geht es wieder kurz ordentlich und dann bleibt es wieder hängen usw.
Ausserdem, wenn ich in den FSM Zuständen anderen Signalen einen Wert 
zuweise, wird dieser ab und zu nicht richtig übernommen. Manchmal kommt 
der FSM in einen undefinierten Zustand und dann geht auch gar Nichts 
mehr. Ich weiss, dieser FSM ist unsafe, aber selbst wenn ich 
zusätzlichen Zustand hinzufüge und den FSM safe mache, bringt es nichts.
Ich habe viel rumexperimentiert und habe herausgefunden, dass wenn das
Eingangssignal gelesen wird oder das Ausgangssignal gesetzt wird, sollte
nichts anderes gemacht werden, ausser den FSM auf den nächsten Zustand 
setzen. Dann scheint es auf dem Osci zu funcen.
Hier ein Beispiel das zu funktionieren scheint:

proc: process(clk, reset)
begin
  if reset = '1' then
    CHANGED_SIGNAL <= '0';
    s0 <= '1';
    s1 <= '0';
    s2 <= '0';
    s3 <= '0';
    is_start <= '1';
  elsif clk'event and clk = '1' then
    if s0 = '1' then
      is_start <= '1';
      if SIGNAL_ORIG = '1' then
        s0 <= '0';
        s1 <= '1';
      end if;
    elsif s1 = '1' then
      s1 <= '0';
      s2 <= '1';
      CHANGED_SIGNAL <= '1';
    elsif s2 = '1' then
      is_start <= '0';

      if SIGNAL_ORIG = '0' then
        s2 <= '0';
        s3 <= '1';
      end if;
    elsif s3 <= '1' then
      CHANGED_SIGNAL <= '0';
        s3 <= '0';
        s0 <= '1';
    else
      leds(3) <= '1';
    end if;
  end if;
end process;


Aber wieder, wenn ich versuche, CHANGED_SIGNAL dort zu setzen wo 
SIGNAL_ORIG gelesen wird, geht das ganze nach kurzer Zeit in den else 
Zweig und dann geht nichts mehr.

Ich weiss, CHANGED_SIGNAL <= SIGNAL_ORIG; funktioniert vorzüglich, ich
möchte aber verstehen, warum die erste Lösung nicht funktioniert und 
sich so merkwürdig verhält(bzw. auch die zweite Lösung wenn 
CHANGED_SIGNAL dort gesetzt wird wo SIGNAL_ORIG gelesen wird)?

Gibt es faustregel die man beim Design beachten muss, wie z.B. dass das
Eingangssignal in einem anderen FSM/Prozess gelesen werden muss, oder 
muss ich die Eigenschaften des Eingangspins anders setzen (PullUp und 
PullDown habe ich schon versucht, den I/O Standard Des Eingangspins habe 
ich auf LVTTL gesetzt)?

Hat jemand eine andere Idee warum das merkwürdige Verhalten oder wie ich
das Problem ZUVERLÄSSIG lösen kann?

Ich bin für jede Idee dankbar da ich nicht weiterarbeiten will, solange
ich das nicht verstehe.

Danke
Patrik

Autor: Joko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hat jemand eine andere Idee warum das merkwürdige Verhalten oder
>wie ich das Problem ZUVERLÄSSIG lösen kann?
ja

>Gibt es faustregel die man beim Design beachten muss,
ja

>wie z.B. dass das Eingangssignal in einem anderen FSM/Prozess
>gelesen werden muss
nein

----------
Dein "Problem" ist ein grundlegendes: man MUß synchron arbeiten !

d.h.: alle Signale müssen auf den Arbeitstakt synchonisiert sein!

Dein Eingangssignal ist jedoch asynchron ! :-(((

Deine Statemachine besteht aus mehr 2 States, d.h. sie besteht aus
mehr als einem FlipFlop
Dadurch kann es passieren, daß bei einem Zustandswechsel des
Eingangssignals ein (oder mehrere) FF(s) einen anderen Wert 
'sieht/sehen',
als die anderen und dadurch die FSM in einen undefinierten Zustand 
gerät.
(Metastabilität - die im Prinzip bei Dir auch auftreten kann - ist dabei
unwahrscheinlicher als der o.a. Effekt)

>Ich weiss, dieser FSM ist unsafe, aber selbst wenn ich zusätzlichen
>Zustand hinzufüge und den FSM safe mache, bringt es nichts.
Bist Du Dir sicher, daß die FSM 'safe' ist? vielleicht wurde sie auch
als 'one hot' implementiert, dann ist sie (in Deinem Fall) immer noch
'unsafe'

Die einzig 'richtige' Vorgehensweise:
Taste Dein Eingangssignal mit zwei (2) hintereinander geschalteten FFs
(mit der FSM-clock) ab und führe das Ausgangssignal an Deine FSM...

Gruß
Jochen

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> faustregel die man beim Design beachten muss
- ein (1) Takt
- keine unnötigen State-Machines
- synchroner Reset
- externe Signale einsynchronisieren

Und wie bei allen Faustregeln gilt, dass an der geeigneten/nötigen 
Stelle davon abgewichen werden darf/soll/muß.

Zu deinem Problem sieh mal dort:
Beitrag "Re: 1 clk impuls erzeugen"

Ganz schlimme Sachen passieren, wenn du das externe Signal direkt auf 
mehrere FFs in einer SM legst. Dann gibt es wirklich mal unerwartete und 
nicht nachvollziehbare Sprünge zwischen den Zuständen. Bei einer 
One-Hot-Implementierung kann es dann sogar sein, dass mehrere FFs hot 
sind  :-o

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>Ich weiss, dieser FSM ist unsafe, aber selbst wenn ich zusätzlichen
>Zustand hinzufüge und den FSM safe mache, bringt es nichts.
Es ist Unsinn, eine SM "safe" machen zu wollen. Das heißt ja nichts 
anderes als: "Ich rechne damit, dass etwas schiefgeht, und definiere 
daher alle Zustände. Dann findet die SM immer einen Weg zurück."
Augen zu und durch :-(

Wichtiger ist es, die Eingangssignale für die SM "safe" zu machen. Und 
in der Praxis heißt das "Einsynchronisieren".


In den Synthese-Properties gibt es die Möglichkeit, die SM safe codieren 
zu lassen (Bild). Diese (scheinbare) Sicherheit kostet aber ganz enorm 
Ressourcen. Als Beispiel:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity StateMachine is
    Port ( clk  : in  STD_LOGIC;
           inp  : in  STD_LOGIC;
           outp : out  STD_LOGIC);
end StateMachine;


architecture Behavioral of StateMachine is
type   State_Type is (S0, S1, S2, S3);
signal state   : State_Type := S0;

signal inpsr  : unsigned(1 downto 0); -- Schieberegister zur Synchronisation
signal inploc : STD_LOGIC;            -- synchronisierter Eingang

begin
   -- SM arbeitet komplett nur mit synchronen Signalen
   process begin
      wait until rising_edge(clk);
      case (state) is 
         when S0 => if (inploc='0') then 
                       state <= S1; 
                    end if;
         when S1 => if (inploc='1') then 
                       state <= S2; 
                    end if;
         when S2 => if (inploc='0') then 
                       state <= S3; 
                    end if;
         when S3 => if (inploc='1') then 
                       state <= S0; 
                    end if;
      end case;
   end process;

   -- Eingang einsynchronisieren und auf lokales Signal abbilden
   process begin
      wait until rising_edge(clk);
      inpsr <= inpsr(0) & inp;
      if (inpsr="00") then inploc<='0'; end if;
      if (inpsr="11") then inploc<='1'; end if;
   end process;
   
   outp <= '1' when state=S0 or state=S1 else '0';

end Behavioral;

....

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
... Daraus wird mit One-Hot ohne die Safe-Implementation sowas wie im 
Bild.
(hier ist nur die eigentliche SM, das Synchronisieren geschieht 
ausserhalb, es ist also das Signal In0 = inploc)

Es könnten hier durch asynchrone Signale, die dirket auf mehrere FFs 
gehen, durchaus auch mal 2 der FFs aktiv werden. Ab dann rennt die SM 
komplett neben der Kappe :-o

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
... Mit One-Hot "safe" wird sowas synthetisiert.
Das Abfangen der unzulässigen Zustände (mehrere FFs auf '1') kostet 
ziemlichen Aufwand. Wer für diese "Sicherheit" soviel Logik verheizen 
will, der soll das ruhig tun. Wenn hier mit einem asynchronen Signal 
hineingefahren wird, gibt es zwar keinen "verbotenen" Zustand mehr, aber 
es kann trotzdem sein, dass ungültige Transitionen durchgeführt werden. 
Und das ist im Ergebnis genauso falsch :-o

Fazit: eine SM an sich muß nicht "safe" sein. Die Eingangssignale zur SM 
müssen "safe" sein. Das werden sie durch das 
Eintakten/Einsynchronisieren.

Autor: Pat Rik (patrik)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,
Hut ab und 10^6 x DANKE!!! :-))

Patrik

Autor: mac4ever (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die SM vollständig auskodieren würde ich sicherlich auch nicht, aber 
warum sehe ich nirgends ein "when others =>" ? Falls die SM dann in 
einen nicht definierten Zustand springt, kann man das wenigstens 
abfangen. Oder ist das bei One-Hot-Kodierung überflüssig ?

Autor: Pat Rik (patrik)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe an vielen Stellen gelesen, dass when others nicht alle 
theoretisch möglichen Zustände abdeckt, sondern nur diejenigen, die in 
der Aufzählung definiert sind, nicht aber durch when Klausel behandelt 
werden. Somit kann die FSM selbst mit when others in einem undefinierten 
Zustand geraten.

Autor: Joko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@mac4ever
>[..] ich nirgends ein "when others =>" ? Falls die SM dann in
>einen nicht definierten Zustand springt, kann man das wenigstens
>abfangen.

eben nicht: um Ressourcen zu sparen ignoriert die Synthese per default
den "when others"-Zweig komplett !

um einen undefinierten abzufangen, muß man den safe-modus manuell
einschalten - kostet aber wie bereits ausführlich beschrieben eine
Unmenge an Ressourcen.
Dies macht man nur, wenn man um ggf. die Auswirkungen von SEU
zu beeinflussen - glaube aber kaum, daß de OP daran denkt, seine
Schaltung in den Anden oder im Weltraum zu betreiben..

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> when others ....
> ist das bei One-Hot-Kodierung überflüssig ?
Wenn jeder Zustand auscodiert wurde, macht when-others bei der 
One-Hot-Codierung mit abgeschalteter "Safe-Implementierung" gar keinen 
Sinn. Da ist jeder definierte Zustand ein (1) FF. Der hier "gemeinte" 
when-others-Fall wäre also, wenn mehr als 1 FF aktiv wäre. Und diese 
Abfrage kostet immensen Aufwand, da dann ja alle FFs mit in die 
entscheidung einfliessen müssen (siehe dazu meine Screenshots).

Die Safe-Option ist bei binär codierten SM einfacher zu implementieren, 
aber Mehraufwand ist es immer.

Grundlegend ist ja wohl, dass üblicherweise when-others niemals erreicht 
werden darf. Und falls es doch dazu kommt, wie sollte denn dann reagiert 
werden? Und wie oft darf es dazu kommen? Darf dann einfach so weiter 
gemacht werden?

Ein lustiger Trick ist übrigens bei Designs, die ab und zu nicht 
funktionieren, einfach mal eine andere Implementierung (z.B. binär statt 
one-hot) zu erzwingen. Wenn sich dann am Verhalten was ändert, sind idR. 
asynchrone Signale und Glitches dafür verantwortlich, nicht die SM an 
sich.

Autor: mac4ever (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, danke für die Infos. Ich hab vorhin auch mal ein wenig herum gesucht 
und bin dabei auf ein Dokument der Nasa gestoßen. Dort werden genau 
Themen wie SEU und "Safe-Mode" bzw. Fehlererkennung angesprochen. Es 
wird empfohlen eine One-Hot-Kodierung durch ein XNOR aller Zustand-FFs 
zur Fehlererkennung zu benutzen. Aber wie Joko schon treffend fragte: 
Wollen wir ins All ? :D

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du bekommst durch den Kondensator nicht wirklich steile Flanken an den 
Eingang. Das verschärft die Probleme mit der Metastabilität (die Zeit 
die der Eingang im verbotenen Bereich verbringt wird länger).

Ich würde daher auf jeden Fall noch ein Schmidt Trigger Gatter davor 
hängen - natürlich zusätzlich zu den restlichen Empfehlungen.

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich habe an vielen Stellen gelesen, dass when others nicht alle
> theoretisch möglichen Zustände abdeckt, sondern nur diejenigen, die in
> der Aufzählung definiert sind, nicht aber durch when Klausel behandelt
> werden. Somit kann die FSM selbst mit when others in einem undefinierten
> Zustand geraten.

Die Sache ist etwas komplexer. Rein formal deckt "when others" alle 
nicht explizit aufgeführten Fälle ab; rein formal sind aber nur die im 
Datentyp aufgelisteten Fälle überhaupt möglich. "When others" deckt 
also tatsächlich nur die im Typ aufgelisteten Fälle ab, weil die andern 
aus Sicht des VHDL-Codes nicht möglich sind und deshalb weder auftreten 
können noch behandelt werden können.

Problem bei der Sache ist, dass die Synthese gar nicht den eingegebenen 
VHDL-Code synthetisiert, sondern einen abgewandelten Code mit kleineren 
Änderungen, in dem zum Beispiel noch andere als die aufgelisteten Fälle 
möglich sind. Wie diese zusätzlichen Fälle behandelt werden, hängt dann 
davon ab, wie diese Code-Transformation im Detail passiert. Die ist Teil 
des Synthesetools, und man kann per Parameter steuern, wie die 
Transformation abläuft. Einer dieser Schalter ist der erwähnte 
"safe"-Schalter, welcher im wesentlichen einen Übergang der neu 
eingeführten Zustände in einen definierten Startzustand einfügt.

Man kann also, sobald eine solche Transformation im Spiel ist, nicht 
mehr genau sagen, ob "when others" die neu eingeführten Fälle abdeckt. 
Das ist abhängig vom Synthesetool. In VHDL-Manuals wird dazu nichts zu 
finden sein, weil diese nur die Semantik eines VHDL-"Programms" 
festlegen, aber nicht, wie dieses Programm bei der Synthese verändert 
werden soll. Im Manual zum Synthesetool gibt es evtl. Informationen 
dazu. Desweiteren gibt es auch gewisse Standards, wie die 
Code-Transformation bei der Synthese abzulaufen hat, aber da kenne ich 
mich leider nicht aus.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich würde daher auf jeden Fall noch ein Schmidt Trigger Gatter davor
> hängen - natürlich zusätzlich zu den restlichen Empfehlungen.
Das war Herr Otto Schmitt, der mit dem Trigger.

Und dieses Schmitttrigger davorhängen ist absolut unnötig. Wenns fürs 
Gewissen und das Gefühl unbedingt sein muß, dann häng doch einfach noch 
ein Register dahinter. Im FPGA gibts genug davon.

Aber dann sind wir schon fast auf dem Niveau vom sauerstofffreiem Kupfer 
für Leiterbahnen... ;-)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> rein formal sind aber nur die im Datentyp aufgelisteten Fälle
> überhaupt möglich.
Und genau auf dieser formalen Ebene läuft dann auch eine 
Verhaltens-Simulation ab.
D.h. hier können wir dann auch gleich den Aberglauben aufräumen, in 
einer Verhaltens-Simulation so ein Verhalten nachstellen und finden zu 
können.

Autor: Pat Rik (patrik)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eigentlich geht der Pin nicht in FPGA sondern in einen Schmidt-Trigger 
und erst danach in FPGA, mein Fehler! Ob er jetzt nötig ist oder nicht, 
das kann ich nicht beurteilen, da kenne ich mich viel zu wenig aus. Ich 
könnte es aber ohne den ausprobieren, denn die Entprellung, die im FPGA 
stattfindet(nicht in dem Beispiel von mir enthalten), ist dann meiner 
Meinung nach ausreichend.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller (lkmiller) wrote:
> Das war Herr Otto Schmitt, der mit dem Trigger.

Patrik Krizan wrote:
> ... Schmidt-Trigger ...

Lernresistent? ;-)

Für das FPGA ist ein Signal erst dann interessant, wenns am IO-Buffer 
ankommt. Ob davor noch irgendwelche Signalkonditionierungen stattfinden 
ist für das FPGA komplett uninteressant. Egal wie steilflankig dieses 
asynchrone Signal ist: es muss auf den Takt (der SM) einsynchronisiert 
werden.

Stichworte dazu sind Setup-Zeit, Hold-Zeit und Metastabilität.


BTW:
der Pin geht nirgendwohin, der ist fest am Gehäuse angebracht.

Autor: Pat Rik (patrik)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, jetzt werd' ich mir es schon merken ;-)

Autor: Dida (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Lothar Miller (lkmiller): verschone uns mit deiner Krümmelkackerei!

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dida wrote:
> @ Lothar Miller (lkmiller): verschone uns mit deiner Krümmelkackerei!
Dito.
Krümel... ;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.