Altera Timequest. Констрейны для неизвестного клока, Как описать клок, точное значение которого неизвестно ? Опции

[Flip-fl0p]

Приветствую Уважаемые посетители форума !
Собственно имеется внутри FPGA некая схема, содержащая PLL.
PLL настроена таким образом, что у нас опорная частота умножается и делится на некие коэффициенты, которые никогда не меняются. (коэффициенты рассчитаны таким образом, чтобы не превышалась максимальная частота VCO( ГУН) по спецификации на чип).
Но вся проблема в том, что опорный клок у меня может лежать в диапазоне от 25Мгц до 80 Мгц. (т.е иметь любое значение, характерное для значения пиксельной частоты VESA)
Как можно обконстрейнить такой клок ?

[Inanity]

Очевидно, что по максимальной частоте, т.е. в вашем случае - 80Мгц, если я правильно понял. Если проект на этой частоте по времянке проходит, то и на 25Мгц всё будет ок.

[Flip-fl0p]

Очевидно, что по максимальной частоте, т.е. в вашем случае - 80Мгц, если я правильно понял. Если проект на этой частоте по времянке проходит, то и на 25Мгц всё будет ок.

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

[Inanity]

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

Нет, почему же? В общем случае должны выполняться требования setup и hold для всех триггеров в схеме. Если это правило выполняется для частоты Fmax, то тем более будет выполняться и для меньших частот.

Есть другой подвох. У вас есть в схеме асинхронные сигналы? Если таковые имеются и переход из одного клокового домена в другой осуществляется через синхронизаторы на регистрах, то при изменении частоты проект может по естественным причинам перестать нормально работать.

Допустим, у вас проект тактируется снаружи частотой в диапазоне 25-80Мгц. Предположим, что на вход приходит единичный асинхронный импульс с длительностью 25нс (40МГц). Вы как положено с помощью синхронизатора делаете этот импульс синхронным для вашей схемы. Пока частота вашей схемы достаточно высока, импульс будет корректно пойман. Но если частота опуститься допустим с 80МГц до 25, то естественно, импульс будет пропущен (или будет ловиться, но иногда, как повезёт). Тоже самое может произойти для выходного сигнала вашей схемы, который будет входом для какого-нибудь другого блока со своей частотой. Короче говоря, за длительностью импульсов надо следить. А если дизайн на 100% синхронный, то при снижении частоты ничего не должно ломаться.

Сообщение отредактировал Inanity - Mar 20 2018, 19:25

[Flip-fl0p]

Нет, почему же? В общем случае должны выполняться требования setup и hold для всех триггеров в схеме. Если это правило выполняется для частоты Fmax, то тем более будет выполняться и для меньших частот.

Есть другой подвох. У вас есть в схеме асинхронные сигналы? Если таковые имеются и переход из одного клокового домена в другой осуществляется через синхронизаторы на регистрах, то при изменении частоты проект может по естественным причинам перестать нормально работать.

Допустим, у вас проект тактируется снаружи частотой в диапазоне 25-80Мгц. Предположим, что на вход приходит единичный асинхронный импульс с длительностью 25нс (40МГц). Вы как положено с помощью синхронизатора делаете этот импульс синхронным для вашей схемы. Пока частота вашей схемы достаточно высока, импульс будет корректно пойман. Но если частота опуститься допустим с 80МГц до 25, то естественно, импульс будет пропущен (или будет ловиться, но иногда, как повезёт). Тоже самое может произойти для выходного сигнала вашей схемы, который будет входом для какого-нибудь другого блока со своей частотой. Короче говоря, за длительностью импульсов надо следить. А если дизайн на 100% синхронный, то при снижении частоты ничего не должно ломаться.

Все переходы между доменами я делал через FIFO. А одиночные сигналы я синхронизирую путем handshake, как-раз для того, чтобы не беспокоиться на счет того, что короткий импульс может потеряться.
Я просто как-то на зарубежном форуме натыкался на аналогичную тему про то, как описывать такие клоки, да вот как-то не гуглится теперь эта тема.