AM6546: Enable CA parity on the DD4 SDRAM

Hi Johnny, sorry for delayed reply.

There are several TMG registers which would change when enabling CA parity.  Can you provide your with/without parity enabled config files from the tool so i can do a diff.  Just want to make sure all of the parameters with additive PL are correct

Also, have you tried initializing with CA parity disabled, then enabling it after training.  Maybe there is some inadvertent error propagating.   

Regards,

James

Hi James, thanks for your reply.

Attached are the configuration files with/without parity enabled.

We have also tried to activate parity after training, and it looks pretty much like if we do it before training (writing and reading back from memory just gives us garbage).

We use Board_DDRInit from the TI RTOS PDK (8.0.0.36) when doing the initialization.

Regards Johnny

Enable parity:

    /* DDR Mode Register 5 */
    HW_WR_DDRPHY_REG32(CSL_EMIF_PHYCFG_MR5_DDR4,
                 DDRPHY_MR5 | 0x00000001);

    /* DDR Mode Register 5. Enable parity (C/A Parity Latency=1=4). */
    HW_WR_REG32((CSL_DDRSS0_CTL_CFG_BASE + CSL_EMIF_CTLCFG_MRCTRL1),
                 DDRPHY_MR5 | 0x00000001);

    /* Write DDR Mode Register 5. */
    regValue = HW_RD_REG32(CSL_DDRSS0_CTL_CFG_BASE + CSL_EMIF_CTLCFG_MRCTRL0);
    regValue |= 0x80005000;
    HW_WR_REG32((CSL_DDRSS0_CTL_CFG_BASE + CSL_EMIF_CTLCFG_MRCTRL0),
                 regValue);

board_ddr_config_no_parity.h

board_ddr_config_parity.h

Hi Johnny,

still not quite sure why this is not working.   I did find the following in the documentation, that you also have to update the INIT6.MR5 registers so it is aligned with the SDRAM reg:

If any part of the SDRAM’s MR register is updated by software, it is also the responsibility of the software to
update corresponding INIT*.*mr* so that it is aligned to the SDRAM’s MR register. For DDR4, INIT*
registers are used to control some run-time functionality (such as CA parity), and for automatic mode
register accesses.

See it this makes a difference.

Regards,

James

Hi James,

It was not possible to update the INIT6.MR5 register after training (static register?). We have tested with C/A Parity Latency disabled (0x480) and C/A Parity Latency = 4 (0x481) in the INIT6.MR5 register in initialization with the same result (writing and reading back from memory just gives us garbage).

Regards Johnny

Johnny, INIT6 is what's called a quasi dynamic register which requires SWCTL.sw_done=0 to be able to write to.  This may be why the write is not working.  Then set SWCTL.sw_done back to 1 to complete the write.

Regards,

James

Thanks James, I manage to set INIT6.MR5 after initialization, but the result is the same (writing and reading back from memory just gives us garbage).

Regards Johnny

Thanks Johnny, still not sure why you are having issues with this.  Let me ask some exploratory questions, some of which might be basic, but just for completeness:

-can you try clearing the CA parity error status in MR5 before enabling CA parity.  This is to ensure no errors are registers before enabling it

-Can you probe the PAR signal to see if it is at least toggling?  If you employ VTT termination, is PAR VTT terminated?

-Do you see an error?  Either by reading MR5[4] or by probing ALERT_n?

-Do you have any unused address signals on the DRAM?

-Do you have persistent mode enabled in MR5[9]?  My understanding is that if this is disabled, you would only get one error, and the DRAM will proceed to operate normally (without checking for CA parity)

-based on your reg dumps, you have crc_parity_retry_enable=0, so my expectation is that if there is an error received, the controller will not attempt to retry sending the command.  So, i think this is a proper setting for now, at least until we debug this

-to try to narrow down a read or write problem, an experiment to try may be to write a small block of memory with parity enabled, turn off parity, and then try to read that block.  Similarly, write the block with ca parity disabled, then try to read with ca parity enabled.   

Depending on some of the results above, there might be something wrong with the latency adjustments when ca parity is enabled.

Regards,

james

Hi James

We clear the CA parity error status in MR5 before enabling CA parity.

We have examined the PAR signal and it is toggling. PAR is VTT terminated (termination resistance 39.2 ohms)

We cannot see any errors either by reading MR5[4] or by examining ALERT_n.

All the address signals on the DRAM are connected.

We have tested both with persistent mode enabled and disabled in MR5[9].

Test

Parity disabled:

mem write address: 0x80000100 value: 0x87654321

mem read address: 0x80000100 value: 0x87654321

Parity enabled:

mem read address: 0x80000100 value: 0xffffff00

mem write address: 0x80000100 value: 0x12345678

mem read address: 0x80000100 value: 0xffffff00

Parity disabled:

mem read address: 0x80000100 value: 0x87654321

Regards

Johnny

Johnny, since you are not getting any parity errors, it seems like there is a problem with the latency timings, and i think i know where the problem is.  The databook mentions this:

For DDR4: RL= CL+AL+PL; WL= CWL+AL+PL

But I'm noticing the spreadsheet doesn't account for the +PL wherever RL or WL is used in the timing registers.  For example, DRAMTMG2 defines WL, but the spreadsheet does not add in +PL (based on a diff of the files you sent).  

I did a quick search and WL and RL are used in formulas in DRAMTMG0/1/2.  Would need to ensure each of these parameters are increased by 2 (PL=4, but because of the 1:2 frequency ratio mode, it would only need to be a +2 for the parameter value) whereever RL or WL are used in the formulas for that bit field.

Regards,

James

I tried to update those registers, but it still does not work.

I have also tried enabling CA Parity on the AM65x Industrial Development Kit (TMDX654IDKEVM) that I have with the same result. Should the CA parity work with the development kit? And if so, is it possible to have the configuration?

Regards

Johnny

Johnny, can you send the full configuration file with your final edits so I can do a diff with the other files sent earlier

My expectation is that this also should work on the IDK, but I don’t think we ever enabled it on that board to my knowledge

thanks,

James

Hi James,

attached is my latest configuration file.

Regards

Johnny

board_ddr_config.h

Johnny, thanks.

Just a warning that i will be out of the office for the next 2 weeks and won't have a chance to look at this until after i get back.  Let me know if this is acceptable. 

My impression so far is that this is not a bug and that i just need to work on the proper latency timings or some other configuration issue.  I am not aware of any bug or errata associated with this.

Is CA parity a requirement for your product?  Can you make progress without it at least for the next couple of weeks?

Regards,

James   

Hi James,

CA parity is a requirement for our safety product. The project will not stop if we wait a couple of weeks, but a solution to the problem as soon as possible is appreciated.

Regards

Johnny

Greetings Johnny,

James will be out for a couple of weeks and we require his input to make progress on this issue. 

Thank you for your patience and understanding.

Sincerely,

Lucas