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.
The critical path that prevented successful II = 1 scheduling:
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.

uchar stallRead = 0;        
        if (stallRead == 0)
            rxData      = read_channel_intel(TOCLIENT);
            rxWord[0]   = rxData.data;            
            rxStatus[0] = parseStatus(rxData.header);
            if (rxStatus[0].eop) //if we hit a end of frame flag, stall for a few clock cycles
                stallRead = 0x40;
            stallMacRead = stallMacRead >> 1;

                case statement and other logic......
Thanks, any suggestions or pointing to examples or documentation is appreciated.