Beim Chipdesign ist er i.d.R. unverzichtbar, bei FPGAs wird er nicht
2
unbedingt benötigt. Er kann sogar zu Problemen führen, wenn die fallenden
3
Flanke des Resetsignals zu einem ungünstigen Zeitpunkt kommt (Siehe
4
Witepaper 272 bei Xilinx). Je nach Logikdesign und der dadurch bedingten
5
Auswirkung der Resetrücknahme, ist damit u.U. eine Verlängerung des
6
Resetsignales so durchzuführen, daß das Löschen des Signals in jedem Falle
7
ausserhalb des Bereiches möglicher Flankenwechsel des Systemtaktes
8
erfolgen. Generell ist darauf zu achten, daß das asynchrone Resetsignal
9
eine genügend lange Periode besitzt, um erfasst zu werden.
Könnte jemand näher darauf eingehen?
Kann er zum Problemen führen, wenn reset ein synchrones Signal ist
und obiges vhdl template benutzt wird? Sollte eigentlich
unproblematisch
sein, denn dann steht im if Zweig komb. Logik, die Register für nächste
Flanke initialisiert. Was wäre so ein ungünstiger Zeitpunkt?
ps. Das Paper habe ich nicht leider gefunden.
Danke im Voraus
Wenn der Reset genau dann verlischt, wenn der FPGA schaltet, dann beseht
aufgrund der geometrischen Struktur und der Laufzeiten das Problem, dass
einige FFs den vorher sehen, während ihn andere hinterher sehen. Damit
liegen z.B. Zählerstartzustände in verschiedenen Modulen nicht auf
demselben clock.
Schlimm ist es, wenn die FF eines einzelnen Zählers auseinanderlaufen,
dann rennt der komplett falsch los. Dasselbe gilt für FFs in state
machines. Daher
1) alle einzelnen externen Signale einmal eintakten, wenn sie an
mehreren Stellen gebraucht werden
2) asynchrone Resets und verbundene Signale (=Busse) zweimal eintakten,
da diese voll kohärent sein müssen.
3) in Schaltungen, in denen metastabile Zustände zu Problemen füren
können, weil das aynchrone Signal nicht verspätet oder zweimal
interpretiert werden darf, überabtasten und filtern oder das Problem mit
wieteren FFs + gfs oder-Kette quantitativ erschlagen
Doch noch die Quelle gefunden.
http://www.xilinx.com/support/documentation/white_papers/wp272.pdf
Trotzdem Danke für die ausführliche Erklärung.
Bis zum Punkt 1 kann ich gut folgen.
unter Punkt 1) meinst du mit externen Signalen, externe synchrone oder
auch asynchrone Signale?
Asynch. Reset Signal ist nur in der Hinsicht ein spezielles Signal,
weil es einen höhren Fan Out hat. Ansonsten droht die verspätete
Wertübernahe bei allen asynch. Signalen. Deswegen verstehe ich nicht
ganz den Unterschied zwischen Punkt 1) und 2).
Zu Punkt 3), ist glaube ich eine gute Strategie so vorzugehen, dass
man Signal mit einem FF abtastet, dann einfach 16 Zyklen wartet,
nochmal abtastet. Bleibt Wert der Neue Wert bestehen, wird es
übernommen.
asyn)
Gemeint sind die asynchronen. Synchron würde ja bedeutet, sie passen
bereits zu FPGA-Takt. Aynchron bezieht sich auf "irgendwann in Relation
zum FPGA-Clock"
Zu 1) Wenn Du nur auf eine Flanke eines Signals wartest und nur ein FF
darauf reagiert, dann reicht einmal eintakten, weil dann genau an diesem
einen Punkt das Signal einmal übernommen wird, egal ob im stabilen oder
im instabilen Fall. Von dort aus kann man dann fein verzeigen.
Täte man das nicht, (FF weglassen) liegt da Signal je nach
Syntheseergebnis wieder an verschiedenen Stellen über Kombinatorik an
und richtet denselben Unfug an, wie der asyn-Reset.
Zu)
Bei Bussen ist doppelt deshalb nötig, weil man zusättzlich die Daten auf
einer Zeitebene erwischen muss. Sonst hat man unsinnige Werte. Ergo
eintakten und entscheiden, ob gültig, dann das Eingetaktete übernehmen.
Das geht nicht über Kombinatorik wie es machbar zu sein scheint, weil in
dem Moment, in dem die Kombinatorik entscheidet, dass der Bus zu
verwenden ist (zweimal dasselbe gekommen, oder strobe ist gekommen) sich
im Moment der Übernahme nach hinten gerade wieder was ändern kann. Da
aber auch eim Eintakten selber eine meta-Zustand herrschen kann und FFs
falsch kippen, wäre im Fall eines zu langen meta-Zustandes das
Sampleschaltwerk noch nicht stabil, bis es ausgewertet wird.
Ergo zweimal!
Wenn man im FPGA deutlich schneller ist, als die doppelte
Bus-Geschwindigkeit, sollte man einfach oversmaplen. Die
Entscheiderschaltung läuft auf dasselbe hinaus, ist aber kleiner und dei
Daten schneller valid.
Lies mal den Beitrag "Hardware mit VHDL "richtig" beschreiben."
Interessant ist bei einem asynchronen Reset nicht der Eintritt in den
Reset-Zustand, sondern das Herauskommen vom Reset-Zustand in den
Normalbetrieb.
Zu dem bereits oben beschriebenen Effekt mit dem Zähler bzw. der
State-Machine kommt bei einem komplett asynchronen Reset noch ein ganz
lustiger Effekt dazu:
Wenn auf der Reset-Leitung ein kurzer (sagen wir mal 5 ns)
ESD-Störimpuls ist, dann werden verteilt über das FPGA ein paar FFs
zurückgesetzt, und andere nicht.
Und du hast jedesmal ein anderes Fehlerbild. Das macht Spass :-/
> Beim Chipdesign ist er i.d.R. unverzichtbar,
Weil bei ASICs erst mal alle FFs ausgerichtet werden müssen.
> bei FPGAs wird er nicht unbedingt benötigt.
Weil beim Laden des FPGAs alle FFs definierte Zustände einnehmen.
>Zu)>Bei Bussen ist doppelt deshalb nötig, weil man zusättzlich die Daten auf>einer Zeitebene erwischen muss. Sonst hat man unsinnige Werte. Ergo>eintakten und entscheiden, ob gültig, dann das Eingetaktete übernehmen.>Das geht nicht über Kombinatorik wie es machbar zu sein scheint, weil in>dem Moment, in dem die Kombinatorik entscheidet, dass der Bus zu>verwenden ist (zweimal dasselbe gekommen, oder strobe ist gekommen) sich>im Moment der Übernahme nach hinten gerade wieder was ändern kann. Da>aber auch eim Eintakten selber eine meta-Zustand herrschen kann und FFs>falsch kippen, wäre im Fall eines zu langen meta-Zustandes das>Sampleschaltwerk noch nicht stabil, bis es ausgewertet wird.
Mit den Bussen habe ich bisher nichts gemacht. Vielleicht kommt es
daher,
dass ich es nur waage verstehe. Mein Wissen begrenzt sich in dem Bereich
auf 2,3 von mit verfolgte Threads wo es um fehlende Tristate Buffer in
modernen FPGAs ging, und wie man sonst Busse beschreibt.
Grob gesagt, geht es darum, dass in dem Moment der Entscheidung,
Businhalt
sich nicht verändert hat. Also wird später nur geschaut, dass die
Inhalte
gleich geblieben sind.
>Interessant ist bei einem asynchronen Reset nicht der Eintritt in den>Reset-Zustand, sondern das Herauskommen vom Reset-Zustand in den>Normalbetrieb.
Genau, nach dem Lesen des white papers ist einiges klar geworden.
>> Beim Chipdesign ist er i.d.R. unverzichtbar,>Weil bei ASICs erst mal alle FFs ausgerichtet werden müssen.
und wie entgeht man beim ASIC den Problemen beim Wegname des asynchr.
Resetsignals?
Im Grunde besteht ja das Problem immernoch.
>> bei FPGAs wird er nicht unbedingt benötigt.>Weil beim Laden des FPGAs alle FFs definierte Zustände einnehmen.
Das ist cool. Gilt das für alle FPGAs?
SRAM basierte FPGA sind damit nach Konfiguration bereits im
richtigen Ausgangszustand.
Was ist mit Flashbasierten? Ich denke hier auch.
Und was Fuse/Antifuse FPGAs?
Daniel schrieb:
> Das ist cool. Gilt das für alle FPGAs?> SRAM basierte FPGA sind damit nach Konfiguration bereits im> richtigen Ausgangszustand.
Die Erfahrung sagt, dass dies beim Spartan3 nur bei der ersten
Konfiguration nach dem Einschalten der Fall ist. Wenn man im Zuge der
Entwicklung im Betrieb ein neues Design lädt, müssen die
Initialisierungen nicht stimmen.
> Was ist mit Flashbasierten? Ich denke hier auch.> Und was Fuse/Antifuse FPGAs?
Bei Actel FPGAs braucht man ein Reset, am besten ein synchrones. Gut
eignet sich das Lock der PLL.
reset <= sres_cnt (sres_cnt'high); -- H aktives synchrones Reset
pres : process (lock_pll, clk) is
begin -- process pres
if lock_pll = '0' then -- rising clock edge
sres_cnt <= (others => '1');
elsif rising_edge(clk) then -- rising clock edge
if sres_cnt (sres_cnt'high) then
sres_cnt <= sres_cnt - 1;
end if;
end if;
end process pres;
Damit hat man nur einen Prozess, der ein asynchronen Reset verarbeiten
muss.
Tom
Lothar Miller schrieb:
> Zu dem bereits oben beschriebenen Effekt mit dem Zähler bzw. der> State-Machine kommt bei einem komplett asynchronen Reset noch ein ganz> lustiger Effekt dazu:> Wenn auf der Reset-Leitung ein kurzer (sagen wir mal 5 ns)> ESD-Störimpuls ist, dann werden verteilt über das FPGA ein paar FFs> zurückgesetzt, und andere nicht.> Und du hast jedesmal ein anderes Fehlerbild. Das macht Spass :-/
Das ist aber auch bei einem synchronen Reset tödlich oder bei jedem
anderen Signal, dass sich so verhält.
Tom
Daniel schrieb:
>>> Beim Chipdesign ist er i.d.R. unverzichtbar,>>Weil bei ASICs erst mal alle FFs ausgerichtet werden müssen.>> und wie entgeht man beim ASIC den Problemen beim Wegname des asynchr.> Resetsignals?> Im Grunde besteht ja das Problem immernoch.
Asynchronous assert, synchronous deassert.
Das Zurücknehmen des Reset erfolgt synchron. Etwa so:
> Das ist aber auch bei einem synchronen Reset tödlich oder bei jedem> anderen Signal, dass sich so verhält.
Ja, und aus diesem Grund kommt bei mir das externe Resetsignal erst mal
an ein 8 Bit langes Schieberegister, und erst, wenn alle 8 Bit den
selben Zustand haben, wird der Reset verwendet. Sicher ist sicher ;-)
Lothar Miller schrieb:
>> Das ist aber auch bei einem synchronen Reset tödlich oder bei jedem>> anderen Signal, dass sich so verhält.> Ja, und aus diesem Grund kommt bei mir das externe Resetsignal erst mal> an ein 8 Bit langes Schieberegister, und erst, wenn alle 8 Bit den> selben Zustand haben, wird der Reset verwendet. Sicher ist sicher ;-)
Ist es sinnvoll wenn man ein Reset an mehreren Modulen im Design braucht
ein Reset Modul zu implementieren, dass einen Reset einsynchronisiert
und an die Module weiterleitet? Oder sollte man in jedem Modul die
Resets einsynchronisieren?
> dass einen Reset einsynchronisiert und an die Module weiterleitet?
Ja, damit du nur einen (in Zahlen 1) definierten Reset hast.
> Oder sollte man in jedem Modul die Resets einsynchronisieren?
Nein, denn dann ist zwar der Reset synchron, aber aufgrund von
Laufzeiten kann es dann sein, dass teilweise der Reset um einen Takt
versetzt ist.
Lothar Miller schrieb:
>> dass einen Reset einsynchronisiert und an die Module weiterleitet?> Ja, damit du nur einen (in Zahlen 1) Reset hast.>>> Oder sollte man in jedem Modul die Resets einsynchronisieren?> Nein, denn dann ist zwar der Reset synchron, aber aufgrund von> Laufzeiten kann es dann sein, dass teilweise der Reset um einen Takt> versetzt ist.
Danke.
Sag mal hast du beruflich mit VHDL/FPGA's zu tun oder ist das nur ein
Hobby?
Deine Antworten sind immer recht fundiert und hilfreich.
> Sag mal hast du beruflich mit VHDL/FPGA's zu tun
Ja
> oder ist das nur ein Hobby?
Ja, auch ;-)
> Deine Antworten sind immer recht fundiert und hilfreich.
Danke
Lothar Miller schrieb:
>> Sag mal hast du beruflich mit VHDL/FPGA's zu tun> Ja
Und was machst du genau?
Studienmäßig gehts bei mir auch in diese Richtung als Vertiefung.
Lothar Miller schrieb:
>> Und was machst du genau?> 20% FPGA (Ankopplung PCI/PCIe nach CAN, SPI...)
Interessant!
Würdest du denn eine CAN Bus Anbindung in der Regel mit einem FPGA
realisieren oder mit einem CAN Controller, z.B. SJA1000, wenn der zu
verwendende Mikrocontroller kein CAN integriert hat?
ja, das ist "etwas" OT...
> Würdest du denn eine CAN Bus Anbindung in der Regel mit einem FPGA> realisieren oder mit einem CAN Controller, z.B. SJA1000
Ich hatte genau diese Aufgabenstellung:
4 x CAN an einen PC anschalten. Als kleine Hürde sollte der möglichst
ähnliches Mailbox-Verhalten haben wie ein 82527.
Weil der 82257 schon lange obsolete ist, und der Bosch CC770 nicht
richtig in die Gänge kam (ROHS-Umstellung), blieb nur ein (halbwegs)
aktueller CAN-Controller oder ein CAN-Core.
Nach eingehender Betrachtung über die für die 4 zu implementierenden
Kerne benötigte FPGA-Größe (Mehrpreis) fiel die Wahl dann auf den
SJA1000. Die Pufferfunktionalität wurde dann im FPGA implementiert.
Ich hätte die CAN-Kerne schon gern im FPGA gehabt, aber gegen Geld ist
kein Kraut gewachsen ;-)
Lothar Miller schrieb:
>> Das ist aber auch bei einem synchronen Reset tödlich oder bei jedem>> anderen Signal, dass sich so verhält.> Ja, und aus diesem Grund kommt bei mir das externe Resetsignal erst mal> an ein 8 Bit langes Schieberegister, und erst, wenn alle 8 Bit den> selben Zustand haben, wird der Reset verwendet. Sicher ist sicher ;-)
Eine ganz andere Frage, wozu brauchst du bei deinen Designs noch ein
externes Reset? Mein letztes Design mit externem Reset habe ich vor 4..5
Jahren erstellt. Bei Xilinx-FPGAs habe ich gar kein Reset mehr, auch
kein internes. Da geht alles über Signal-Initialisierung bei der
Deklaration. Falls eine FSM mal hängen bleiben kann, führe ich einen
Timeout ein.
Für Actel-FPGAs erzeuge ich mir ein synchrones Reset wie im Posting
oben.
Tom
Lothar Miller schrieb:
> Die Pufferfunktionalität wurde dann im FPGA implementiert.
Puffer? Ist doch schon im SJA1000 integriert?
Welchen CAN Core hättest du denn eingesetzt?
Lothar Miller schrieb:
"Nein, denn dann ist zwar der Reset synchron, aber aufgrund von
Laufzeiten kann es dann sein, dass teilweise der Reset um einen Takt
versetzt ist."
Wenn der Reset in der jeweilingen Taktdomäne asynchron bleibt, hast du
so oder so einen oder mehrere Takte Ungewissheit. Sauberer wäre es
meiner Meinung nach, das synchrone Abschalten des Resets für jede
Taktdomäne separat vorzunehmen.
Gruß,
SuperWilly
> Eine ganz andere Frage, wozu brauchst du bei deinen Designs noch ein> externes Reset?
Na klar: für den allgegenwärtigen Reset-Taster ;-)
Ich habe in meinen Designs eine einfache Regel, die ich versuche soweit
als möglich einzuhalten:
1
Es gibt genau einen (1) Takt und keinen (0) Reset.
In 9 von 10 Fällen sind ohne weiteres beide Bedingungen leicht
erfüllbar.
> Puffer? Ist doch schon im SJA1000 integriert?
Es geht um dem Sendepuffer.
Beim 82527 kann ich mehrere Messages einspeichern, die dann nacheinander
versendet werden. Der SJA1000 hat nur 1 Sendepuffer und gibt nach
Versenden einen Interrupt.
Lothar Miller schrieb:
>> Puffer? Ist doch schon im SJA1000 integriert?> Es geht um dem Sendepuffer.
Autsch! Ja klar. Danke für die Antworten!
IP Core wird wohl nichts werden, für den Xilinx CAN Core müsste man ca.
20'000 USD löhnen - zuviel bei unseren Stückzahlen.
Lothar Miller schrieb:
> Ich habe in meinen Designs eine einfache Regel, die ich versuche soweit> als möglich einzuhalten:>>
1
> ... und keinen (0) Reset.
2
>
>> In 9 von 10 Fällen sind ohne weiteres beide Bedingungen leicht> erfüllbar.
Wäre einer von 10 Fällen z.B. wenn ich ein kleines Spiel auf einem FPGA
implementieren möchte und man mitten im Spiel statt es fertig zu spielen
neustarten möchte? Da wüßte ich jetzt nicht wie ich das sinnvoll ohne
Reset machen könnte (außer man schaltet das FPGA kurz aus und lässt es
die Konfig neu laden).
> Da wüßte ich jetzt nicht wie ich das sinnvoll ohne Reset machen könnte
Du mußt in deinen Zustandsautomaten "nur" einen Init-State definieren,
in dem die ganzen Aufräumarbeiten erledigt werden. Das wäre dann sowas
ähnliches wie ein synchroner Reset.
Aber quick and dirty könnte man sich auch einen Reset-Eingang dafür
ausdenken, wobei dann z.B. die Block-RAMs nicht initialisiert werden.
Lothar Miller schrieb:
>> Da wüßte ich jetzt nicht wie ich das sinnvoll ohne Reset machen könnte> Du mußt in deinen Zustandsautomaten "nur" einen Init-State definieren,> in dem die ganzen Aufräumarbeiten erledigt werden. Das wäre dann sowas> ähnliches wie ein synchroner Reset.
Bisher ist das so, dass dem Reset ein Taster auf dem Board entspricht.
Dieser Reset wird in einem Modul auf die Weise eingetaktet wie ichs auf
deiner HP gelesen habe und das einsynchronisierte Signal wird an alle
Teilmodule die einen Reset benötigen weitergeleitet und setzen sich dann
in den von mir definierten Start/Ausgangszustand.
Bis jetzt funktioniert das mit den Teilmodulen die ich bisher habe auch
wenn das Projekt noch nicht fertig ist.
Thread beobachten
Seitenaufteilung abschalten