Насколько дорого стоит преобразование типов данных в сравнении с манипуляцией битовыми массивами в VHDL?

В VHDL, если вы хотите увеличить std_logic_vector, который представляет реальное число на единицу, я столкнулся с несколькими вариантами.

1) Используйте функции преобразования типов данных для преобразования вектора std_logic в знаковое или беззнаковое значение, затем преобразуйте его в целое число, добавьте единицу к этому целому числу и преобразуйте его обратно в std_logic_vector противоположным образом, чем раньше. Приведенная ниже диаграмма очень удобна при попытке сделать это.

Диаграмма преобразования чисел в векторы

2) Проверьте, чтобы увидеть значение МЛАДШИЙ БИТ. Если это "0", сделайте его "1". Если это '1', Сделайте "сдвиг влево" и соедините '0' С LSB. Пример: (для 16-битного вектора) вектор (15 вниз 1) & '0';

В ПЛИС, по сравнению с микропроцессором, физические аппаратные ресурсы, по-видимому, являются ограничивающим фактором вместо фактического времени обработки. Всегда есть риск, что вы можете выбежать из физических ворот.

Итак, мой реальный вопрос заключается в следующем: какая из этих реализаций "дороже" в FPGA и почему? Достаточно ли надежны компиляторы для реализации одного и того же физического представления?

3 5
fpga

3 ответа:

Ни одна из конверсий типов не стоит.

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

Преобразование типов - это ваш способ сказать компилятору: "да, я хотел это сделать".

Используйте тип, который наилучшим образом выражает замысел проекта.

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

Затем преобразуйте, когда это необходимо : часто на портах верхнего уровня или IP других людей.

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

Что касается вашего варианта 2: низкий уровень детализации описания не только труднее понять, чем a <= a + 1;, но они не легче для инструментов синтезатора для перевода и, скорее всего, содержат ошибки.

14

Я даю другой ответ, чтобы лучше ответить, почему с точки зрения Гейтса и ресурсов FPGA действительно не имеет значения, какой метод вы используете. В конце концов, логика будет реализована в Look-Up-таблицах и шлепанцах. Обычно (или всегда?) в структуре ПЛИС нет собственных счетчиков. Синтез превратит ваш код в LUTs, точка. Я всегда рекомендую попытаться выразить код как можно проще. Чем больше вы пытаетесь написать свой код в RTL (по сравнению с поведенческим), тем больше он подвержен ошибкам. быть. Поцелуй-это правильный курс действий каждый раз, инструмент синтеза, если он хорош, максимально упростит ваше намерение.

0

Единственная причина реализовать арифметику вручную, если вы:

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

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

Кстати, довольно стандартная уловка для снижения стоимости аппаратных счетчиков заключается в том, чтобы избежать обычной двоичной арифметики и вместо нее использовать, например, счетчики LFSR. Смотрите Xilinx XAPP 052 для некоторых вдохновение в этой области, если вы заинтересованы в ПЛИС (это довольно старый, но общие принципы те же в текущих Плис).
0