Krzysztof Firlg
Politechnika Warszawska, Wydzia Transportu
TESTOWANIE SPECJALIZOWANYCH URZDZE
STEROWANIA RUCHEM DROGOWYM
W STRUKTURACH FPGA
Rkopis dostarczono, kwiecie 2013
Streszczenie: Urzdzenia sterowania ruchem drogowym, ze wzgldu na ich zoono oraz wan
rol jak peni, a take wymagan du niezawodno , musz by testowane na kadym etapie ich tworzenia. Zastosowanie ukadów FPGA w urzdzeniach srd, pozwala na zwikszenie wydajnoci i niezawodnoci tych ukadów, jednak wymaga wykorzystania nowoczesnych narzdzi i metod testowania tych urzdze.
Przedstawiono zoony proces powstawania urzdze sterowania ruchem drogowym w strukturach FPGA. Dla poszczególnych etapów tego procesu zosta przedstawiony i przeanalizowany problem wystpowania i wykrywania bdów dziaania. Rozpatrzono bdy wynikajce z bdnej specyfikacji, bdnej realizacji ukadu oraz bdy powstae w wyniku uszkodzenia realizacji.
Przedstawiono opracowan metod testowania modeli specjalizowanych urzdze sterowania ruchem, pozwalajc wykry bdy specyfikacji urzdze zaprojektowanych w jzyku VHDL i zrealizowanych w ukadach FPGA.
Sowa kluczowe: urzdzenia sterowania ruchem, ukady programowalne, testowanie
1. WSTP
Podstawowym elementem systemu sterowania ruchem, realizujcym sterowanie na najniszym poziomie systemu jest sterownik lokalny ruchu drogowego. Sterownik lokalny jak kade urzdzenie sterujce realizuje zaoony algorytm sterowania ruchem.
Pierwsze realizacje sterowników ruchu drogowego bazoway na rozwizaniach mechanicznych i elektromechanicznych. Wraz z rozwojem elektroniki wprowadzono rozwizania sterowników elektronicznych jako platformy sprztowe z ukadów maej i redniej skali integracji, nastpnie zaczto realizowa sterowniki na platformach programowych z ukadów wielkiej skali integracji, jako rozwizania mikroprocesorowe [3]. Wspóczenie stosowane rozwizania programowe (mikroprocesorowe) sterowników charakteryzuj si koniecznoci stosowania oprogramowania uytkowego i sekwencyjnoci realizacji algorytmów sterowania i przetwarzania danych, ze wszystkimi wynikajcymi z tego faktu konsekwencjami.
Sterownik lokalny realizujc adaptacyjny algorytm sterowania wykorzystuje dane o procesie ruchu. Wymaga to stosowania czujników ruchu, detektorów i wideodetektorów, których obsuga w czasie rzeczywistym wymusza due prdkoci przetwarzania i znaczne zasoby logiczne urzdze. Ograniczenia obecnych rozwiza programowych s pokonywane poprzez stosowanie rozwiza wieloprocesorowych, albo sprztow realizacj wyodrbnionych algorytmów.
Rozwizaniem, zwikszajcym prdko przetwarzania sterowników, jest powrót do sprztowych realizacji urzdze sterowania ruchem. Sprztowe rozwizania uwaane s za wielokrotnie szybsze od rozwiza programowych, poniewa umoliwiaj przetwarzanie danych w wielu równolegych procesach. Jednoczenie projektowanie systemów cyfrowych polegajce na budowie systemów z wielu odrbnych, standardowych ukadów wielkiej skali integracji, uzupenianych elementami maej i redniej skali integracji, zastpiono specjalizowanymi ukadami wytwarzanymi przez producenta na zamówienie uytkownika. Ukady specjalizowane ASIC (Application Specific Integrated Circuit) s to ukady cyfrowe dedykowane do cile okrelonego zastosowania, gdzie cay, nieraz bardzo zoony system cyfrowy moe mieci si w jednym ukadzie scalonym. Niestety, chocia ukady charakteryzuj si du prdkoci i wydajnoci, to problemem jest ich uniwersalno , gdy zmiana struktury takiego ukadu nie jest moliwa. Koszt tych rozwiza sprawia, e tylko wielkoseryjna produkcja jest opacalna.
Ewolucj ukadów ASIC byy ukady cyfrowe programowalne przez uytkownika PLD (Programmable Logic Device) [4], umoliwiajce, po zaprogramowaniu, realizacj dowolnego ukadu cyfrowego. Pojcie programowalnych elementów logicznych PLD obejmuje szereg ukadów produkowanych w rónorodnych odmianach. Nale do nich ukady zawierajce od kilkudziesiciu do kilku tysicy bramek. Dostpne narzdzia projektowe i metody projektowania sprawiaj, e opacalna staje si realizacja pojedynczych urzdze w oparciu o ukady programowalne, gdzie proces projektowy i realizacja urzdzenia moe przebiega „na biurku”. Dodatkowe moliwoci stwarzaj ukady reprogramowalne, umoliwiajce wielokrotn zmian struktury wewntrznej.
Obecnie du popularno zyskay ukady reprogramowalne FPGA (Field Programmable Gate Array), bdce jednym z rodzajów ukadów PLD, charakteryzujce si prostoktn macierz bloków logicznych, rozmieszczonych pomidzy tzw. kanaami poczeniowymi. Zasoby ukadów FPGA sigajce milionów bramek logicznych i tysicy wyprowadze powoduj, e moliwa staje si realizacja rozbudowanych systemów sterowania wewntrz jednego ukadu scalonego w technice SoC (System On Chip).
Przez dugi czas testowanie ukadów cyfrowych traktowane byo jako zadanie podrzdne w stosunku do projektowania i wytwarzania. Obecnie w epoce systemów wymagajcych duej niezawodnoci dziaania, jak systemy sterowania ruchem, jako testowania i zwizane z ni prawdopodobiestwo poprawnej pracy ukadu stao si kluczowym zagadnieniem. Niepoprawne dziaanie ukadu cyfrowego moe by wynikiem bdów projektowania lub niedoskonaoci procesu wytwarzania. Uszkodzenia mog take powsta w czasie uytkowania ukadu.
Testowanie nowoczesnych ukadów scalonych stwarza powane problemy wynikajce std, e klasyczne procedury testowania, opracowane dla ukadów maej i redniej skali integracji, staj si zawodne dla ukadów duej skali integracji. W artykule przedstawione zostan zagadnienia weryfikacji i testowania specjalizowanych sterowników ruchu drogowego projektowanych i realizowanych w ukadach programowalnych FPGA.
2. WERYFIKACJA I TESTOWANIE CYFROWYCH
URZDZE STEROWANIA
2.1. PRZYCZYNY POWSTAWANIA BDÓW
Projektowanie i realizacja urzdze sterowania ruchem drogowym w ukadach programowalnych FPGA, jak równie innych cyfrowych urzdze sterowania, jest procesem wieloetapowym. W pierwszym etapie projektant zapisuje swoje wyobraenia o urzdzeniu. Odbywa si to w formie schematów logicznych, sieci dziaa (algorytmu pracy urzdzenia) lub w formie jzyków opisu sprztu np.: VHDL (Very High Speed Integrated Circuits Hardware Description Language). W drugim etapie nastpuje synteza i implementacja projektu w postaci prototypu, nastpnie urzdzenie trafia na lini produkcyjn gdzie jest wytwarzane. Proces ten przedstawia rysunek 1.
Opis dziaania ukadu
(Algorytm sterowania) Specyfikacja (VHDL, FSM, BDE) weryfikacja Synteza Realizacja, implementacja testowanie
Badanie prototypu ukadu
Produkcja urzdzenia N T N T N T testowanie Weryfikacja (testowanie) oprogramowania Bdy specyfikacji Testowanie sprztu
Bdy i uszkodzenia realizacji
Diagnostyka Bdna specyfikacja Bdna realizacja Uszkodzenia realizacji
Rys. 1. Etapy procesu powstawania urzdze cyfrowych
Powstae w ten sposób urzdzenie moe nie speni postawionych mu wymaga. Przyczyny tego mog by róne, zwykle przedstawia si je, jako [5]:
– bdna specyfikacja – rozbienoci pomidzy dziaaniem wyspecyfikowanego urzdzenia a zaoeniami, wedug których miao dziaa ;
– bdna realizacja ukadu – wynika ze zej dokumentacji, bdnej implementacji; – uszkodzenia realizacji – niewaciwe prowadzenie procesu technologicznego,
wadliwe podzespoy.
Uszkodzenia mog te powsta w czasie uytkowania ukadu na skutek naturalnego procesu starzenia lub niekorzystnej zmiany warunków zewntrznych. W celu wyeliminowania wymienionych bdów konieczna jest ciga weryfikacja i testowanie urzdze cyfrowych na kadym etapie ich wytwarzania, oraz diagnostyka w czasie uytkowania urzdze.
2.2. WERYFIKACJA NA ETAPIE SPECYFIKACJI
Bdy na etapie specyfikacji obejmuj rozbienoci pomidzy dziaaniem wyspecyfikowanego urzdzenia a zaoeniami, wedug których miao dziaa , czyli bdy w algorytmie dziaania urzdzenia, pomyki projektanta, pomyki programisty, bdy w kodzie opisujcym dziaanie ukadu. Bdy te mog by weryfikowane bezporednio na poziomie systemu CAD (Computer Aided Design), w którym nastpia specyfikacja.
Poniewa urzdzenia realizowane w ukadach FPGA specyfikowane s w jzykach opisu sprztu, na etapie specyfikacji mamy do czynienia z programem napisanym np.: w jzyku VHDL, który moemy traktowa analogicznie do jzyków programowania i do weryfikacji bdów specyfikacji wykorzystywa metody testowania oprogramowania.
Weryfikacja bdów procesu specyfikacji kodu VHDL rozpoczyna si ju podczas kompilacji, gdzie badana jest poprawno skadniowa i semantyczna programu.
Do weryfikacji kodu ukadu wykorzystuje si dwie gówne strategie testowania [6]: – testowanie (weryfikacj) oparte na funkcji programu (testowanie funkcjonalne); – testowanie (weryfikacj) oparte na strukturze programu (testowanie
strukturalne).
W weryfikacji funkcjonalnej przypadki testowe s dobierane na postawie sformuowania samego zadania, czyli zaoe projektanta, co do dziaania ukadu. Bada si wszystkie funkcje, jakie powinien realizowa ukad. Pena weryfikacja moe prowadzi do testów wyczerpujcych, np.: pokrywajcych pen przestrze danych wejciowych. W praktyce liczba sytuacji, które mog zaistnie w sterowanym obszarze przekracza moliwo wykonania penych testów. Std istotne jest wykorzystywanie do tego celu metod systematycznych.
Celem weryfikacji strukturalnej jest cakowite pokrycie struktury testowanego programu przez wybrane przypadki testowe. Struktura programu skada si z instrukcji, których wykonanie powinno ujawni bdy. O tym, które instrukcje i w jakiej kolejnoci s wykonane decyduj instrukcje sterujce, reprezentowane na grafach sterowania, jako rozgazienia, natomiast w kodzie VHDL widoczne, jako instrukcje: if, case, itp. Program powinien by weryfikowany tak dugo, a kade rozgazienie wynikajce z grafu sterowania zostanie wykonane, chocia raz. Spenienie tego kryterium gwarantuje wykonanie kadej osigalnej instrukcji programu.
Aby nieco zmniejszy liczb moliwych przypadków testowych stosuje si zasad warunków brzegowych, tzn. zasad, e jeeli kod dziaa poprawnie dla warunków skrajnych, to na pewno bdzie te dziaa dobrze w warunkach normalnych.
Specyfikacja ukadów sterowania ruchem drogowym w jzyku VHDL wymaga realizacji ukadów wielomoduowych. Ukady specyfikuje si zwykle na wielu poziomach, zaczynajc od podstawowych elementarnych moduów, nastpnie czc te moduy w wiksz cao . Mona wyróni trzy metody weryfikacji tak wyspecyfikowanych ukadów:
– weryfikacja wstpujca; – weryfikacja zstpujca;
– weryfikacja podstawowych moduów, nastpnie ich jednoczesne scalenie i weryfikacja ukadu finalnego.
Niezalenie od strategii i metody weryfikacji, procesy te s bardzo czasochonne i pracochonne. Niezbdna jest pewna ich automatyzacja. Niestety cakowita automatyzacja procesu weryfikacji jest nie moliwa. W rodowiskach opartych na VHDL automatyzuje si proces weryfikacji i testowania poprzez tworzenie automatycznych rodowisk testowych (Test Bench). S to niesyntezowalne moduy, sterujce moduem syntezowanym, umoliwiajce jego symulacj. rodowisko takie definiuje przebiegi sygnaów pobudzajcych okrelone porty i powinno by pisane przez programist ju na etapie specyfikacji kodu ukadu. Gówne zadania moduów testowych to generacja i podawanie wymusze oraz porównywanie odpowiedzi z wzorcem.
Jako ocen jakoci procesu weryfikacji i testowania wykorzystuje si analiz pokrycia testów. Dla potrzeb tej analizy wprowadza si odpowiednie miary [6]. Miary te wie si z wasnociami strukturalnymi kodu VHDL. Pokrycie bdów jest miar bezporednio okrelajc liczb wykrytych bdów przez opracowany przypadek testowy. Dobre testy powinny charakteryzowa si duym pokryciem przepywu danych i sterowania. W przypadku analizy pokrycia strukturalnego, podstawowymi miarami z tego zakresu s: pokrycie instrukcji; pokrycie bloków; pokrycie decyzji; pokrycie warunków.
2.3. BDY I USZKODZENIA REALIZACJI URZDZE
W UKADACH FPGA
Bdy oraz uszkodzenia realizacji, powstajce podczas wytwarzania ukadu wskutek niedoskonaoci procesów technologicznych, bdów operatorskich oraz uszkodzenia powstae w czasie uytkowania ukadu mona wykry poprzez testowanie prototypu urzdzenia. Testowanie na tym etapie moe by przeprowadzone na poziomie pakietu oprogramowania integrujcego w sobie narzdzia specyfikacji, implementacji i wspópracujcego z prototypem urzdzenia, lub za pomoc systemów automatycznego testowania ATE (Automated Test Equipment).
2.3.1. Techniki testowania ukadów programowalnych
Wspóczesne programowalne struktury logiczne mona podzieli na ukady [4]:
– ASIC – ukady zamawiane bd projektowane przez uytkownika, programowane przez producenta;
– CPLD1/FPGA – ukady projektowane i programowane przez uytkownika. Zalenie od typów ukadów testowanie ich mona podzieli na dwa rodzaje:
– testowanie wszystkich komórek ukadu i wszystkich pocze; – testowanie logiki uytej do realizacji funkcji ukadu.
Pierwsze testowanie odnosi si do ukadów ASIC i nie zaprogramowanych ukadów CPLD i FPGA. Testowanie to ma na celu wykrycie uszkodze struktury ukadu. Wymaga znajomoci modelu bdów testowanego ukadu i specjalistycznych narzdzi. Testowaniu
1
Complex PLD – zoone programowalne ukady logiczne, charakteryzujce si programowaln matryc pocze otoczon makrokomórkami
temu ukady poddawane s gównie u producenta (test produkcyjny). Drugi rodzaj testowania odnosi si do zaprogramowanego ukadu FPGA. Polega on na testowaniu zaprogramowanej logiki dziaania ukadu (funkcji uytkownika). Technika ta zwykle wykorzystuje ide samotestowania.
Techniki testowania ukadów programowalnych moemy podzieli na [8]:
– zewntrzne techniki, gdzie dla danego modelu uszkodze, odpowiednio opracowana sekwencja wektorów testowych, podawana jest z zewntrznego generatora testów ATE;
– wewntrzne techniki testowania, wykorzystujce wbudowane elementy testowe BIST (Built-In Self-Test) – wbudowane autotestowanie. Ta technika w przypadku ukadów FPGA moe by rozszerzona o moliwo wykorzystania jako elementy struktury BIST niewykorzystanych zasobów logicznych ukadu, lub te moliwa jest dekompozycja ukadu, i testowania w kilku sesjach bloków logicznych, z tymczasowym umieszczaniem elementów BIST w miejscu aktualnie nie testowanych zasobów.
2.3.2. Modele bdów ukadów FPGA
Poza klasycznymi modelami bdów skleje (Stuck-At) i zwar (Wired), w ukadach FPGA wystpuj bdy charakterystyczne dla ukadów programowalnych [2]:
– bdy struktury FPGA – bdy pocze, bdy typu skleje, cakowite rozczenie lub zwarcie pary pocze (rys. 2a);
– bdy komórek CLB2 – bdy multiplekserów, przerzutników D (rys. 2b); – bdy komórek LUT3 – bdy pamici, bdy dekodera (rys. 2b).
a) CLB CLB CLB CLB CLB CLB CLB CLB CLB
IOB IOB IOB IOB
IOB IOB IOB IOB
IO B IO B IO B IO B IO B IO B IO B IO B b) LUT D > Q CLB Dekoder adresowy LUT Pami 0 1 1 0 0 1 0 1
Rys. 2. Budowa ukadu FPGA: a) architektura ukadu, b) struktury komórek CLB i LUT
Ponadto, poza bdami statycznymi, wystpuj bdy dynamiczne, których efekty mog ujawnia si przy zmianach sygnaów wejciowych np.: bdy opó nieniowe (modele bramkowe i ciekowe).
2
CLB (Configurable Logic Block) – bloki logiczne w strukturze FPGA 3
Oprócz trwaych uszkodze wystpuj jeszcze bdy przemijajce, chwilowe, typu zmiana wartoci komórki pamici, rejestru, linii sygnaowej na warto przeciwn do poprawnej. Wraz z rozwojem technologii, zmniejszaniem si wymiarów technologicznych, obserwuje si równie wzrastajc czuo ukadów na bdy przemijajce. Dla poszczególnych modelów bdów opracowano wiele metod ich weryfikacji, opartych gównie na dekompozycji ukadów i specjalistycznych metodach testowania.
2.3.3. Techniki samotestowania w ukadach FPGA
Testowania dowolnych struktur ukadów cyfrowych jest problemem trudnym i kosztownym. Std duym zainteresowaniem ciesz si techniki projektowania ukadów atwo testowalnych. Dziaania te maj na celu gównie zwikszenie kontrolowalnoci i obserwowalnoci ukadów cyfrowych.
Rozwiniciem technik projektowania uatwiajcego testowanie s techniki samotestowania BIST. Metody samotestowania mona podzieli na [7,8]:
- samotestowanie wspóbiene z normaln prac systemu; - samotestowanie prewencyjne (off-line).
Ukady BIST mog by na stae wbudowane w struktur ukadów FPGA, lub samotestowanie ukadów FPGA moe odbywa si przez wykorzystanie cechy rekonfigurowalnoci w systemie. Wykorzystywane s wolne zasoby ukadu FPGA, które przeksztacane s tymczasowo w generator i analizator testu dla pozostaych komórek. Po przetestowaniu przywracana jest konfiguracja odpowiadajca normalnej pracy. W ten sposób samotestowanie przeprowadzane jest bez nadmiaru ukadowego.
Istot metody samotestowania jest dekompozycja ukadu FPGA na fragmenty, które s testowane w oddzielnych sesjach testowych, gdzie kada z sesji skada si z zaprogramowania ukadu, wykonania samotestowania i weryfikacji wyniku. Techniki samotestowania s obecnie najbardziej rozwijanymi technikami testowania ukadów programowalnych FPGA.
3. METODA TESTOWANIA SPECJALIZOWANYCH
URZDZE STEROWANIA RUCHEM
Analiza metod weryfikacji i testowania, oraz prowadzone badania bazujce na opracowanych modelach specjalizowanych sterowników duchu drogowego (rys. 5a) [1], pozwoliy opracowywa metod weryfikacji urzdze sterowania ruchem drogowym realizowanych w ukadach programowalnych FPGA.
Weryfikacj przeprowadza si na poziomie specjalistycznych narzdzi wspomagania komputerowego, w których nastpuje specyfikacja ukadów. Wykorzystuje si pakiety oprogramowania: Active-HDL, a jako jzyk specyfikacji VHDL. Podczas weryfikacji specyfikacji ukadów sterowania ruchem, za gówny cel stawia si poprawn realizacj algorytmów sterowania ruchem.
Weryfikacj kodu VHDL ukadu sterowania rozpoczyna si od kompilacji projektu, eliminujc na tym etapie bdy semantyczne i skadniowe. Przy czym z powodu wielomoduowoci ukadów sterowania zarówno kompilacja jak i dalsza weryfikacja prowadzona jest metod wstpujc.
Weryfikacja przeprowadzana jest metod weryfikacji funkcjonalnej z elementami weryfikacji strukturalnej. Bada si wszystkie funkcje projektowanego sterownika. Podstawow analiz przeprowadza si na przebiegach czasowych. Jako analizator odpowiedzi wykorzystuje si narzdzie komparacji przebiegów czasowych, w czytelny sposób wskazujce wszelkie rónic w porównywanych przebiegach (rys. 3).
Rys. 3. Wynik porównania dwóch przebiegów czasowych
Automatyzacja procesu weryfikacji moliwa jest dziki wykorzystaniu automatycznych rodowisk testowych (Test Bench). Zbiór wektorów testowych generowany jest zarówno do testów funkcjonalnych jak i strukturalnych.
W przypadku ukadów sterowania posiadajcych wiele wyprowadze, narzdziem uatwiajcym opracowanie wektorów testowych, zarówno przy weryfikacji funkcjonalnej jak i strukturalnej, jest narzdzie analizujce zmian stanów portów ukadu i informujce o ewentualnym braku aktywnoci na danym porcie (Toggle Coverage) (rys. 4a).
W wyniku weryfikacji funkcjonalnej pokryte zostan wszystkie funkcje ukadu, lecz nie caa jego struktura. Naley wczy do weryfikacji elementy testowania strukturalnego. Pomocne, do oceny jakoci pokrycia, jest narzdzie pakietu Active-HDL umoliwiajce analiz miar pokrycia strukturalnego (Code Coverage). Narzdzie to automatycznie raportuje dwie gówne miary z zakresu weryfikacji strukturalnej. Analizowane s linie kodu, które zostay wykonane podczas wykonywania programu i sprawdzane ile razy takie wywoanie nastpio (rys. 4b). Analiz pokrycia kodu testem dopenia narzdzie analizujce wykonanie rozgazie kodu (Branch Coverage), badane s wywoania warunków typu IF, CASE (rys. 4c), sprawdzajc ile razy zostay one wykonane.
Analiza pokrycia kodu, pozwala na modyfikacj wektora testowego, aby otrzyma maksymalne pokrycie struktury programu. Naley pamita o warunkach brzegowych. Naley zweryfikowa dziaanie ukadu dla skrajnych wartoci zadeklarowanych zmiennych, wykona poszczególne ptle, sprawdzi dziaanie liczników, ich maksymalne zakresy i warunki zerowania.
Przeprowadzenie w ten sposób weryfikacji opracowanego kodu ukadu sterowania, pozwala znale wszystkie bdy etapu specyfikacji i usun je w kolejnych rewizjach kodu VHDL opisujcego ukad sterowania ruchem.
a) b) c)
Rys. 4. Raporty z analizy pokrycia strukturalnego: a) Toggle Coverage, b) Code Coverage, c) Branch Coverage
Kolejnym etapem jest testowanie prototypu sterownika (rys. 5b). Stosujc zewntrzne techniki testowania weryfikuje si prac urzdzenia, co pozwala wyeliminowa bdy realizacji sterownika. Wykorzystanie wewntrznych technik testowania, poprzez implementacj w prototypie ukadów samotestowania poszczególnych bloków sterownika (rys. 5a), umoliwia wykrycie uszkodze powstaych w czasie uytkowania ukadu.
a) b)
Rys. 5. Specjalizowany sterownik ruchu drogowego: a) model sterownika, b) prototyp sterownika
4. WNIOSKI
Urzdzenia sterowania ruchem drogowym, ze wzgldu na ich zoono oraz wan rol, jak peni, musz by testowane na kadym etapie ich tworzenia, bowiem, nie wykryte bdy w algorytmach urzdze lub ich uszkodzenia, poza kosztami produkcyjnymi nios koszty spoeczne. W zwizku z tym niezwykle istotne jest rozwijanie nowych technik i metod testowania. Zastosowanie ukadów FPGA w urzdzeniach srd, pozwala na wykorzystanie nowoczesnych narzdzi i metod testowania tych urzdze.
Przedstawiono analiz metod testowania urzdze sterowania ruchem, na etapach specyfikacji urzdze sterowania w jzykach opisu sprztu VHDL i realizacji w ukadach FPGA, gdzie zaproponowano zastosowania technik testowania oprogramowania na etapie modelowania struktur sprztowych urzdze.
Przedstawiono pen metod testowania modeli specjalizowanych urzdze sterowania ruchem, pozwalajc na wyeliminowanie bdów specyfikacji urzdze.
Dalsze prace bd skupia si nad rozwijaniem metod testowaniem bdów realizacji urzdze sterowania w ukadach FPGA, gdzie gówny nacisk pooony jest na samotestowanie tych urzdze.
Bibliografia
1. Firlg K., Kawalec P.: Budowa modeli specjalizowanych sterowników ruchu drogowego w jzykach opisu sprztu. Materiay Konferencji Naukowej „Systemy Transportowe - teoria i praktyka”, Katowice, 2012, s. 22-23.
2. Harris I. G., Tessier T.: Testing and Diagnosis of Interconnect Faults in Cluster-Based FPGA Architectures. Department of Electrical and Computer Engineering University of Massachusetts at Amherst, 2002.
3. Leko M., Guzik J.: Sterowanie ruchem drogowym. Sterowniki i systemy sterowania i nadzoru ruchu. Wydawnictwo Politechniki lskiej, Gliwice, 2000.
4. uba T., Jasiski K., Zwierzchowski B.: Specjalizowane ukady cyfrowe w strukturach PLD i FPGA. WK, Warszawa,1997.
5. Sapiecha K.: Testowanie i diagnostyka systemów cyfrowych. PWN, Warszawa, 1987.
6. Sosnowski J.: Testowanie i niezawodno systemów komputerowych. Akademicka Oficyna Wydawnicza EXIT, Warszawa, 2005.
7. Stroud C. E.: A Designer's Guide to Built-In Self-Test. Kluwer Academic Publishers, 2002.
8. Tomaszewicz, P., Kraniewski, A.: Samotestowanie rekonfigurowalnych ukadów FPGA zaprogramowanych przez uytkownika. Materiay Krajowego Sympozjum Telekomunikacji, Bydgoszcz, 1998, s. 126-132.
TESTING OF SPECIALIZED ROAD TRAFFIC CONTROL DEVICES REALIZED IN FPGA DEVICES
Summary: Road traffic control devices, due to their complexity and a significant role, as well as a high level
of required reliability, must be tested at every stage of their creation. Application of FPGA circuits in road traffic control devices allows for increasing efficiency and reliability of these circuits, however, the use of modern tools and testing methods of these devices is required.
A complex process of creation of road traffic control devices within FPGA structures has been presented. The problem of appearing and detecting operating errors has been presented and analyzed for particular stages of the process. Errors resulting from wrong specification and realization of the circuit, as well as errors resulting from realization damage have been considered.
The designed method for testing models of specialized road traffic control devices has been presented, which allows for detection of specification errors of devices designed within VHDL and realized in FPGA circuits.
