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-closureThank you in advance.--Best regards,Ivan

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.RegardsAnand

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_clocksderive_clock_uncertaintyset_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_delayset_input_delay -clock ssync_clk_ext -min -0.5 [get_ports {ssync_rx_data[*]}] -clock_fall -add_delayset_false_path -fall_from [get_clocks ssync_clk_ext ] -rise_to [get_clocks inst1|altpll_component|auto_generated|generic_pll1~PLL_OUTPUT_COUNTER|divclk] -setupset_false_path -rise_from [get_clocks ssync_clk_ext ] -fall_to [get_clocks inst1|altpll_component|auto_generated|generic_pll1~PLL_OUTPUT_COUNTER|divclk] -setupset_false_path -rise_from [get_clocks ssync_clk_ext ] -rise_to [get_clocks inst1|altpll_component|auto_generated|generic_pll1~PLL_OUTPUT_COUNTER|divclk] -holdset_false_path -fall_from [get_clocks ssync_clk_ext ] -fall_to [get_clocks inst1|altpll_component|auto_generated|generic_pll1~PLL_OUTPUT_COUNTER|divclk] -holdI 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

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.RegardsAnand

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

Okay, Thanks for update.RegardsAnand

I/O D1/D3 delay values higher than needed.

14 Replies

AnandRaj_S_Intel
Regular Contributor
6 years ago
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
- IDeyn
  Contributor
  6 years ago
  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
AnandRaj_S_Intel
Regular Contributor
6 years ago
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
- IDeyn
  Contributor
  6 years ago
  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
  - AnandRaj_S_Intel
    Regular Contributor
    6 years ago
    Okay, Thanks for update.
    Regards
    Anand
AnandRaj_S_Intel
Regular Contributor
6 years ago
Hi Ivan,
May be due to constraints.
we need to have tight, complete and accurate timing constraints.
Regards
Anand
IDeyn
Contributor
6 years ago
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
TSE_TEST.rar31.3 MB
AnandRaj_S_Intel
Regular Contributor
6 years ago
Hi Ivan,
Thanks for the project, Let me check and come back.
Regards
Anand
- IDeyn
  Contributor
  6 years ago
  Hi Anand!
  Ok, thank you very much.
  --
  Best regards,
  Ivan
  - AnandRaj_S_Intel
    Regular Contributor
    6 years ago
    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
AnandRaj_S_Intel
Regular Contributor
6 years ago
Hi Ivan,
That's how tool behaves.
Design may/may not meet timing requirements. We have to set it manually.
Regards
Anand
- IDeyn
  Contributor
  6 years ago
  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