реклама на сайте
подробности

 
 
2 страниц V  < 1 2  
Reply to this topicStart new topic
> Timing Constraints, Проблема при работе с Ethernet на скорости 1 Gbs
AndreiUS
сообщение Jan 28 2015, 11:50
Сообщение #16


Местный
***

Группа: Свой
Сообщений: 293
Регистрация: 23-12-08
Из: Тверь
Пользователь №: 42 694



Все зависит от PHY. Если у Вас MAC-интрефейс RGMII и фронты тактового сигнала совпадают с началом/концом данных (нет сдвига, именно так работает например 88E1111 и 88E1145 по умолчанию), то можно применить констрейн наподобие снизу:

Код
NET "rgmii_rx_clk0" TNM_NET = "phy_clk_rx0";
TIMESPEC TS_phy_rx0 = PERIOD "phy_rx0" 8 ns HIGH 50 %;
///////////////////////////////////////////////////////
INST "rgmii_rxd0[0]" TNM = "rgmii_rx_d0_0";
INST "rgmii_rxd0[1]" TNM = "rgmii_rx_d0_1";
INST "rgmii_rxd0[2]" TNM = "rgmii_rx_d0_2";
INST "rgmii_rxd0[3]" TNM = "rgmii_rx_d0_3";
INST "rgmii_rx_ctl0" TNM = "rgmii_rx_ctrl0";
///////////////////////////////////////////////////////
TIMEGRP "rgmii_rx_d0_0" OFFSET = IN 0 ns VALID 3.5 ns BEFORE "rgmii_rx_clk0" RISING;
TIMEGRP "rgmii_rx_d0_0" OFFSET = IN 0 ns VALID 3.5 ns BEFORE "rgmii_rx_clk0" FALLING;

TIMEGRP "rgmii_rx_d0_1" OFFSET = IN 0 ns VALID 3.5 ns BEFORE "rgmii_rx_clk0" RISING;
TIMEGRP "rgmii_rx_d0_1" OFFSET = IN 0 ns VALID 3.5 ns BEFORE "rgmii_rx_clk0" FALLING;

TIMEGRP "rgmii_rx_d0_2" OFFSET = IN 0 ns VALID 3.5 ns BEFORE "rgmii_rx_clk0" RISING;
TIMEGRP "rgmii_rx_d0_2" OFFSET = IN 0 ns VALID 3.5 ns BEFORE "rgmii_rx_clk0" FALLING;

TIMEGRP "rgmii_rx_d0_3" OFFSET = IN 0 ns VALID 3.5 ns BEFORE "rgmii_rx_clk0" RISING;
TIMEGRP "rgmii_rx_d0_3" OFFSET = IN 0 ns VALID 3.5 ns BEFORE "rgmii_rx_clk0" FALLING;

TIMEGRP "rgmii_rx_ctrl0" OFFSET = IN 0 ns VALID 3.5 ns BEFORE "rgmii_rx_clk0" RISING;
TIMEGRP "rgmii_rx_ctrl0" OFFSET = IN 0 ns VALID 3.5 ns BEFORE "rgmii_rx_clk0" FALLING;


При этом по входам придется разместить элементы задержки IODELAY с правильно выставленнымми временами задержки, например так:
Код
   (* IODELAY_GROUP = "group_1_0" *) // Specifies group name for associated IODELAYs and IDELAYCTRL
   IODELAY # (
      .DELAY_SRC("I"),  // Specify which input port to be used, "I"=IDATAIN,
                        //  "O"=ODATAIN, "DATAIN"=DATAIN, "IO"=Bi-directional
      .HIGH_PERFORMANCE_MODE("TRUE"), // "TRUE" specifies lower jitter
                                      //   at expense of more power
      .IDELAY_TYPE("FIXED"),  // "FIXED" or "VARIABLE"
      .IDELAY_VALUE(15),         // 0 to 63 tap values
      .ODELAY_VALUE(0),         // 0 to 63 tap values
      .REFCLK_FREQUENCY(200.0), // Frequency used for IDELAYCTRL
                                //   175.0 to 225.0
      .SIGNAL_PATTERN("DATA")  // Input signal type, "CLOCK" or "DATA"
   ) IODELAY_D0 (
      .DATAOUT(rgmii_rxd_delay[0]),   // 1-bit delayed data output
      .C(1'b0),     // 1-bit clock input
      .CE(1'b0),   // 1-bit clock enable input
      .DATAIN(1'b0),     // 1-bit internal data input
      .IDATAIN(rgmii_rxd[0]),   // 1-bit input data input (connect to port)
      .INC(1'b0), // 1-bit increment/decrement input
      .ODATAIN(),   // 1-bit output data input
      .RST(1'b0), // 1-bit active high, synch reset input
      .T(1'b0)      // 1-bit 3-state control input
   );

В отчете должно получиться примерно следующее:
Код
Slack (setup path):     0.987ns (requirement - (data path - clock path - clock arrival + uncertainty))
   Source:               rgmii_rxd0<0> (PAD)
   Destination:          RGMII_test/rgmii_0/IDDR_0 (FF)
   Destination Clock:    RGMII_test/rgmii_0/clk_out_iodelay rising at 0.000ns
   Requirement:          0.000ns
   Data Path Delay:      2.939ns (Levels of Logic = 2)
   Clock Path Delay:     3.951ns (Levels of Logic = 3)
   Clock Uncertainty:    0.025ns

Т.е. TSetup~1нс, чего вполне достаточно для корректного приема.
Go to the top of the page
 
+Quote Post
Tolas
сообщение Jan 28 2015, 13:53
Сообщение #17


Участник
*

Группа: Участник
Сообщений: 53
Регистрация: 14-11-10
Пользователь №: 60 881



Цитата(Bad0512 @ Jan 28 2015, 14:16) *
P.S. такие большие задержки по клоку могут быть из-за :
1. Входящий клок заведен на не клоковый пин.
2. Кривое использование DCM.

1) Сигнал e0gtxclk заведен на V26 (IO_L40P_GCLK11_M1A5_1), сигнал e0rxclk на W27 (IO_L41P_GCLK9_IRDY1_M1RASN_1), сигнал e0txclk на W28 (IO_L41N_GCLK8_M1CASN_1).
Если я правильно понимаю, это клоковые пины, но так как я новичок rolleyes.gif , я могу ошибаться, поправьте меня пожалуйста, если это не так.
Такое ощущение, что проблема во внутренних сигналах TX_CLKG и RX_CLKG. Может их надо как-то "по особому" определить?
2) Очень может быть, что здесь "кривое использование DCM", так как я не знаю что это. rolleyes.gif Может направите где узнать об этом можно?
Go to the top of the page
 
+Quote Post
Bad0512
сообщение Jan 29 2015, 04:39
Сообщение #18


Знающий
****

Группа: Свой
Сообщений: 802
Регистрация: 11-05-07
Из: Томск
Пользователь №: 27 650



Цитата(Tolas @ Jan 28 2015, 19:53) *
1) Сигнал e0gtxclk заведен на V26 (IO_L40P_GCLK11_M1A5_1), сигнал e0rxclk на W27 (IO_L41P_GCLK9_IRDY1_M1RASN_1), сигнал e0txclk на W28 (IO_L41N_GCLK8_M1CASN_1).
Если я правильно понимаю, это клоковые пины, но так как я новичок rolleyes.gif , я могу ошибаться, поправьте меня пожалуйста, если это не так.
Такое ощущение, что проблема во внутренних сигналах TX_CLKG и RX_CLKG. Может их надо как-то "по особому" определить?
2) Очень может быть, что здесь "кривое использование DCM", так как я не знаю что это. rolleyes.gif Может направите где узнать об этом можно?

1. У 6 Спартана есть одна странная особенность. У него 24 клоковых буфера на чип. Но из них всего 8 являются полноценно глобальными, остальные 16 - могут напрямую драйвить только половину (левую или правую) чипа.
У вас выбраны клоковые пины, однако оба они могут напрямую драйвить только правую половину чипа. Соответственно если какая-то логика (или пины I/O) расположены в левой половине (это можно поглядеть в XDE или PlanAhead) то путь клока до этих элементов сильно удлиняется. Обо всём этом можно почитать в ug382. Чтобы что-то сказать наверняка надо поглядеть развёрнутый тайминг репорт полностью. Если не затруднит - выложите плиз.
2. Если вы сами не пытались вставлять DCM для компенсации задержки по клоку, то скорее всего в пути клока нет неправильно включенной DCM. О том как использовать DCM также можно почитать в ug382.
Go to the top of the page
 
+Quote Post
Tolas
сообщение Jan 29 2015, 06:51
Сообщение #19


Участник
*

Группа: Участник
Сообщений: 53
Регистрация: 14-11-10
Пользователь №: 60 881



top_tcp.txt - это ucf файл, там я подправил Timing Constraints, но что-то я опять не уверен в их правильности...
top_tcp_twx.txt - это файл, сгенерированный Timing Analyzer Post-Place & Route. Мне там не нравится сигнал e0tx_en, что-то слишком большая задержка у него, если я правильно понимаю. Он уходит с ПЛИС на физ.уровень, с компоненты TOP_LEVEL_TCP, COM5401, GMII_MII_WRAPPER сигнала TX_EN, который тоже в свою очередь вносит задержку. Можно ли эти задержки как-то минимизировать?

P.S. файлы .txt формата, так как мне нельзя загружать файлы форматов .ucf и .twx.

Прикрепленный файл  top_tcp.txt ( 6.55 килобайт ) Кол-во скачиваний: 223

Прикрепленный файл  top_tcp_twx.txt ( 228.92 килобайт ) Кол-во скачиваний: 154


Сообщение отредактировал Tolas - Jan 29 2015, 09:34
Go to the top of the page
 
+Quote Post
Tolas
сообщение Jan 29 2015, 08:56
Сообщение #20


Участник
*

Группа: Участник
Сообщений: 53
Регистрация: 14-11-10
Пользователь №: 60 881



Цитата
Все зависит от PHY. Если у Вас MAC-интрефейс RGMII и фронты тактового сигнала совпадают с началом/концом данных (нет сдвига, именно так работает например 88E1111 и 88E1145 по умолчанию)

Я использую GMII, ниже приведу рисунок из Datasheet на Marvell Alaska с временными характеристиками для gtx_clk сигнала.
Прикрепленное изображение

Еще нашел для tx_en:
Прикрепленное изображение

Я так понимаю, исходя из этих данных, я должен составить правильные Timing Constraint... Для GTX_CLK period боле-менее понятно, а вот как это соотносится с сигналами данных TXD?..
Go to the top of the page
 
+Quote Post
Timmy
сообщение Jan 29 2015, 09:45
Сообщение #21


Знающий
****

Группа: Участник
Сообщений: 835
Регистрация: 9-08-08
Из: Санкт-Петербург
Пользователь №: 39 515



Цитата(Tolas @ Jan 29 2015, 11:56) *
Я использую GMII, ниже приведу рисунок из Datasheet на Marvell Alaska с временными характеристиками для gtx_clk сигнала.
Я так понимаю, исходя из этих данных, я должен составить правильные Timing Constraint... Для GTX_CLK period боле-менее понятно, а вот как это соотносится с сигналами данных TXD?..

Разброс между выходным клоком и данными в ISE нельзя по-нормальному обконстрейнить. В данном случае можно объединить в группу сигналы GTX_CLK, TDX*, и задать для неё пустой(Analize only) OFFSET OUT с REFERENCE_PIN "GTX_CLK". Всё это делается, при желании, с помощью визарда. Тогда в отчёте будет максимальный разброс между данными и клоком, и можно глазами проверить, что он маленький. Если при этом восходящий фронт клока выровнен по середине данных(в этом можно убедиться в симуляции, или просто анализом дизайна), то всё в порядке.

Для RXD* можно задать OFFSET 2.5 ns VALID 3ns в соответствии с другим рисунком из даташита(если не учитывать PCB skew). Для этого тоже подойдёт визард, он ещё соотвествующую картинку показывает.
Go to the top of the page
 
+Quote Post
Tolas
сообщение Aug 30 2016, 13:30
Сообщение #22


Участник
*

Группа: Участник
Сообщений: 53
Регистрация: 14-11-10
Пользователь №: 60 881



Цитата(Timmy @ Jan 29 2015, 12:45) *
Разброс между выходным клоком и данными в ISE нельзя по-нормальному обконстрейнить. В данном случае можно объединить в группу сигналы GTX_CLK, TDX*, и задать для неё пустой(Analize only) OFFSET OUT с REFERENCE_PIN "GTX_CLK". Всё это делается, при желании, с помощью визарда. Тогда в отчёте будет максимальный разброс между данными и клоком, и можно глазами проверить, что он маленький. Если при этом восходящий фронт клока выровнен по середине данных(в этом можно убедиться в симуляции, или просто анализом дизайна), то всё в порядке.

Для RXD* можно задать OFFSET 2.5 ns VALID 3ns в соответствии с другим рисунком из даташита(если не учитывать PCB skew). Для этого тоже подойдёт визард, он ещё соотвествующую картинку показывает.


Скажите, пожалуйста, а нельзя ли задать в моем случае констрейны для выходных сигналов TXD используя входную тактовую RX_CLK? Напоминаю код:
Код
RX_CLKG <= RX_CLK;
TX_CLKG <= RX_CLK;
Go to the top of the page
 
+Quote Post

2 страниц V  < 1 2
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 18th July 2025 - 23:49
Рейтинг@Mail.ru


Страница сгенерированна за 0.01419 секунд с 7
ELECTRONIX ©2004-2016