Wszyscy chcemy, aby nasze układy FPGA były niezawodne w swoim docelowym środowisku pracy. Szczególnie, jeśli układ taki pracuje w krytycznej dla bezpieczeństwa sekcji urządzenia. W pierwszej części tego artykułu przyjrzeliśmy się jak podejść do projektowania układu z FPGA o wysokim stopniu niezawodności, jak dobrać elementy urządzenia, w tym oscylatory i system resetowania FPGA. Dowiedzieliśmy się także jak skomunikować pomiędzy sobą różne moduły wewnątrz FPGA i sam układ pogramowalny z innymi układami scalonymi w systemie.
W drugiej, ostatniej części artykułu przyjrzymy się pozostałym kwestiom, jakie są istotne w systemach o podwyższonej bezawaryjności:
1. Wykorzystanie mechanizmu dwuetapowego wydawania komend - "uzbrój i strzelaj".
2. Liczniki.
3. Bezpieczne maszyny stanów.
4. Potrójna, modułowa redundancja.
5. Weryfikacja.
Uzbrój i strzelaj - dwuskładnikowy system wydawania komend
Dla bardzo krytycznych kanałów wydawania komend innym modułom lub urządzeniom w systemie warto zaimplementować mechanizm "uzbrój i strzelaj", czyli dwuskładnikowy system wydawania komend. Odmiennie niż w klasycznym przypadku komenda wydawana jest nie z pomocą pojedynczej linii, a dwóch. Jedna z nich uzbraja urządzenie, a druga rozpoczyna wykonanie komendy. Maszyna stanów interpretująca te komendy czeka najpierw na impuls 'uzbrajający', a następnie na komendę 'strzału'. Jeśli w odpowiednim czasie ta druga nie zostanie odebrana system się resetuje do początkowego stanu.
W bardzo krytycznych aplikacjach mechanizmy dwuskładnikowych komend mogą być zaimplementowane nawet z wykorzystaniem dwóch, niezależnych fizycznych interfejsów. Dodatkowo do interfejsu dodane mogą być linie potwierdzające (ACK), którymi docelowy układ informuje FPGA, że otrzymał zadaną komendę. Linia ACK jest zdublowana i oba interfejsy wyposażone są w swoją własną i niezależną.
Liczniki.
Liczniki w układach programowalnych wykorzystywane są do wielu zadań. Niektóre z nich mierzą czas pomiędzy rozmaitymi wydarzeniami, inne generują periodyczne zachowania układów. Wiele liczników wykorzystywanych jest w połączeniu z maszynami stanów.
Większość liczników nie jest zdolnych do liczenia do potęg dwójki. W związku z tym istnieje szansa wystąpienia wartości powyżej granicznej wartości licznika. Oznacza to, że jeżeli dane w liczniku ulegną uszkodzeniu, wartość zapisana w liczniku może osiągnąć wartość większą niż zaprogramowana liczba do jakiej zliczać miał ten moduł. Tego rodzaju błąd w układzie programowalnym może spowodować niepoprawne działanie FPGA, ale także zupełnie go zawiesić. Jednym ze sposobów na ustrzeżenie się następstw takiej sytuacji jest projektowanie liczników z warunkiem stopu jako większe lub równe, a nie tylko równe, jak pokazano na fragmencie kodu zamieszczonym powyżej.
Bezpieczne maszyny stanów.
Maszyny stanów są kluczowym elementem wielu projektów systemów na FPGA. Wykorzystywane mogą być do kontroli układów logicznych w danej aplikacji lub z ich pomocą zaimplementowane są protokoły komunikacyjne. Aby system mógł pracować niezawodnie należy zadbać o to, aby maszyna stanów była w tanie wykrywać błędy i różne awarie, a także w sposób odpowiedni (tj. bezpieczny dla systemu) na nie reagować.
Błąd związany z niezmapowanym stanem może nastąpić gdy maszyna stanów wejdzie w niepoprawny stan. Co oznacza niepoprawny to dokładnie zależy od tego w jaki sposób kodujemy stany maszyny w naszym systemie. Jeśli wykorzystano implementację sekwencyjną, to niepoprawnymi tanami będą wszystkie te, które znajdują się pomiędzy naszym najwyższym stanem a najbliższą potęgą dwójki. Z kolei jeśli do kontroli stanów użyjemy rejestru, to niepoprawnym stanem będzie taki w którym więcej niż jeden rejestr jest załączony.
Gdy maszyna stanów wejdzie w niepoprawny stan nie ma żadnego sposobu na wyskoczenie z niego, co oznacza poważną awarię. Jak temu przeciwdziałać?
Jak w wielu technikach systemów o wysokiej bezawaryjności tak i tutaj architektura detekcji i korekcji sprawdza się bardzo dobrze. Maszyna stanów z zaimplementowaną taką funkcją działać będzie poprawnie, nawet po wejściu w niepoprawny stan. Powyższe diagramy prezentują działanie maszyny stanów wykorzystującej detekcję i korekcję kodów stanów.
Potrójna, modułowa redundancja.
Podstawowa idea potrójnej, modułowej redundancji (TMS) jest prosta - należy potropić krytyczne elementy projektu lub jego części, a następnie wyznaczać "średnie" wyjście lub pozwolić modułom na "głosowanie" i wartość tą przyjmować jako wyjście z modułu. W sytuacji idealnej, wszystkie trzy elementy działać będą tak samo dając to samo na wyjściu. W przypadku awarii jednego z nich nadal większość modułów będzie miała rację, więc sam system nadal będzie działał poprawnie, dzięki TMR.
Technika ta jest często brana pod uwagę podczas projektowania systemów o podwyższonej bezawaryjności, jednakże, co już nie jest takie oczywiste, można TMR implementować w trzy różne sposoby:
TMR Globalny: Cały projekt implementowany jest w układzie programowalnym potrójnie, wliczając w to zegary, system resetu i układy I/O.
Podejście globalne pozwala uchronić się przed błędami wynikającymi z działania samej 'tkanki' FPGA i pamięci konfiguracyjnej (w przypadku układów opartych o SRAM). Jednakże, podejście globalne wiąże się z dużo większym zużyciem powierzchni w FPGA, co przekłada się na konieczność ciaśniejszego upakowania modułów w układzie programowalny. Wykorzystując podejście globalne, aby zapewnić sobie poprawność działania, musimy upewnić się, że wszystkie przerzutniki w systemie są obsługiwane przez TMR o resynchronizowane z tymi, które uległy błędom lub awarii.
TMR Wielkoziarnisty: To podobna do podejścia globalnego architektura, w której potraja się część lub całość architektury FPGA. W odróżnieniu od podejścia globalnego, architektura wielkoziarnista nie wymaga resynchronizacji przerzutników na stopniu lokalnym - to wyjścia przerzutników w układach są uśredniane.
Podobnie jak w przypadku podejścia globalnego, technika ta chroni przez błędami konfiguracji i logiki. Podejście to wymaga jeszcze osobnego mechanizmu - częściowej rekonfiguracji - który ma za zadanie korygować błędy powstałe na etapie implementacji projektu w układzie programowalnym.
TMR Lokalny: Najprostsze z podejść do realizacji TMR, często implementowane w układach FPGA, które mają pracować w przestrzeni kosmicznej, na poziomiej rejestrów. Pozwala na uśrednianie wyników dla każdego przerzutnika pomiędzy blokami kombinacyjnymi. Dzięki temu gwarantuje się poprawny stan rejestrów, jednakże podejście lokalne nie chroni przed błędami wynikającymi z SET (Single Event Transient), które zachodzić mogą w blokach kombinacyjnych ponieważ wyjście z bloku kombinacyjnego jest podłączone na wejście wszystkich trzech przerzutników.
Istnieją oczywiście metody, pozwalające na korekcję błędów wynikających z zdarzeń SET, ale istotnie zwiększają one poziom skomplikowania projektu w układzie programowalnym i najlepiej, jeśli są one implementowane bezpośrednio w strukturze krzemowej FPGA.
Weryfikacja.
Finalnie, gdy już zaprojektujemy odpowiedni system, uwzględniając wszystkie opisane w obu częściach artykułu sugestie, pamiętać musimy, że aby uzyskać projekt o możliwie najwyższych parametrach konieczna jest weryfikacja. Dzięki systemowemu podejściu do tworzenia urządzenia w ramach planowania jego projektowania nie możemy zapominać o weryfikacji i testowaniu od samych początków. Każdy moduł, jaki implementujemy w FPGA musi być niezależnie przetestowany wykorzystując odpowiednią technikę, na przykład:
* Test samodzielny: raportowanie zaliczenia lub braku testu.
* Test warunków skrajnych: zapewnienie, że moduł działać będzie w skrajnych warunkach pracy systemu.
* Test wartości brzegowych: zapewnienie, że moduł działać będzie w okolicy warunków brzegowych.
* Dokumentacja: zapewnienie dokładnego opisu (wyzwalanie, ścieżki, komendy, warunki testowania) jakie potem zaimplementowane mogą być w warsztacie testującym prototypy i finalnie, w systemie testującym urządzenia na linii produkcyjnej.
W dokumentacji nie jesteśmy w stanie ująć wszystkiego, ale warto w niej opisać także wszystkie przeprowadzane na modułach testy i ich wyniki. Informacje te wykorzystać można później, testując gotowe urządzenie w fazie prototypowania.
Podczas planowania systemu pamiętać musimy, że etap weryfikacji układu i jego modułów często jest najbardziej czasochłonnym etapem - zajmuje on nawet więcej niż samo tworzenie układu. Jest to szczególnie prawdziwe w przypadku urządzeń opartych na FPGA, gdzie istotne jest testowanie nie tylko samych modułów, ale zależności między nimi. W szczególnie krytycznych aplikacjach może następować konieczność stosowania bardziej wyrafinowanych technik testowania i weryfikacji jak na przykład sprawdzanie formalnej równoważności (ang. formal equivalence checking).
Podsumowanie
Opracowywanie systemów opartych na układach programowalnych o podwyższonej bezawaryjności wymaga szerokiej gamy zabiegów i musi być realizowane w ujęciu systemowym wraz z analizą wymagań docelowej aplikacji. Jak pokazaliśmy w artykule istnieje szereg technik i narządzi, które pozwalają na realizację tego jeśli uwzględni się planie projektowania odpowiednie kroki i zaimplementuje odpowiednie mechanizmy w FPGA.
Źródło: http://www.eetimes.com/author.asp?doc_id=1330399&page_number=10
W drugiej, ostatniej części artykułu przyjrzymy się pozostałym kwestiom, jakie są istotne w systemach o podwyższonej bezawaryjności:
1. Wykorzystanie mechanizmu dwuetapowego wydawania komend - "uzbrój i strzelaj".
2. Liczniki.
3. Bezpieczne maszyny stanów.
4. Potrójna, modułowa redundancja.
5. Weryfikacja.
Uzbrój i strzelaj - dwuskładnikowy system wydawania komend
Dla bardzo krytycznych kanałów wydawania komend innym modułom lub urządzeniom w systemie warto zaimplementować mechanizm "uzbrój i strzelaj", czyli dwuskładnikowy system wydawania komend. Odmiennie niż w klasycznym przypadku komenda wydawana jest nie z pomocą pojedynczej linii, a dwóch. Jedna z nich uzbraja urządzenie, a druga rozpoczyna wykonanie komendy. Maszyna stanów interpretująca te komendy czeka najpierw na impuls 'uzbrajający', a następnie na komendę 'strzału'. Jeśli w odpowiednim czasie ta druga nie zostanie odebrana system się resetuje do początkowego stanu.
W bardzo krytycznych aplikacjach mechanizmy dwuskładnikowych komend mogą być zaimplementowane nawet z wykorzystaniem dwóch, niezależnych fizycznych interfejsów. Dodatkowo do interfejsu dodane mogą być linie potwierdzające (ACK), którymi docelowy układ informuje FPGA, że otrzymał zadaną komendę. Linia ACK jest zdublowana i oba interfejsy wyposażone są w swoją własną i niezależną.
Liczniki.
Liczniki w układach programowalnych wykorzystywane są do wielu zadań. Niektóre z nich mierzą czas pomiędzy rozmaitymi wydarzeniami, inne generują periodyczne zachowania układów. Wiele liczników wykorzystywanych jest w połączeniu z maszynami stanów.
Większość liczników nie jest zdolnych do liczenia do potęg dwójki. W związku z tym istnieje szansa wystąpienia wartości powyżej granicznej wartości licznika. Oznacza to, że jeżeli dane w liczniku ulegną uszkodzeniu, wartość zapisana w liczniku może osiągnąć wartość większą niż zaprogramowana liczba do jakiej zliczać miał ten moduł. Tego rodzaju błąd w układzie programowalnym może spowodować niepoprawne działanie FPGA, ale także zupełnie go zawiesić. Jednym ze sposobów na ustrzeżenie się następstw takiej sytuacji jest projektowanie liczników z warunkiem stopu jako większe lub równe, a nie tylko równe, jak pokazano na fragmencie kodu zamieszczonym powyżej.
Bezpieczne maszyny stanów.
Maszyny stanów są kluczowym elementem wielu projektów systemów na FPGA. Wykorzystywane mogą być do kontroli układów logicznych w danej aplikacji lub z ich pomocą zaimplementowane są protokoły komunikacyjne. Aby system mógł pracować niezawodnie należy zadbać o to, aby maszyna stanów była w tanie wykrywać błędy i różne awarie, a także w sposób odpowiedni (tj. bezpieczny dla systemu) na nie reagować.
Błąd związany z niezmapowanym stanem może nastąpić gdy maszyna stanów wejdzie w niepoprawny stan. Co oznacza niepoprawny to dokładnie zależy od tego w jaki sposób kodujemy stany maszyny w naszym systemie. Jeśli wykorzystano implementację sekwencyjną, to niepoprawnymi tanami będą wszystkie te, które znajdują się pomiędzy naszym najwyższym stanem a najbliższą potęgą dwójki. Z kolei jeśli do kontroli stanów użyjemy rejestru, to niepoprawnym stanem będzie taki w którym więcej niż jeden rejestr jest załączony.
Gdy maszyna stanów wejdzie w niepoprawny stan nie ma żadnego sposobu na wyskoczenie z niego, co oznacza poważną awarię. Jak temu przeciwdziałać?
Jak w wielu technikach systemów o wysokiej bezawaryjności tak i tutaj architektura detekcji i korekcji sprawdza się bardzo dobrze. Maszyna stanów z zaimplementowaną taką funkcją działać będzie poprawnie, nawet po wejściu w niepoprawny stan. Powyższe diagramy prezentują działanie maszyny stanów wykorzystującej detekcję i korekcję kodów stanów.
Potrójna, modułowa redundancja.
Podstawowa idea potrójnej, modułowej redundancji (TMS) jest prosta - należy potropić krytyczne elementy projektu lub jego części, a następnie wyznaczać "średnie" wyjście lub pozwolić modułom na "głosowanie" i wartość tą przyjmować jako wyjście z modułu. W sytuacji idealnej, wszystkie trzy elementy działać będą tak samo dając to samo na wyjściu. W przypadku awarii jednego z nich nadal większość modułów będzie miała rację, więc sam system nadal będzie działał poprawnie, dzięki TMR.
Technika ta jest często brana pod uwagę podczas projektowania systemów o podwyższonej bezawaryjności, jednakże, co już nie jest takie oczywiste, można TMR implementować w trzy różne sposoby:
TMR Globalny: Cały projekt implementowany jest w układzie programowalnym potrójnie, wliczając w to zegary, system resetu i układy I/O.
Podejście globalne pozwala uchronić się przed błędami wynikającymi z działania samej 'tkanki' FPGA i pamięci konfiguracyjnej (w przypadku układów opartych o SRAM). Jednakże, podejście globalne wiąże się z dużo większym zużyciem powierzchni w FPGA, co przekłada się na konieczność ciaśniejszego upakowania modułów w układzie programowalny. Wykorzystując podejście globalne, aby zapewnić sobie poprawność działania, musimy upewnić się, że wszystkie przerzutniki w systemie są obsługiwane przez TMR o resynchronizowane z tymi, które uległy błędom lub awarii.
TMR Wielkoziarnisty: To podobna do podejścia globalnego architektura, w której potraja się część lub całość architektury FPGA. W odróżnieniu od podejścia globalnego, architektura wielkoziarnista nie wymaga resynchronizacji przerzutników na stopniu lokalnym - to wyjścia przerzutników w układach są uśredniane.
Podobnie jak w przypadku podejścia globalnego, technika ta chroni przez błędami konfiguracji i logiki. Podejście to wymaga jeszcze osobnego mechanizmu - częściowej rekonfiguracji - który ma za zadanie korygować błędy powstałe na etapie implementacji projektu w układzie programowalnym.
TMR Lokalny: Najprostsze z podejść do realizacji TMR, często implementowane w układach FPGA, które mają pracować w przestrzeni kosmicznej, na poziomiej rejestrów. Pozwala na uśrednianie wyników dla każdego przerzutnika pomiędzy blokami kombinacyjnymi. Dzięki temu gwarantuje się poprawny stan rejestrów, jednakże podejście lokalne nie chroni przed błędami wynikającymi z SET (Single Event Transient), które zachodzić mogą w blokach kombinacyjnych ponieważ wyjście z bloku kombinacyjnego jest podłączone na wejście wszystkich trzech przerzutników.
Istnieją oczywiście metody, pozwalające na korekcję błędów wynikających z zdarzeń SET, ale istotnie zwiększają one poziom skomplikowania projektu w układzie programowalnym i najlepiej, jeśli są one implementowane bezpośrednio w strukturze krzemowej FPGA.
Weryfikacja.
Finalnie, gdy już zaprojektujemy odpowiedni system, uwzględniając wszystkie opisane w obu częściach artykułu sugestie, pamiętać musimy, że aby uzyskać projekt o możliwie najwyższych parametrach konieczna jest weryfikacja. Dzięki systemowemu podejściu do tworzenia urządzenia w ramach planowania jego projektowania nie możemy zapominać o weryfikacji i testowaniu od samych początków. Każdy moduł, jaki implementujemy w FPGA musi być niezależnie przetestowany wykorzystując odpowiednią technikę, na przykład:
* Test samodzielny: raportowanie zaliczenia lub braku testu.
* Test warunków skrajnych: zapewnienie, że moduł działać będzie w skrajnych warunkach pracy systemu.
* Test wartości brzegowych: zapewnienie, że moduł działać będzie w okolicy warunków brzegowych.
* Dokumentacja: zapewnienie dokładnego opisu (wyzwalanie, ścieżki, komendy, warunki testowania) jakie potem zaimplementowane mogą być w warsztacie testującym prototypy i finalnie, w systemie testującym urządzenia na linii produkcyjnej.
W dokumentacji nie jesteśmy w stanie ująć wszystkiego, ale warto w niej opisać także wszystkie przeprowadzane na modułach testy i ich wyniki. Informacje te wykorzystać można później, testując gotowe urządzenie w fazie prototypowania.
Podczas planowania systemu pamiętać musimy, że etap weryfikacji układu i jego modułów często jest najbardziej czasochłonnym etapem - zajmuje on nawet więcej niż samo tworzenie układu. Jest to szczególnie prawdziwe w przypadku urządzeń opartych na FPGA, gdzie istotne jest testowanie nie tylko samych modułów, ale zależności między nimi. W szczególnie krytycznych aplikacjach może następować konieczność stosowania bardziej wyrafinowanych technik testowania i weryfikacji jak na przykład sprawdzanie formalnej równoważności (ang. formal equivalence checking).
Podsumowanie
Opracowywanie systemów opartych na układach programowalnych o podwyższonej bezawaryjności wymaga szerokiej gamy zabiegów i musi być realizowane w ujęciu systemowym wraz z analizą wymagań docelowej aplikacji. Jak pokazaliśmy w artykule istnieje szereg technik i narządzi, które pozwalają na realizację tego jeśli uwzględni się planie projektowania odpowiednie kroki i zaimplementuje odpowiednie mechanizmy w FPGA.
Źródło: http://www.eetimes.com/author.asp?doc_id=1330399&page_number=10
Fajne? Ranking DIY