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

Для начала Вам необходимо прочитать о constraint'ах (см. Constraint Guide) OFFSET, IOBDELAY и IOB.
При помощи OFFSET IN можно задать необходимое соотношение между данными и clock'ом, а при компиляции среда сможет проверить выполняются ли эти соотношения или нет.
IOBDELAY определяет использование элементов задержки в IOB.
Именно для V-4 – не помню, но в ряде FPGA можно задерживать как Data, так и Clock.
Кстати, обращаю Ваше внимание, иногда этот Delay втыкается автоматически (когда не нужен), поэтому его лучше всегда задавать вручную.
Также помогает FPGA Editor, чтобы понять, какие ресурсы использованы и как расположены триггера (легли в IOB или нет - от этого очень сильно зависит времянка)...
Constraint IOB задаёт: укладывать триггер в IOB или нет.

Если не поможет, то тогда почитайте про DCM. Вроде как им можно покрутить фазу непрерывного clock'а.

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

ADC - LTC2208. Такт АЦП 100 МГц с кварца. Затем с АЦП такт заводится сначала на одну ПЛИС (Spartan3), а затем на VIrtex4 LX25. По этому такту защелкиваются данные с АЦП. Вижу появление доп. гармоник оцифрованного сигнала. На входе их нет. Подозрение на неправильное защелкивание.

А осциллографом посмотреть?..
Хотя datasheet недвусмысленно говорит - Latch the data on the falling edge of CLKOUTB или Latch the data on the rising edge of CLKOUTA.


Аналоговый "антиалайзинговый" НЧ-фильтр на входе АЦП стоит?

Да, стоит.

Чувствую, будет проще если вы схему загрузите. А то уж больно хитро как-то.

Согласен, взглянуть бы на схему (достаточно функциональную) в части организации тактирования АЦП и ПЛИС и на спектр оцифрованного сигнала (какое значение SFDR получается?), потому как наличие спектральных составляющих, не относящихся к самому сигналу может быть вызвано некачественным тактовым сигналом на самом АЦП (либо по причине характеристик самого генератора, либо по причине каких-либо промахов в схемотехнике распределения тактовой частоты).
Практически уверен, что ПЛИС здесь не причем (подбором настроек, указанных в ответе Boris_TS и выбором фронта вполне можно получить подходящие фазовые соотношения), если конечно отсчеты АЦП защелкиваются регистрами, расположенными в блоках IOB (обязательное условие стабильной работы).
Есть ещё момент, который нужно иметь ввиду: Генераторы ВЧ - сигналов зачастую совместно с полезным сигналом на выходе имеют еще и гармоники этого сигнала, которые не являются признаком несоответствующей работы схемы.

Выкладываю схему тактирования и FFT. Такт 100 МГц. Рис.2 - fft в нашем случае. На входе Sin 19 МГц. Видны собственные гармоники, которые ведут себя неадекватно. При изменении уровня входного сигнала, гармоники изменяются непропорционально. Должно быть как на рис.3. доп. "палки" - гармоники генератора.
Пробовали понижать тактовую частоту. До 70 МГц все в норме.

Основное, что бросается в глаза - это используемый в схеме генератор тактового сигнала и путь, проходимый тактовым сигналом из АЦП к ПЛИС, регистрирующей отсчеты (Virtex 4). Если честно такое решение (прохождение тактового сигнала из АЦП) выглядит нелогичным ( должно быть АЦП - Virtex4 - Spartan3), но фатальным оно не является. Для стабильной повторяемости результатов разводки проектов для ПЛИС предлагаю следующий обратить внимание на следующие моменты:
1. Spartan3
1.1. Тактовый сигнал обязательно должен быть заведен на специальные контакты GCLK
1.2. Поскольку петли для выравнивания фазы с помощью DCM скорее всего нет, для стабильной повторяемости результатов трассировки тактовый сигнал на выходе Spartan3 рекомендую выполнить с использованием выходного DDR-регистра в IOB, и уже с выхода регистра сигнал будет поступать на выходные контакты. (К сведению: в Spartan3 для использования DDR - регистра придется подключать DCM для формирования сигналов clk0 и clk180, кстати здесь можно и поиграться с фазой тактового сигнала 0->(clk0,clk180), Pi/2->(clk90,clk270), Pi->(clk180,clk0), 3Pi/2->(clk270,clk90), где в скобках указано подключение тактовых к DDR-регистру ).
2. Virtex4
2.1. Тактовый сигнал обязательно должен быть заведен на специальные контакты (глобального или регионального тактового сигнала). Замечание: Если используются входы для регионального тактового сигнала, необходимо убедиться, что входные (данные из АЦП) контакты принадлежат одному из банков, имеющих подключение к контакту регионального тактового сигнала сигналу.
2.2. поскольку в промежуточной ПЛИС (Sprtan3) будет использована DCM, то для упрощения работы в Virtex4 желательно использовать просто глобальный буфер BUFG (при использовании DCM, а она будет 2-ой в цепочке, а поэтому, придется заниматься ее инициализацией).
2.3. еще раз повторюсь - обязательное использование входных регистров в блоках IOB для защелкивания данных из АЦП.

Что касается используемого генератора GK-154. Подобные генераторы предназначены только для тактирования цифровых схем. Ожидать качественных характеристик от АЦП при его использовании не приходится: качество сигнала на его выходе как раз и может служить причиной той картины что представлена на 1-ом спектре (виден сигнал, 2-я гармоника, а наивысшая из ненужных палок - около -75 дБ, причем спектр не разваливается). Кстати, при понижении тактовой частоты какой генератор использовался? Конечно параметры и GK-154 можно улучшить: поставить на его выходе полосовой кварцевый фильтр, но относительная нестабильность этого генератора улучшена быть не может.

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

Если мне не изменяет память, то в Spartan3 есть DLL, который может криво/коряво (с точки зрения jitter'а) заниматься компенсацией фазы. Даже если петля обратной связи не была предусмотрена, то, по идеи, её можно сделать на любой подходящей свободной ножке, использовав и OBUF, и IBUF оной. В этом случае схема более или менее нормальной компенсации может выглядеть следующим образом:
IN_CLK -> IBUF -> BUFG* -> DLL.CLKIN
IO_BF_CLK -> IBUF -> BUFG* -> DLL.CLKBF
DLL.CLK0/DLL.CLK180 -> BUFG -> ODDR -> OBUF -> IO_BF_CLK
DLL.CLK0/DLL.CLK180 -> BUFG -> ODDR -> OBUF -> OUT_V4_CLK
* - Если возможно отказаться от этих BUFG, то от них обязательно необходимо отказаться (именно со Spartan3 не работал - поэтому не знаю надо ли их использовать в этом месте или нет) - чем меньше лишних элементов, тем значительно меньше jitter и отклонение фазы выходного clock'а относительно входного.

Спасибо за развернутый ответ. При понижении частоты использовали лабораторный генератор Agilent. Какой генератор посоветуете для тактирования АЦП?

Обратите внимание на продукцию ОАО "МОРИОН" (http://morion.com.ru/rus/oscillators/), например модель ГК118-ТС для установки на плату. Требуемая частота получается путем умножения (с помощью дискретной логики) с последующей фильтрацией нужной гармоники, используя кварцевый фильтр. Получившийся сигнал остается привести в соответствие с требуемым уровнем. Вот и всё. Генератор будет, конечно, дороговат (порядка 10000 - 15000 руб), но результат будет положительным (не забываем про правильную организацию питания на плате). Вообще подобные генераторы отлично подходят на роль системных опорников, где от одного генератора запитываются несколько потребителей, а для одного потребителя его использование всё же несколько расточительно.


Упоминание проблемы джиттера на частоте 100 МГц были бы уместно, если бы шло обсуждение формирования тактового сигнала для АЦП, а не для использования в обсуждаемом контексте. В нашем случае величина джиттера значительно меньше чем диапазон "setup...Hold" для триггеров внутри ПЛИС, а кроме того при разводке и проверке на выполнение временных ограничений, джиттер, порождаемый DCM и BUFG уже учтен в значениях "setup/hold".

Что-то мне подсказывает, что для такого АЦП, jitter Spartan3 DLL просто убьёт всё измерение. И да, в этом случае о нём будет крайне уместно говорить !

Так я же про всё вместе говорил... если что. А т.к. в Virtex-4 нет PLL, а есть только аналогичной корявости DLL, то в худшем случае (т.е. нашем) jitter обоих DLL может складываться и составлять уже весьма заметную величину. Также, туда же в кучу необходимо накинуть будет статическое отклонение фазы, вызванное разбросами тех. параметров элементов Spartan-3 (да, эти разбросы наносят заметно больше вреда, чем jitter Spartan-3 DLL, но и jitter тоже имеет место быть).

Думаю, что наверное, работать всё-таки будет, но без детального описания и расчетов гарантировать работу будет затруднительно.

АЦП тактируется напрямую от кварца

Хочу сдвинуть входной поток данных ADC_IN относительно clk на 2 ns.
Если использовать OFFSET IN это будет выглядеть так:

NET "ADC_IN" OFFSET = IN "2 ns" VALID "10 ns" BEFORE "clk" RISING;

соответственно если, например, сдвинуть только 6-й бит потока:

NET "ADC_IN<5>" OFFSET = IN "2 ns" VALID "10 ns" BEFORE "clk" RISING;

Вам сначала необходимо зафиксировать фазу частоты в Spartan. Для этого надо, чтобы частота там прошла через DCM. То, что это добавит джиттер - уже неважно, потому что мы хлопаем оцифрованные данные. Далее, эта частота придет в Virtex-4 c некоторым смещением к данным. Вам надо это смещение засечь осцилографом. И затем на это смещение подвинуть клок, либо с помощью DCM в Spartan, либо использовав в Virtex еще одну DCM. Статически клок сдвинуть в DCM можно при ее создании в Coregen.

Если я хочу сдвинуть только один бит, например 6-й. В UCF эту строчку нужно прописать?

NET "ADC_IN<5>" OFFSET = IN "2 ns" VALID "10 ns" BEFORE "clk" RISING;

Эта строка - всего лишь временное ограничение для транслятора, который будет просто стараться уложиться в определенный диапазон, а возможностью управлять задержками в IOB она не обладает. Найдите в каталоге XILINX файл "cgd.pdf" (очень полезный файл!) и просмотрите главу "Input Buffer Delay Value (IBUF_DELAY_VALUE)".