Управление фазой низкочастотного сигнала., Virtex Опции

[Intekus]

Xilinx Virtex 5. Задача: создать 2 сигнала 10 МГц и 5 МГц с возможностью менять их взаимную фазу (произвольно, или, хотя бы, ступенчато) в процессе работы. Какой относительно какого сдвигать - без разницы. Внутри ПЛИС переходы между доменами данных частот осуществляются через синхронизаторы.

Идеально - менять фазу без перерывов в тактовых. Так что вариант динамического реконфигурирования PLL/DCM ("останов-реконфигурирование-пуск") - нежелателен.
С учётом того, что обе частоты будут, в том числе, выводиться из ПЛИС наружу - после разводки и до начала экспериментов по сдвигу фаз тактовых порождающие их PLL/DCM нужно закрепить - верно?
Динамический сдвиг фазы DCM ограничен 10 нс, что много меньше периода, в PLL динамического сдвига фазы нет (только реконфигурирование). Каковы плюсы и минусы расширения диапазона регулировки DCM добавлением на его вход линии задержки на триггерах, тактируемых, допустим, 200 МГц? Разводку предполагается закрепить, неравномерность задержек между триггерами роли для экспериментов не играет.
Кроме того: минимальная входная частота DCM - 32 МГц, если только не использовать один лишь CLKFX; а использовать только него можно лишь при условии отсутствия обратной связи. Есть ли в работе без обратной связи какие-то минусы? Делить на DCM входную частоту (например 100 МГц) не хочется, так как в этом случае (как я понимаю) фаза выходных (допустим) 5 МГц, относительно 10 (созданных из исходных 100 МГц на расположенной рядом PLL) окажется непредсказуема от запуска к запуску. При этом существует требование воспроизводимости сдвига фаз при включении устройства, при пересборке проекта, а также при переносе прошивки на другой экземпляр устройства.

Прошу ответов на вопросы и/или общего совета, как решить исходную задачу.

[o_khavin]

Xilinx Virtex 5. Задача: создать 2 сигнала 10 МГц и 5 МГц с возможностью менять их взаимную фазу (произвольно, или, хотя бы, ступенчато) в процессе работы. Какой относительно какого сдвигать - без разницы. Внутри ПЛИС переходы между доменами данных частот осуществляются через синхронизаторы.

Идеально - менять фазу без перерывов в тактовых. Так что вариант динамического реконфигурирования PLL/DCM ("останов-реконфигурирование-пуск") - нежелателен.
С учётом того, что обе частоты будут, в том числе, выводиться из ПЛИС наружу - после разводки и до начала экспериментов по сдвигу фаз тактовых порождающие их PLL/DCM нужно закрепить - верно?
Динамический сдвиг фазы DCM ограничен 10 нс, что много меньше периода, в PLL динамического сдвига фазы нет (только реконфигурирование). Каковы плюсы и минусы расширения диапазона регулировки DCM добавлением на его вход линии задержки на триггерах, тактируемых, допустим, 200 МГц? Разводку предполагается закрепить, неравномерность задержек между триггерами роли для экспериментов не играет.
Кроме того: минимальная входная частота DCM - 32 МГц, если только не использовать один лишь CLKFX; а использовать только него можно лишь при условии отсутствия обратной связи. Есть ли в работе без обратной связи какие-то минусы? Делить на DCM входную частоту (например 100 МГц) не хочется, так как в этом случае (как я понимаю) фаза выходных (допустим) 5 МГц, относительно 10 (созданных из исходных 100 МГц на расположенной рядом PLL) окажется непредсказуема от запуска к запуску. При этом существует требование воспроизводимости сдвига фаз при включении устройства, при пересборке проекта, а также при переносе прошивки на другой экземпляр устройства.

Прошу ответов на вопросы и/или общего совета, как решить исходную задачу.

Основной вопрос в том, каковы требования к стабильности и джиттеру этих низкочастотных сигналов. Если требования не слишком высоки, то можно и на счётчиках сделать, с выводом через DDR-регистры в I/O cell-ах. Для воспроизводимости положения сигналов относительно друг друга в этом случае достаточно будет закрепить эти самые I/O cell-ы, что произойдет естественным путём при назначении конкретных пинов для вывода сигналов (в ucf-файле, к примеру).

Насчет DCM - он там лишний, получите все прелести разбросов по PVT - никакой повторяемости. Лучше поставьте микруху грейдом повыше, и сделайте входную частоту делителя повыше. DCM понадобится чтобы сделать быструю частоту на делитель.\

Т.е. DCM понадобится в любом случае.

[SM]

Основной вопрос в том, каковы требования к стабильности и джиттеру этих низкочастотных сигналов. Если требования не слишком высоки, то можно и на счётчиках сделать, с выводом через DDR-регистры в I/O cell-ах.

IMHO заметной разницы в джиттере при работе через DCM или через регистры не будет. А то джиттер и меньше даже будет, DCM не способствует повышению качества клока.

И DDR регистры тоже не нужны. Если зафиксировать точку ввода клоков в bufg (конкретно какой bufg и триггер, с которого он туда идет), то при выводе из глобального клока в I/O задержка (точнее разность задержек двух клоков) так и так будет повторяемая и фиксированная

[o_khavin]

IMHO заметной разницы в джиттере при работе через DCM или через регистры не будет. А то джиттер и меньше даже будет, DCM не способствует повышению качества клока.

И DDR регистры тоже не нужны. Если зафиксировать точку ввода клоков в bufg (конкретно какой bufg и триггер, с которого он туда идет), то при выводе из глобального клока в I/O задержка (точнее разность задержек двух клоков) так и так будет повторяемая и фиксированная

DDR-регистр даёт двукратное падение требований тайминга, если речь идёт про формирование низкочастотных клоков при помощи счётчика от одного высокочастотного клока. А частота этого высокочастотного клока чем больше будет, тем лучше с точки зрения количества шагов регулировки.
А джиттер - это естественное следствие использования DCM-а. Вопрос не в больше/меньше, а в абсолютных требованиях, о которых ТС умолчал или ещё не думал.

Сообщение отредактировал o_khavin - Mar 7 2014, 09:13

[SM]

DDR-регистр даёт двукратное падение требований тайминга,

А как потом завести с выхода DDR-регистра (он ведь в I/O) этот клок в bufg, да еще с повторяемостью? У человека этими клоками домены внутри ПЛИС тактируются.

[o_khavin]

А как потом завести с выхода DDR-регистра (он ведь в I/O) этот клок в bufg, да еще с повторяемостью? У человека этими клоками домены внутри ПЛИС тактируются.

Это вообще не нужно, достаточно использовать внутри один и тот же материнский (высокочастотный) клок. Как вариант, в комплекте с enable-ом + multicycle в констрейнтах. Разве что ТС собирается ставить внутри FPGA какие-то эксперименты над переходом из домена в домен, но такого я в его сообщении не видел.

И - действительно ли DCM добавляет джиттер, а не, наоборот, стабилизирует период (мне казалось именно второе)? А PLL - ведут себя в этом отношении также?

DCM стабилизирует период на продолжительном отрезке, но добавляет мгновенный джиттер. Про PLL не помню уже. В любом случае, смотрите документацию перед тем как.
Моя идея безотносительна к этим вопросам, она просто состоит в конструировании периода и относительного сдвига двух медленных клоков представляя их как данные, генерируемые на высокочастотном клоке. А использование DDR-регистра на выходе просто позволяет обменять смягчение тайминга вдвое на некоторое усложнение логики (ведь надо генерить отдельно чётные и нечётные полупериоды). И кстати, посмотрите по слову OSERDES, там можно сделать сериализацию 6 к одному и даже 10 к одному, что открывает неплохие перспективы.

Сообщение отредактировал o_khavin - Mar 7 2014, 10:46

[SM]

Это вообще не нужно, достаточно использовать внутри один и тот же материнский (высокочастотный) клок.

Вот это крайне маловероятно, так как для точности регулировки фазы придется его разгонять под максимум ГЕНЕРАТОРА КЛОКОВ, а вот всю схему запустить на этом максимуме маловероятно. Домены IMHO приятнее для решения этого вопроса. Одно дело планировать схему под 10 МГц, другое дело под 200-300-...

А какие именно констрейны понадобятся кроме объявления синтезированного на логике тактового, как, собственно, тактового?

1) объявить эти клоки асинхронными и задать периоды.
2) объявить расположение bufg и выходных триггеров на переходе в глобальные клоковые цепи.
3) если решите сделать мультиплектор/инвертор клока перед одним из делителей, то тоже его привязать к месту и региональному клоку.

Хорошая идея; думаю, разница в полтакта "быстрого" >200 МГц-сигнала между {подаваемым наружу} и {используемым для тактирования внутренней логики, созданном на не-DDR-триггере} в данном конкретном случае окажется некритична. А "инверсный быстрый" можно взять с инверсного выхода того же DCM/PLL, на котором создаётся основной?

IMHO в данном контексте использование DDR-триггера совершенно не нужно, это сложный монструозный путь. Проще (по логике, то есть ее количеству), и лучше, сделать программируемую инверсию клока на ВХОДЕ одного из двух делителей, вот вам и смещение его фазы на пол-такта быстрого клока. И полная гарантия повторяемости, и клоки сразу введены в bufg, и не надо бояться нескольких доменов - ну да, переходы, но зато логика куда компактнее, чем если ее заводить на сотнях МГц.

PLL очищает клок от джиттера, если, конечно, он хуже джиттера самой PLL, и происходит это из-за фильтра после фазового детектора в цепи управления ГУН.

[o_khavin]

Вот это крайне маловероятно, так как для точности регулировки фазы придется его разгонять под максимум ГЕНЕРАТОРА КЛОКОВ, а вот всю схему запустить на этом максимуме маловероятно. Домены IMHO приятнее для решения этого вопроса. Одно дело планировать схему под 10 МГц, другое дело под 200-300-...

IMHO в данном контексте использование DDR-триггера совершенно не нужно, это сложный монструозный путь. Проще (по логике, то есть ее количеству), и лучше, сделать программируемую инверсию клока на ВХОДЕ одного из двух делителей, вот вам и смещение его фазы на пол-такта быстрого клока. И полная гарантия повторяемости, и клоки сразу введены в bufg, и не надо бояться нескольких доменов - ну да, переходы, но зато логика куда компактнее, чем если ее заводить на сотнях МГц.

Во первых, я не видел упоминаний ТСа по требуемой точности. Во вторых, OSERDES 10:1 при опорном клоке в 100 Mгц даст шаг 1ns или 100 шагов на период целевого клока. В третьих, на 100Мгц в Virtex5 можно сделать чуть менее чем всё что угодно.
P.S. Я конечно уважаю Вашу привычку отстаивать свою точку зрения, но зачем уж до абсурда доводить то?

[SM]

P.S. Я конечно уважаю Вашу привычку отстаивать свою точку зрения, но зачем уж до абсурда доводить то?

Это не абсурд. Я привык во всех проектах минимизировать количество обработки на высоких частотах, и минимизирвоать количество регионов ПЛИС, региональных клоков (глобальных лучше вообще не применять, куда загнан ВЧ клок), так как это:

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

Итого, уменьшает цену решения, бывает, что в разы. А в "среднем по больнице" - цена определяет, сколько с проекта можно заработать. Я, конечно, понимаю, что бывают отдельные случаи, когда цена пофигу совершенно, и это, может быть, как раз он, но, все же, IMHO, надо всегда стараться удешивить изделие, если оно от этого не потеряет. А не придумывать, как бы сильнее разогреть воздух и опустошить кошелек.

[o_khavin]

Это не абсурд. Я привык во всех проектах минимизировать количество обработки на высоких частотах, и минимизирвоать количество регионов ПЛИС, региональных клоков (глобальных лучше вообще не применять, куда загнан ВЧ клок), так как это:

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

Итого, уменьшает цену решения, бывает, что в разы. А в "среднем по больнице" - цена определяет, сколько с проекта можно заработать. Я, конечно, понимаю, что бывают случаи, когда цена пофигу совершенно, но, все же, IMHO, надо всегда стараться удешивить изделие, если оно от этого не потеряет. А не придумывать, как бы сильнее разогреть воздух и опустошить кошелек.

Так импульсивно и так малоинформативно.
1) ТС уже выбрал чип.
2) 100 МГц для этого чипа не является высокой частотой. На любом спидгрейде.
3) Можно обойтись одним единственным клоком + минимальная логика, которая генерит 10-разрядный паттерн для каждого из 2-х выходов. Размер остальной логики (которая, как я понял, обрабатывает оцифрованные данные) совершенно не зависит от частоты. Достаточно использовать результат её работы 1 раз из 10. К тому же можно даже сэкономить на размере чипа за счёт временного разделения при использовании ограниченных ресурсов, например DSP-блоков.
4) Разница в потреблении будет минимальна, т.к. (сюрприз!) потребление регистров зависит от частоты переключения, а не от частоты клока. Или предлагаете высчитывать блох в разнице потребления DCM-а при работе на разных частотах? Так это ещё вопрос, где будет больше - при одном клоке но 100Мгц или при двух (или сколько их там в Вашем варианте) на 10.

В общем на этом я остановлюсь. Всё что я хотел написать ТС-у, я уже написал, а тратить время на демагогию не охота.

Сообщение отредактировал o_khavin - Mar 7 2014, 12:00

[SM]

потребление регистров зависит от частоты переключения, а не от частоты клока.

А потребление глобальной клоковой сети (дерева), состоящей из десятков тысяч буферов по всему кристаллу? Одно дело пустить клок на маленький региональный локальный клок, другое на глобальный. Это раз. А два - потребление регистра зависит от частоты переключения только в том случае, если от него отключается клок физически (смотрим принципиальную схему D-триггера). Иначе же ключи в нем щелкают всегда, просто защелкивая предыдущее значение, запущенное на него же через обратную связь с выхода, но переключение ключей идет на каждом клоке. В таком режиме он жрет меньше, чем когда переключается, но все равно жрет. И, даже если клок отключен от триггера физически, он все равно перезаряжает емкость этой "отключалки", внося потребление.

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

И последнее, количество логики на 10 МГц и на 100 как правило все таки отличается, в среднем в пару раз, в худшем, в десятки, потому, что на 10 МГц можно пускать более длинными путями, экономя на совместном использовании одной логики (resource sharing). А на 100 МГц уже будут лишние конвейеры, репликация логики, никакого совместного использования ресурсов, и т.д. Хотя, конечно, этого можно избежать, описав огромную пачку MULTICYCLE констрейнов, правда ucf как бы не стал толще самого проекта.

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