[andrew_b 14]

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

Din [0] DFFIO_RX_B75/B_DQS_3
Din [1] DFFIO_RX_B82/B_DQ33 *
Din [2] DFFIO_RX_B71
Din [3] DFFIO_RX_B70/B_DQ21 *
Din [4] DFFIO_RX_B78/B_DQ29 *
Din [5] DFFIO_RX_B66/B_DQ17 *
Din [6] DFFIO_RX_B62/B_DQ13 *
Din [7] DFFIO_RX_B74/B_DQ25 *
Din [8] DFFIO_RX_B79
Din [9] DFFIO_RX_B51/B_DQS_0
Din [10] DFFIO_RX_B58/B_DQ9 *
Din [11] DFFIO_RX_B50/B_DQ1 *
Din [12] DFFIO_RX_B54/B_DQ4 *
Din [13] DFFIO_RX_B67/B_DQS_2

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

Начал прочёсывать интернет. И выяснилось:

 

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

Cyclone V DQ pin used for user pin(not DDR DQ pin), always need to route through HMCPHY_RE. this routing element would cause almost 2ns differnece between setup and hold. no way to bypass it.

so never use DQ pins as high speed input or output in cyclone V

 

С одной стороны, эти 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" как бы намекает на второй.

 

[des00 25]

И "never used" как бы намекает на второй.

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

 

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

 

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

[andrew_b 14]

лечите PLLкой. клоки с разными фазами для разных линий. Собираете в регистры.

Не вопрос.

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

[des00 25]

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

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

 

[andrew_b 14]

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

 

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

 

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

 

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

Post-synthesis and post-fit gate-level simulations run significantly slower than RTL simulation. Altera

recommends that you verify your design using RTL simulation for functionality and use the TimeQuest

timing analyzer for timing. Timing simulation is not supported for Arria V, Cyclone V, Stratix V, and

newer families.

Гады.

[otv116 0]

Добрый день.

Делаю прошивку под C-III как раз с АЦП AD9634, который тут упоминался.

Все работает нормально, но хочу навести порядок в голове с констрейнами по входу.

Вопрос возник по примеру sdc, что предоставил des00.

Сначала опишу что сделал сам.

Решил тоже не юзать виртуальный клок, а описывать непосредственно от DCO.

По даташиту фронт DCO запаздывает за данными на Tskew (0.3 : 0.7 нс).

Соответственно:

set_input_delay -max -clock [get_clocks {ADC1DCO}] -0.3 [get_ports {ADC1Data[*]}]
set_input_delay -max -clock [get_clocks {ADC1DCO}] -clock_fall -0.3 [get_ports {ADC1Data[*]}] -add_delay

set_input_delay -min -clock [get_clocks {ADC1DCO}]   -0.7 [get_ports {ADC1Data[*]}] -add_delay
set_input_delay -min -clock [get_clocks {ADC1DCO}] -clock_fall -0.7 [get_ports {ADC1Data[*]}] -add_delay

set_false_path -rise_from [get_clocks {ADC1DCO}]  -fall_to [get_clocks {adc1pll|altpll_component|auto_generated|pll1|clk[0]}]
set_false_path -fall_from [get_clocks {ADC1DCO}]  -rise_to [get_clocks {adc1pll|altpll_component|auto_generated|pll1|clk[0]}]

Задержки по плате не учитываю, т.к. АЦП близко к 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.

Может подскажете, где я ошибся в своих констрейнах.

 

 

Спасибо.

Изменено 3 марта, 2018 пользователем otv116

[otv116 0]

Пробовал бороться с задержкой сигнала от 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.

 

Изменено 21 марта, 2018 пользователем otv116

[_sda 0]

Кстати, насчёт HMCPHY, может есть у кого доступ на альтерафорум - помогите скачать:

Using Cylcone V HMCPHY DQ pins as high frequency inputs.pdf

Наверное не только мне будет интересно.

[otv116 0]

Для интереса поменял CEBA на CEFA, у которого есть HMC.

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

 

-> _Anatoliy

см. аттач.

Using_Cylcone_V_HMCPHY_DQ_pins_as_high_frequency_inputs.pdf

[_sda 0]

Спасибо, коллега!

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

[Flip-fl0p 4]

Спасибо, коллега!

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

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

P.S. Однако данный способ очень кривой и нестабильный, поскольку по какой-то неизвестной мне причине добавление в этот проект дополнительных блоков сбивает стабильный прием, и выше 500 Mb/s уже скорость не поднимается. Думаю тут надо как-то хитро задать времянки.