Timing Constraints, Проблема при работе с Ethernet на скорости 1 Gbs Опции

[Tolas]

Здравствуйте!
Являюсь новичком в 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. А может вообще данные временные ограничения не важны и проблема в чем-то еще?..
Спасибо.

[Tolas]

А опубликуйте, собственно, сам 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? (прошу разъяснить, возможно ли что-то подобное, так как я пока "чайник" в ПЛИС)

[SM]

Извините, не понял, что опубликовать?

В отчете STA жолжен быть детально расписан путь, от пада и до триггера, со всеми задержками на каждом этапе этого пути. Вот его и хотел увидеть. При его длине в 9 нс - физически никак нельзя выполнить констрейны для 125 МГц.

[Bad0512]

В отчете STA жолжен быть детально расписан путь, от пада и до триггера, со всеми задержками на каждом этапе этого пути. Вот его и хотел увидеть. При его длине в 9 нс - физически никак нельзя выполнить констрейны для 125 МГц.

Не совсем так. Просто времянка по данным должна укладываться в требование :
для rising edge - меньше чем 9нс - Tsu
и одновременнно для falling edge - больше чем 9нс + Thold

P.S. такие большие задержки по клоку могут быть из-за :
1. Входящий клок заведен на не клоковый пин.
2. Кривое использование DCM.