Latch Problem

Torben Gast #933180
Lesenswert?
• ▲
▼ 
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:
1
Signal Speicher;

2
Eingang --Eingangssginal von der FSM

3


4
--Reset

5
SYNC_PROC: process (CLK, reset_i)

6
begin

7
   if (reset_i = '1') then

8
      CS <= INI_MODE;

9
   elsif rising_edge(CLK) then

10
      CS <= NS;

11
   end if;

12
end process SYNC_PROC;

13


14


15
begin   

16
   case CS is

17
  when INI_MODE =>

18
    …

19
  when … =>

20
    …

21
  when Daten_Einlesen =>

22
    Speicher <= Eingang;

23
    …

24
  when … =>

25
    …

26
  when Daten_Auslesen =>

27
    if Speicher = ‘1’ then

28
      …

29
    end if;

30
end case;
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Jörg Gast #933208
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Lothar M. Moderator (Firma: Titel) Persönliche Seite #933451
Lesenswert?
• ▲
▼ 
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:

1
Signal Speicher;

2
Eingang --Eingangssginal von der FSM

3


4
--Reset

5
SYNC_PROC: process (CLK) -- Prozess ist nur vom CLK abhängig

6
begin

7
  if rising_edge(CLK) then

8
    if (reset_i = '1') then

9
      CS <= INI_MODE;

10
    else

11
      case CS is

12
      when INI_MODE =>

13
         CS <= NEXT_STATE;

14
         …

15
      when NEXT_STATE =>

16
         CS <= Daten_Einlesen;

17
         …

18
      when Daten_Einlesen =>

19
         Speicher <= Eingang;

20
         …

21
      when … =>

22
         …

23
      when Daten_Auslesen =>

24
        if Speicher = ‘1’ then

25
         …

26
      end case

27
    end if;   -- reset_i

28
  end if;  -- CLK

29
end process;
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jörg Gast #933471
Lesenswert?
• ▲
▼ 
@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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Lothar M. Moderator (Firma: Titel) Persönliche Seite #933601
Lesenswert?
• ▲
▼ 
>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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

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.

Formatierung
  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Dein Name und deine E-Mail-Adresse

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.