Wirtualne prototypy

Wysokiej jakości urządzenia wbudowane na ogół zawierają wiele mikroprocesorów i procesorów sygnałów cyfrowych DSP, zapewniających zaawansowane przetwarzanie sygnałów, a także do obwodów do realizacji łączności WiFi, systemu ustalania pozycji GPS lub Bluetooth (rys. 1). Urządzenia te zawierają DSP, rdzenie procesorów, kompletne podsystemy, modemy i bloki multimedialne. Mieszczą się w nich także liczne interfejsy, od USB do Bluetooth i Wi-Fi. Związany z tym dalszy rozwój oprogramowania wymaga rozszerzenia standardowych systemów operacyjnych na nowe możliwości sprzętowe. Obecnie nowe aplikacje muszą być opracowywane i testowane we wcześniejszej niż dotychczas fazie projektowania.

Idealny sposób zaspokojenia tych potrzeb powinien umożliwiać zespołom projektanckim uruchamianie oprogramowania zanim jeszcze powstanie prototyp sprzętu, dla którego jest ono przeznaczone. Zespół projektancki potrzebuje programowego prototypu sprzętu, zwanego prototypem wirtualnym. Prototyp taki ma służyć do przeprowadzania wszelkich prac w trakcie rozwijania oprogramowania bez docelowego prototypu sprzętowego. Prototyp wirtualny musi być w pełni funkcjonalnym programowym modelem prototypu docelowego. A w praktyce prototyp ten musi być dostępny nawet zanim jego architektura zostanie ostatecznie ustalona, i stale następnie uzgadniany z powstającym oprogramowaniem w miarę postępu prac.

Wirtualny prototyp zbudowany na modelu programowym

Rys. 1. Złożone urządzenia wbudowane na ogół zawierają wiele mikroprocesorów i procesorów sygnałów cyfrowych DSP, zapewniających zaawansowane przetwarzanie sygnałów, a także wiele interfejsów komunikacyjnych

Budowa wirtualnego prototypu wiąże się z tworzeniem programowego modelu produktu docelowego wraz z odpowiadającym mu wysokopoziomowym systemem testowania (testbench). Do tego celu używa się bloków funkcyjnych wysokiego poziomu, powiązanych z rozmaitymi blokami IP oraz modeli struktury ich wzajemnych połączeń. Struktura ta jest niezwykle ważna w sprzęcie, ponieważ liczne strumienie danych (na przykład strumień wideo i strumień audio) muszą być obsługiwane równocześnie, w miarę możności w połączeniu z pozostałą aktywnością komunikacyjną. W wirtualnym prototypie struktura modeli połączeń wzajemnych jest krytyczna dla sprawności symulacji, ważnej ze względu na produktywność zespołu opracowującego oprogramowanie.

Z perspektywy oprogramowania konieczność działania w czasie rzeczywistym musi się łączyć z potrzebami aplikacji pod kontrolą systemu operacyjnego czasu rzeczywistego (RTOS). Wirtualny prototyp winien szczegółowo odwzorowywać taktowanie struktury połączeń wzajemnych (cykl za cyklem), aby mógł udzielać odpowiedzi na pytania dotyczące jakości architektury. Modele bardzo szybkie i funkcyjnie poprawne mogą zabierać zbyt dużo czasu systemowego na udzielanie takich odpowiedzi. Z drugiej strony, dokładne modelowanie struktury połączeń wzajemnych cykl za cyklem może odbić się ujemnie na całkowitej sprawności symulacji, a zatem i na wydajności zespołu projektanckiego.

Projektanci przede wszystkim potrzebują takiego rozwiązania, które pozwala im dobierać poziom szczegółowości modelowania struktury połączeń wzajemnych. Wymagane szczegóły będą zależały od odpowiedzi, których ma im dostarczyć symulacja. Jeżeli jest to kwestia interakcji pomiędzy procesorem aplikacji a na przykład podsystemem modemu, ta część chipu powinna zostać odwzorowana szczegółowo, cykl po cyklu. Pozostałe części mogą być modelowane na poziomie funkcyjnym.

Użycie metody odwzorowania na mieszanych poziomach

Rys. 2.Ten sam system testujący i oprogramowanie mogą być używane do symulowania projektu, niezależnie od konfiguracji wirtualnego prototypu i użytych do modelowania systemu docelowego poziomów abstrakcji

Metoda odwzorowania na mieszanych poziomach wraz z pomocniczymi programami narzędziowymi pozwalają projektantom tworzyć wirtualny prototyp projektu docelowego. Mogą oni połączyć go z systemem testującym „bodziec/reakcja” (testbench), załadować zespół programów wykonawczych (po jednym dla każdego mikroprocesora i DSP) i uruchomić bardzo szybko działającą symulację. Narzędzia te powinny umożliwić łatwe konfigurowanie wirtualnego prototypu na potrzeby różnorodnych pomiarów i do rozwijania projektowanego programu.

Przy odwzorowywaniu na mieszanych poziomach ważne jest to, że ten sam system testujący i oprogramowanie mogą być używane do symulowania projektu, niezależnie od konfiguracji wirtualnego prototypu i użytych do modelowania systemu docelowego poziomów abstrakcji. W takim rozwiązaniu, jak przedstawione na rys. 2, poszczególne bloki wirtualnego prototypu są zwykle modelowane na oddzielnych poziomach funkcyjnych w języku C lub C++, a następnie łączone przez SystemC (rys. 3). Interfejsy zewnętrzne, do komunikowania się z systemem testującym, są modelowane na oddzielnym poziomie funkcyjnym.

Projektantów nie interesują szczegóły różnych bloków własności intelektualnej (IP) na poziomie systemu, dzięki czemu ten sposób modelowania działa w większości projektów. Zwykle bloki z poprzednich projektów są brane ponownie do użytku, albo otrzymywane od dostawcy IP. Projektanci są natomiast zainteresowani tworzeniem w systemie testującym funkcyjnie dokładnych strumieni danych. Dążą do zbadania, jak strumienie te są obsługiwane w wirtualnym prototypie, przez obserwację ich wpływu na wspólną magistralę i na zasoby układu. Na przykład szczegóły bloku USB nie mają wielkiego znaczenia. Istotny jest natomiast sposób otrzymywania danych za pośrednictwem interfejsu USB, a także skuteczność pomiarów.

Modelowanie interfejsów zewnętrznych, jak USB, na wysokim poziomie abstrakcji zapewnia szybkość wymaganą przez opracowujących oprogramowanie i pozwala im wprowadzać rzeczywiste strumienie danych. Projektanci mogą używać sprzętu stacji roboczej, na przykład interfejsu USB, i łączyć go z portem USB wirtualnego prototypu. Mogą więc być z nim łączone rzeczywiste źródła i wyjścia danych, jak wyświetlacze. W trakcie opracowywania oprogramowania i analiz architektury systemów można się posługiwać wszelkimi źródłami i ujściami danych.

Model funkcyjny jest głównym przy korzystaniu z poziomów mieszanych

Rys. 3. Poszczególne bloki wirtualnego prototypu są zwykle modelowane na oddzielnych poziomach funkcyjnych w języku C lub C++, a następnie łączone przez SystemC

Centralnym zagadnieniem techniki modelowania na poziomach mieszanych jest połączenie modeli funkcyjnych z modelami cyklicznie dokładnymi struktury połączeń wzajemnych. Na przykład w firmie Synopsys opracowano technikę oznaczania, pozwalającą wywołanie funkcji wysokiego poziomu opatrywać informacją o numerze cyklu. To wywołanie funkcji może być następnie odwzorowane w serii wywołań interfejsu programowania aplikacji (API) cykl po cyklu SystemC modelu połączeń wzajemnych cykl po cyklu. Modelowane w ten sposób symulacje z wykorzystaniem bloków IP są raczej cyklicznie przybliżonymi niż dokładnymi. Jednak, gdy są połączone z cyklicznie dokładną magistralą, zawierają wystarczającą ilość informacji do podejmowania decyzji o architekturze.

Istotnym warunkiem dla pomyślnego opracowywania oprogramowania jest istnienie interfejsu i możliwości współpracy ze zwykłymi programami uruchomieniowymi (debuggerami). Ponieważ twórcy oprogramowania preferują różne programy uruchomieniowe, środowisko weryfikacyjne na poziomie mieszanym musi mieć interfejsy z licznymi programami uruchomieniowymi oprogramowania. Interfejsy te muszą ponadto współdziałać z tymi programami w sprzęcie i w domenach weryfikacji.

Dla twórców oprogramowania stosowanie wirtualnego prototypu do uruchamiania wielordzeniowego jest korzystne, ponieważ skanowanie JTAG zatrzymuje w danym momencie tylko jeden procesor, ale w wirtualnym prototypie mogą zostać zatrzymane wszystkie rdzenie, gdy osiągnięty zostanie albo programowy albo sprzętowy punkt przerwania.

Gdy wirtualny prototyp zostanie zdefiniowany i przekazany zespołowi programistów, staje się bardzo istotne, aby opracowywany równocześnie sprzęt był z tym prototypem zgodny. Gdyby tej zgodności zabrakło, praca programistów zostałaby zmarnowana.

Oprogramowanie wraz z systemem testowania tworzą nadrzędne środowisko weryfikacyjne do testowania zdefiniowanej przez zamawiającego konfiguracji modelu systemu docelowego na poziomie mieszanym. Model ten jest następnie doskonalony i stopniowo zastępowany przez odwzorowanie poszczególnych bloków w języku czasu rzeczywistego (RTL). W tym momencie to samo środowisko weryfikacyjne może – i powinno – zostać użyte do zapewnienia zgodności modelu wysokiego poziomu z modelem RTL systemu docelowego.

Ze względu na wydajność prawdopodobnie cały program nie będzie mógł działać na modelu RTL. Jednakże zespół weryfikacyjny może starannie dobrać obejmujący wszystkie funkcje komplet testów, które muszą działać i sprawdzić program na modelu funkcyjnym wysokiego poziomu, na bardziej szczegółowym modelu architektury i na modelu RTL projektu. Taki komplet testów tworzy pakiet regresji. Pakiet ten zlokalizuje wszystkie rozbieżności pomiędzy modelem RTL a wirtualnym prototypem, używanym przez programistów do atestowania i rozwijania aplikacji.

Takie podejście pozwala opracowywać oprogramowanie i sprzęt naprawdę równocześnie. Zapewnia, że gdy powstanie prototyp sprzętowy, przeznaczone dla niego oprogramowanie będzie gotowe, można je będzie od razu załadować i przetestować w całości. Wszystkie najważniejsze podzespoły zostaną sprawdzone, a większość oprogramowania opracowana. Ponadto zgodność oprogramowania ze sprzętem była monitorowana przez cały czas ich powstawania. W rezultacie faza ich końcowego scalenia staje się raczej ich atestacją z bardzo wysokim prawdopodobieństwem sukcesu w pierwszym podejściu. (KKP)