.. _w03-sync: ============================== WykĹad 3: UkĹady synchroniczne ============================== Data: 17.10.2018 .. toctree:: .. contents:: UkĹady kombinacyjne i sekwencyjne ================================= UkĹad kombinacyjny to acykliczna sieÄ bramek logicznych. W ukĹadzie kombinacyjnym wartoĹÄ sygnaĹĂłw wyjĹciowych zaleĹźy tylko od wartoĹci sygnaĹĂłw wejĹciowych (pomijajÄ c opóźnienia). UkĹad sekwencyjny to sieÄ bramek logicznych zawierajÄ ca cykle. Stany logiczne na tych cyklach stanowiÄ pamiÄÄ wewnÄtrznÄ ukĹadu, a Ĺźeby przewidzieÄ wartoĹÄ sygnaĹĂłw wyjĹciowych musimy znaÄ ich wartoĹÄ (jak rĂłwnieĹź wartoĹÄi sygnaĹĂłw wejĹciowych). Wyróşniamy dwa typy ukĹadĂłw sekwencyjnych: - ukĹady synchroniczne: zmiana stanu ukĹadu nastÄpuje tylko na skutek zmian jednego wyróşnionego sygnaĹu wejĹciowego, zwanego wejĹciem zegarowym - ukĹady asynchroniczne: wszystkie inne Zatrzaski ========= Najprostszym ukĹadem sekwencyjnym (ale nie synchronicznym) sÄ zatrzaski (latch), czyli ukĹady z 1-bitowÄ pamiÄciÄ i sygnaĹem zapisu. .. image:: dl.svg WyjĹcie Q zawsze pokazuje stan zatrzasku. Gdy wejĹcie E ma stan 1, stan zatrzasku jest ustawiany na wejĹcie D, a gdy ma stan 0, stan zatrzasku siÄ nie zmienia. Aby opisaÄ w Verilogu logikÄ z zatrzaskami, wystarczy napisaÄ proces podobny do logiki kombinacyjnej, ale nie zawsze ustawiajÄ cy swĂłj rejestr wyjĹciowy:: reg q; wire d, e; // RĂłwnowaĹźne pojedynczemu zatrzaskowi typu D. always @(d, e) begin if (e) q <= d; end PiszÄ c logikÄ kombinacyjnÄ za pomocÄ procesu, naleĹźy uwaĹźaÄ, by zawsze ustawiaÄ stan wyjĹÄ -- w przeciwnym wypadku dostaniemy niechciany zatrzask. W jÄzyku SystemVerilog ten problem zostaĹ rozwiÄ zany przez wprowadzenie sĹĂłw kluczowych ``always_comb`` (jak ``always``, ale powoduje bĹÄ d syntezy, gdy powstaĹy ukĹad nie bÄdzie kombinacyjny) oraz ``always_latch`` (powoduje bĹÄ d syntezy, gdy powstaĹy ukĹad nie jest zatrzaskiem). W zaleĹźnoĹci od technologii, zatrzask typu D moĹźe mieÄ wiÄcej dostÄpnych wejĹÄ. Po szczegĂłĹy odsyĹam do dokumentacji konkretnego ukĹadu (bÄ dĹş biblioteki komĂłrek w przypadku ASICĂłw). Ten dostÄpny w Spartanie 3E w peĹnej konfiguracji (LDCPE) zachowuje siÄ nastÄpujÄ co:: wire clr; // Asynchronous clear/reset. wire pre; // Asynchronous set/preset. wire d; // Data input. wire g; // Gate input (rĂłwnowaĹźne wejĹciu e powyĹźej). wire ge; // Gate enable input. reg q = <...>; // Data output (moĹźemy wybraÄ wartoĹÄ poczÄ tkowÄ ). always @(clr, pre, d, g, ge) begin if (clr) q <= 0; else if (pre) q <= 1; else if (g && ge) q <= d; end MoĹźliwoĹÄ ustawienia wartoĹci poczÄ tkowej zatrzaskĂłw i przerzutnikĂłw jest cechÄ charakterystycznÄ ukĹadĂłw FPGA i niektĂłrych ukĹadĂłw CPLD -- jeĹli projektujemy ASIC, stan poczÄ tkowy jest nieustalony i musimy samemu zapewniÄ odpowiedni ukĹad resetujÄ cy stan przy wĹÄ czeniu zasilania. W logice, zatrzaskĂłw uĹźywa siÄ rzadko -- szczegĂłlnie w przypadku FPGA, gdzie zatrzaski i przerzutniki majÄ ten sam koszt. ZatrzaskĂłw uĹźywa siÄ natomiast jako pamiÄÄ -- jeĹźeli uĹźywamy zewnÄtrznej asynchronicznej pamiÄci SRAM, jest to po prostu wielka tablica zatrzaskĂłw i steruje siÄ niÄ doĹÄ podobnie. Przerzutniki ============ Najprostszym ukĹadem synchronicznym (i podstawowym elementem, z ktĂłrego skĹadajÄ siÄ wszystkie ukĹady synchroniczne) jest przerzutnik: .. image:: dff.svg Przerzutnik dziaĹa podobnie do zatrzasku, ale kopiuje stan wejĹcia D do wyjĹcia Q tylko w momencie zmiany wejĹcia C z 0 na 1 -- gdy stan wejĹcia bÄdzie juĹź ustabilizowany na 1, przerzutnik (w przeciwieĹstwie do zatrzasku) nie bÄdzie reagowaĹ na dalsze zmiany wejĹcia D. W Verilogu moĹźemy go opisaÄ nastÄpujÄ co:: reg q; wire d, c; always @(posedge c) begin q <= d; end Nigdy nie naleĹźy prĂłbowaÄ samemu skĹadaÄ przerzutnika z bramek logicznych w ukĹadzie FPGA (a w przypadku ASICa naleĹźy byÄ bardzo, bardzo ostroĹźnym) -- jego poprawne dziaĹanie jest zaleĹźne od odpowiedniego uĹoĹźenia czasĂłw opóźnieĹ propagacji na bramkach. Przerzutniki, podobnie do zatrzaskĂłw, miewajÄ wiÄcej wejĹÄ. W ukĹadzie Spartan 3E mamy dostÄpne dwa rodzaje przerzutnikĂłw: z synchronicznymi i asynchronicznymi wejĹciami resetu. Ten z synchronicznym resetem (FDRSE) dziaĹa nastÄpujÄ co:: wire r; // Synchronous reset input. wire s; // Synchronous set input. wire ce; // Clock enable input. wire c; // Clock input. wire d; // Data input. reg q = <...>; always @(posedge clk) begin if (r) q <= 0; else if (s) q <= 1; else if (ce) q <= d; end Nie ma on wiÄkszych moĹźliwoĹci od postawowego przerzutnika (poza wartoĹciÄ poczÄ tkowÄ ) -- dodatkowe wejĹcia daĹoby siÄ emulowaÄ logikÄ kombinacyjnÄ . Przerzutnik z asynchronicznym resetem (FDCPE) jest ciekawszy:: wire clr; // Asynchronous clear input. wire pre; // Asynchronous set input. wire ce; // Clock enable input. wire c; // Clock input. wire d; // Data input. reg q = <...>; always @(posedge clk, posedge clr, posedge pre) begin if (clr) q <= 0; else if (pre) q <= 1; else if (ce) q <= d; end DziaĹa on nastÄpujÄ co: - zawsze, gdy ustawiony jest asynchroniczny reset, stan jest ustawiany na 0 (pozostaĹe wejĹcia, w tym wejĹcie zegarowe, sÄ ignorowane) - zawsze, gdy ustawiony jest asynchroniczny preset, ale nie reset, stan jest ustawiany na 1 - jeĹli Ĺźaden z asynchronicznych sygnaĹĂłw nie jest ustawiony, ustawiony jest sygnaĹ clock enable, i nastÄpuje zbocze rosnÄ ce na wejĹciu zegarowym, kopiuje stan wejĹcia d do stanu wewnÄtrznego - w pozostaĹych momentach, utrzymuje poprzedniÄ wartoĹÄ stanu .. warning:: Asynchronicznego resetu nie da siÄ emulowaÄ innÄ funkcjonalnoĹciÄ . Przed uĹźyciem bardziej skomplikowanych kombinacji, naleĹźy skonsultowaÄ siÄ z dokumentacjÄ uĹźywanego ukĹadu FPGA. Czasem moĹźna spotkaÄ nastÄpujÄ ce ograniczenia: 1. Przerzutnik moĹźe mieÄ asynchroniczny reset albo asynchroniczny preset, ale nie oba naraz. 2. Asynchroniczne wejĹcie musi ustawiaÄ przerzutnik na stan poczÄ tkowy -- np. jeĹli uĹźywamy asynchronicznego presetu, stanem poczÄ tkowym musi byÄ 1. UkĹady synchroniczne, czasy setup i hold ======================================== UkĹad synchroniczny skĹada siÄ z pewnej liczby przerzutnikĂłw uĹźywajÄ cych wspĂłlnego sygnaĹu zegarowego i ukĹadĂłw kombinacyjnych wyznaczajÄ ych nowy stan ukĹadu. DziaĹa on nastÄpujÄ co: 1. Przed rosnÄ cym zboczem zegarowym stan ukĹadu i jego wejĹÄ jest stabilny. 2. Przychodzi rosnÄ ce zbocze zegarowe. 3. KaĹźdy przerzutnik w ukĹadzie jednoczeĹnie sampluje stan wejĹcia D i kopiuje je na wyjĹcie Q. 4. CzÄĹÄ kombinacyjna ukĹadu przez pewien czas liczy nowy stan. 5. UkĹad siÄ stabilizuje -- wyjĹcia Q przerzutnikĂłw wciÄ Ĺź trzymajÄ stary stan ukĹadu, a na wejĹciach D jest juĹź gotowy nowy stan ukĹadu. 6. Nadchodzi kolejne rosnÄ ce zbocze zegarowe. Moment nadejĹcia opadajÄ cego zbocza zegarowego nie jest zbyt istotny -- liczy siÄ tylko rosnÄ ce zbocze. Aby ukĹad dziaĹaĹ poprawnie, naleĹźy zapewniÄ, Ĺźe wszystko stanie siÄ w odpowiednim czasie. KaĹźdy przerzutnik (lub inny gotowy ukĹad synchroniczny) ma nastÄpujÄ ce waĹźne parametry, ktĂłrych wartoĹci moĹźna znaleĹşÄ w dokumentacji: - Setup time (T_xS): wymagany przez przerzutnik czas, przez ktĂłry stan wejĹcia D musi byÄ stabilny przed rosnÄ cym zboczem zegarowym, bo jego stan zostaĹ poprawnie przeczytany. - Hold time (T_xH): wymagany przez przerzutnik czas, przez ktĂłry stan wejĹcia D musi byÄ stabilny po rosnÄ cym zboczu zegarowym, bo jego stan zostaĹ poprawnie przeczytany. - Clock-to-Output time (T_CKO): czas od rosnÄ cego zbocza zegarowego do pojawienia siÄ nowego stanu na wyjĹciu. W zaleĹźnoĹci od konstrukcji, przerzutnik moĹźe mieÄ zerowy (bÄ dĹş nawet ujemny) czas setup albo hold, ale nie oba naraz. PoniewaĹź czas hold jest problematyczny (nie chcemy, by inny przerzutnik w ukĹadzie mĂłgĹ popsuÄ ukĹad liczÄ c nowy stan zbyt szybko), zazwyczaj dÄ Ĺźy siÄ do minimalizacji bÄ dĹş wyeliminowania go. Co wiÄcej, kaĹźda sensowna technologia ma ``T_CKO > T_xH``, wiÄc nie musimy siÄ przejmowaÄ czasem hold dopĂłki nie mamy bardzo nierĂłwnomiernych opóźnieĹ w transmisji sygnaĹu zegarowego i nie mieszamy technologii (np. przez podĹÄ czenie innego ukĹadu do FPGA). PozostaĹe czasy determinujÄ maksymalnÄ moĹźliwÄ czÄstotliwoĹÄ sygnaĹu zegarowego, przy ktĂłrej ukĹad synchroniczny dziaĹa poprawnie -- jest to ``1 / (T_CKO + T_xS + najwiÄksze opóźnienie na logice kombinacyjnej i przesyĹaniu danych miÄdzy wyjĹciem Q a wejĹciem D)``. AnalizÄ czasowÄ wykonujÄ za nas narzÄdzia -- jeĹli nasz zegar mieĹci siÄ w podanej przez narzÄdzia maksymalnej czÄstotliwoĹci naszego ukĹadu (i speĹnione sÄ ograniczenia czasowe na synchroniczne sygnaĹy wejĹcia/wyjĹcia), wszystko jest w porzÄ dku. W przeciwnym wypadku, musimy zwolniÄ zegar, bÄ dĹş wziÄ Ä siÄ za przeprojektowanie ukĹadu. MetastabilnoĹÄ ============== Niestety, w prawdziwym Ĺwiecie nie istniejÄ ukĹady w peĹni cyfrowe -- kaĹźdy ukĹad jest tak naprawdÄ ukĹadem analogowym i moĹźna wprowadziÄ go w stany poĹrednie (gdzieĹ pomiÄdzy 0 i 1). ZapisujÄ c taki stan (szczegĂłlnie stan bliski 0.5) do zatrzasku lub przerzutnika, moĹźemy go wprowadziÄ w stan rĂłwnowagi niestabilnej -- dowolne zaburzenie spowoduje, Ĺźe spadnie w stan 0 lub stan 1, lecz moĹźe to zajÄ Ä duĹźo wiÄcej czasu niĹź normalny parametr T_CKO. Takie zjawisko nazywa siÄ metastabilnoĹciÄ . MetastabilnoĹÄ jest zjawiskiem niebezpiecznym, gdyĹź dany stan moĹźe byÄ róşnie zinterpretowany przez podĹÄ czone wejĹcia róşnych bramek logicznych, powodujÄ c w naszym ukĹadzie synchronicznym przejĹcia niespĂłjne zarĂłwno ze stanem logicznym 0 jak i stanem logicznym 1. ByĹoby bardzo niedobrze, gdyby np. róşne czÄĹci skĹadowe procesora nie zgadzaĹy siÄ na temat tego, czy w danym cyklu procesor rozpoczyna obsĹugÄ przerwania. MetastabilnoĹÄ moĹźe powstaÄ na dwa sposoby: 1. Dajemy ukĹadowi synchronicznemu stan poĹredni jako wejĹcie (naleĹźy tego nie robiÄ). 2. Nie przestrzegamy czasu setup bÄ dĹş czasu hold. MetastabilnoĹÄ jest zjawiskiem nieuniknionym, gdy dany ukĹad synchroniczny ma wejĹcia asynchroniczne (a praktycznie kaĹźdy ma) -- prÄdzej czy później, wejĹcie zmieni siÄ odpowiednio blisko zbocza sygnaĹu zegarowego, powodujÄ c naruszenie czasu setup bÄ dĹş hold. Musimy wiÄc sobie jakoĹ z tym poradziÄ. Z drugiej strony, stany metastabilne trwajÄ bardzo krĂłtko -- praktycznie zawsze rozwiÄ zujÄ siÄ w ciÄ gu jednego, ewentualnie dwĂłch cykli zegara. Z tego powodu, na sygnaĹach asynchronicznych uĹźywa siÄ tzw. synchronizatorĂłw -- ĹaĹcuchĂłw dwĂłch lub trzech przerzutnikĂłw:: wire async_in; reg tmp1, tmp2; reg out; always @(posedge clk) tmp1 <= async_in; tmp2 <= tmp1; out <= tmp2; end JeĹli przerzutnik ``tmp1 <= async_in`` zĹapie wejĹcie w momencie zmiany stanu i wejdzie w stan metastabilny, z bardzo duĹźym prawdopodobieĹstwem stan ten rozpadnie siÄ do stanu 0 bÄ dĹş 1 zanim jego wyjĹcie zostanie uĹźyte przez kolejny przerzutnik (ma na to caĹy cykl zegara). JeĹli nawet to siÄ nie uda, na przerzutniku ``tmp2 <= tmp1`` mamy kolejnÄ szansÄ. Na wyjĹciu ``out`` z bardzo duĹźym prawdopodobieĹstwem dostajemy juĹź czyste wyjĹcie bez metastabilnoĹci. Zapobieganie metastabilnoĹci ma charakter probabilistyczny, a odpornoĹÄ ukĹadu na metastabilnoĹÄ podaje siÄ jako MTBF (mean time between failures) -- szacowany Ĺredni czas bezawaryjnej pracy. JeĹli osiÄ gniemy MTBF rzÄdu setek tysiÄcy lat, moĹźemy go uwaĹźaÄ za odporny na metastabilnoĹÄ. MTBF zaleĹźy od: - CzÄstotliwoĹci zegara. WiÄksza czÄstotliwoĹÄ to: - wiÄcej szans, Ĺźe coĹ pĂłjdzie nie tak - krĂłtszy okres czasu w synchronizatorze na rozpad stanu metastabilnego - Technologii wykonania (nowsze ukĹady FPGA majÄ dedykowane bloki synchronizacyjne z przerzutnikami wykonanymi w specjalnej technologii zoptymalizowanej na zapobieganie metastabilnoĹci) - Liczby przerzutnikĂłw w synchronizatorze (MTBF roĹnie wykĹadniczo z liczbÄ przerzutnikĂłw). Dwa przerzutniki to absolutne minimum, dla bezpieczeĹstwa zaleca siÄ trzy. SynchronizatorĂłw naleĹźy uĹźywaÄ *zawsze* na asynchronicznych wejĹciach. W przypadku wejĹÄ z ukĹadĂłw synchronicznych pracujÄ cych z innÄ czÄstotliwoĹciÄ zegara, naleĹźy zapewniÄ jeszcze jeden przerzutnik na poczÄ tku, uĹźywajÄ cy sygnaĹu zegarowego ukĹadu ĹşrĂłdĹowego -- zapobiega to wydostawaniu siÄ stanĂłw poĹrednich z logiki kombinacyjnej. Jedyny przypadek, w ktĂłrym wolno pominÄ Ä synchronizator na wejĹciu to wejĹcie z innego ukĹadu synchronicznego pracujÄ cego na ĹciĹle zwiÄ zanym sygnale zegarowym (np. naszym sygnale zegarowym podzielonym bÄ dĹş pomnoĹźonym przez staĹÄ przez ukĹad generowania zegara) -- w tym wypadku naleĹźy dobrze opisaÄ wzajemnÄ relacjÄ tych zegarĂłw, by narzÄdzia analizy czasowej mogĹy sprawdziÄ zachowanie czasĂłw setup i hold. Zjawisko metastabilnoĹci wystÄpuje zawsze, gdy dwie konfliktujÄ ce zmiany stanĂłw mogÄ siÄ zdarzyÄ blisko siebie -- w szczegĂłlnoĹci moĹźe teĹź dotyczyÄ asynchronicznych sygnaĹĂłw reset, bÄ dĹş wejĹcia do zatrzasku (gdy zmienia siÄ jednoczeĹnie ze zmianÄ 1 na 0 na wejĹciu E). O stanie poczÄ tkowym i uruchamianiu FPGA ======================================== W ukĹadach FPGA mamy moĹźliwoĹÄ ustawienia stanĂłw poczÄ tkowych przerzutnikĂłw, wiÄc sygnaĹy reset do kaĹźdego przerzutnika nie sÄ ĹciĹle potrzebne (w przeciwieĹstwie do ASICĂłw). JeĹli uĹźywamy sygnaĹĂłw reset (by mĂłc przywrĂłciÄ czÄĹÄ ukĹadu do stanu poczÄ tkowego), zazwyczaj Ĺatwiej jest uĹźyÄ resetĂłw synchronicznych. Polecam tutaj lekturÄ: https://www.xilinx.com/support/documentation/white_papers/wp272.pdf Natomiast naleĹźy zauwaĹźyÄ, Ĺźe jeĹli nasz ukĹad ma zaczÄ Ä pracÄ od razu po starcie (jak np. mikroprocesor, ktĂłry natychmiast po wĹÄ czeniu zaczyna wykonywaÄ kod z pamiÄci), samo zjawisko startu FPGA moĹźe prowadziÄ do metastabilnoĹci jeĹli stanie siÄ to blisko stanu zbocza zegarowego. RozwiÄ zania tego problemu sÄ dwa: 1. ZaprojektowaÄ stan poczÄ tkowy ukĹadu tak, Ĺźeby byĹ stabilny (nastÄpny stan == stan poczÄ tkowy), z wyjÄ tkiem jednego przerzutnika, stanowiÄ cego poczÄ tek synchronizatora, ktĂłry spowoduje rozpoczÄcie pracy ukĹadu ("iskry Ĺźycia"):: reg start0 = 0; reg start1 = 0; reg running = 0; always @(posedge clk) begin start0 <= 1; start1 <= start0; running <= start1; end 2. ZsynchronizowaÄ start ukĹadu FPGA do wĹasnego zegara. Procedura startowa FPGA ----------------------- W przypadku ukĹadu Spartan 3E, procedura uruchamiania wyglÄ da nastÄpujÄ co: 1. UkĹad power-on reset monitoruje stan linii zasilajÄ cych i utrzymuje caĹy ukĹad w stanie poczÄ tkowym dopĂłki nie osiÄ gnÄ one poziomu napiÄcia odpowiedniego do rozpoczÄcia pracy. 2. UkĹad zaczyna generowaÄ zegar za pomocÄ wewnÄtrznego (bardzo niedokĹadnego) oscylatora. 3. UkĹad czyĹci pamiÄÄ konfiguracyjnÄ . 4. UkĹad sprawdza stan linii sterujÄ cych wybierajÄ cych ĹşrĂłdĹo konfiguracji (na pĹytce Basys2 moĹźemy wybraÄ dwie opcje za pomocÄ zworki). 5. W zaleĹźnoĹci od ĹşrĂłdĹa konfiguracji: - jeĹli ukĹad ma sam wczytaÄ konfiguracjÄ z koĹci flash, uĹźywa wewnÄtrznego oscylatora jako zegara konfiguracyjnego (CCLK) i rozpoczyna wczytywanie - jeĹli ukĹad ma byÄ konfigurowany przez zewnÄtrzne ĹşrĂłdĹo, wyĹÄ cza wewnÄtrzny oscylator i uĹźywa zewnÄtrznego zegara jako CCLK - jeĹli ukĹad ma byÄ konfigurowany przez JTAG, ukĹad wyĹÄ cza wewnÄtrzny oscylator i zatrzymuje siÄ, czekajÄ c na instrukcje (i zegar) na porcie JTAG 6. UkĹad konfiguruje siÄ, uĹźywajÄ c zewnÄtrznego bÄ dĹş wewnÄtrznego sygnaĹu CCLK bÄ dĹş sygnaĹu zegarowego z portu JTAG 7. UkĹad sprawdza poprawnoĹÄ konfiguracji. 8. UkĹad przechodzi z zegara konfiguracyjnego na zegar startowy, wybrany w konfiguracji (opcja ``StartupClk`` polecenia ``bitgen``). MoĹźe to byÄ: - ``JTAGClk``: zegar z portu JTAG. UĹźywajÄ c tego ustawienia z innÄ metodÄ konfiguracji niĹź JTAG, zawiesimy ukĹad przed uruchomieniem. - ``CCLK``: ten sam zegar, co uĹźywany przy konfiguracji metodammi innymi niĹź JTAG. UĹźywajÄ c tego zegara z metodÄ JTAG, moĹźemy zawiesiÄ ukĹad, jeĹli nic nie podaje stosownego sygnaĹu na odpowiedniÄ nóşkÄ FPGA. - ``UserClk``: dowolny zegar wybrany przez uĹźytkownika przez podĹÄ czenie go do odpowiedniego bloku ``STARTUP``. 9. UkĹad przechodzi przez kolejne fazy startu, w kolejnoĹci wybranej przez uĹźytkownika (za pomocÄ opcji programu ``bitgen``). Te fazy to: - wĹÄ czenie sygnaĹu DONE, oznajmiajÄ cego Ĺwiatu zewnÄtrznemu, Ĺźe FPGA zakoĹczyĹo konfiguracjÄ i rozpoczÄĹo pracÄ. W przypadku uĹźycia wielu ukĹadĂłw FPGA, mamy moĹźliwoĹÄ monitorowania sygnaĹĂłw DONE z innych FPGA i poczekania, aĹź wszystkie bÄdÄ gotowe (synchroniczny start ukĹadu zĹoĹźonego z wielu FPGA). - wyĹÄ czenie specjalnego sygnaĹu GTS (global three-state), blokujÄ cego wszystkie sygnaĹy wyjĹciowe (zabezpiecza on przed nadawaniem nieustalonych sygnaĹĂłw na wyprowadzeniach ukĹadu w trakcie konfiguracji). - oczekiwanie na uruchomienie i ustabilizowanie wybranych ukĹadĂłw DCM (generatorĂłw zegara). - wĹÄ czenie specjalnego sygnaĹu GWE (global write enable), umoĹźliwiajÄ cego zapis do pamiÄci zawartych w ukĹadzie (przerzutnikĂłw oraz pamiÄci RAM) -- do tego momentu, ukĹad jest w stanie poczÄ tkowym. 10. UkĹad wyĹÄ cza oscylator wewnÄtrzny, jesli nie zrobiĹ tego wczeĹniej. Prymityw STARTUP_SPARTAN3E -------------------------- MoĹźemy kontrolowaÄ pewne aspekty procedury startowej instancjonujÄ c prymityw ``STARTUP_SPARTAN3E`` (moĹźna to zrobiÄ co najwyĹźej raz):: STARTUP_SPARTAN3E my_startup ( // 4 wejĹcia, kaĹźde z nich opcjonalne. .CLK(clk), // Zegar startowy (uĹźywany przez opcjÄ UserClk) .GSR(gsr), // Global Set/Reset .GTS(gts), // Global Three-State .MBT(mbt) // Multiboot trigger ); GSR jest globalnym sygnaĹem, ktĂłry asynchronicznie resetuje wszystkie przerzutniki w FPGA na ich stan poczÄ tkowy (jest uĹźywany wewnÄtrznie w czasie konfiguracji) -- moĹźemy go uĹźyÄ do restartu naszego ukĹadu. Nie jest to kompletny powrĂłt do stanu poczÄ tkowego -- nie dotyczy on wewnÄtrznych pamiÄci RAM. GTS zostaĹ opisany powyĹźej -- moĹźna go uĹźyÄ po uruchomieniu FPGA, by na chwilÄ wyĹÄ czyÄ wszystkie wyjĹcia. MBT powoduje peĹny restart i rekonfiguracjÄ FPGA z alternatywnej konfiguracji w rĂłwnolegĹej pamiÄci flash. Nie jest to dla nas zbyt interesujÄ ce, gdyĹź nasze pĹytki nie majÄ takiej pamiÄci flash. UĹźywajÄ c wejĹcia CLK moĹźemy zapewniÄ, Ĺźe uruchomienie FPGA bÄdzie zsynchronizowane z naszym zegarem i uniknÄ Ä metastabilnoĹci przy starcie.