DDR Code Preview

DDR Tool generates source code which can be incorporated into an application to initialize the DDR subsystem. The source code uses an array-based format and is generated after validation on target is finished.

Note: Changing DDR frequency in DDR View will generate code for the desired frequency, but the DDR clock initialization must be handled by user application - i.e. DDR PLL must be configured for same frequency.
  1. Configure DDR controller from DDR View
  2. Select Connection type and configure parameters
  3. Select test, e.g. Firmware Init test
  4. Click on Start Validation
  5. Wait until execution finishes
  6. The generated code is shown in the Code Preview tab on the right window. It displays all generated files, each in its own tab
Figure 1. DDR Generated Files

Generated Files:

Init Firmware and Operational tests

  • ddr_init.c – main source file and the entry point of ddr initialization. The method which needs to be called from the user application in order to initialize the DDR subsystem is ddr_init(). It configures the DDRC controller based on the selected UI values from DDR View and executes the PHY training algorithm
    Figure 2. ddr_init.c file
  • ddr_init.h – main header file, contains method prototypes and global variable definitions
  • dq_swap_cfg.c – contains DQ swapping options, generated based on selection from UI
    Figure 3. DDR DQ Swapping
  • phy_cfg.c – contains phy module initialization sequence, based on the selected parameters from UI
  • pie_cfg.c – contains PIE initialization sequence
  • ddrss_cfg.c – initializes global data structure used in ddr_init() method
  • ddrc_cfg.c – DDRC controller initialization sequence, generated based on selected values in UI (e.g. Clock Cycle Freq (MHz))
  • imem_cfg.c – IMEM initialization sequence, covering both training stages:
    • struct uint16_t imem_1d[]; - mandatory
    • struct uint16_t imem_2d[]; - optional, depending on the selected Train 2D option
  • dmem_cfg.c – DMEM initialization sequence:
    • struct uint16_t dmem_1d[]; - mandatory
    • struct uint16_t dmem_2d[]; - optional, depending on the selected Train 2D option
  • io.h – io access utility methods
  • ddr_utils.c – utility methods used by the phy training algorithm
  • ddr_utils.h – utility methods header file
  • ddr_lp.c – low power utility methods for transitioning the DDR subsystem from normal more to low power (and back); see more details in Low Power section below.
  • ddr_lp.h – low power utility methods leader file
  • ddr_lp_csr.c – list of registers which need to be stored/restored while transitioning the DDR system
  • ddr_poll.c – contains an example of polling method which must be periodically called from user application in case Auto Derating Erata option is enabled. The method will revert changes made by errata workaround if they are no longer needed.
A subset of the files above is dynamically generated based on output log file obtained from the target. If the log file is missing, a custom message is displayed, and code generation is stopped.
Figure 4. DDR Log file not found

Read Margin and Write Margin tests

  • ddr_diag_rx.h – ASCII representation comment and C structures populated with parameters of interest for each read diag eye matrix
  • ddr_diag_tx.h – ASCII representation comment and C structures populated with parameters of interest for each write diag eye matrix
Figure 5. DDR Diag Codegen
Any of the Shmoo scenarios will display results but will not generate initialization code in Code Preview. A custom message is displayed instead:
Figure 6. DDR Shmoo Codegen

Low Power Support

DDR Tool generated code provides reference code to transition the DDR subsystem from normal mode to low power mode (retention mode) as well as the other way around. Low power related methods can be found in:
  • ddr_lp.h, ddr_lp.c
    • utility methods for storing and loading configuration registers to / from a given address
    • ddr subsystem transitioning methods: ddrss_to_io_retention_mode and ddrss_to_normal_mode
  • ddr_csr_lp.c
    • the list with registers which need to be stored / restored
    • generated dynamically, based on the memory type
Note: Configuration registers are not stored by default when executing DDR training. In order to enable this feature, STORE_CSR_ENABLE symbol must be defined. This can be done by uncommenting it in ddr_utils.h file or by defining the symbol in the project settings when integrating the generated code in a custom application.
Figure 7. Uncomment symbol to enable low power support
Note: By default, the configuration registers are stored at the beginning of standby RAM. To use a different address, the value of RETENTION_ADDR can be changed in ddr_utils.h file
Figure 8. Default address when registers are stored
Note: Standby RAM initialization must be configured within the user application, it’s not handled by the tool’s generated code.

Code Format

Code Preview content varies depending on the user’s selection in Code Format option.
  • U-boot - default code format used by DDR Tool, compliant with U-boot coding style guidelines (such as indentation, use of tabs and newlines, character limit, etc).
    Figure 9. Code section in U-boot format
  • MISRA - Generated code is compliant with MISRA-C 2012 coding standard, with a limited list of exceptions (deviations) which are documented in the files they occur in.
    Figure 10. MISRA deviations section
    Figure 11. Code section in MISRA format
  • ATF - Generated code is compliant with Arm Trusted Firmware specifications and standards. The format is similar to the U-boot one but uses different API for memory read/write accesses.
    Figure 12. Code section in ATF format
Note: In case any error occurs while applying a specific format, the tool will revert to the default one and generate all the files in U-boot coding style. In such cases, a warning icon will be displayed, clicking on it will display more details:
Figure 13. MISRA format conversion warnings