Подскажите, Уважаемые. Чего-то вообще тупик.
Есть простая схема (первый рисунок) - специально нарисовал чтоб кусок с констрейном отладить. Триггер должен разрешать импульс на выход.
Если брать все без задержек, то на входах элемента "И" получится картина как на втором рисунке
Чтобы весь положительный импульс прошел наверняка, надо сигнал разрешения сдвинуть как на третьем рисунке, на 3нс. Т.е. на вход элемента "И" сигнал с триггера должен прийти на 3 нс раньше, чем фронт клока.
Как это описать? Пробовал делать сгенерированный клок на выходе триггера и ставить set_max_delay, пробовал делать так:

set_max_delay -from [get_registers {inst2}] -rise_to [get_clocks {inst1|altpll_component|auto_generated|pll1|clk[0]}] 3

и еще много чего, уже не упомнить, но результата ноль...

Кто чем может, подскажите пожалуйста!

PS. Крутить фазы на ПЛЛ-е не предлагать, этап пройденный, в большом проекте в итоге от сборки к сборке всяко может получится: может первый сигнал задержаться, а может и второй. Надо именно законстрейнить, НО КАК?


UPD: Сигналы рисовал сам, есть неточность, изменение на выходе триггера должно быть по фронту а не по спаду, но сути это не меняет.

Вы бы лучше нарисовали диаграммы того, что требуется получить на выходе.
Может бы и мысли появились.

А у Вас клок заведен на логику - как то это неправильно. Есть смутные предположения, что от этого надо избавиться и увеличить клок в 2 раза.

Сообщение отредактировал alevnew - Apr 21 2012, 05:05

Тактировать триггер по спаду. Если это не допустимо, как вы пишете - то общий ответ - сделать этого нельзя.
Вы хотите написать количество наносекунд задержки, и чтобы в соответствии с этим САПР вставила требуемое количестов элементов lcell или аналогичных, чтобы задержка была не менее заданной? Она так не умеет. Ограничения воспринимаются в обратную сторону - вставить не слишком много логических ячеек по ходу сигнала.

Диаграмма того что требуется получить на входах И и есть 3-й рисунок

Клок нельзя увеличить в 2 раза.



Я хочу описать количество наносекунд задержки, и чтобы в соответствии с этим САПР расположил элементы (не добавлял новые) и провел пути так чтоб выполнить это требование. Ув. DES00 консультировал по констрейнам, многие сигналы двигаются в пределах +/- 1..2 нс только за счет указания констрейнов путем расположения элементов и проведения трасс.

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

Спасибо за ответы!

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

Если есть возможность, для такой функции лучше использовать выходной DDR триггер.

Нельзя триггер: надо пропустить на выход положительный импульс ровно той ширины как на выходе PLL.
Повторюсь - это тестовая схема, в ней триггер - имитация сигнала разрешения в реальной схеме. Вот и нужно задать констрейн между клоком и сигналом разрешения клока. Чтоб сигнал разрешения приходил немного загодя до положительного импульса.

Пару мыслей на этот счет...
Насколько я понимаю, на 2-м рисунке сигнал а - нижний вход элемента "И", b - верхний вход. ИМХО очевидно, что изменение сигнала на b есть следствие изменение сигнала a (по логике работы D-триггера). А из 3-го рисунка видно, что Вы хотите, чтобы b изменялся раньше, чем a, т.е. следствие опережает причину...
Теперь почему у Вас схема в некоторых случаях работает...
Возможно один из сигналов a или b "добегает" до элемента "И" раньше. Если предположить, что сигнал до b "добегает" позже сигнала до "a" на ~10 нс (по рисунку), то все должно работать.
Сомневаюсь, что существует констрейн, который указывает, чтобы сигнал до элемента доходил "не раньше, чем". Поэтому в вашем случае лучше использовать дополнительные триггеры.

Возможно сумбурно получилось, но смысл, думаю, понятен.

В случае клоков таймквест считает параметр "clock relationship" - расстояние между активными фронтами как я понял. Т.е по сути неважно, доходит сигнал со сдвигом на один такт или без оного. Сам клок то ведь периодический. Поэтому и констрейн надо задать до активного фронта (переднего). Если мультицикл=2 использовать (т.е. указать констрейн чтоб таймквест считал фронты со сдвигом клока на один такт) - тоже варинат, но у меня не получилось...

Повторюсь, триггеры нельзя - после них потеряется длительность импульса с ПЛЛ, а ее надо соблюсти

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

В данном конкретном случае, в рамках квартуса и автоматически ИМХО это не возможно. Потому что, как уже отметили, схема асинхронная и несвязанная с передачей данных.

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

Помимо этого есть очевидные проблемы с разводкой глобального тактового сигнала на логику. Поэтому, если out это выходной порт, то вам правильно посоветовали использовать DDR выходной триггер. Для этого нужно включить его повторителем тактового сигнала и подать сигнал управления с логики, работающей на спадающем фронте тактовой частоты.

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

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

Схема в рисунке. С плл выходит два клока, сдвинутые на 90 град. один заводится на входы D - входы обоих DDR триггеров, другой - на клок. Ожидал на выходе увидеть повторение сигнала cl. Как видно из рисунка симулятора - неопределенность. Выходы cl и clk80 - виртуальные, чтоб было видно соотношение фаз. Таймквест не ругается, ПЛЛ лочится, DDR буфер используется (рисунок resource property editor, там видно)

В чем может быть затык?

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

Вроде понял. Сделал так (рисунок), покритикуйте. Триггер играет роль разрешителя импульсов. С первого взгляда все ок (рисунок симулятора)...

хммм, для повторителя явно не то %) там надо на ноги данных подать 0 и 1, а рулить всем остальным. Но в вашем случае может быть ваша схема и работает %)

Да я сначала так и сделал, подал 0 и 1, а как тогда импульсы запрещать? У меня не получалось. Один раз защелкнули 0 и 1 (если клокэнейблом разрешать) и все - потом хоть разрешай, хоть не разрешай - 0 и 1 уже защелкнуты и импульсы уже не останавливаются. А тут получается подоспела единица к началу импульса - прошел импульс, нет - нет импульса. То есть импульс либо проходит полностью (не обрезается), либо вообще не идет, и если времянки не проходят сейчас по крайней мере должен ругнуться.

Вобщем идея действительно стоящая, сейчас все по уму, огромное Вам спасибо, Des00 и Timmy!