Jakie są najlepsze praktyki dla języków opisu sprzętu (Verilog, VHDL itp.) [zamknięte]

Coś w stylu starego wątku, ale chciałem włożyć moje 0,02$. To nie jest tak naprawdę specyficzne dla Verilog/VHDL.. więcej na temat projektowania sprzętu w ogóle... specjalnie syntetyzowany projekt dla niestandardowych ASICs.

Oto moja opinia oparta na wieloletnim (w przeciwieństwie do akademickiego) doświadczeniu w projektowaniu. Nie są w określonej kolejności

Moje oświadczenie parasol jest do projektowania dla walidacji wykonania. W projektowaniu sprzętu Walidacja jest najważniejsza. Błędy są dużo droższe kiedy znajduje się w prawdziwym krzemie. Nie możesz po prostu ponownie skompilować. Dlatego pre-krzem jest znacznie bardziej skoncentrowany.

• Poznaj różnicę między ścieżkami sterowania a ścieżkami danych. Pozwala to na stworzenie o wiele bardziej eleganckiego i łatwego do utrzymania kodu. Pozwala również na zapisywanie bramek i minimalizowanie propagacji X. Na przykład ścieżki danych nigdy nie powinny wymagać resetowalnych flopów, ścieżki sterowania zawsze powinny tego potrzebować.

• Udowodnij funkcjonalność przed walidacją. Albo przez podejście formalne lub poprzez przebieg. Ma to wiele zalet, wyjaśnię 2. Po pierwsze, pozwoli Ci zaoszczędzić zmarnowany czas obierania cebuli przez problemy. W przeciwieństwie do wielu projektów na poziomie aplikacji (esp podczas nauki) i większości kursów, czas zmiany kodu jest bardzo duży (od 10 minut do dni, w zależności od złożoności). Za każdym razem, gdy zmieniasz kod, musisz przejść przez opracowanie, sprawdzenie lint, kompilację, wywołanie przebiegu i wreszcie rzeczywistą symulację.. które mogą samo zajmuje godziny. Po drugie, jest znacznie mniej prawdopodobne, że masz trudne do trafienia narożne przypadki. Uwaga dotyczy to walidacji wstępnej krzemu. Te z pewnością uderzą w post-silicon, kosztując Cię dużo $$$. Zaufaj mi, początkowy koszt udowodnienia funkcjonalności znacznie minimalizuje ryzyko i jest wart wysiłku. Czasami trudno jest przekonać niedawnych absolwentów college ' u.

• Zjedz "chicken bits". Kawałki kurczaka są bitami w MMIO ustawionymi za pomocą sterownika, aby wyłączyć funkcję w silikon. Jego celem jest przywrócenie wprowadzonych zmian, w których zaufanie nie jest wysokie (zaufanie jest wprost proporcjonalne do wysiłków walidacji). Prawie niemożliwe jest trafienie w każdy możliwy stan pre-krzemu. Zaufanie do twojego projektu nie może być naprawdę spełnione, dopóki nie zostanie udowodnione w post-silikonie. Nawet jeśli tylko 1 Stan zostanie trafiony 0.000005% czasu, który ujawnia błąd, zostanie trafiony w post-silicon, ale niekoniecznie w pre-silicon.

• Unikaj WYJĄTKÓW w kontroli ścieżka za wszelką cenę. Każdy nowy wyjątek podwaja twoje wysiłki walidacyjne. Trudno to wyjaśnić. Powiedzmy, że istnieje blok DMA, który zapisuje dane do pamięci, której będzie używał inny blok. Powiedzmy, że zapisana struktura danych zależy od wykonywanej funkcji. Jeśli zdecydowałeś się zaprojektować tak, aby zapisywana struktura danych była różna między różnymi funkcjami, po prostu pomnożyłeś swoje wysiłki walidacyjne przez liczbę funkcji DMA. Jeśli zasada ta jest przestrzegana, zapisana struktura danych byłaby super-zbiorem wszystkich danych dostępnych dla każdej funkcji, w której lokalizacje treści są zakodowane na twardo. Gdy logika zapisu DMA zostanie zweryfikowana dla 1 funkcji, zostanie ona zweryfikowana dla wszystkich funkcji.

• Minimalizuj interfejsy(Czytaj Minimalizuj ścieżki sterowania). Jest to związane z minimalizacją WYJĄTKÓW. Po pierwsze, każdy nowy interfejs wymaga walidacji. Obejmuje to nowe kontrolery/trackery, twierdzenia, punkty zasięgu i Modele funkcjonalne magistrali w testbenchu. Po drugie, może zwiększyć twoje wysiłki walidacyjne wykładniczo! Powiedzmy, że masz 1 interfejs do odczytu danych w pamięci podręcznej. Teraz powiedzmy (z jakiegoś dziwnego powodu) decydujesz, że chcesz inny interfejs do czytania pamięci głównej. Właśnie czterokrotnie zwiększyłeś swoje wysiłki. Teraz musisz zweryfikować te kombinacje w dowolnym momencie N :

  • no cache read, no memory read
  • no cache read, memory read
  • Cache read, no memory read
  • Cache read, memory Czytaj

• Zrozumieć i komunikować założenia. Brak tego jest głównym powodem blokowania problemów komunikacyjnych. Możesz mieć idealny blok w pełni zweryfikowany.. jednak bez zrozumienia wszystkich założeń, Twój blok zawiedzie, gdy jest połączony.

• Zminimalizować potencjalne Stany. Im mniej stanów (zamierzonych lub niezamierzonych) ma projekt, tym mniejszy wysiłek wymagany do walidacji. Dobrą praktyką jest grupowanie funkcji podobnych do 1 najwyższego poziomu funkcji (jak sekwencery i arbitry). Bardzo trudno jest zidentyfikować i zdefiniować tę funkcję wysokiego poziomu tak, aby obejmowała ona jak najwięcej mniejszych funkcji, ale w ten sposób znacznie eliminujesz stan i z kolei potencjał błędów.

• Zawsze zapewnij silny sygnał wychodzący z bloku. W większości przypadków jest to rozwiązanie. Nie masz pojęcia, co zrobią z nim bloki punktów końcowych. Możesz napotkać problemy z czasem, które mogą mieć bezpośredni wpływ na Twoja doskonała realizacja.

• Unikaj mealy typu FSMs, chyba że wydajność ma negatywny wpływ. Mealy FSMs są bardziej prawdopodobne, aby produkować problemy z czasem nad Moore

• .. i wreszcie ten, którego najbardziej Nie lubię: "jeśli nie jest zepsuty, nie naprawiaj go" ze względu na związane z tym ryzyko i wysoki koszt błędów, wiele razy hacking jest bardziej praktycznym rozwiązaniem do rozwiązywania problemów. Inni wymykają się temu, wspominając o wykorzystaniu istniejących komponenty.

Co do porównania z bardziej tradycyjnym projektowaniem oprogramowania:

• Programowanie dyskretne oparte na zdarzeniach to zupełnie inny paradygmat. Ludzie widzą składnię veriloga i myślą "oh, its just like C"... nie może to jednak być dalsze od prawdy. Chociaż składnia jest podobna, trzeba myśleć inaczej. Na przykład tradycyjny debugger jest praktycznie bez znaczenia w syntezowalnym RTL (konstrukcja Testbench jest inna). Waveforms on papier to najlepsze dostępne narzędzie. Jednak, biorąc to pod uwagę, FSM design może czasami naśladować programowanie proceduralne. Ludzie z zapleczem programistycznym mają tendencję do szaleństwa z FSMs (wiem, że na początku tak było).

• System Verilog ma wiele i wiele (i wiele) specyficznych funkcji testbench. Jest całkowicie zorientowany obiektowo. Jeśli chodzi o projekt testbench, jest bardzo podobny do tradycyjnego projektowania oprogramowania. Jednak ma jeszcze 1 wymiar związany z nim, że czasu. wyścig warunki i opóźnienia protokołu muszą być rozliczane

• Jeśli chodzi o walidację, to również jest inna (i taka sama). Istnieją 3 główne podejścia;

  • Formalna weryfikacja propagacyjna (FPV): za pomocą logiki udowadniasz, że zawsze będzie działać
  • kierowane testy losowe. Losowo ustawia opóźnienia, wartości wejściowe i włączanie funkcji zgodnie z definicją zalążka. skierowane oznacza, że ziarno obciąża ścieżki, które mają mniejszą pewność siebie. Podejście to wykorzystuje pokrycie punkty wskazujące zdrowie
  • badanie ostrości. Jest to podobne do tradycyjnego testowania oprogramowania

... aby uzyskać kompletność, muszę również omówić najlepsze praktyki projektowania stanowisk testowych... ale to na inny dzień

Przepraszam za Długość.. Byłem w "strefie":)

HDL jest jak Verilog i VHDL naprawdę zachęcają do spaghetti code. Większość modułów składa się z kilku bloków 'always' (Verilog) lub 'process' (VHDL), które mogą być w dowolnej kolejności. Ogólny algorytm lub funkcja modułu jest często całkowicie zasłonięta. Zastanawianie się, jak działa kod (jeśli go nie napisałeś) jest bolesnym procesem.

Kilka lat temu natknąłem się naTen artykuł , który przedstawia bardziej ustrukturyzowaną metodę projektowania VHDL. Podstawową ideą jest to, że każdy moduł ma tylko 2 bloki procesowe. Jeden dla kodu kombinatorycznego, a drugi dla synchronicznego (rejestrów). Świetnie nadaje się do tworzenia czytelnego i łatwego do utrzymania kodu.

• W HDL, niektóre części kodu mogą działać w tym samym czasie, na przykład dwie linie kodu "mogą działać" w tym samym czasie, jest to zaleta, mądrze używać. jest to coś, co programista, który jest przyzwyczajony do języków liniowych, może być trudne do uchwycenia na początku: {]}

  • długie i specyficzne dla Twoich potrzeb rurociągi mogą być tworzone.
  Możesz sprawić, że Twoje Duże moduły będą działać w tym samym czasie.
• zamiast jednej jednostki do powtarzania akcji na różnych danych, możesz utworzyć kilka jednostek i wykonywać pracę równolegle.

Debugowanie na sprzęcie jest zwykle znacznie trudniejsze niż debugowanie oprogramowania, więc:

• Preferowany jest prosty kod, czasami są inne sposoby na przyspieszenie kodu, po jest już uruchomiony, na przykład przy użyciu szybszego układu, itp".

• Unikaj "inteligentnych" protokołów między komponentami.

• Działający kod w HDL jest cenniejszy niż w przypadku innego oprogramowania, ponieważ sprzęt jest tak trudny do debugowania, ponownego użycia, a także rozważyć użycie "bibliotek" modułów, które niektóre są wolne, a inne sprzedawane.

• Projektowanie powinno uwzględniać nie tylko błędy w kodzie HDL, ale także awarie na procesorze, który programujesz, i na innych urządzeniach sprzętowych, które łączą się z chipem, więc naprawdę należy pomyśleć o projekt, który jest łatwy do sprawdzenia.

Kilka porad debugowania:

• Jeśli projekt zawiera kilka bloków konstrukcyjnych, prawdopodobnie chciałbyś stworzyć linie od interfejsów między tymi blokami do punktów testowych poza chipem.

• Będziesz chciał zapisać wystarczającą ilość linii w projekcie, aby przekierować interesujące dane do kontroli za pomocą urządzeń zewnętrznych. możesz również użyć tych linii i kodu jako sposobu na poinformowanie Cię o bieżącym stanie wykonania - na przykład, jeśli otrzymasz dane w niektórych punkt, piszesz jakąś wartość do linii, na późniejszym etapie wykonania piszesz inną wartość, itd '

  Jeśli twój chip jest rekonfigurowalny, stanie się to jeszcze bardziej przydatne, ponieważ możesz dostosować konkretne testy i przeprogramować wyjścia dla każdego testu w miarę upływu czasu (wygląda to bardzo dobrze z diodami LED :). )

Edit:

Powodem jest to - Fidning bugs "wewnątrz" FPGA/ASIC jest releivly łatwe, jak masz symulatory. Więc jeśli masz pewność, że dane są dostarczane tak, jak chcesz, i wychodzą, jak Twój program je wysyła, osiągnęliście Hardware utopia - możliwość pracy na poziomie oprogramowania:) (z symulatorem). Ale jeśli Twoje dane nie docierają do ciebie, tak jak chcesz i masz żeby dowiedzieć się dlaczego... będziesz musiał połączyć się z liniami, a to nie jest takie proste.

Znalezienie błędu na liniach jest trudne, ponieważ musisz połączyć się z liniami za pomocą specjalnego sprzętu, który rejestruje Stany linii, w różnym czasie, i musisz upewnić się, że Twoje Linie działają zgodnie z protokołem.

Jeśli musisz połączyć dwie jednostki fizyczne, aby "protokół" był tak prosty, jak to tylko możliwe , do tego stopnia, że nie będzie nazywany protokołem :) Na przykład, jeśli jednostki dzielą zegar, dodają x linii danych między nimi i sprawiają, że jedna jednostka zapisuje te, a druga odczytuje, na przykład przekazując jedno "słowo", które ma x Bity między nimi przy każdym upadku zegara. Jeśli masz FPGA, jeśli oryginalna częstotliwość zegara jest zbyt szybka dla równoległych danych - możesz kontrolować prędkość tego, zgodnie z eksperymentami, na przykład sprawiając, że dane pozostają na liniach co najmniej " t " cykli zegara itp. Zakładam, że równoległy transfer danych jest prostszy, ponieważ można pracować z niższym stawki zegarowe i uzyskać te same występy, bez konieczności dzielenia słów na jednym urządzeniu i ponownie montować na drugim. (mam nadzieję, że nie ma opóźnienia między "zegarem" każda jednostka otrzymuje). Nawet to jest chyba zbyt skomplikowane:)

Odnośnie SPI, I2C itp ' nie zaimplementowałem żadnego z nich, Mogę powiedzieć, że podłączyłem nogi dwóch FPGA działających z tego samego zegara (nie pamiętam dokładnego formowania rezystorów w środku), w znacznie wyższych częstotliwościach, więc naprawdę nie mogę wymyślić dobrego powód, aby ich używać, jako głównego sposobu przekazywania danych między własnymi FPGA, chyba że FPGA znajdują się bardzo daleko od siebie, co jest jednym z powodów, aby używać szeregowej, a nie równoległej magistrali.

JTAG jest używany przez niektóre firmy FPGA do testowania/programowania swoich produktów, ale nie jest pewien, czy jest używany jako sposób transportu danych z dużą prędkością i jest protokołem... (nadal taki, który może mieć wbudowaną obsługę chipów).

Jeśli musisz zaimplementować jakiś znany protokół, rozważ użycie gotowego kodu HDL do tego - który można znaleźć lub kupić.

To jest pytanie, które wymaga 10 przykazań JBDAVID do projektowania sprzętu.

1. Użyj kontroli wersji / wersji, tak jak w oprogramowaniu. SVN i Hg są bezpłatne.
2. Wymagaj, aby Kod przeszedł kontrolę składni przed odprawą. Narzędzie LINT jest lepsze.
3. Użyj pełnego języka weryfikacji sprzętu do weryfikacji projektu. System-Verilog to niemal bezpieczny wybór.
Śledź Błędy. Bugzilla i gnaty to darmowe narzędzia. FogBugz wymaga trochę $.
4. Użycie Twierdzenia, aby złapać problemy z nieprawidłowym użyciem.
5. Triada pokrycia zapewnia stabilny projekt: pokrycie kodu miary, pokrycie funkcjonalne i pokrycie twierdzeń zarówno w narzędziach symulacyjnych, jak i formalnych.
6. władza jest Królem: użyj CPF lub UPF, aby przechwycić, wyegzekwować i zweryfikować swoje intencje dotyczące władzy.
7. prawdziwy projekt jest często mieszanym sygnałem, użyj języka mieszanego sygnału, aby zweryfikować analogowy z cyfrowym. Verilog-AMS jest jednym z takich rozwiązań. Ale nie przesadzaj. Modelowanie Realnumber może osiągnij większość funkcjonalnych aspektów zachowania mieszanego sygnału.
8. Użyj akceleracji sprzętowej, aby zweryfikować oprogramowanie, które musi współpracować z silikonem!
9. edytory tekstu świadome składni dla HDL/HVL są minimalnym wymogiem dla programisty IDE.

Dla FPGA, Xilinx ma tę świetną stronę (Brak, nowa lokalizacja). Prawie wszystkie mają zastosowanie do innych dostawców FPGA lub mają równoważne Zasady. Wiele ma zastosowanie do projektów ASIC.

Altera ma zalecane Style kodowania HDL (PDF) i zalecenia projektowe dla Altery Urządzenia i Asystent projektu Quartus II . Altera ma ten kurs płatny . Chodzi jednak bardziej o produktywność. Nie mam innych informacji, jak dobry jest.