VHDL: архитектура именования и интерпретации

Примечание: я использую ISE Xilinx и у меня есть плата ПЛИС для работы (с переключателями, лампами и т. Д.), И я до сих пор собирал несколько простых проектов. В то же время я читаю несколько учебных пособий, чтобы заложить основу для того, что я делаю.

Я видел различные объекты и их архитектуры, упомянутые в справочных материалах, которые я просматривал, но названия часто вводят в заблуждение. Часто вместо «архитектура ртл из ..» или «архитектура структурная из ...» я буду видеть «архитектура фу из ...» или даже «архитектура арка из ...»

Я понимаю (с опозданием), что имя архитектуры столь же произвольно, как и наименование объекта, хотя есть руководства по стилю, которые предлагают более согласованные соглашения об именах, чтобы избежать этой проблемы. Это приводит меня к нескольким вопросам:

• Глядя на сущность, как можно определить фактическую используемую архитектурную модель без подсказок из названия архитектуры? RTL, поведенческие, структурные ... они очень похожи на взгляд моего ученика (при условии, что примеры, которые я видел, были названы правильно). Здесь может быть полезен простой, но очевидный пример (или указатель на него).

• Если вы указываете несколько архитектур для одного объекта (что, как я понимаю, возможно), вы просто даете архитектурам разные имена в одном файле или ...?

• Ограничены ли имена архитектуры определенным объектом (то есть, есть ли проблема с «пространствами имен» при использовании одного и того же имени архитектуры для нескольких объектов)?

Редактировать: и еще один:

• Кажется, есть различие между RTL и поведенческим поведением, но, как уже упоминалось выше, я не вижу этого в примерах, которые я видел (часто я вижу только одну архитектуру, которая определяется). Является ли одна архитектура более распространенной, чем другие?

То, что я искал, - это всеобъемлющий, но простой многокомпонентный проект (маленькие компоненты), написанный с использованием лучших практик (правильное именование, не все в одном файле и т. Д.), Но я пока не нашел его. Я считаю, что правильно созданные примеры проектов очень полезны для освещения основных принципов и лучших практик. Если вы знаете такой пример проекта, я был бы признателен за указание на это. (Если ничего другого, возможно, когда я это выясню, я смогу поделиться своим собственным ...)

Глядя на сущность, как можно определить фактическую используемую архитектурную модель без подсказок из названия архитектуры?

Вы не можете - когда он создается или конфигурируется, можно указать архитектуру (если есть несколько вариантов) или для вас будет выбрано значение по умолчанию.

Если вы указываете несколько архитектур для одного объекта (что, как я понимаю, возможно), вы просто даете архитектурам разные имена в одном файле или ...?

Вы даете им разные имена. Это не обязательно должно быть в одном файле (на самом деле VHDL заботится намного меньше, чем вы думаете о том, что находится в каком файле)

Ограничены ли имена архитектуры определенным объектом (то есть, есть ли проблема с «пространствами имен» при использовании одного и того же имени архитектуры для нескольких объектов)?

Они «привязаны» к сущности, поэтому могут быть использованы повторно.

Я часто использую в a1качестве своей архитектуры все, что можно синтезировать как

• rtl подразумевает более низкий уровень (для многих читателей), чем я пишу.
• behavioural часто подразумевает несинтезируемый (для некоторых читателей)
• synth используется синтезатором для своей модели (в противном случае я бы использовал это)

a1 до сих пор не был конфликтным и не вызывает путаницы;)

Если я на самом деле имею более чем одну архитектуры, я склонен называть их пространно (например , hard_multipliersи lut_multipliersдля фильтра , который создает экземпляр - или нет - MUL18 блоков).

Очень часто у вас есть только одна архитектура, поэтому это не имеет значения. Хорошие имена сущностей гораздо важнее.

Кажется, есть различие между RTL и поведенческим поведением, но, как уже упоминалось выше, я не вижу этого в примерах, которые я видел (часто я вижу только одну архитектуру, которая определяется). Является ли одна архитектура более распространенной, чем другие?

Это исторически - раньше вы не могли синтезировать «поведенческий» код (который в один момент включал в себя такие вещи, как добавление!) - поэтому вы создали RTL-версию, в которой были созданы сумматоры и тому подобное. (Это, как я понимаю, - я писал поведенческий (и все еще синтезируемый) код, так как я начал VHDLing примерно в 1999 году!)

Вот типы архитектуры:

Поведенческие:

Главные примечания:

• Традиционно нет иерархии (только один файл, экземпляры не создаются), хотя это зависит от инструментов.
• Очень быстро симулировать.
• Сигналы поведения определены.
• Когда для моделирования используется только поведение, оно может содержать несинтезируемый код. Поведенческий, предназначенный для синтеза, естественно, должен быть синтезируемым.

Xilinx конкретные заметки

• Обычно модели генераторов ядра представляют собой файлы предварительного синтеза .vhd.

Структурный:

Общее определение

• Только создает экземпляры компонентов и связывает их вместе (иерархически).
• Имитация медленнее, чем поведенческая.
• Нет реального определения поведения сигнала на верхнем уровне.
• Только синтезируемый код.

Xilinx специфические ноты

• Модели генераторов ядра не принимают во внимание время.
• Как правило, модели генераторов ядра создают списки соединений после синтеза

Выше это в основном традиционные два основных животных архитектуры. Очень часто используется «смешанное» определение, которое содержит свойства обоих.

RTL:

RTL, что на самом деле ставится на ПЛИС в конце дня. Таким образом, это синтезируемый код, который определяет поведение системы и состоит из иерархии кода:
нижние уровни будут синтезируемыми поведенческими, где определяется тонкость поведения сигнала, а верхние уровни будут структурными, где поведенческие компоненты связаны между собой, чтобы создать «блок-схему» верхнего уровня, если хотите.

На нескольких архитектурах:

Архитектуры могут быть все в одном файле или в нескольких файлах. Единственная важная вещь - это то, что объект компилируется первым, и указывается используемая архитектура.

Эта книга очень удобна и подробно описывает подобные вещи.

Не существует жесткого и быстрого правила о том, как следует действовать, имея в виду наличие различных поведенческих и структурных моделей или просто их смешение. Обычно в огромных разработках микропрограмм (или в больших корпорациях, где код используется совместно и повторно используется), полезно различать их для упрощения, но в конце концов все сводится к тому, что вам подходит.

Прежде всего, проекты архитектуры реального мира не могут быть строго категоризированы таким образом. Зачем себя ограничивать? Возможно, вы захотите создать другие объекты и соединить их «структурно», но добавьте процесс или одновременное назначение здесь и там, чтобы добавить некоторую логику «rtl», и, возможно, использовать некоторые «поведенческие» шаблоны кодирования, чтобы синтезатор вычислил некоторые из подробности, которые вас не волнуют (например, добавление без создания экземпляра сумматора с параметрами area / pipelining / performance) - все в одной архитектуре.

Что еще более важно, вы должны понимать, что синтезируется в современных технологиях asic / fpga, а что нет, и это независимо от модели архитектуры.

Сущность может быть реализована несколькими способами, даже если допускается немного другое поведение, поэтому у вас может быть несколько архитектур для одной и той же сущности. Кроме того, у вас может быть архитектура только для симуляции (обычно не синтезируемая), которая может симулировать быстрее, чем «реальная» версия, что может пригодиться при тестировании для больших проектов в целом. Вы бы дали этим архитектурам имена, которые помогут вам вспомнить, что отличает их от других, и просто bhv / str / rtl обычно недостаточно или точно, учитывая гибридную природу проектов реального мира.

Что касается ваших конкретных вопросов, объявление архитектуры связано с именем объекта, поэтому не возникает проблем с пространством имен для архитектур с одним и тем же именем для различных объектов. Просто используйте разные имена для архитектур для одного и того же объекта.

Архитектуры могут находиться в разных файлах, вам просто нужно сначала убедиться, что объявление сущности скомпилировано.

Вы можете выбрать, какую архитектуру использовать при создании экземпляра объекта или с помощью операторов конфигурации. Если вы этого не сделаете, по умолчанию будет «обычно» последняя архитектура, которую компилятор видел для данного объявления сущности.