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

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

MOliv45
Beginner
313 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
6 Replies
RichardTanSY_Intel
254 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
146 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
Valued Contributor III
238 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
146 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
86 Views

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


Regards,

Richard Tan


0 Kudos
MOliv45
Beginner
76 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
Reply