2015-07-13 8 views
6

Предположим, что мне нужно протестировать разные биты на std_logic_vector. было бы лучше реализовать один процесс, который для циклов для каждого бита или для создания «n» процессов с использованием for-generate, на котором каждый процесс проверяет один бит?Какова практическая разница между внедрением FOR-LOOP и FOR-GENERATE? Когда лучше использовать один над другим?

FOR-LOOP

my_process: process(clk, reset) begin 
    if rising_edge (clk) then 
    if reset = '1' then 
     --init stuff 
    else 
     for_loop: for i in 0 to n loop 
     test_array_bit(i); 
     end loop; 
    end if;  
    end if; 
end process; 

FOR-GENERATE

for_generate: for i in 0 to n generate begin 
my_process: process(clk, reset) begin 
    if rising_edge (clk) then 
    if reset = '1' then 
     --init stuff 
    else 
     test_array_bit(i); 
    end if; 
    end if; 
end process; 
end generate; 

Что бы влияние на FPGA и ASIC реализаций для этих случаях? С чем легко справиться с инструментами САПР?

EDIT: Просто добавить ответ я дал одному помочь парню, чтобы сделать мой вопрос более ясно:

Например, когда я побежал кусок кода, используя для петель на ISE, резюме синтез дал мне справедливый результат, занять много времени, чтобы вычислить все. когда я перекодировал свой дизайн, на этот раз используя for-generate и несколько процессов, я использовал немного больше области, но инструмент смог быстрее вычислить все, и мой результат синхронизации был лучше. Итак, подразумевает ли это правило, которое всегда лучше использовать для генерирования со стоимостью дополнительной области и меньшей сложности, или это один из случаев, когда я должен проверять каждую возможность реализации?

ответ

3

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

Понять, что поскольку цикл for выполняется за один такт, синтез разворачивает его и генерирует отдельный экземпляр test_array_bit для каждого входного бита. Поэтому вполне возможно, что средства синтеза могут генерировать идентичную логику для обеих версий - по крайней мере, в этом простом примере.

И на этой основе я бы (незначительно) предпочел вариант for ... loop, потому что он локализует программную логику, тогда как «генерирующая» версия глобализирует ее, размещая ее вне шаблона process. Если вы обнаружите, что версия loop немного легче читать, вы согласитесь на каком-то уровне.

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

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

Различные варианты инструментов удаляют (и изредка вводят) такие дефекты. Вы можете обнаружить, что опция «Использовать новый парсер» от ISE (для частей до Spartan-6) или Vivado или Synplicity вернет это, где нет старшего парсера ISE. (Например, передача сигналов из процедур, старые версии ISE имели серьезные ошибки).

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

Если вы обнаружите что-то конкретное таким образом, стоит сообщить об этом (отвечая на свой вопрос). Xilinx использовал, чтобы поощрять сообщать о таких дефектах через свою систему Webcase; в конце концов они были даже исправлены! Кажется, они прекратили это, в последние год-два.

0

Первый фрагмент будет эквивалентен следующему:

my_process: process(clk, reset) begin 
    if rising_edge (clk) then 
    if reset = '1' then 
     --init stuff 
    else 
     test_array_bit(0); 
     test_array_bit(1); 
     ............ 
     test_array_bit(n); 
    end if;  
    end if; 
end process; 

В то время как второй будет генерировать n+1процессов для каждого i, вместе с логикой сброса и все (что может быть проблемой, как логика будет пытаться управлять одними и теми же сигналами из разных процессов).
В целом, циклы for представляют собой последовательные операторы, содержащие последовательные операторы (т.е. каждая итерация последовательно выполняется после предыдущего). Контуры for-generate являются параллельными операторами, содержащими параллельные операторы, и именно так вы можете использовать его, например, для создания нескольких экземпляров компонента.

+0

Привет, Евгений, большое спасибо за ответ. Мне очень жаль, но я должен был более четко ответить на мой вопрос. Я знаю основы кодирования и «логические» последствия использования обеих структур. Я сомневаюсь в практическом результате их использования. Я использовал пример с одним простым вектором так же, как и в случае с шоу, но на практике все усложняется. Итак, переформулируем: если у меня есть кусок кода, который должен дать мне ответ за один такт (или запустить все его содержимое параллельно, если это будет лучше), то с физической точки зрения lvl будет лучшей реализацией стратегия? –

+0

Например, когда я запускаю фрагмент кода с использованием for-loops на ISE, обобщение сводки дало мне справедливый результат, за считанные секунды вычислить все. Итак, это подразумевает правило, которое всегда лучше использовать для генерирования со стоимостью дополнительной области или это один из случаев, когда я должен проверять каждую возможность реализации? –

+0

Более быстрое вычисление было результатом параллельного характера второй реализации. И, как всегда, существует компромисс с количеством используемых ресурсов. Если вы посмотрите на схему RTL обеих реализаций, вы увидите разницу. Лично я использую «генерации» циклов при кодировании логики RTL, то есть при указании точной структуры аппаратного обеспечения и циклов 'for' с поведенческими описаниями (ну, почти никогда :) :) –