Grüßt Euch zusammen,
nachdem ich immer wieder erneut auf dieses Thema zurückkomme und bisher
immer noch keine 100%-ige Antwort trotz lesen von Whitepapern +
sonstigen Beiträgen gefunden habe, würde ich gerne folgende Frage in die
Runde stellen.
Es geht mir dabei vorrangig um die Spartan 3 + 6 sowie CoolRunner Xilinx
Sparte in Verbindung mit dem kostenlosen Xilinx Webpack.
Selber habe ich des Öfteren eine Applikation welche keinen externen
Reset benötigt. Sowohl mein "Top-Prozess" als auch die Unter-Instanzen
anderer Komponenten haben somit weder einen asynchronen noch synchrones
Reset-Signal. Bisher dachte ich, dass wenn ich alle "internen Signalen"
welche weitere Teile des Gesamtdesigns treiben mit einem Wert
initialisiere, diese auch nach dem Startup den zugewiesenen Zustand
annehmen (Also alle gleichzeitig, synchron mit dem gleichen CLK nach dem
Startup). Somit entfällt der einmal nötige Reset doch meines Erachtens
vollkommen?
Diese Deklaration und gleichzeitige Initialisierung betrifft dabei
sowohl einfache Datentypen wie auch eigens Definierte (z.B. für
State-Maschinen-Zustände). Jetzt die Frage, liegt ich hier komplett
falsch oder gibt es vielleicht noch einen Haken, welchen ich nicht
bedacht habe der es dennoch nötig macht ein paar FF's im CLB mit dem
Reset zu versehen?
P.S. Ich habe hier keinesfalls vor eine große Runde einzuläuten, um über
die verschiedenen Reset-Möglichkeiten als auch
Einsynchronisierungsmöglichkeiten in FPGA’s zu diskutieren. Das sollte
soweit klar sein.
Danke für Eure Hilfe im Voraus!
Grüße
Stefan
du kannst problemlos ohne einen Reset auskommen. Ueberleg mal, wie so
ein FPGA 'hochkommt': Es wird ein HW-Reset durchgefuehrt, dann wird ein
Bitstream von einem Konfigurationsport (meistens der Flashbaustein, kann
aber auch z.B. ein Microcontroller sein) oder via JTAG geladen. Dieser
Bitstream enthaelt den Wert jedes Flipflops des Bausteins (wird alles
seriell via Shift-Kette durchgeschoben). Daraus folgt: Dein FPGA/CPLD
steht nach der Konfiguration richtig da.
Wenn du in deiner VHDL oder Verilog Beschreibung nun einem FF einen Wert
ungleich 0 zuweist, dann bauen die Tools das in den Bitstream ein. Also
steht dieser Wert dann nach der Konfiguration auch in deinem FF. Gibst
du nichts an, dann wird halt eine Null angenommen und reingeschrieben...
Etwas anderes ist dann der Simulator. Der weiss nix von einem Bitstream
und generiert dir dann halt 'X' und 'U' fuer FFs die du nicht in deiner
Beschreibung spezifizierst hast.
Eine spezielle Sache bzgl. Reset gibt es: Wenn du mit on-chip PLLs
arbeitest, und diese PLL jemals den Lock verliert, dann kannst du mit
einem Reset (der eben den PLL-Lock mit enthaelt), deinen Design wieder
sauber resetten. Aber eigentlich brauchst du sonst keinen Reset.
Spitze!
Dann kann ich beruhigt weiter ausschließlich wie gehabt mit der
Initialisierung von internen Signalen in meiner 'architecture' arbeiten.
Vielen lieben Dank auch für den Hinweis bzgl. der PLL-Recovery.
Super Forum!
DANKE,
Gruß Stefan
Stefan schrieb:> Dann kann ich beruhigt weiter ausschließlich wie gehabt mit der> Initialisierung von internen Signalen in meiner 'architecture' arbeiten.
Was aber nur Sinn macht, wenn das tatsächlich speichernde Signale
(=Flipflops) sind. Denn eine simple Verbindung (=Routing) kann natürlich
nur in der Simulation mit einem Wert initialisiert werden... :-o
Stefan schrieb:> P.S. Ich habe hier keinesfalls vor eine große Runde einzuläuten, um über> die verschiedenen Reset-Möglichkeiten als auch> Einsynchronisierungsmöglichkeiten in FPGA’s zu diskutieren. Das sollte> soweit klar sein.
Die Runde wurde schon mal eingeläutet im uralten
Beitrag "Xilinx und die Resets"
Was bzgl. Initialisierung und Reset geht und was nicht, steht im
entsprechenden Handbuch zum Synthesizer, bei Xilinx der XST Users
Guide...
> FPGA’s
Das hier unnötigerweise verwendete Satzzeichen nennt man volkstümlich
"Deppenapostroph".
Siehe: http://de.wikipedia.org/wiki/Apostrophitis
Und: http://www.stupidedia.org/stupi/Deppenapostroph
berndl schrieb:> Gibst> du nichts an, dann wird halt eine Null angenommen und reingeschrieben...
hu, die Aussage ist gewagt und hängt von der Synthese ab.
Wenn kein Init-Wert angegeben wird, gilt 'U' für das speichernde Element
(FF, SRL, BRAM, etc). Die Synthese verfolgt das Signal und entscheidet
sich später für '1' oder '0', je nachdem welcher Startwert sinnvoller
ist z. B. für Optimierungen oder gar möglich ist (Spartan: Init-Wert =
Reset-Wert).
Beispiel:
a) nicht initialisiertes FF (also 'U')
b) in einem getaktetem Process wird dem FF konstant '1' zugewiesen
c) die Synthese nimmt als Init-Wert '1' und optimiert das FF weg.
Thema Startwerte:
es stimmt, dass zu Beginn alle speichernde Elemente einen definierten
Wert haben (auch BRAMs, DSPs, SRLs), der bei jedem Start gleich ist
(anders als bei ASICs).
JEDOCH ist das Freigabesignal (Global Write Enable) nach der
Konfiguration des FPGAs asynchron. Dieses Signal wird durch den
internen CCLK bestimmt (Configuration Sequence, Step 8). Dieser CCLK hat
keinen Bezug zu dem eigentlichen Systemtakt (oder gar Takte), so dass es
passieren kann, dass einige FF das GWE einen Takt eher erkennen als
andere FFs. Das ist z. B. ungünstig bei Zählern, die sofort los laufen.
Ohne genau Prüfung des Verhaltens in den ersten Takte wäre es also
sträflich einfach den Reset durch einen Init-Wert zu ersetzen.
gruß
Daniel M. schrieb:> berndl schrieb:>> Gibst>> du nichts an, dann wird halt eine Null angenommen und reingeschrieben...>> hu, die Aussage ist gewagt und hängt von der Synthese ab.
Die Aussage ist nicht gewagt. Hier mal der Auszug aus dem XST User Guide
(UG687, Chapter 3, page 60). Dort sind die Unterschiede zwischen
IEEE-Standard und XST aufgeführt.
Bei Altera, Lattice und Microsemi wird es ähnliche Definitionen geben.
Duke
Hallo,
meine Erfahrungen mit den Signalinitialisierungen bei Xilinx FPGAs sind
durch wachsen. Ein Design mit Signalinitialisierungen läuft immer
richtig an, wenn der FPGA gerade eingeschaltet wurde, egal ob per JTAG
geladen wurde oder aus einem PROM. Es gibt gelegentlich Probleme, wenn
man ein Bitfile in einen in Betrieb-befindlichen FPGA lädt.
Tom
Duke Scarring schrieb:> Hier mal der Auszug aus dem XST User Guide> (UG687, Chapter 3, page 60).
Da scheint wohl mal wieder die viel gelobte Doku-Qualität von Xilinx
hervor zu kommem ;)
einfach mal ausprobieren:
1
entitytopis
2
Port(i_clk:inSTD_LOGIC;
3
o_data:outSTD_LOGIC);
4
endtop;
5
6
architectureBehavioraloftopis
7
signals_ff:std_logic;
8
begin
9
10
11
process(i_clk)
12
begin
13
ifrising_edge(i_clk)then
14
s_ff<='1';
15
endif;
16
endprocess;
17
18
o_data<=s_ff;
19
20
endBehavioral;
Resultat bei mir (sogar für einen Virtex6): kein FF vorhanden, '1' wird
hard-codiert.
schreibt man
1
signals_ff:std_logic:='0';
was gemäß der Doku das gleiche ist, erhält man etwas völlig anderes. FF
ist vorhanden und XST schlägt einen anderen Init-Wert vor, um besser
Optimieren zu können.
Gruß
In der Initialisierung versuche ich generell alle Werte vorzugeben, egal
ob '0' oder '1'. Wenn das Synthesetool mir dann was modifiziert bzw.
rausschmeißt sollte es zumindest eine Meldung geben, der ich
anschließend nachgehen kann.
In der ISE Design View nach Auswahl meines zugehörigen Design Files habe
ich die Möglichkeit gefunden für die unter "Generate Programming File" >
"Process Properties" in den "Startup Options" GWE_cycles Property einen
Wert zu vergeben. Default ist 6. Ich denke das sollten die sechste
einstellbare Phase sein in welcher der interne GWE 'enabled' wird,
richtig? Muss ich jetzt davon ausgehen, dass das GWE Signal während
dieser Phase immer noch "asynchron" kommt (irgendwann während der
8-phasen sequenziellen Statemaschine), oder soll das hiermit unterbunden
werden, quasi anstelle einer art FF-Einsynchronisierung erstmal warten
bis der Takt sicher überall ansteht?
Siehe hierzu auch die Doku im Netz: "... that asserts the internal write
enable to flip-flops, LUT RAMs, and shift registers..." unter diesem
Link
[[http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/pp_db_startup_options.htm]]
In der Spartan 6 Device Library als auch im Configuration Guide
existiert ein Startup Block "STARTUP_SPARTAN6. Sofern ich einen
"globalen" Reset in meinem Design verwenden müsste, wäre es doch
angebracht hier das "EOS" Signal abzugreifen, richtig?
Zu guter letzt habe ich noch eine kleine Fußnote im UG380 von Xilinx auf
Seite 83 gefunden:
http://www.xilinx.com/support/documentation/user_guides/ug380.pdf
(3) "GWE is asserted synchronously to the configuration clock (CCLK) and
has a significant skew across the part. Therefore, sequential
elements might not be released synchronously to the system clock and
timing violations can occur during startup. It is
recommended to reset the design after startup and/or apply some other
synchronization technique"
Das bestätigt auch die super Info von Daniel M. für mich:
==> Zumindest ist für mich klar, dass eine Kontrolle des Verhaltens nach
den ersten Takten angebracht ist!
DANKE!
Gruß Stefan
Ich denke, wenn man das EOS bei den neueren Chips mit dem verwendeten
System-Takt einsynchronisiert und dann als synchrones Reset verwendet,
ist man auf der sicheren Seite. Man kann das Startup ja auch verzögern,
bis alle verwendeten DCMs fertig sind, dann hat man auf jeden Fall einen
Takt.
Ob die eigentlich mittlerweile das Signal mal im Simulationsmodell drin
haben? Bei mir lieferte das in der Simu unter 14.3 zumindest immer nur
ein 'U', weil das File quasi leer ist.
Christian R. schrieb:> Ich denke, wenn man das EOS bei den neueren Chips mit dem verwendeten> System-Takt einsynchronisiert und dann als synchrones Reset verwendet,> ist man auf der sicheren Seite.
Dann hat man wieder einen Startup-Reset :(
Eine aus meiner Sicht andere, elegante Möglichkeit wäre, den Systemtakt
erst nach dem GWE zuzuschalten, also z.B. einen BUFGCE nehmen. Dessen
CE-Signal wird dann z.B. aus dem EOS-Signal gewonnen (und/oder aus dem
Locked-Signal der DCM, wenn vorhanden).
Na wenn man schon den DCM nimmt, kann man das aber dann doch sein
lassen, oder? Denn der DCM "lockt" auf jeden Fall erst nach dem EOS,
also wenn alle FF bereits ihren Wert bekommen haben. Man kann so
höchstens die paar Takt-Zyklen am Ausgang des DCM vor dem Lock
verhindern. Da kommt immer eine kleine Weile unregelmäßiger Mist raus.
Christian R. schrieb:> Da kommt immer eine kleine Weile unregelmäßiger Mist raus.
Richtig. Und der kann einem im Ernstfall die schön initialisieren FFs
durcheinander bringen. Wirklich auf der sicheren Seite ist man da nur,
wenn man entweder nen Reset verwendet, der die FFs solange noch
festhält, oder die Clocks erst nach dem Lock sauber enabled.
