04.pdf

(1310 KB) Pobierz
Krok po kroku
Kursy EP
Pierwsze kroki z FPGA (4)
Szkoła MAXimatora
– monitorowanie pracy projektu
z użyciem debugera SignalTAP II
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.
Idea działania IP core o nazwie SignalTAP II przypomina
wkładany do  wnętrza FPGA rejestrator stanów logicz-
nych. 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ła-
sną 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 kon-
struktora 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.
Podczas realizacji projektów z wykorzystaniem Signal-
TAP II trzeba pamiętać, że  jest to  IP core implemento-
wany w FPGA, w związku z czym pochłania część zaso-
bów tego układu. Na 
rysunku  2
pokazano porównanie
wykorzystania zasobów przy implementacji samego licz-
nika 74169 (lewa strona rysunku 2) i przy implementacji
tego samego licznika z  dołączonym debugerem Signal-
TAP. Porównanie liczb może wywołać myśl, że  Signal-
TAP II jest bardzo zasobożerny (odnosząc do implemen-
tację 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 pre-
zentowanym przykładzie zadeklarowano 7 kanałów wej-
ściowych (z czego użyto 6) i głębokość pamięci 128 słów.
Przykład zastosowania debugera SignalTAP pokażemy
na  przykładzie znanego nam już licznika 74196, który
będzie taktowany sygnałem zegarowym 10 MHz (genera-
tor kwarcowy wbudowany na płytce MAXimator). Moni-
torować będziemy stany linii wyjściowych licznika,
a także poziomy sygnałów na jego wejściach. Wejście LD
Poprzednie części kursu i dodatkowe materiały dostępne są na FTP:
ftp://ep.com.pl,
user:
77642,
pass:
3220ppmm
114
ELEKTRONIKA PRAKTYCZNA 7/2016
Krok po kroku
Kursy EP
Rysunek 1. Schemat blokowy ilustrujący działanie sprzętowego debugera SignalTAP II
licznika spełnia w  przykładzie rolę wejścia zerującego,
posłuży nam ono w projekcie także do wyzwolenia reje-
stracji stanów linii przez SignalTAP II.
W wersjach Quartusa od 14.0 możliwe są dwie ścieżki
implementacji debugera SignalTAP II, zaczniemy od pre-
zentacji metody klasycznej, w  której ręcznie dodajemy
do schematu lub opisu HDL IP core debugera.
Implementację debugera SignalTAP II w  projek-
cie implementowanym w  FPGA należy przeprowa-
dzić po  jego kompilacji i  przypisaniu linii sygnało-
wych do  fizycznych wyprowadzeń układu. Zaczy-
namy od  wygenerowania sparametryzowanego IP core
Rysunek 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)
Poprzednie części kursu i dodatkowe materiały dostępne są na FTP:
ftp://ep.com.pl,
user:
77642,
pass:
3220ppmm
Rysunek 3. SignalTAP II jest dostępny w ramach bezpłatnych IP core w pakietach Quartus II i Quartus Prime
ELEKTRONIKA PRAKTYCZNA 7/2016
115
Krok po kroku
Kursy EP
Rysunek 4. Generację IP core debugera zaczynamy od nadania nazwy naszej mutacji SignalTAP II
Rysunek 5. Okno parametryzacji debugera SignalTAP II
Poprzednie części kursu i dodatkowe materiały dostępne są na FTP:
ftp://ep.com.pl,
user:
77642,
pass:
3220ppmm
Rysunek 6. Ustawienie w menedżerze projektu pozwa-
lające wyświetlić listę wszystkich plików w projekcie
Rysunek 7. W ten sposób generujemy symbol graficzny
dla wybranego pliku źródłowego
116
ELEKTRONIKA PRAKTYCZNA 7/2016
Krok po kroku
Kursy EP
Rysunek 8. Wygenerowany symbol graficzny – użyjemy go
na schemacie
debuggera SignalTAP II, co wymaga wybrania w katalogu
dostępnych IP core opcji
Library>Basic Functions>Si-
mulation, Debug and Verification>Debug and Performan-
ce>Altera SignalTap II Logic Analyzer
(rysunek 3). Spo-
woduje to uruchomienie generatora i parametryzatora IP
Rysunek 10. Menu, z którego wybieramy
plik zawierający opis konfiguracji debugera
core’ów (rysunek 
4),
w  którego pierwszym oknie poda-
jemy nazwę generowanego modułu (w  przykładzie jest
to TAP74169). Parametryzacja debugera w naszym przy-
kładzie ogranicza się do  podania liczby potrzebnych
wejść rejestrujących dane, w  przykładzie ich liczbę
nadmiarowo
usta-
lono 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ęk-
szyć lub zmniejszyć
jej pojemność (w  sek-
cji
Data
okna pokaza-
nego na  rysunku  5).
Nie będziemy teraz
korzystać z  pozosta-
łych, bardziej zaawan-
sowanych możliwości
Rysunek 9. Przykładowy schemat z zastosowanym symbolem debugera
Poprzednie części kursu i dodatkowe materiały dostępne są na FTP:
ftp://ep.com.pl,
user:
77642,
pass:
3220ppmm
Rysunek 11. Zakładka konfiguracyjna SignalTAP II
ELEKTRONIKA PRAKTYCZNA 7/2016
117
Krok po kroku
Kursy EP
Rysunek 12. Lista sygnałów monitorowanych w FPGA, które będą
wyświetlane w postaci przebiegów
parametryzacji, wrócimy do  ich prezentacji przy okazji
kolejnych odcinków kursu.
Po  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 pro-
jektu. Proces ten musimy wykonać ręcznie, co  wymaga
otwarcia pliku
TAP74169.qip
(znajduje on  się katalogu
sciezka_generacji_plikow-debugera\synthesis)
i  następ-
nie dodania go do  projektu (Project>Add
Current File
to  Project).
Po  wykonaniu tych czynności w  nawiga-
torze projektu (Project
Navigator
– 
rysunek  6)
wyświe-
tlamy wszystkie pliki wchodzące w skład projektu i roz-
wijamy 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.
Żeby położyć symbol debugera na  planszy sche-
matu postępujemy tak jak w  przypadku innych sym-
boli –  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 niekon-
sekwentnych 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 wyzwala-
jącej do testowanej części projektu. Odbywa się to w taki
sam sposób, jak w  przypadku rysowania schematu roz-
wiązania implementowanego w ramach projektu.
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ć ewentu-
alne błędy uniemożliwiające jego poprawną implemen-
tację. 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świe-
tlonym oknie, w sekcji
Verification/Debugging Files
(rysu-
nek  10),
wybieramy
SignalTap II Logic Analyzer File.
Okno analizatora pokazano na rysunku 11.
Konfigurację tej części projektu zaczynamy od  usta-
lenia listy monitorowanych sygnałów, co wymaga dwu-
krotnego 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 poka-
zano na rysunku 12. Wybieramy z listy interesujące nas
sygnały (w  przykładzie OUT3…OUT0 oraz nRES, przy
Poprzednie części kursu i dodatkowe materiały dostępne są na FTP:
ftp://ep.com.pl,
user:
77642,
pass:
3220ppmm
Rysunek 13. Zalecana do celów naszego kursu konfiguracja monitorowanych sygnałów
118
ELEKTRONIKA PRAKTYCZNA 7/2016

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin