|
Timing Constraints, Проблема при работе с Ethernet на скорости 1 Gbs |
|
|
|
Jan 28 2015, 06:34
|

Участник

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

|
Здравствуйте! Являюсь новичком в VHDL и вообще проектировании на ПЛИС, поэтому просьба сильно не ругать Имеется ПЛИС Spartan6 xc6slx150t-2fgg900. Так же имеется сторонняя реализация TCP/IP стека на VHDL с возможностью работать на скорости 1 Gbs. Разработчики TCP/IP стека рекомендуют задавать следующие Timing constrains: CODE # NET "e0rx_clk" PERIOD = 40 ns; OFFSET = IN 10 ns BEFORE "e0rx_clk"; NET "e0tx_clk" PERIOD = 40 ns; OFFSET = OUT 20 ns AFTER "e0tx_clk"; OFFSET = IN 10 ns BEFORE "e0tx_clk";
NET "e0rx_clk" TNM_NET = "e0rx_clk"; NET "e0tx_clk" TNM_NET = "e0tx_clk";
TIMESPEC TS_erxclk = PERIOD "e0rx_clk" 36 ns; TIMESPEC TS_etxclk = PERIOD "e0tx_clk" 36 ns; # OFFSET = IN 8 ns VALID 15 ns BEFORE "e0rx_clk"; OFFSET = OUT 15 ns AFTER "e0tx_clk";
# place a constraint on the LAN tx signals timing NET "e0tx_clk" TNM = "LAN_TX_OUT"; #NET "TX_CTL" TNM = "LAN_TX_OUT"; NET "e0tx_en" TNM = "LAN_TX_OUT"; NET "e0tx_er" TNM = "LAN_TX_OUT"; NET "e0txd[0]" TNM = "LAN_TX_OUT"; NET "e0txd[1]" TNM = "LAN_TX_OUT"; NET "e0txd[2]" TNM = "LAN_TX_OUT"; NET "e0txd[3]" TNM = "LAN_TX_OUT"; NET "e0txd[4]" TNM = "LAN_TX_OUT"; NET "e0txd[5]" TNM = "LAN_TX_OUT"; NET "e0txd[6]" TNM = "LAN_TX_OUT"; NET "e0txd[7]" TNM = "LAN_TX_OUT";
TIMEGRP "LAN_TX_OUT" OFFSET = OUT 10.5 ns AFTER "e0rx_clk"; # In addition, place a constraint on the input pins from the PHY to minimize the delay spread among the rx pins # place a constraint on the LAN rx signals timing #NET "RX_CTL" TNM = "LAN_RX_IN"; NET "e0rx_er" TNM = "LAN_RX_IN"; NET "e0rxd[0]" TNM = "LAN_RX_IN"; NET "e0rxd[1]" TNM = "LAN_RX_IN"; NET "e0rxd[2]" TNM = "LAN_RX_IN"; NET "e0rxd[3]" TNM = "LAN_RX_IN"; NET "e0rxd[4]" TNM = "LAN_RX_IN"; NET "e0rxd[5]" TNM = "LAN_RX_IN"; NET "e0rxd[6]" TNM = "LAN_RX_IN"; NET "e0rxd[7]" TNM = "LAN_RX_IN";
TIMEGRP "LAN_RX_IN" OFFSET = IN 0.5 ns BEFORE "e0rx_clk"; для сигналов Ethernet (надеюсь назначение выводов понятно по их названию). Так вот, при сборке проекта в среде Xilinx ISE 14.4, я получаю следующие ошибки в Timing Analyzer (приведу для сигнала e0txd<6>, но примерно тоже самое получается и для сигналов e0txd<5> и e0txd<2>): CODE Paths for end point e0txd<6> (V30.PAD), 1 path -------------------------------------------------------------------------------- Slack (slowest paths): -3.001ns (requirement - (clock arrival + clock path + data path + uncertainty)) Source: e0/Inst_Top_level_TCP/Inst_COM5401/IF_SEL_002.Inst_GMII_MII_WRAPPER/TXD_6 (FF) Destination: e0txd<6> (PAD) Source Clock: e0/Inst_Top_level_TCP/Inst_COM5401/TX_CLKG rising at 0.000ns Requirement: 10.500ns Data Path Delay: 4.111ns (Levels of Logic = 1) Clock Path Delay: 9.365ns (Levels of Logic = 4) Clock Uncertainty: 0.025ns Clock Uncertainty: 0.025ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE Total System Jitter (TSJ): 0.050ns Total Input Jitter (TIJ): 0.000ns Discrete Jitter (DJ): 0.000ns Phase Error (PE): 0.000ns Maximum Clock Path at Slow Process Corner: e0rx_clk to e0/Inst_Top_level_TCP/Inst_COM5401/IF_SEL_002.Inst_GMII_MII_WRAPPER/TXD_6 Location Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------- ------------------- W27.I Tiopi 1.557 e0rx_clk e0rx_clk clk_pad1/xcv2.u0/g0.ttl0.ip ProtoComp1105.IMUX.23 BUFIO2_X4Y18.I net (fanout=1) 0.627 e0rx_clk_signal BUFIO2_X4Y18.DIVCLK Tbufcko_DIVCLK 0.190 e0/Inst_Top_level_TCP/Inst_COM5401/IF_SEL_002.Inst_GMII_MII_WRAPPER/BUFIO2_inst e0/Inst_Top_level_TCP/Inst_COM5401/IF_SEL_002.Inst_GMII_MII_WRAPPER/BUFIO2_inst BUFGMUX_X2Y3.I0 net (fanout=1) 1.327 e0/Inst_Top_level_TCP/Inst_COM5401/IF_SEL_002.Inst_GMII_MII_WRAPPER/RX_CLK2 BUFGMUX_X2Y3.O Tgi0o 0.209 e0/Inst_Top_level_TCP/Inst_COM5401/IF_SEL_002.Inst_GMII_MII_WRAPPER/BUFG_001 e0/Inst_Top_level_TCP/Inst_COM5401/IF_SEL_002.Inst_GMII_MII_WRAPPER/BUFG_001 BUFGMUX_X3Y5.I1 net (fanout=62) 2.826 e0/Inst_Top_level_TCP/Inst_COM5401/RX_CLKG BUFGMUX_X3Y5.O Tgi1o 0.209 e0/Inst_Top_level_TCP/Inst_COM5401/IF_SEL_002.Inst_GMII_MII_WRAPPER/BUFGMUX_inst e0/Inst_Top_level_TCP/Inst_COM5401/IF_SEL_002.Inst_GMII_MII_WRAPPER/BUFGMUX_inst OLOGIC_X35Y94.CLK0 net (fanout=85) 2.420 e0/Inst_Top_level_TCP/Inst_COM5401/TX_CLKG ------------------------------------------------- --------------------------- Total 9.365ns (2.165ns logic, 7.200ns route) (23.1% logic, 76.9% route) Maximum Data Path at Slow Process Corner: e0/Inst_Top_level_TCP/Inst_COM5401/IF_SEL_002.Inst_GMII_MII_WRAPPER/TXD_6 to e0txd<6> Location Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------- ------------------- OLOGIC_X35Y94.OQ Tockq 1.080 e0/Inst_Top_level_TCP/Inst_COM5401/IF_SEL_002.Inst_GMII_MII_WRAPPER/TXD<6> e0/Inst_Top_level_TCP/Inst_COM5401/IF_SEL_002.Inst_GMII_MII_WRAPPER/TXD_6 V30.O net (fanout=1) 0.309 e0/Inst_Top_level_TCP/Inst_COM5401/IF_SEL_002.Inst_GMII_MII_WRAPPER/TXD<6> V30.PAD Tioop 2.722 e0txd<6> e0txd_6_OBUF e0txd<6> ------------------------------------------------- --------------------------- Total 4.111ns (3.802ns logic, 0.309ns route) (92.5% logic, 7.5% route) -------------------------------------------------------------------------------- На скорости 10/100 Mbs интерфейс Ethernet работает вполне себе нормально. Проблема именно со скоростью 1 Gbs. Из-за отсутствия понимания логики приведенных Timing Constraints, у меня возникли следующие вопросы: 1. Данные временные ограничения важны только для 1 Gbs? (Раз уж 10/100 работает); 2. Что нужно сделать чтобы "попасть" в заданные временные ограничения? 3. А может вообще данные временные ограничения не важны и проблема в чем-то еще?.. Спасибо.
|
|
|
|
2 страниц
1 2 >
|
 |
Ответов
(1 - 14)
|
Jan 28 2015, 08:25
|

Участник

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

|
Цитата крутяк! интересно сколько стоит такая корка ? Здесь можно посмотреть цены и варианты.Цитата Те констрейнты, которые вы привели, относятся к конкретной физической реализации платы. Если у вас другая плата, другая ПЛИС, или другая микросхема PHY констрейнты требуют уточнения. Плата другая, не типичная (не Kit). Разработчики ядра утверждают, что тестировали на ПЛИС Xilinx Spartan-6 XC6SLX16 FPGA со скоростью -2, и у них все было замечательно. Если я не ошибаюсь, используемая мной ПЛИС "помощнее" и должна "тянуть" данный код. Микросхема PHY другая, разработчики ядра тестировали на Micrel KSZ 9021, у меня стоит Marvell Alaska 88E1111.
|
|
|
|
|
Jan 28 2015, 09:04
|

Участник

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

|
Цитата Что-то мне не нравится "Clock Path Delay: 9.365ns (Levels of Logic = 4) " Самому не нравятся сигналы RX_CLKG и TX_CLKG Вот такая часть кода там присутствует: CODE -- two cases: @1000 Mbps (GMII), the GTX_CLK is an output . At 10/100Mbps (MII), the TX_CLK in an input.
-- In the 1000Mbps mode, we must provide a 125 MHz GTX_CLK to the PHY. Make tx clock <= rx clock frequency. -- In the 10/100 Mbps mode, the TX_CLKG clock is generated by the PHY (may drift w.r.t rx clock frequency) -- IMPORTANT Key design assumption: PHY always generates a RX_CLK, even when no cable is connected.
BUFGMUX_inst : BUFGMUX generic map ( CLK_SEL_TYPE => "SYNC" -- Glitchless ("SYNC") or fast ("ASYNC") clock switch-over ) port map ( O => TX_CLKG, -- 1-bit output: Clock buffer output I0 => TX_CLK, -- 1-bit input: Clock buffer input (S=0) I1 => RX_CLKG, -- 1-bit input: Clock buffer input (S=1) S => GMII_FLAG -- 1-bit input: Clock buffer select ); Как я понял, в зависимости от скорости выбирается что идет на выход - TX_CLK или RX_CLKG. При 1 GBs получается что туда идет RX_CLKG. Которая в свою очередь идет через "странную" конструкцию: CODE BUFIO2_inst : BUFIO2 generic map ( DIVIDE => 1, -- DIVCLK divider (1-8) DIVIDE_BYPASS => TRUE, -- Bypass the divider circuitry (TRUE/FALSE) I_INVERT => FALSE, -- Invert clock (TRUE/FALSE) USE_DOUBLER => FALSE -- Use doubler circuitry (TRUE/FALSE) ) port map ( DIVCLK => RX_CLK2, -- 1-bit output Divided clock output IOCLK => open, -- 1-bit output I/O output clock SERDESSTROBE => open, -- 1-bit output Output SERDES strobe (connect to ISERDES2/OSERDES2) I => RX_CLK -- 1-bit input Clock input (connect to IBUFG) );
-- declare the RX clock as a global clock BUFG_001 : BUFG port map ( O => RX_CLKG, -- Clock buffer output I => RX_CLK2 -- Clock buffer input );
Где RX_CLK передается в IP-ядро с нижнего уровня, прямиком с ножки ПЛИС.
|
|
|
|
|
Jan 28 2015, 10:38
|

Участник

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

|
Цитата А опубликуйте, собственно, сам Clock Path по отчету. Извините, не понял, что опубликовать? Упростил весь код до "паренной репы": CODE RX_CLKG <= RX_CLK; TX_CLKG <= RX_CLKG;
Timing constraints уладились. На ping стал отвечать. Для 1 Gbs пока сойдет. По заданию данный интерфейс должен работать только в этом режиме. Но... Есть одно но... Таких интерфейсов должно быть 2. Но второй интерфейс пингуется "через раз", а то и реже. Timing Constraints у него идентичны первому интерфейсу, timing constraints errors так же уладились. Если они абсолютно идентичны друг другу логически, то скорее всего ошибка где-то на физике? Или, может быть, как вариант, ПЛИС "тяжело" генерировать 2 частоты 125 MHz на выход для PHY? (прошу разъяснить, возможно ли что-то подобное, так как я пока "чайник" в ПЛИС)
|
|
|
|
|
Jan 28 2015, 10:47
|

Участник

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

|
Цитата Предлагаю самостоятельно осилить операцию типа 1/x , посчитать тактовую частоту интерфейса и подумать как это соотносится с 1Gbps.... 40 нс - это период для частоты 25 МГц, используемой для 100 МБит/с. Правильно ли я понимаю, что мне нужно изменить данное значение на 8 нс для 125 МГц?
|
|
|
|
|
Jan 28 2015, 10:49
|
Знающий
   
Группа: Участник
Сообщений: 835
Регистрация: 9-08-08
Из: Санкт-Петербург
Пользователь №: 39 515

|
Цитата(Tolas @ Jan 28 2015, 13:38)  Упростил весь код до "паренной репы": Таких интерфейсов должно быть 2. Но второй интерфейс пингуется "через раз", а то и реже. Timing Constraints у него идентичны первому интерфейсу, timing constraints errors так же уладились. Если они абсолютно идентичны друг другу логически, то скорее всего ошибка где-то на физике? Или, может быть, как вариант, ПЛИС "тяжело" генерировать 2 частоты 125 MHz на выход для PHY? (прошу разъяснить, возможно ли что-то подобное, так как я пока "чайник" в ПЛИС) Видимая проблема в том, что констрейны не полны, и к тому же не соответствуют требованиям гигабитного интерфейса 88E1111. Так что даже их выполнение работоспособности не гарантирует. Несоответствие есть как по тактовой частоте, так и по setup/hold.
|
|
|
|
|
Jan 28 2015, 11:16
|
Знающий
   
Группа: Свой
Сообщений: 802
Регистрация: 11-05-07
Из: Томск
Пользователь №: 27 650

|
Цитата(SM @ Jan 28 2015, 16:51)  В отчете STA жолжен быть детально расписан путь, от пада и до триггера, со всеми задержками на каждом этапе этого пути. Вот его и хотел увидеть. При его длине в 9 нс - физически никак нельзя выполнить констрейны для 125 МГц. Не совсем так. Просто времянка по данным должна укладываться в требование : для rising edge - меньше чем 9нс - Tsu и одновременнно для falling edge - больше чем 9нс + Thold P.S. такие большие задержки по клоку могут быть из-за : 1. Входящий клок заведен на не клоковый пин. 2. Кривое использование DCM.
|
|
|
|
|
Jan 28 2015, 11:34
|
Гуру
     
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881

|
Цитата(Bad0512 @ Jan 28 2015, 14:16)  Не совсем так. Просто времянка по данным должна укладываться в требование : для rising edge - меньше чем 9нс - Tsu и одновременнно для falling edge - больше чем 9нс + Thold Тогда уж надо редуцировать длину всего пути на целое кол-во периодов по 8 нс - останется 1 нс. Но я имел в виду не это, что именно констрейны при этом не выдержать, формально то можно, а то, что такой latency скорее всего приведет к каким нибудь неприятностям, связанным с невозможностью вовремя взвести какой либо сигнал, по причине задержки более, чем на 1 такт. То есть, немного некорректно высказался.
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|