## Critical Path in Loop

I'm trying to the use the details of the loop analysis report to decrease the ii of a loop. Unfortunately I can't find a good explanation about some of the details. I've posted the output of part of the report below, followed by some questions.
Code:
```The critical path that prevented successful II = 1 scheduling:
Number of nodes in critical path exceeded what the compiler has captured. Only the top 13 failing nodes are listed.
1.1 clock cycle Select Operation (udpip.cl: 195, udpip.cl: 199)1.1 clock cycle Select Operation (udpip.cl: 144, udpip.cl: 222, udpip.cl: 362, udpip.cl: 366, udpip.cl: 371, udpip.cl: 388, udpip.cl: 390)1.1 clock cycle Select Operation (udpip.cl: 191, udpip.cl: 192)1 clock cycle Left Shift Operation (udpip.cl: 195)0.22 clock cycles 32-bit Integer Add Operation (udpip.cl: 1220, udpip.cl: 1228, udpip.cl: 1235)0.22 clock cycles 32-bit Integer Add Operation (udpip.cl: 1220, udpip.cl: 1235)0.22 clock cycles 32-bit Integer Add Operation (udpip.cl: 1235).........```
Question 1) - The first bullet says the number of nodes in critical path is beyond what the compiler captured, and the top 13 FAILING does are listed. Some of the bullets below that are > 1 clock cycle, some are < 1 clock cycle. Is each bullet an independent critical path? If so, aren't the paths < 1 NOT failing? Am I missing something here? If I know I can focus on the bullets that are > 1 to get to an ii of 1 it would be easier.

Question 2) - Bullet 1 indicates a 1.1 clock cycle select operation on the "stallRead" variable. I can't fathom how this logic can't be accomplished in a single clock cycle. See the code segment below. I want to read from a channel on every loop, until an end of frame flag is set in the read data. At that point, stall for 6 clock cycles then then start reading again.

Code:
```uchar stallRead = 0;
while(1)
{