Использование разных библиотек стандартных ячеек в одном проекте Опции

[Fat Robot]

Добрый день.

Сейчас эту задачу приходится решеать разделением проекта на уровне RTL на две части. Первую синтезировать с библиотекой 12t, вторую с 7t. Синтез и timing closure приходится делать фактически для двух проектов. Еще дополнительно нужна сшивка цепочек сканирования. В общем боль и несправедливость..

Подскажите, если какие-то сдвиги в этом направлении? Может есть что-то автоматическое?

[Shivers]

Я так понимаю, проблема только в высоте ячеек. Если есть два блока на одном уровне иерархии, причем один надо делать на 12t, а второй на 7t, то и синтез и BE можно делать в один заход. Но для этого надо вводить информацию о пауер-доменах. Как это выглядит: один блок объявляется одним пауер доменом, с библиотекой 12t, а второй блок - объявляется вторым доменом с библиотекой 7t. Тот факт, что питание может совпадать, ничего не меняет - тул начинает блюсти, чтобы элементы одного домена не попали во второй домен. У каденса это маршрут с CPF, у синопсиса UPF. А поскольку UPF недавно признали стандартом IEEE, то каденс по идее должен и с CPF работать. В общем, читайте юзергайды по lowpower, они хорошо описаны и у синопсиса и у каденса.

[Fat Robot]

Спасибо за ответы. Буду смотреть upf-cpf. Маршрут: rc+encounter.

В моем случае этот подход нужен для уменьшения площади кристалла.

Принцип разбиения простой: проект на уровне rtl делится на 2 части на верхнем уровне иерархии. Блоки с высокой тактовой объединяются и синтезируются под быструю, но менее компактную 12t-библиотеку. А 'медленные' блоки синтезируются под медленную, но более компактную 7t, при этом 'быстрая' часть подключается в 'медленную', как black box.

Как я писал, если делать 'в лоб', то объём работы увеличивается уже на этапе синтеза. Что там на этапе back end, я представляю лишь в общих чертах: 2 разных сетки для линий питания в одном проекте.

[SM]

Принцип разбиения простой: проект на уровне rtl делится на 2 части на верхнем уровне иерархии. Блоки с высокой тактовой объединяются и синтезируются под быструю, но менее компактную 12t-библиотеку. А 'медленные' блоки синтезируются под медленную, но более компактную 7t, при этом 'быстрая' часть подключается в 'медленную', как black box.

Тогда, кроме upf/ucf, есть еще вариант, как такое раньше делали. Та часть, которая выглядит как black box, синтезируется отдельно, и разводится совершенно отдельно, получается IP-блок, который при разводке для роутера выглядит черным ящиком с пинами, как, например, блоки памяти, сгенерированные memory compiler-ом, или всякие покупные запчасти.

[Fat Robot]

Именно об этом подходе идет речь в моем исходном сообщении.

"Совершенно отдельно" - это верно лишь умозрительно. На практике же все оборачивается значительным количеством итераций синтеза для обеих частей проекта.

Тогда, кроме upf/ucf, есть еще вариант, как такое раньше делали. Та часть, которая выглядит как black box, синтезируется отдельно, и разводится совершенно отдельно, получается IP-блок, который при разводке для роутера выглядит черным ящиком с пинами, как, например, блоки памяти, сгенерированные memory compiler-ом, или всякие покупные запчасти.

[SM]

Именно об этом подходе идет речь в моем исходном сообщении.

Это да, я лишь добавил, что делать при таком подходе с backend-ом. Там все это вырождается в относительно несложную задачу разводки IP-блочка и подключения его потом как единого и неделимого. Он делается со своей сеткой и со своими кольцами, и потом "встает" куда-то в другую сетку, "пробивая" в ней соответствующую брешь, в любое удобное место.

Насчет автоматизации синтеза при таком подходе "в лоб" - это ведь получается классический bottom-up синтез вроде, то есть, по терминологии Synopsys DC, compile-characterize-write_script-recompile - в этом автоматизация и заключается. Но, процесс итеративный, тут уж никуда не деться.