Jump to content

    

команды set_data_check в тулах cadence

У кого-нибудь есть положительный опыт использования команды set_data_check либо ее альтернативы в innovus/genus ?

Вообще интересует задача выравнивания задержки не связанных между собой сигналов.

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

Есть еще пара set_max_delay.set_min_delay, но set_min_delay работает плохо.

Edited by MickeyMouse

Share this post


Link to post
Share on other sites

set_data_check работает только с сигналами, приходящими на входы одного селла. По сути, это такое же выравнивание, как если бы один сигнал считался клоком, а второй данными (тип проверки - сетап и холд). Для выравнивания задержек этот констрейнт подходит плохо, особенно если выравнивать приходится сигналы в разных путях reg2reg (по сути - в шине). Лучше вообще избегать таких схеме; классика жанра - одиночные сигналы синхронизовать через 2(3) флопа, а массив данных - через двупортовую память, в которой индекс передается в коде грея. Пробрасывать же целую шину в асинхронный домен  -моветон.

Но если очень надо, то начинать надо с деревьев: все передающие флопы должны иметь одинаковое летенси (одна скью группа домена А), так же и принимающие флопы - одна скью группа домена В. Обязательное условие - отсутствие любой логики (логика в CDC переходе - моветон в квадрате, могу обьяснить почему). Таким образом, останется только выровнять задержки, что можно сделать просто разбив приграничные флопы на пары (флоп доменаА + флоп домена В), и ставя флопы каждой пары физически рядом (или попытать set_max_delay, уповая что тул сам все расставит правильно). В результате, неровность задержек будет только за счет перекоса деревьев - незначительно гулять по температуре и питанию. Как сделать лучше, я не знаю. Но, повторюсь, лучше вообще избегать подобных CDC решений.

Share this post


Link to post
Share on other sites
18 часов назад, Aleх сказал:

set_data_check работает только с сигналами, приходящими на входы одного селла. По сути, это такое же выравнивание, как если бы один сигнал считался клоком, а второй данными (тип проверки - сетап и холд). Для выравнивания задержек этот констрейнт подходит плохо, особенно если выравнивать приходится сигналы в разных путях reg2reg (по сути - в шине). Лучше вообще избегать таких схеме; классика жанра - одиночные сигналы синхронизовать через 2(3) флопа, а массив данных - через двупортовую память, в которой индекс передается в коде грея. Пробрасывать же целую шину в асинхронный домен  -моветон.

Но если очень надо, то начинать надо с деревьев: все передающие флопы должны иметь одинаковое летенси (одна скью группа домена А), так же и принимающие флопы - одна скью группа домена В. Обязательное условие - отсутствие любой логики (логика в CDC переходе - моветон в квадрате, могу обьяснить почему). Таким образом, останется только выровнять задержки, что можно сделать просто разбив приграничные флопы на пары (флоп доменаА + флоп домена В), и ставя флопы каждой пары физически рядом (или попытать set_max_delay, уповая что тул сам все расставит правильно). В результате, неровность задержек будет только за счет перекоса деревьев - незначительно гулять по температуре и питанию. Как сделать лучше, я не знаю. Но, повторюсь, лучше вообще избегать подобных CDC решений.

Формально set_data_check работает и с сигналами в разных ячейках.

Дело в том, что у меня задача clock data recovery и нужно выровнять N фаз идущих с макро на входы N флопов которые тактируются общим клоком.
В общем-то я так и делаю минимизирую скью на приемниках и размещаю их ровным столбиком возле макро.

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

Варианты с skew_group для самих фаз не дают результатов(видимо потому что у этих N тактов нет нагрузок в виде тактовых пинов).

Кстати не подскажете какой командой можно поставить флопы рядом?)

Edited by MickeyMouse

Share this post


Link to post
Share on other sites

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

Что получается. Разряды в шине расползаются на +/- 1 такт в любом случае (поскольку сигналы асинхронные), и Ваша задача их потом выровнять с помощью фифо. Возникает вопрос - а на сколько выравнивать фазы? Полагаю, что допустимый разброс не должен превышать одного такта за вычетом сетапа и холда флопа, а так же разброса по температуре и питанию - в этом случае будет ошибка не более +/- 1 такт, а не, скажем, +/-2 такта. В зависимости от частоты это может быть и большой разброс и маленький, частоту Вы не указали. На мой взгляд, здесь надо все плейсить руками, включая клоковые буферы. Вероятно, эту часть схемы лучше выделить в отдельный уровень иерархии, и построить для нее Н-дерево или фишбон, а может еще и развести клок руками.  Другой вариант - не заморачиваться с плейсом, но организовать выравнивание +/-2 клока с помощью фифо :-)

Что касается сдвигания флопов, я это делаю скриптами. Для выходного пина первого флопа  узнаете его координаты (через атрибуты). Далее , через placeinstance (или как то так - нет мануала под рукой) плейсите в эту координату второй флоп, а потом выполняете refineplace. Получаете два флопа рядом. Но это медленно работает, особенно на больших обьемах. Если же нужно аккуратно расставить целый массив (фифо, к примеру) из флопов, то очень рекомендую почитать про SDP - техника специально для расстановки структурированых массивов селлов.

Edited by Aleх

Share this post


Link to post
Share on other sites
В 23.02.2019 в 13:15, Aleх сказал:

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

Что получается. Разряды в шине расползаются на +/- 1 такт в любом случае (поскольку сигналы асинхронные), и Ваша задача их потом выровнять с помощью фифо. Возникает вопрос - а на сколько выравнивать фазы? Полагаю, что допустимый разброс не должен превышать одного такта за вычетом сетапа и холда флопа, а так же разброса по температуре и питанию - в этом случае будет ошибка не более +/- 1 такт, а не, скажем, +/-2 такта. В зависимости от частоты это может быть и большой разброс и маленький, частоту Вы не указали. На мой взгляд, здесь надо все плейсить руками, включая клоковые буферы. Вероятно, эту часть схемы лучше выделить в отдельный уровень иерархии, и построить для нее Н-дерево или фишбон, а может еще и развести клок руками.  Другой вариант - не заморачиваться с плейсом, но организовать выравнивание +/-2 клока с помощью фифо :-)

Что касается сдвигания флопов, я это делаю скриптами. Для выходного пина первого флопа  узнаете его координаты (через атрибуты). Далее , через placeinstance (или как то так - нет мануала под рукой) плейсите в эту координату второй флоп, а потом выполняете refineplace. Получаете два флопа рядом. Но это медленно работает, особенно на больших обьемах. Если же нужно аккуратно расставить целый массив (фифо, к примеру) из флопов, то очень рекомендую почитать про SDP - техника специально для расстановки структурированых массивов селлов.

 

Поняли верно. В данном случае N фаз - это просто 1 тактовый сигнал с задержками 100ps * i, где i-номер фазы. Т.е. при захвате данных(фаз) некоторым клоком на синхронизаторе получается снапшот текущего состояния фаз(например 0000001111111, по позиции бит 01 я определяю оптимальный индекс фазы...) В целом метастабильность допустима и неизбежна из-за асинхронности. Сейчас я добиваюсь скью на синхронизаторе около 15ps что в сравнении с 100ps и вполне допустимо.

Но еще ведь нужно выбрать из этих фаз оптимальную по полученному индексу. Т.е. фазы должны проходить через мукс с равными задержками. Выбранная фаза тактирует флоп на который поступают некоторые данные(DI)(синхронные выбранной фазе).

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

Иначе генус во-первых начинает вставлять 4-х входовые вентили сильно искажающие скважность, во-вторых задержки по отдельным фазам сильно разнятся.

Задачу выравнивания DI и выбранной фазы решаю путем ecoAddRepeater.

Как видите имеется сразу несколько мест в дизайне с требованиями к одинаковым задержкам и по идее команда set_data_check подходит идеально, но не работает, поэтому приходиться шаманить тулом.

Еще по поводу H-tree... Был опыт небольшой совсем и результаты по скью получились хуже. Кроме того, как-то читал статью cadence про ccopt где утверждалось, что на глубоких технологиях от 65нм(если не ошибаюсь) лучшие результаты дает unconstrained tree, там правда речь шла именно про слэк, а не про скью.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this