• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 7579 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.

Please provide Algorithm for (72, 64) SECDED ECC as used with TMS570LS3137 device

Pashan None
Genius 5660 points
Other Parts Discussed in Thread: NOWECC, TMS570LS3137

Hello Support,

Can you please provide a detailed description of (72,64) SECDED ECC Algorithm as being used within nowECC as well as TMS570LS3137?

I am looking for Boolean Equations for SECDED ECC Logic.

Thank you.

Regards

Pashan

 

  • 0
    TI__Intellectual 1325 points

    Hi Pashan,

    This question is being reviewed by the nowECC team and will be responded to shortly.

    Best regards.

  • 0 in reply to Diwakar Bansal
    TI__Intellectual 1325 points

    Hello Pashan,

    Please refer to the following Application note which describes describes ECC handling in TMSx70-Based Microcontrollers.

    http://www.ti.com/lit/an/spna126/spna126.pdf

    Section 1.5 , Table 1. ECC Encoding in this Application note illustrates how the ECC is calculated.

  • 0 in reply to Diwakar Bansal
    Genius 5660 points

    Hello Diwakar,

    1> Can you please explain the meaning of the column ADDR_MSW_LSW in the above mentioned table?

    2> In ADDR_MSW_LSW column, one row is EMPTY means what?

    Thank you.

    Regards

    Pashan

     

  • 0 in reply to Pashan None
    TI__Guru**** 190616 points

    Hi Prashan,

      ADDR means the address. MSW means the most significant (the upper 32bit) word and LSW means the least significant (lower 32bit) word.  ECC is calculated based on both the address and the 64-bit data associated with the specified address.

     I think somehow the apps note missed to show the value under the column ADDR_MSW_LSW for ECC bit5. The value should be 07F80_FF00FF00_FF00FF00.

    Please let me know if this answers the question.

    regards,

    Charles

     

  • 0 in reply to Charles Tsai
    Genius 5660 points

    Hello Charles,

    In the CPU Parity Column, I don't see any entry for ECC(5) and ECC(0).

    What does that missing entry means?

    Thank you.

    Regards

    Pashan

     

  • 0 in reply to Pashan None
    TI__Intellectual 1325 points

    It is 'Even' for both ECC(5) and ECC(0). This is also missing from the app note. Thanks for the inputs.

    Regards,

    Diwakar

  • 0 in reply to Pashan None
    TI__Guru**** 190616 points

    Hi Pashan,

      As Diwakar just said they are "Even". During document coversion these fields are missed out for some reason. I will report this issue. I also notice another errors in the table for rows corresponding to ECC(5) and ECC(0). The fields that marked with "x" are not matching the the hex data code presented under the ADDR_MSW_LSW column. I think thisi is again a result of file conversion. Please also take notice of this. For example, for row corresponding to ECC(0) the hex value is 554EA_B4D1B4D1_4B2E4B2E is correct. But if you look at the corresponding "x" they don't match.

    regards,

    Charles

  • 0 in reply to Charles Tsai
    Genius 5660 points

    Hello Charles/Diwakar,

    I am still not clear about the BOOLEAN Equations required for generating ECC bits.

    Initially I thought for 64-Bit DATA, with NO Address ECC,

    Each row of spna126.pdf table need to be XORed [x-bit positions] for the corresponding ECC-Bit.

    But, then how does CPU Parity Column fits into that BOOLEAN XOR equation for each ECC Bit?

    Please provide some more detail with example for 64-Bit DATA with NO ADDRESS ECC calculation.

    That will help me understand.

    For 64-Bit DATA with no ADDRESS ECC example below:

    0x0000_0000_0000_0000             ------------  0x0C [ECC Byte]

    0x0000_0000_0000_0001              ----------- 0x6E [ECC Byte]

    0x0000_0000_0000_0002              ----------- 0x68 [ECC Byte]

    0x0000_0000_0000_0004              ----------- 0x6B [ECC Byte

    How does for the above example ECC Byte is calculated with no ADDRESS ECC?

    Thank you.

    Regards

    Pashan

     

  • 0 in reply to Pashan None
    TI__Guru**** 190616 points

    Hi Pashan,

      Each ECC bit is a result of the corresponding data bits at the specified bit locations being XOR'ed together. The CPU parity bit column specifies whether the ECC parity is calculated in EVEN parity format or ODD parity format. For example to calculate ECC(0), it needs to have even number of '1' at the corresponding bit positions marked with 'x' to set ECC(0) to '1'. Likewise, for ECC(2), it needs to have odd number of '1' at the corresponding bit positions marked with 'x' to set ECC(2) to '1'.

      If you just want to calculate ECC for only the 64-bit data then you can just simply ignore all the participating address bits. Just ignore all the 'x' in the upper table for bits 82:64 which corresponds to address bits 21:03.

    regards,

    Charles

     

  • 0 in reply to Charles Tsai
    Genius 5660 points

    Hello Charles,

    Following the above rules,

    Can you please elaborate for the following 64-Bit DATA Item of 0x0000_0000_0000_0001, how ECC Byte as 0x6E?

    This will help me understand the algorithm better.

    Thank you for the support.

    Regards

    Pashan

     

  • 0 in reply to Pashan None
    TI__Guru**** 190616 points

    Hi Pashan,

      I'm not sure how you get the 0x6E for the data value of 0x0000_0000_0000_0001. Please look at the below equations to calculate each ECC bit.

    regards,

    Charles

    ECC(0) <= DATA(1) xor DATA(2) xor DATA(3) xor DATA(5) xor

                DATA(8) xor DATA(9) xor DATA(11) xor DATA(14) xor

                DATA(17) xor DATA(18) xor DATA(19) xor DATA(21) xor

                DATA(24) xor DATA(25) xor DATA(27) xor DATA(30) xor

                DATA(32) xor DATA(36) xor DATA(38) xor DATA(39) xor

                DATA(42) xor DATA(44) xor DATA(45) xor DATA(47) xor

                DATA(48) xor DATA(52) xor DATA(54) xor DATA(55) xor

                DATA(58) xor DATA(60) xor DATA(61) xor DATA(63);

     

      ECC(1) <= DATA(0) xor DATA(1) xor DATA(2) xor DATA(4) xor

                DATA(6) xor DATA(8) xor DATA(10) xor DATA(12) xor

                DATA(16) xor DATA(17) xor DATA(18) xor DATA(20) xor

                DATA(22) xor DATA(24) xor DATA(26) xor DATA(28) xor

                DATA(32) xor DATA(33) xor DATA(34) xor DATA(36) xor DATA(38) xor

                DATA(40) xor DATA(42) xor DATA(44) xor DATA(48) xor

                DATA(49) xor DATA(50) xor DATA(52) xor DATA(54) xor

                DATA(56) xor DATA(58) xor DATA(60);

     

      ECC(2) <= not (DATA(0) xor DATA(3) xor DATA(4) xor DATA(7) xor

                DATA(9) xor DATA(10) xor DATA(13) xor DATA(15) xor

                DATA(16) xor DATA(19) xor DATA(20) xor DATA(23) xor

                DATA(25) xor DATA(26) xor DATA(29) xor DATA(31) xor

                DATA(32) xor DATA(35) xor DATA(36) xor DATA(39) xor

                DATA(41) xor DATA(42) xor DATA(45) xor DATA(47) xor

                DATA(48) xor DATA(51) xor DATA(52) xor DATA(55) xor

                DATA(57) xor DATA(58) xor DATA(61) xor DATA(63));

     

      ECC(3) <= not (DATA(0) xor DATA(1) xor DATA(5) xor DATA(6) xor

                DATA(7) xor DATA(11) xor DATA(12) xor DATA(13) xor

                DATA(16) xor DATA(17) xor DATA(21) xor DATA(22) xor

                DATA(23) xor DATA(27) xor DATA(28) xor DATA(29) xor

                DATA(32) xor DATA(33) xor DATA(37) xor DATA(38) xor

                DATA(39) xor DATA(43) xor DATA(44) xor DATA(45) xor

                DATA(48) xor DATA(49) xor DATA(53) xor DATA(54) xor

                DATA(55) xor DATA(59) xor DATA(60) xor DATA(61));

     

      ECC(4) <= DATA(2) xor DATA(3) xor DATA(4) xor DATA(5) xor

                DATA(6) xor DATA(7) xor DATA(14) xor DATA(15) xor

                DATA(18) xor DATA(19) xor DATA(20) xor DATA(21) xor

                DATA(22) xor DATA(23) xor DATA(30) xor DATA(31) xor

                DATA(34) xor DATA(35) xor DATA(36) xor DATA(37) xor

                DATA(38) xor DATA(39) xor DATA(46) xor DATA(47) xor

                DATA(50) xor DATA(51) xor DATA(52) xor DATA(53) xor

                DATA(54) xor DATA(55) xor DATA(62) xor DATA(63);

     

      ECC(5) <= DATA(8) xor DATA(9) xor DATA(10) xor DATA(11) xor

                DATA(12) xor DATA(13) xor DATA(14) xor DATA(15) xor

                DATA(24) xor DATA(25) xor DATA(26) xor DATA(27) xor

                DATA(28) xor DATA(29) xor DATA(30) xor DATA(31) xor DATA(40) xor

                DATA(41) xor DATA(42) xor DATA(43) xor DATA(44) xor

                DATA(45) xor DATA(46) xor DATA(47) xor DATA(56) xor

                DATA(57) xor DATA(58) xor DATA(59) xor DATA(60) xor

                DATA(61) xor DATA(62) xor DATA(63);

     

      ECC(6) <= DATA(0) xor DATA(1) xor DATA(2) xor DATA(3) xor

                DATA(4) xor DATA(5) xor DATA(6) xor DATA(7) xor

                DATA(24) xor DATA(25) xor DATA(26) xor DATA(27) xor

                DATA(28) xor DATA(29) xor DATA(30) xor DATA(31) xor

                DATA(32) xor DATA(33) xor DATA(34) xor DATA(35) xor

                DATA(36) xor DATA(37) xor DATA(38) xor DATA(39) xor

                DATA(56) xor DATA(57) xor DATA(58) xor DATA(59) xor

                DATA(60) xor DATA(61) xor DATA(62) xor DATA(63);

     

      ECC(7) <= DATA(0) xor DATA(1) xor DATA(2) xor DATA(3) xor

                DATA(4) xor DATA(5) xor DATA(6) xor DATA(7) xor

                DATA(24) xor DATA(25) xor DATA(26) xor DATA(27) xor

                DATA(28) xor DATA(29) xor DATA(30) xor DATA(31) xor

                DATA(40) xor DATA(41) xor DATA(42) xor DATA(43) xor

                DATA(44) xor DATA(45) xor DATA(46) xor DATA(47) xor

                DATA(48) xor DATA(49) xor DATA(50) xor DATA(51) xor

                DATA(52) xor DATA(53) xor DATA(54) xor DATA(55);

  • 0 in reply to Charles Tsai
    Genius 5660 points

    Hello Charles,

    I am attaching a document [Cortex_F021_ECC.pdf] as well as all the necessary files in ZIP format in order to recreate the problem at your end with the nowECC Version 2.17 tool.

    Let me know if you don't find the error.

    Attached document mentions how to view the error.

    I am waiting for the clear understanding of the error I am seeing at my end as it doesn't fit the BOOLEAN EQUATION you mentioed.

    Thank you.

    Regards

    Pashan

     

    Test_ECC.zip
  • 0 in reply to Pashan None
    TI__Guru**** 190616 points

    Hello Pashan,

      I will need to check with our nowECC developer and get back.

    regards,

    Charles

  • 0 in reply to Charles Tsai
    TI__Guru**** 190616 points

    Hello Pashan,

      Sorry for the delay. Your query on nowECC had been communicated to our nowECC developer.  I will suggest that you open a new forum post regarding nowECC checksum calculation for easier tracking.

    regards,

    Charles

  • 0 in reply to Charles Tsai
    TI__Genius 14205 points

    Hello Pashan,

    For ARM R4 devices running in big endian mode (Big Endian 32), the byte ordering is swapped to become:  MSB 7,6,5,4,3,2,1,0 LSB ->  4, 5, 6, 7, 0, 1, 2, 3.

    For e.g : If your 64 bit data is (MSB )0x07060504_03020100 (LSB), then after swapping the data will be 0x04050607_00010203.

    The ECC has to be calculated on the swapped data using the algorithm specified earlier. This is the ECC ordering expected by the ARM CPU running in BE32 mode. For ARM R4 CPUs running in little endian mode, no byte swapping is needed.

    Regards,

    Prathap

  • 0 in reply to Prathap
    Genius 5660 points

    Hello Prathap,

    I have attached a TEST CASE in the mail above [Test_ECC.zip] using NO_ADD option.

    Can you please let me know what is wrong with the test case?

    I am getting for 0x0000_0000_0000_0001 -- 0x6E as ECC -- not matching with Boolean Expression.

    I am getting for 0x0000_0000_0000_0002 -- 0x68 as ECC -- not matching with Boolean Expression.

    Thank you.

    Regards

    Pashan

     

  • 0 in reply to Pashan None
    Expert 1150 points
    I use the now ecc option is -f021 16M_ADD -o file_ecc.hex4 -r4
    I got the exact same result as yours
    and if follow his theory, ecc byte should be 0 if the 64bits data is 0x00000000
    I am struggling with the algorithm either.have you got any clue?
    leo