Question about Verilog Semantics / Xilinx Synthesis of embedded EMAC

Hi,

yesterday I solved a problem while integrating the embedded TEMAC of an V4FX60 with an RGMII PHY after some try and error. The solution works, but I wonder why it didn't before. Ah, I'm using ISE 8.1i for synthesis (and using EDK for the build process..).

That's what happened: At first I used coregen to generate a template of an embedded EMAC with RGMII connection in Verilog and integrated it in my design. Only receiving worked, sending resulted in frames with bad fcs at the receiver. I studied afterwards the EDK implementation of the hard_temac core (because this example works). Now I have the following situation:

I/O-Signals are defined as: output [3:0] RGMII_TXD_RISING_0; output [3:0] RGMII_TXD_FALLING_0; output RGMII_TX_CTL_RISING_0; output RGMII_TX_CTL_FALLING_0; input [3:0] RGMII_RXD_RISING_0; input [3:0] RGMII_RXD_FALLING_0; input RGMII_RX_CTL_RISING_0; input RGMII_RX_CTL_FALLING_0;

The following code snippet works:

wire [7:0] rgmii_rxd; wire [7:0] rgmii_txd;

assign rgmii_rxd = {RGMII_RXD_FALLING_0, RGMII_RXD_RISING_0}; assign RGMII_TXD_FALLING_0 = rgmii_txd[7:4]; assign RGMII_TXD_RISING_0 = rgmii_txd[3:0];

EMAC v4_emac ( ... .PHYEMAC0RXCLK (RGMII_RXC_0), .PHYEMAC0RXD (rgmii_rxd), .PHYEMAC0RXDV (RGMII_RX_CTL_RISING_0), .PHYEMAC0RXER (RGMII_RX_CTL_FALLING_0), .PHYEMAC0MIITXCLK (), .EMAC0PHYTXCLK (), .EMAC0PHYTXD (rgmii_txd), .EMAC0PHYTXEN (RGMII_TX_CTL_RISING_0), .EMAC0PHYTXER (RGMII_TX_CTL_FALLING_0), .PHYEMAC0COL (1'b0), .PHYEMAC0CRS (1'b0), ... );

The following code can only receive data, but sending doesn't work:

EMAC v4_emac ( ... .PHYEMAC0RXCLK (RGMII_RXC_0), .PHYEMAC0RXD ({RGMII_RXD_FALLING_0, RGMII_RXD_RISING_0}), .PHYEMAC0RXDV (RGMII_RX_CTL_RISING_0), .PHYEMAC0RXER (RGMII_RX_CTL_FALLING_0), .PHYEMAC0MIITXCLK (), .EMAC0PHYTXCLK (), .EMAC0PHYTXD ({RGMII_TXD_FALLING_0, RGMII_TXD_RISING_0}), .EMAC0PHYTXEN (RGMII_TX_CTL_RISING_0), .EMAC0PHYTXER (RGMII_TX_CTL_FALLING_0), .PHYEMAC0COL (1'b0), .PHYEMAC0CRS (1'b0), ... );

Interestingly receiving works in both cases. In my naive thinking I would believe that both snippets are semantically identical. So where did I make an error? Are there some optimizations which changed the behaviour?

Thanks, Christian.

Reply to
cpmetz
Loading thread data ...

The two snippets are essentially equivalent. My first guess would be that your project is not adequately constrained to meet timing requirements of transmit. It is possible that you get a better fit by renaming the two

4-bit pieces into an 8-bit bus, due to the mapping feature of "register ordering", which tries to find bus structures by name and place them in adjacent logic elements.

HTH, Gabor

Reply to
Gabor

Hi,

thanks for your answer. Now it makes some sense :-) At first I thought that this should be fully synchronous and thus covered by the timing analysis, since the *_FALLING and *_RISING signals are fed through DDR-flipflops to outputs. But I looked in my UCF and there it is needed to place following timing (or: non-timing) constraints in it:

NET *rgmii_txd_falling_?_i TIG; NET *rgmii_tx_ctl_falling_?_i TIG;

Without them the design fails to meet timing and so I copied them without much thinking from the examples. Is there the possibility to form a bus in the UCF?

Thanks, Christian.

Reply to
cpmetz

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.