Kurzer Peak (0ps) in Modelsim Simulation

Thommy Gast 17.02.2014 13:54 #3538063

Lesenswert?

•

Hallo zusammen,

ich habe den folgenden VHDL-Code (etwas vereinfacht!).

  check_data : PROCESS (CLK, NRES)
    IF NRES = '0' THEN
      s_check_signal <= (OTHERS => '0');
      ...
    ELSIF rising_edge(CLK) THEN
      s_check_signal <= CHECK_INPUT; 
      ...
    END IF;
  END PROCESS check_data;
  s_check_signal_mod <= s_check_signal WHEN ERROR_IN = '0' ELSE (OTHERS => '1');
  s_comparator(0) <= '1' WHEN s_check_signal_mod = CFG_IN_2 ELSE '0';
  s_comparator(1) <= '1' WHEN s_check_signal_mod = CFG_IN_1 ELSE '0';
  s_valid <= '0' WHEN or_reduce(s_comparator) = '1' ELSE '1';
  VALID <= s_valid;


Ich habe also einen getakteten Prozess, in dem ich das Signal 
s_check_signal aktualisiere.

Dieses Signal wird dann in kombinatorischer Logik verschaltet und dann 
mit den statischen Inputs (CFG_IN_1/2) vergleichen und daraufhin das 
VALID-flag erzeugt.

Nun habe ich in der Simulation das oben gezeigte Bild.
Zu sehen ist ein kurzer Peak im Valid Signal der genau dann entsteht, 
wenn s_check_signal aktualisiert wird. Der Peak ist 0ps lang, wird also 
auch bei maximaler Zoom-Stufe nicht breiter.

Woher kommt dieser Peak?

Ich denke Modelsim ist eine funktionale Simulation, in der die 
Laufzeiten im Gatter keine Rolle spielen? Auch wenn ich mir nicht 
erklären kann, wieso an dieser Stelle Laufzeiten eine Rolle spielen 
sollten, denn zu jederzeit ist ja erfüllt, dass VALID = '0' sein sollte.

Vor und nach der entscheidenden Taktflanke sollte VALID eigentlich '0' 
sein, aber zur Flanke wird es kurz '1'. Vor der Flanke ist 
s_check_signal "00000010". Das verstehe ich nicht ganz.

Kann mir jemand eine Erklärung dazu geben?

Vielen Dank!
Tom

Angehängte Dateien:

peak_0ns.png (1020 Bytes)

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden

isch misch Gast 17.02.2014 14:48 #3538131

Lesenswert?

•

▲
▼

http://de.wikipedia.org/wiki/Glitch_%28Elektronik%29

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Lothar M. (lkmiller) Moderator (Firma: Titel) 17.02.2014 15:29 #3538199

Lesenswert?

•

▲
▼

Thommy schrieb:
> Woher kommt dieser Peak?
Das korrekte Stichwort hierzu ist "Delta-Cycles".
> Ich denke Modelsim ist eine funktionale Simulation, in der die
> Laufzeiten im Gatter keine Rolle spielen?
Die Berechnung des neuen Zustands ergibt erst nach Berechnung einiger 
kombinatorischer Abhängigkeiten ein stabiles Signal. Wenn sich das 
Signal nicht stabilisiert (z.B. wegen einer kombinatorischen Schleife), 
dann bricht die Simulation mit einer Fehlermeldung ab.

In der Realität wirst du auf diesem Signal dann die erwähnten Glitches 
beobachten können.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Da D. (dieter) 17.02.2014 20:27 #3538684

Lesenswert?

•

▲
▼

Thommy schrieb:
> Ich denke Modelsim ist eine funktionale Simulation, in der die
> Laufzeiten im Gatter keine Rolle spielen?

Exakt. Deswegen hat dein Peak aus die Länge 0. Wie Lothar erwähnt hat, 
ist das Signal ein (oder mehrere) Deltacycles lang auf High.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Thommy Gast 18.02.2014 08:44 #3539110

Lesenswert?

•

▲
▼

Hallo und vielen Dank!

Wie kann ich denn in meinem konkreten Fall die Glitches verhindern?
Oder muss ich damit leben, weil es anders nicht kombinatorisch zu 
beschreiben geht?

Leider bin ich auf die kombinatorische Erzeugung von VALID angewiesen...

Vielen Dank!
Tom

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Lothar M. (lkmiller) Moderator (Firma: Titel) 18.02.2014 09:01 #3539127

Lesenswert?

•

▲
▼

Thommy schrieb:
> Wie kann ich denn in meinem konkreten Fall die Glitches verhindern?
Gar nicht. Wozu auch? Du hast immer irgendwelche Glitches. Nur müssen 
die sich bis zur nächsten Taktflanke beruhigt haben.

> Leider bin ich auf die kombinatorische Erzeugung von VALID angewiesen...
Muss diese Erzeugung von VALID so kompliziert sein? Das ist ja fast 
schon "obfuscated code"...

Du hast irgendwie einen Hang zum Verkomplizieren von Dingen: warum hast 
du deine Zustände explizit auscodiert? Das ist unnötig, schlecht lesbar 
und es verhindert Optimierungen. Aber das hatten wir ja schon im 
Beitrag "WHEN OTHERS in einer FSM" diskutiert...

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Lola Gast 18.02.2014 09:06 #3539132

Lesenswert?

•

▲
▼

Mach einfach mal ein paar "WHEN" weniger ;-) Ist ja schlimm zu lesen...

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Fpgakuechle K. Gast 18.02.2014 09:13 #3539135

Lesenswert?

•

▲
▼

Thommy schrieb:
> Hallo und vielen Dank!
>
> Wie kann ich denn in meinem konkreten Fall die Glitches verhindern?
> Oder muss ich damit leben, weil es anders nicht kombinatorisch zu
> beschreiben geht?


1. der Glitch den du da siehst ist nicht der in Echt. Wenn du 
wahrscheinlich realitätsgetreue Glitches sehen willst muss du eine 
post-place&route simulation durchführen.

2. Glitches entstehen immer , man "filtert" sie mit einem getakteten FF 
weg.

3. man kann Position und Breite der Glitches beeinflußen. Beispielsweise 
durch die verwendung von wenigen logic-blocken mit hohen Fan-in 
(DRAM-LUT) statt vieler logic-blöcke mit kleinen Fan-In.

4) Laufzeitunterschiede entstehen hauptsächlich durch unterschiedlich 
langes Routing. Halte dein design kompakt (beispielsweise durch Area 
constraint). Aber auch das ist keine wirkliche Abhilfe. Mit manuellem 
Routing (FPGA-Editor) kannst du Laufzeitunterschiede steuern. Allerdings 
sind die Angaben nur max-werte. In echt schwanken die laufzeiten orts-, 
temperatur und exemplarabhängig.

Letzlich wirst du damit leben müßen. In deiner verhaltenssimulation hast 
du vielleicht noch eine Chance in dem du das or_reduce umschreibst. Aber 
das ist letzlich Selbstbetrug. In echt hast du Glitches und die kann man 
nur mit synchronen Design "ausgrenzen.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Thommy Gast 18.02.2014 11:00 #3539275

Lesenswert?

•

▲
▼

Hallo,

Lothar Miller schrieb:
> Du hast irgendwie einen Hang zum Verkomplizieren von Dingen: warum hast
> du deine Zustände explizit auscodiert?

Wie meinst Du das?
Welche Zustände meinst du?

Ihr habt schon recht, der Code ist nicht gerade übersichtlich, aber ich 
habe ein Blockbild und in dem tauchen die Signalnamen auf. Die wollte 
ich anhand der besseren Vergleichbarkeit nicht einfach verwefen.

Vielen Dank!
Tom

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Lothar M. (lkmiller) Moderator (Firma: Titel) 18.02.2014 14:04 #3539561

Lesenswert?

•

▲
▼

Thommy schrieb:
> Welche Zustände meinst du?
Z.B. den da:

   s_check_signal_mod <= ... (OTHERS => '1');
  ... WHEN s_check_signal_mod = CFG_IN_2 ...;

Und den s_check_signal, der ja irgendwie mit Symbolen verheiratet wird, 
aber trotzdem nur ein Vektor ist...
Wie gesagt, wir hatten das im vorhin verlinkten Beitrag schon 
diskutiert: du würdest da beser einen eigenen Typ definieren und 
könntest dann symbolisch arbeiten.

Fpga Kuechle schrieb:
> In echt hast du Glitches
Ein Problem ist ein Glitch allerdings nur dann, wenn so ein Signal zur 
Ansteuerung eines Flipflops (lach jetzt bloß keiner: ein asynchroner 
kombinatorischer Reset war schon oft die Ursache für einige Tage voller 
Sorgen) oder gar eines Latches verwendet wird...

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Kurzer Peak (0ps) in Modelsim Simulation

Antwort schreiben