[MickeyMouse 0]

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

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

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

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

Изменено 21 февраля, 2019 пользователем MickeyMouse

[Avex 1]

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

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

[MickeyMouse 0]

18 часов назад, Aleх сказал:

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

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

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

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

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

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

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

Изменено 22 февраля, 2019 пользователем MickeyMouse

[Avex 1]

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

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

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

Изменено 23 февраля, 2019 пользователем Aleх

[MickeyMouse 0]

В 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, там правда речь шла именно про слэк, а не про скью.