• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 410 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C6678 SRIO LSU status mechanism

Peter Robertson
Expert 2770 points

I am curious as to why the truly-bizarre mechanism to determine the completion of an LSU transaction was chosen.

Having to read a bit when you lock the LSU registers and later wait until a status field matches that bit seems to be a vastly over-complicated way of doing something simple.

Why did the status field not just have a 'busy' value?

  • 0
    TI__Mastermind 23525 points

    Reading the CC was a little more straight-forward on C64x where each LSU only processed one transaction at a time, i.e. you would get an interrupt (or poll bsy bit) then you could simply read the CC.  With C66x, the goal was improve performance, thus the shadow registers were added allowing the user to program multiple transactions without waiting for the preceeding transaction to complete.  To support this, a mechanism must exist to track multiple CCs because when you get an interrupt and the ISR fires, you may need to look at multiple CCs because multiple tranactions may have completed.  The LTID indexes which field to look at in the LSUx_STATn register, and once you look a that field, the LCB tells you if it is valid for the current transaction, or if it is for the next transaction.  The CC needs to be viewed in a timely manner before it is reused by another transaction. 

  • 0 in reply to tscheck
    Expert 2770 points

    "The CC needs to be viewed in a timely manner before it is reused by another transaction."

    So you have built a potential race condition into the hardware.

    As far as I can see the only way round that is to limit the number of extant operations to one, which defeats the purpose of the mechanism.

    That sounds like a big mistake to me.

  • 0 in reply to Peter Robertson
    TI__Mastermind 23525 points

    Software servicing hardware always involves such conditions in many many places with real time systems unless you have infinite resources.  I explained how it works here. You don't have use it if you don't want to.