Design Article
Book excerpt: SRAM and SDRAM controllers for FPGAs, part 3
8/31/2012 10:26 AM EDT
16.8.2 Testing software
The testing program basically writes data to the SRAM and SDRAM modules and then reads it back to check errors. Since the content of the SRAM and SDRAM devices will be destroyed during the process, the testing program must be placed in the on-chip memory module. The BSP configuration and the program code are discussed in the following subsections.
BSP setting We must adjust the BSP setting to accommodate two special requirements of this application:
When the final software image (i.e., the .elf file) is generated, it is divided into several sections (for code text, stack, heap, etc.). We can specify the locations of these sections in BSP. The procedure is
This procedure puts the software image in the on-chip memory and frees the SRAM and SDRAM modules for testing.

The 16-KB size of on-chip memory is fairly small. To accommodate its limited capacity, we must reduce the footprint of the software image. This can be done by enabling certain options in BSP Editor to use the smaller drivers and library functions. The procedure is discussed in the end of Section 12.2.3. We can follow the procedure in Section 10.3.5 to check the size of the software image and it shows that the footprint of the testing program in Listing 16.4 is about 8 KB.
Testing program We can verify the operation of a memory module by first writing data to the module and then reading it back to check errors. A function, check_mem (), is constructed for this purpose. Its arguments are mem_base, min, and max, which specify the base address of the memory module and the lower and upper offsets of the intended test region. The function is shown in Listing 16.3.

In the function, we treat the designated region as a 32-bit word array and cast the pointer to the beginning of the array, phase, to mem_base. The ith element of the array is filled with i/\t_pattn, where t_pattn is a 32-bit toggling pattern. If a bit of t_pattn is 1, the corresponding bit of i is inverted after the xor operation. For verification purposes, we also deliberately inject four errors in the end and these errors should be detected while the array is read back.
The main program is shown in Listing 16.4. It calls the check_mem() function to check the entire memory range.

Since the memory contents are overwritten during the memory test, the testing program must reside on a separate memory module. We include an embedded on-chip module in the Nios II system for this purpose.
16.9 BIBLIOGRAPHIC NOTES
The detailed specification of the DEl board's SRAM and SDRAM can be found in the ISS/IS61LV25616 data sheet and ICSI IS42S16400 data sheet, which are included in the DEl board distribution CD. The SDRAM data sheets from Micron Technology provide a better explanation for the SDRAM operation and timing and can be found on its website. A text, titled Memory Systems: Cache, DRAM, Disk by B. Jacob et al., has a detailed discussion of the SRAM and SDRAM operation and organization. The use of the SOPC's SDRAM controller core is covered in Chapter 1, titled SDRAM Controller Core, of Embedded Peripherals IP User Guide. An example is provided at the end of the chapter to demonstrate the calculation of SDRAM clock's phase shift.
The general I/O timing consideration of Altera FPGA is discussed in Application note 336, titled Understanding I/O Output Timing for Altern Devices. The use of the SOPC's PLL core is covered in Chapter 36, titled PLL Cores, of Embedded Peripherals IP User Guide. The configuration of PLL is documented separately in Phase-Locked Loop (ALTPLL) Megafunction User Guide and the specification of Cyclone II PLL is covered in Cyclone II Device Handbook.
The testing program basically writes data to the SRAM and SDRAM modules and then reads it back to check errors. Since the content of the SRAM and SDRAM devices will be destroyed during the process, the testing program must be placed in the on-chip memory module. The BSP configuration and the program code are discussed in the following subsections.
BSP setting We must adjust the BSP setting to accommodate two special requirements of this application:
- The testing code must be located in the on-chip memory module.
- The code size must be small enough to be stored in the on-chip memory module.
When the final software image (i.e., the .elf file) is generated, it is divided into several sections (for code text, stack, heap, etc.). We can specify the locations of these sections in BSP. The procedure is
- Invoke Nios II BSP Editor.
- Select the Linker Script tab page. The Linker Section Mappings panel is displayed on the top, as shown in Figure 16.19. Eight sections are included.
- Select the .bss section (the first row). Click the Linker Region Name column and a pull-down menu of three memory modules (i.e., onchip_mem, sram, and sdram) appears. Select the onchip_mem module.
- Repeat the process for the other sections.
- Click the Generate button on the bottom.
This procedure puts the software image in the on-chip memory and frees the SRAM and SDRAM modules for testing.

Click image to enlarge
Figure 16.19: BSP Editor Linker Script tab page.
The 16-KB size of on-chip memory is fairly small. To accommodate its limited capacity, we must reduce the footprint of the software image. This can be done by enabling certain options in BSP Editor to use the smaller drivers and library functions. The procedure is discussed in the end of Section 12.2.3. We can follow the procedure in Section 10.3.5 to check the size of the software image and it shows that the footprint of the testing program in Listing 16.4 is about 8 KB.
Testing program We can verify the operation of a memory module by first writing data to the module and then reading it back to check errors. A function, check_mem (), is constructed for this purpose. Its arguments are mem_base, min, and max, which specify the base address of the memory module and the lower and upper offsets of the intended test region. The function is shown in Listing 16.3.
Listing 16.3

Click image to enlarge
In the function, we treat the designated region as a 32-bit word array and cast the pointer to the beginning of the array, phase, to mem_base. The ith element of the array is filled with i/\t_pattn, where t_pattn is a 32-bit toggling pattern. If a bit of t_pattn is 1, the corresponding bit of i is inverted after the xor operation. For verification purposes, we also deliberately inject four errors in the end and these errors should be detected while the array is read back.
The main program is shown in Listing 16.4. It calls the check_mem() function to check the entire memory range.
Listing 16.4

Click image to enlarge.
16.9 BIBLIOGRAPHIC NOTES
The detailed specification of the DEl board's SRAM and SDRAM can be found in the ISS/IS61LV25616 data sheet and ICSI IS42S16400 data sheet, which are included in the DEl board distribution CD. The SDRAM data sheets from Micron Technology provide a better explanation for the SDRAM operation and timing and can be found on its website. A text, titled Memory Systems: Cache, DRAM, Disk by B. Jacob et al., has a detailed discussion of the SRAM and SDRAM operation and organization. The use of the SOPC's SDRAM controller core is covered in Chapter 1, titled SDRAM Controller Core, of Embedded Peripherals IP User Guide. An example is provided at the end of the chapter to demonstrate the calculation of SDRAM clock's phase shift.
The general I/O timing consideration of Altera FPGA is discussed in Application note 336, titled Understanding I/O Output Timing for Altern Devices. The use of the SOPC's PLL core is covered in Chapter 36, titled PLL Cores, of Embedded Peripherals IP User Guide. The configuration of PLL is documented separately in Phase-Locked Loop (ALTPLL) Megafunction User Guide and the specification of Cyclone II PLL is covered in Cyclone II Device Handbook.
Navigate to related information

