Latch Problem

[Torben (Gast)]

Moin,
ich hab eine diesmal eine grundlegende Frage in Bezug auf Latches.
Im Moment besteht meine Datei aus einer FSM mit mehreren States, in 
einem dieser werden Werte vom Eingangssignal übernommen und in einem 
anderen State bereitgestellt. Der Reset erfolgt außerhalb dieser FSM.
Mein Problem ist, dass die Übernahme der Werte der Eingangssignale in 
einem Latch enden. Wie kann ich darauf ein Vernünftiges Register machen, 
dass die Werte auch zwischenspeichert und mir je nach Bedarf die Werte 
auch wieder bereitstellt?

Hier einmal das Konzept meines FSM incl. Reset:

Signal Speicher;
Eingang --Eingangssginal von der FSM

--Reset
SYNC_PROC: process (CLK, reset_i)
begin
   if (reset_i = '1') then
      CS <= INI_MODE;
   elsif rising_edge(CLK) then
      CS <= NS;
   end if;
end process SYNC_PROC;


begin   
   case CS is
  when INI_MODE =>
    …
  when … =>
    …
  when Daten_Einlesen =>
    Speicher <= Eingang;
    …
  when … =>
    …
  when Daten_Auslesen =>
    if Speicher = ‘1’ then
      …
    end if;
end case;

[Jörg (Gast)]

Du hast nur ein Code-Fragment, beim zweiten Prozess fehlt "process(..)".
"Speicher" wird im zweiten Prozess nicht per Default gesetzt bzw. nicht
in jedem Case gesetzt; das hat ein Latch zur Folge.

Um nun ein FF/Register zu erzeugen, gibt es verschiedene Möglichkeiten.
Definiere z.B. zu "speicher" ein weiteres Signal

  ...
  signal speicher     : was_auch_immer_type := was_auch_immer_value;
  signal speicher_reg : was_auch_immer_type := was_auch_immer_value;
  ...

und setze im ersten Prozess

  elsif rising_edge(CLK) then
    ...
    speicher_reg <= speicher;
    ...
  endif;

und im zweiten Prozess vor der Case-Anweisung

  speicher <= speicher_reg;
  case ...
    ...

Statt der Werteinitialisierung kannst du auch den Wert im Reset-Teil
definieren (nicht alle Synth-Tools bieten Werteinitialisierung).


Gruss

Jörg

[Torben (Gast)]

Genau das hab ich gebraucht, danke für deine schnelle Hilfe.

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

Alternativ gewöhne man sich die 1-Prozess-Schreibweise und auch gleich 
den synchronen Reset an, da kann man sich ein transparentes Latch nicht 
so ohne weiteres einfangen:

Signal Speicher;
Eingang --Eingangssginal von der FSM

--Reset
SYNC_PROC: process (CLK) -- Prozess ist nur vom CLK abhängig
begin
  if rising_edge(CLK) then
    if (reset_i = '1') then
      CS <= INI_MODE;
    else
      case CS is
      when INI_MODE =>
         CS <= NEXT_STATE;
         …
      when NEXT_STATE =>
         CS <= Daten_Einlesen;
         …
      when Daten_Einlesen =>
         Speicher <= Eingang;
         …
      when … =>
         …
      when Daten_Auslesen =>
        if Speicher = ‘1’ then
         …
      end case
    end if;   -- reset_i
  end if;  -- CLK
end process;

[Jörg (Gast)]

@Lothar Miller,

ohne jetzt eine Diskusion um 1/2/3-Prozess-Ansatz anstossen zu wollen,
ich verwende meist den 2-Prozess-Ansatz: Ein sequentieller und ein
kombinatorischer Prozess. Im sequentiellen Prozess werden nur die
sig_reg-Signale beschrieben und die sig-Signale gelesen, im
kombinatorischen nur die sig-Signale beschrieben und die sig_reg-Signale
gelesen. Habe eigentlich nie ein ungewünschtes Register bzw. Latches
und falls doch, so lässt sich dass im Code sehr schnell finden(z.B.
Default-Wert im Kombi-Teil vergessen etc..). Siehst du dann einen
Nachteil?

Gruss

Jörg

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

>ohne jetzt eine Diskusion um 1/2/3-Prozess-Ansatz anstossen zu wollen...
FULL ACK ;-)

>...Siehst du dann einen Nachteil?
Nein, wenn du dir bewusst bist, dass du im nicht getakteten Teil nur 
Kombinatorik bekommst, ist das nicht nachteilig. Nur ist es eben so, 
dass viele (Anfänger-)Probleme auf diese Mehr-Prozess-Schreibweise 
zurückzuführen sind.
Wenn z.B. im getakteten Teil irgendwas mit einem Signal gemacht werden 
soll und auch im kombinatorischen Teil, dann haut dir der Synthesizer 
ein paar Fehler ums Ohr, und dann geht das Gebastel los.

Klar hat auch die 1-Prozess-Darstellung ihre Macken, und da hat sich 
schon mancher mal 1 Takt Latency eingehandelt.
Aber was mir am besten gefällt, ist dass die Simulation immer klappt.
Weil nur 1 Signal in die Sens-List eingeht, können die allseits 
bekannten Simulationseffekte mit vergessenen Signalen gar nicht 
auftreten.