wersja mobilna | kontakt z nami

Pierwsze kroki z FPGA (4). Szkoła MAXimatora - monitorowanie pracy projektu z użyciem debugera SignalTAP II

Numer: Lipiec/2016

Miesiąc temu pokazaliśmy sposób weryfikacji działania projektu implementowanego w FPGA za pomocą symulatora wbudowanego w środowisko projektowe Quartus. 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.

Pobierz PDF

rys-1Idea 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?? (ączone do interesujących nas sygnałów w implementowanym projekcie, wyposażoną we własną pamięć (rysunek 1). 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-2Podczas 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.

rys-3Przykład zastosowania 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-4Implementację 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). 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-5Po ustaleniu potrzebnej liczby wejść generujemy (wciskając Generate HDL…) pliki źródłowe debugera w wybranym języku HDL (Verilog lub VHDL). Późniejsze ewentualne modyfikacje parametrów modułu można wygodnie zmieniać otwierając plik TAP74169.qsys i po wprowadzeniu zmian ponownie generując pliki HDL. W tym momencie mamy wygenerowany opis HDL debugera, ale nie został on jeszcze dodany do projektu. Proces ten musimy wykonać ręcznie, co wymaga otwarcia pliku TAP74169.qip (znajduje on się katalogu sciezka_generacji_plikow-debugerasynthesis) i następnie dodania go do projektu (Project>Add Current File to Project). Po wykonaniu tych czynności w nawigatorze projektu (Project Navigator – rysunek 6) wyświetlamy wszystkie pliki wchodzące w skład projektu i rozwijamy gałąź TAP74169/sythesis/ (rysunek 6), w której znajduje się plik HDL z opisem debugera (w przykładzie jest to plik w Verilogu). Klikamy w nazwę pliku prawym klawiszem myszki i wybieramy opcję Create Symbol Files for Current File (rysunek 7), co powoduje dodanie graficznego symbolu debugera do biblioteki projektu.

rys-6 rys-7

Żeby położyć symbol debugera na planszy schematu postępujemy tak jak w przypadku innych symboli – dwukrotnie klikamy w puste miejsce na planszy, co spowoduje wyświetlenie okna Symbol (rysunek 8), w którym dostępne są dwa symbole TAP74169. Jest to normalne zjawisko, wynikające z pewnych niekonsekwentnych rozwiązań w pakiecie Quartus, przy czym są one nieszkodliwe.

Wybieramy jeden z dostępnych symboli i opisujemy sposób dołączenia linii wejściowych oraz linii wyzwalającej do testowanej części projektu. Odbywa się to w taki sam sposób, jak w przypadku rysowania schematu rozwiązania implementowanego w ramach projektu.

rys-8 rys-9

Na rysunku 9 pokazano schemat połączeń układu testowego, w którym jedno z wejść debugera dołączono na stałe do logicznej „1”. Po wykonaniu wszystkich połączeń kompilujemy projekt, żeby wychwycić ewentualne błędy uniemożliwiające jego poprawną implementację. Jeżeli wszystko jest w porządku, możemy przejść do kolejnego kroku – przygotowania pliku debugera. W tym celu wybieramy w menu File>New i w wyświetlonym oknie, w sekcji Verification/Debugging Files (rysunek 10), wybieramy SignalTap II Logic Analyzer File. Okno analizatora pokazano na rysunku 11.

rys-10 rys-11

 

Konfigurację tej części projektu zaczynamy od ustalenia listy monitorowanych sygnałów, co wymaga dwukrotnego kliknięcia w zakładce Setup, w wyniku czego wyświetli się okno Node Finder pokazane na rysunku 12. Ponieważ wejścia debugera SignalTAP II dołączyliśmy do wyjść i niektórych wejść monitorowanego licznika, w filtrze sygnałów (Options>Filter) wybieramy opcję Pins:all i następnie klikamy List. Wynik tej operacji pokazano na rysunku 12. Wybieramy z listy interesujące nas sygnały (w przykładzie OUT3…OUT0 oraz nRES, przy którym aktywujemy opcję Trigger Enable – rysunek 13) i klikamy Insert.

rys-12 rys-13

 

rys-14Po wykonaniu tych czynności ponownie kompilujemy cały projekt, do czego zachęca komunikat widoczny w belce Instance Manager, w górnej części okna pokazanego na rysunku 13. Po rekompilacji programujemy lub konfigurujemy docelowy układ FPGA, co jest oczywiste – musimy umieścić testowany projekt w FPGA, żeby móc go fizycznie monitorować.

Alternatywnym, wygodniejszym sposobem implementacji w projekcie umieszczanym w FPGA debugera SignalTAP, jest dodanie do projektu pliku *.stp (jak na rysunku 10) i wykonanie kolejnych czynności, łącznie z wybieraniem monitorowanych sygnałów z poziomu okna SignalTap II Logic Analyzer (jak na rysunku 14). W nowych wersjach Quartusa uruchomienie tego okna i zdefiniowanie listy sygnałów powoduje automatyczną implementację debugera w projekcie.

We wrześniowym wydaniu EP przedstawimy zaawansowane możliwości debugera SignalTAP II.

Piotr Zbysiński, EP

 

Z przyjemnością publikujemy listę 14 osób, które otrzymały nagrody w konkursie dla fanów FPGA, który ogłosiliśmy w EP5/2016. Łącznie otrzymaliśmy aż 54 zgłoszenia! Nagrody zostały wysłane pocztą przez sklep KAMAMI.pl.

Lista osób nagrodzonych:
1. Aleksandra Gaszyńska
2. Jacek Dębniak
3. Jakub Jakubowski
4. Jarosław Krukowski
5. Karol Kulig
6. Konrad Miciński
7. Wojciech Kozikowski
8. Marcin Skóra
9. Mariusz Dziębowski
10. Piotr Zamorski
11. Przemysław Szymański
12. Wojciech Stodulny
13. Piotr Chodorowski
14. Wojciech Przybycień

We wrześniowym wydaniu EP kolejny konkurs!

Pozostałe artykuły

System sterowania DMX512 dla każdego (3) Adresowanie urządzeń

Numer: Sierpień/2016

W kolejnej części kursu obsługi urządzeń z interfejsem DMX512 wykonamy próbne sterowanie oświetleniem w postaci diod LED RGB. Zainstalujemy też program pomocniczy, ułatwiający adresowanie urządzeń DMX i chroniący przed popełnianiem błędów.

Zastosowanie modułu Wi-Fi ESP-12 (2). Wirtualny interfejs szeregowy

Numer: Sierpień/2016

UART jest jednym z interfejsów używanych do komunikacji. Jest on łatwy w obsłudze programowej i użyciu, szczególnie w wypadku komunikacji z komputerem PC. Dla uzyskania podstawowej funkcjonalności jest przyłączenie jedynie 3 linii: RxD, TxD oraz masy. Ileż prościej by było, gdyby można zastosować taki interfejs bez używania żadnych kabli. Pozwoliłoby to na bezproblemową komunikację komputera z systemem wbudowanym, bez konieczności ...

Programowanie paneli HMI (4)

Numer: Lipiec/2016

Praca z nowym urządzeniem zawsze zaczyna się od prostego przykładu. Takim przykładem zazwyczaj jest Hello world, czyli tak naprawdę sprawdzenie poprawności działania urządzenia. W tym odcinku kursu HMI wykonamy nieskomplikowany ekran wizualizacji z napisem "Hello world!".

System sterowania DMX512 dla każdego (2). Konfigurowanie urządzeń oraz okablowanie sieci

Numer: Lipiec/2016

W kolejnej części kursu obsługi urządzeń z interfejsem DMX512 zajmiemy się skonfigurowaniem urządzeń w sieci DMX512. Podamy też uwagi, które pozwolą na wykonanie poprawnego okablowania oraz uzyskanie wymaganego zasięgu transmisji danych. Jest to szczególnie ważne przy tworzeniu rozległych instalacji scenicznych.

Podstawy programowania STM32F746G-DISCO (3). Jak zbudować oscyloskop z FFT z użyciem STM32F746G-DISCO

Numer: Lipiec/2016

W ostatniej części artykułu poświęconego aplikacji próbkującej i wyświetlającej sygnał z wejścia liniowego zostaną omówione pakiet BSP, biblioteki graficzna STemWin, matematyczna ARM CMSIS DSP oraz moduł do wykrywania podstawowych gestów wykonanych przez użytkownika na panelu dotykowym.

Mobilna
Elektronika
Praktyczna

Elektronika Praktyczna

Sierpień 2017

PrenumerataePrenumerataKup w kiosku wysyłkowym

Elektronika Praktyczna Plus

lipiec - grudzień 2012

Kup w kiosku wysyłkowym