• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 564 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.

[C66x, EDC] Usage of L2EDCMD.SUSP and L1PEDCMD.SUSP

Naoki Kawada
Guru 19890 points

Hello, 

I came from :

And now my customer needs to clarify the usage of L2EDCMD.SUSP and L1PEDCMD.SUSP.

As for L1PEDCMD.SUSP, the TMS320C66x DSP CorePac User Guide says:

  Programs can suspend the Error Detect logic by writing a ‘1’ to L1P Error Detection
  Command Register Suspend bit (L1PEDCMD.SUSP = ‘1’). While suspended, the L1P
  neither checks parity nor updates the valid bits. The purpose of this mode is to test this
  logic in emulation mode.

And as for L2EDCMD.SUSP, the user guide says:

  Programs can suspend the EDC logic by writing a ‘1’ to the L2 Error Detection
  Command Register Suspend bit (L2EDCMD.SUSP = ‘1’). While suspended, the L2
  neither checks parity nor updates the valid bits. The purpose of this mode is to allow
  testing of the EDC logic in emulation mode.

What we don't understand is the purpose of these bits.
'emulation mode' sounds these bits are existing for testing -- validating the EDC logic and related interrupt/exception are functional during the emulation.
But in the previous post (Please take a look at the above link), I understood there was no way to generate the parity error condition intentionally for debug purpose and I believe these bits would be used for other purposes. 

Could you please explain what is intended by these bits ?
I'm wondering if we could use these bits to suspend EDC logic not to happen parity error interrupt/exception during the debug via CCS. Correct ? 

Best Regards,
Naoki Kawada

 


  • 0
    TI__Genius 12805 points

    Hi Naoki

    This is my understanding of the above -

    If you want to verify that the parity mechanism actually works you do the following:

    You load the memory (L1D or L1P ) with some data. Now the parity bit is calculated and is set according to the data

    You suspend the Error detection logic

    Now you re-write the memory with different data (different code). The parity bit is not updated (because the logic is suspended) so now the parity bit is not correct

    Now you enable the error detection logic and you read the same data, but this time, the parity bit is not correct so you should get an exception error

    Does it make sense?  If so close the thread

    Regards

    Ran

  • 0 in reply to ran35366
    Guru 19890 points
    Hello Ran,

    Thanks for your reply. Ok, I understood.

    I will close this thread, but I got an another quick question related to EDC. And to answer to their question, I want to confirm the following understanding is correct.

    My assumptions are --
    The width of C66x fetch packet is 256bit, so the read width for each fetch from 'L1P SRAM/Cache' should be always 256bit. a 256bit fetch can be regarded as '128bit aligned read', because it is multiple of 128, in EDC point of view. A 256bit fetch is also applied to 'L2 SRAM/Cache' and it is never divided into narrower accesses to invalidate the parity, for example, 4 x 64 bit read accesses from L2 to L1P (because 256bit bus is existing between L1P and L2).

    Is my understanding correct, right ?
    Once this is clarified, I'll close the thread.

    Best Regards,
    Naoki Kawada
  • 0 in reply to Naoki Kawada
    TI__Genius 12805 points

    I am not sure what exactly you mean when you talk about L2 to L1P (do you mean L1D for 64 bit read?) but regardless, I think that you understand the mechanism is working

    Ran

  • 0 in reply to ran35366
    Guru 19890 points

    Sorry for the confusion, I had a typo --  I corrected my previous comments as below:

          A 256bit fetch is also applied to 'L2 SRAM/Cache' and it is never divided into narrower accesses to invalidate ignore hamming code check for the parity,
          for example, 4 x 64 bit read accesses from L2 to L1P (because 256bit bus is existing between L1P and L2).

    Well, CorePack User guide says, 

    The L2 memory controller always performs a full hamming code
    check on 128-bit reads

    So when the code is on L2 SRAM/Cache and when a fetch for the code is not a 256bit width (i.e. not in 128bit boundary), suchlike 4times of 64bit, then it could violate the above statements and I wondered if the party check might not be taken.... And now what i want to confirm is that there is no condition to ignore the hamming code check for the parity when executing the code on L2.
    In other word, I want to confirm my understanding is correct, which L1P controller would always read a code form L2 on 256bit boundary.  

    Hope you could understand my question...

    Best Regards,
    Naoki Kawada

  • 0 in reply to Naoki Kawada
    TI__Genius 12805 points
    yes, i think that you are correct.

    ran
  • 0 in reply to ran35366
    Guru 19890 points
    Ran, thanks for your reply. Understood. I close the thread.

    Naoki