Начал наконец смотреть распиновку.

Слаки на сигналах, помеченных звёздочками, т. е. DQ[*].
Начал прочёсывать интернет. И выяснилось:

http://www.alteraforum.com/forum/showthrea...9491#post189491


С одной стороны, эти 2 нс мы как раз и наблюдаем.
С другой -- как это сформулировано. Ведь "DQ pin used for user pin(not DDR DQ pin), always need to route through HMCPHY_RE" -- это один смысл, а "DQ pin is used for user pin(not DDR DQ pin), always need to route through HMCPHY_RE" -- несколько иной. И "never used" как бы намекает на второй.

ИМХО главное тут "no way to bypass it." Казлы.

ЗЫ. в свое время на подобное (т.е. не рекомендуется для высокоскоростного интерконнекта) поведение напоролся с пинами VREFB.

PPS. ИМХО лечите PLLкой. клоки с разными фазами для разных линий. Собираете в регистры. Замена частоты тактирования через автомат реконфигурации PLL. Во второй ревизии поправить ноги плиса.

Не вопрос.
Вопрос в другом. У части шины задержки получаются больше периода. Лишним регистром я их выровняю. Но как объяснить это TA? Мультициклы писать? Я думал, что мультициклы пригодны только для сигналов, длительность которых больше периода. А АЦП данные приходят каждый клок.

мультициклами сдвигаете фронты анализа. т.е. говорите что сетап сдвинут на 2 фронт, а hold не на нулевой (как в классическом мультицикле), а на 1 фронт.

Отпишусь по результатам натурных испытаний.

HMCPHY_RE упоминает в хэндбуке на C V только один раз. Не заметить этот малюсенький абзац проще простого. Увидеть наличие HMCPHY_RE я смог только в одном месте: в отчёте TimeQuest и то только при выставленной галке Show Routing. Всё. Ни в Chip planner, ни в нетлисте после разводки никаких HMCPHY_RE нет.

Самое странное вот что. Часть шины по отчёту TQ имеет задержки больше периода, поэтому на остальную часть вроде бы как надо поставить дополнительный регистр, чтобы компенсировать задержки в HMCPHY_RE. Так вот, если этого не делать, то данные принимаются правильно. Если регистр всё-таки поставить, то данные неправильные.

До экспериментов с железкой ситуацию могло бы прояснить моделирование с задержками после разводки, но
Гады.

Добрый день.
Делаю прошивку под C-III как раз с АЦП AD9634, который тут упоминался.
Все работает нормально, но хочу навести порядок в голове с констрейнами по входу.
Вопрос возник по примеру sdc, что предоставил des00.
Сначала опишу что сделал сам.
Решил тоже не юзать виртуальный клок, а описывать непосредственно от DCO.
По даташиту фронт DCO запаздывает за данными на Tskew (0.3 : 0.7 нс).
Соответственно:

Задержки по плате не учитываю, т.к. АЦП близко к FPGA и их вклад несущественен.
В FPGA ставлю PLL в режиме source synchronous и ей подкручиваю фазу, чтобы TQ не ругался.

С первой потытки выставил так, что слаки по сетапу большие, по холду - на грани: 2.3 нс и 0.2 нс. Залил в плату - все работает.
На плате 4 АЦП, со всеми все ок (на каждый свой pll).
Подвинул фазу так, чтобы сбалансировать сетап и холд. Стали в районе 1.2 нс. Заливаю - не годится.
Получается что я неверно задал констрейны и в первом случае просто пальцем в небо?

ок, беру sdc от des00.
Когда сетап на грани - не работает. Возможно сказываются задержки на плате.
Балансирую сетап и холд. Оба становятся в районе 0.75 нс. Заливаю - порядок.
Как говорится, респект des00.

des00, подскажите, пожалуйста, как вы получили цифры -max 1.0, -min -0.4.
Может подскажете, где я ошибся в своих констрейнах.


Спасибо.

Сообщение отредактировал otv116 - Mar 3 2018, 09:40

Пробовал бороться с задержкой сигнала от DQ пина до LAB через HMCPHY. Как и автор топика.
alt_lvds работает на клоке, сдвинутом относительно ADC_DCO, чтобы защелкивать данные в нужный момент.
В лабе защелкиваю вторым клоком, еще немного сдвинутым. Оба эти клока делаются одной и той же pll в режиме source synchronous.
Между ними добавил мультицикл. Все как предлагал des00.
Ничего толкового не вышло. Из четырех моделей, по которым ведется анализ (комбинации 0С 85С fast slow), всегда какая-то
не проходит. Как я понял, из за того, что путь очень длинный, то его вариации от PVT очень велики в абсолютном значении.
Поэтому подогнав под одну модель, херим другую.

Еще заметил одну вещь.
Я работаю с 5CEBA4F23C7. В нем вообще нет hard memory controller. Но 6 пар из 24 LVDS сигналов АЦП, которые я завел на DQ пины (еще не зная о проблеме), пошли в лаб через HMCPHY. Остальные напрямик, с ними проблемы нет.
Смотрел это в отчете time quest.


Сообщение отредактировал otv116 - Mar 21 2018, 13:07

Кстати, насчёт HMCPHY, может есть у кого доступ на альтерафорум - помогите скачать:
Using Cylcone V HMCPHY DQ pins as high frequency inputs.pdf
Наверное не только мне будет интересно.

Для интереса поменял CEBA на CEFA, у которого есть HMC.
Ничего не изменилось. Кто шел напрямик, тот и идет. Кто через HMCPHY, так и идет через HMCPHY.

-> _Anatoliy
см. аттач.

Спасибо, коллега!
Тоже сталкивался с подобной ситуацией, только не с АЦП а с ЦАП и на Циклоне-3. Два бита из шины данных никак не удавалось усмирить. Прободавшись некоторое время решил забить на это дело, так как нарушений работоспособности не увидел. Изделие выпускается уже 12 лет без нареканий, может мне "повезло" наткнуться на глюк самого STA.

Подстройкой фазы, можно добиться стабильного приёма практически на всем диапазоне частот. Во всяком случае 5 циклон С6 имеет ограничение на прием 800Mb/s. Однако я на этих DQ пинах вполне стабильно вытягивал - 780 Mb/s. А пути между DDR регистрами и логикой - я исключил из анализа времянок.
P.S. Однако данный способ очень кривой и нестабильный, поскольку по какой-то неизвестной мне причине добавление в этот проект дополнительных блоков сбивает стабильный прием, и выше 500 Mb/s уже скорость не поднимается. Думаю тут надо как-то хитро задать времянки.