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

[dm.pogrebnoy]

Те констрейнты, которые вы привели, относятся к конкретной физической реализации платы. Если у вас другая плата, другая ПЛИС, или другая микросхема PHY констрейнты требуют уточнения.

[des00]

Так же имеется сторонняя реализация TCP/IP стека на VHDL

крутяк! интересно сколько стоит такая корка ?

[Tolas]

крутяк! интересно сколько стоит такая корка ?

Здесь можно посмотреть цены и варианты.

Те констрейнты, которые вы привели, относятся к конкретной физической реализации платы. Если у вас другая плата, другая ПЛИС, или другая микросхема PHY констрейнты требуют уточнения.

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

[SM]

Что-то мне не нравится "Clock Path Delay: 9.365ns (Levels of Logic = 4) "

похоже, Вы его туда как-то криво завели....

[Tolas]

Что-то мне не нравится "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-ядро с нижнего уровня, прямиком с ножки ПЛИС.

[SM]

Да-да. Вот там и ищите, почему оно так вышло. Явно можно было пустить клоки как-то короче (я не спец по физическому устройству xilinx). У Вас ПЛИС значительно больше, поэтому, и задержки в деревьях тактовых сигналов тоже больше. Поэтому у них в мелкой все ОК, а у Вас - уже нет.

А опубликуйте, собственно, сам Clock Path по отчету. Откуда там 4 уровня то? Может оно каким-то раком пошло через разные регионы?

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

[Bad0512]

NET "e0rx_clk" PERIOD = 40 ns;
NET "e0tx_clk" PERIOD = 40 ns;

Предлагаю самостоятельно осилить операцию типа 1/x , посчитать тактовую частоту интерфейса и подумать как это соотносится с 1Gbps....

[Tolas]

Предлагаю самостоятельно осилить операцию типа 1/x , посчитать тактовую частоту интерфейса и подумать как это соотносится с 1Gbps....

40 нс - это период для частоты 25 МГц, используемой для 100 МБит/с.
Правильно ли я понимаю, что мне нужно изменить данное значение на 8 нс для 125 МГц?

[SM]

Да, однозначно.

[Timmy]

Упростил весь код до "паренной репы":
Таких интерфейсов должно быть 2. Но второй интерфейс пингуется "через раз", а то и реже.
Timing Constraints у него идентичны первому интерфейсу, timing constraints errors так же уладились.
Если они абсолютно идентичны друг другу логически, то скорее всего ошибка где-то на физике?
Или, может быть, как вариант, ПЛИС "тяжело" генерировать 2 частоты 125 MHz на выход для PHY? (прошу разъяснить, возможно ли что-то подобное, так как я пока "чайник" в ПЛИС)

Видимая проблема в том, что констрейны не полны, и к тому же не соответствуют требованиям гигабитного интерфейса 88E1111. Так что даже их выполнение работоспособности не гарантирует. Несоответствие есть как по тактовой частоте, так и по setup/hold.

[SM]

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

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

[Bad0512]

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

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

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

[SM]

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

Тогда уж надо редуцировать длину всего пути на целое кол-во периодов по 8 нс - останется 1 нс.

Но я имел в виду не это, что именно констрейны при этом не выдержать, формально то можно, а то, что такой latency скорее всего приведет к каким нибудь неприятностям, связанным с невозможностью вовремя взвести какой либо сигнал, по причине задержки более, чем на 1 такт. То есть, немного некорректно высказался.

[AndreiUS]

Все зависит от 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нс, чего вполне достаточно для корректного приема.

[Tolas]

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).
Если я правильно понимаю, это клоковые пины, но так как я новичок , я могу ошибаться, поправьте меня пожалуйста, если это не так.
Такое ощущение, что проблема во внутренних сигналах TX_CLKG и RX_CLKG. Может их надо как-то "по особому" определить?
2) Очень может быть, что здесь "кривое использование DCM", так как я не знаю что это. Может направите где узнать об этом можно?

[Bad0512]

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

1. У 6 Спартана есть одна странная особенность. У него 24 клоковых буфера на чип. Но из них всего 8 являются полноценно глобальными, остальные 16 - могут напрямую драйвить только половину (левую или правую) чипа.
У вас выбраны клоковые пины, однако оба они могут напрямую драйвить только правую половину чипа. Соответственно если какая-то логика (или пины I/O) расположены в левой половине (это можно поглядеть в XDE или PlanAhead) то путь клока до этих элементов сильно удлиняется. Обо всём этом можно почитать в ug382. Чтобы что-то сказать наверняка надо поглядеть развёрнутый тайминг репорт полностью. Если не затруднит - выложите плиз.
2. Если вы сами не пытались вставлять DCM для компенсации задержки по клоку, то скорее всего в пути клока нет неправильно включенной DCM. О том как использовать DCM также можно почитать в ug382.

[Tolas]

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

[Tolas]

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

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

Еще нашел для tx_en:

Я так понимаю, исходя из этих данных, я должен составить правильные Timing Constraint... Для GTX_CLK period боле-менее понятно, а вот как это соотносится с сигналами данных TXD?..

[Timmy]

Я использую 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). Для этого тоже подойдёт визард, он ещё соотвествующую картинку показывает.

[Tolas]

Разброс между выходным клоком и данными в 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;