Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
21268 Discussions

How to constrain inter-clock transfers with very low default relationiship (1 ps)?

MOliv45
Beginner
1,743 Views

=== SHORT INTRO ===

Due to some questionable architecture decisions in the past, we ended up with a large circuit implemented in three related clock frequencies using timing division multiplexing. This FPGA firmware is replicated to 116 boards featuring the largest Arria 10 FPGA. This circuit is divided into three parts running at 320 MHz, 240 MHz, and 280 MHz (all multiples of 40 MHz), please see the attached photo of the clock topology.

MOliv45_2-1718242505231.png

=== CLOCK TOPOLOGY ===

A clock buffer drives a 160 MHz clock that feeds an Arria 10 IOPLL that outputs 160, 320, and 1200 MHz. The 320 MHz output is connected to a cascaded IOPLL through the adjpllin reference clock input to generate the 240 MHz clock.  Again, the clock topology is very questionable but I can't change it right now, unfortunately.

 

=== ISSUE ===

There are hundreds of bits crossing between these three regions. Fortunately, we designed these transfers in such a way that the data stays constant for 25 ns before each inter-clock transfer. At the destination, the data are latched at a configurable phase.

 

For example, see the attached picture. The 320 MHz input serial stream (magenta) is deserialized to a 320 MHz parallel word that changes every 25 ns, i.e. every 8 clock cycles (yellow), then it is latched by a register running at 240 MHz (orange). The clock enable of the register indicated in orange is asserted one clock cycle every 25 ns, i.e. one time every 6 clock cycles of 240 MHz. The phase of this periodic clock_enable signal can be selected from the 6 discrete possible values using a multiplexer connected to a shift register holding the 6 different signal phases.

MOliv45_0-1718241392147.png

 

One can notice that despite the fact that source and destination registers are running at 320 MHz and 240 MHz, the data are refreshed every 40 MHz cycles. When one takes into account the fact that the clock enable is asserted periodically only once at 25 ns at both ends, one can consider this transfer very similar to a 40 MHz intra-clock transfer.  However, without a suitable timing constraint, the STA tool is unable to guess this information.

 

=== QUESTIONS ===

 

1) What is the right constraint for this 320-to-240 MHz transfer which both clocks enable are asserted only once every 40 MHz cycle?

 

2) Currently I am latching the destination register at the middle of the 25 ns window of the source register. Is this the best phase offset for such a transfer?

 

3) By default Quartus considers the default relationship for this transfer to be 0.001 ns, i.e. 1 ps. I don't quite understand how Quartus ended up with this 1 ps default setup relationship. Would you know how to explain this?

MOliv45_1-1718242265126.png

 

 

 

 

 

 

Labels (1)
0 Kudos
17 Replies
RichardTanSY_Intel
1,684 Views

Please allow me some time to look into this.

Is it okay to share the design so that I can investigate it further?

 

Is it possible to make any design changes? It seems that it is not possible based on your short intro.

 

Regards,

Richard Tan

 

0 Kudos
MOliv45
Beginner
1,576 Views

Hi Richard,

Yes sure, please find the archived design at https://cernbox.cern.ch/s/scVyb1GatL2mxzr

 

It is possible to implement changes if they are well justified.

 

Thanks in advance Richard and have a nice weekend.

 

Marcos

0 Kudos
FvM
Honored Contributor II
1,668 Views

Hi,

you have 14 ns between launch and latch clock, ages for a simple register-to-register transfer.

I don't recognize at first sight how to constrain the transfer intelligently. In case of doubt specify asynchronous domains and a delay statement.

0 Kudos
MOliv45
Beginner
1,576 Views

Hi @FvM,

 

Exactly, the slack is very large, but indeed I don't know yet the recommended way to constrain such path. Also it is confusing the default setup relationship being 1 ps. 

 

 

0 Kudos
RichardTanSY_Intel
1,516 Views

Just to inform that I am checking the design and may need some time. 


Regards,

Richard Tan


0 Kudos
MOliv45
Beginner
1,506 Views

Thanks @RichardTanSY_Intel. I understand you downloaded the files already so I will disable the folder sharing.

 

Thanks one more time for looking into it.

 

Marcos

0 Kudos
RichardTanSY_Intel
1,396 Views

Sorry for the delay in response. I was busy for the past weeks.

1. For 320-to-240 MHz Transfer, given that the data is stable for 25 ns and the clock enables are asserted once every 25 ns, you can use a set_multicycle_path constraint to tell Timing Analyzer the correct relationship between the source and destination. 

Example

set_multicycle_path -from [get_ports {source_ports}] -to [get_ports {destination_ports}] -setup 8 -end

set_multicycle_path -from [get_ports {source_ports}] -to [get_ports {destination_ports}] -hold 7 -end

The setup requirement spans 8 cycles of the 320 MHz clock (25 ns), giving the data sufficient time to stabilize. Similarly, the hold time spans 7 cycles of the 320 MHz clock (21.875 ns), ensuring data remains stable post-capture.


2. Yes, I believe latching the destination register in the middle of the source register's 25 ns window is generally a good strategy because it maximizes the setup and hold times, providing the most timing margin. This means you are latching the data around 12.5 ns from when it becomes valid. Given that 240 MHz has a period of ~4.167 ns, a good phase offset is around 12.5 ns. You might need to select the phase offset such that the clock enable occurs at ~12.5 ns from the start of the data window.


3. My guess is that Quartus may consider the default relationship of 1 ps due to the lack of constraints for the multicycle paths. It seems to indicate an immediate transfer without considering the multicycle nature. Add the set_multicyle_paths so that Quartus understand the actual timing requirements.


P.S. I apologize, but your design is somewhat difficult for me to understand, so I cannot determine which clocks you are referring to.


Regards,

Richard Tan


0 Kudos
melissa-aguiar
Beginner
1,346 Views

Hello Richard,

 

Thanks a lot for your feedback, it is very helpful.

 

We are applying your suggestions and I would like to double check one detail about the multicycle path. For our case, wouldn't it be more appropriate to use setup/hold as 8/7 with -start or as 6/5 with -end?

 

Kind regards,

Melissa

0 Kudos
RichardTanSY_Intel
1,287 Views

You are right; I think it is more appropriate to use -start, in which the multicycle value is relative to the source clock waveform.

Thank you for asking.


Regards,

Richard Tan


0 Kudos
RichardTanSY_Intel
1,270 Views

Hi,

Do you have further inquiries regarding this case?


Regards,

Richard Tan


0 Kudos
melissa_aguiar
Beginner
1,257 Views

Hi Richard,

 

Thanks for your reply. We are testing a new clock tree and we will come back as soon as we have any news on this topic.

 

Cheers,

Melissa

0 Kudos
RichardTanSY_Intel
1,253 Views

Noted. Will this process take some time?


If so, I will transition this thread to community support, meaning it will not be attended by an Altera agent, as we do not want the case to idle for too long.


Rest assured, if you need further assistance, you can always file a new case, and we'll be ready to provide support promptly.

Thank you for your understanding.


Regards,

Richard Tan


0 Kudos
melissa_aguiar
Beginner
1,202 Views

Hello Richard,

 

We tested your suggestion to add multicycle path for our project with the current clock tree.

 

For the data transfer between the clocks 320 and 240 MHz:

- Using setup -start 8 and hold -start 7, we have hold violations.

- The timing violations disappear when we use the same value for setup and hold, for example setup -start 8 and hold -start 8. It also works for the pairs setup/hold 3/3, 4/4, 5/5, 6/6, 7/7.

 

For the data transfer between the clocks 240 and 280 MHz:

- We have hold violations using setup -start 6 and hold -start 5.

- The timing violations still exist when using the same value for setup and hold.

- The timing violations disappear when we use a value for hold greater than the setup value, for example setup -start 5 and hold -start 6. it also work for the pairs setup/hold 3/4, 4/5.

 

Does it make sense to use a value for hold equal or greater than the setup value in our case? For me it's clear how the setup work, but I don't understand well the values to use for hold.

 

Kind regards,

Melissa

0 Kudos
RichardTanSY_Intel
1,117 Views

No, it does not make sense to me.

The hold value should not be equal or more than the setup value.

Even though there is no timing violation, I worry that the timing analysis might not be invalid or incorrect.

Check the "Timing Analyzer' > 'Waveform' and check whether the launch and latch clock relationship is correct.


Regards,

Richard Tan 


0 Kudos
RichardTanSY_Intel
1,084 Views

Hi,


Any update on this?


Regards,

Richard Tan


0 Kudos
RichardTanSY_Intel
1,028 Views

We noticed that we haven't received a response from you regarding the latest previous question/reply/answer, and will now transitioning your inquiry to our community support. We apologize for any inconvenience this may cause and we appreciate your understanding.

 

If you have any further questions or concerns, please don't hesitate to reach out. Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support.

 

The community users will be able to help you on your follow-up questions.

 Thank you for reaching out to us!

 

Best Regards,

Richard Tan


0 Kudos
RichardTanSY_Intel
1,028 Views

We noticed that we haven't received a response from you regarding the latest previous question/reply/answer, and will now transitioning your inquiry to our community support. We apologize for any inconvenience this may cause and we appreciate your understanding.

 

If you have any further questions or concerns, please don't hesitate to reach out. Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support.

 

The community users will be able to help you on your follow-up questions.

 Thank you for reaching out to us!

 

Best Regards,

Richard Tan



0 Kudos
Reply