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

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

Ок, подождём.


Строго говоря, офсет должен контролироваться, а вот его обеспечение нигде не обещается.

Между IDDR2 и данными никакой доп. логики нет. Это видно из схемы. Проблему решил, убрав BUFG для clk0 и clk180 между PLL и IDDR2, т.е такт завожу напрямую от PLL. После этого констрейнты стали выполняться.

Сообщение отредактировал maxics - Dec 11 2013, 10:28

Хм.. А в обратной связи, значит, оставили? Может просто компенсация неправильно в ДЦМе настроена?

Здравствуйте.
В ПЛИС новичок. Изучаю вопрос подключения АЦП к ПЛИС (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 - это похоже верхний предел для этих клоков.

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

Не совсем правильно. Задержка , насколько я понял, фиксированная, то есть не зависит от частоты никак. Частота 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

ISERDES нужен только для понижения входной частоты, которая слишком высока для софтлогики. 1 к 4 достаточно, окончательная десериализация должна выполняться на софтлогике, так что больше одного ISERDES на входную линию не требуется.

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

Большое спасибо за идею по поводу понижения тактовой и использования только одного ISERDESE1.

Ковыряю дальше, и встретил вот что (в документе ug361_Select_IO):
Если используется IODELAY, значит должен быть также объявлен экземпляр (instance) IDELAYCTRL.
Он используется для калибровки всех ЛЗ (в регионе - IOBank). Я английский понимаю очень хорошо, но есть в документе фраза, которая ломает мне моск.



То есть, независимо от всего остального дизайна, если я использую IODELAY, одна из глобальных тактовых частот у меня должна быть 200 МГц? В таком случае независимо от частоты сигнала, подаваемого на ЛЗ, каждый отвод ЛЗ будет составлять 78 пс (1/64 от опорного)?
Ладно, если так, это приемлемо (хотя это, вроде, идет вразрез с обратной связью в документе харр1071).

Но может ли кто-либо объяснить следующую игру слов:
"clock must be driven by a global clock buffer --- can be supplied directly from a user-supplied source"
и "must be routed on a global clock buffer"
Или я могу все-таки взять опорный со своего входа (как в харр1071), но подавать надо еще и на выводы global clock, чтобы запитать этот IDELAYCTRL?
Что-то я запутался...

Нашел еще один несколько похожий документ - харр881 Virtex-6 FPGA LVDS 4X Asynchronous Oversampling at 1.25 Gb/s

Из него становится понятно, что действительно надо отдельный сигнал фиксированной частоты (200 или 300 МГц) заводить на IDELAYCTRL (рисунок прилагаю). Выход IDELAYCTRL - RDY, собственно, никуда больше не идет, но сам примитив нужен.

У меня тогда вот такой вопрос по документации.
К документу харр881 на сайте прилагается зип-архив с reference design files. Скачали и посмотрели.

А в тексте интересующего меня документа харр1071 приводится адрес, по которому находятся те же reference design files, но при переходе по данной ссылке требуется подробный ввод данных аккаунта Xilinx, после чего появляется сообщение с извинениями, что данный аккаунт не прошел проверку (failed US export compliance verification).
Вопрос: как мне его достать - искать друзей в америке, симулировать американский IP, чо-то в аккаунте поправить или есть тут на форуме добрые люди с таким доступом?

Спасибо