VHDL: Nazewnictwo i interpretacja architektury

Uwaga: używam ISE Xilinx i mam kartę FPGA do pracy (z przełącznikami i światłami itp.), I jak dotąd zhakowałem kilka prostych projektów. Jednocześnie czytam kilka samouczków, aby stworzyć podstawy tego, co robię.

Widziałem różne byty i ich architektury wspomniane w materiałach referencyjnych, przez które przechodziłem, ale nazewnictwo jest często mylące. Często zamiast „architektura RTL z ..” lub „architektura strukturalna ...” zobaczenia „architektura foo z ...”, a nawet „architektura łuk z ...”

Zdaję sobie sprawę (z opóźnieniem), że nazwa architektury jest tak samo dowolna jak nazewnictwo bytu, chociaż istnieją przewodniki po stylach, które sugerują bardziej spójne konwencje nazewnictwa, aby uniknąć tego problemu. To prowadzi mnie do kilku pytań:

• Patrząc na jednostkę, jak określić rzeczywisty model architektoniczny, który jest używany, bez podpowiedzi z nazwy architektury? RTL, behawioralne, strukturalne ... wydają się być bardzo podobne do oka mojego ucznia (zakładając, że przykłady, które widziałem, zostały właściwie nazwane). Pomocny byłby tu prosty, ale oczywisty przykład (lub wskaźnik do jednego).

• Jeśli określenie wielu architektur dla jednego obiektu (co, jak rozumiem, jest możliwe), po prostu nadajesz architekturom różne nazwy w tym samym pliku lub ...?

• Czy nazwy architektury są ograniczone do danego obiektu (to znaczy, czy jest jakiś problem z „przestrzeniami nazw” przy użyciu tej samej nazwy architektury w wielu obiektach)?

Edytuj: i jeszcze jeden:

• Wydaje się, że istnieje różnica między RTL i behawioralną, ale jak wspomniano powyżej, tak naprawdę nie widzę tego w przykładach, które widziałem (często widzę tylko jedną zdefiniowaną architekturę). Czy jedna architektura jest bardziej powszechna niż inne?

To, czego szukałem, to kompleksowy, ale prosty projekt wieloskładnikowy (małe komponenty), napisany przy użyciu najlepszych praktyk (prawidłowe nazewnictwo, nie wszystkie wtłoczone w jeden plik itp.), Ale jeszcze go nie znalazłem. Uważam, że odpowiednio wykonane przykładowe projekty są bardzo przydatne do wyjaśnienia podstawowych zasad i najlepszych praktyk. Jeśli znasz taki przykładowy projekt, byłbym wdzięczny za wskazówkę do tego. (Jeśli nic więcej, być może kiedy to rozwiążę, mogę podzielić się jednym z moich ...)

Patrząc na jednostkę, jak określić rzeczywisty model architektoniczny, który jest używany, bez podpowiedzi z nazwy architektury?

Nie możesz - kiedy jest tworzona instancja lub konfiguracja, możesz określić architekturę (jeśli jest więcej niż jedna do wyboru) lub domyślna zostanie wybrana dla ciebie.

Jeśli określenie wielu architektur dla jednego obiektu (co, jak rozumiem, jest możliwe), po prostu nadajesz architekturom różne nazwy w tym samym pliku lub ...?

Nadajesz im różne imiona. Nie musi znajdować się w tym samym pliku (w rzeczywistości VHDL obchodzi o wiele mniej niż myślisz o tym, co jest w jakim pliku)

Czy nazwy architektury są ograniczone do danego obiektu (to znaczy, czy jest jakiś problem z „przestrzeniami nazw” przy użyciu tej samej nazwy architektury w wielu obiektach)?

Są „przywiązani” do bytu, więc można je ponownie wykorzystać.

Często używam a1jako mojej architektury do wszystkiego, co można zsyntetyzować jako

• rtl implikuje niższy poziom (dla wielu czytelników) niż piszę na.
• behavioural często implikuje brak syntezy (dla niektórych czytelników)
• synth jest używany przez syntezator dla jego modelu (w przeciwnym razie użyłbym tego)

a1 jak dotąd nie był w konflikcie i nie powoduje zamieszania;)

Jeśli faktycznie mam więcej niż jedną architekturę, mam tendencję do nazywania ich słowami (na przykład hard_multipliersi lut_multipliersdla filtra, który tworzy - lub nie - bloki MUL18).

Bardzo często masz tylko jedną architekturę, więc to nie ma znaczenia. Dobre nazwy bytów są znacznie ważniejsze.

Wydaje się, że istnieje różnica między RTL i behawioralną, ale jak wspomniano powyżej, tak naprawdę nie widzę tego w przykładach, które widziałem (często widzę tylko jedną zdefiniowaną architekturę). Czy jedna architektura jest bardziej powszechna niż inne?

Jest historyczny - nie byłeś w stanie zsyntetyzować kodu „behawioralnego” (który w pewnym momencie obejmował dodawanie czegoś!) - więc stworzyłeś wersję RTL, która tworzyła addery i tym podobne. (Rozumiem to - piszę kod behawioralny (a jednak nadal syntezowalny), odkąd zacząłem VHDLing około 1999 roku!)

Oto typy architektury:

Behawioralne:

Ogólne notatki:

• Tradycyjnie brak heirarchii (tylko jeden plik, brak składowych składników), chociaż różni się to w zależności od narzędzi.
• Bardzo szybki do symulacji.
• Zachowania sygnałów są zdefiniowane.
• Gdy do symulacji wykorzystywany jest tylko behawioralny, może on zawierać kod niesyntetyzowalny. Zachowanie przeznaczone do syntezy musi naturalnie być syntezowalne.

Uwagi dotyczące Xilinx

• Generalnie podstawowe modele generatorów to pliki .vhd przed syntezą

Strukturalny:

Ogólna definicja

• Tworzy tylko instancje komponentów i łączy je ze sobą (hierarchicznie).
• Wolniej symulować niż behawioralny.
• Brak definicji rzeczywistego zachowania sygnału na najwyższym poziomie.
• Tylko kod syntezowalny.

Xilinx xpecific notes

• Modele generatorów rdzeniowych nie uwzględniają czasu.
• Generalnie podstawowe modele generatorów tworzą listy sieciowe po syntezie

Powyżej są w zasadzie tradycyjne dwa główne zwierzęta architektury. Bardzo często stosowana jest definicja „mieszana”, która zawiera właściwości obu.

RTL:

RTL, co tak naprawdę jest umieszczane na FPGA pod koniec dnia. Jest to więc kod, który można syntetyzować, który określa zachowanie systemu i składa się z hierarchii kodu:
dolne warstwy będą podlegały syntezie behawioralnej, w których zdefiniowano ziarnistość zachowania sygnału, a górne poziomy będą strukturalne, gdzie komponenty behawioralne są ze sobą powiązane, aby utworzyć duży „schemat blokowy” najwyższego poziomu.

Do wielu architektur:

Architektury mogą znajdować się w jednym pliku lub w wielu plikach. Jedyną ważną rzeczą jest to, że encja jest najpierw kompilowana, a architektura, która ma być użyta, jest określona.

Ta książka jest bardzo przydatna i całkiem dobrze opisuje takie rzeczy.

Nie ma twardej i szybkiej zasady dotyczącej tego, jak należy postępować w kategoriach posiadania odrębnych modeli behawioralnych i strukturalnych lub po prostu ich mieszania. Zwykle w dużych projektach oprogramowania układowego (lub w dużych korporacjach, w których kod jest współużytkowany i ponownie wykorzystywany), warto rozróżnić te dwa elementy, aby uprościć sprawy, jednak pod koniec dnia sprowadza się do tego, co działa dla Ciebie.

Przede wszystkim nie można tak ściśle kategoryzować projektów architektury świata rzeczywistego. Po co się ograniczać? Możesz utworzyć instancję innych jednostek i połączyć je „strukturalnie”, ale dodaj proces lub współbieżne przypisanie tu i tam, aby dodać logikę „rtl” i być może użyć pewnych „behawioralnych” wzorców kodowania, aby syntezator wyliczył niektóre szczegóły, na których ci nie zależy (np. dodawanie bez tworzenia instancji sumatora z parametrami obszar / potok / wydajność), wszystko w tej samej architekturze.

Co ważniejsze, musisz zrozumieć, co można syntetyzować w obecnych technologiach asic / fpga, a co nie, i to niezależnie od modelu architektury.

Encję można zaimplementować na wiele sposobów, nawet pozwalając na nieco inne zachowania, więc możesz mieć wiele architektur dla tej samej encji. Dodatkowo możesz mieć architekturę tylko do symulacji (zwykle nie syntezowalnej), która może symulować szybciej niż „prawdziwa” wersja, co może się przydać podczas testowania dużych projektów jako całości. Dałbyś tym architekturom nazwy, które pomogą ci zapamiętać, co odróżnia je od innych, a po prostu bhv / str / rtl zwykle nie jest wystarczający lub dokładny, biorąc pod uwagę hybrydowy charakter rzeczywistych projektów.

Jeśli chodzi o konkretne pytania, deklaracja architektury jest powiązana z nazwą encji, więc nie ma problemów z przestrzenią nazw z architekturami o tej samej nazwie dla różnych encji. Wystarczy użyć różnych nazw dla architektur dla tego samego obiektu.

Architektury mogą znajdować się w różnych plikach, wystarczy upewnić się, że deklaracja encji jest najpierw kompilowana.

Możesz wybrać architekturę, która ma być używana podczas tworzenia instancji lub za pomocą instrukcji konfiguracji. Jeśli nie, domyślną wartością jest „zwykle” ostatnia architektura, którą kompilator widział dla deklaracji danej jednostki.