Проблема приема данных Spartan-6 от АЦП Опции

[maxics]

Требуется принять поток данных в SPARTAN-6 с двухканальной АЦП LTC2195. Частота 100 МГц, режим DDR 4 lane, т.е данные в АЦП приходят с частотой 200 МГц по переднему и заднему фронту.

Это второй релиз платы (разводка сильно не менялась). В первом релизе, потратив много времени, удалось подобрать смещение фазы DCO (такт с АЦП) с помощью DCM (PHASE_SHIFT).
В последнем релизе сделать это не удается. Видно искажение входного сигнала. Пытались подобрать фазу DCO, закреплять в PlanAhead, но безрезультатно. Бывает, что при определенном значении Phase Shift данные принимаются верно, но достаточно что-нибудь поменять в проекте, как все "уезжает". В чем может таиться ошибка? Как лучше организовать прием?
Файл с исходным кодом:
 ADC2195_receiver.vhd ( 9.53 килобайт ) Кол-во скачиваний: 638

[Mityan]

Здравствуйте.
В ПЛИС новичок. Изучаю вопрос подключения АЦП к ПЛИС (V6) по LVDS.
Сигнал DCO+/- предполагается 448 МГц (не дотягивает до GTH).
FCO+/- - 64 МГц (т.е. 14 битов данных в режиме DDR по одному каналу).
Надо , видимо, принимать на IO Tile и делать преобразователь из последовательных данных в параллельные.

Нашел документ xapp1071_v6_adc_dac_lvds.pdf

там для сохранения временных соотношений между DCO, FCO и D предлагается схема с автоподстройкой временной задержки тактового сигнала согласно следующему рисунку (прикрепил)

А в документе ds152_DC_and_Switching_Characteristics для IODELAY
указан параметр T_IODELAY_CLK_MAX = 300 МГц (у меня speed grade -1).
Означает ли это, что ПЛИС с таким показателем скорости не подойдет для приема сигнала с указанной тактовой частотой (448 МГц)?

Спасибо.

Эскизы прикрепленных изображений

 

[Bad0512]

Здравствуйте.
В ПЛИС новичок. Изучаю вопрос подключения АЦП к ПЛИС (V6) по LVDS.
Сигнал DCO+/- предполагается 448 МГц (не дотягивает до GTH).
FCO+/- - 64 МГц (т.е. 14 битов данных в режиме DDR по одному каналу).
Надо , видимо, принимать на IO Tile и делать преобразователь из последовательных данных в параллельные.

Нашел документ xapp1071_v6_adc_dac_lvds.pdf

там для сохранения временных соотношений между DCO, FCO и D предлагается схема с автоподстройкой временной задержки тактового сигнала согласно следующему рисунку (прикрепил)

А в документе ds152_DC_and_Switching_Characteristics для IODELAY
указан параметр T_IODELAY_CLK_MAX = 300 МГц (у меня speed grade -1).
Означает ли это, что ПЛИС с таким показателем скорости не подойдет для приема сигнала с указанной тактовой частотой (448 МГц)?

Спасибо.

Это немного другие 300МГц. Дело в том, что макросу IODELAY для работы ещё необходим блок упарвления IODELAY_CTRL, которому как раз для успешной работы нужны независимые клоки в районе 200МГц.
Ну а цифра 300 - это похоже верхний предел для этих клоков.

[Mityan]

Это немного другие 300МГц. Дело в том, что макросу IODELAY для работы ещё необходим блок упарвления IODELAY_CTRL, которому как раз для успешной работы нужны независимые клоки в районе 200МГц.
Ну а цифра 300 - это похоже верхний предел для этих клоков.

То есть правильно ли я понимаю, что внутри IODELAY линия задержки с 32 отводами обеспечивает задержку входного сигнала от 1/64 до 1/2 периода опорной тактовой частоты?
Если я не могу завести на тактовый вход 448 непосредственно, как примере, то можно, разделив ее на 2 (в BUFR), завести 224 МГц и получить 32 отвода ЛЗ уже не на полпериода, а на целый период интересующей частоты 448 (от 1/32 до 1)?

[Bad0512]

То есть правильно ли я понимаю, что внутри IODELAY линия задержки с 32 отводами обеспечивает задержку входного сигнала от 1/64 до 1/2 периода опорной тактовой частоты?
Если я не могу завести на тактовый вход 448 непосредственно, как примере, то можно, разделив ее на 2 (в BUFR), завести 224 МГц и получить 32 отвода ЛЗ уже не на полпериода, а на целый период интересующей частоты 448 (от 1/32 до 1)?

Не совсем правильно. Задержка , насколько я понял, фиксированная, то есть не зависит от частоты никак. Частота 200МГц нужна для каких-то внутренних дел (калибровок или чего-то ещё).
Почему вы не можете завести 448МГц напрямую в ПЛИС? Какую ПЛИС использовать планируете?
И какая АЦП у вас? Дело в том, что частота на DCO как правило в 2 раза ниже частоты сэмплирования, так как данные передаются по обоим фронтам (DDR).

[Mityan]

Не совсем правильно. Задержка , насколько я понял, фиксированная, то есть не зависит от частоты никак. Частота 200МГц нужна для каких-то внутренних дел (калибровок или чего-то ещё).
Почему вы не можете завести 448МГц напрямую в ПЛИС? Какую ПЛИС использовать планируете?
И какая АЦП у вас? Дело в том, что частота на DCO как правило в 2 раза ниже частоты сэмплирования, так как данные передаются по обоим фронтам (DDR).

ПЛИС XC6VLX240T-1FFG1156.
Если я правильно понял, то эта схема на IODELAY нужна для компенсации доп. задержки, которую вносит BUFR. Конечно, поскольку временные диаграммы сигналов на выходе АЦП (а значит и на входе ПЛИС) как раз такие, как нужно, было бы идеально их завести через одинаковые буферы IBUFDS. Но поскольку DCO используется для тактирования преобразователя последовательных данных в параллельные, он должен быть подан в цепи тактирования (region clock) на специальные входы (clock capable). Через буфер. И вот тут-то временные соотношения и поплывут при высоких входных частотах. Верно? Или я чего-то недопонял?

В документе харр1071 (см. картинку выше) изображена именно обратная связь - выходной тактовый сигнал с BUFR заводится в блок IODELAY1 на опорный вход С. И задержка блока выражается именно в долях данного тактового (ниже привожу картинку из документа v6_DC_and_Switching_Characteristics).

Или мне нужно некий сторонний сигнал REF CLK обеспечить, и это должно быть либо 200 либо 300 МГц ровно?

По поводу АЦП, кстати, еще один вопрос. АЦП AD9257 - 8 каналов (1-wire), 14 бит, 65 МГц.
Приведенные 448 МГц, я уже писал выше, это именно в режиме DDR.
Преобразователь ISERDESE1 дает только 6 битов, каскадное включение возможно только двух примитивов, поэтому 14=(6+1)+(6+1) - итого 4. На 8 каналов это будет 8*4 + 1 в цепи DCO = 33 примитива ISERDESE1. Имеется ли в наличии столько в одном IOBank (для данной ПЛИС)? Или как это сформулировать - влезет ли? Учитывая, что примитивы все-таки универсальные, на все случаи жизни, что обуславливает их избыточность (в контексте моей задачи).

Сообщение отредактировал Mityan - Dec 23 2013, 06:42

Эскизы прикрепленных изображений

 

[Bad0512]

ПЛИС XC6VLX240T-1FFG1156.
Если я правильно понял, то эта схема на IODELAY нужна для компенсации доп. задержки, которую вносит BUFR. Конечно, поскольку временные диаграммы сигналов на выходе АЦП (а значит и на входе ПЛИС) как раз такие, как нужно, было бы идеально их завести через одинаковые буферы IBUFDS. Но поскольку DCO используется для тактирования преобразователя последовательных данных в параллельные, он должен быть подан в цепи тактирования (region clock) на специальные входы (clock capable). Через буфер. И вот тут-то временные соотношения и поплывут при высоких входных частотах. Верно? Или я чего-то недопонял?

В документе харр1071 (см. картинку выше) изображена именно обратная связь - выходной тактовый сигнал с BUFR заводится в блок IODELAY1 на опорный вход С. И задержка блока выражается именно в долях данного тактового (ниже привожу картинку из документа v6_DC_and_Switching_Characteristics).

Или мне нужно некий сторонний сигнал REF CLK обеспечить, и это должно быть либо 200 либо 300 МГц ровно?

По поводу АЦП, кстати, еще один вопрос. АЦП AD9257 - 8 каналов (1-wire), 14 бит, 65 МГц.
Приведенные 448 МГц, я уже писал выше, это именно в режиме DDR.
Преобразователь ISERDESE1 дает только 6 битов, каскадное включение возможно только двух примитивов, поэтому 14=(6+1)+(6+1) - итого 4. На 8 каналов это будет 8*4 + 1 в цепи DCO = 33 примитива ISERDESE1. Имеется ли в наличии столько в одном IOBank (для данной ПЛИС)? Или как это сформулировать - влезет ли? Учитывая, что примитивы все-таки универсальные, на все случаи жизни, что обуславливает их избыточность (в контексте моей задачи).

Если задержка возникает именно в клоковой цепи, то логично было бы её компенсировать добавлением доп. задержки в канал данных, т.е. добавить IODELAY в data lane. Хотя возможно и предложенная в XAPP схема тоже работает. Тут ещё многое зависит от качества разводки вашей платы. Если все дифф. пары на плате у вас выровнены по длине, то достаточно порулить задержкой по клоку для нахождения устойчивого состояния приёма данных (абсолютная фаза тут не очень важна - задержка на целое число бит далее скомпенсируется логикой подстройки по фрейму).
В принципе в вашем случае чем выше частота на клоках IODELAY тем лучше разрешение по времени задержки.
Десериализатор вам нужен только один на каждый канал данных. Достаточно режима 1:4, весь дальнейший демультиплекс данных и выравнивание по фрейму можно делать на частоте 224МГц. Для frame adjustment также можно пользовать bitslip логику десериализаторов.