How can I validate the DDR interface on my newely designed board based on ADSP-SC58x/ADSP-2158x processors?

Before starting application development on a newly designed board with ADSP-SC58x/ADSP-2158x processors along with DDR3/DDR2/LPDDR memory interface, it is very important to make sure that there are no basic issues with the DMC(Dynamic Memory Controller) interface itself. The following steps can be followed to validate the DMC interface on ADSP-SC58x/ADSP-2158x processors:

• Preparing the CGU/DMC initialization code:  The first step is to make sure that one has the right CGU and DMC initialization code available customized for the specific clock requirements and the DDR memory device being used. The application note EE-387 provides the necessary guidance along with subroutines for CGU and DMC initialization (CGUInit.c/h and DMCInit.c/h files). These routines can be used for any customized CGU/DMC settings by passing the right parameters. The code examples DDR3_Init_Core1/DDR2_Init_Core1/LPDDR_Init_Core1 show how to do that. For more details, refer “DMC Initialization Code” section of the EE-387. It can be found at the link below:

          http://www.analog.com/en/search.html?q=EE-387

• Validating the DMC interface: The simplest way to validate the DMC interface could be to run the whole test residing in the L1 memory of one of the SHARC cores. By default, the ARM core enables the SHARC core but the ARM code resides in the DMC interface.  To bypass loading the code in the ARM core, one can set the bit 19 of the RCU0_MSG_SET register via emulator which would allow to execute the code directly on the SHARC core (see the screenshot below).

          EE-387 provides the files “DMCInit_Debug.c/h” which contain function “Memory_Sweep_Test()” to test both the core and DMA (MDMA)           accesses to the DDR device for various data patterns and memory widths (8/16/32/64 bits). It also contains the function to print the           programmed values of the DMC registers which can be used to cross verify whether the programmed values are indeed correct. For           more details, refer “Validating the DMC Interface “section of EE-387.

• Stress testing the DMC interface:

1. 1. Testing across clock frequencies: In order to make sure that the memory sweep test provided with EE-387 works across frequencies (CCLK/SYSCLK/DCLK etc.), one can make appropriate modifications to the CGUInit() function in the “main.c” file of the DDR test code.
   2. Testing with other DMC running in the background: In case the system makes use of both the DMCs, one can stress the DMC interface more by running another DMC in background by making little modification to the test code supplied with EE-387. The attached code “DDR3_Init_Core1_Dual_DMCs.zip” shows how to do that.

• Creating customized preload and init codes: In most applications, the CGU and DMC initialization is only done once after the power up. This can be done with the help of “preload” code (when loading the application via emulator) or “init” code (when loading the application via booting). The CCES installation provides the “preload” and “init” code sources and dxes for the default CGU/DMC settings which can be modified as per the customized system requirements. EE-387 also discusses how to do this. For more details, refer “Creating Preload and Initialization Code with Customized CGU and DMC Settings” section of EE-387.