Dlaczego wywnioskowane zatrzaski są złe?

Mój kompilator narzeka na wywnioskowane zatrzaski w moich pętlach kombinatorycznych ( always @(*)w Verilog). Powiedziano mi również, że najlepiej unikać wywnioskowanych zatrzasków.

Co dokładnie jest nie tak z wnioskowanymi zatrzaskami? Z pewnością ułatwiają pisanie pętli kombinatorycznych.

„Zatrzask” różni się od „Flip-Flop” tym, że FF zmienia swoją moc wyjściową tylko w odpowiedzi na zbocze zegara. Zatrzask może zmienić swoją moc wyjściową w reakcji na coś innego niż zegar. Na przykład SR-Latch ma zestaw i wejście resetowania, a jeśli jedno z nich jest aktywne, wyjście może się zmienić. Gdzie jako SR-FF reaguje na zestaw lub resetuje tylko wtedy, gdy występuje również zbocze zegara.

W FPGA chcesz, aby logika była w pełni synchroniczna. Oznacza to, że wszystkie elementy pamięci (takie jak FF) są taktowane z jednego źródła zegara. Wszystko, co jest asynchroniczne z tym zegarem, musi być traktowane bardzo ostrożnie, w przeciwnym razie wystąpią błędy synchronizacji.

Zatrzask jest w zasadzie asynchronicznym elementem pamięci. Nie ma wejścia zegara, dlatego nie można go zsynchronizować z żadnym zegarem. Powinienem zauważyć, że istnieją FF z asynchronicznym resetowaniem i resetowaniem danych wejściowych, które należy traktować z taką samą ostrożnością jak normalne zatrzaski.

Omówienie wszystkich problemów z synchronizacją, które mogą powodować zatrzaski, wykracza daleko poza to, co można tutaj omówić, ale dam wam jeden przykład:

Powiedzmy, że masz zatrzask SR i chcesz, aby był ustawiany za każdym razem, gdy 8-bitowy licznik osiągnie określoną wartość. Nie jestem pewien, jaki byłby kod Verilog, ale w VHDL kod to: ustaw <= '1', gdy count = "11010010" else '0'; Ten ustawiony sygnał trafia do ustawionego wejścia w naszej zatrzasku SR.

Generowana logika jest czysto kombinatoryczna; mieszanka bramek, bramek i falowników (lub LUT). Ale ścieżki sygnału przez tę kombinatoryczną logikę nie zawsze są idealne i „ustalony” sygnał może mieć na nim usterki. Ścieżka sygnału przez określoną grupę bramek może potrwać dłużej niż inna grupa, powodując, że ustawione wyjście uaktywni się na chwilę, zanim wyjście ustabilizuje się do stanu końcowego.

Ta usterka wyjściowa może spowodować ustawienie naszego SR-Latch, nawet jeśli nie było to konieczne. Jeśli przełączymy się z SR-Latch na SR-FF, wyzerujemy ten sam zegar, co licznik, wtedy SR-FF będzie czekał na jeden cały cykl zegara przed zmianą stanu. Zasadniczo poczeka, aż ustawiony sygnał ustabilizuje się, zanim na niego spojrzy.

Jeśli ścieżki przez kombinatoryczną logikę dla ustawionego sygnału są po prostu inaczej prowadzone (powodując różne opóźnienia), wówczas zachowanie usterki również się zmieni. Logika może działać dobrze, ale ponieważ zmieniłeś coś całkowicie niezwiązanego, logika jest kierowana inaczej, więc pojawia się błąd. Temperatura i napięcie również zmienią przebieg sygnału, a tym samym mogą zmienić zachowanie usterki.

To niepewne w czasie, dlatego powinieneś unikać zatrzasków w logice. FF są znacznie bezpieczniejsze w użyciu. Właśnie dlatego twój kompilator ostrzega cię o zatrzaskach, ponieważ łatwo jest przez pomyłkę zrobić zatrzask i prawdopodobnie i tak go nie chcesz.

Oczywiście czasami wymagane są zatrzaski. Musisz ich używać bardzo rzadko, tylko gdy jest to absolutnie wymagane, a następnie musisz odpowiednio zaprojektować logikę, aby nie było żadnych problemów.

Co sprawia, że ​​wnioskujesz o zatrzasku?
W przypadku logiki kombinatorycznej wyjście obwodu jest funkcją wyłącznie wejściową i nie powinno zawierać żadnej pamięci ani stanu wewnętrznego (zatrzask).

W Verilog zmienna zachowa swoją poprzednią wartość, jeśli nie zostanie jej przypisana wartość w bloku zawsze . Aby zapisać tę wartość bieżącą, należy utworzyć zatrzask.

Niekompletna instrukcja if-else wygeneruje zatrzaski. If-else oświadczenie uważa się za „niepełne” jeśli stan wyjścia nie jest zdefiniowane dla wszystkich możliwych warunków wejściowych. To samo dotyczy niekompletnej instrukcji case lub instrukcji case , która nie ma wartości domyślnej: item.

Dlaczego wywnioskowane zatrzaski są złe?
Wnioskowane zatrzaski mogą służyć jako „znak ostrzegawczy”, że projekt logiki może nie zostać zaimplementowany zgodnie z przeznaczeniem. Wprojekcie może brakowaćkluczowejinstrukcji if-else lub case .

Zatrzaski mogą prowadzić do problemów z czasem i warunkami wyścigu. Mogą one prowadzić do kombinatorycznego sprzężenia zwrotnego - kierowania wyjścia z powrotem do wejścia - co może być nieprzewidywalne.

Aby uniknąć tworzenia wnioskowanych zatrzasków:

• Obejmują wszystkie gałęzie na razie lub wypadku oświadczenie
• Przypisz wartość do każdego sygnału wyjściowego w każdej gałęzi
• Użyj domyślnych przypisań na początku procedury, aby każdy sygnał został przypisany.

Niektóre części zostały sparafrazowane z „FPGA Prototyping by Verilog Examples” P. Chu

Zatrzaski są bardzo trudne w użyciu w FPGA lub CPLD, więc wiele osób po prostu ich całkowicie unika. Jednym z powodów jest to, że wiele układów FPGA nie ma wbudowanej zatrzasku, więc są wykonane z bramek logicznych - może to powodować nieprzyjemne problemy z synchronizacją.
Ponadto nie masz żadnej kontroli nad opóźnieniami czasowymi i warunkami wyścigu podczas używania zatrzasku (chyba że istnieje element natywny)

Odradzałbym używanie zatrzasków, chyba że absolutnie nie możesz się bez nich obejść (np. Pożyczanie czasu, aby osiągnąć wymaganą maksymalną częstotliwość taktowania) i zastosować techniki kodowania, aby zmniejszyć prawdopodobieństwo przypadkowego wnioskowania zatrzasków.

Projekty logiki sekwencyjnej zbudowane przy użyciu logiki kombinatorycznej i sprzężenia zwrotnego generalnie przyjmują założenie, które wydawałoby się rozsądne przy zastosowaniu fizycznych bramek: że wyjście bramki nie zmieni się w odpowiedzi na zmianę danych wejściowych, aż do czasu, gdy dane wejściowe faktycznie się zmienią. W niektórych przypadkach to założenie może się nie utrzymywać, gdy używane są prawdziwe bramki (np. Jeśli zarówno szybka bramka NOR, jak i szybki falownik są napędzane sygnałem, który powoli wzrasta z VSS do VDD, i gdy falownik przełącza się na 1,2 wolta, podczas gdy NOR bramka nie przełącza się, dopóki 1,7 wolta, bramka NOR może zobaczyć niski poziom wyjściowy falownika, zanim zobaczy, że wolno rosnący sygnał osiągnął wysoki poziom), ale takie problemy można ogólnie rozwiązać, dodając bufor za każdym razem, gdy powoli się zmienia sygnał jest kierowany do więcej niż jednego miejsca docelowego. Niestety,

Problem polega na tym, że jeśli wyraźnie nie podano inaczej, kompilator FPGA może dowolnie zastąpić obwód kombinatoryczny całkowicie innym obwodem, który ma takie samo zachowanie w stanie ustalonym, ale może mieć zupełnie inne taktowanie. Załóżmy na przykład, że złożona funkcja kombinatoryczna F pobiera sześć wejść U do Z. F jest podawany bezpośrednio do obwodu P, a (F NAND Z) jest podawany do obwodu Q. Kompilator może zdawać sobie sprawę, że wartość podawana do Q będzie zależeć tylko od F, gdy Z jest wysokie, i może obliczać funkcję F ', która jest podobna do F, z tym że Z przyjmuje się jako wysoką; Q może być następnie zasilany (F 'NAND Z) zamiast (F NAND Z). Byłoby całkowicie możliwe, że najbardziej wydajna realizacja P miałaby pięć opóźnień bramki, ale najbardziej wydajna realizacja Q miałaby tylko dwa. A zatem,

Jeśli obwód ma kombinatoryczne pętle sprzężenia zwrotnego, kompilator FPGA będzie musiał dodać fizyczne węzły sygnałowe, które fizycznie będą miały opóźnienie dodatnie (pętla sprzężenia zwrotnego o zerowym opóźnieniu nie może istnieć w świecie rzeczywistym), ale nie ma gwarancji, że takie węzły zostałyby dodane w miejscach niezbędnych do tego, aby obwód zachowywał się zgodnie z potrzebami. Nie ma też żadnej gwarancji, że niewielka zmiana w projekcie nie spowoduje zmiany kompilatora z dowolnego umiejscowienia, które zdarza się działać w świecie rzeczywistym, do innego dowolnego umiejscowienia, które się nie powiedzie.

Szczegółowe informacje o tym, jak złapać zatrzask w projekcie, zostały krótko wyjaśnione w tym linku.

https://www.doulos.com/knowhow/fpga/latches/