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.

AM57xx ECC function with DDR3

Hi,

I have some questions regarding ECC function of Am57xx processor.

1.I would like to know how to work the ECC function.If 8bit or 16bit write access occurs, how does AM57xx work wiht ECC function? For example,
 1. 32bit read
 2. 8 or 16 bit write
 3. ECC calculation
 4. 32bit write

Is the above sequence right?
 
2.If the above sequence is right, there is 1bit error when 32bit reading, how does AM57xx work?
3.If there is 2bit error when 32bit reading, how does AM57xx work?

4.When 32bit write access occurs, 32bit read access does not happen because all bits is changed. Is my understanding right?

5.If 1bit error is detected by ECC function when 32bit reading, Its data is modified by ECC,isn't it? and, is the modified data writebcked after modified data sended to CPU(or other Master)?

I appreciate your quick reply.

Best regards,

Michi

  • Hi,

    I will ask the DDR experts to help on this.
  • Michi Yama said:

    1.I would like to know how to work the ECC function.If 8bit or 16bit write access occurs, how does AM57xx work wiht ECC function? For example,
     1. 32bit read
     2. 8 or 16 bit write
     3. ECC calculation
     4. 32bit write

    Is the above sequence right?

    No this is not correct.  Please see Section 15.3.4.14 "Error Correction And Detection Feature" of the Technical Reference Manual.  In short, all writes must be quanta-sized and quanta-aligned, where a quanta is equal to the EMIF1 bus width.  Non quanta accesses will generate an interrupt:

    Quote:

    • If a write access with byte count that is not a multiple of ECC quanta or with a non quanta aligned address
      is performed within the address range protected by ECC, the EMIF will send out a write ECC error
      interrupt.

    Michi Yama said:
    3.If there is 2bit error when 32bit reading, how does AM57xx work?

    This is covered in the same section...

    Michi Yama said:
    4.When 32bit write access occurs, 32bit read access does not happen because all bits is changed. Is my understanding right?

    The EMIF (on this device) never performs a read-modify-write when told to a write.   The "read-modify-write" capability you describe is available on Keystone2 devices but not on AM57xx, and in that case the capability is configurable whether or not you want to use it.  This device requires all writes to be quanta-sized and quanta-aligned and this is specifically discussed in the chapter.

    Michi Yama said:
    5.If 1bit error is detected by ECC function when 32bit reading, Its data is modified by ECC,isn't it? and, is the modified data writebcked after modified data sended to CPU(or other Master)?

    Quote:

    • For 1-bit ECC error in the data, the EMIF will correct the data
      and send it on the SYS or MPU return interface.
    • In the event that the EMIF detects a single bit ECC error, although the error is corrected on the returned
      data, the data in the SDRAM is not corrected. It is the responsibility of the system software to correct the
      ECC error at that location.
  • Dear Brad-san,

    Thank you for your support.

    I would like to confirm your answer regarding question no.1.

    > In short, all writes must be quanta-sized and quanta-aligned, where a quanta is equal to the EMIF1 bus width.

    I have an eratta sheet(sprz429g). According to the i882 of the eratta sheet, only full quanta support is errata. So I think full quanta support only is eratta, not spec. Then I heard that this errata will be fixed in future revision. If my information is correct, 8bit, 16bit
    access can be used.

    Do you have any information about this?

    I appreciate your quick reply.

    Best regards,
    Michi
  • Michi-San,

    Sorry that is not correct. The errata says you need to perform quanta accesses to *the entire EMIF1* (protected and non protected).   Once it is fixed you will only have to perform quanta accesses to the protected part. Read-modify-write is definitely not planned for AM572x PG2.0.

    Best regards,

    Brad

  • Brad-san,

    Thank you for your reply.

    I would like to reconfirm your comment.

    > you will only have to perform quanta accesses to the protected part. Read-modify-write is definitely not planned for AM572x PG2.0.

    Do you mean 8,16, and 32 bit is accessible as quanta accesses. But "read-modify-write" does not happen.

    When 8 bit write:

    1. EMIF read 32 bit data

    2. EMIF writes 8 bit data

    3. EMIF calcurates ECC

    4. EMIF write 32 bit data

    Only 2 and 3 are executed. aren't they? Please advise me.


    I appreciate your quick reply.

    Best regards,

    Michi

     

     

     

  • No. A quanta is equal to the bus width. Assuming 32-bit wide EMIF1 a quanta is 32 bits. That means all accesses to protected memory in SR2.0 will need to be 32-bit wide and 32-bit aligned. Any 8-bit or 16-bit access will trigger an error interrupt.

    Note that any normal cacheable memory being used by the ARM will automatically satisfy these requirements as the cache controller always operates on entire cache lines.
  • Dear Brad-san,

    Thank you for your reply.

    I don't stll understand your answer. Please see the below.

    > No. A quanta is equal to the bus width. Assuming 32-bit wide EMIF1 a quanta is 32 bits. That means all accesses to protected memory in

    > SR2.0 will need to be 32-bit wide and 32-bit aligned. Any 8-bit or 16-bit access will trigger an error interrupt.

    A full quanta for 16bit data bus is 16bit. A sub-quanta for 16bit is 8bit.

    A full quanta for 32 bit data bus is 32 bit. A sub-quanta for 32bit ara 16bit and 8 bit.

    Is the above my understanding right?

    > Note that any normal cacheable memory being used by the ARM will automatically satisfy these requirements as the cache controller always

    > operates on entire cache lines.

    In case of 32 bit quanta, if 16bit write access occurs to ECC protected area by cache miss hit, is an error interrupt generated? I thought i882 will be

    fixed by next revision, and 8bit, 16 bit write access to ECC protected area will become possible.

    I am confused, Please advise me.

     

    Best regards,

    Michi

     

  • Michi Yama said:

    I would like to reconfirm your comment.

    > you will only have to perform quanta accesses to the protected part. Read-modify-write is definitely not planned for AM572x PG2.0.

    Do you mean 8,16, and 32 bit is accessible as quanta accesses. But "read-modify-write" does not happen.

    No.  Please revisit the definition of "quanta".

  • Let me paraphrase i882 to hopefully clarify for you one final time... The *intended* operation of the device is that EMIF1 has a protected region and a non-protected region. The protected region would require all accesses to be quanta sized and aligned. The non-protected region should allow any kind of access. The bug described in i882 is that you get a false error reported in-band for the case that a non-quanta access is performed to the NON PROTECTED space. The workaround is to perform quanta sized/aligned accesses to THE ENTIRE EMIF. We will fix this erroneous error reporting in SR2.0. That will allow you to define a non-protected space where there are no quanta restrictions.
  • Dear Brad-san,

    Thank you for your reply.

    I understood that the protected region would require all accesses to be quanta sized and alighned.

    However, is this specification no problem for software? For example, I am not expert for "OS",  does HLOS use only quanta access? 8, 16bit access does not occur in OS running? Please advise me.

     I appreciate your quick reply.

    Best regards,

    Michi  

  • It's hard to give any definitive guidance with respect to HLOS.  As a general point, just about all memory accesses to DDR being performed by HLOS are going to be cacheable.  The quanta rules are guaranteed to be followed for cacheable memory since all the cache controller requests will be a quanta multiple and quanta boundary.  I think more detailed analysis for any OS would be needed for any code performing non-cached accesses to DDR.  These are the areas where you would need to be careful.

    I'd like to also mention one other item that you may not have considered.  Specifically, you need to consider the case of other memory access initiators in the device.  For example, USB and Ethernet have "integrated DMA" that directly access buffers in memory.  You may run into quanta issues with these peripherals.  To avoid the issues you would either need to locate their buffers in EMIF2 or OCMC RAM.

  • Dear Brad-san,

    Thank you for you reply.

    I need more information for peripheral initiators.

    > For example, USB and Ethernet have "integrated DMA" that directly access buffers in memory.
    >You may run into quanta issues with these peripherals.

    You said, to use DMA acceess is workaround for peripheral to this ECC limitation( the access to DDR must be full quanta in protected ECC region). Is my understanding right?
    In case of the peripheral is initiator, is the cache coherency retained if DMA is used to DDR access? Is that full quanta access?

    Please advise me.

    I appreciate your quick reply.

    Best regards,

    Michi
  • Michi Yama said:
    You said, to use DMA acceess is workaround for peripheral to this ECC limitation( the access to DDR must be full quanta in protected ECC region). Is my understanding right?

    I said that DMA (like USB and Ethernet) can cause problems.  You may need to put the corresponding buffers on EMIF2 to avoid issues.