Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: сборка нескольких _ПОЧТИ_ одинаковых модулей в один проект
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Разработка цифровых, аналоговых, аналого-цифровых ИС
yes
то есть, имеется проект, в котором есть несколько модулей, которые отличаются очень мало друг от друга: при синтезе модуля передается некий параметр, который используется затем для определения доступа к модулю (что-то типа адреса на общей шине)

так как модули большие и их много, то хотелось бы синтезировать нетлист верхнего уровня с "black box"-ами на месте инстанциации этих модулей, а сам модуль синтезировать отдельно
это нужно
1) для уменьшения времени синтеза
2) облегчения правок (ЕСО) внутри модуля - если все одинаковые, то можно простым скриптом исправить, а если будут пересинтезированы, то не обязательно функции будут смапированы в одинаковую логику
3) предполагаю, что это может сильно облегчить процедуру размещения и трассировки

-----------------

если бы это были абсолютно одинаковые модули - никаких проблем не возникло бы - синтезировал отдельно модуль и топ и потом link

------------------

я вижу такие пути
1) заменить параметр входом (сигналом), тогда модули будут одинаковые и проблема дешифрации будет не при синтезе, а run-time. минусы : логика добавится / времянка ухудшится. ну и неудобство в описании топ-а
2) регрупировать иерархию, чтобы вытащить тот субмодуль (маленький), который делает дешифрацию наружу и синтезировать вместе с top, а остальное синтезировать отдельно. минусы - такого не делал и слегка сомневаюсь, ну и связь RTL vs. netlist будет хуже. но это пока лучшее решение
3) переписать RTL - не хочется / организационные сложности

есть ли какое либо еще решение средствами синтеза (конкретно DC) решить проблему?

-------

UPD: та же проблема есть и для FPGA, там модулей таких меньше, но пересинтезировать приходится чаще ):
http://electronix.ru/forum/index.php?showtopic=57074
SM
заменить параметр сигналом и не запрещать DC оптимизировать нетлисты. Он тогда там все сам перепашет на этапе маппера-оптимизатора. Ну и чтобы constant propagation / boundary optimization были разрешены. И поколдовать с set_dont_touch, чтобы не перепахивало лишнего, а только дешифратор. Возможно - для удобства управления оптимизатором - выделить дешифратор в отдельный модуль, внутри того модуля, не вынося наружу.

А какое неудобство в описании топа? Что, есть резница между параметром #(.addr(16'h1234)) и сигналом (.addr(16'h1234)), кроме "#" перед скобкой ? smile.gif

Еще вариант - маленький модуль дешифратора в том модуле, он, дешифратор, на высоком уровне описан, а модуль синтезирован. Без вытаскивания его наружу. Дешифратор синтезируется, модуль - уже нетлистом, потом слинковать и ungroup дешифратору. Вопрос в передаче параметра - вот я не знаю, можно ли через модуль-нетлист передать насквозь параметр в модуль, который не нетлист. Но - экспериментально имхо проверяется на раз и по идее д.б. можно, в фпга это обычная практика со всякими PLL и DCS. Если не поддерживает - опять boundary optimization + constant propagation
Escorial
Я бы переписал внутренний суб-модуль и разделил его на 2 части (2 под-модуля):
1. Изменяемую часть с дешифратором.
2. Неизменяемую часть (ту, которую вы боитесь трогать).

Кстати, не очень понял, как именно сейчас у вас реализовано изменение функциональности, но если необходимо менять только параметр внутреннего модуля, можно использовать один и тот же файл-модуль, в который вставить директиву // synopsys template. А параметр задавать на верхнем уровне через defparam (Verilog).
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.