- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
=== 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.
=== 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.
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?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just to inform that I am checking the design and may need some time.
Regards,
Richard Tan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
![](/skins/images/8B5EA638CA3587CA763EE9EF53643DD4/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page