.. _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).