edk lvds adc Опции

[rv3dll(lex)]

как в едк подключить 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

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

[rv3dll(lex)]

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

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

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

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

[DmitryR]

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

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

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

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

[rv3dll(lex)]

Я не про эту штуку сказал, а про разницу путей от дифференциального буфера канала данных до входов ISERDES,

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

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

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

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

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

[DmitryR]

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

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

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

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

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

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

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

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

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