IBQ stalls на С55x, или как их избежать Опции

[Warlord]

О том как работает fetch конвейер в мануалах TI написано скупо и поверхностно. Буфер IB наполняется со скоростью 4 байта, а опустошается 1-6 байт. Смотрю в Pipeline Stall Analyzer по ходу программы IB начинает опустошаться и возникает IBQ stall причем никакими страшными 5 и 6 байтными командами и вызовами и циклами не пахнет. Отсюда возникают вопросы: При каких условиях перестает наполняться очередь и при каких вознобновляется. Вот для примера кусочек кода:

Код

_func
    NOP_16 || NOP
    NOP_16 || NOP_16
    NOP_16 || NOP
    NOP_16 || NOP
    NOP_16 || NOP
    NOP_16 || NOP_16
    NOP_16
    NOP_16 || NOP
    NOP_16
    NOP_16 || NOP
    NOP_16 || NOP_16
    NOP_16 || NOP
    NOP_16 || NOP_16
    NOP_16 || NOP_16
    NOP_16 || NOP_16
    RET

В процессе выполнения последние 2 инструкции перед RET оказываются отсеченными IBQ stall. Почему? Никаких видимых препятствий для наполнения буфера нет.

[Warlord]

Жизнь совпадает с симулятором - 32 такта, включая CALL(5) и RET(11), 15 инструкций, 1 stall

[SM]

Жизнь совпадает с симулятором - 32 такта, включая CALL(5) и RET(11), 15 инструкций, 1 stall

Как предположение - RET делает что-то с IBQ когда находится в AD или AC1 конвейера, что и вгоняет его в stall. Второе подозрительное - в описании фазы D сказано, что она читает 6 байт из IBQ. А не "up to 6". Точно также как и сказано, что IBQ читает по 32 бита, а отправляет в декодер пакетами по 48. Так что остается только гадать, как это там внутри происходит.