FPGA, SoC, And CPLD Boards And Kits
FPGA Evaluation and Development Kits
5892 Discussions

Timing violation when route emac from HPS to FPGA in quartus prime standard 18.1

Mingyuexin
Beginner
3,388 Views

Hi,

I need to use route EMAC from HPS to FPGA because our system need 4 channels of ethernets, and one USB interface also.

I refer to the examples from here https://rocketboards.org/foswiki/Projects/CycloneVRGMIIExampleDesign

which uses RGMII interface for PHY.

I followed the important notes stated there:

  1. use an ini file which has contents "b2t_enable_hps_emac_internal_clock_arcs = on" to enable the internal timing path from HPS clock mux.

  2. I removed the content cv_soc_rgmii_5csxfc6_hps_0_fpga_interfaces.sdc

 

 There is timing violation after compilation and fitting.

 The violation is from cv_soc_rgmii_5csxfc6:soc_0|cv_soc_rgmii_5csxfc6_hps_0:hps_0|cv_soc_rgmii_5csxfc6_hps_0_fpga_interfaces:fpga_interfaces|peripheral_emac0~internal_clock

 to phy_rgmii_rgmii_txd[0]. I.e. from the data clock (TX_SRC_CLK_125) to output clock (TX_CLK_OUT_125) of RGMII interface.

 

 The timing constraint in soc_system_timing_sdc file related to those two clocks are as follows:

 create_clock -name TX_SRC_CLK_125 -period "125 MHz" [get_keepers {soc_0|hps_0|fpga_interfaces|peripheral_emac0~internal_clock}] -add

 

 create_generated_clock -name TX_CLK_OUT_125 \

-source [get_pins {ddio_out_1|ALTDDIO_OUT_component|auto_generated|ddio_outa[0]|muxsel}] \

-master_clock TX_SRC_CLK_125 [get_ports phy_rgmii_rgmii_tx_clk] -add

 

#**************************************************************

# Input delay and output delay to each IO pins

### TX path output delay ###

set_output_delay -clock TX_CLK_OUT_125 -min -2.95 \

[get_ports "phy_rgmii_rgmii_txd* phy_rgmii_rgmii_tx_ctl"] -add_delay

set_output_delay -clock TX_CLK_OUT_125 -max -0.85 \

[get_ports "phy_rgmii_rgmii_txd* phy_rgmii_rgmii_tx_ctl"] -add_delay

set_output_delay -clock TX_CLK_OUT_125 -min -2.95 \

[get_ports "phy_rgmii_rgmii_txd* phy_rgmii_rgmii_tx_ctl"] -clock_fall -add_delay

set_output_delay -clock TX_CLK_OUT_125 -max -0.85 \

[get_ports "phy_rgmii_rgmii_txd* phy_rgmii_rgmii_tx_ctl"] -clock_fall -add_delay

 

#**************************************************************

# Multi-cycles & False paths

#**************************************************************

### to align the launch edge with the latch edge ###

set_multicycle_path 0 -setup -end -rise_from [get_clocks "TX_SRC_CLK_125 TX_SRC_CLK_25 TX_SRC_CLK_2_5"] -rise_to [get_clocks "TX_CLK_OUT_125 TX_CLK_OUT_25 TX_CLK_OUT_2_5"]

set_multicycle_path 0 -setup -end -fall_from [get_clocks "TX_SRC_CLK_125 TX_SRC_CLK_25 TX_SRC_CLK_2_5"] -fall_to [get_clocks "TX_CLK_OUT_125 TX_CLK_OUT_25 TX_CLK_OUT_2_5"]

 

### false path for different edge between lauch and latch clocks ###

set_false_path -fall_from [get_clocks "TX_SRC_CLK_125 TX_SRC_CLK_25 TX_SRC_CLK_2_5"] \

-rise_to [get_clocks "TX_CLK_OUT_125 TX_CLK_OUT_25 TX_CLK_OUT_2_5"] -setup

set_false_path -rise_from [get_clocks "TX_SRC_CLK_125 TX_SRC_CLK_25 TX_SRC_CLK_2_5"] \

-fall_to [get_clocks "TX_CLK_OUT_125 TX_CLK_OUT_25 TX_CLK_OUT_2_5"] -setup

set_false_path -fall_from [get_clocks "TX_SRC_CLK_125 TX_SRC_CLK_25 TX_SRC_CLK_2_5"] \

-fall_to [get_clocks "TX_CLK_OUT_125 TX_CLK_OUT_25 TX_CLK_OUT_2_5"] -hold

set_false_path -rise_from [get_clocks "TX_SRC_CLK_125 TX_SRC_CLK_25 TX_SRC_CLK_2_5"] \

-rise_to [get_clocks "TX_CLK_OUT_125 TX_CLK_OUT_25 TX_CLK_OUT_2_5"] -hold

 

I believe the timing constraint is fine. The example used Quartus 14.0.2, but I used Quartus 18.1 to compile. Is the Quartus software cause this timing violation, how I can solve this problem?

 

By the way, I also tried the example in AN706, which route emac from hps to fpga but uses GMII interface instead. There is also timing violation from data clock (emac0_tx_clk) to output clock (enet1_tx_clk). Again, in AN706, the design was based on quartus prime standard version 14.0, but I use 18.1.

 

Does anybody know how to fix this, any reply is appreciated.

0 Kudos
40 Replies
Mingyuexin
Beginner
1,227 Views

The project is attached here.

0 Kudos
Kenny_Tan
Moderator
1,227 Views

Thanks for your attachment, I review your sdc files,

 

#create_generated_clock -name TX_CLK_OUT_2_5 \

#-source [get_pins {ddio_out_1|ALTDDIO_OUT_component|auto_generated|ddio_outa[0]|muxsel}] \

#-master_clock TX_SRC_CLK_2_5 [get_ports phy_rgmii_rgmii_tx_clk] -add

 

I can't to see this output pin -source [get_pins {ddio_out_1|ALTDDIO_OUT_component|auto_generated|ddio_outa[0]|muxsel}] \ in the rtl viewer. This should be a mux, the pin i found is

-source [get_pins {soc_0|gmii_to_rgmii_adapter_0|u_altera_gmii_to_rgmii_adapter_core|u_mac_tx_clock_input_mux|outclk|combout}] \

 

I see there are tans of ignore constrain in your design, you need to fix all the timing warning to make sure that there are no warning messages. As currently, the timing report does not seems make sense to me, it is failing from clock to data with reference with cross clock. Usually, the from node should be a data instead of a clock.

 

You can reattached the design after you fix all the ignored warning. Thanks

 

 

0 Kudos
Mingyuexin
Beginner
1,227 Views

Hi,

Thank you very much for the advise.

get_pins {ddio_out_1|ALTDDIO_OUT_component|auto_generated|ddio_outa[0]|muxsel is an input pin of ddio_outa.

See the rtl view snapshot below:

I have removed all the warnings, see the project as attached now.

With best wishes

Jasmine

 

0 Kudos
Kenny_Tan
Moderator
1,227 Views

can u attached your screenshot? the problem is that I don't see this clock TX_CLK_OUT_2_5 being shown in the timing report

 

U can check all the sdc written session

 

0 Kudos
Mingyuexin
Beginner
1,227 Views

Hi,

See the attachment, TX_CLK_OUT_2_5 is at item 35.

 

With best wishes

Jasmine

 

0 Kudos
Mingyuexin
Beginner
1,227 Views

This is the snapshot that is missing in the previous reply.

With best wishes

Jasmine

0 Kudos
Kenny_Tan
Moderator
1,227 Views

Hi,

 

What I means is your rtl view snapshot, you mention above but you did not attached it.

 

Thanks

0 Kudos
Kenny_Tan
Moderator
1,227 Views
Not sure if u have update on the rtl view?
0 Kudos
Kenny_Tan
Moderator
1,227 Views
Looking into the timing violation cv_soc_rgmii_5csxfc6:soc_0|cv_soc_rgmii_5csxfc6_hps_0:hps_0|cv_soc_rgmii_5csxfc6_hps_0_fpga_interfaces:fpga_interfaces|peripheral_emac0~internal_clock phy_rgmii_rgmii_txd[1] TX_SRC_CLK_125 TX_CLK_OUT_125 Will there be a data transfer from this internal_clock to the phy? If no, you can false path it.
0 Kudos
Kenny_Tan
Moderator
1,227 Views
Any chance if you have check the path as mention above?
0 Kudos
Mingyuexin
Beginner
1,227 Views

Sorry I replied so late.

There is data transfer from internal_clock to phy.

With best wishes

Jasmine​

0 Kudos
Kenny_Tan
Moderator
1,227 Views

Then you just overconstrain that path specifically.

0 Kudos
Mingyuexin
Beginner
1,227 Views

As I said, this path has both setup violation and hold violation. Please advice me how to over constrain this path. I attached the detail of this path. I referred to http://www.rkra.de/quartus/Timequest/Timing%20Constraints%20-%20Altera%20Wiki.html for over constrain advice, as I know, over constrain works for small setup violation, and there is long distance between two registers. But in my case, I do not see two registers.

With best wishes

Jasmine

0 Kudos
Kenny_Tan
Moderator
1,227 Views

This cv_soc_rgmii_5csxfc6:soc_0|cv_soc_rgmii_5csxfc6_hps_0:hps_0|cv_soc_rgmii_5csxfc6_hps_0_fpga_interfaces:fpga_interfaces|peripheral_emac0~internal_clock

 

should not be a data path. it is a clock path. If it is not a clock, you will not set this in your sdc files:

 

### RGMII TX clock 125/25/2.5MHz ###

create_clock -name TX_SRC_CLK_125 -period "125 MHz" [get_keepers {soc_0|hps_0|fpga_interfaces|peripheral_emac0~internal_clock}] -add

create_clock -name TX_SRC_CLK_25 -period "25 MHz" [get_keepers {soc_0|hps_0|fpga_interfaces|peripheral_emac0~internal_clock}] -add

create_clock -name TX_SRC_CLK_2_5 -period "2.5 MHz" [get_keepers {soc_0|hps_0|fpga_interfaces|peripheral_emac0~internal_clock}] -add

 

Theoretically, we analyze from node to to node with a data path, the launch and latch is for the clock path. I would suggest you false path this. Thanks

0 Kudos
Mingyuexin
Beginner
1,227 Views

Hi,

Thank you very much for the reply.

I set false paths to all the paths from cv_soc_rgmii_5csxfc6:soc_0|cv_soc_rgmii_5csxfc6_hps_0:hps_0|cv_soc_rgmii_5csxfc6_hps_0_fpga_interfaces:fpga_interfaces|peripheral_emac0~internal_clock

to phy_rgmii_rgmii_txd[*]

Then I notice there is no path analyzed from TX_SRC_CLK_125 to TX_OUT_CLK_125.

Then what is the point to set output delay like this:

set_output_delay -clock TX_CLK_OUT_125 -max $output_max_delay [get_ports "phy_rgmii_rgmii_txd* phy_rgmii_rgmii_tx_ctl"]

Because the output delay is set and supposed to be analyzed from TX_SRC_CLK_125 to TX_OUT_CLK_125 (according to AN433 and AN477).

I attached the new design here after I set the false paths.

 

 

 

 

 

0 Kudos
Kenny_Tan
Moderator
1,227 Views

Let me look into the document whether it make sense for your case. Will get back to you on this.

0 Kudos
Kenny_Tan
Moderator
1,227 Views

Hi Lijiao,

 

I almost forgot, those are ddio path. Only ddio path are entitied to have generated_clock to data in the timing analyzer.

 

With that said, you have the correct constrain. However, your design are failling at setup and hold at the same time. There are no way to close timing having it fail at the same time, this means that base on your requirement, it cannot run so fast on that pin. You may have to tune the output_delay value or reduce the frequency if necessary.

 

If you failed only on one of the edges, you can tune the D1 to D5 delay on the pin. That is also you have to see whether pin IO standard can run so fast or not.

 

Since the original design is created by rocket board, they have not close the timing as you mention the design originally run on Q14.0 and Q14.1 and the timing not close.

0 Kudos
Mingyuexin
Beginner
1,227 Views

Hi,

Thank you very much for the detailed answer.

I will have a look and see what I can do to make it work, otherwize I have to give up the idea of routing the EMAC to FPGA and output via RGMII interface.

 

With best wishes

Jasmine

0 Kudos
Kenny_Tan
Moderator
1,227 Views

I just found this document. https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/arria-10/a10_handbook.pdf

page 183 although this is A10, It should be apply to all device.

 

Basically, it mention that you need a different IO standards if your frequencies running too high.

0 Kudos
Mingyuexin
Beginner
1,164 Views

Hi,

Thank you very much for the answer again.

The RGMII runs at 125 MHz, it's not very high speed.

I have given up to implement RGMII in this design now.

Anyway, thank you very much for the information.

 

With best wishes

Jasmine

 

0 Kudos
Reply