W poprzednim odcinku pokazaliśmy sposób weryfikacji działania projektu implementowanego w FPGA zestawu MAXimator za pomocą symulatora wbudowanego w środowisko projektowe Quartus Prime. Konstruktorzy korzystający z FPGA maja także inną możliwość weryfikacji działania implementowanego projektu, koncepcyjnie bliższą współczesnym mikrokontrolerom: dzięki bezpłatnemu IP core o nazwie SignalTAP II, który jest dystrybuowany wraz z Quartusem, można wygodnie zweryfikować działanie projektu, korzystając z interfejsu JTAG. W artykule pokażemy jak to zrobić krok-po-kroku.

Idea działania IP core o nazwie SignalTAP II przypomina wkładany do wnętrza FPGA rejestrator stanów logicznych. Wyobraźmy sobie wielowejściową sondę, której wejścia są dołączone do interesujących nas sygnałów w implementowanym projekcie, wyposażoną we własną pamięć (rysunek 1).

Rys. 1. Schemat blokowy ilustrujący działanie sprzętowego debugera SignalTAP II

W pamięci tej są rejestrowane stany logiczne występujące w wybranych (poprzez dołączenie linii wejściowych modułu SignalTAP) przez konstruktora miejscach. Odczyt zgromadzonych w pamięci danych odbywa się za pomocą interfejsu USB Blaster za pośrednictwem interfejsu JTAG, tego samego, który jest używany do programowania i/lub konfigurowania FPGA.

Rys. 2. Porównanie zajętych w FPGA zasobów przy implementacji samego licznika 74169 (lewa strona) i przy implementacji tego samego licznika z dołączonym debugerem SignalTAP II (prawa strona)

Podczas realizacji projektów z wykorzystaniem SignalTAP II trzeba pamiętać, że jest to IP core implementowany w FPGA, w związku z czym pochłania część zasobów tego układu. Na rysunku 2 pokazano porównanie wykorzystania zasobów przy implementacji samego licznika 74169 (lewa strona rysunku 2) i przy implementacji tego samego licznika z dołączonym debugerem SignalTAP. Porównanie liczb może wywołać myśl, że SignalTAP II jest bardzo zasobożerny (odnosząc do implementację do samego 74169), ale przy dostępnych zasobach układu 10M08 użytego w MAXimatorze widać, że nie „zjada” on relatywnie wielu zasobów. Trzeba wziąć pod uwagę, że pojemność użytej pamięci i liczba zajętych przez SignalTAP rejestrów będzie się zmieniać w zależności od liczby rejestrowanych kanałów i głębokości pamięci rejestrującej zmiany stanów logicznych. W prezentowanym przykładzie zadeklarowano 7 kanałów wejściowych (z czego użyto 6) i głębokość pamięci 128 słów.

Przykład użycie debugera SignalTAP pokażemy na przykładzie znanego nam już licznika 74196, który będzie taktowany sygnałem zegarowym 10 MHz (generator kwarcowy wbudowany na płytce MAXimator). Monitorować będziemy stany linii wyjściowych licznika, a także poziomy sygnałów na jego wejściach. Wejście LD licznika spełnia w przykładzie rolę wejścia zerującego, posłuży nam ono w projekcie także do wyzwolenia rejestracji stanów linii przez SignalTAP II.

W wersjach Quartusa od 14.0 możliwe są dwie ścieżki implementacji debugera SignalTAP II, zaczniemy od prezentacji metody klasycznej, w której ręcznie dodajemy do schematu lub opisu HDL IP core debugera.

Rys. 3. SignalTAP II jest dostępny w ramach bezpłatnych IP core w pakietach Quartus II i Quartus Prime

Implementację debugera SignalTAP II w projekcie implementowanym w FPGA należy przeprowadzić po jego kompilacji i przypisaniu linii sygnałowych do fizycznych wyprowadzeń układu. Zaczynamy od wygenerowania sparametryzowanego IP core debuggera SignalTAP II, co wymaga wybrania w katalogu dostępnych IP core opcji Library>Basic Functions>Simulation, Debug and Verification>Debug and Performance>Altera SignalTap II Logic Analyzer (rysunek 3). Spowoduje to uruchomienie generatora i parametryzatora IP core’ów (rysunek 4), w którego pierwszym oknie podajemy nazwę generowanego modułu (w przykładzie jest to TAP74169).

Rys. 4. Generację IP core debugera zaczynamy od nadania nazwy naszej mutacji SignalTAP II

Parametryzacja debugera w naszym przykładzie ogranicza się do podania liczby potrzebnych wejść rejestrujących dane, w przykładzie ich liczbę nadmiarowo ustalono na 7 (rysunek 5). Do naszych celów wystarcza domyślna pojemność pamięci rejestrującej dane, która wynosi 128 próbek, ale można – w zależności od potrzeb – zwiększyć lub zmniejszyć jej pojemność (w sekcji Data okna pokazanego na rysunku 5). Nie będziemy teraz korzystać z pozostałych, bardziej zaawansowanych możliwości parametryzacji, wrócimy do ich prezentacji przy okazji kolejnych odcinków kursu.

Rys. 5. Okno parametryzacji debugera SignalTAP II