FPGA - 02 - Memory Tests

Hey everyone,

ZynqHW_2017_lab_3_v13.pdf

In lab 3 we will start discussing the other Zynq blocks in detail.

The lab starts with introducing the selection of boot device. The QSPI memory interface (Quad Serial Peripheral Interface) is a SPI (another asynchronous serial communication protocol) module which has a memory mapped register interface, which allows direct interface for accessing data from external SPI devices and thus simplifying software requirements. The bootup of the QSPI interface takes place in the order of the following finite state machine :

The UG585 manual states the following: In the I/O mode, the software can choose varying degrees of control by setting appropriate register bits to control different aspects of read data management. The Linear mode does all the necessary read management functions such as reading the ROM, to booting up the software. The Feedback clock which the lab manual instructs us to enable, is a memory interface clock that needs to be greater than 40 MHz. The feedback signal is received during the I/O state of the QSPI bootup sequence.

The next step was setting up the USB MIO pins. Followed by setting up the SD Card MIO pins. But wait a minute, I don't see any SD card slot ! The UG585 states that :

"Boot from SD Card: The BootROM expects the SD card to be connected to MIO pins 40 through 45 ". Thus, from what  I could conclude, there would be a "on board" memory unit (I highly suspect the Flash since it cannot be mapped by a EMIO) which consist of the bootloader and the Petalinux kernel. Sure enough with a little check :

2 bootloader partitions and a partition for the Petalinux? The answer would be unveiled in a later blog.

The lab talks further about setting each of the three PLLs and the math behind it. If you have no idea what one is, have a look at experiment 7 of an old road-test that I did : Analog System Lab Kit (STEM Product) - Review .

• ARM PLL: Recommended clock source for the CPUs and the interconnect
• DDR PLL: Recommended clock for the DDR DRAM controller and AXI_HP interfaces
• I/O PLL: Recommended clock for I/O peripherals

The lab says that the ARM PLL must be 1.33 GHz. This is because it gives the most ideal ratio between CPU performance and bandwidth across an interconnect. Thus this gives us the PLL feedback Divider Value to be 40 and CPU clock divider divisor value (no idea what this is) to be 2 . A similar justification could be said for DDR PLL too.

The controller and I/O interface is driven by the same QSPI reference clock. Hence , the 2 factor is required to divide the QSPI reference clock. The next step talks about configuring the SDIO clock. The SDIO controller  communicates with the SD memory card or any SDIO devices (have a look here https://en.wikipedia.org/wiki/Secure_Digital#SDIO_cards ) connected to the PS.

Later on in the manual , for the "Generate Output Products", we have been asked to change the synthesis option to Global instead from the default option - Out of context per IP. From what I could understand, a design checkpoint (DCP) is generated for each of the synthesized IPs and those called in the end by the synthesized top-level module or we can say here the DCPs are "Out Of Context (OOC)". The Global option synthesizes each of the IPs along with the synthesized top-level module. The manual UG896 claims that OOC is faster than the Global option. To me, I think there won't be much of a difference.

I won't talk much about the way the MiniZed has been programmed. One can look it up if needed. Also, one can tweak around with the generated code to see different results. For example, the core header file that Memory_tester revolves around is memory_config_g,c  This was a file generated from the hdf, which includes the peripheral name and memory units.

So that concludes my experiment for lab 3. One thing I would like to bring to the notice of any the people writing the manual for the Avnet.

FPGAs can be a bit daunting for anyone new to this field. A Zynq board is paving the way to the future, infact I am sure the new MPSoC - Versal (Based on the Ultrascale) would be a big stepping stone for the FPGA industry. My suggestions is to keep a clear objective when writing manuals. Either they should explain well or they should just keep the steps as minimal as possible. To understand this entire manual took me two whole days and I had to keep on referring  to the UG manuals for the poor explanation given for each step in the lab. So yes, I would say cut on the text, major time and keep a few concise steps with some pictures.

And with that food for thought, until next time element14!

Tomfoolery

So like the title suggest I would try some modifications in the program :

Firstly what happens if we try to test the memory unit ps_ram_0 which is being used to store the application ?

The program just stalls. Well self apparent explanation .

PS NOTE : Don't play around with this too much, my board got really hot when I left this program running for 15 minutes!

Secondly what happens if we extend the test range of ps_ram_1 to the end of the address space (here 0xFFFF_FFFF)?

It works perfectly fine. I have added the modified code to my git repo, here : My PTP repo