doom13 0 27 ноября, 2019 Опубликовано 27 ноября, 2019 · Жалоба 1 hour ago, _sda said: В тексте не видно фальспассов... Взято из template Xilinx, всё что есть Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_sda 0 27 ноября, 2019 Опубликовано 27 ноября, 2019 · Жалоба 18 минут назад, doom13 сказал: Взято из template Xilinx, всё что есть Они забыли Вот что рекомендует Альтера: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
doom13 0 27 ноября, 2019 Опубликовано 27 ноября, 2019 · Жалоба 1 hour ago, _sda said: Вот что рекомендует Альтера: Вот смотрю, какие false path тут можно добавить и не нахожу вариантов. У Альтера всё задаётся относительно двух клоков, один из которых виртуальный, тут такого нет, как для передающей части, так и для приёмной. Вроде как должно быть правильно. Можно проект скачать на 3-ей странице в самом низу, будет наглядней. Вопрос остался. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_sda 0 27 ноября, 2019 Опубликовано 27 ноября, 2019 · Жалоба А мне ваше рассуждение странно. На кой ляд мерять задержки между rising и falling фронтами... Надо бы от rising до rising... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_sda 0 27 ноября, 2019 Опубликовано 27 ноября, 2019 · Жалоба Похоже у нас нестыковки из-за разных методов формирования клока DDR. По диагонали просмотрел ваш вариант, а советы начал давать по другому варианту, который я обычно делаю. Сорри. Этот вариант на картинке. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
doom13 0 27 ноября, 2019 Опубликовано 27 ноября, 2019 · Жалоба 46 minutes ago, _sda said: А мне ваше рассуждение странно. На кой ляд мерять задержки между rising и falling фронтами... Надо бы от rising до rising... Ну как бы интерфейс DDR. Или я не понял что вы хотели сказать? На 2 странице скрины с расчётом прохождения данных и клока. Вы видите там ошибку? Для анализа setup использует clock LAN_RXC fall edge (4.00) и clock LAN_RXC rise edge (8.00). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
doom13 0 27 ноября, 2019 Опубликовано 27 ноября, 2019 · Жалоба Прошу прокомментировать. Спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 28 27 ноября, 2019 Опубликовано 27 ноября, 2019 · Жалоба Приветствую! Выкроил время разобраться что и как с этим DDR Для начала упрощаем задачу - есть SDR порт для которого задается input delay # input ____________________ # clock _____________| |_____________ # | | # dv_bre | dv_are dv_bfe | dv_afe # <------>|<------> <------>|<------> # _ ________|________ ________|________ _ # data _XXXX____Rise_Data____XXXX____Fall_Data____XXXX_ set_input_delay -clock $rgmii_rx_clk -max [expr $rgmiirx_rxc_period/2 - $rgmiirx_dv_bfe] [get_ports $input_ports] set_input_delay -clock $rgmii_rx_clk -min $rgmiirx_dv_are [get_ports $input_ports] После P&R видим timing ошибки setup анализ которых говорит задержка данных 3.992ns - из них 2.8ns это внешняя задержка dv_bfe, соответсвенно задержка пути данных в FPGA всего 1.192ns задержка пути клока для LAN_RXC составляет 1.754ns - казалось бы задержки почти равны - откуда тогда ошибки??? А ошибки из за времени Setup_IDDR_HDIOLOGIC_S_CB_D равного 2.660ns. Как можно понять из названия это требуемое время setup данных на D входе IDDRE1 относительно пина CB. (DS922 Global Clock Input Setup and Hold With 3.3V HD) Получается без дополнительной задержки клока требования по setup не выполнить. Удачи! Rob. P.S. Хотя все одно странное время Setup_IDDR_HDIOLOGIC_S_CB_D. Не понятно как это время считается. В табличке вроде как времена pin to pin приводят. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
doom13 0 27 ноября, 2019 Опубликовано 27 ноября, 2019 · Жалоба 28 minutes ago, RobFPGA said: Получается без дополнительной задержки клока требования по setup не выполнить. Спасибо. Что скажете про передающую сторону (ссылка на пост выше)? Там всё норм? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 28 27 ноября, 2019 Опубликовано 27 ноября, 2019 · Жалоба Приветствую! Интересно получается - если setup время для faling edge 2.660ns а max delay время после rising edge время 2.8ns то формально уложится в требуемый бюджет будет сложно. Так как клок надо задержать на 2.66-1.2 =1.46 ns Но тогда rising edge hold будет 1.2-1.46 = -0.26 ns что очень близко к - 0.35 ns из таблички. Если я конечно чего либо не напутал. Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Avex 1 28 ноября, 2019 Опубликовано 28 ноября, 2019 (изменено) · Жалоба 16 hours ago, doom13 said: Прошу прокомментировать. Спасибо. Вы неверно считаете значение задержек. 1. Сетап. Полный период Т=8 , значение сетап на приемной части tsu-r. Значит, на долю внешней задержки приходится Т - tsu- r(можно еще вычесть задержку по плате, но это расслабит констрейнт) .То же, и по спадающему фронту, но использовать tsu-f. Ошибся. тут все верно. Можно приплюсовать задержку по плате, для реалистичности 2. Холд. Время удержания на приемнике равно tsu-r, поскольку проверка в том же такте. Это и есть холд, в Вашем случае он положительный (с плюсом). По спадающему фронтеу надо использовать thd-f соотв. т.е. ошибка только в знаке. Но можно еще вычесть задержку по плате, для реалистичности 3. Опять нет фалзпасов. Они обязательны при таком способе констрейнинга ddr интерфейса, поскольку констрейнты задаются раздельно - как будто идет работа по райзу клока (полный период - Т), и отдельно - по фоллу клока (снова полный период), а кросс путей (удвоение частоты) между ними нет. Впрочем, если Вы уже задали эти фалзпасы (но не запостили), тогда норм. Второй способ как можно констрейнить ddr - через виртуальные клоки, но не хочу Вас путать. Изменено 28 ноября, 2019 пользователем Aleх Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ielect 0 Вчера в 12:40 Опубликовано вчера в 12:40 · Жалоба I am using two gmii_to_rgmii IP in vivado 2019.1. For, first port (eth0, ie., IP0), I have configured it as external clock of 25MHz (to work for 100MBPs), instantiate idelay control enabled, phy address = 8, and skew added by phy. and It is configured to "include shared logic in core". For second IP (eth1, i.e., IP1), It is configured as external clock to 25Mhz from same source as of IP0, instantiate idelay control enabled, phy address 8 and skew added by phy., and it is configured to "include shared logic in example design". now in block diagram, i have connected ref_in of IP1 with ref_clk_out of IP0. in the constraints file, along with pin assignment, i have added following statements; create_clock -period 40.000 -name eth0_rgmii_txclk [get_ports eth0_rgmii_txclk] create_clock -period 40.000 -name eth0_rgmii_rxclk [get_ports eth0_rgmii_rxclk] create_clock -period 40.000 -name eth1_rgmii_txclk [get_ports eth1_rgmii_txclk] create_clock -period 40.000 -name eth1_rgmii_rxclk [get_ports eth1_rgmii_rxclk] set_property IDELAY_VALUE 16 \ [get_cells -hier -filter {name =~ *delay_rgmii_rxd*}] \ [get_cells -hier -filter {name =~ *delay_rgmii_rx_ctl}] set_property IODELAY_GROUP gmii2rgmii_iodelay_group\ [get_cells -hier -filter {name =~ *idelayctrl}] \ [get_cells -hier -filter {name =~ *delay_rgmii_rxd*}] \ [get_cells -hier -filter {name =~ *delay_rgmii_rx_ctl}] Now, when i bootup my zynq-7030 customized board, eth0 and eth1 does not work on same subnet. in case I use different subnet then eth0 is still unstable; it drops packets when i ping it from my PC. Is there anything wrong in my design or in my approach? Any help is highly appreciated. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться