Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
Announcements
All support for Intel NUC 7 - 13 systems has transitioned to ASUS. Read latest update.
20577 Discussions

TSE Timing constraints

jayrflare
Beginner
548 Views

I have a couple questions regarding the timing constraints of the Triple Speed Ethernet IP Core.

Background:

Quartus II 11.1

20 mhz clk input pin sources to PLL 

PLL1 sources: 125 mhz clk 90 deg phase shifted (rgmii_tx_clk) - RGMII clk to the phy , phase shifted

          sources: 125 mhz clk 0 deg phase shifted (tx_data_clk) - clk for RGMII TX data registers

          sources: 100 mhz clk 0 deg phase shifted (clk) - clk for FIFO (AST) and clk for core config

Clks were chosen based on reocmmendations for 32 mb fifo variant and 1gb

 

 

I am using 1gb Small MAC variant of the IP core.

Since im using PLL to source the clks, the SDC files generated by the core were giving me trouble since those files expect clks to be at the top level not from pll . 

For the small MAC variant, these constraints simply constrain the declared clocks and set asynchronous groups between each. Is this correct?

I added all my constraints to the top level and added RGMII constraints according to AN477

and added asynchronous clock groups separating rgmii_tx clk + tx_data clk from clk.

 

Is it safe to assume that rgmii_tx_clk and tx_data_clk are asynchronous from clk?

Timing report shows violations due to the 100 mhz to 125 mhz relationship. I assume there are internal CDCs to handle the variance between core clk and rgmii clks. Would setting asynchronous clock groups / or false paths between the different domains affect these synchronizers? 

 

Thanks

 

 

                

0 Kudos
7 Replies
IntelSupport
Community Manager
515 Views

Hi Justin,


Let me check this internally and get back to you with update.


0 Kudos
IntelSupport
Community Manager
479 Views

Hi jayrflare,


rgmii_tx_clk and tx_data_clk are asynchronous from clk?

- In this scenario, where the clocks are derived from the same source, static timing analysis is possible and safe to assume it is asynchronous. You may see below KDB on CDC constrain.

https://www.intel.com/content/www/us/en/support/programmable/articles/000080400.html


0 Kudos
IntelSupport
Community Manager
445 Views

May I know if there is any update?


0 Kudos
jayrflare
Beginner
429 Views

Hi,

 

Thank you for the response.

So within the Intel TSE IP, tx_data_clock, and rgmii_tx  clks ARE asynchronous from clk. So my assumption is correct that it is okay to use clock groups to separate them. 

 

Are there any other timing constraints that the Intel TSE needs aside from setting clock groups, and constraining each clk on the top level?

 

How would i handle these constraints according to the article when i dont know what registers are being used for clock crossing within the intel TSE IP?

I am unsure what i would put as data_a and data_b 

jayrflare_0-1678146767553.png

So for my example, what registers would need to have a net delay and max skew constraint when considering the tx_data_clock to clk relationship where:

Tx_data_clock is 125 mhz nonshifted clock sourcing the RGMII TX data registers

Clk is 100 mhz clk sourcing TSE control and Avalon ST fifo registers

 

Thanks

 

0 Kudos
IntelSupport
Community Manager
409 Views

Hi Justin,


Just to confirm Firstly, Is the CDC occur within TSE IP?

Also. can you migrate to latest version if possible? 11.1 is quite old and might be hard to support.


0 Kudos
jayrflare
Beginner
356 Views

Hi, that is the question i have here. My assumption is that streaming clocks and core clock are asynchronous to the RGMII Tx clocks WITHIN the TSE IP. I do cannot confirm since I cannot see logic within the IP.

 

I cannot migrate to newer version due to current licensing (safety package).  Regardless, i believe the implementation of the CDC will be the same throughout all versions of TSE IP. 

0 Kudos
IntelSupport
Community Manager
394 Views

May I know if there is any update ?

Did you able to work on this?


0 Kudos
Reply