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

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

IDeyn
New Contributor III
1,121 Views

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

fig_1.jpg

and if I manually decrease D1/D3 delay values timing successfully meets

good_path_RPE.jpg

and hold check also passes with a positive slack. But the question is why Quartus sets D1/D3 too high automatically?

fail_path_RPE.jpg

 

// 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

 

0 Kudos
14 Replies
AnandRaj_S_Intel
Employee
791 Views

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

0 Kudos
IDeyn
New Contributor III
791 Views

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

0 Kudos
AnandRaj_S_Intel
Employee
791 Views

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

0 Kudos
IDeyn
New Contributor III
791 Views

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

 

0 Kudos
AnandRaj_S_Intel
Employee
791 Views

Okay, Thanks for update.

 

Regards

Anand

0 Kudos
IDeyn
New Contributor III
791 Views

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

0 Kudos
AnandRaj_S_Intel
Employee
791 Views

Hi Ivan,

 

May be due to constraints.

we need to have tight, complete and accurate timing constraints.

 

Regards

Anand

0 Kudos
IDeyn
New Contributor III
791 Views

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.

 

dac_200MHz.png

 

 

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:

 

dac_100MHz.png

 

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

 

0 Kudos
AnandRaj_S_Intel
Employee
791 Views

Hi Ivan,

 

Thanks for the project, Let me check and come back.

 

Regards

Anand

 

0 Kudos
IDeyn
New Contributor III
791 Views

Hi Anand!

 

Ok, thank you very much.

 

 

--

Best regards,

Ivan

 

0 Kudos
AnandRaj_S_Intel
Employee
791 Views

Hi ivan,

 

  1. 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.
  2. 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>
  3. 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.

tse.JPG

Regards

Anand

 

 

0 Kudos
IDeyn
New Contributor III
791 Views

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.

TIMING.jpg

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

 

0 Kudos
AnandRaj_S_Intel
Employee
791 Views

Hi Ivan,

 

That's how tool behaves.

Design may/may not meet timing requirements. We have to set it manually.

 

Regards

Anand

0 Kudos
IDeyn
New Contributor III
791 Views

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

 

0 Kudos
Reply