Microsemi In-Circuit FPGA Debug

Informacje o produkcie

Specyfikacje

• Typ urządzenia: Microsemi SmartFusion2 SoC FPGA
• Data wydania: maj 2014
• Możliwości debugowania: debugowanie FPGA w układzie, wbudowany analizator logiczny
• Maksymalna częstotliwość przechwytywania danych: do 100MHz

Abstrakcyjny
Układy FPGA to potężne elementy konstrukcyjne systemów wbudowanych, które mają wiele zalet projektowychtages, ale te urządzenia mogą mieć złożone projekty ze złożonymi problemami projektowymi, które wymagają debugowania. Śledzenie problemów projektowych, takich jak błędy definicji, problemy z interakcją systemu i błędy czasowe systemu, może być wyzwaniem. Włączenie możliwości debugowania w układzie FPGA może radykalnie poprawić debugowanie sprzętu i uniknąć niezliczonych godzin frustracji. W tym artykule opisano kilka różnych podejść do debugowania w układzie FPGA, zidentyfikowano kluczowe kompromisy i poprzez exampProjekt, przeznaczony dla układu SoC FPGA Microsemi SmartFusion®2, pokaże, w jaki sposób nowe możliwości można wykorzystać do przyspieszenia debugowania i testowania.

Wstęp

FPGA to wszechobecne i potężne elementy projektowe, które obecnie można znaleźć w praktycznie każdym systemie wbudowanym. Wraz ze wzrostem pojemności, włączeniem złożonych bloków funkcjonalnych na chipie i zaawansowanych interfejsów szeregowych, urządzenia te mogą również mieć złożone problemy projektowe, które wymagają debugowania. Śledzenie problemów, takich jak błędy definicji funkcjonalnej (na poziomie FPGA lub systemu), problemy z interakcją systemu funkcjonalnego, problemy z synchronizacją systemu i problemy z wiernością sygnału między układami scalonymi (takie jak szum, przesłuch lub odbicia), staje się znacznie bardziej złożone w przypadku stosowania zaawansowanych FPGA. Symulacja jest z pewnością dużą pomocą w identyfikowaniu wielu problemów projektowych, ale wiele interakcji w świecie rzeczywistym nie pojawi się, dopóki projekt nie zostanie zaimplementowany sprzętowo. Opracowano kilka różnych technik debugowania złożonych problemów projektowych w celu uproszczenia procesu. Dokładne zrozumienie każdej z tych kluczowych technik, w tym różnych zaawansowanychtages i niekorzyśćtagjest przydatna przy rozważaniu, która technika lub kombinacja technik jest odpowiednia dla konkretnego projektu.
ByłyampProjekt FPGA, przeznaczony dla układu FPGA SoC Microsemi SmartFusion2, może posłużyć do zademonstrowania niektórych zaawansowanych funkcjitages i niekorzyśćtages tych standardowych technik, jak również najnowszych możliwości debugowania w układzie. Ten przykładowy przykładamppokażemy, w jaki sposób można wykorzystać te różne techniki do przyspieszenia identyfikacji i eliminowania problemów sprzętowych podczas debugowania sprzętu.

Dlaczego debugowanie FPGA jest kluczowym aspektem projektowania i rozwoju systemu?
FPGA mają dwa główne modele użytkowania, które odróżniają je od innych elementów projektowych. FPGA mogą być używane w produkcie produkcyjnym lub jako pojazd rozwojowy do sprawdzania lub prototypowania koncepcji projektu produkcyjnego. Gdy są używane jako pojazd produkcyjny, FPGA mogą być o wiele bardziej elastycznym celem niż pojazdy produkcyjne oparte na ASIC lub CPU. Jest to szczególnie ważne w przypadku nowego projektu, który nie został jeszcze zaimplementowany w sprzęcie. Projekty z różnymi opcjami architektonicznymi można łatwo tworzyć i testować, aby zidentyfikować optymalny projekt. FPGA z procesorami na chipie (SoC FPGA) umożliwiają również kompromis między przetwarzaniem opartym na CPU a funkcjami akceleracji opartymi na FPGA wspomaganymi sprzętowo. Te zaawansowanetagDzięki temu możliwe jest znaczne skrócenie czasu potrzebnego na projektowanie, walidację, testowanie i analizę usterek w przypadku nowych produktów.
W przypadku prototypowania projektu, być może produkcyjnego układu ASIC, elastyczność FPGA jest kluczową zaletą. Rzeczywista platforma sprzętowa, nawet taka, która nie działa z pełną prędkością, znacznie ułatwia uzyskanie szczegółowych metryk wydajności systemu, danych analizy przepustowości i wyników dowodu koncepcji architektury. Obsługa FPGA dla utwardzonych implementacji standardowych magistral przemysłowych (takich jak PCIe®, Gigabit Ethernet, XAUI, USB, CAN i inne) upraszcza testowanie związane z tymi interfejsami. Najnowsze rodziny układów FPGA z procesorami ARM na chipie (SoC FPGA) ułatwiają prototypowanie implementacji z wbudowanymi procesorami. Wcześniej opracowany kod procesora można przenieść do prototypu, a nowy kod utworzyć równolegle z wysiłkiem projektowania sprzętu.

Ta kombinacja standardowego procesora ze standardowymi magistralami interfejsu umożliwia wykorzystanie dużego ekosystemu dostępnych bibliotek kodu, sterowników, funkcjonalnych interfejsów API, systemów operacyjnych czasu rzeczywistego, a nawet pełnych systemów operacyjnych, aby znacznie szybciej stworzyć działający prototyp. Ponadto, gdy projekt zostanie utrwalony, prototyp FPGA może zostać użyty do przechwycenia rozległych zestawów testów symulacyjnych (zarówno dla bodźca, jak i odpowiedzi), które odzwierciedlają rzeczywiste dane systemowe. Te zestawy danych mogą być nieocenione przy tworzeniu ostatecznych symulacji dla ASIC lub innej implementacji produkcyjnej. ZaawansowanetagWykorzystanie układu FPGA jako prototypu projektu może znacznie skrócić czas projektowania, walidacji, testowania i analizy awarii na potrzeby wdrożenia finalnego produktu.
W obu tych typowych modelach zastosowań FPGA kluczową zaletą jest elastyczność FPGA jako celu projektowego.tage. Oznacza to, że wiele zmian i iteracji projektu byłoby normą, a zatem możliwość szybkiego debugowania błędów projektu byłaby kluczowa dla umożliwienia jak największej liczby opcji projektowych. Bez wydajnej możliwości debugowania wiele z zaawansowanychtage elastyczności projektu FPGA zostanie zmniejszona przez dodatkowy czas wymagany na debugowanie. Na szczęście FPGA mogą również zapewnić dodatkowe funkcje sprzętowe, które radykalnie upraszczają debugowanie w czasie rzeczywistym. Zanim przyjrzymy się tym możliwościom, przyjrzyjmy się najpierw najczęstszym typom problemów, z którymi może się zmierzyć projekt FPGA, abyśmy mieli odpowiednie podstawy do oceny wydajności i powiązanych kompromisów różnych narzędzi do debugowania.

Typowe problemy podczas debugowania projektów FPGA

Wraz z rozszerzonymi możliwościami, jakie oferują nowoczesne układy FPGA, związana z tym zwiększona złożoność utrudnia tworzenie projektów bezbłędnych. W rzeczywistości oszacowano, że debugowanie może zająć ponad 50% cyklu projektowania systemów wbudowanych. Ponieważ presja związana z czasem wprowadzania produktów na rynek nadal ogranicza cykl rozwoju, debugowanie sprzętowe początkowego systemu jest spychane na margines — zbyt często zakładając, że weryfikacja (sama w sobie stanowi duży procenttage harmonogramu rozwoju), wyłapie wszystkie błędy przed początkowym uruchomieniem systemu. Przyjrzyjmy się kilku typowym typom problemów systemowych, aby lepiej zrozumieć wyzwania, z którymi typowy projekt będzie musiał się zmierzyć podczas początkowego uruchomienia systemu.

Błędy w definicji funkcjonalnej mogą być podwójnie trudne do znalezienia, ponieważ projektant źle zrozumiał konkretne wymaganie, więc błąd może zostać przeoczony nawet po dokładnym przyjrzeniu się szczegółom projektu. Byłyample typowego błędu definicji funkcjonalnej to taki, w którym przejście maszyny stanowej nie kończy się we właściwym stanie. Błędy mogą również pojawiać się w interfejsach systemowych jako problem interakcji. Opóźnienie interfejsu, na przykładample, może być nieprawidłowo określony, co może skutkować nieoczekiwanym przepełnieniem bufora lub jego niedopełnieniem.
Problemy z synchronizacją na poziomie systemu są kolejnym bardzo powszechnym źródłem błędów projektowych. W szczególności zdarzenia asynchroniczne są powszechnym źródłem błędów, gdy efekty synchronizacji lub przekraczania domeny czasowej nie są starannie rozważane. Podczas pracy z dużą prędkością tego typu błędy mogą być bardzo problematyczne i mogą pojawiać się bardzo rzadko, być może tylko wtedy, gdy ujawniają się określone wzorce danych. Wiele powszechnych naruszeń synchronizacji mieści się w tej kategorii i zazwyczaj są bardzo trudne, jeśli nie niemożliwe do zasymulowania.

Naruszenia synchronizacji mogą być również wynikiem niskiej wierności sygnału między układami scalonymi, w szczególności w systemach z wieloma szynami zasilania dla każdego obwodu. Niska wierność sygnału może powodować szum sygnału, przesłuchy, odbicia, nadmierne obciążenie i problemy z zakłóceniami elektromagnetycznymi (EMI), które często objawiają się jako naruszenia synchronizacji. Problemy z zasilaniem, takie jak stany przejściowe (w szczególności podczas uruchamiania lub wyłączania systemu), wahania obciążenia i wysokie naprężenia rozpraszania mocy, mogą również powodować tajemnicze błędy, często niełatwe do wyśledzenia do źródła zasilania. Nawet jeśli projekt jest całkowicie poprawny, problemy z produkcją płytki mogą powodować błędy. Wadliwe połączenia lutowane i nieprawidłowo przymocowane złącza, na przykładample, może być źródłem błędów i może być nawet zależne od temperatury lub lokalizacji płytki. Zastosowanie zaawansowanych technik pakowania FPGA może utrudniać sondowanie sygnałów na płytce drukowanej, więc samo uzyskanie dostępu do pożądanego sygnału może być często problematyczne. Często wiele problemów projektowych nie powoduje natychmiastowego błędu i musi przechodzić przez projekt, aż błąd faktycznie się ujawni. Śledzenie początkowego błędu do przyczyny źródłowej może być często frustrującym, trudnym i czasochłonnym zadaniem.

Na przykładample, pojedynczy błędny bit w tabeli translacji może nie skutkować błędem aż do wielu cykli później. Niektóre z narzędzi, które omówimy później w tym dokumencie, które wykorzystują dedykowany sprzęt do debugowania w układzie, są specjalnie ukierunkowane na przyspieszenie i ułatwienie tych „polowań na błędy”. Zanim przejdziemy do szczegółów tych narzędzi, przyjrzyjmy się najpierw popularnej symulacji techniki debugowania opartej na oprogramowaniu, aby lepiej zrozumieć zaawansowanątages i niekorzyśćtagwykorzystania symulacji do debugowania.

Wykorzystanie symulacji do debugowania
Zazwyczaj w symulacji projektu wszystkie rzeczywiste komponenty wewnątrz i na zewnątrz projektu są modelowane matematycznie jako procesy oprogramowania, które są wykonywane sekwencyjnie na standardowym procesorze CPU. Zastosowanie szerokiego zakresu bodźców do projektu i sprawdzenie oczekiwanego wyniku w porównaniu z wynikami symulowanego projektu to łatwy sposób na wyłapanie najbardziej oczywistych błędów projektowych. Okno pokazujące typowy przebieg symulacji jest przedstawione na poniższym rysunku 1. Wyraźna zaawansowanatage symulacji w porównaniu ze sprzętowym debugowaniem polega na tym, że symulację można przeprowadzić w oprogramowaniu — nie jest potrzebny żaden rzeczywisty sprzętowy projekt ani stanowisko testowe. Symulacja może szybko wychwycić wiele błędów projektowych, w szczególności tych związanych z nieprawidłowymi specyfikacjami, niezrozumieniem wymagań interfejsu, błędami funkcji i wieloma innymi „poważnymi” typami błędów, które można łatwo wykryć za pomocą prostych wektorów bodźców.

Symulacja jest szczególnie skuteczna, gdy projektant ma dostęp do rozległych kombinacji bodźców, a uzyskane wyniki są dobrze znane. W takich przypadkach symulacja może przeprowadzić niemal wyczerpujący test projektu. Niestety, większość projektów nie ma łatwego dostępu do rozległych zestawów testowych, a proces ich tworzenia może być bardzo czasochłonny. Stworzenie zestawu testowego obejmującego 100% projektu jest praktycznie niemożliwe w przypadku dużych projektów opartych na FPGA, a w celu objęcia kluczowych elementów projektu należy stosować skróty. Inną trudnością związaną z symulacją jest to, że nie jest ona „realną” implementacją i nie może wychwycić zdarzeń asynchronicznych, szybkich interakcji systemowych ani naruszeń czasu. Wreszcie, proces symulacji może być bardzo powolny, a jeśli wymaganych jest wiele iteracji, symulacja szybko staje się najbardziej czasochłonną i często najkosztowniejszą częścią procesu rozwoju.

Jako alternatywę (lub może lepiej powiedzieć, jako dodatek do symulacji) projektanci FPGA odkryli, że mogą dodać sprzęt do debugowania do projektu FPGA, aby obserwować i kontrolować kluczowe sygnały w urządzeniu. Techniki te pierwotnie opracowano jako podejścia ad-hoc, ale stopniowo rozwinęły się w standardową strategię debugowania sprzętu. To wykorzystanie możliwości debugowania w układzie oferuje znaczne korzyścitagw projektach opartych na FPGA, a w następnej sekcji zostaną omówione trzy najpopularniejsze strategie i ich różne zalety.tages i niekorzyśćtagt.j.

Typowe podejścia do debugowania w układzie FPGA
Najczęściej stosowane techniki implementacji funkcji debugowania w układzie FPGA wykorzystują wbudowany analizator logiczny, zewnętrzny sprzęt testowy lub dedykowany sprzęt sondy sygnałowej wbudowany w strukturę FPGA. Wbudowany analizator logiczny jest zazwyczaj implementowany przy użyciu struktury FPGA i jest wstawiany do projektu. JTAG port służy do dostępu do analizatora, a przechwycone dane mogą być wyświetlane na komputerze. Gdy używany jest zewnętrzny sprzęt testowy, testowany projekt FPGA jest modyfikowany tak, aby wybrane wewnętrzne sygnały FPGA były kierowane do pinów wyjściowych. Te piny można następnie obserwować za pomocą zewnętrznego sprzętu testowego. Gdy używany jest dedykowany sprzęt sondy sygnałowej, szeroki wybór sygnałów wewnętrznych można odczytać w czasie rzeczywistym. Niektóre implementacje sondy mogą być nawet używane do zapisu w rejestrze lub lokalizacjach pamięci, co dodatkowo zwiększa możliwości debugowania. Przyjrzyjmy się bliżejtages i niekorzyśćtages każdej z tych technik, a następnie spójrz na byłegoample design, aby sprawdzić, jak różne podejścia mogą wpłynąć na całkowity czas debugowania.

Analizator logiki wbudowany w układ FPGA Debug
Koncepcja wbudowanego analizatora logicznego była bezpośrednim rezultatem możliwości doraźnego debugowania w układzie, które projektanci wdrożyli, gdy po raz pierwszy zastosowano układy FPGA. Wbudowane analizatory logiczne dodały nowe możliwości i wyeliminowały konieczność opracowania przez projektanta własnego analizatora. Większość układów FPGA oferuje te możliwości, a firmy zewnętrzne oferują standardowe analizatory (Identify® firmy Synopsys to jeden z popularnych example), który może łatwo łączyć się z narzędziami wyższego poziomu w celu dalszej poprawy produktywności.

Funkcjonalność analizatora logicznego jest wbudowana w projekt, wykorzystując strukturę FPGA i bloki pamięci wbudowanej jako bufory śladów, jak pokazano na rysunku 2. Tworzone są również zasoby wyzwalające, dzięki czemu złożone interakcje sygnałów można łatwo wybierać i przechwytywać. Dostęp do analizatora w celu sterowania i przesyłania danych odbywa się zazwyczaj za pośrednictwem standardowego JTAG port w celu uproszczenia wymagań interfejsu. Przechwycone dane można wyświetlić na komputerze za pomocą typowego viewoprogramowanie i zwykle odzwierciedla wynik przebiegu symulatora logicznego vieww dobrym stylu.

AwanstagW tym podejściu nie stosuje się żadnych dodatkowych pinów FPGA I/O, tylko standardowe JTAG sygnały. Rdzenie IP wbudowanego analizatora logicznego są zazwyczaj stosunkowo niedrogie i w niektórych przypadkach mogą być opcją dla istniejących narzędzi syntezy FPGA lub symulacji. W niektórych przypadkach wbudowany analizator logiczny może również zapewnić dodatkowe wyjścia na nieużywanych wejściach/wyjściach, jeśli jest to wygodniejsze. Jedną z wadtagW tym podejściu jest to, że wymagana jest duża ilość zasobów FPGA. W szczególności, jeśli używane są bufory śladowe, zmniejszy to liczbę dostępnych pamięci blokowych. Jeśli potrzebny jest szeroki bufor, będzie to również kompromisem w stosunku do głębokości pamięci (ponieważ użycie szerszej pamięci skutkuje płytszą głębokością pamięci) — dużą wadątage przy użyciu mniejszych urządzeń. Być może największą wadą tej techniki jest to, że za każdym razem, gdy wprowadzana jest zmiana położenia sondy, konieczne jest ponowne skompilowanie i przeprogramowanie projektu. Przy użyciu dużego urządzenia proces ten może zająć znaczną ilość czasu. Ze względu na sposób umieszczenia sond sygnałowych w projekcie, trudno jest skorelować zależności czasowe sygnału. Ponadto opóźnienia między sondami sygnałowymi nie są spójne, a zatem trudno jest porównywać zależności czasowe. Jest to szczególna trudność przy porównywaniu sygnałów asynchronicznych lub sygnałów z różnych domen czasu.

Debugowanie FPGA w układzie – zewnętrzny sprzęt testowy
Użycie kodu debugowania w układzie w połączeniu z zewnętrznym sprzętem testowym było naturalnym rozwiązaniem, gdy zewnętrzny analizator logiczny był już dostępny do testowania systemu. Tworząc prosty kod debugowania w celu identyfikacji i wyboru wewnętrznych sygnałów testowych i zastosowania ich do wejść/wyjść FPGA, jak pokazano na rysunku 3, można było wykorzystać zaawansowane możliwości analizatorów (takie jak duże bufory śladów, złożone sekwencje wyzwalania i wiele viewing options) do tworzenia prostych, ale wydajnych środowisk debugowania. Bardziej złożone możliwości w obwodzie dla zaawansowanych opcji wyzwalania mogą zminimalizować liczbę potrzebnych wyjść. Na przykładamptzn. wybieranie konkretnych adresów na szerokiej magistrali mogłoby być niemożliwe, gdyby wymagane były zewnętrzne piny.
Użycie wewnętrznej logiki FPGA drastycznie zmniejsza wymagania I/O i może nawet szukać określonych wzorców adresów (być może sekwencji wywołania i powrotu) do debugowania bardziej złożonych problemów. Jeśli dostępny jest wspólny interfejs użytkownika, może to uprościć krzywą uczenia się i poprawić produktywność.

AwanstagZaletą tego podejścia jest to, że wykorzystuje ono koszt zewnętrznego sprzętu testowego, a zatem nie ma dodatkowych kosztów narzędzi. Niektóre rdzenie IP obwodów debugowania są dostępne u producentów sprzętu lub producentów układów FPGA i mogą być bardzo tanie lub nawet bezpłatne. Ilość zasobów FPGA wymagana do wdrożenia logiki wyboru sygnału jest bardzo mała, a ponieważ funkcja śledzenia jest wykonywana przy użyciu zewnętrznego analizatora logicznego, nie są potrzebne żadne pamięci bloków. Ponieważ logika wyboru jest niedroga, można również obsługiwać dużą liczbę kanałów z szerokim wyzwalaniem. Analizator logiczny może działać zarówno w trybie czasowym, jak i w trybie stanu, co pomaga wyizolować niektóre problemy z czasem.
Niekorzyśćtages tego podejścia może obejmować konieczność zakupu analizatora logicznego, jeśli nie jest on już przydzielony do projektu. Ta wadatage może wystarczyć, aby zniechęcić do tego podejścia w wielu przypadkach. Należy jednak zauważyć, że niektóre niedrogie opcje analizatorów logicznych stają się dostępne, które wykorzystują komputer lub tablet do wyświetlania, co sprawia, że ​​ta opcja jest znacznie bardziej opłacalna w przypadku prostych wymagań debugowania.
Liczba zużywanych pinów FPGA może być kolejną wadątage i jeśli trzeba obserwować szerokie magistrale, konieczne jest znaczące planowanie układu płytki i dodanie złączy debugowania. Ten wymóg jest najczęściej trudny do przewidzenia na wczesnym etapie fazy projektowania i jest kolejną niepożądaną złożonością. Podobnie jak w przypadku podejścia z wbudowanym analizatorem logicznym, strategia testów zewnętrznych wymaga ponownej kompilacji i przeprogramowania projektu, gdy potrzebny jest każdy nowy eksperyment.

Wspólna wadatages tych dwóch technik — wykorzystanie zasobów na chipie (co może również wpłynąć na wydajność czasową projektu i stworzyć dodatkowe wymagania debugowania), konieczność ponownej kompilacji i przeprogramowania projektu (co może dodać godziny lub nawet dni do harmonogramu debugowania), wstępne planowanie wymagane do zidentyfikowania prawdopodobnych scenariuszy testowych oraz wykorzystanie dodatkowych zasobów wejścia/wyjścia chipa stworzyły potrzebę podejścia bez tych wad. Jedną z odpowiedzi było dodanie dedykowanej logiki debugowania do struktury FPGA w niektórych urządzeniach. Rezultatem było debugowanie w obwodzie przy użyciu sond sprzętowych.

Debugowanie FPGA w układzie – sondy sprzętowe
Użycie sond sprzętowych radykalnie upraszcza techniki debugowania w układzie FPGA. Ta technika zaimplementowana jako funkcja Live Probe w urządzeniach SmartFusion2®SoC FPGA i IGLOO®2 FPGA dodaje dedykowane linie sondy do struktury FPGA w celu obserwacji wyjścia dowolnego bitu rejestru elementu logicznego. Jak pokazano na schemacie blokowym na rysunku 4, sondy sprzętowe są dostępne w dwóch kanałach sondy A i B.

Wybrane wyjścia rejestrów (punkty sondy), takie jak te, które są podane na dole rysunku, są kierowane powyżej dwóch kanałów sondy i jeśli zostaną wybrane, mogą być stosowane do kanału A lub B. Te sygnały kanału w czasie rzeczywistym mogą być następnie wysyłane do dedykowanych pinów Probe A i Probe B na urządzeniu. Sygnały Probe A i Probe B mogą być również wewnętrznie kierowane do wbudowanego analizatora logicznego.

Należy zauważyć, że charakterystyki czasowe pinów sondy są regularne i mają pomijalne odchylenie od jednego punktu sondy do drugiego, co znacznie ułatwia porównywanie charakterystyk czasowych sygnałów w czasie rzeczywistym. Dane mogą być przechwytywane z częstotliwością do 100 MHz, co czyni je odpowiednimi dla większości projektów docelowych.
Być może najważniejsze jest to, że lokalizacje punktów sondy, ponieważ nie są one wybierane jako część zaimplementowanego projektu (są wybierane za pośrednictwem dedykowanego sprzętu, gdy projekt jest uruchomiony na FPGA), można szybko zmienić, po prostu wysyłając dane wyboru do urządzenia. Nie jest wymagana żadna rekompilacja ani przeprogramowanie projektu.
Aby jeszcze bardziej uprościć korzystanie z funkcji Live Probe, powiązane narzędzie oprogramowania do debugowania ma dostęp do wszystkich lokalizacji sygnałów sondy za pośrednictwem automatycznie generowanego pliku debugowania. file. Jak pokazano na Rysunku 5, nazwę sygnału można wybrać z listy sygnałów i zastosować do żądanego kanału. Można to zrobić nawet podczas działania projektu, dzięki czemu aktywność sondowania w projekcie jest płynna i bardzo wydajna.

W wielu przypadkach możliwości sondy sprzętowej, np. Live Probe, można stosować w połączeniu z opisanym wcześniej wbudowanym analizatorem logicznym i zewnętrznymi technikami testowania.

Jak pokazano na rysunku 6, funkcja Live Probe do wybierania sygnałów „w locie” umożliwia szybką i łatwą zmianę sygnałów pod obserwacją bez konieczności ponownej kompilacji projektu. Zewnętrzny analizator logiczny lub oscyloskop może łatwo obserwować sondowane sygnały, jak pokazano w prawym górnym rogu rysunku na dedykowanych pinach wyjściowych sondy. Alternatywnie (lub może nawet dodatkowo) wewnętrzny analizator logiczny (blok ILA Identify, pokazany na rysunku) może być używany do obserwacji pinów sondy. Sygnały sondy mogą być przechwytywane przez ILA i obserwowane w oknie przebiegu. Lokalizacje sondy można zmieniać bez konieczności ponownej kompilacji projektu docelowego.
Warto zauważyć, że dodatkowe możliwości wyzwalania i śledzenia można wykorzystać do rozszerzenia funkcjonalności sondy, dzięki czemu łatwiej będzie wykryć nawet złożone problemy projektowe.

Dodatkowe możliwości debugowania sprzętu są również dostępne w urządzeniach SmartFusion2 SoC FPGA i IGLOO2 FPGA. Jedna z tych możliwości, zwana Active Probe, może dynamicznie i asynchronicznie odczytywać lub zapisywać do dowolnego bitu rejestru elementu logicznego. Zapisana wartość jest zachowywana przez jeden cykl zegara, dzięki czemu normalna praca może być kontynuowana, co czyni ją bardzo cennym narzędziem do debugowania. Active Probe jest szczególnie interesujący, jeśli wymagana jest szybka obserwacja sygnału wewnętrznego (być może po prostu w celu sprawdzenia, czy jest aktywny lub w pożądanym stanie, jak sygnał resetu) lub jeśli istnieje potrzeba szybkiego przetestowania funkcji logicznej poprzez zapisanie do punktu sondy.
(być może w celu zainicjowania przejścia maszyny stanowej poprzez szybkie ustawienie wartości wejściowej, by wyizolować problem przepływu sterowania).

Inną funkcją debugowania udostępnianą przez Microsemi jest Memory Debug. Funkcja ta pozwala projektantowi dynamicznie i asynchronicznie odczytywać lub zapisywać do wybranego bloku SRAM FPGA. Jak pokazano na zrzucie ekranu narzędzia Debug Tool (rysunek 7), po wybraniu karty Memory Blocks użytkownik może wybrać żądaną pamięć do odczytu, wykonać migawkę pamięci, zmodyfikować wartości pamięci, a następnie zapisać wartości z powrotem do urządzenia. Może to być szczególnie przydatne do sprawdzania lub ustawiania buforów danych używanych w portach komunikacyjnych do obliczeń zorientowanych na zapis lub nawet do kodu wykonywanego przez wbudowany procesor. Debugowanie złożonych błędów zależnych od danych jest znacznie szybsze i łatwiejsze, gdy pamięci można obserwować i kontrolować tak szybko.

Po debugowaniu projektu może być pożądane wyłączenie możliwości debugowania sprzętu w celu ochrony poufnych informacji. Atakujący może użyć tych samych funkcji do odczytania krytycznych informacji lub zmiany ustawień systemu, co może umożliwić łatwy dostęp do poufnych części systemu. Microsemi dodał funkcje, które pozwalają projektantowi zabezpieczyć urządzenie po zakończeniu debugowania. Na przykładample, dostęp do Live Probe i Active Probe może zostać zablokowany, aby całkowicie wyłączyć funkcję jako możliwy środek ataku (eliminuje to nawet możliwość, że aktywność sondy tworzy jakiekolwiek wzorce w prądzie zasilania, które mogłyby zostać wykorzystane do próby pośredniej obserwacji danych sondy). Alternatywnie, dostęp do wybranych części projektu może zostać zablokowany, aby uniemożliwić dostęp tylko do tych sekcji. Może to być wygodne, jeśli tylko część projektu musi być bezpieczna, dzięki czemu reszta projektu będzie nadal dostępna do testowania w terenie lub analizy błędów.

Tabela porównawcza debugowania w układzie
Teraz, gdy szczegółowy review opisano trzy główne techniki debugowania sprzętu w układzie, a podsumowujący wykres, pokazany na rysunku 8, przedstawia szczegółowo różne zaawansowanetages i niekorzyśćtages każdej metody. Pamiętając, że niektóre techniki można stosować łącznie (Live Probe i Internal Logic Analyzer (ILA), np. Synopsys Identifyample), możemy zobaczyć kluczowe mocne i słabe strony każdej techniki. Zbiór możliwości debugowania sprzętu w obwodzie (Live Probe, Active Probe i Memory Debug — zbiorczo nazywane SmartDebug) jest najsłabszy w porównaniu z innymi technikami, jeśli chodzi o liczbę dostępnych sond (czerwone kółko) i jest słabszy od najlepszych (żółte kółko), jeśli weźmiemy pod uwagę szybkość przechwytywania (zewnętrzny sprzęt testowy może być szybszy).
Techniki oparte na ILA, takie jak Synopsys Identify, są najsłabsze w porównaniu z innymi technikami i gdy brane są pod uwagę wymagania dotyczące zasobów FPGA. Techniki oparte na zewnętrznym sprzęcie testowym są najsłabsze pod względem szeregu czynników, przy czym najbardziej uciążliwe są koszty, wpływ na czas projektowania i narzut ruchu sondy (z powodu konieczności ponownej kompilacji projektu). Być może optymalnym rozwiązaniem jest połączenie SmartDebug i jednej z innych technik, tak aby osłabić liczbę kanałów słabości SmartDebug i zmniejszyć wadę ruchu punktu sondy.tagRównież stosowanie innych technik uległo zmniejszeniu.

Klasyfikacje sygnałów
Można dokonać użytecznego rozróżnienia między niektórymi z najczęstszych typów sygnałów, co może pomóc w planowaniu podejścia do debugowania. Na przykładample, sygnały, które nie zmieniają się poza czasem rozruchu systemu, takie jak reset systemu, reset bloku lub rejestry inicjalizacji, można sklasyfikować jako sygnały statyczne. Do tych typów sygnałów można uzyskać najefektywniej dostęp za pomocą obiektu, który może łatwo obserwować i kontrolować sygnał, bez potrzeby długiego cyklu rekompilacji. Active Probe to doskonałe narzędzie do debugowania sygnałów statycznych. Podobnie sygnały, które zmieniają się częściej, ale są nadal statyczne przez zdecydowaną większość czasu, można sklasyfikować jako pseudostatyczne i są również najskuteczniej debugowane za pomocą Active Probe. Sygnały, które zmieniają się często, takie jak sygnały zegara, można sklasyfikować jako dynamiczne i nie są tak łatwo dostępne za pomocą Active Probe. Live Probe to lepszy wybór do obserwowania tych sygnałów.

Prosty przypadek użycia debugowania

Teraz, gdy lepiej rozumiemy różne opcje debugowania w układzie, przyjrzyjmy się prostemu przykładowi projektuample, aby zobaczyć, jak działają te techniki. Rysunek 9 przedstawia prosty projekt FPGA w urządzeniu FPGA SmartFusion2 SoC. Podsystem mikrokontrolera (MSS) jest resetowany przez blok CoreSF2Reset Soft IP. Wejściami tego bloku są Power On Reset, User Fabric Reset i External Reset. Wyjściami są reset User Fabric, reset MSS i reset M3. Objawy błędu to brak aktywności na wejściach/wyjściach, mimo że urządzenie pomyślnie wychodzi ze stanu POR. Na rysunku zilustrowano również trzy różne opcje debugowania tego błędu: Niebieskie pole (oznaczone jako ETE) dotyczy metody External Test Equipment; zielone pole (oznaczone jako ILA) dotyczy metody Internal Logic Analyzer; a pomarańczowe pole (oznaczone jako AP) dotyczy metody Active Probe. Założymy, że potencjalnymi przyczynami źródłowymi błędu są nieprawidłowo potwierdzone wejścia resetu do bloku CoreSF2Reset Soft IP.

Przyjrzyjmy się teraz procesowi debugowania dla trzech wcześniej opisanych metod wewnątrzukładowych.

Zewnętrzny sprzęt testowy
Stosując tę ​​metodę, zakłada się, że sprzęt testowy jest dostępny i nie jest używany przez projekt o wyższym priorytecie. Ponadto ważne jest, aby zaplanować z wyprzedzeniem, aby niektóre wejścia/wyjścia FPGA były dostępne i można je było łatwo podłączyć do sprzętu testowego. Posiadanie nagłówka na płytce drukowanej, np.ample, byłoby bardzo pomocne i zminimalizowałoby czas spędzony na próbie zidentyfikowania i połączenia z „prawdopodobnym podejrzanym” lub potencjalnym zwarciem pinów podczas sondowania. Projekt będzie musiał zostać skompilowany ponownie, aby wybrać sygnały, które chcemy zbadać. Miejmy nadzieję, że nie będziemy „obierać cebuli” i nie będziemy musieli wybierać dodatkowych sygnałów do dalszego badania, ponieważ często nasze początkowe badanie po prostu skutkuje większą liczbą pytań. W każdym razie proces ponownej kompilacji i przeprogramowania może zająć znaczną ilość czasu, a jeśli skutkuje naruszeniami czasowymi, wymagane jest przeprojektowanie (wszyscy wiemy, jak frustrujące mogą być próby rozwiązania problemów z zamknięciem czasowym, w szczególności, gdy wprowadzasz zmiany w projekcie, aby znaleźć błąd projektowy — cały proces może trwać od minut do godzin)! Ważne jest również, aby pamiętać, że jeśli projekt nie ma wolnych wejść/wyjść użytkownika, tej metody nie można zaimplementować. Co więcej, ta metoda jest strukturalnie inwazyjna dla projektu — a błędy związane z czasem mogą zniknąć lub pojawić się ponownie między iteracjami.

Wewnętrzny analizator logiczny
Używając tej metody ILA musi zostać wstawiony do projektu przy użyciu zasobów struktury, a następnie musi zostać skompilowany ponownie. Należy zauważyć, że jeśli ILA został już utworzony, sygnały, które chcemy zbadać, mogły nie zostać zinstrumentowane, co również wymagałoby ponownej kompilacji. Ten proces grozi zmianą oryginalnego projektu i naruszeniem ograniczeń czasowych. Jeśli czas zostanie spełniony, projekt musi zostać przeprogramowany i ponownie zainicjowany. Cały ten proces może zająć kilka minut lub nawet godzin, jeśli czasy ponownej kompilacji są długie i wymagane są wielokrotne przejścia. To podejście jest strukturalnie inwazyjne i może powodować podobne problemy do tych opisanych przy użyciu powyższej metody.

Aktywna sonda
Używając tej metody, Aktywna Sonda może być wskazana na źródło różnych sygnałów resetowania, z których wszystkie pochodzą z wyjść rejestrów (co jest powszechne w każdej dobrej praktyce projektowania cyfrowego). Sygnały są wybierane pojedynczo z menu Aktywnej Sonda pokazanego na Rysunku 10 poniżej. Wybrane wartości sygnału można odczytać i wyświetlić w oknie danych Aktywnej Sonda. Wszelkie błędne potwierdzenia są łatwo identyfikowane. Ten test można wykonać natychmiast, bez konieczności ponownej kompilacji i przeprogramowania urządzenia, i nie jest on strukturalnie ani proceduralnie inwazyjny. Cały proces trwa zaledwie kilka sekund. Ta metoda może również tworzyć sterowalność (asynchroniczne zmienianie wartości), na co nie pozwalają dwie pozostałe metody. W tym konkretnym przypadkuampsygnał resetu pochodzący z rejestru można łatwo zbadać i odkryć, że jest on utrzymywany w stanie aktywnym.

Chwilowe przełączenie sygnału resetu można uzyskać poprzez asynchroniczną manipulację rejestrem generującym sygnały spoczynku.

Bardziej złożony przypadek użycia debugowania
Powyższy projekt jest bardzo prosty i stanowi użyteczne wprowadzenie do stosowania opisanych technik projektowania, ale bardziej złożony projektample może być jeszcze bardziej ilustratywne. Często sygnał zainteresowania nie jest sygnałem statycznym, jak w naszym prostym example but jest dynamiczny. Typowym sygnałem dynamicznym jest zegar pośredni, być może używany do pomiaru czasu uzgadniania dla interfejsu szeregowego. Rysunek 11 przedstawia taki projekt z rdzeniem Soft IP użytkownika, w tym przypadku niestandardowym interfejsem szeregowym podłączonym do magistrali APB systemu. Objawy błędów są takie, że nie ma żadnej aktywności na niestandardowym interfejsie szeregowym użytkownika i że gdy master magistrali APB wydaje transakcję w celu uzyskania dostępu do interfejsu szeregowego, przechodzi w stan wyjątku wskazujący na nieprawidłowe uzgadnianie. Warunki te wydają się wykluczać przyczynę statyczną, taką jak nieprawidłowy sygnał resetu, ponieważ maszyna stanu transakcji wydaje się nie działać z oczekiwaną szybkością, co powoduje wyjątek. Uważa się, że przyczyną główną jest generator częstotliwości zegara w rdzeniu IP użytkownika.

Jeżeli nie pracuje z właściwą częstotliwością, mogą wystąpić opisane błędy.

W tej sytuacji prawdopodobnie lepszą strategią jest zastąpienie podejścia Active Probe podejściem Live Probe. Jest to zilustrowane na powyższym rysunku pomarańczowym polem LP, przy użyciu JTAG sygnał do wyboru źródła sondy.

Zewnętrzny sprzęt testowy
W tym przypadku metodologia jest bardzo podobna do opisanej wcześniej prostej metodyample. Sygnał zegara użytkownika jest doprowadzany do punktu testowego (miejmy nadzieję, że na nagłówku) i wymagana jest czasochłonna rekompilacja. Pomocne może być również doprowadzenie sygnału odniesienia, być może zegara systemowego, który jest używany do taktowania IP użytkownika jako sygnału porównawczego. Ponownie będziemy musieli dokonać ponownej kompilacji i przeprogramowania, więc cały proces może zająć znaczną ilość czasu.

Wewnętrzny analizator logiczny
Ten przypadek jest bardzo podobny do prostego przypadkuample. ILA musi zostać wstawiony lub zdefiniowany żądany sygnał, a także wykonany cykl ponownej kompilacji i ponownego programowania. Wszystkie wcześniej opisane problemy nadal skutkują znacznym czasem cyklu debugowania. Istnieje jednak dodatkowa złożoność. Zegar sterujący ILA musi być synchroniczny, a w idealnym przypadku znacznie szybszy w stosunku do zegara obserwowanego z rdzenia Soft IP użytkownika. Jeśli te zegary są asynchroniczne lub nie mają prawidłowych relacji czasowych, przechwytywanie danych będzie nieprzewidywalne i może być źródłem zamieszania w procesie debugowania.
Należy pamiętać, że jeśli zegar Soft IP użytkownika nie jest generowany na układzie scalonym (być może jest odzyskiwany z interfejsu szeregowego), projektant może musieć dodać moduł zegara w celu generowania szybszego zegara ILA, wykorzystując dodatkowe zasoby, co może prowadzić do naruszenia synchronizacji.

Sonda na żywo
Używając tej metody, Live Probe może być szybko skierowany na źródło zegara użytkownika i dowolne inne źródło zegara z rejestru, aby wyśledzić przyczynę błędu. Live Probe pokaże wybrane wyjścia sygnału w czasie rzeczywistym, a wszelkie relacje czasowe między sygnałami są zatem znacznie łatwiejsze do ustalenia. Cały proces zajmuje zaledwie kilka sekund.

Inne funkcje debugowania dla interfejsów szeregowych
Ważne jest również podkreślenie, że w urządzeniach SmartFusion2 SoC FPGA i IGLOO2 FPGA dostępnych jest wiele dodatkowych możliwości debugowania, których można używać w interfejsach szeregowych, takich jak w poprzednim przykładzie.ampprojekt, w którym błędy są jeszcze bardziej skomplikowane. SERDES Debug, na przykładample, zapewnia określone możliwości debugowania dla dedykowanych szybkich interfejsów szeregowych. Niektóre z funkcji debugowania SERDES obejmują obsługę testów PMA (takich jak generowanie wzorców PRBS i testowanie pętli zwrotnej), obsługę wielu konfiguracji testów SERDES z rekonfiguracją na poziomie rejestru, aby uniknąć użycia pełnego przepływu projektu do wprowadzania zmian konfiguracji, a także raporty tekstowe pokazujące skonfigurowane protokoły, rejestry konfiguracji SERDES i rejestry konfiguracji Lane. Te funkcje znacznie ułatwiają debugowanie SERDES i mogą być używane w połączeniu z Live Probe i Active Probe w celu dalszego przyspieszenia debugowania złożonych obwodów.
Opisane wcześniej narzędzie Memory Debug można również używać w połączeniu z SERDES Debug w celu przyspieszenia testowania. Ponieważ bufory pamięci można szybko i łatwo sprawdzać i zmieniać za pomocą Memory Debug, możliwe jest szybkie tworzenie „pakietów testowych” i obserwowanie wyników pętli zwrotnej lub komunikacji międzysystemowej. Projektant może wykorzystać te możliwości, a tym samym zminimalizować potrzebę specjalistycznych „uprząży testowych”, które zużywają dodatkową strukturę FPGA i mogą mieć wpływ na taktowanie układu.

Wniosek
W tym artykule szczegółowo opisano kilka różnych podejść do implementacji debugowania w układzie FPGA i SoC FPGA — użycie zintegrowanego analizatora logicznego, użycie zewnętrznego sprzętu testowego i użycie dedykowanych obwodów sondy zintegrowanych z strukturą FPGA. Wykazano, że dodanie wyspecjalizowanych i dedykowanych obwodów sondy, takich jak Active Probe i Live Probe oferowanych przez Microsemi w urządzeniach SmartFusion2 SoC FPGA i IGLOO2 FPGA, znacznie przyspiesza i upraszcza proces debugowania. Możliwość szybkiej modyfikacji wyboru sygnałów wewnętrznych (bez konieczności wykonywania bardzo czasochłonnego cyklu ponownej kompilacji i ponownego programowania) oraz możliwość sondowania sygnałów wewnętrznych (bez konieczności używania struktury FPGA i potencjalnego wprowadzania naruszeń czasowych) okazały się głównymi zaletamitages podczas debugowania projektów FPGA. Ponadto opisano wykorzystanie wielu metodologii, które mogą ze sobą współpracować, aby zapewnić jeszcze bardziej wszechstronne możliwości debugowania. Na koniec dwa exampAby zilustrować kompromisy pomiędzy opisanymi metodami, podano przypadki użycia debugowania.

Aby dowiedzieć się więcej

1. FPGA IGLOO2
2. Układy FPGA SoC SmartFusion2

Microsemi Corporation (Nasdaq: MSCC) oferuje kompleksową gamę rozwiązań półprzewodnikowych i systemowych dla rynków komunikacyjnych, obronnych i bezpieczeństwa, lotniczego i przemysłowego. Produkty obejmują wysokowydajne, odporne na promieniowanie analogowe układy scalone o mieszanym sygnale, układy FPGA, SoC i ASIC; produkty do zarządzania energią; urządzenia do pomiaru czasu i synchronizacji oraz precyzyjne rozwiązania czasowe, wyznaczające światowy standard czasu; urządzenia do przetwarzania głosu; Rozwiązania RF; elementy dyskretne; technologie bezpieczeństwa i skalowalna ochrona przed tamper produktów; Power-over-Ethernet ICs i midspans; a także możliwości projektowania na zamówienie i usługi. Siedziba główna Microsemi znajduje się w Aliso Viejo w Kalifornii i zatrudnia około 3,400 pracowników na całym świecie. Dowiedz się więcej na www.microsemi.com.

© 2014 Microsemi Corporation. Wszelkie prawa zastrzeżone. Microsemi i logo Microsemi są znakami towarowymi firmy Microsemi Corporation. Wszystkie inne znaki towarowe i znaki usługowe są własnością ich odpowiednich właścicieli.

Siedziba firmy Microsemi

• Jeden Przedsiębiorstwo, Aliso Viejo CA 92656 USA
• W Stany Zjednoczone: +1 800-713-4113
• Poza Stany Zjednoczone: +1 949-380-6100
• Obroty: +1 949-380-6136
• Faks: +1 949-215-4996
• E-mail: sales.support@microsemi.com

Często zadawane pytania

• P: Jaka jest maksymalna częstotliwość przechwytywania danych przez urządzenie?
  A: Urządzenie obsługuje przechwytywanie danych z częstotliwością do 100 MHz, co jest odpowiednie dla większości projektów docelowych.
• P: Czy muszę ponownie kompilować projekt, jeśli do debugowania używam obwodów sondowych?
  O: Nie, lokalizację punktów pomiarowych można szybko zmienić bez konieczności ponownej kompilacji lub przeprogramowania projektu.

Dokumenty / Zasoby

Microsemi In-Circuit FPGA Debug [plik PDF] Instrukcje Debugowanie FPGA w układzie, Debugowanie FPGA, Debugowanie

Odniesienia

• Instrukcja obsługi