PRZEMYSŁAW SOŁTAN

Transkrypt

1 PRZEMYSŁAW SOŁTAN

2 Historia projektu wersja vhdlunit 1.06 (dodanie dodatkowej procedury vhdlunicclock z możliwością ustalania rodzaju sygnału inicjującego zegar stymulus'a; dodanie funkcji negowania typu nstd_logic - nstd2neg) wersja vhdlunit 1.05 (bugg fix!) wersja vhdlunit 1.04 (dodanie pola info do metod asercji assertequal) wersja vhdlunit 1.02 (obsługa dodatkowych asercji dla typów std_logic_vector i nstd_logic_vector) wersja vhdlunit 1.0 beta (modyfikacja dokumentacji i inicjalizacja projektu witryny internetowej prezentującej projekt ) ukończenie ostatecznej wersji publikacji opisującej bibliotekę vhdlunit (materiał po akceptacji ukaże się na konferencji Reprogramowalnych Układów Cyfrowych - RUC'2004 w Szczecinie) wersja vhdlunit_08_alpha wersja vhdlunit_07_alpha (dodanie procedury obsługi uniwersalnych zegarów taktujących vhdlunitclock wykorzystywanych w testbencha'ch) wersja vhdlunit_06_alpha wersja vhdlunit_05_alpha podział biblioteki na moduły (vhdlunit.vhd i vhdlunit_ext_nstd_logic.vhd) wersja vhdlunit_04_alpha aktualizacja dokumentacji wersja vhdlunit_03_alpha obsługa logów (log4vhdl) wersja rozwojowa inicjalizacja modułu TCL do graficznej obsługi biblioteki wersja vhdlunit_02_alpha obsługa serii testów (dodanie vhdlunit.properties) wersja vhdlunit_01_alpha inicjacja projektu realizacji testów jednostkowych w języku VHDL potrzeba stworzenia automatyzowanego środowiska do prac projektowych prowadzonych w ramach grantu Wykryte błędy do poprawienia: spradzić poprawność konwersji nstd2std() dla nstd_logic_vector np. nstd2std(cout & sout)

3 Wstęp Testy jednostkowe jako zestaw zautomatyzowanych testów działają na wyższym poziomie, niż kompilator, który sprawdza składnię programu. Zadaniem testów jest kontrola prawidłowego działania (semantykę) programu. Raporty Testy jednostkowe Testowany System Zastosowanie sprzężenia zwrotnego, które pokazuje jakość wykonanej pracy za pomocą zautomatyzowanych testów jednostkowych. Projekt VhdlUnit jest wzorowany na pakiecie JUnit wspomagającego wykonywanie testów jednostkowych programów tworzonych przy użyciu języka Java. Projekt VhdlUnit jest zestawem funkcji testowych napisanych przy użyciu vhdl z przeznaczeniem do automatycznego wywoływania serii testbenchy i raportowania poprawności wykonywanych wyników. Generowane raporty są dostępne w postaci dokumentu html. Specyfikacja projektu opisywana zostaje w postaci testów jednostkowych. Testy jednostkowe Junit (Erich Gamma, Kent Beck) Stosowanie standardowej asercji w vhdl'u. assert a = b report 'Błąd...: a jest równe b' severity ERROR; NOTE - can be used to pass information messages from simulation WARNING - can be used in unusual situation in which the simulation can be continued, but the results may be unpredictable ERROR - can be used when assertion violation makes continuation of the simulation not feasible FAILURE - can be used when the assertion violation is a fatal error and the simulation must be stopped at once Wady: przerwanie przy napotkaniu pierwszego błędu (???) obecność kodu wewnątrz projektu brak nechanizmów uruchamiania (???) brak możliwości raportowania przebiegu testu Stosowanie testów jednostkowych vhdlunit Zalety: wiele mechanizmów uruchamiania testów (???) oddzielenie testów od kodu (zewnętrzna biblioteka) niezależność od środowiska projektowego (całość testów opisana przy użyciu vhdl'a) przypadki testowe (???) budowanie raportów process (najmniejszą jednostką testową)

4 Uruchamianie Proces wykonania testu przebiega w trzech fazach. Faza I wykonanie metody initialize Faza II wywołanie testbenach y poszczególnych architektur projektowanego układu lub grupy układów Faza III wykonanie metody finalize Podczas inicjalizacji następuje przygotowanie ustawień początkowych i zostaje utworzony plik vhdlunit.htm raportujący przebieg testu. Zastosowanie testów nadaje się do testowania pojedynczego układu (entity) dla jednej lub wielu architektur, jak również dla grupy niezaleznych układów. To projektant decyduje jaki test (testy) realizować. Faza III kończy realizację testów i przygotowuje ostateczne zestawienie zapisywane w raportowanym pliku html. open new initialize VhdlUnit_tb (unit_initialize) update test 1 Raport (Html/XML) update update test 2 test N Testowane komponenty close finalize vhdlunit.do VhdlUnit_tb (unit_finalize) Zastosowanie Fazy I i III wynika z bezstanowości języka vhdl, tzn. Braku możliwości przekazywania parametrów pomiędzy poszczególnymi testami. Komunikację taką zrealizowano jednak przy pomocy pliku konfiguracyjnego vhdlunit.properties uaktualnianego po zakończeniu każdego testu.

5 Komponent inicjalizacji i zakonczenia testu ---- library IEEE; use IEEE.STD_LOGIC_1164.all; use work.vhdlunit_cfg.all; use work.vhdlunit.all; entity vhdlunit_tb is end vhdlunit_tb; ---- architecture unit_initialize of vhdlunit_tb is InitializeTestCase : process initialize; wait for 2ns; end unit_initialize; ---- architecture unit_finalize of vhdlunit_tb is FinalizeTestCase : process finalize; wait for 2ns; end unit_finalize; ---- configuration INITIALIZE_VHDL_UNIT of vhdlunit_tb is for unit_initialize end for; end INITIALIZE_VHDL_UNIT; configuration FINALIZE_VHDL_UNIT of vhdlunit_tb is for unit_finalize end for; end FINALIZE_VHDL_UNIT; ---- Raportowanie Raportowanie przy użyciu html (xml w przygotowaniu). Raportowanie testów w xml jako dane daje możliwość ich obróbki przez zewnetrzne bibliot eki (przekształcenia XSL np. Wizualizacja graficzna przy użyciu SVG grafiki wektorowej, zdalene wywoływanie testów i ich automat).yczne publikowane w sieci internet praca grupowa). Nadawanie wersji generowanych raportów (dokumentowanie postępu prac) Porównywanie różnic w poszczególnych raportach (w planach)

6 GUI Przykładowy ekran z Junit (testów jednostkowych w javie) oraz vhdlunit (w przygotowaniu GUI w TCL). Prosty przykład Przykład bramki logicznej i kilku testów Metodologia projektowania - zaprojektowanie bloku entity - zaprojektowanie testbenchy - zaprojektowanie testów jednostkowych - iteracyjne projektowanie architektury (poprawianie) i wykonywanie testów jednostkowych Wcześniejsze opracowanie testów Definicja wymagań: Testy funkcjonalności (vhdlunit) Extreme Programming w VHDL? Metodologia Extreme Programming polega przede wszystkim na tym, aby projektowanie rozpocząć od zdefiniowania testów. Testy gwarantują zachowanie określonej funkcjonalności w procesie tworzenia projektu. Automatyzacja testów wymusza zachowanie powtarzalności zachowania środowiska projektu. Testowalność określenie warunków akceptacji systemu. Proces weryfikacji trwa przez czały okrec projektowania. Głównym celem jest identyfikacja defektów projektowanego systemu oraz ocena, czy system spełnia oczekiwania odbiorcy. Celem testowania jest wykrycie obecności błędów, a nie ich braku (trudności w dowodzeniu poprawności wiarygodności duża złożoność). Testowanie ma na celu stwierdzenie istnienia błędów. Testowanie modułów (unit testing) testowanie poszczególnych komponentów systemu w izolacji od pozostałych.

7 Testowanie integracyjne (integration testing) testowanie interfejsów współpracujących ze sobą modułów lub podsystemów Testowanie systemowe szczegółowe testowanie funkcjonowania całego systemu. Testowanie akceptacyjne wykonywane w celu stwierdzenia, czy system spełnia swoje wynagania. (zwykle podzbiór testów systemowych). Testowanie regresywne identyfikacja błędów wprowadzonych do już isniejącej i testowanej funkcjonalności (np. Podczas nanoszenia poprawek). Plan testów: Odwzorowanie testów systemowych na wymagania (weryfikacja pokrycia testów). Wyszczególnienie co będzie podlegać testowaniu. Procedury przechowywania testów (przechowywanie wyników testów) Wymagania sprzętowe Testowanie kolejnych poprawek: uruchamiamy i patrzymy na wynik (wielokrotne wywoływanie tych samych faz) zaprojektowanie TestBench'y procedury dostarczające danych wejściowych i sprawdzające wynik wykorzystanie test framework raporty z wyników testu, lepsza kontrola procesu testowania. Komponent TestBench TestUnit+metoda assercji (weryfikacja wyniku) Osadzanie testów Wykorzystanie plików (np. VhdlUnit.do) do lokalizacji testów wywołanie określonych testów Tryb tekstowy i GUI Dlaczego? Tworzenie testów wraz z kodem ma swoje zalety: (testy automatycznie wykrywają błędy wprowadzane przy poprawkach lub dodawaniu funkcjonalności testy stanowią formę dokumentacji kodu wiadomo jak ma się zachowywać kod naprzemienne kodowanie i tworzenie testów wprowadza inkrementny tryb pracy (eliminacja przykrych niespodzianek) XP zaleca nawet pisanie unit testów przed odpowiednim fragmentem kodu. Dobry test Test, który pokazuje, że program w danej sytuacji nie funkcjonuje prawidłowo. Aby wykazać, że dany program nie posiada błędów, trzeba przeprowadzić wszystkie możliwe testy (w praktyce jest to niemożliwe). Testowanie typowych przypadków, niż sprawdzanie przypadków skrajnych (???) Przy testowaniu ważniejsza jest funkcjonalność całego projektu, niż poszczególnych komponenów. Testy jednostkowe - Projekt VhdlUnit

8 Instalacja biblioteki vhdlunit umieścić archiwum biblioteki w katalogu źródeł do TestBenach a dołączyć bibliotekę vhdlunit: library ieee,nstd_logic_2000; use ieee.std_logic_1164.all; use nstd_logic_2000.nstd_logic_2000.all; use work.vhdlunit.all; entity gedeon_and2_tb is end gedeon_and2_tb;... do TestBencha a dodać proces testu jednostkowego TEST CASE TestCase : process constant test_time: time := 50ns; setup("gedeon_and2"); -- inicjalizacja testu wait for asserttime(50ns); assertequals("o",o,'0'); wait for asserttime(100ns); assertequals("o",o,'0'); wait for asserttime(150ns); assertequals("o",o,'0'); wait for asserttime(200ns); assertequals("o",o,'1'); teardown; -- koniec testu

9 ... do makra vhdlunit.do dodać dane symulacji przykładowego układu clear SetActiveLib -work # Test INITIALIZE_VHDL_UNIT comp -include "$DSN\src\vhdlUnit.vhd" asim INITIALIZE_VHDL_UNIT run 1ns endsim # TESTBENCH_FOR_gedeon_and2 comp -include "$DSN\src\gedeon\gedeon_and2.vhd" comp -include "$DSN\src\TestBench\gedeon_and2_TB.vhd" asim TESTBENCH_FOR_gedeon_and2 run 200 ns endsim # Test FINALIZE_VHDL_UNIT asim FINALIZE_VHDL_UNIT run 1ns endsim Makro startowe Do uruchomienia testów jednostkowych wykorzystano język makr udostępniony przez środowisko ActiveHdl. W przypadku symulatorów innych firm należy wykorzystać ich specyficzne właściwości. Sam test polega na wykonaniu wszystkich symulacji testowych z dodatkową symulacją począkową (INITIALIZE_VHDL_UNIT) i końcową (FINALIZE_VHDL_UNIT). Symulacja początkowa służy do inicjalizacji całego testu, a końcowa do jego zamknięcia. Obie symulacje wywołują odpowiednie funkcje biblioteki vhdlunit opisane przy uzyciu języka vhdl. Stosowanie dodatkowych symulacji wynika z bezstanowości języka vhdl pomiędzy dwoma różnymi symulacjami (brak możliwości przekazywania wartości zmiennych pomiędzy dwoma symulacjami). Makro startowe vhdlunit.do wywołania symulacji testowej. clear SetActiveLib -work # Test INITIALIZE_VHDL_UNIT comp -include "$DSN\src\vhdlUnit.vhd" asim INITIALIZE_VHDL_UNIT run 1ns endsim # Test TESTBENCH_FOR_gedeon_and4 comp -include "$DSN\src\gedeon\gedeon_and4.vhd" comp -include "$DSN\src\TestBench\gedeon_and4_TB.vhd" asim TESTBENCH_FOR_gedeon_and4 run 800 ns endsim # Test TESTBENCH_FOR_gedeon_and8 comp -include "$DSN\src\gedeon\gedeon_and8.vhd"

10 comp -include "$DSN\src\TestBench\gedeon_and8_TB.vhd" asim TESTBENCH_FOR_gedeon_and8 run ns endsim # Test... #... # Test FINALIZE_VHDL_UNIT asim FINALIZE_VHDL_UNIT run 1ns endsim Po zainicjowaniu danej symulacji (asim TESTBENCH_FOR_gedeon_and4) symulacja zostaje wykonana przez określony okres czasu (run 800ns), a następnie wykonane zostaje polecenie zakończenia symulacji (endsim) w celu umożliwienia inicjalizacji następnych symulacji. Komponenty inicjalizacji i finalizacji testu Proces inicjalizacji i finalizacji testu jest wykonywany za pomocą bloku testowego vhdlunit_tb zdefiniowanego wewnątrz pliku vhdlunit.vhd. Blok ten zawiera dwie architektury umożliwiające wykonanie funkcji initialize lub finalize w zależności od ustawień konfiguracji. library IEEE; use IEEE.STD_LOGIC_1164.all; use work.vhdlunit.all; entity vhdlunit_tb is end vhdlunit_tb; ---- architecture unit_initialize of vhdlunit_tb is InitializeTestCase : process initialize; wait for 2ns; end unit_initialize; ---- architecture unit_finalize of vhdlunit_tb is FinalizeTestCase : process finalize; wait for 2ns; end unit_finalize; ---- configuration INITIALIZE_VHDL_UNIT of vhdlunit_tb is for unit_initialize end for; end INITIALIZE_VHDL_UNIT; configuration FINALIZE_VHDL_UNIT of vhdlunit_tb is for unit_finalize end for; end FINALIZE_VHDL_UNIT; ---- Opis funkcji i procedur pakietu vhdlunit

11 procedure setup(name : in string); procedure teardown; procedure fail(name : in string); function assertwait(t:in time)return time; function asserttime(t:in time)return time; procedure assertequals(name : in String; arg1,arg2 : in nstd_logic); procedure assertzero(arg: in nstd_logic); procedure asserttrue(arg: in nstd_logic); procedure assertfalse(arg: in nstd_logic); procedure assertinfo(message: in string); function nstd2std(arg : in nstd_logic) return std_logic; function std2nstd(arg : in std_logic) return nstd_logic; Funkcje w przygotowaniu: procedure assertsame(name : in String; arg1,arg2 : in nstd_logic); procedure assertnotsame(name : in String; arg1,arg2 : in nstd_logic); AssertionFailedError Realizacja przykładowych procesów testowych Zdefiniowane przykładowe procesy testowy pobierają stany sygnałów testbench a wykonującego test funkcjonalny przykładowego układu. W tym przypadku mamy dostęp do czterech sygnałów pobudzających (in_1, in_2, in_3, in_4) oraz jednego sygnału odpowiedzi (out_1). Układ testowy realizuje funkcję czterowejściowej bramki AND. Proces testowy oparty o opis wzorca w postaci bezpośrednich porównań Proces dla określonych przedziałów czasu pobiera wartość sygnału z wyjścia out_1 i porównuje z odpowiednią stałą wartością. -- TEST CASE TestCase : process setup("gedeon_and4"); -- inicjalizacja testu wait for asserttime(50ns); assertequals("out_1",out_1,'0'); wait for asserttime(100ns); assertequals("out_1",out_1,'0'); wait for asserttime(150ns); assertequals("out_1",out_1,'0'); wait for asserttime(200ns); assertequals("out_1",out_1,'0'); wait for asserttime(250ns); assertequals("out_1",out_1,'0'); wait for asserttime(300ns); assertequals("out_1",out_1,'0'); wait for asserttime(350ns); assertequals("out_1",out_1,'0'); wait for asserttime(400ns); assertequals("out_1",out_1,'0'); wait for asserttime(450ns); assertequals("out_1",out_1,'0'); wait for asserttime(500ns); assertequals("out_1",out_1,'0'); wait for asserttime(550ns); assertequals("out_1",out_1,'0'); wait for asserttime(600ns); assertequals("out_1",out_1,'0'); wait for asserttime(650ns); assertequals("out_1",out_1,'0'); wait for asserttime(700ns); assertequals("out_1",out_1,'0'); wait for asserttime(750ns); assertequals("out_1",out_1,'0'); wait for asserttime(800ns); assertequals("out_1",out_1,'1'); teardown; -- koniec testu Proces testowy oparty o opis wzorca w postaci wektora danych

12 Proces dla określonych przedziałów czasu pobiera wartość sygnału z wyjścia out_1 i porównuje z odpowiednią wartością z tablicy wektorów. -- TEST CASE TestCase : process constant test_vector: nstd_logic_vector(1 to 16) := " "; constant test_time: time := 50ns; setup("gedeon_and4"); -- inicjalizacja testu for i in 1 to test_vector'length loop wait for asserttime(i*test_time); assertequals("out_1",out_1,test_vector(i)); end loop; teardown; -- koniec testu Proces testowy oparty o opis wzorca w postaci funkcji Proces dla określonych przedziałów czasu pobiera wartość sygnału z wyjścia out_1 i porównuje z odpowiednią wartością zmiennej test_out określoną na podstawie funkcji funkcjonalnego opisu wzorca (bramki AND) z pobieraniem aktualnych wartości sygnałów z testbencha (sygnały in_1, in_2, in_3 i in_4). -- TEST CASE TestCase : process constant test_time: time := 50ns; constant test_count: integer:= 16; variable test_out : std_logic; setup("gedeon_and4"); -- inicjalizacja testu for i in 1 to test_count loop wait for asserttime(i*test_time); test_out := nstd2std(in_1) and nstd2std(in_2) and nstd2std(in_3) and nstd2std(in_4); -- opis wzorca assertequals("out_1",out_1,std2nstd(test_out)); end loop; teardown; -- koniec testu

13 Opis testu dla 16 bitowego multipleksera (technologia prądowa) -- TEST CASE TestCase : process constant test_time: time := 50ns; constant test_count: integer:= 16; variable test_out : std_logic; variable s : std_logic_vector(3 downto 0); setup("multiplekser mux16_1e - wersja pradowa"); -- inicjalizacja testu for i in 1 to test_count loop wait for asserttime(i*test_time); s(0):= nstd2std(s0); s(1):= nstd2std(s1); s(2):= nstd2std(s2); s(3):= nstd2std(s3); if e='1' then case s is when "0000" => test_out := nstd2std(d0); when "0001" => test_out := nstd2std(d1); when "0010" => test_out := nstd2std(d2); when "0011" => test_out := nstd2std(d3); when "0100" => test_out := nstd2std(d4); when "0101" => test_out := nstd2std(d5); when "0110" => test_out := nstd2std(d6); when "0111" => test_out := nstd2std(d7); when "1000" => test_out := nstd2std(d8); when "1001" => test_out := nstd2std(d9); when "1010" => test_out := nstd2std(d10); when "1011" => test_out := nstd2std(d11); when "1100" => test_out := nstd2std(d12); when "1101" => test_out := nstd2std(d13); when "1110" => test_out := nstd2std(d14); when "1111" => test_out := nstd2std(d15); when others => null; end case; else test_out:='0'; end if; assertequals("o",o,std2nstd(test_out)); end loop; teardown; -- koniec testu Moduły rozszerzające Biblioteka vhdlunit została zastosowana przy testowaniu prądowego układu FPGA. W tym celu zaprojektowano moduł rozszerzający funkcjonowanie biblioteki o nowy typ danych nstd_logic. Zewnętrzna biblioteka nstd_logic_2000 zaprojektowana przez autorów publikacji umozliwia realizację modeli układów cyfrowych pracujacych w logice wielowartościowej[tu odniesienie do literatury]. Weryfikacja opracowanych układów Weryfikacja opracowanych układów (Opracowanie modelów VHDL, Realizacja w układzie scalonym, wyniki testów, opracowanie własnych i dostosowanie istniejących programów do sprawdzenia poprawności schematu i działania układu)

14 Zastosowanie: Model prądowego układu FPGA realizowanego w ramach grantu (tu podać numerek). Zalety: modyfikacja elementów projektu i wykonanie grupowych testów funkcjonalności wcześniej sprawdzanych konfiguracji układu. (łatwość eksperymentowania z nowymi pomysłami z uwzdlędnieniem weryfikacji wcześniej wykonanej pracy). Wnioski Możliwości dalszego rozwoju biblioteki: Dodanie nowych funkcji i procedur assercji dla różnych typów danych (std_logic, ustd_logic, nstd_logic, integer, string, real, std_logic_vector itd...) Realizacja procesów testowych w oparciu o wzorce danych zawartych w zewnętrznych plikach (plik tekstowy oraz waveform) Rozbudowa części raportowania o generację dokumentów XML Bibliografia