Elektroda.pl
Elektroda.pl
X
PCBway
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Filozofia FPGA: Obsługa błędów poprzez automat stanu

13 Lut 2008 17:45 1572 6
  • Poziom 19  
    Witam,
    chciałbym zaprosić wszystkich do dyskusji na temat dość filozoficzny, związany z obsługiwaniem błędów.

    Problem jest następujący:
    Jest sobie maszyna stanu, która realizuje powierzone jej zadanie, jednak co jakiś czas w trakcie jej działania może dojść do powstawania błędów, przykłady:
    - automat zajmuje się uzupełnianiem tablicy danymi płynącymi z FIFO i nagle kolejka się opróżnia, zakładamy oczywiście, że dane potrzebujemy natychmiast i nie możemy na nie czekać aż pojawią się znowu w FIFO
    - w pewnym stanie automat zajmuje się dekodowaniem rozkazu, a rozkaz który przyszedł jest nierozpoznawany
    - jesteśmy w stanach które przetwarzają dane, a nagle pojawia się rozkaz
    - itd.
    Jeśli w naszym automacie występuje tylko jednego rodzaju błąd, to jeszcze nie tak źle, ale wyobraźmy sobie sytuację, w której w stanach automatu mogą występować różne błędy, zarówno w obrębie jednego stanu jak i całego automatu. Wtedy musimy przejść do stanu obsługującego błędy. Rodzi to 3 problemy: dużą ilość przejść do stanu obsługi błędów (praktycznie w każdym stanie automatu musimy mieć warunek prowadzący nas do stanu błędu), konieczność zapamiętania rodzaju błędu (jeżeli istnieje tylko jeden stan obsługi błędów, a nie osobny dla każdego rodzaju błędu), oraz konieczność zapamiętania w jakim stanie automatu wystąpił błąd (chcemy wiedzieć jaka operacja spowodowała błąd). I tak z pięknego automatu, którego stworzyliśmy na początku, tworzy się dosyć zagmatwana struktura, która znacząco zwiększa powierzchnię układu zajmowaną przez automat.

    Przedstawiłem swoją koncepcję, sposób który niestety nie wygląda zbyt ładnie, tak więc poddaję temat pod dyskusję, być może ktoś zna jakieś ciekawe rozwiązania.

    Pozdrawiam.
  • PCBway
  • Poziom 27  
    pndemon napisał:
    Problem jest następujący:/.../
    I tak z pięknego automatu, /.../ tworzy się dosyć zagmatwana struktura


    mysle, ze to rzeczywiscie czysta filozofia :)
    ale jesli chodzi o poprawienie czytelnosci kodu moze mozna by tak:
    glowna fsm jest w stanie np. 'A', jesli jest ok, przechodzi dalej,
    jesli nie, przechodzi do stanu 'wait_A' [czy moze 'error_in_A'],
    ktory to stan 'wyzwala' fsm_error_A czy procedure obslugi bledu A,
    owa procedura po zrobieniu swojego mowi glownej fsm gdzie ma isc
    dalej ze stanu 'wait_A';
    takich error_fsm czy procedur obslugi bledow masz tyle, ile przewidywanych
    bledow do specjalnego potraktowania;
    glowna fsm komplikuje sie minimalnie, a to, co nalezy zrobic w wypadku
    bledu jest ladnie opisane w malym kawalku rtl;

    J.A
  • PCBway
  • Poziom 21  
    pndemon napisał:
    Jest sobie maszyna stanu (...) jednak co jakiś czas w trakcie jej działania może dojść do powstawania błędów, przykłady:
    - automat zajmuje się uzupełnianiem tablicy danymi płynącymi z FIFO i nagle kolejka się opróżnia, zakładamy oczywiście, że dane potrzebujemy natychmiast i nie możemy na nie czekać aż pojawią się znowu w FIFO
    - w pewnym stanie automat zajmuje się dekodowaniem rozkazu, a rozkaz który przyszedł jest nierozpoznawany
    - jesteśmy w stanach które przetwarzają dane, a nagle pojawia się rozkaz
    - itd.


    Chyba musiał byś opisać co rozumiesz jako maszynę stanów. Tak na wprost to twojego opisu modelu automatu wynika że jest cała masa stanów (określona sygnałami wejściowymi i wyjściowymi automatu) które nie zostały przewidziane/opisane w automacie.
    pndemon napisał:
    - jesteśmy w stanach które przetwarzają dane, a nagle pojawia się rozkaz

    co to znaczy "nagle". Przecież ta maszyna stanów musi dekodować komplet (dowolny) zestaw sygnałów czyli nastąpiło przejscie z jednego stanu do innego, a co ma sie wykonac to już będzie zależało od założeń konkretnego projektu. Chyba nie istnieje cos takiego jak uniwersalna metoda obsługi stanów które nie maja sensu z użytkowego punktu widzenia dowolnego automatu. Dla automatu bioracego udział w sterowaniu elektrownia jądrową będzie wymagana całkiem inna reakcja niż dla urzadzenia sterującego prosta zabawką. Generalnie mozna by próbowac okreslac jakiś "bezpieczny" stan błędu urządzenia i tam się przełączać ale jest to bardzo nieostre pojęcie.

    bis
  • Poziom 42  
    bis napisał:

    co to znaczy "nagle". Przecież ta maszyna stanów musi dekodować komplet (dowolny) zestaw sygnałów czyli nastąpiło przejscie z jednego stanu do innego, a co ma sie wykonac to już będzie zależało od założeń konkretnego projektu.
    Ja mam wrażenie że temat jest bardzo filozoficzny i dotyczy może jakiś asynchronicznych maszyn stanowych.
  • Poziom 19  
    Cytat:
    ale jesli chodzi o poprawienie czytelnosci kodu moze mozna by tak:

    No w zasadzie to nie chodzi mi o poprawienie czytelności, ale tego co powstaje po syntezie. Owa "brzydka" maszyna stanu, to po prostu maszyna stanu z wieloma przejściami.

    No idąc dalej, widzę że trzeba jednak zmniejszyć trochę poziom abstrakcji i dać konkretny przykład.

    Na rysunku jest przedstawiony automat inicjalizacyjny. Jego zadanie polega na odbiorze i dekodowaniu rozkazów (stan init_decision), oraz na zapisie pewnych struktur pamięciowych - dla każdego rozkazu jest inna struktura. Na rysunku, za względu na czytelność, nie ma przejść do stanu init_error. Działa on tak: pobiera rozkaz, a następne przychodzą już dane, które muszą zostać zapisane w odpowiedniej strukturze.

    Możliwe błędy:
    - w stanie init_decision czekamy na rozkaz, a tymczasem z procesora (automat jest częścią koprocesora) dostajemy dane.
    - w którymś ze stanów inicjalizacji, kiedy zapisujemy dane pojawia się rozkaz
    - wspomniane struktury pamięciowe mają określoną wielkość, np. w stanie init_str_main potrzeba 16 kolejno po sobie przychodzących danych, jeśli pojawi ich się mniej to jest to błąd.
    - dostaliśmy nieznaną instrukcję

    Założyłem, że jeśli wystąpi błąd do procesora jest zwracany rozkaz błędu, zawierający informację o tym jakiego rodzaju jest to błąd (error_code), oraz w jakim stanie to nastąpiło. Stąd pojawia się dodatkowa konieczność zapamiętania stany poprzedniego oraz definiowania w każdym ze stanów możliwych do zaistnienia kodów błędu.

    Dla przykładu podam opis jednego ze stanów:
    Code:

    basic_case := s_exist & s_control & net_datain(2 downto 0);
           .
           .
           .
    when init_str_main =>
          case basic_case(4 downto 3) is
             when "11" => error_code <= "0100";
                init_next <= init_error;
             when "10" => error_code <= "----";
                if (init_str = "0000") then
                   init_next <= init_decision;
                else
                   init_next <= init_str_main;
                end if;
             when others => error_code <= "0011";
                init_next <= init_error;
          end case;


    Oczywiście wszystko jest też kwestią tego jak bardzo mam być uprzejmy w stosunku do programisty procesora (notabene sam nim jestem :)) i na co mam mu zwracać uwagę, bo przecież mógłbym nie stosować żadnego sprzężenia zwrotnego i też jest szansa, że uda się to uruchomić.
    Natomiast to co mnie najbardziej martwi to to, że praktycznie jedynie dokładając obsługę błędów, które i tak nie mają prawa się pojawić poza fazą testów oprogramowania, automat stał się dosyć zagmatwany. Bo przecież prawie z każdego stanu muszę zdefiniować warunki przejścia do stanu init_error, co więcej w każdym tych stanów muszę dodatkowo dekodować jakiego rodzaju jest to błąd. Nie robiłem żadnych szacunków, ale myślę, że po tych zabiegach, automat zajmuje przynajmniej 2 razy tyle miejsca na matrycy co przed wprowadzeniem obsługi błędów.
  • Poziom 27  
    pndemon napisał:
    /.../

    mam jakas slabosc intelektualna i nie mam sily
    probowac zrozumiec twoj konktretny przyklad :(;
    ale pofilozofowac moge :);
    tam gdzie masz czas na jakas bardziej wyrafinowana obsluge
    bledow, tam zastosujesz tani mikroprocesor zamiast wielokrotnie
    drozszej fpga;
    jesli dokladasz jakas ekstra logike, ktora sprawdza
    poprawnosc danych i jeszcze na dodatek reaguje na bledy,
    to oczywiscie konsumpcja zasobow wzrosnie, nie rozumiem,
    czemu cie to dziwi ... :)
    osobna sprawa, to dokladanie 'inteligencji' by sobie
    ulatwic debugowanie, sam czesto wyprowadzam jakis sygnal,
    umozliwiajacy mi triggerowanie oscyloskopu, jesli musze
    sprawdzic timing na pinach, czy logike wykrywajaca bledy
    by wyzwalac SignalTap [ChipScope w ise];
    i na koniec - jak dolaczyc ta logike sluzaca do usuwania
    bledow do istniejacego kodu, by nie zaciemnic obrazu calosci,
    na ten temat swoj pomysl napisalem poprzednio;

    J.A
  • Poziom 42  
    pndemon napisał:
    Bo przecież prawie z każdego stanu muszę zdefiniować warunki przejścia do stanu init_error, co więcej w każdym tych stanów muszę dodatkowo dekodować jakiego rodzaju jest to błąd. Nie robiłem żadnych szacunków, ale myślę, że po tych zabiegach, automat zajmuje przynajmniej 2 razy tyle miejsca na matrycy co przed wprowadzeniem obsługi błędów.
    Wydaje mi się że w takim przypadku wszystko zależy od kodowania stanów, jeśli załóżmy (tak dla wygody) że masz 256 wszystkich stanów i 128 pozwala na wyjście do stanu błędu, to można tak zakodować numeryczne odpowiedniki stanów że zezwolenie na przejście będzie kodowane bezpośrednio w numerze stanu jednym bitem. Dla bardziej rozbudowanego przypadku jeśli zezwolić syntezerowi na samodzielne przypisywanie oznaczeń bitowych odpowiadających określonym stanom to on sam to zrobi tak żeby było to optymalnie i w efekcie końcowym układ może zajmować mniejszą powierzchnię matrycy.
    Zakładając że syntezer nie jest aż tak mądry ;) można zauważyć też że konieczne są elementy logiczne pozwalające na zdekodowanie "zezwolenia" na sytuację awaryjną dla określonych stanów. Realizacja takich układów przy pomocy modułów LUT jest trywialna, bo można dla każdego stanu wejściowego przypisać odpowiedź (nie trzeba rozkładać na maxtermy czy mintermy i grupować jak to się robi w PLD).