Angenommen ich synchronisiere einen Reset der von außen kommt (Knopf
z.b.) über 2 Flipflops ins FPGA ein.
Diesen Reset verwende ich dann im restlichen Design asynchron zum Takt
also
1
if(rst...)elsif(clock...)endif;
Spricht man dann noch von einem asynchronen Reset und sollte das dann
einwandfrei funktionieren?
Armin schrieb:> soweit ich weiß, bügelt der Reset alles nieder - sollte also auf jeden> Fall funktionieren.
Was ich genau meinte: Treten da auch noch Glitches auf so dass ein Teil
der Schaltung noch im Resetzustand ist und der andere schon anläuft?
D. I. schrieb:> Was ich genau meinte: Treten da auch noch Glitches auf so dass ein Teil> der Schaltung noch im Resetzustand ist und der andere schon anläuft?
Nein, du hast ja geschrieben dass du den externen Reset
einsynchronisiert hast. Einen "halben" Reset wird es somit nicht geben.
Hiermit:
D. I. schrieb:> if (rst ...) elsif (clock ...) end if;
baust du Reset-Kombinatorik auf, welche sich u.U. kontraproduktiv auf
die maximale Frequenz des Designs auswirkt.
Ah ok.
Die Frage ist natürlich berechtigt und da fehlt mir die praktische
Erfahrung, um das zu beantworten.
Aber Gegenfrage: was passiert, wenn du deinen RST nicht
einsynchronisierst und trotzdem zufällig eine Flanke triffst beim
Auslösen?
Sollten die Teile nicht so designt sein, dass RST und CLK einen ähnlich
langen Weg zu den Registern haben?
Vielleicht kann man so etwas ja auch simulieren?
Warten wir mal ein bisschen - das hat bestimmt schon mal ein Praktiker
getestet ^^
Man kann sich natürlich auch fragen, warum es notwendig ist, einen
asyncRESET-Eingang zu verwenden, wenn man ohnehin weiß, dass das Signal
synchron ist.
oh es gibt schon Antworten:
spartanne schrieb:> Nein, du hast ja geschrieben dass du den externen Reset> einsynchronisiert hast. Einen "halben" Reset wird es somit nicht geben.
Die Gefahr wird wohl eher sein, dass einige Register mit einer
vorbeikommenden CLK-Flanke schon anlaufen, während andere noch im RST
sind. Darauf hat sich mein Beitrag bezogen.
Armin schrieb:>> Aber Gegenfrage: was passiert, wenn du deinen RST nicht> einsynchronisierst und trotzdem zufällig eine Flanke triffst beim> Auslösen?
Der Fall ist mir schon bewusst, da kann Gott und die Welt passieren.
Armin schrieb:> oh es gibt schon Antworten:>> spartanne schrieb:>> Nein, du hast ja geschrieben dass du den externen Reset>> einsynchronisiert hast. Einen "halben" Reset wird es somit nicht geben.>> Die Gefahr wird wohl eher sein, dass einige Register mit einer> vorbeikommenden CLK-Flanke schon anlaufen, während andere noch im RST> sind. Darauf hat sich mein Beitrag bezogen.
Nochmal: wenn du ein externes Signal mit dem Takt einsynchronisierst und
dieses synchronisierte Signal verwendest wirst du nie Probleme haben
solange zu fmax nicht verletzt. Ein FPGA ist so konstruiert, dass das
Clock-Signal quasi zeitgleich an allen Registern anliegt. Dafür hat
Xilinx, Altera, Lattice und Co. zu sorgen und der Anwender kann sich
darauf verlassen.
D. I. schrieb:>> Aber Gegenfrage: was passiert, wenn du deinen RST nicht>> einsynchronisierst und trotzdem zufällig eine Flanke triffst beim>> Auslösen?>> Der Fall ist mir schon bewusst, da kann Gott und die Welt passieren.
Da wird GARANTIERT etwas schiefgehen! Es gilt für alle externe Signale:
einsynchronisieren, egal ob Reset oder sonstwas. Wer sich daran nicht
hält ist selbst Schuld an der langwierigen Fehlersuche.
Armin schrieb:> Man kann sich natürlich auch fragen, warum es notwendig ist, einen> asyncRESET-Eingang zu verwenden, wenn man ohnehin weiß, dass das Signal> synchron ist.
Ein asynchrones Rest zu beschreiben macht schon Sinn, denn es benötigt
weniger Resourcen als ein synchrones Reset und man erreicht damit oft
auch höhere Taktraten.
Das kann man auch schön sehen, wenn man sich so einen typische CLB näher
betrachtet: Der besteht sehr vereinfacht aus einer LUT mit einem
anschließendem FF. Der Ausgang der LUT geht an den D-Eingang des FF,
aber dieses besitzt neben dem D-Eingang noch ein Enable und ein Reset
(Clock natürlich auch). Wenn man z.B. ein LUT4 hat und das D-Signal aus
4 Signalen kombinatorisch gebildet wird, dann reicht ein LUT4 dafür aus.
Wenn man dann aber noch das Reset synchron verwendet werden aus den 4
Singalen derer 5. Die Folge ist, dass dafür zwei LUT4 benötigt werden.
=> Mehr Resourcen und lägere Laufzeiten. Dafür bleibt aber der
Reset-Eingang des FF frei ;-)
Natürlich muss das Reset aber zuvor einsynchronisiert sein.
> Spricht man dann in dem Fall noch von einem asynchronen Reset oder von> einem synchronen Reset?
Es bleibt wie schon gesagt ein asynchroner Reset. Wenn das systemweit
gemacht wird, dann wären die Whitepaper WP272 und WP275 von Xilinx mal
einen Blick wert. Denn durch den asynchronen Reset werden z.B. bei
Xilinx-FPGAs die FFs im FPGA in den asynchronen Modus geschaltet, der
insbesondere die Setz-und Rücksetzeingänge beeinflusst. Das kann als
zusätzlicher Aufwand und schlechteren Laufzeiten bemerkbar machen:
http://www.lothar-miller.de/s9y/archives/70-Asynchroner-Reset.html
Und etliche Möglichkeiten (wie z.B. Schieberegister in den LUTs) werden
durch einen Reset (synchron oder asynchron) generell verhindert.
> Ein asynchrones Rest zu beschreiben macht schon Sinn, denn es benötigt> weniger Resourcen als ein synchrones Reset und man erreicht damit oft> auch höhere Taktraten.
Ich hatte mal ein Design bei Lattice MachXO-Bauteinen, da brachte ein
lokaler asynchroner Reset an handverlesenen FFs tatsächlich eine
Verbesserung... :-o
Fazit:
Bei einer VHDL-Hardware-Beschreibung darf die dahinterliegende Hardware
niemals ausser Acht gelassen werden, wenn ein halbwegs optimales Design
herauskommen soll.
>Fazit:>Bei einer VHDL-Hardware-Beschreibung darf die dahinterliegende Hardware>niemals ausser Acht gelassen werden, wenn ein halbwegs optimales Design>herauskommen soll.
Da hat sich jemand besonnen ;O)
VG,
SuperWilly
Diese Aussage auf Seite 2 in CummingsSNUG2002SJ_Resets stimmt so
unbesehen allerdings nicht:
1
This coding style will generate extraneous logic as shown in Figure 1.
Es wird hier keinerlei zusätzliche Logik erzeugt (Bild_1)!
Es wird lediglich (wie ja auch im Code beschrieben) das Reset-Signal
unnötigerweise auf den Clock-Enable-Eingang des 2. FFs aufgeschaltet.
1
libraryieee;
2
useieee.std_logic_1164.all;
3
4
entityFFstyleis
5
port(
6
clk:instd_logic;
7
rst_n:instd_logic;
8
d:instd_logic;
9
q2:outstd_logic);
10
endFFstyle;
11
12
architecturertlofFFstyleis
13
signalq1:std_logic;
14
begin
15
process(clk)
16
begin
17
if(clk'eventandclk='1')then
18
if(rst_n='0')then
19
q1<='0';
20
else
21
q1<=d;
22
q2<=q1;-- 1) rst_n geht auf clock-enable von q2 (Bild_1)
23
endif;
24
q2<=q1;-- 2) q2 wird nur getaktet (Bild_2)
25
endif;
26
endprocess;
27
endrtl;
Es ist auch keineswegs (wie in dem PDF vorgeschlagen) nötig, 2 Prozesse
zu verwenden. Es muß nur die Zuweisung an q2 ausserhalb des Reset-Zweigs
passieren.
Letztendlich ist der Satz, den Lothar geschrieben hat die ganze
Wahrheit:
> Fazit:> Bei einer VHDL-Hardware-Beschreibung darf die dahinterliegende Hardware> niemals ausser Acht gelassen werden, wenn ein halbwegs optimales Design> herauskommen soll.
Xilinx empfiehlt explizit synchrone Resets, siehe auch Whitepaper WP231.
Das widerspricht zum Teil dem, was Cliff Cummings in seinen Papers
schreibt.
Bei einem neuen Design habe ich kürzlich aus Neugierde ausprobiert, wie
gross der Unterschied im Bezug auf Altera FPGAs ist, da es ein solch
schönes Whitepaper bei Altera schlicht nicht zu geben scheint.
Die Ergebnisse sind eigentlich recht eindeutig (Zumindest für mein recht
kleines Submodul):
CycloneII-C6: sync reset: 224 LUT, fmax 64,3MHz; asnyc reset: 187LUT,
69,5MHz
(Vergleichbare Ergebnisse für CycloneIII-C7)
Dem StratixIII wiederum ist es ziemlich Wurst, da ändern sich (mit dem
selben Design) die Syntheseergebnisse marginal.
Der Unterschied ist nur der Reset für insgesamt 73FFs.
Weiter sagt z.B. der Altera DRC zu einem asynchronen Reset folgendes:
Warning: (Medium) Rule R102: External reset signals should be
synchronized using two cascaded registers. Found 1 node(s) related to
this rule.
Quartus möchte also wohl einen synchronisierten Reset, der allerdings
auf die async_reset Pins der FFs geführt wird.
Fazit:
Literaturstudium (für die Zielplattform!) und ggf. eigene Tests sind bei
solchen Streitfragen äusserst wichtig. Das "richtig" für alle
Plattformen gibt es nicht.
p.s. Übrigens gilt das gleiche auch für Verilog :-)
> This coding style will generate extraneous logic as shown in Figure 1.
extraneous:
fremd
irrelevant
unerheblich
unwesentlich
fremdländisch
nicht relevant
nicht zur Sache gehörig
In der Sache bleibt es gleich: es wird keine unwesentliche oder
belanglose (oder was auch immer) Logik generiert, weil eben überhauptkeine Logik erzeugt wird.
Lothar Miller schrieb:> In der Sache bleibt es gleich: es wird keine unwesentliche oder> belanglose (oder was auch immer) Logik generiert, weil eben überhaupt> keine Logik erzeugt wird.
Doch, es wird unnötige Hardware generiert: Ein ladbares Flipflop!
In einem FPGA ist das egal. Dort hat man multifunktionale FFs. Aber in
einem ASIC wird nun eine andere Zelle, nämlich eine mit lade Eingang,
verwendet. Und ein solches ist nicht unerheblich größer.
> Aber in einem ASIC wird nun eine andere Zelle,> nämlich eine mit lade Eingang, verwendet.
Richtig, ich hatte überlesen, dass in den PDFs eigentlich nur von ASICs
geschrieben wird :-/
>Nochmal: wenn du ein externes Signal mit dem Takt einsynchronisierst und>dieses synchronisierte Signal verwendest wirst du nie Probleme haben>solange zu fmax nicht verletzt.
Genau deshalb kannst du ein Problem haben! Das Einsynchronisieren nutzt
dir bei der Verwendung als asynchroner Reset wenig, da die statische
Timinganalyse beim Place and route Pfade die an asynchronen Eingängen
enden nicht erfasst. Es kann dir sehr wohl passieren, das ein Teil der
Schaltung aus dem reset fällt, während der andere Teil sich noch im
selben befindet. Auch bei der Verwendung des dedizierten Reset
Netzwerkes (Xilinx:StartUp-Komponente). Deshlab rät ja Xilinx seit
VirtexII vom asnychronen Reset insbesonders bei großen FPGA's ab.
Ein PERIOD constraint erfasst eben nicht die Pfade vom Ausgang der
Synchronisierstufe bis zum nächsten Eingang. Das kann daher schon mal
länger als eine Periode (oder eine halbe bei DDR -Output-FF) dauern. Bei
Xilinx muss du dann schon ein FROM TO constraint setzen um ein
asynchrones Erwachen zu verhindern, aber dann kannst du auch gleich
einen synchronen Reset nutzen.
Die FF bei Altera haben beide Eingänge - asynchron und synchron -
deshalb ist bei diesen kein Vorteil bei der Resourcenausnutzung für
synchron feststellbar. Falls die Implementierung mit synchr. Reset
langsamer ausfällt, hilft es das letzte Synchronisier-FF zu
vervielfachen, also den "vorsynchronisierten" Reset sternförmig zu
verteilen und so mehrere lokale synchrone Resetquellen zu erzeugen.
MfG,
> Die FF bei Altera haben beide Eingänge - asynchron und synchron -> deshalb ist bei diesen kein Vorteil bei der Resourcenausnutzung für> synchron feststellbar.
Sie haben laut Handbuch eine dedizierte synchrone Load and Clear Logik.
Den zweiten Satz kann ich jedoch nicht unterschreiben, ein praktischer
Versuch zeigt mir jedenfalls deutliche Unterschiede zwischen asynchron:
1
always @(posedge clk or negedge reset_n)
2
begin
3
if (!reset_n)
4
phase <= 33'sd0;
5
else if (enable)
6
phase <= result2;
7
end
und synchron:
1
always @(posedge clk)
2
begin
3
if (!reset_n)
4
phase <= 33'sd0;
5
else if (enable)
6
phase <= result2;
7
end
Die Werte hab ich weiter oben ja schon geschrieben. Aber hier gehts ja
um die Theorie, also bin ich mit meiner Praxis jetzt mal ruhig.
*******************************
Keine Asynchronen Resets bauen!
*******************************
Ist bei FPGAs kontraproduktiv!
Meistens braucht man nicht einmal einen globalen Reset, weil die
Bausteine in definierte Startzustände gebracht werden können.
Das einzige, was es braucht ist ist Möglichkeit, ALLE state machines
wieder in einen Startzustand zu bringen. Das geht am besten voll
synchron mit ihrem jeweiligen Takt.
> Meistens braucht man nicht einmal einen globalen Reset
Meistens gibt es nicht mal einen globalen Reset, denn aktuelle FPGAs
haben kein dediziertes globales Reset-Netzwerk mehr...
Fazit: Jeder Reset muß aufwändig quer durchs ganze FPGA geroutet werden.
Jeder sollte sich die Frage stellen:
Wofür brauche ich an dieser Stelle einen Reset?
Und wenn die Antwort lautet:
Nur für den Power-Up und den Reset-Taster.
Dann hilft keine Ausrede mehr, denn:
Power-Up-Zustände für Register können als Defaultwerte angegeben werden.
Den Reset-Taster drückt ausser dem Entwickler niemals irgendjemand.
(Und falls doch, dann ist das Design noch nicht fertig.)
Hallo,
also ich bevorzuge die Reseteinsynchronisierung in folgender Art.
Reset wird asynchron ausgelöst und mit der fallenden Clockflanke
losgelassen.
Hier mal ein einfaches Beispiel:
signal schieberegister : std_logic_vector(1 downto 0);
...
process (ext_resetsignal, clock)
begin
if ext_resetsignal = '1' then
schieberegister <= "00";
elsif falling_edge(clock) then
schieberegister <= schieberegister(0) & '1';
end if;
end process;
reset <= schieberegister(1);
Ansonsten (zur eigentlichen Frage): wenn der Reset mit 2 Flipflops
einsynchronisiert wurde ist das kein asynchroner Reset mehr, da er die
Clock benötigt um eine Auswirkung zu haben. Das ist bei der Schaltung
hier nicht der Fall.
Zu beachten ist, dass sich die meisten hier im Forum mit FPGAs
beschäftigen. Die Vorschläge sind manchmal recht ungeeignet für ein
ASIC. Und gerade beim Reset scheint das ganz besonders der Fall zu sein.
Der Besucher
> Reset wird ... mit der fallenden Clockflanke losgelassen.
Verwendest du auch im restlichen Design den fallenden Takt?
Falls nein, dann hast du ja nur die halbe Zeit für das Routing dieses
Reset-Signals zur Verfügung, um die Setupzeit tsu der angeschlossenen
FFs nicht zu verletzen...
Denn wie gesagt: im FPGA gibt es kein Reset-Netz. Das wird alles
handverdrahtet.
> Zu beachten ist, dass sich die meisten hier im Forum mit FPGAs be-> schäftigen. Die Vorschläge sind manchmal recht ungeeignet für ein ASIC.
Ja, gut, das Forum heißt ja auch FPGA, VHDL & Co ;-)
Und auch die Frage ganz zu Beginn des Freds bezog sich ziemlich
definitiv auf ein FPGA:
>>>> synchronisiere einen Reset ... über 2 Flipflops ins FPGA ein.
Im Zweifel hätte ich auch den Reset auf der entgegengesetzten Taktflanke
losgelassen. Wenn ich ihn mit der gleichen Taktflanke loslasse mit der
auch die Register arbeiten habe ich ja viel eher ein race zwischen dem
gerade losgelassenen Reset und dem Taktnetzwerk.
@Fpga Kuechle: Es gibt ja zb Reset Removal bei der Timing-Analyse, wird
sowas dabei nicht berücksichtigt?
Ich glaube an dieser Stelle muss erst noch mal geklärt werden, was genau
ein asynchrones Reset ist! Asynchron bedeutet, dass ein Register (FF)
unabhängig von seinem Clock in einen bestimmten Zustand wechselt. Dabei
ist es völlig unabhängig ob das Reset zuvor einsynchronisiert wurde oder
nicht.
Ganz gefährlich wird es wenn man dieses asynchrone Signal nicht in Bezug
zu dem verwendeten Takt des Registers bringt. Stichwörter:
Metastabilität, undefinierte Zustände, etc.
Damit es mit dem asynchronen Reset zu keinen Schwierigkeiten kommt, muss
das Reset-Signal mit dem zugehörigen Takt in Verbindung gebracht werden.
Sprich: einsynchronisiert.
Es gibt aber einige weitere wichtige Kriterien, die für die Verwendung
eines asynchronen Resets wichtig sind:
- Es muss glitchfrei sein. Daher keine Kombinatorik sondern immer ein
Ausgang eines Registers!
- Es muss das Timing des Resetpfades sichergestellt sein. Constraining!
- Es muss eine Mindestlänge haben. Sonst kann es zu Metastabilität
führen.
Vor allem letzter Punkt wird oft nicht beachtet. Es schwirren dazu viele
Codefragmente die genau diesen Punkt unberücksichtigt lassen. Folgender
geposteter Code steht für ein solches fehlerhaftes Beispiel:
1
>process(ext_resetsignal,clock)
2
>begin
3
>ifext_resetsignal='1'then
4
>schieberegister<="00";
5
>elsiffalling_edge(clock)then
6
>schieberegister<=schieberegister(0)&'1';
7
>endif;
8
>endprocess;
9
reset<=schieberegister(1);
Problematisch ist daran, dass wenn das eingehende ext_resetsignal nur
ein sehr kurzer spike (oder eine Störung) ist. Da kann es im
schieberegister(1) am Ausgang zu einem metastabilen Zustand kommen.
Funktionieren würde das ganze wenn das Bit schieberegister(1) nicht im
asynchronen Resetpfad durch ext_resetsignal bedient.
Dieses Design funktioniert nur Sicher wenn das ext_resetsignal eine
mindestlänge garantiert. Sollte aber eine Mindestlänge garantiert sein,
dann reicht es meist auch aus das externe Reset einfach über zwei
Register einzusynchronisieren.
Nun nochmal zur Theorie: Macht es Sinn ein Reset asynchron zu verwenden?
Da lautet die Antwort ganz klar Ja!. Die Register bieten nun mal die
Resourcen an, wärend man bei einer synchronen Verwendung weitere
Resourcen verschwendet. Aber man muss da genau wissen was man tut, dass
es zu keinen Problemen kommt. Vor allem aber stellt sich an erster
Stelle die Frage ob ein Reset überhaupt notwendig ist. Da hat Lothar
völlig recht.
Matthias schrieb:> Im Zweifel hätte ich auch den Reset auf der entgegengesetzten Taktflanke> losgelassen. Wenn ich ihn mit der gleichen Taktflanke loslasse mit der> auch die Register arbeiten habe ich ja viel eher ein race zwischen dem> gerade losgelassenen Reset und dem Taktnetzwerk.>> @Fpga Kuechle: Es gibt ja zb Reset Removal bei der Timing-Analyse, wird> sowas dabei nicht berücksichtigt?
Was meinst du mit reset removal?
Allgemein zur Timing analyse, prinzipiell kann jeder Pfad bei der Timing
Analyse und damit beim Place und Route berücksichtigt werden. Und jeder
Pfad kann auch ignoriert werden. In meinem Beitrag habe ich
herausgehoben, das beim üblichen Vorgehen (PERIOD constraint setzen, I-O
Pfade constrainen, sonst nix), die Pfade die an den asynchronen
Eingängen enden NICHT analysiert werden. Das bedeutet sehr
unterschiedliche und unter Umständen sehr lange Laufzeiten. Um eine
maximale Laufzeit in dem Netzwerk zu garantieren, muß ein anderes
constraint gesetzt werden. (die constraint PERIOD und FROM To beziehen
sich hier auf die Xilinx-Tools).
MfG,
Matthias G. schrieb:> Nun nochmal zur Theorie: Macht es Sinn ein Reset asynchron zu verwenden?> Da lautet die Antwort ganz klar Ja!. Die Register bieten nun mal die> Resourcen an, wärend man bei einer synchronen Verwendung weitere> Resourcen verschwendet.
Sorry, das stimmt so allgemein gesprochen nicht. Bei Xilinx kann man die
FF entweder mit synchronen (SET/RESET) oder asynchronen (PRESET/CLEAR)
Eingängen konfigurieren. (asynchron SET/RESET ist hier keine zusätzliche
Resource sondern ein entweder .. oder) Werden nun wie bei einem Reset
üblich, alle oder die meisten die FF asynchron initialisiert, muss man
für setzen/löschen im "Normalbetrieb" Logik vor den Dateneingang D und
das enable CE synthetisieren. Das führt insbesonders bei FSM zu
zusätzlichen Logikleveln (mehr resourcenverbrauch) und verlangsamt das
Design.
Hier (Xilinx) ist der asynchrone Reset eine Verschwendung an ressorucen)
Unklar bleibt die Begründung warum ein Design mit (ausschliesslich)
synchronen Reset/Set mehr Resourcen benötigen soll als eines mit
asynchronen. Bitte erläutern.
MfG,
Fpga Kuechle schrieb:> Unklar bleibt die Begründung warum ein Design mit (ausschliesslich)> synchronen Reset/Set mehr Resourcen benötigen soll als eines mit> asynchronen. Bitte erläutern.
Ich habe dazu mal ein einfaches Beispieldesign geschrieben. Das
Einsynchronisieren des Resets habe ich mal großzügig weg gelassen.
1
libraryieee;
2
useieee.std_logic_1164.all;
3
4
entityasync_sync_resetisport
5
(
6
clk:instd_logic;
7
rst:instd_logic;
8
data:instd_logic_vector(3downto0);
9
q_async:outstd_logic;
10
q_sync:outstd_logic
11
);
12
endasync_sync_reset;
13
14
architecturebehaviorofasync_sync_resetis
15
16
begin
17
18
async_proc:process(rst,clk)
19
begin
20
ifrst='1'then
21
q_async<='0';
22
elsifrising_edge(clk)then
23
q_async<=data(0)anddata(1)anddata(2)anddata(3);
24
endif;
25
endprocess;
26
27
sync_proc:process(clk)
28
begin
29
ifrising_edge(clk)then
30
ifrst='1'then
31
q_sync<='0';
32
else
33
q_sync<=data(0)anddata(1)anddata(2)anddata(3);
34
endif;
35
endif;
36
endprocess;
37
38
endbehavior;
Dabei habe ich das ganze im Cyclone 3 implementiert. Der hat (vielleicht
im Gegensatz zu Xilinx) keinen synchronen Reseteingang am FF. Das
Resultat des Technology Map Viewers ist im Anhang zu sehen. Dabei wird
schnell deutlich, dass die Variante mit dem asynchronen Reset nur ein
LUT4 benötigt und das mit dem synchronen Reset zwei. Daher Ressourcen
verschwendet und Geschwindigkeit verschenkt. Bei anderen Technologien
kann das aber auch anders sein.
Ich habe das ganze auch einmal testweise nur mit dem asynchronen Teil
und einmal mit dem synchronen Teil compiliert. Einmal wird 1 "Total
logic elements" benötigt und einmal 2.
MfG
> Ich habe dazu mal ein einfaches Beispieldesign geschrieben.> Dabei habe ich das ganze im Cyclone 3 implementiert. Der hat> (vielleicht im Gegensatz zu Xilinx) keinen synchronen Reseteingang am FF.
Ich habe das mal für Xilinx synthetisieren lassen. Und das Ergebnis: es
wird einfach nur die Betriebsart des FFs umgeschaltet (siehe
Screenshot).
Offenbar sind die Altera-FPGAs eher auf die traditionelle Schreibweise
(wie sie in jedem Buch zu finden ist) mit asynchronem Reset ausgelegt.
Über was man sich auf jeden Fall im Klaren sein sollte:
Nicht das Eintreten in den Resetzustand ist kritisch. Spannend wird es,
wenn der Resetzustand verlassen werden soll. Von solchen "trivialen"
Dingen wie Spikes auf dem Reseteingang und daraus resultierend nur halb
zurückgesetzten FPGAs mal abgesehen... :-o