Trouble with EMAC on CycloneV SoC

[Altera_Forum]

Hello. 

 We use 5CSEBA4U19I7 chip in our devices. And we have a trouble with EMAC.  "EMAC0 pin" in Qsys is configured as "FPGA" mode.  GMII signals of HPS instance (emac0_phy_txd_o and emac0_phy_txen_o) latch into the registers, triggered by the emac0_phy_txclk_o: logic emac0_tx_d; logic emac0_tx_en; logic emac0_tx_d_d1; logic emac0_tx_en_d1; always_ff @(posedge emac_gtx_clk) begin emac0_tx_d_d1 <= emac0_tx_d; emac0_tx_en_d1 <= emac0_tx_en; end soc_hps_0# ( .F2S_Width (0), .S2F_Width (1) ) hps_0 ( ... .emac0_phy_txd_o (emac0_tx_d), .emac0_phy_txen_o (emac0_tx_en), .emac0_phy_txclk_o (emac_gtx_clk), ... );  According to the test results (as well as in SignalTap)  it is seen that the data in emac0_tx_d_d1 contains bit errors.  It is look like timing violation. But Timequest doesn't see any path from HPS to registers and doesn't analyze them.  I want used data from HPS EMAC (Tx GMII) into FPGA application logic. How can I get data from HPS EMAC without bit errors?  If anyone has any idea, please tell me. Thanks in advance.

[Altera_Forum]

I believe this has been addressed in Quartus 14.0 

 By the way in case you haven't seen this you might find this design example handy: http://rocketboards.org/foswiki/projects/cyclonevrgmiiexampledesign

[Altera_Forum]

Timequest reports the timing path based on your timing constraint. 

In 14.0, there is a fix in this timing path from HPS EMAC to FPGA region but the SDC is yet to be updated.  During GMII mode, the clock is source from EMAC Clk Manager to PHY. You should take note on your timing constraint, the clock node should be source from internal node as below:  soc_system_hps_0_fpga_interfaces.sdc  create_clock -name <clock_name> -period <clock_period> [get_keepers {*|fpga_interfaces|peripheral_emac0~internal_clock}] -add <clock _period> refer to tx clock rate of GMII interface.   old timing constraint to be removed: create_clock -period <clock_period> [get_pins -compatibility_mode *|fpga_interfaces|peripheral_emac0|phy_txclk_o]

[Altera_Forum]

--- Quote Start ---  Timequest reports the timing path based on your timing constraint. In 14.0, there is a fix in this timing path from HPS EMAC to FPGA region but the SDC is yet to be updated.  During GMII mode, the clock is source from EMAC Clk Manager to PHY. You should take note on your timing constraint, the clock node should be source from internal node as below:  soc_system_hps_0_fpga_interfaces.sdc  create_clock -name <clock_name> -period <clock_period> [get_keepers {*|fpga_interfaces|peripheral_emac0~internal_clock}] -add <clock _period> refer to tx clock rate of GMII interface.   old timing constraint to be removed: create_clock -period <clock_period> [get_pins -compatibility_mode *|fpga_interfaces|peripheral_emac0|phy_txclk_o]  --- Quote End ---    I'm attempting to do this but the constraint is being ignored (~internal_clock could not be matched). Is there a problem with the HPS timing model?

[Altera_Forum]

--- Quote Start ---  I'm attempting to do this but the constraint is being ignored (~internal_clock could not be matched). Is there a problem with the HPS timing model?  --- Quote End ---    The linked example design (Cyclone V RGMII Example Design) contains a very subtle pointer:   --- Quote Start ---    An INI file is required to enable the internal timing path from HPS clock mux.    --- Quote End ---   Unfortunately, this INI file is missing in the design archive.   I think a 'quartus.ini' file in the project directory is meant and its contents should be  b2t_enable_hps_emac_internal_clock_arcs = on  otherwise {*|fpga_interfaces|peripheral_emac0~internal_clock } is not available and any timing constraint based on it will fail.  On a side note: I am using the latest available Quartus version (15.0 update 2).

[Altera_Forum]

--- Quote Start ---  The linked example design (Cyclone V RGMII Example Design) contains a very subtle pointer:  Unfortunately, this INI file is missing in the design archive.   I think a 'quartus.ini' file in the project directory is meant and its contents should be  b2t_enable_hps_emac_internal_clock_arcs = on  otherwise {*|fpga_interfaces|peripheral_emac0~internal_clock } is not available and any timing constraint based on it will fail.  On a side note: I am using the latest available Quartus version (15.0 update 2).  --- Quote End ---    Yup, INI file is required in this case. Just create a quartus.ini with the instances "b2t_enable_hps_emac_internal_clock_arcs = on" in your project directory will do. You can check if the INI is being applied to your project in compilation report (after compiled), somewhere under synthesis, INI report if I remember it correctly.

[Altera_Forum]

--- Quote Start ---  Yup, INI file is required in this case. [..]   --- Quote End ---   Hm okay, thanks. Still strange that the QSYS generated SDC file (*_fpga_interfaces.sdc) creates a clock constraint that depends on an undocumented INI 'hack'. Also there seems to be a lot more needed if one wants to integrate a 10/100/1000Mbit PHY by use of FPGA pins. The SDC file (soc_system_timing.sdc) contained in the SGMII design example ( http://releases.rocketboards.org/release/2014.11/cv-sgmii-ed/hw/cv_soc_sgmii_ed.tar.gz ) seems to be much more comprehensive, but still painful to replicate. Pity QSYS is not (yet) able to take the board and PHY related delay parameters and automatically generate the needed timing constraints (as it is e.g. done for DDR RAM).