How to use D5_DELAY or D5_OE_DELAY on Cyclone V

[Joakim]

I'm desperately trying to get the timing to work between my Cyclone V and an external CPU. Because of the clock delay, it seem to be impossible to get the timing to pass within one clock cycle, so I tried to get it to within 2 clock cycles using multi cycle.

But in that case my data is delayed 22 ns instead of 3 ns. Looking at Chip planner, I notice that the tool has set D5_OE_DELAY to 31, which should be maximum delay.

So how do I get it to use a more reasonable delay, like 10 ns?

I have tried:

set_instance_assignment -name D5_DELAY 8 -to FX3_DQ[0] or set_instance_assignment -name D5_OE_DELAY 5 -to FX3_DQ[0]

But it seem to be ignored (the 8 and 5 are at the moment just experimental numbers).

[sstrell]

Can you post any code, your .sdc file, and a timing report?

Adjusting I/O delays and intentionally adding multicycle to simply loosen timing are not great solutions.

#iwork4intel

[KhaiChein_Y_Intel]

Hi,

Could you provide the sample test case for investigation?

Thanks.

[Joakim]

Thank you for your quick reply.

I have created a mini project containing only the most vital parts, see attached FX3GPIF qar file.

It shows about the same issue, you can easily add / remove the multicycle statement in the sdc file.

With the multi cycle statement I get D5 OE Delay chain as 31, and 0 without it.

BR / Joakim

[KhaiChein_Y_Intel]

Hi,

The total delay is too high, the min delay is 1.7ns and max delay is 3.2ns. The design has timing margin of 5ns which is not enough in this case.

Thanks.

[Joakim]

Yes, I figured that. But how do I get around it. It can't be unusual to have an interface to a 100 MHz data bus.

I tried multiclock which would give 15 ms timing margin, but in that case it needs a lot more than using single clock.

It seem to be the D5 OE Delay that is set to a value that is too high.

[Joakim]

Hi @KhaiY_Intel​ ,

Have you tried my design with multi_cycle enabled?

The question is really why I can't get the timing to work using multi cycle, resulting in a 20 ns clock.

BR / Joakim

[KhaiChein_Y_Intel]

Hi Joakim,

Yes. I am working on this. Please allow me some time on this. I will provide an update by tomorrow.

Thanks.

[KhaiChein_Y_Intel]

Hi,

Could you try

set_multicycle_path -from [get_clocks {FX3_PCLK}] -to [get_clocks {FX3_PCLK_virt}] -setup 2 -end

set_multicycle_path -from [get_clocks {FX3_PCLK}] -to [get_clocks {FX3_PCLK_virt}] -hold 1 -end

Thanks.

[Joakim]

Thank you for your suggestion.

My concern with this solution is that the setup time will be too long, i.e. it will actually go high before the first rising edge of the clock (see picture).

I believe I was once told that using -hold 0 (or not specifying hold time), would help here, but I'm not sure how.

I would actually like to specify both a max time and min time for the setup, i.e. min 3.2 ns and max (10-hold time = 8.3 ns)(?)

[Joakim]

Are there any good documentation available on how to use the Output and Input Pin delay in a correct way.

I'm very confused about paths that appear to be very short, takes very long time to arrive, and the opposite.

I assumed that I would be able to see it in the delay registers in the Resource property editor, but the delay is always displayed as 0.

I also assumed that these delay circuits would be used to adjust the external timing, but can't see anything like this.

[KhaiChein_Y_Intel]

Hi,

You may refer to https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/qts/qts_qii53024.pdf

Page 7-6 Input/Output Constraint

Page 7-9 Creating Multicycle Exceptions

By default, the TimeQuest analyzer performs a single-cycle analysis to determine the setup and hold checks. Also, by default, the TimeQuest Timing Analyzer sets the end multicycle setup assignment value to one and the end multicycle hold assignment value to zero.

You may refer to Page 7-14 for the examples of applying multicycle for different conditions. You have to examine which condition fit your design requirement.

If you use multicycle paths that cross different clock domains, you must carefully examine the timing paths in the TimeQuest analyzer before and after applying the multicycle exception to determine if the launch and latch clock edges function as you intend.

Thanks.

[KhaiChein_Y_Intel]

Hi,

May I know if you have any questions?

Thanks.

[Jodok]

Hi Joakim,

I encountered a similar behaviour. Did you found a solution to your problem?

Greetings

Tom