- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a problem, and it could be described like this:
there is PHY - to FPGA (Cyclone V) RGMII interface, receive side (for FPGA).
Namely I have 125 MHZ, DDR, I use center-aligned mode, I exploit PHY's internal ability to create the delay between clock and data for 90 degrees phase shift. I wrote constraints for the source synchronous, double data rate, center-aligned same edge transfer.
I checked constraints, setup fails
and if I manually decrease D1/D3 delay values timing successfully meets
and hold check also passes with a positive slack. But the question is why Quartus sets D1/D3 too high automatically?
// I have an issue similar to what was mentioned in that post https://forums.intel.com/s/question/0D50P00003yyRgfSAE/altddio-16bitx250mhz-to-32bitx125mhz-proper-timequest-timing-closure
Thank you in advance.
--
Best regards,
Ivan
- Tags:
- timing
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ivan,
These delays chain are part of FPGA I/O architecture and are preconfigured with settings based on the characterization of FPGA devices.
The Quartus II Compiler can program these delays to a value automatically.
Regards
Anand
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Anand.
Thank you for your reply.
Yes, I know that Quartus can program these delays, and it programs them indeed in my project, and I want Quartus to do that automatically following my constraints.
Because I exploit constraints, and also I use DDIO, D1/D3 delay values are the way for Quartus to pass timing.
So my problem is - I wrote constraints like this (as it is in example done by Ryan Scoville in Source Synchronous wiki examples):
create_clock -period 8.0 -name ssync_rx_clk [get_ports ssync_rx_clk] -waveform {2.0 6.0}
create_clock -period 8.0 -name ssync_clk_ext
derive_pll_clocks
derive_clock_uncertainty
set_input_delay -clock ssync_clk_ext -max 0.5 [get_ports {ssync_rx_data[*]}]
set_input_delay -clock ssync_clk_ext -min -0.5 [get_ports {ssync_rx_data[*]}]
set_input_delay -clock ssync_clk_ext -max 0.5 [get_ports {ssync_rx_data[*]}] -clock_fall -add_delay
set_input_delay -clock ssync_clk_ext -min -0.5 [get_ports {ssync_rx_data[*]}] -clock_fall -add_delay
set_false_path -fall_from [get_clocks ssync_clk_ext ] -rise_to [get_clocks inst1|altpll_component|auto_generated|generic_pll1~PLL_OUTPUT_COUNTER|divclk] -setup
set_false_path -rise_from [get_clocks ssync_clk_ext ] -fall_to [get_clocks inst1|altpll_component|auto_generated|generic_pll1~PLL_OUTPUT_COUNTER|divclk] -setup
set_false_path -rise_from [get_clocks ssync_clk_ext ] -rise_to [get_clocks inst1|altpll_component|auto_generated|generic_pll1~PLL_OUTPUT_COUNTER|divclk] -hold
set_false_path -fall_from [get_clocks ssync_clk_ext ] -fall_to [get_clocks inst1|altpll_component|auto_generated|generic_pll1~PLL_OUTPUT_COUNTER|divclk] -hold
I also use a PLL in source synchronous mode.
I checked them, and I received negative setup slacks on input ports as can be seen in my first post, fig 1.
After that, I inspected failed paths, and I realized that Quartus set I/O D1/D3 delays in such way, that timing fails, but then I had manually chosen different values, timing passed.
So, my question is, why Quartus decided to choose "wrong" delay values?
Thank you.
--
Best regards,
Ivan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ivan,
Quartus II software chooses different delay settings based on the timing constraints, it is important that we have tight, complete and accurate timing constraints.
With same constrain try to fix the locations of all the internal registers using location assignments in the Assignment Editor, so the I/O timing paths from internal registers to the output pins are fixed.
Regards
Anand
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Anand.
My internal registers are located in Fast I\O, they are part of TSE IP Core and it puts them into Fast I\O automatically.
So the paths are totally fixed.
I will try to create a simple project and if the problem will still be present I will attach it here.
Thank you.
--
Best regards,
Ivan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Anand.
For now, what have I done.
New simple project with TSE was created, and it works fine, I/O delays are chosen by the software correctly and timing meets with positive slacks on both setup and hold.
It's strange because TSE I/O timing is independent from other design parts - because it is I/O timing.
But in the full version of the project I still observe wrong values, and I noticed an interesting thing - choosing Quartus 16.0, I acquired better performance -
for example RXD1 Slack changed from -0.613 to -0.202. I had compared fitter settings (16.0 vs 17.1) and hadn't found any differences there.
So for now I can say that it looks like the issue which is located deep inside the engine and depends on version of Quartus.
--
Best regards,
Ivan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ivan,
May be due to constraints.
we need to have tight, complete and accurate timing constraints.
Regards
Anand
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Anand.
Finally me and my colleague "successfully" recreated the issue in a simple test project.
The project on its top-level consists of three parts - CLOCK, ETHERNET and a simple DAC part.
CLOCK consists of two PLLs, first PLL is for all clocks used in project, and second is for RX part of ETHERNET only, it receives rx_clock from TSE rx and in Source Synchronous Mode outputs clock for latching the RX data to the appropriate I/Os.
ETHERNET consists of triple speed ethernet core and DDIO for TX clock output.
DAC consists of a very simple bunch of code, and the most interesting thing is that it is clocked by 200 MHz clock by default.
So the issue which I mentioned in the beginning of that post was recreated.
We also found what action should be done for the issue to disappear - we changed the source clock for DAC part from 200 to 100 MHz and the result is on the picture below:
So the interesting part of an issue is that there is another block whose source clock comes from another PLL has an impact on timing (in particular the I/O internal delay values). As I previously mentioned we can correct I/O internal delay values manually and obtain the correct timing.
I attached the project.
--
Best regards,
Ivan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ivan,
Thanks for the project, Let me check and come back.
Regards
Anand
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Anand!
Ok, thank you very much.
--
Best regards,
Ivan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi ivan,
- Although the Quartus II software configures the delay elements settings automatically. After you have compiled your design, design may/may not meet timing requirements in design, But might still want to skew or deskew some I/O signals in FPGA using delay element.
- The Intel Quartus®Prime software does not automatically set delay elements to maximize slack in the I/O timing analysis. To close the timing or maximize slack, set the delay elements manually in the Intel Quartus Prime settings file (.qsf). set_intance_assignment –to <PIN> -name <INPUT/OUTPUT/OE>_DELAY_CHAIN <0..63>
- If you have compiled design and face timing problems that can be mitigated by setting delay elements manually.
So in example you have shared we have to manually change the delay chain value to constrain the path.
Regards
Anand
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Anand!
Thank you for your answer.
In my second post I wrote that I can manually set the delays in order to meet timing.
So the question was what is the reason for Quartus engine not to choose delay settings in order to meet timing.
It is strange, isn't it, that Quartus sets the delays so timing fails, but you can manually choose the right values for timing to pass.
And the main part of question was - Quartus almost always chooses right values, except in the project I attached.
The small changes in the project, as I mentioned, lead to right values in delays which Quartus choose.
I thought that maybe it is a bug and our project could be helpful for the team to fix it.
It is strange and probably a bit useless if need to check correctness every time and manually set delays.
In our test project case we can show that Quartus automatically chooses delays which lead to perfect slacks in both setup and hold.
So it is arguably that Quartus chooses delay values and as you said "does not automatically set delay elements to maximize slack".
And I also asked for the root cause of the problem.
--
Best regards,
Ivan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ivan,
That's how tool behaves.
Design may/may not meet timing requirements. We have to set it manually.
Regards
Anand
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Anand!
Sorry for my persistence, but if it is like you said, what is the driving signal for the engine to automatically set I/O delay elements values?
I mean, the engine should be guided by something, so why not to be guided by a positive slack as an aim?
Because it explicitly does not set them randomly, as we demonstrated the timing results are quite stable.
--
Best regards,
Ivan

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page