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ß
Angehängte Dateien:
-
VHDL_Initial_Values.png
34 KB
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 | entity top is |
2 | Port ( i_clk : in STD_LOGIC; |
3 | o_data : out STD_LOGIC); |
4 | end top; |
5 | |
6 | architecture Behavioral of top is |
7 | signal s_ff : std_logic; |
8 | begin
|
9 | |
10 | |
11 | process(i_clk) |
12 | begin
|
13 | if rising_edge(i_clk) then |
14 | s_ff <= '1'; |
15 | end if; |
16 | end process; |
17 | |
18 | o_data <= s_ff; |
19 | |
20 | end Behavioral; |
Resultat bei mir (sogar für einen Virtex6): kein FF vorhanden, '1' wird hard-codiert. schreibt man
1 | signal s_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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.