Многомерные массивы VHDL: советы и хорошие методы проектирования

Question

Я работаю с Xilinx ISE на Spartan-6, который управляет сложной доской с несколькими функциями. Как вы можете себе представить, проект VHDL становится довольно сложным, и, как программист на C++, я чувствую необходимость использования массивов для уплотнения кода.

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

Итак, вот вопросы: какие меры предосторожности я должен иметь в виду при использовании массивов? Каковы наиболее важные методы проектирования с массивами? Будут ли у меня проблемы с имитацией подмодулей с последующей картой или после-PAR моделирования?

Answer 1

Я использую массивы для двух вещей.

Прежде всего, чтобы сделать код кратким и простым. Например:

signal cnt1 : unsigned(10 downto 0); 
signal cnt2 : unsigned(10 downto 0); 
... 
signal cnt9 : unsigned(10 downto 0); 

Может быть заменен:

type cnt_arr_t is array(1 to 9) of unsigned(10 downto 0); 
signal cnt : cnt_arr_t; 

Я никогда не имел «проблемы» в Xilinx, используя массивы, как это, они ведут себя так же, как определение кратные сигналов, они могут быть мульти- sizenal, вы можете передать их функции, иметь их на портах сущностей и т. д. Руководство пользователя XST указывает, что многомерные массивы не могут использоваться в качестве порта сущности, но Molten Zilmer использует их без проблем.

Второе, более распространенное использование массивов - определение памяти (ОЗУ, ПЗУ, двухпортовая оперативная память и т. Д.). В этом случае вы должны быть осторожны, как вы используете массив, или дизайн не будет отображаться на ресурсы памяти. В памяти 512x32 используется 1 blockRAM или много LUT/register. Память меньше, быстрее и менее энергоемкой для больших значений глубины.

Посмотрите на XST synthesis guide, как использовать массив для определения памяти. Как правило, ваши индексы массива должны начинаться с 0 (от 1 до 2048 не равно 0 до 2047). Кроме того, многомерные массивы не сопоставляются с ресурсами памяти, по крайней мере, когда я пробовал это с более старой версией XST. В противном случае массивы std_logic_vector/unsigned и массивы записей прекрасны.

Вы всегда должны смотреть на сводный отчет, чтобы убедиться, что XST понимает ваш код так, как вы планируете. Сообщается о каждом отображении памяти с его режимом, глубиной, шириной и т. Д. Это лучший способ определить ошибки неправильного толкования.

Должен признаться, что мне никогда не нужно делать моделирование после карты/PAR, поэтому я не могу сказать вам, возникнут ли у вас проблемы.

Answer 2

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

Возможно, будет сложно определить «новое имя» для вашего массива из-за оптимизаций/переименований, но это не следует путать с другой реализацией дизайна на аппаратном уровне.

При использовании массивов синтаксис может быть особенно затруднительным при работе с инициализацией. Обязательно обратитесь к справочному руководству по синтезатору или руководству пользователя для синтаксиса и конструкций поддержки.

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

Answer 3

Массивы и записи и их комбинации являются одной из самых сильных сторон VHDL и позволяют создавать функциональный, читаемый, масштабируемый и поддерживаемый код. Эти типы всегда были в VHDL, и у меня не возникало проблем с инструментами из-за этих типов. Инструменты VHDL, как правило, настолько зрелы, что в более тонких функциях вы можете столкнуться с ошибками.

Если вы столкнулись с изменениями интерфейса в списке соединений post-map/PAR, то я думаю, что это должны быть адреса обертки вокруг дизайна, чтобы вписаться в существующий стенд.

Поскольку большинство проверок симуляции (должно быть) выполнено на уровне VHDL (любое моделирование после карты/PAR - только для проверки работоспособности STA), гораздо важнее иметь высокий уровень и абстрактный вид дизайн во время такой симуляции и отладки, вместо того, чтобы проектировать на уровне бит, чтобы сделать совпадение дизайна при моделировании после карты/PAR.