как в едк подключить lvds ацп

на какие ноги подавать клоки, как назначить эти ноги
нужен ли dcm

ацп - битовая частота 300 фреймовая 50
по 2м фронтам 12 бит

к сожалению не могу работать с ftp изза ограничений доступа
по этой теме имею ссылки

ftp://ftp.xilinx.com/pub/utilities/fpga/d...buf_v1_00_a.zip

ftp://ftp.xilinx.com/pub/utilities/fpga/d...buf_v1_00_a.zip

если объём небольшой помогите скачать

Давайте сначала подумаем, что с этим богатством будет делать MicroBlaze? Даже если предстваить, что канал у этого АЦП один - вы получите 75 мегабайт (18.75 мегаслов) в секунду. С учетом, что MicroBlaze работает максимум на 200 МГц - у него будет 10 тактов на каждое слово. Загрузить-выгрузить и сделать пару-тройку арифметических операций.
То есть, обычно поток c быстрого АЦП предварительно аппаратно обрабатывается. Как после этой аппаратной обработки отдать поток процессору - это уже другой разговор, можно сделать ему интерфейс PLB, можно любой другой, какой есть в EDK IP. Можно конечно прямо поток АЦП перевести на PLB или FSL, но толку от этого я не вижу. Не сделав же никакого железа (HDL-кода), используя только стандартные IP EDK захватить поток 300 МГц думаю, не выйдет.

вы не поняли вопрос - отсчёты с 50 меговым шагом уже вовсю успешно обрабатываются!!!!!
из параллельного ацп

перехожу на ацп с лвдс каналом
нужно подключить его грамотно с первого раза

Так в чем тогда сложность? Добавьте к существующей схеме десериализатор, это же банальное устройство, сдвиговый регистр.

я пытаюсь использовать ISERDES но пока безуспешно

я завёл 300 меговый клок на DCM - получил 2 противофазных сигнала(для чередования) и делённый на 6 сигнал, которые завёл на ISERDES на входы CLK CLKDIV соответственно

не понимаю что делать дальше

как использовать фрамовый клок 50 мгц который идёт от АЦП и как осуществляется защита от циклического сдвига ????

Начнем с того, что ISERDES использовать не надо - он коротковат и все равно придется его перехлопывать в триггеры, 300 МГц даже на спартане ловится без проблем.

Далее, для захвата битов необходимо использовать входную частоту 300, пропущенную через IDELAY (или DCM), задержку (или phase shift) на котором (которой) надо подобрать либо по результатам временного моделирования, либо написать калибровочный автомат, который будет переводить АЦП в режим тестирования и, меняя задержку IDELAY (dynamic phase shift DCM), находить окно, в котором приходят правильные данные, впоследствии устанавливая задержку на середину этого окна. Захват битов необходимо осуществлять в IDDR, также в IOB надо обязательно разместить триггер, который будет захлопывать строб фрейма.

Затем биты, захваченные в IDDR уже только по восходящему фронту входной частоты по два захлопываются в обычный сдвиговый регистр длиной 12. В момент подъема фреймового строба, задержанного еще на такт для компенсации задержки в IDDR этот регистр записывается в короткий FIFO (elastic buffer). Читается elastic buffer по входной частоте, деленной на 6.

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

P.S. Имейте в виду, что в текущей версии ISE есть баг (обсужденный на Webcase и признанный), в результате которого IDELAY с переменной задержкой во временную модель не попадает, поэтому ее (модель) надо поправлять руками.

насчёт коротковат не согласен
лвдс вход включает в себя 2 преобразователя в одиночный выход - или как его там - короче примитив его лвдс вход - 2 противофазных выхода

к обоим выходам прямому и инверсному подключаем по ISERDES (их в этом модуле тоже 2) оба в мастер режиме

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

на триггерах собирать всё это может не хватить несурсов FX20 загружен уже на 85% а каналов таких 4



фактически 12 бит захвачены - только как стактировать фреймовым клоком - если на ISERDES на CLKDIV подаётся клок 300 делённый на 6.

и вот чего я ещё никак не могу понять - в ISERDES по CLKDIV что внутри происходит?

если он защёлкивает данные сдвигового регистра - то само собой что они на выходе будут сдвинуты и сдвинуты на число отсчётов разфазировки между от балды полученным CLKDIV и фреймовым причём чтобы этот сдвиг восстановить нужно будет использовать 24 бита предыдущий и текущий 12 битный отсчёт. Меня все документы посвяженные этому запутали окончательно

Вы перепутали, это выход. У входного буфера LVDS наоборот - два входа (прямой и инверсный) и один выход.


Проблема в том, что в каждй ножке один ISERDES. Соответственно, если использовать два так как вы описали - сигнал ко входу одного из них придет гораздо быстрее, чем ко второму, и все почти наверняка поломается. А чтобы починить это, вам придется тактирование на них подавать с компенсирующим этот скос сдвигом по фазе, что есть совершенно излишний гемморой. Если же использовать ISERDES каскадно, что гарантирует правильную работу - то они не умеют длину 12, поэтому я и не рекомендовал их использовать в данном случае.
И еще один аргумент на всякий случай: подумайте, чего вам будет стоить синхронизировать ISERDES с феймовым стробом.


Ресурсов тут нужно примерно 35 LUT и 20 триггеров на канал, это вместе с тупо сделанным на LUTRAM elastic, не думаю, что это будет проблемой.

не соглашусь - не знаю как в других в 4 виртексе эта штуковина получается абсолютно симметрично
эта штука называется IBUFDS_LVDS_DIFFOUT или BUFDS_DIFF_OUT

если посмотреть структуру вывода то BUFDS стоит в каждой ноге и имеет связь с другой ногой LVDS пары, которая может быть подключена к выводу

таким образом получаем 2 однополярных - противофазных сигнала - результата LVDS посмотрите xapp866

вот я и пытаюсь сообразить как подать фреймовый клок на CLKDIV и вообще разобраться с возможностью это сделать - но пока не как не пойму

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


Никак, потому что фрейм - это строб, а не тактовый сигнал, в частности у него плохая скважность и фронт не выровнен с фронтом синхронизации, а опережает ее (чтобы по фронту синхронизации строб мог быть надежно захвачен). Вам придется писать машину состояний, которая будет дергать BITSLIP у ISERDES до тех пор, пока он не встанет в нужную фазу с входным потоком. Если же вы хотите биться за свое решение до конца - пробуйте подавать строб фрейма прямо на CLKDIV, может и удастся чего добиться, подобрав правильную задержку. Но IMHO если бы вы делали, как я написал - проблема бы уже была решена.

она абсолютно одинакова

не получается подать на CLKDIV с фреймового клока напрямую - почему пока сам не понимаю

а бьюсь я с этим вопросом по своему так как потом надо будет сделать 32 или 64 таких канала - и поэтому хочу сравнить ресурсы

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

это рассогласование надо численно оценить и произвести выборку окна с правильными данными
всё это уже на частоте 50 мегагерц

Вы это откуда узнали, можно спросить? Поставьте на линию, которая идет на входы данных ISERDES констрейн MAXSKEW=1 ps и увидте, насколько они реально различаются.


Я в предыдущем посте описал возможную причину: у строба фрейма плохая скважность.


Тогда надо исключить elastic buffer, в принципе и без него должно работать, так как после DCM фронт деленой частоты совпадает с фронтом CLK0. Тогда на канал останется ~25 триггеров, на 64 канала - ~1600 триггеров, или 8% емкости кристалла. Вы кстати еще подумайте, вам хватит ли ресурсов FX20 обработать 64 канала.


Вы красиво пишите теорию, но на практике, как видите, все не так гладко. Численно оценить это не выйдет, так как это величина не постоянная, а будет каждый раз меняться, и поэтому на решение этой задачи (написание автомата калибровки по BITSLIP) у вас уйдет ресурсов не меньше, чем в моем решении (ведь такой автомат надо ставить на каждые 4 канала).

пока решаю проблемы такого плана

Pack:1107 - Unable to combine the following symbols into a single IOB
component:
PAD symbol "D_clk_n_pin" (Pad Signal = D_clk_n_pin)
SlaveBuffer symbol
"udk_02_muz_0/udk_02_muz_0/USER_LOGIC_I/IBUFDS_clk_F/SLAVEBUF.DIFFIN" (Output
Signal = udk_02_muz_0/udk_02_muz_0/USER_LOGIC_I/IBUFDS_clk_F/SLAVEBUF.DIFFIN)
SlaveBuffer symbol
"udk_02_muz_0/udk_02_muz_0/USER_LOGIC_I/IBUFDS_clk_d/SLAVEBUF.DIFFIN" (Output
Signal = udk_02_muz_0/udk_02_muz_0/USER_LOGIC_I/IBUFDS_clk_d/SLAVEBUF.DIFFIN)
The component already has an input slave buffer.
ERROR:Pack:1107 - Unable to combine the following symbols into a single IOB
component:
PAD symbol "D_clk_p_pin" (Pad Signal = D_clk_p_pin)
DIFFAMP symbol "udk_02_muz_0/udk_02_muz_0/USER_LOGIC_I/IBUFDS_clk_F/IBUFDS"
(Output Signal = udk_02_muz_0/udk_02_muz_0/USER_LOGIC_I/F_clk_S)
DIFFAMP symbol "udk_02_muz_0/udk_02_muz_0/USER_LOGIC_I/IBUFDS_clk_d/IBUFDS"
(Output Signal = D_clk_to_dcm)
The I/O component already owns an input buffer.