How to count levels of logic in timing paths?

[harnhua]

Hi,

I am having some trouble finding out where the levels of logic are in my critical paths on a Stratix10 design in Quartus Prime 21.4 Pro Edition.

For example, in Timequest, the Statistics show 1 level of logic for a particular path.

However, the datapath itself seems to contain many more levels of logic:

In the table, rows 3 to 18 contain elements of type "IC" or "CELL" and  "Combinational cell".

- Counting "CELL" types: 12 logic levels?

- Counting "CELL" types in different XY locations: 4 logic levels?

However much I tried, I could not figure out how to arrive at 1 level of logic.

Unfortunately I was not able to use the schematic view as this path is in an encrypted node.

Is there a document that explains how the number of logic levels are calculated?

What is the way to count them from the STA report?

Thanks!

[sstrell]

That is strange.  Like you say, normally logic levels are counted as jumps between cell delays and interconnect delays.  Maybe it's because this is inside encrypted IP.  Do you see multiple paths like this?  Or paths that do display the number of logic levels correctly?

[harnhua]

Yes, I see multiple paths like this.

So far, all the paths with incorrect logic level numbers seem to belong to encrypted IP.

And yes, I do see paths with the correct number of logic levels. The one shown below makes sense that it has 2 logic levels.

Interestingly, those are located in unencrypted nodes. I am able to view and verify the logic levels in the schematic view as well.

I guess there may be a bug (or intended feature) in the path statistics for paths in encrypted IP?

Thanks

[AqidAyman_Intel]

Hello,

Could you share your test case design with us so that we can reproduce it on our side and see the root problem of it?

You can choose to share it or not and if yes, is it privately or publicly by replying here? Just let me know.

Regards,

Aqid Ayman

[harnhua]

Hi,

Thank you for following up on this.

Unfortunately, as it is a customer's design, we are unable to share it.

If the theory that this incorrect logic levels number is reported for encrypted IP, maybe can you try a small testcase containing encrypted IP?

Thanks!

[AqidAyman_Intel]

Hello,

Alright, noted that.

The reason why I asked for the customer's design is to see if the error was observed from my end also or not. It will be more efficient to debug the issue.

Regards,

Aqid Ayman

[harnhua]

Thank you for trying to help.

Please let me know if you can reproduce the same issue in any design with encrypted IP.

I will try to get a testcase as well.

[AqidAyman_Intel]

Hello,

Okay, sure. I will update you if I able to reproduce the issue.

Regards,

Aqid Ayman

[AqidAyman_Intel]

Hi,

Do you able to provide the test case?

Regards,

Aqid Ayman

[harnhua]

Hi,

Thank you for following up on this.

Unfortunately, we have not gotten permission to share this design.

[Ryan_S_Intel]

I'm guessing the last part, where the node locations increment by 3, e.g. N0, N3, N6, N9... are part of a carry-chain, which are not counted as a single logic level since they are much faster.  I'm not sure how they're counted.  But with the first part there are definitely distinct hops that should count as more than one.  Personally, I've done timing closure on designs for ~20 years and have never found "levels of logic" that useful.  There are just too many other things going on, such as carry-chain, fan-out, interconnectedness, etc. that it's not that useful.  Plus, in the screen-shot above there is so much more info in the Data Path tab.  You have a path with many levels, it crosses three LABs(Y112, Y111, Y109), and looks to be placed and routed really well.  If you only had one failing path, maybe getting rid of a lab hop would help close timing, but most likely you have a number of paths, and many similar ones that just barely make timing, whereby squeezing this path down into fewer LABs will probably break another path.

My first question would be why are the two endpoints in ALM registers?  Do they have retiming restrictions that prevent Hyper-Retiming?  When you run report_timing, click on the -extra_info all and it should give you info about retiming restrictions(plus other fun stuff).  

[AqidAyman_Intel]

Hi Harn,

Did you have any feedbacks on the comments by Ryan?

Regards,

Aqid

[AqidAyman_Intel]

Hi Harn,

Did you have any feedbacks on the comments by Ryan?

Regards,

Aqid

[harnhua]

Hi,

My apologies for the delay in responding. I have been requesting information from the customer.

If I understand @Ryan_S_Intel 's comments correctly, levels of logic are not terribly useful beyond getting a rough sense of whether they are feasible given a path's timing budget - if not, some redesign is recommended. As you stated, maybe in reality there are too many things going on at the same time. Levels of logic is a single check and probably not the most important one.

Regarding @Ryan_S_Intel 's question about Hyper-Timing, here is the Extra Info portion from a similar path (the design has since changed):

Is it correct to say that Hyper-Timing is expected to move all endpoints away from ALM registers to hyper-register locations by default, if there are no restrictions?

There does not seem to be any Retiming restrictions stated, yet the endpoints are still ALM Registers.

Thank you for your comments. Much appreciated.

[Ryan_S_Intel]

It's actually very common for registers with no retiming restrictions to still end up in the ALM register as the best possible location.  We used to not have this extra_info report that showed retiming restrictions, and I would waste a lot of time trying to figure out if there was a restriction or not.  With the report you can see the "--" and know you don't have to worry about retiming restrictions on the end points, and can then move on to more traditional optimizations, like reducing levels of logic.  : )  (Note I'm not against analyzing levels of logic, but I'm not that interested in the absolute number.)

Actually, since this is the worst path, you could look at the Retiming Critical Chain Report, to see how big the chain is and if there is any way you can pipeline or remove restrictions elsewhere in the Critical Chain.  

Your path is placed and routed well, has a carry-chain for half the logic which is very fast.  I see your target is 2ns/500MHz, which is quite fast and usually takes very careful designing to close timing(though you are very close already, so are doing a good job, though squeezing out that last bit may be difficult)  Good luck!

[AqidAyman_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.