Синтезатор заботится об одном или двух процессах?

Question

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

Я ищу воспроизводимых экспериментов : код VHDL для двух стилей кодирования и особенности их синтеза (чтоинструмент, параметры которого).

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

Answer 1

Большая часть такого рода «знаний» основана на инструментах, которые были около 20 лет назад. Дела пошли дальше.

Это не значит, что все исправлено во всех случаях, но вы делаете правильные вещи, фактически проводя испытания.

Другие вещи, которых в прошлом избегали:

• Дженерики, потому что, по-видимому, они несинтезируемы. Не правда, и гораздо лучше, чем
  код предварительной обработки, который обычно защищается.
• Записи по портам. Это долго вызывало проблемы с DC-оболочкой. Было бы неправильно подключиться вещи. Я не знаю, решено ли это.
• Различные стили синхронного процесса, особенно те, которые используют wait вместо списка чувствительности. Это особенно безумно, потому что если вы читаете спецификацию VHDL, там написано, что они эквивалентны и должны быть реализованы одинаково.

Answer 2

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

Я даже не знаю, использовал ли он как проблему со старомодными синтезаторами или люди просто предполагали, что это так!

Answer 3

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

//Instances 1 clock gate
reg [7:0] value;
always @(posedge i_clk)
  if(enable)
    value <= new_value; 

//Instances 8 muxes
always @(posedge i_clk)
  if(enable)
    value <= new_value;
  else //Exhaustive so assignment always occurs
    value <= value;

В первом примере будет использоваться один тактовый шлюз для часов во всех восьми DFF.Во втором примере будет использовано 8 мультиплексоров, возвращающих выходные данные каждого DFF на вход.В зависимости от площади и соотношения мощности затворов часов и мультиплексоров, различия могут быть значительными.Это было проверено на Talus.

Конечно, условие else во втором примере бесполезно, но смысл эксперимента состоял в том, чтобы увидеть, насколько хорошо инструмент обрабатывает сложные операторы casez / x и разделяет разрешения для блоков всегда.Для FSM я бы предпочел использовать синтаксис, если FSM обнаружен.Я основываю это на том, как XST обрабатывает их, и на том, что оптимизация конечного автомата является очень зрелой темой.