PRZEMYSŁAW SOŁTAN e-mail: kerk@moskit.ie.tu.koszalin.pl



Podobne dokumenty
Laboratorium 10 Temat: Zaawansowane jednostki testowe. Operacje na plikach. Funkcje.

KONCEPCJA REALIZACJI TESTÓW JEDNOSTKOWYCH W JĘZYKU VHDL

Krótkie wprowadzenie do ModelSim i Quartus2

Modelowanie złożonych układów cyfrowych (1)

Projekt prostego procesora

Języki opisu sprzętu VHDL Mariusz Rawski

Kierunek EiT Specjalność Sieci i usługi, V rok Programowalne Układy Cyfrowe. Zaawansowany VHDL. Rajda & Kasperek 2014 Katedra Elektroniki AGH 2

Weryfikacja i walidacja. Metody testowania systemów informatycznych

Kierunek EiT Specjalność Sieci i usługi, V rok Programowalne Układy Cyfrowe. Zaawansowany VHDL. Rajda & Kasperek 2015 Katedra Elektroniki AGH 1

Elementy języka VHDL. obiekty typy danych atrybuty pakiety i biblioteki instrukcje współbieżne instrukcje sekwencyjne. PUE-w3 1

Testowanie oprogramowania. Piotr Ciskowski

Projektowanie Urządzeń Cyfrowych

MentorGraphics ModelSim

Sposoby projektowania systemów w cyfrowych

Projektowanie hierarchiczne Mariusz Rawski

WOJSKOWA AKADEMIA TECHNICZNA im. Jarosława Dąbrowskiego LABORATORIUM UKŁADÓW PROGRAMOWALNYCH I SPECJALIZOWANYCH

Laboratorium Projektowania Systemów VLSI-ASIC Katedra Elektroniki Akademia Górniczo-Hutnicza

Specyfika projektowania Mariusz Rawski

Altera Quartus II. Opis niektórych komponentów dostarczanych razem ze środowiskiem. Opracował: mgr inż. Leszek Ciopiński

Układy reprogramowalne i SoC Język VHDL (część 4)

1. ISE WebPack i VHDL Xilinx ISE Design Suite 10.1 VHDL Tworzenie projektu Project Navigator Xilinx ISE Design Suite 10.1 File

Pojedyncze wartości zadeklarowanego typu Ustawiane przed rozpoczęciem symulacji bez moŝliwości

Szkoła programisty PLC : sterowniki przemysłowe / Gilewski Tomasz. Gliwice, cop Spis treści

Weryfikacja logiczna projektów VHDL realizowanych w reprogramowalnych układach FPGA pracujących w trybie prądowym

Aby w pełni przetestować układ o trzech wejściach IN_0, IN_1 i IN_2 chcemy wygenerować wszystkie możliwe kombinacje sygnałów wejściowych.

Systemy Czasu Rzeczywistego FPGA

Testowanie aplikacji mobilnych na platformie Android - architektura, wzorce, praktyki i narzędzia

Automatyzacja testowania oprogramowania. Automatyzacja testowania oprogramowania 1/36

Całościowe podejście do testowania automatycznego dla programistów. (TDD, BDD, Spec. by Example, wzorce, narzędzia)

Systemy Czasu Rzeczywistego FPGA

Układy reprogramowalne i SoC Testbenches. Symulacja sterowana zdarzeniami.

Politechnika Białostocka Wydział Elektryczny Katedra Automatyki i Elektroniki. ĆWICZENIE Nr 4 (3h) Przerzutniki, zatrzaski i rejestry w VHDL

Projektowanie automatów z użyciem VHDL

REFERAT PRACY DYPLOMOWEJ

Programowanie poprzez testy z wykorzystaniem JUnit

Programowanie w Ruby

Security Master Class Secure Configuration Life Cycle. Marcin Piebiak Senior Solutions Architect Linux Polska Sp. z o.o.

Etapy życia oprogramowania

Przykładowe pytania z części PSPICE. 1. Podaj zasady tworzenia pliku symulacyjnego. 2. Czy składnia PSPICE jest czuła na wielkość liter? 3.

Język opisu sprzętu VHDL

Testowanie oprogramowania. Testowanie oprogramowania 1/34

Całościowe podejście do testowania automatycznego dla programistów. /C#/PHP (TDD, BDD, Spec. by Example, wzorce, narzędzia)

Technika Cyfrowa. Wprowadzenie do laboratorium komputerowego część II

Technika cyfrowa projekt: Sumator 4 bitowy równoległy

Testowanie aplikacji. Kurs języka Ruby

Etapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania

Testowanie. Ryszard Beczek & Piotr Miłkowski 1 04/11/07

Systemy Czasu Rzeczywistego FPGA

Programowalne układy logiczne

Język programowania PASCAL

Układy reprogramowalne i SoC Implementacja w układach FPGA

Konwerter Plan testów. Jakub Rauch Tomasz Gołębiowski Adam Busch Bartosz Franaszek 1 czerwca 2008

Wydział Elektryczny. Katedra Automatyki i Elektroniki. Instrukcja do ćwiczeń laboratoryjnych z przedmiotu: SYNTEZA UKŁADÓW CYFROWYCH ES2D100005

Spis treści 1. Wstęp 2. Ćwiczenia laboratoryjne LPM

Realizacja bezpiecznego programowalnego sterownika logicznego z wykorzystaniem języków HDL

Wprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego

Wykład 8. Testowanie w JEE 5.0 (1) Autor: Zofia Kruczkiewicz. Zofia Kruczkiewicz

Zarządzanie testowaniem wspierane narzędziem HP Quality Center

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

METODY PROGRAMOWANIA

Politechnika Białostocka Wydział Elektryczny Katedra Automatyki i Elektroniki

Testowanie oprogramowania

Analiza i projektowanie aplikacji Java

Szablon Planu Testów Akceptacyjnych

Politechnika Białostocka Wydział Elektryczny Katedra Automatyki i Elektroniki

Maciej Oleksy Zenon Matuszyk

Automatyzacja testów aplikacji webowych w Selenium podstawy. Natalia Krawczyk

Testowanie I. Celem zajęć jest zapoznanie studentów z podstawami testowania ze szczególnym uwzględnieniem testowania jednostkowego.

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o.

Procesowa specyfikacja systemów IT

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania

Praca Magisterska "System zdalnego składania ofert kupna i sprzedaży za pośrednictwem Internetu" AUTOR PROMOTOR

Programowanie zespołowe

1. Synteza układów opisanych w języku VHDL Xilinx ISE Design Suite 10.1 VHDL 2. Obsługa przetwornika CA Project Add source...

Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu. Projekt ZEFIR 2

Inżynieria oprogramowania (Software Engineering)

INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE

LABORATORIUM TECHNIKA CYFROWA. Pamięci. Rev.1.35

VHLD Very High Speed Integrated Circuit (VHSIC) Hardware Description Language (VHDL)

Politechnika Białostocka Wydział Elektryczny Katedra Automatyki i Elektroniki

Uwagi dotyczące notacji kodu! Moduły. Struktura modułu. Procedury. Opcje modułu (niektóre)

IO - Plan testów. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006

Informatyzacja przedsiębiorstw WYKŁAD

Bloki anonimowe w PL/SQL

Projektowanie w VHDL

Technika mikroprocesorowa. Struktura programu użytkownika w systemie mikroprocesorowym

mgr inż. Maciej Rudek opracował: dr inż. Daniel Kopiec

COMARCH IT AKADEMIA. Programista VBA w Microsoft Excel (microbootcamp)

Program szkolenia: Test Driven Development (TDD) using Spock or JUnit 5

Sposoby tworzenia projektu zawierającego aplet w środowisku NetBeans. Metody zabezpieczenia komputera użytkownika przed działaniem apletu.

PROJEKTOWANIE. kodowanie implementacja. PROJEKT most pomiędzy specyfikowaniem a kodowaniem

Główne założenia XP. Prostota (Simplicity) Komunikacja (Communication) Sprzężenie zwrotne (Feedback) Odwaga (Agressiveness)

Wprowadzenie do projektu QualitySpy

INŻYNIERIA OPROGRAMOWANIA TESTOWANIE INTEGRACYJNE

1 Wstęp. 2 Proste przykłady. 3 Podstawowe elementy leksykalne i typy danych. 6 Opis strukturalny. 7 Moduł testowy (testbench)

Wykaz zmian w programie SysLoger

LABORATORIUM ELEKTRONIKA Projektowanie koderów, transkoderów i dekoderów w języku VHDL

Kurs Zaawansowany S7. Spis treści. Dzień 1

Tester oprogramowania 2014/15 Tematy prac dyplomowych

Model reprogramowalnego prądowego układu działającego w logice wielowartościowej

Transkrypt:

PRZEMYSŁAW SOŁTAN e-mail: kerk@moskit.ie.tu.koszalin.pl

Historia projektu 04.05.2004 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) 24.03.2004 wersja vhdlunit 1.05 (bugg fix!) 23.03.2004 wersja vhdlunit 1.04 (dodanie pola info do metod asercji assertequal) 14.03.2004 wersja vhdlunit 1.02 (obsługa dodatkowych asercji dla typów std_logic_vector i nstd_logic_vector) 10.03.2004 wersja vhdlunit 1.0 beta (modyfikacja dokumentacji i inicjalizacja projektu witryny internetowej prezentującej projekt http://kik.ie.tu.koszalin.pl/vhdlunit ) 1.03.2004 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) 24.02.2004 wersja vhdlunit_08_alpha 15.02.2004 wersja vhdlunit_07_alpha (dodanie procedury obsługi uniwersalnych zegarów taktujących vhdlunitclock wykorzystywanych w testbencha'ch) 3.02.2004 wersja vhdlunit_06_alpha 31.01.2004 wersja vhdlunit_05_alpha 30.01.2004 podział biblioteki na moduły (vhdlunit.vhd i vhdlunit_ext_nstd_logic.vhd) 30.09.2003 wersja vhdlunit_04_alpha 30.09.2003 aktualizacja dokumentacji 26.11.2003 wersja vhdlunit_03_alpha 25.11.2003 obsługa logów (log4vhdl) wersja rozwojowa 13.11.2003 inicjalizacja modułu TCL do graficznej obsługi biblioteki 22.09.2003 wersja vhdlunit_02_alpha 22.09.2003 obsługa serii testów (dodanie vhdlunit.properties) 21.09.2003 wersja vhdlunit_01_alpha 28.08.2003 - 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: 24.03.2004 spradzić poprawność konwersji nstd2std() dla nstd_logic_vector np. nstd2std(cout & sout)

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ą)

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.

---- -- 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)

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.

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

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

... 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"

comp -include "$DSN\src\TestBench\gedeon_and8_TB.vhd" asim TESTBENCH_FOR_gedeon_and8 run 12800 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

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

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) := "0000000000000001"; 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

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)

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 http://www.xprogramming.com