zawsze blok @ * z pojedynczym niepustującym przydziałem - dobry, zły lub nieistotny?

Question

Ogólna zasada wspomniana we wszystkich książkach, które dotychczas przeczytałem, polega na tym, że musisz używać blokad zawsze w blokach, które są napędzane przez podnoszenie lub opadanie zegara. Wręcz przeciwnie, do opisu logiki kombinatorycznej należy stosować przypisania blokujące. Ta zasada ma dla mnie sens, a autorzy przykładów dokładnie ją stosują.

Jednak dostrzeżone następujący fragment Verilogu jednego kodu produkcyjnego:

always @* begin 
    in_ready <= out_ready || ~out_valid; 
end 

Należy zauważyć, że nie blokuje zadanie <= jest używany. Nie sądzę, żeby to miało jakikolwiek wpływ na tę sprawę, ponieważ nie ma wielu przydziałów. Jednak nie mogę znaleźć żadnego wyjaśnienia tego. Pytanie brzmi: czy to robi, czy nie ma znaczenia, zarówno w zakresie danego bloku zawsze i jako część większego projektu?

Answer 1

Nieistotna, ale zła praktyka.

Wątpię, czy pojedyncze zadanie powoduje jakiekolwiek skutki uboczne. Blok zawsze wywoła zmiany po prawej stronie, aktualizując in_ready. Nie ma nic do zablokowania, więc nieblokowanie nie spowoduje problemów.

Jeśli większy projekt miał:

always @* begin 
    in_ready <= out_ready || ~out_valid ; 
    other_ready <= in_ready || other_ready ; 
end 

Nie jestem zbyt pewien, jak to jest kombinatoryczne może po prostu wziąć dodatkowy krok delta rozwiązać.

Answer 2

Oczywiście narusza to moją wytyczną dotyczącą kodowania nr 3: http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf), ale zadziała.

Powodem, dla którego należy unikać stosowania blokad niezablokowanych do kodowania logiki kombinowanej jest wydajność symulacji. W przykładzie Munkymorgy, po wyzwalaczach zawsze blokujących, ocenisz prawostronną (RHS) wszystkie równania, wrócisz na górę zawsze bloku, zaktualizujesz LHS równań, które ponownie uruchomią zawsze blokuj, co ponownie zmusi symulator do oceny RHS równań, przejdź do początku bloku zawsze, a następnie zaktualizuj LHS równań. W przypadku większych bloków może to spowodować wiele iteracji poprzez blok zawsze z odpowiednią karą symulacji.

W tym prostym przykładzie z 1 linii nie ma wewnętrznej kary symulacji, ale w innych miejscach mogą obowiązywać kary za przekroczenie uprawnień.

Dobrzy koderowie używają konsekwentnie dobrych nawyków kodowania. Chciałbym zmienić kod. Jeśli zmiana kodu spowoduje przerwanie wyników symulacji, wówczas istnieją dodatkowe złe nawyki kodowania zakopane gdzie indziej w kodzie. Kod nie powinien być tak delikatny.

Pozdrawiam - Cliff Cummings - Verilog & SystemVerilog Guru

Answer 3

jej nie złe jego wybór, jeśli zrozumieć sposób układ będzie zachowywał się jej bardzo dobrze tak na przykład

zawsze @ * rozpocząć b < = a + c; a = b; koniec

1. więc w tym próbki kodu kompletny obwód opracowane wewnątrz zawsze bloku zostanie aktywowany, gdy coś wewnątrz listy wrażliwości, która jest wszystkie wejścia będą albo wzrost lub spadek zmieni swój aktualny stan
2. teraz b < = a + c teraz tutaj pełny sumator zostanie utworzony z "a" i "c" jako dane wejściowe, ale teraz zostanie wykonany projekt lub kompilator zsyntetyzuje obwód w taki sposób, że następne wyrażenie a = b tutaj drut jest wyciągany ze starej wartości, a nie ze zaktualizowanego b, i został dostarczony do ; tak po prostu
3. jeśli chcesz to samo wydarzy zapraszamy zrobić bez problemu wejdzie w syntezowalne