Reset oder PLL Problem?

[Matthias (Gast)]

Hallo,

ich ärgere mich hier schon längere Zeit an einem Problem rum, jetzt 
scheint es mal zu funktionieren (das schien es aber auch schon früher 
mal und dann trat wieder was auf) und ich bin ein wenig verwirrt.

Das System ist so aufgebaut, dass ein Stratix 2 mit einem anderen Chip 
einerseits über ein Schreib- und andererseits ein Lese-Interface 
"spricht". Die Interfaces sind Source-Synchronous, wobei der FPGA das 
Schreib-Interface taktet und der andere Chip das Leseinterface über 
einen mit simpler FF Logik vom Sendetakt abgeleiteten Takt. In der FPGA 
Implementierung gibt es einen kleinen Teil, der auf dem Rücktakt 
arbeitet und die gelesenen Daten über einen Dual-Clock FIFO wieder in 
eine andere Taktdomäne zur Weiterverarbeitung schiebt. Der Rücktakt wird 
dabei über eine PLL geführt, um die Phase verändern zu können.

Als Feature haben wir, dass der Stratix den anderen Chip resettieren 
kann.

Dieser Reset macht nicht deterministische Schwierigkeiten und zwar nach 
meiner Analyse in dem kleinen Teil, der auf dem Rücktakt läuft. Mit 
SignalTap hab ich hier einen Zähler falsch zählen sehen und die Input 
Signale vollkommen inkorrekt bzw gar nicht eingelesen, obwohl ich sie 
einerseits mit einem Oszilloskop zwischen den beiden Chips gemessen habe 
und andererseits noch auf einen Logikanalysator rausgeführt habe, wo sie 
auch immer korrekt aussehen. Das seltsame Verhalten hat mich ein Problem 
mit dem Takt vermuten lassen, jetzt habe ich den problematischen Teil 
mal direkt an Takteingang gehängt ohne die PLL dazwischen und ohne dass 
der Prozess resettiert wird, der gerade laufende Test sieht ganz gut 
aus.

Was mich aber verwundert, ist dass ich es mit der PLL nicht hinbekommen 
habe. Zuerst wurde der fragliche Prozess nie resettiert und bekam das 
Ein- und Ausschwingen der PLL ab, da dachte ich an Timing Probleme in 
diesen Phasen. Ich habe dann dazu zusätzliche Logik implementiert, die 
den Reset des Rückleseteils über das locked Signal der PLL erzeugt und 
dabei mittels Schieberegister einerseits das Signal synchronisiert und 
andererseits kurze Pulse auf dem Locked-Signal herausgefiltert. Der Code 
für diese Reseterzeugung schaut so aus:

p_gen_reset_rb_clk : process (s_rb_clk, s_rb_pll_locked)
  begin
    if s_rb_pll_locked = '0' then  -- asynchronous reset (active low)
      s_reset_rb_clk <= (others => '0');
    elsif s_rb_clk'event and s_rb_clk = '1' then  -- rising clock edge
      s_reset_rb_clk <= "1" & s_reset_rb_clk(s_reset_rb_clk'high
                                                       downto 1);
    end if;
  end process p_gen_reset_rb_clk;

Von s_reset_rb_clk wird Bit 0 im Design dann als Reset Signal verwendet, 
codiert wie ein asynchroner Reset.

Damit sind weiterhin Probleme aufgetreten, obwohl das lt Logikanalysator 
ganz gut ausgesehen hat, dh die fragliche Logik bekam einen ausreichend 
langen Reset bis der Takt von der PLL stabil war.

Hat jemand eine Idee, was da passieren könnte? Aus meiner Sicht habe ich 
entweder den Reset vermurkst oder das Aus- und Einschalten des 
Eingangstakts der PLL macht Schwierigkeiten, die ich nicht sehe. Das 
komische Verhalten war allerdings sowohl mit wie ohne Reset da, den 
Fortschritt hat erst das Rausnehmen der PLL gebracht.

Sorry für den langen Text, hoffe das ist verständlich,

lg
Matthias

[Matthias (Gast)]

Nachdem mich das Thema noch beschäftigt (und um den Thread zu puschen ;) 
) noch eine Frage: Angenommen man hat einen IP Core wie beispielsweise 
den TSE_MAC von Altera, der zumindest zwei unterschiedliche Takte hat, 
den transmit clock und den receive clock, aber nur einen Reset Eingang: 
Wie soll man so ein Ding sauber resettieren? Asynchronenen Reset 
einsynchronisieren kann man mit den beiden Takten ja wohl vergessen, 
oder übersehe ich da etwas?

lg
Matthias

[Duke Scarring (Gast)]

Matthias schrieb:
> Asynchronenen Reset
> einsynchronisieren kann man mit den beiden Takten ja wohl vergessen,
Nein. Genau das muß gemacht werden. Alle asynchronen Signale müssen 
zwingend einsynchronisiert werden. Du findest dazu genügend Beiträge 
hier im Forum. Problematisch ist sonst das undefinierte Verlassen des 
Reset-Zustandes.

Dazu kommt, das wenn Du die PLL verwendest, die Taktfrequenz hintenraus 
zwar bekannt ist, aber die Phase zu keinem Eingangssignal mehr stimmt 
(außer im source-synchronous mode). Damit werden auch bisher zum Takt 
synchrone Signale quasi asynchron.

Duke

[Matthias (Gast)]

Mein Problem ist eben, dass es da einen IP Core gibt, der nur einen 
reset-Eingang aber dafür wenigstens zwei verschiedene Takte hat, in 
Wahrheit noch mehr. Wie soll ein Reset-Signal in allen Lebenslagen zu 
all diesen Takten synchron sein? Ich sehe dann nur die Möglichkeit, die 
Clocks während des Reset zu gaten. Das werde ich mir noch näher 
anschauen.

Und die Beiträge hier lese ich schon lang und gerne, hab viel gelernt 
hier. Aber so manches Design kommt halt mit einem Dutzend Interfaces und 
einem halben Dutzend verschiedenen Clocks und verschiedenen IP-Cores 
daher, da ist ein Cummings-Paper über synchronisierte asynchrone Resets 
zwar gut um das Problem zu verstehen, aber die Lösung nicht so einfach 
umsetzbar.

lg
Matthias

[Duke Scarring (Gast)]

Matthias schrieb:
> Mein Problem ist eben, dass es da einen IP Core gibt, der nur einen
> reset-Eingang aber dafür wenigstens zwei verschiedene Takte hat, in
> Wahrheit noch mehr. Wie soll ein Reset-Signal in allen Lebenslagen zu
> all diesen Takten synchron sein?
Dann wird er sich möglicherweise Reset intern auf die anderen Takte 
einsynchronisieren. Oder es gibt Teile ohne Reset. Da hilft nur genau in 
die Dokumentation zu schauen.

Duke

[Matthias (Gast)]

In der Dokumentation zum tse_mac, Abschnitt 10/100/1000 Ethernet MAC 
steht nur

"A hardware reset resets all logic. You can perform a hardware reset by 
asserting the reset signal."

Weiter unten im Abschnitt 1000BASE-X/SGMII PCS steht dann explizit von 
synchronierten Resets und diese KOmponente hat dann auch lt 
Dokumentation so viele Reset- wie Taktsignale.

Im functional simulation model wird der reset nicht synchronisiert. Aber 
das heißt ja vielleicht nichts.

Ich bin skeptisch, dass das Ding die intern synchronisiert.

lg
Matthias

[Duke Scarring (Gast)]

Matthias schrieb:
> Der Rücktakt wird
> dabei über eine PLL geführt, um die Phase verändern zu können.
Warum eigentlich? Wenn Du jeweils am Dateneingang einen asynchronen FIFO 
hast und der auf der Eingangsseite mit dem Quelltakt gefüttert wird, 
sollten die Daten richtig übertragen werden. Ist der FIFO per Wizard 
generiert worden?

Auch für den Reset brauchst Du keine PLL. Auf der Slaveseite muß der 
Reset mit dem Slavetakt einsynchronisiert werden (2 FFs) und fertig. 
Nach dem einsynchronisieren hast Du einen synchronen Reset, den kann man 
z.B. so verwenden:

process
begin
  wait until rising_edge( clk);
  if reset = '1' then
    regs <= default_regs;
  else
    regs <= new_regs;
  end if;
end process;

Duke

[Matthias (Gast)]

Die PLL hat den Grund, dass man die Phasenlage des Takts zu den Steuer- 
bzw Datensignalen verschiebbar machen wollte. Es gab zum Zeitpunkt der 
Erstellung des FPGA-Designs noch viele Unsicherheiten, wie das 
Zeitverhalten genau sein würde.

Das andere Problem dreht sich eben um den IP Core (3 zueinander async. 
Takte, ein Reset). Ich frage mich, ob sich der Arbeitsaufwand lohnt, 
alles umzuarbeiten, an das ich rankomme, wenn es dann immer noch 
signifikante Teile des Designs gibt, die vmtl nicht wasserdicht sind. 
Eine andere Möglichkeit die ich habe ist, anstatt Resets immer FPGA 
Neukonfigurationen auszulösen und zu hoffen, dass Altera das "Anfahren" 
ihres Chips wasserdicht umgesetzt hat.

lg
Matthias

[Duke Scarring (Gast)]

Matthias schrieb:
> Das andere Problem dreht sich eben um den IP Core (3 zueinander async.
> Takte, ein Reset).
Da würde ich mir keine Gedanken machen. Du hast zweimal den externen 
Takt. Wenn da was versemmelt wird, ist das Paket kaputt. Und der Reset 
wird zum internen Takt gehören, damit die State-Machines richtig 
klappern. Und (je nachdem was das Datenblatt sagt) nur zum internen Takt 
würde ich den Reset passend machen.

Duke

Matthias schrieb:
> Die PLL hat den Grund, dass man die Phasenlage des Takts zu den Steuer-
> bzw Datensignalen verschiebbar machen wollte. Es gab zum Zeitpunkt der
> Erstellung des FPGA-Designs noch viele Unsicherheiten, wie das
> Zeitverhalten genau sein würde.
Ok. Und sind diese Unsicherheiten jetzt beseitigt? Sind die 
Signallaufzeiten ausgelängt? WIe hoch ist der Takt? Hat der Takt eine 
bekannte Verzögerung zu den Daten? Sonst handelst Du Dir u.U. Setup-Time 
Verletzungen (am Ziel-FPGA) ein.

Duke

[Matthias (Gast)]

ad 1.: Werd ich so machen, obwohl ich noch leicht verunsichert bin, ob 
da dann nicht doch zb die Sende FSM alle heiligen Zeiten mal 
angeschossen werden könnte.

ad 2.: Jetzt ist das ganze recht fix und der Takt, daher kann ich auch 
auf die PLL verzichten und lese die Signale einfach auf der negativen 
Taktflanke ein. Damit hab ich gestern mal einen Langzeittest gemacht, 
der fehlerfrei lief. Mich beschäftigt aber, dass ich es imo nach allen 
Regeln der Kunst gemacht habe und dennoch hat es das Werkl aufgestellt.

lg
Matthias