Нужна помощ с описанием внешнего такта в SDC языке для TimeQuest (Altera)
У меня PLL генерирует 200MHz и 50MHz такты. Этот 200MHz идёт сразу на внешний чип, каторый делит этот такт на два, и через кокое то время (скажем, 3nS) посупает опять на FPGA. И потом этот сигнал пользуется как такт в внутренних цепях.
Нарисовал картинку чтоб было бы ясно.


Написал так:

Но как правильно описать эту задержку (фазу)?

Я не специалист по TQ, но, на мой взгляд, Вам следует описать MHz100 как generated_clock от MHz200 с указанием сдвига фазы.

Но, лучше подождите ответов гуру.

Да, пробовал. Но тогда Quartus ругается(warning), что не может найти как этот клок был сгенерирован. В резултате, это описание игнориуруется

create_generated_clock не может использоваться без указания физического источника этого клока, т.е. в данном случае вариант отпадает.


Описывается стандартно через create_clock.
У вас есть передача данных их домена 100МГц в домен 50МГц? Если нет, то задержка не важна.
Если есть то это сложнее, я вижу единственную возможность это задать сдвиг по фазе между клоками с помошью ключа waveform. Но тут есть тонкий момент, у вашего делителя скоре всего нормируются максимальные и минимальные параметры задержки, и как вы будете учитывать их при анализе мне не совсем понятно. Может быть гуру объяснят.

Еще мне не понятно, зачем делить клок на внешнем устройстве, если есть PLL. Или почему бы не сгенерировать 50МГц со 100МГц получаемых с внешнего делителя.

Это упрощенное обяснение проекта. Внешная микросчема не всегда этот сигнал выдаёт. Но когда работает - 100MHz там есть.

Да, передача данных там есть от обеих доменов. Потому мне и надо описать их корректно.

Задержка там фиксированна, окола 3-5nS.

Спасибо за идею о сдвиг. Может быть поможет.

Она то фиксирована, но вам надо рассмотреть крайние варианты, что бы быть уверенным в работоспособности. А то на одной плате может работать, а на другой нет. Как тут быть не совсем понятно.


я бы рассмотрел внимательно передачу данных и рассмотрел вариант использования фифо %)

Так ведь у автора MHz200 выходит с FPGA, почему он не подходит как физический источник?

200 выходит, делится на внешнем устройстве и 100 заходит в плис. Вот эти 100 с помощью генерайтед клоков описать нельзя %)

Хм...


А так разве нельзя?





Квартус ругается:



Смотрим справку:



Добавляем в .sdc строку:




И все в порядке.

Сообщение отредактировал des333 - Jan 23 2010, 18:49

Это Вас кто-то наобманул

верилог:


SDC:


первый - описывает входной клок.
Второй - описывает генерейтед клок на выходном пине с учетом всех задержек.
Третий - описывает генерейтед клок, пришедший снаружи, сделанный из второго, деленный напополам и смещенный на 4 наны.
ну и uncertainty на +-1 нану, так как там ведь 3..5, а не 4.

А варнинг... Ну и что, что варнинг... Забить на него следует.
Warning: No paths exist between clock target "ret_clk" of clock "rclk" and its clock source. Assuming zero source clock latency.
И правильно говорит варнинг. Внутри путей нет, и считает latency за ноль, о чем на всякий пожарный и сообщает, мало ли, человек ошибся, случайно не ту ноду указал... Но мы-то знаем, что ту ноду, и что не ноль там, а 3..5, и это описали через -offset и через uncertainty. Можно и без оффсета, через дополнительный set_clock_latency. Ну и еще set_load не помешал бы, чтобы задать емкость нагрузки на выходной пин клока. Но я что-то не уверен в наличии такой команды в таймквесте

Wow!
Вот это решение! Очень спасибо.
А то так и было - на одной плате работает, а на другой нет.

теперь вижу что можно, как всегда невнимательно читал даташит %)

UPD 2 SM и des333, надеюсь вы не возражаете если этот пример я сохраню для всех %)

Кстати по тому примеру что там выложен. Если сделать посмотреть анализ времянок и пути клока в 200МГц



то возникает вопрос, откуда кварутс насчитал 6нс между клоками, тогда как должно быть 7.7...9.7 нс ?

UPD2 Поковырялся. 6 нс это период 100МГц 10нс минус смещение 4 нс. uncertanty учитывается при расчете Data Required и для клоков не рассматривается. А где учтена задержка по сигналу 200МГц... Странно.

UPD3.
Сделал так
задержка выросла
но анализ того самого пути изменился на 0.03нс и то за счет того что Clock Delay по clk50MHz выросла, ИМХО это подтверждение того, что задержка clk200MHz не учитывается %)

Если добавить строчку:


то задержка lcell начнет учитываться.

Точно, занятно. Значит таймквест, утвержая
нагло врет в текстовой форме %)

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