critical path start and end in same register

--- Quote Start ---

Hi,

I try to understand the critical path reports from quartus (timing analyzer). it seems that there are paths that start and end in the same register but i don't know how this would be reflected in the source code.

Actually the critical path report is difficult to understand, because between the registers there are several blocks with unrecognisable names which i cannot link to source code via the 'locate in design file' option.

Is there any idea what start and end in the same register would mean and how to resolve this? And how to recognise those conbinational blocks in quartus critical path visual representation?

Thanks,

--- Quote End ---

My immediate thoughts would be that such paths exist for any registered logic that takes in its own output e.g.accumulators, adders, counters.

--- Quote Start ---

My immediate thoughts would be that such paths exist for any registered logic that takes in its own output e.g.accumulators, adders, counters.

--- Quote End ---

True in general but in this case this register is an output of a mux and only written...

Btw, is there a way to locate those 'nodes' in the critical path representation in the source file? if i select the locate to file option it just points to a process

--- Quote Start ---

True in general but in this case this register is an output of a mux and only written...

Btw, is there a way to locate those 'nodes' in the critical path representation in the source file? if i select the locate to file option it just points to a process

--- Quote End ---

still it means there is some feedback from somewhere at output back into your register inputs.

Regarding locating path it may have been created by fitter without clear mapping to source code. Try locate in floor planner and map it back to that process.

If timing passed I wouldn't worry about critical path. Moreover the definition of critical path is not standard. It may refer to usual timing register paths or it may refer to some combinatorial path delays from input pins to output pins. I never understood it really.

Most feedback paths are due to the conditions where logic holds its value. Often this inferred, e.g. you might have something like:

always@(posedge clk) begin

if (a) begin

if (b) begin

c <= d;

If a and b are not true, the c <= c, which is implied. That being said, this feedback is usually a short path and doesn't fail timing. It's generally only if you code a true large feedback, like kaz is talking about, that timing might be an issue. As for locating back to the code, you do have to understand the code to a certain degree. Registers can usually trace back to the process, and then you can find it based on names. But combinatorial logic/LUTs don't directly trace back to a line in the code or anything like that, and take some detective work. I find the RTL viewer pretty useful. Find the register on the left side in the Node Finder/Hierarchy(I forget the name) and right-click New Sheet(again, I forget the name, but it creates a sheet with only the register in it). You can select the D/Q pins of the register and expand between selected points. You can also double click in pins to expand, or right-click Expand. It helps draw out what it goes through, but it's pretty high level and you have to translate it back to the RTL.

--- Quote Start ---

Most feedback paths are due to the conditions where logic holds its value. Often this inferred, e.g. you might have something like:

always@(posedge clk) begin

if (a) begin

if (b) begin

c <= d;

If a and b are not true, the c <= c, which is implied. That being said, this feedback is usually a short path and doesn't fail timing. It's generally only if you code a true large feedback, like kaz is talking about, that timing might be an issue. As for locating back to the code, you do have to understand the code to a certain degree. Registers can usually trace back to the process, and then you can find it based on names. But combinatorial logic/LUTs don't directly trace back to a line in the code or anything like that, and take some detective work. I find the RTL viewer pretty useful. Find the register on the left side in the Node Finder/Hierarchy(I forget the name) and right-click New Sheet(again, I forget the name, but it creates a sheet with only the register in it). You can select the D/Q pins of the register and expand between selected points. You can also double click in pins to expand, or right-click Expand. It helps draw out what it goes through, but it's pretty high level and you have to translate it back to the RTL.

--- Quote End ---

I tried it and it was useful, thank you!!

--- Quote Start ---

I tried it and it was useful, thank you!!

--- Quote End ---

Btw, regarding critical paths, i inserted some registers on one of the reported paths, but the timeQuest result after this update showed new paths with longer delay than previous case....is this normal? i assume if you add registers you either get some or worst case no reduction in delay, can you add them and get delay increase in other paths?

--- Quote Start ---

It will depend how you've added them. If they are simply in the data path with no control logic then yes, the path should be shorter, unless it has somehow put these registers miles away. Also check that it hasn't merged them with some other logic. I once caught a bug where quartus had merged my register with some shift register in another entity that was completely unrelated. This is very unlikely, but check out the map view.

--- Quote End ---

what about the case with control logic? can something go wrong in that case? any example?

--- Quote Start ---

Like with any logic, the longest path will depend on the logic. If you have enables on these registers, then those also need to meet timing. The more paths to a register, the more things the fitter has to time for, and it could be the case that a register is being pulled in multiple directions to get it to meet timing.

--- Quote End ---

i don't see any enable signal in RTL viewer actually ....the path that was marked as critical was a ending on register which was assigned a value after 3-4 OR gates like: output <= a or b or c or d. The path start was signal c and end the output...just one register between c and output gave worse frequency result...and the new worse critical path was marked with c as the end...seems weird?