Poznaj układy PLD cz.4 - Źródła i zastosowanie sygnałów zegarowych

Dlatego w zdecydowanej większości układów cyfrowych wprowadzany jest wyróżniony sygnał nadający tempo pracy poszczególnym składowym układu. Sygnał ten nazywamy sygnałem zegarowym lub krótko zegarem, a układy go wykorzystujące – układami synchronicznymi. Dzięki obecności zegara wystarczy udowodnić (co syntezator robi automatycznie), że analizowany fragment układu cyfrowego ustabilizuje stan swoich wyjść w czasie nie dłuższym niż okres sygnału zegarowego.

Nie musimy więc przejmować się ani przejściowymi stanami pośrednimi na wyjściach układu, ani analizować go jako całości, co genialnie upraszcza budowanie i automatyczną weryfikację złożonych konstrukcji. Możemy wręcz dokładać nowe klocki do już istniejącej konstrukcji i spodziewać się poprawnego działania większej całości, co w układach asynchronicznych samoistnie nie zachodzi.

Drugim ważnym zastosowaniem sygnałów zegarowych są wszelkiego rodzaju synchroniczne interfejsy komunikacyjne, oczekujące pojawienia się potrzebnej informacji dokładnie w oczekiwanym, wyznaczonym przez zegar momencie.

Sygnały zegarowe są zazwyczaj tak wszechobecne, że rzadko zastanawiamy się głębiej nad nimi samymi i szczegółami technicznymi związanymi z ich poprawną realizacją układową. W układach PLD mamy jednak zazwyczaj więcej niż jeden sygnał zegarowy i z tego powodu nie możemy sobie pozwolić na luksus ignorancji. Uproszczoną ogólną strukturę bloków zegarowych przedstawia rysunek 1.

Rys.1 Uproszczona ogólna struktura bloków zegarowych

Z naszego punktu widzenia istotne jest źródło pochodzenia sygnału zegarowego oraz sposób jego wykorzystania. Jakości sygnału zegarowego stawia się bardzo wysokie wymagania, więc w zdecydowanej większości układów PLD nie są one przesyłane połączeniami wchodzącymi w skład głównej sieci routingu (u nas DSI), lecz wydziela się dla nich dedykowaną sieć.

W układach 5LP sieć ta liczy 12 ścieżek, z czego 8 jest przeznaczone na sygnały cyfrowe, a 4 na sygnały analogowe. Takimi nazwami posługuje się dokumentacja, ale trzeba pamiętać, że są to jedynie wygodne skróty myślowe: w obu przypadkach są to „cyfrowe” sygnały prostokątne o bardzo niskim szumie fazowym (jitter) i współczynniku wypełnienia bliskim 50%.

Zegary „analogowe” służą po prostu do taktowania analogowych składowych układów 5LP, więc ze względu na istotną w tych zastosowaniach potrzebę ścisłego kontrolowania fazy sygnału zegarowego bloki je wytwarzające są dodatkowo wyposażone w programowalne linie opóźniające. Linia taka składa się z 21 połączonych szeregowo stopni, z których każdy wprowadza opóźnienie o 500 pikosekund względem swojego sygnału wejściowego.

Multiplekser pozwala podłączyć się do N-tego ogniwa tego łańcucha, więc sygnał wyjściowy może być opóźniony o 0,5*N nanosekund względem sygnału wejściowego. Wartość tego opóźnienia, w połączeniu ze znaną częstotliwością sygnału opóźnianego, da się przeliczyć na przesunięcie fazowe obu sygnałów w stopniach, jeżeli taka interpretacja okaże się dla Czytelnika wygodniejsza.

Źródła sygnałów zegarowych - omówienie

Tu sprawa jest nieco bardziej skomplikowana. Pierwsze wrażenie z rysunku 2 może być wręcz takie, że jest beznadziejnie skomplikowana. Na szczęście nie jest to prawda, tylko trzeba rysunek przeanalizować, pamiętając, czemu ta złożona konstrukcja ma służyć. Po drugie, na pocieszenie powiem, że im większy układ programowalny, tym sytuacja staje się bardziej złożona, choć – co do zasady – podobna. Szczegóły będą oczywiście zależne od konkretnego układu, ale na szczęście nawet w największych układach FPGA wiedza i intuicje wyniesione z poznania serii 5LP pozostaną poprawne.

Rys.2 Zegary

Najważniejszym sygnałem zegarowym w układach 5LP jest sygnał o nazwie MASTER_CLK (1). Nie mijając się zbytnio z prawdą, możemy wstępnie przyjąć, że to właśnie z niego wywodzą się wszystkie pozostałe sygnały zegarowe w układzie, więc z konieczności będzie to sygnał najwyższej częstotliwości. Poprzez podział tego sygnału przez podaną w polu (2) liczbę naturalną powstaje sygnał BUS_CLK, który służy do taktowania rdzenia ARM, szyny danych, bloków DMA i koprocesora DFB.

Maksymalna częstotliwość zegara MASTER_CLK to 80MHz, a minimalny dzielnik to 1, więc taka też będzie największa możliwa częstotliwość sygnału BUS_CLK. Uwaga: maksymalna częstotliwość taktowania bloków PLD to 67MHz, więc nie możemy w tym celu użyć sygnału 80MHz! Trzeba sygnał MASTER_CLK albo podzielić przez kolejną możliwą liczbę, czyli 2, co skutkuje sygnałem maksymalnie 40MHz dla bloków logiki programowalnej (i do 80MHz dla procesora), albo obniżyć go do 67MHz i po podziale przez 1 taką częstotliwością taktować procesor oraz PLD.

Z powodów konstrukcyjnych nie ma możliwości uzyskania maksymalnej wydajności obu tych elementów jednocześnie, więc w zastosowaniach wymagających dużej wydajności należy dokładnie przemyśleć sprawę i wybrać najkorzystniejszy wariant. Obecnie jako domyślną proponuję przyjąć pierwszą z opcji: będziemy wówczas mieli szybki procesor i jednocześnie taktowanie logiki programowalnej będzie bezpiecznie odsunięte od wartości granicznej, dzięki czemu na początku nauki nie natkniemy się na dość ezoteryczne problemy związane z czasem propagacji sygnałów i jeszcze dziwniejsze sposoby radzenia sobie z nimi.

Zanim sygnał MASTER_CLK zacznie podlegać dalszym podziałom, musi się najpierw skądś wziąć: jego źródło wybieramy z listy (1). Dostępnymi możliwościami są IMO (wewnętrzny oscylator RC, znajdujący się na chipie procesora), XTAL (oscylator oparty na zewnętrznym rezonatorze kwarcowym lub ceramicznym), Digital Signal (sygnał dostarczony przez DSI i pochodzący z pinu lub bloku PLD) oraz PLL (3).

Ostatnia z opcji jest najbardziej elastyczna, pozwala bowiem uniezależnić częstotliwość taktowania układu od częstotliwości generatorów: pętla PLL mnoży częstotliwość sygnału zegarowego podanego na jej wejście przez podany ułamek. Na przykład uzyskanie sygnału 80MHz z generatora 3MHz wymaga jego pomnożenia przez 80/3. W praktyce mogłoby to być jedyne interesujące nas rozwiązanie, gdyby nie fakt, że pętla PLL zużywa jakąś ilość energii, wprawdzie niewielką, ale jeżeli w projekcie Czytelnika maksymalna wydajność nie jest istotna, za to każdy miliwat się liczy, to skorzystanie z innych wariantów zegara może okazać się korzystniejsze.

Rys.3 Układ PLL o ułamkowym mnożniku

Układ PLL o ułamkowym mnożniku (rysunek 3) opiera się na bardzo ciekawym pomyśle, więc mniej zaawansowanym Czytelnikom warto powiedzieć o nim kilka słów. Sygnał z wewnętrznego generatora sterowanego napięciem VCO jest dzielony przez liczbę naturalną P (od 4 do 256) i podawany na jedno z wejść detektora fazy PFD. Na drugie wejście detektora jest podawany sygnał referencyjny podzielony przez liczbę Q (od 1 do 16).

Detektor fazy wraz z filtrem dolnoprzepustowym wytwarzają napięcie proporcjonalne do różnicy faz sygnałów wejściowych. Napięcie to zwiększa lub zmniejsza chwilową częstotliwość generatora VCO. Układ stara się tak sterować VCO, by różnica faz między oboma sygnałami wynosiła 0 stopni. Gdy uda mu się to osiągnąć, informacja o tym jest przekazywana na wyjście lock bloku PLL. Synchronizacja zajdzie, gdy f_VCO/P=f_ref/Q. Jeżeli dzielniki P i Q mają jednakową wartość (np. 4), to sygnał z VCO będzie dokładną kopią sygnału referencyjnego. W innym przypadku sygnał VCO będzie miał częstotliwość dokładnie P/Q częstotliwości referencyjnej.

Wróćmy do źródeł sygnału. Generator IMO (4) do swojego działania nie wymaga żadnych elementów zewnętrznych i to właśnie z niego (nieświadomie) korzystaliśmy we wcześniejszych projektach. Jego częstotliwość wyjściowa jest konfigurowalna (3, 6, 12, 24, 48, 62,6 albo 74,7 megaherca), ale jej tolerancja rośnie wraz ze wzrostem częstotliwości.

Producent gwarantuje dokładność ±1% w całym zakresie temperatur pracy i napięć zasilania układu tylko dla przypadku 3MHz, w pozostałych przypadkach jest znacznie gorzej, bo aż do ±7%. Często nawet tak duża tolerancja będzie w zupełności wystarczająca, ale projekty wymagające precyzyjnego taktowania będą musiały skorzystać albo z zewnętrznego generatora kwarcowego lub MEMS, albo z oscylatora XTAL (5) i rezonatora.

Użycie zewnętrznego rezonatora

Źródło precyzyjnego zegara bardzo przydaje się podczas prototypowania, więc – niezależnie od naszych bieżących potrzeb – zachęcam, by przylutować rezonator wraz z odpowiednimi dla niego kondensatorami do pinów P15[0] oraz P15[1]. Ze względu na możliwości powielające pętli PLL częstotliwość kwarcu nie jest bardzo istotna; ja użyłem rezonatora 16MHz. Trzeba tylko pamiętać, by mieściła się ona w zakresie 4–25MHz.

Użycie zewnętrznego rezonatora wprowadza do naszego projektu kilka dodatkowych aspektów, których określenie staje się możliwe po włączeniu bloku oscylatora „ptaszkiem”. Pojawia się wówczas dodatkowe okno konfiguracyjne (rysunek 4).

Rys.4 Dodatkowe okno konfiguracyjne

W polu (a) wpisujemy częstotliwość naszego rezonatora, a w polu (b) możemy wpisać jej tolerancję, jeśli jest nam znana. W polach (c) wpisujemy pojemność kwarcu oraz kondensatorów obciążających. Pozostałe ustawienia pozostawiamy w trybie Automatic. Uwaga: na podstawie podanych wartości PSoC Creator sprawdza spełnienie ograniczeń wybranego układu.

Jego autorzy jednak błędnie przyjęli absolutną nieprzekraczalność maksymalnej częstotliwości taktowania układu (80MHz), choć dokumentacja mówi inaczej (80,01MHz). Chcąc skorzystać w projekcie z maksymalnej częstotliwości taktowania, nie możemy programowi powiedzieć prawdy, bo nawet wyjątkowo dokładny kwarc 5ppm po powieleniu przez PLL okazuje się produkować sygnał poza zakresem dopuszczalnym. Trzeba wówczas w prawym polu tolerancji wpisać 0 [ppm] jako mniejsze zło.

Rezonator jest elementem mechanicznie delikatnym, więc jego uszkodzenie – choć rzadkie – nie jest wykluczone i może mieć katastrofalny skutki dla otoczenia. Gwałtowne zatrzymanie się układu sterującego np. głównym kluczem przetwornicy zasilanej z sieci i pozostawienie tego klucza w stanie stale włączonym może skończyć się pożarem. Projektanci układów 5LP przewidzieli to i wprowadzili środki umożliwiające reakcję układu na taki scenariusz.

Jeżeli rezonator/generator zewnętrzny w ogóle nie wystartuje w zadanym czasie po resecie (e), to układ (taktowany w tej fazie z oscylatora IMO) może się albo zatrzymać na etapie rozruchowym, albo pozostać na IMO i już z poziomu programu użytkownika np. wyświetlić komunikat o błędzie.

Po drugie, co prawda start może się udać, ale do uszkodzenia rezonatora dojdzie po kilku miesiącach bezawaryjnej pracy urządzenia. Układy 5LP stale monitorują zewnętrzny sygnał zegarowy i – w razie jego zaniku – mogą automatycznie przełączyć się na IMO (d). Tolerancja sygnału zegarowego oczywiście gwałtownie się wówczas pogorszy (m.in. nie spełni wymagań interfejsu CAN), ale do kontrolowanego wyłączenia awaryjnego urządzenia nawet taki zegar z powodzeniem wystarczy.

W takim przypadku trzeba jednak starannie dobrać częstotliwość kwarcu do ustawień IMO, by nie doprowadzić do gwałtownego skoku częstotliwości referencyjnej, mogącego „wystrzelić” generator VCO pętli PLL daleko poza dopuszczalny zakres parametrów układu, co będzie źródłem jeszcze większych kłopotów.

Specjalne wymagania co do częstotliwości i tolerancji taktowania ma interfejs USB, więc przydzielono mu specjalizowany blok zegarowy (6). Ponieważ standard wymaga zegara 48MHz, sygnał wejściowy musi mieć częstotliwość albo właśnie taką, albo 24MHz, dzięki wbudowanemu w IMO opcjonalnemu podwajaczowi częstotliwości.

Uzyskanie sygnału o takich parametrach jest możliwe tylko albo przez użycie rezonatora kwarcowego o częstotliwości 24MHz, albo wygenerowanie 48MHz za pomocą PLL. Niestety, w układzie jest tylko jedna pętla PLL, więc 48MHz stanie się też maksymalną częstotliwością sygnału MASTER_CLK i nie zbliżymy się nawet do maksymalnej wydajności układu.

W praktyce okazuje się to dotkliwym ograniczeniem, np. w częstościomierzu chcielibyśmy mieć rezonator 10MHz (celem zapewnienia łatwej integracji układu z zewnętrznym standardowym sygnałem wzorcowym o tej właśnie częstotliwości), taktować procesor 80MHz oraz jednocześnie móc podłączać nasz przyrząd przez USB. Opisana wyżej technika nie pozwala spełnić wszystkich tych wymagań jednocześnie.

Z tego powodu blok IMO został wyposażony w specjalny tryb pracy: przy częstotliwości 48MHz tolerancja zegara wynosi co prawda nieakceptowalne w tym zastosowaniu ±5%, ale po podłączeniu do szyny USB co milisekundę pojawiają się na niej znaczniki czasowe transmitowane przez host. IMO potrafi się automatycznie z nimi zsynchronizować i obniżyć swoją tolerancję do ±0,25%, co już w zupełności wystarcza dla USB.

Taktowanie pozostałej części układu może być więc efektywnie „odpięte” od bloku USB – dlatego w praktyce jednoczesne użycie wszystkich dostępnych źródeł sygnału zegarowego w rozbudowanym projekcie nie musi być niczym dziwnym.

Na pokładzie PSoC5LP znajduje się jeszcze znacznie wolniejszy generator ILO. Generuje on stosunkowo niskie częstotliwości (maks. 100kHz) i działa nawet wtedy, gdy procesor znajduje się w stanie uśpienia. Z tego powodu musi on pobierać znikomą moc, na czym cierpi tolerancja: może ona wynosić nawet +100/–50%. Słabo sprawdzi się więc w roli precyzyjnego źródła czasu. Jest z niego taktowany watchdog oraz inne systemy aktywne w trybie uśpienia, ale użytkownik również może z tego sygnału skorzystać.

Dla kompletności należy wspomnieć o opcjonalnym, typowym w mikrokontrolerach oscylatorze 32768Hz stosowanym do dokładnego pomiaru czasu (8) wraz z zewnętrznym rezonatorem widełkowym oraz jednym źródle „obcego” sygnału zegarowego (9).

Jak widać, zagadnienie jest obszerne, ale wcale nie takie zawiłe, jak się początkowo wydawało. Pierwszym krokiem jest zawsze ustalenie potrzebnego zegara głównego MASTER_CLK, a następnie wytworzenie z niego sygnału BUS_CLK poprzez podział. Dopiero wtedy istotne staje się znalezienie najwłaściwszego źródła taktowania dla zegara głównego, co jest czynnością czysto techniczną i zależną od wymagań projektu.

Wykorzystanie praktyczne sygnału zegarowego

No dobrze, skonfigurowaliśmy już nasz MASTER_CLK, sygnał BUS_CLK taktujący procesor powstał z niego automatycznie przez podział i nic nie musimy z nim robić, ale jak wykorzystać własne zegary w komponentach logiki programowalnej?

Nic prostszego: w katalogu komponentów wpisujemy „clock” i na schemat przeciągamy element System→Clock [v2.20], który domyślnie udostępnia pojedyncze wyjście cyfrowe. Klikamy na nim dwukrotnie i w wizardzie konfiguracyjnym (rysunek 5) nadajemy mu odpowiednią nazwę (1). Z listy (2) wybieramy źródło sygnału zegarowego (zazwyczaj MASTER_CLK) i w polu (3) określamy potrzebną częstotliwość zegara.

Możemy zrobić to albo jawnie, podając dzielnik, albo od razu częstotliwość wynikową, a wtedy PSoC Creator sam wyznaczy odpowiedni dzielnik. Uwaga: dopuszczalne dzielniki są 16-bitowymi liczbami naturalnymi i tylko wynikające z nich częstotliwości da się uzyskać dokładnie. Ze źródła 10MHz nie uzyskamy sygnału 3MHz, choć taką liczbę da się wpisać w wizardzie – otrzymamy tylko najlepsze możliwe jej przybliżenie.

Rys.5 Wizardzie konfiguracyjny - własny zegar (komponenty PLD)

Domyślnie wszystkie zegary startują automatycznie po resecie, ale można to indywidualnie zmienić w kolumnie DWR→ Clocks→Start on Reset. Działaniem zegara można sterować zarówno sprzętowo (zakładka Built-in→Settings→Disable), jak i programowo. Jeżeli domyślne działanie nam odpowiada i nie potrzebujemy sterować zegarem podczas działania projektu, warto też „zaptaszyć” Settings→Suppress API Generation. Nie zostaną wówczas automatycznie wygenerowane pliki w C dostarczające powyższej funkcjonalności – im mniej zbędnych elementów w projekcie, tym bardziej jest on przejrzysty. Uwaga ta stosuje się zresztą jednakowo do wszystkich innych komponentów.

Warto też zajrzeć do zakładki Advanced, bo kryje się tam krytycznie istotne ustawienie: Sync with BUS_CLK. Jeżeli wszystkie zegary wytworzyliśmy przez podział MASTER_CLK, to są one w naturalny sposób zsynchronizowane z BUS_CLK, bo i on jest podzielonym MASTER_CLK. W takiej sytuacji, pomimo mnogości zegarów, relacje fazowe pomiędzy nimi są dobrze określone i cały układ można traktować jako pojedynczą domenę zegarową. To jest przypadek typowy.

W polu Source możemy jednak (zbyt łatwo…) wskazać inne źródło (np. IMO), które może działać zupełnie niezależnie od zegara głównego. Częstotliwości i fazy takich zegarów nie są w żadnej ustalonej relacji, co prowadzi do powstania dwóch (lub więcej) niezależnych domen zegarowych.

Bezbłędna wymiana informacji pomiędzy różnymi domenami, zwłaszcza dwukierunkowa, jest problemem skrajnie trudnym i należy jej unikać jak ognia, jeśli tylko wymagania na to pozwalają. Zignorowanie tej rady kosztowało mnie kiedyś dwa dni debugowania z oscyloskopem i poszukiwania wsparcia w Słowniku polskich wyzwisk, inwektyw i określeń pejoratywnych prof. Stommy.

Czytelniku, zostałeś ostrzeżony!

Jeśli jednak niezależna domena już się pojawiła, to warto rozważyć jej synchronizację z BUS_CLK. Jednak nie rozwiązuje to magicznie wszystkich problemów, a wręcz wprowadza nowe: zegar obcy będzie próbkowany podczas zboczy BUS_CLK, więc po synchronizacji jego współczynnik wypełnienia zmieni się w niekontrolowany sposób i niekoniecznie będzie przypominał sygnał wejściowy. Problemu najlepiej pozbyć się całkowicie, wywodząc wszystkie zegary z MASTER_CLK. Odstępstwa są dopuszczalne dopiero na wysokim poziomie zaawansowania, a i wtedy jest to proszenie się o kłopoty. Układy FPGA często zawierają dostarczone przez producenta komponenty przeznaczone do wymiany informacji między domenami zegarowymi. Dla prostych przypadków PSoC Creator również udziela takiego wsparcia: Digital→Utility→Sync [v1.0].

Warto też zauważyć, że każdy egzemplarz komponentu zegara na schemacie wprowadza do układu nowy zegar, nawet jeśli częstotliwość jest identyczna z jakimś już istniejącym. Rzadko jest to pożądane, więc przy okazji zapoznajmy się z kolejnym elementem edytora schematów: Sheet Connector. Jest on oznaczony „diamentem” i znajduje się pod „wężykiem”.Stosuje się go celem wyraźnego zaznaczenia, że sygnał pochodzi „z zewnątrz” bieżącego arkusza (schematy mogą składać się z wielu arkuszy, choć z tego faktu jeszcze nie korzystaliśmy), ale na jednym arkuszu działa równie dobrze.

Dlatego zamiast prowadzić połączenia ze wspólnego zegara do każdego miejsca jego użycia, lepiej zrobić to czytelniej: łączymy wyjście zegara z „diamentem”, klikamy dwukrotnie na połączeniu i w wizardzie odznaczamy Use computed name and width. Poniżej pola Specify Full Name wpisujemy odpowiednią dla naszego zegara nazwę (np. CLK_4MHZ). W miejscu użycia robimy to samo, co kończy sprawę: bez jawnego przewodu podłączyliśmy się do wspólnego, nazwanego sygnału.

W przypadku bardziej rozbudowanych projektów łatwo docenić zaletę tego rozwiązania. Oczywiście użycie „diamentu” nie ogranicza się do sygnałów zegara, dokładnie w ten sam sposób możemy potraktować dowolne inne pojedyncze połączenia, a nawet całe wielobitowe szyny. „Diament” będzie automatycznie przyjmował kolor związanego z nim połączenia.

Rys.6 Projekt demonstracyjny (zrzut ekranu)

Wszystkie istotne elementy omówione w dzisiejszym odcinku zawarłem w dostępnym w Elportalu projekcie demonstracyjnym – rysunek 6 pokazuje zrzut ekranu. Jako źródło sygnału zegarowego wybrałem generator IMO o częstotliwości 3MHz, którego sygnał następnie powieliłem za pomocą pętli PLL do 40MHz. Częstotliwość ta mieści się w zakresie możliwości zarówno procesora, jak i bloku PLD, więc sygnał bez dalszych podziałów pełni funkcję jednocześnie MASTER_CLK i BUS_CLK.

Na schemacie umieściłem komponent zegara i skonfigurowałem go w taki sposób, by jego źródłem był MASTER_CLK, a częstotliwością wyjściową 1kHz. Na tej podstawie PSoC Creator automatycznie obliczył, że właściwym dzielnikiem będzie 40000, a tolerancja częstotliwości wyjściowej wyniesie ±1%. Sygnał zegara poprzez „wirtualne połączenie” oparte na „diamencie” taktuje kaskadę przerzutników T połączonych tak, by każdy z nich dzielił go przez dwa. Ponieważ przerzutników jest 10, sygnał jest dzielony przez 2¹⁰, czyli 1024. Znajdująca się na płytce zestawu niebieska dioda LED D1 będzie więc migać z częstotliwością 1000Hz/1024, czyli nominalnie 976 miliherców.

Poznawszy zegary, mamy już wszystkie podstawowe elementy do konstruowania synchronicznych układów logicznych, choć jeszcze nie zawsze w sposób czytelny i efektywnie wykorzystujący zasoby układu. Jednak oprócz pogłębiania wiedzy należy ćwiczyć też warsztat, więc w następnym odcinku chwilowo odłożymy na bok poznawanie kolejnych bloków sprzętowych rodziny 5LP i zajmiemy się modularyzacją naszych projektów.