2015-07-25 4 views
1

Я блуждал с точки зрения «производительности», если есть какая-то разница между структурным и поведенческим поведением VHDL. Я знаю, что сегодня более распространено писать поведенческие, а не структурные, но поскольку я хотел бы иметь понимание с точки зрения производительности, я думал, что, возможно, есть какая-то разница ...Поведение VHDL по сравнению с структурными характеристиками

+0

Всегда полезно посмотреть на сгенерированный [RTL] (https://en.wikipedia.org/wiki/Register-transfer_level) и сравнить. – dlask

+0

Вы можете сделать это для небольшой системы, я думаю ... для большой системы вы, я не думаю, что имеет смысл писать обе модели и сравнивать. – user8469759

+1

Обычно ваша задача - быть продуктивной, и задача компилятора - понять ваши намерения. По этой причине обычно используется поведенческий код. – dlask

ответ

3

Нет причин, связанных с оборудованием предпочитают одну или другую форму.

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

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

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


Что наиболее важно (если вы не раздвигают границы скорости или размера FPGA) ясность, что приводит к удобочитаемости, надежности, эффективности, контролируемости, ремонтопригодности и так далее. Если вы не можете понять это, вы не можете увидеть неэффективность или даже проверить его правильно.

Здесь структурный VHDL играет определенную роль на верхнем уровне: разделение системы на блоки, такие как процессор, интерфейс памяти, процессор FFT, UART, SPI и так далее. Иногда иерархически, поэтому вы можете разделить интерфейс памяти на логику обновления, исправление ошибок, мультиплексирование адресов и т. Д.

Но большинство блоков - например, задачи, которые может обрабатывать один конечный автомат, являются самыми ясными и простыми, когда они выражены поведением. Таким образом, в UART у вас могут быть два отдельных процесса для TX и RX, в то время как интерфейс SPI (который отправляет и получает на тех же частотах SPI), вероятно, лучше всего в качестве одного поведенческого процесса.

+0

Поскольку нет особых причин, чтобы предпочесть конкретный описатель (с точки зрения аппаратного синтеза). Может ли структурное описание каким-то образом повлиять на скорость компиляции? (Предполагая, что у нас есть два эквивалентных описания оборудования поведенческих и один структурный). – user8469759

Смежные вопросы