The routing delay is 0 ns in quartus chipplanner

[sunin]

I designed a program about TDC. However,i found the routing delay is 0 ns when i check its timming by Timequest.Shown below, the Tco is 0.073ns,but the routing delay is 0 ns.

chip planner

Obviously, there is no delay between the adjacent LEs. In this case, the timing report illustrates many slacks shown figure below. 

timing report

I want to have it working reliably, and make it clear whether the zreo ns effected by those slecks.

Any ideas?

Thanks and best regards

sunin

[RichardTanSY_Intel]

Wow, that is a huge negative slack! I will look into why the clock skew is so high and start work from there first. 2.347 is too high.

Before that, check if the timing path is relevant as Timing Analyzer will analyze all paths. If not, set false path to tell the tool to exclude that path.

You may checkout the Best Design Practices for Timing Closure:

https://www.youtube.com/watch?v=UGGkKZylJBo&t=122s

p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 9/10 survey.

[sunin]

In fact,  i have confirmed that the 0 ns routing delay has no connection with the huge slack earlier this evening. And now, i am more concerned about why the 0 ns routing delay persist... I have been stumped until now and didn't know what else to do... 

[sunin]

I designed a 16-bit full adder. Its routing delay between adjacent LABs is 0 ns as similar as the figure above. Both are wrong obviously, but what else can I do?

[RichardTanSY_Intel]

I do not have the answer with the current info provided.

I will need to get your design to further investigate this. Could you share the design .qar file?

Which Quartus Pro version and devices are you using?

[sunin]

Thanks for your response!  The file below is a simble project about 16_bit adder. It use the delay  chain resourse shown in the chip-planner. In this case, there is no extra delay between the adjacent LABs. In my humble opinion, the routing delay between LABs should be bigger than those between LEs. Your reply is very helpful to me!

Best wishes for you!

[sunin]

Especially, the code is designed at Quartus prime standrad edition and EP4CE10F17C8.

[sunin]

Are you still there？ In my opinion, thare are different delays between adjacent LEs especially between adjacent LABs. However, the routing delay created in 16-bit adder is not like this. The 16-bit adder project shown below has played STA, and the delays are similar. I will so appreciate it if you can reply to me    ==||

[RichardTanSY_Intel]

Sorry for the delay in response. It seems that the timing path comes from the LPM_ADD_SUB IP itself.

I believe the IP function correctly and the 0ns routing delay could be an expected behavior.

Do you see any problem when you try to run simulation with the current design?

[RichardTanSY_Intel]

May I know if you able to check whether the design work as desired, through simulation?

[RichardTanSY_Intel]

Hi,

Any update in regards to this case?

[RichardTanSY_Intel]

As we do not receive any response from you on the previous question/reply/answer that we have provided. Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

Thank you.

Best Regards,

Richard Tan

p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 9/10 survey.