[doom13 0]

1 hour ago, _sda said:

В тексте не видно фальспассов...

Взято из template Xilinx, всё что есть

[_sda 0]

18 минут назад, doom13 сказал:

Взято из template Xilinx, всё что есть

Они забыли 

Вот что рекомендует Альтера:

[doom13 0]

1 hour ago, _sda said:

Вот что рекомендует Альтера:

Вот смотрю, какие false path тут можно добавить и не нахожу вариантов. У Альтера всё задаётся относительно двух клоков, один из которых виртуальный, тут такого нет, как для передающей части, так и для приёмной. Вроде как должно быть правильно.

 

Можно проект скачать на 3-ей странице в самом низу, будет наглядней.

Вопрос остался.

 

[_sda 0]

А мне ваше рассуждение странно. На кой ляд мерять задержки между rising и falling фронтами... Надо бы от rising до rising...

[_sda 0]

Похоже у нас нестыковки из-за разных методов формирования клока DDR. По диагонали просмотрел ваш вариант, а советы начал давать по другому варианту, который я обычно делаю. Сорри.

Этот вариант на картинке.

[doom13 0]

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]

Прошу прокомментировать. Спасибо.

[RobFPGA 28]

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

Выкроил время разобраться что и как с этим 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]

28 minutes ago, RobFPGA said:

Получается без дополнительной задержки клока  требования по setup не выполнить.

Спасибо. Что скажете про передающую сторону (ссылка на пост выше)? Там всё норм?

[RobFPGA 28]

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

Интересно получается  - если 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]

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]

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.