Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Mingyuexin
Beginner
655 Views

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

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.

Tags (1)
0 Kudos
40 Replies
KennyT_Intel
Moderator
106 Views

Hi Liu, Since your design download from rocket board, can you post the question there? The answer is yes, whenever there is a quartus change, routing and placement will change and you will have to close the timing again. If rocket board .com cannot help, you will have to attached your design.qar here for us to look into the failure.
Mingyuexin
Beginner
106 Views

Hi, Thank you very much for the reply.

I asked rocketboard, they did not reply at all.

Also I tried version 14.1, 15.0, all of them have timing violation.

My project is attached here, please help me with it. My project is compiled with quartus prime 18.1

KennyT_Intel
Moderator
106 Views

is there any update?
KennyT_Intel
Moderator
106 Views

I look into the design, whenever they are two different clock domain. Timing will be different.

 

Since the violation is not much on those path, what I suggest you try different seeds to see if it can close the timing. As the timing had been close in Q14.0 before. https://fpgawiki.intel.com/uploads/e/e6/FittingAlgorithms_and_SeedSweeps.pdf

Mingyuexin
Beginner
106 Views

Thank you very much for the advice. It seems I have to do seed sweep manually, i.e. set different see value and see which one can close the timing. I have tried several seeds, I have not found any see which can close the timing yet.

Is there any trick to find the right seed faster? For example, do seed sweep automatically?

KennyT_Intel
Moderator
106 Views

If you refer to the document above, you can use dse to do automatically seed. There are no magic seed for it. If you have try about 20seeds and it still failed timing, means we have to look for another way to close the timing.

Mingyuexin
Beginner
106 Views

Thank you very much again.

Yes, I tried 13 seeds already, all of them fails the timing. The timing slack is about between -0.3 to 0.4 ns, I do not think seed selection can solve this problem, any other way we can use to solve this timing issue?

 

Thank you in advance!

KennyT_Intel
Moderator
106 Views

Further check, the rgmii interface constrain that use for old version of Quartus might be incorrect. You will have to look for the constrain again with the latest release Q18.0. Our suggestion is look into the https://fpgacloud.intel.com/devstore/platform/?search=triple&acds_version=any&family=cyclone-10-lp for referrence. After you have modify the *sdc files, you can send again the design.qar if the timing still failed.
Mingyuexin
Beginner
106 Views

Hi,

I took this https://fpgacloud.intel.com/devstore/platform/?search=triple&acds_version=any&family=cyclone-10-lp for referrence, this time, not only setup time has violation, but also hold time.

See the attached project.

KennyT_Intel
Moderator
106 Views

Thanks, I see that your timing violation now are minimal. The slack now are quite low and some of the similar path are passing the timing but some of it not for hold and setup. I am using latest release Quartus 18.1.1 with all the upgrade done.

 

What you can do is:

 

1) overconstrain the design base on https://fpgawiki.intel.com/wiki/Timing_Constraints

2) change some of the pin location assignment, I would suggest you let it float if possible.

 

Thanks

Mingyuexin
Beginner
106 Views

Hi,

Thank you very much for the quick response.

The setup violation for slow 1100 mV 0C Model is about -0.241 ns, is it what you get when you use the latest version 18.1.1?

When you say let the pin float, do you mean let rgmii pin float?

 

Thank you in advance!

Best regards

Jasmine

Mingyuexin
Beginner
106 Views

Hi,

I removed pin assignment for gmii interfaces, the timing was not improved, I checked the pins were assigned by Quartus to a different locations.

I then assigned gmii interfaces to other locations, I got those timing violations:

Slow 1100 mV 85 C model

-0.024 ns setup

-0.014 ns hold

Slow 1100 mV 0 C model

-0.062 ns setup

-0.057 ns hold

Looks like the timing improved a little bit after I change the pin location manually.

 

Well, since there are setup timing violation for all the tx pins, and hold timing violation for part of tx pins, I do not know where the over constraint should be set. Because the same path (e.g. from clock_ena to tx_d) is too long for setup analysis, but short for hold analysis.

 

I'm trying seed sweep (20 seeds), I will update the result when it's done.

Best wishes

Jasmine

Mingyuexin
Beginner
106 Views

Seed sweep does not help at all, all 20 seeds failed.

KennyT_Intel
Moderator
106 Views

Yes, I get the same violation slack that you have. Yes, try to pin float the rgmii related pin and the clock.

KennyT_Intel
Moderator
106 Views

Can you attached your latest timing report to have a look?

Mingyuexin
Beginner
106 Views

Hi,

The timing violation path is attached.

 

Best wishes

Jasmine

Mingyuexin
Beginner
106 Views

I attach the design with new pins assignment here also

KennyT_Intel
Moderator
106 Views

I see your report. This is a small delay happened from register to IO. Now u can try tune the d5 of d4 delay to close the remaining timing. D5 or d4 delay is shown in the IO, try to search it in the chip planner -> look into the specific IO -> resource property -> in the resource property editor -> right click on the triangle sign and see if you can modify the timing. Or you can just play around the value in the assignment editor.
KennyT_Intel
Moderator
106 Views

After the timing closed, you can attached your design for me to review it. Thanks
Mingyuexin
Beginner
82 Views

Hi,

It's hard to close the timing by adjust D5. Because there is both setup and hold timing violations. And the timing violation happens not only on one tx channel, but on almost all the tx channels.

 

See one of the path, in the attachment, the setup timing is fine, but hold timing fails.

 

The main problem I think is the path between CLKCTRL_G8 to *DDIO_outa[*]|muxsel.

As you can see, for setup timing, the delay on this path for data arrival path is 2.921, for data required path is 2.250, the difference is 0.671

for hold timing, the delay on this path for data arrival path is 2.244, for data required path is 2.929, the difference is 0.685.

The difference is too big.

 

Is there any way to reduce this difference?

 

With best wishes

Jasmine

 

Reply