.. _w08-timing: ========================= WykĹad 8: Analiza czasowa ========================= Data: 28.11.2018 .. toctree:: .. contents:: Wprowadzenie ============ Gdy juĹź napiszemy nasz ukĹad w jÄzyku opisu sprzÄtu, przetestujemy go w symulatorach i przeprowadzimy weryfikacjÄ formalnÄ , nadchodzi czas na realizacjÄ sprzÄtowÄ -- w przypadku FPGA, oznacza to wykonanie kroku place and route, ktĂłry rozmieĹci nasz ukĹad wewnÄ trz FPGA. Jest to moment, w ktĂłrym zostanÄ ustalone cechy fizyczne naszego ukĹadu -- rozmieszczenie logiki w ukĹadzie, mapowanie wejĹÄ/wyjĹÄ na fizyczne nóşki ukĹadu, maksymalna moĹźliwa czÄstotliwoĹÄ zegara, zuĹźycie prÄ du, itp. DomyĹlnie, place and route wykona caĹÄ pracÄ za nas i powiadomi nas o wyniku za pomocÄ wielu raportĂłw. MoĹźemy jednak sterowaÄ tym procesem za poĹrednictwem tzw. constraintĂłw, przekazywanych przez plik ``ucf``. 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. Raporty z analizy czasowej ========================== Do wygenerowania raportu moĹźna uĹźyÄ narzÄdzia ``trce``:: trce abc_par.ncd Wygenerowany zostanie plik raportu ``.twr``, w ktĂłrym znajdziemy informacje o opóźnieniach w naszym ukĹadzie: - czasy propagacji sygnaĹĂłw wewnÄtrznych od zbocza do zbocza (odwrotnoĹÄ tego czasu jest maksymalnÄ czÄstotliwoĹciÄ danego zegara) - czasy hold/setup od nóşki wejĹciowej do zbocza zegarowego - czasy propagacji od zbocza zegarowego do nóşki wyjĹciowej Pliki UCF ========= Pliki UCF (User Constraint File) sĹuĹźÄ do przekazania oczekiwanych cech fizycznych ukĹadu (zwanych constraintami) do procesu place and route. PeĹny opis dostÄpnych opcji dostÄpny jest tutaj: https://www.xilinx.com/support/documentation/sw_manuals/xilinx11/cgd.pdf . NajwaĹźniejsze z nich to: - ``PERIOD``: opisuje cechy przychodzÄ cego sygnaĹu zegarowego:: NET "myclk" = PERIOD 20ns INPUT_JITTER 100ps; Oznacza to, Ĺźe nasz zegar (na sieci myclk) ma okres 20ns (czyli czÄstotliwoĹÄ 50MHz) i jitter 100ps. Podanie tego ograniczenia powoduje, Ĺźe par bÄdzie staraĹ siÄ o takie rozmieszczenie ukĹadu, by ukĹad mĂłgĹ dziaĹaÄ z tÄ czÄstotliwoĹciÄ . W przypadku podĹÄ czenia takiego zegara jako wejĹcia do DCM, narzÄdzia same wyprowadzÄ odpowiednie parametry dla zegara wyjĹciowego. - ``LOC``: pozwala na wymuszenie poĹoĹźenia danego elementu bÄ dĹş sieci. UĹźywaliĹmy juĹź tego do powiÄ zania wejĹÄ/wyjĹÄ gĹĂłwnego moduĹu z nóşkami FPGA:: NET "Led<0>" LOC = "M5"; Czasami przydatne jest teĹź wymuszenie poĹoĹźenia dla innych blokĂłw:: INST "moj_dcm" LOC = "DCM_X0Y0"; - ``PULLUP``, ``PULLDOWN``, ``KEEPER``, ``FLOAT``: mĂłwi, jakiego typu opornika podciÄ gajÄ cego uĹźyÄ dla wyprowadzeĹ. - ``DRIVE``: mĂłwi, jakiego natÄĹźenia prÄ du uĹźyÄ na pinach wyjĹciowych (w miliamperach) -- wiÄksze wartoĹci pozwalajÄ na szybszÄ zmianÄ stanu i wiÄksze czÄstotliwoĹci zegara, ale jednoczesna zmiana stanu na zbyt wielu silnych nóşkach jednoczeĹnie wiÄ Ĺźe siÄ z ryzykiem wystÄ pienia tzw. ground bounce -- skoku napiÄcia na liniach zasilajÄ cych ukĹad. - ``IOSTANDARD``: wybiera standard elektryczny do przesyĹu danych na pinie. W przypadku pĹytki Basys 2, wszystkie nóşki uĹźywajÄ domyĹlnej wartoĹci (``LVCMOS33``). - ``ASYNC_REG``: oznacza przerzutnik jako czÄĹÄ synchronizatora. W przypadku naruszenia czasu hold/setup w symulacji nie zostanie zgĹoszony bĹÄ d (i nie zostanie wygenerowany stan X).