Если клоки отличаются только по фазе (например несколько АЦП с общим исходным клоком) то переход вообще тривиален. Если клоки разные по частоте, то переход чуть сложнее. Опять же не совсем понятно почему бы не работать на клоке DCO, чем он плох? Конфигурирование АЦП - процесс не слишком сложный, делается простеньким софт процессором (пикоблейз,микроблейз или что-то ещё), который в свою очередь тактируется независимым клоком.

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

Вот именно, отдельный. И переход в его домен из доменов со всех DCO всех АЦП системы... Геморрой. А так, все АЦП работают от одного качественного источника тактов, ПЛИС - тоже, и сразу принимает на главном такте данные от всех АЦП, несмотря на то, что они могут работать с разной частотой дискретизации, заданной программистом. Просто и удобно. Я хочу показать, что такая схема добавляет удобства в проект ПЛИС и расширяет возможности по программированию частоты DCO.


Это, как сказать... У меня наоборот - программистам лишь требование не менять фазу DCO, и режимы I/O (понятно почему). А уметь менять частоту дискретизации - это их полное право. ПЛИС сама это должна понять, и корректно все принять.


DCO плох тем, что, получается, что каждому АЦП свой клоковый домен. Плюс некий анализатор частоты DCO (ну мне бы понадобился, а так, видимо, опционально). Плюс отдельный генератор для работы того, что занимается конфигурированием АЦП - совсем лишний домен. Зачем делать кучу доменов, когда можно работать на одном общем клоке, и совершенно беззатратно автоматизировать обработку задания частоты DCO. Просто глобальное упрощение всей схемы и экономия ресурсов.

Единственное, можно рассмотреть использование DCO для подачи на вход DQS, и использовать блок выравнивания данных от DDR-памяти (DQSBUFF у латиса, как он у ксилинкса называется, я не знаю), но тут я не уверен, что это все удастся, хотя, по идее, должно. И, опять же, будут отдельные проблемы с анализом текущей частоты DCO.

Я пока решил дальше продолжить делать схему, т.к. на мой взгляд пока не совсем честно смотреть тайминги, и там у меня возник ещё один вопрос. Как я уже говорил данные с АЦП необходимо сохранить в ОЗУ типа DDR2. Данные с ISERDES идут на вход порта IP контроллера памяти DDR2 сгенерированного MIG. Вопрос такой: Как c одного тактового входа ПЛИС затактировать все? А именно:
1) ISERDES (частота 400 МГц) - данные с АЦП
2) DDR2 (частота 400 МГц) - входной буфер данных
3) LPDDR (частота 200МГц) - выходной буфер данных

Я пробовал так:
clk0_p/n => IBUFGDS => PLL => BUFG => GCLK_400 { 1,2
1) => PLL => BUFPLL => ISERDES
2) => cX_sys_clk (DDR controller)

Выдает ошибку: нельзя последовательно использовать BUFG и IBUFG

По другому:
clk0_p/n { 1,2
1) => IBUFGDS => PLL => BUFG => GCLK_400 =>...
2) => cX_sys_clk (DDR controller)

Выдает ошибку: нельзя нагружать PAD (может быть только один компонент)

Как убрать/нейтролизовать IBUFG в IP контроллера DDR? (IP я подключал как компонент example_top.vhd)

Для данной платы я решил остановиться на тактирований от DCO, хотя я тоже считаю, что лучше работать от одного источника тактов.
Пришлось выставить параметр CLOCK_DEDICATED_ROUTE = FALSE, поскольку DCO заведен не на тактовый домен, задействовать PLL с BUFPLL и прописать их место положение, задать режим "Retimed" для ISERDES2.