Коллеги, а есть какая либо методика достоверной калибровки фазы клока приёмника этой шины? Просто сейчас столкнулся с тем что при передаче состояния счётчика по шине приём идёт без ошибок(благо при передаче счётчика очень легко поставить ловушку ошибок). Я и успокоился. Но при подключении на передающей стороне АЦП без сигнала(передаётся только шум младших бит) очень хорошо просматривается "залипание" некоторых бит. Получается что приём счётчика без ошибок ещё не гарантирует безотказную работу шины. Передавать какой нибудь LFSR? А как контролировать ошибки? Речь не идёт о работе с памятью, чисто шина FPGA-FPGA.

Как вариант, возможно нужно просто включить DIFF_TERM во входном буфере (это у Xilinx, у Альтеры может как-нибудь по-другому называется).

Согласен,у Xilinx это легко включается, а вот у Альтеры что то не найду,чип Аррия-5, может кто подскажет?

Извините, но почему вы решили, что подобное "залипание" - это не есть отражение реального видения АЦП напряжения на своем плавающем входе? "Залипают" очень большие разряды? Тоже может быть не показатель. Наводки от руки на плавающий вход осциллоскопа доводилось, наверное, наблюдать.

set_instance_assignment -name INPUT_TERMINATION DIFFERENTIAL -to <input_pin>

Отсюда:

https://www.altera.com/support/support-reso...032011_226.html

Нет,это совершенно из другой оперы. На 12-ти битном АЦП часто "залипает" 10-й бит,иногда 9-й. Но на сам сигнал на передающей стороне перед регистрами DDR ставил ловушку - чисто. Интересно что я формировал модулированный радиоимпульс ЛЧМ - никаких искажений не видел, а вот шумок сразу показал истинную ситуацию.


Спасибо!

Код Грея очень помогает в случае, подобном вашему. Здесь про АЦП. Проверку с использованием ПСП (М - последовательности) реализовать не так уж сложно, т.к. число тактов будет известно. Кстати, нельзя исключать и не слишком удачную разводку. Успехов.

Не читайте на ночь советских газет(С).Насчёт кода грея очень сомневаюсь,не его это задача. Для линейного счётчика - это да, а когда АЦП оцифровывает синус с тремя отсчётами на период - то тут уж извините.
Теперь о результатах. Поставил терминаторы, перекалибровался ещё раз - за 10 минут ни единой ошибки, я и успокоился. Часа три занимался этим же проектом, но другими узлами,питание не выключал. Потом решил ещё раз проверить ошибки - оказалось примерно 200 битовых ошибок за 1 мс. Перекалибровался ещё раз, через два часа проверил - опять ошибки идут. И что же делать дальше? Знак ошибки не изменился, сначала был код задержки 6, во второй раз пришлось увеличить до 11, а в третий раз поставил 15. Задержку меняю в лапах. Тактовая частота 300Мгц, две шины по 12 бит. Есть ли мысли?

Приветствую!


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

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

Удачи! Rob.

сначала был код задержки 6, во второй раз пришлось увеличить до 11, а в третий раз поставил 15. Задержку меняю в лапах. Тактовая частота 300Мгц, две шины по 12 бит. Есть ли мысли?

В начале работы, при старте АЦП нужно делать подстройку клока в центр принимаемых данных от АЦП (сделать "глаз").
Тема калибровок АЦП (надежного приема даных от АЦП) обсуждалась ранее

http://electronix.ru/forum/index.php?showtopic=128018

С утра включил с кодом 15 - полёт нормальный. Будем считать что поторопился... Обычно я кручу фазу приёмника в одном направлении до появления ошибок,потом в обратном и устанавливаю среднее значение. А всё таки это очень длительный процесс - нельзя ли как то (скриптом каким) оперативно изменять значения задержек в iodelay? Ведь чтобы изменить эту константу совсем не обязательно пересобирать весь проект. А так приходится ждать по 30 минут для каждого изменения.

Создается автомат (FSM), который по запуску АЦП, производит автоматическую поиск и установку
клока в центр данных, меняя (перебирая ) значения задержек и определения оптимальной задержки.
У Xilinx есть много xapp'ов на эту тему с примерами. Зависит от семейств ФПГА.
Например xapp855,xapp856,xapp860, xapp866,xapp1064,xapp1071,xapp585
У Альтеры также есть инструменты надежного приема данных от АЦП с документацией
взависимости от семейства

У меня Альтеровская ария5,ткните,плз, где описано как динамически изменять задержки. DLL или что то ещё?

Altiobuf ? Читал но ничего не понял,никакой конкретики...

Я работаю с Xilinx. Но похоже у вас клок не попадает в центр данных. Это надо обеспечить.
Потом возможно несоответствие метода приема и разводки линий даных АЦП на плате (выравнивание).
Всю документацию и рекомендации от Алтеры надо просмотреть.
Как это обеспечивается Timing constraints и тд
Какие мегафункции используете для приема данных
Допустим может надо использовать ALTDDIO_IN или ALTLVDS_RX.

Ясно,спасибо!
Нашёл altiobuf_design_example , будем разбираться.