Оценка области, необходимой для реализации VHDL - PullRequest
2 голосов
/ 30 мая 2011

У меня есть несколько VHDL-файлов, которые я могу скомпилировать с ghdl в Debian. Одни и те же файлы были адаптированы для реализации ASIC. Есть одна реализация "большой области" и одна "компактная" реализация для алгоритма. Я хотел бы написать еще несколько реализаций, но для их оценки мне нужно было бы уметь сравнивать, какую область занимают различные реализации.

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

Ответы [ 2 ]

7 голосов
/ 31 мая 2011

Начните с подсчета триггеров (FF).Их количество (почти) однозначно определяется написанным вами кодом RTL.Имея некоторый опыт, вы можете получить это число, проверив код.

Как правило, существует хорошая корреляция между #FF и общей областью.Старое эмпирическое правило заключается в том, что для многих проектов комбинаторная область будет примерно такой же, как и последовательная область.Например, предположим, что подсчет площади триггера равен 10 вентилям в технологии массива гейтов, тогда #FFs * 20 даст вам начальную оценку.

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

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

3 голосов
/ 31 мая 2011

Я бы хотел провести оценку без установки каких-либо проприетарных компиляторов или приобретения какого-либо оборудования.

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

Я бы посоветовал вам пересмотреть причины, по которым вы избегаете "проприетарных компиляторов" для выполнения оценки. Я не знаю ни о каких проприетарных инструментах синтеза для VHDL (хотя это обсуждалось ). Популярные поставщики ПЛИС предоставляют бесплатные версии своего программного обеспечения для Windows и Linux, которые вы можете использовать для получения точного подсчета использования ресурсов. Должно быть целесообразно перевести использование ресурсов ПЛИС в нечто более значимое для вашей целевой технологии.

Я не очень знаком с миром ASIC, но, опять же, могут быть бесплатные (но проприетарные) инструменты, доступные вам для использования.

...