Zedboard How to control DDR read/write from PL end (v)

With the front of a pile of bedding. Now it's time to formally prepare to read and write DDR, development environment: VIVADO2014.2 + SDK.

　　First, in the PL end to control the DDR through AXI, we must have a Axi master, because it is a test, do not write their own, directly with the package IP generated, the method is as follows:

1. Select the Package IP tool

　　

2. Create a new Axi peripheral

　　

3. Interface type Select full, mode Select Master, if you do not care about the detailed implementation of the process, then the direct finish is good. (We'll continue to analyze the process later)

　　

　　

　　Second, the creation of IP, naturally to add to the IP library, in the IP catalog blank right-click, set, the path has just generated IP to put in:

　　

　　Third, the next create BD block, the entire hardware system to build:

　　

It should be noted that, since we need to use HP, so in the ZYNQ configuration of the HP tick, select a channel on the line

　　

Four, then verify the correctness, produce output file, create BD block top layer, this is the routine, all the way down the line. If you want to see the AXI signal generated in the debug, you need to mark the Axi with debug

Five, synthesis, set up debug, and then generate a bitstream, and import it into the SDK, the SDK to run a Hello world, the main purpose is to use the CPU to initialize the DDR controller.

Here the whole process is almost over, then look at the simulation waveform:

　　

Zoom in a bit, you can see the step length of each address is a decimal 64, this is because our burst length is set to 16, the bit width is 32bit.

But here's the problem, as we said in the previous section that some of the addresses are connected to the OCM, so how much is this part of the address? The following instructions are given in the UG585:

　　

We started writing data from all 0 addresses, but all 0 of the addresses were assigned to OCM, which was awkward. Do you want the program to run for a bit longer at first so that the address can run to 0x0008_0000? But it didn't work, because the address only ran to 00001000 and stopped,

　　

Remember when you packaged the Axi IP before we said we were going to analyze the process? In fact, there has been dug a hole, specifically see the code:

This is Axi's write Data state machine, (you can see, the official is also using a section of state machine to achieve the entire timing, confirmed that the previous three-segment state machine bad implementation of the argument), from the write state to read the state of the jump is controlled by the writes_done signal, then this Writes_ How did it come about? Continue to see the code:

　　

Writes_done is controlled by the high carry of the write_burst_counter, and then continues to find Write_burst_counter:

　　

In this counter there is a very critical bit c_no_bursts_req, in the code of the low 179 lines, it is defined as follows:

Localparam integer C_no_bursts_req = C_master_length-clogb2 ((c_m_axi_burst_len*c_m_axi_data_width/8)-1);

　　

C_m_axi_burst_len we set the 16,c_m_axi_data_width is 32,CLOGB2 can be understood to calculate the logarithm of a number at the base of 2, then the last obtained c_no_bursts_req = 6; that is to say Write_ The bit width of the burst_counter is 7, and when the highest bit is 1 o'clock, the write data is stopped. That is, only 64 write data will occur, and then the counter and the write address will be zeroed. Then 64 times the write data multiplied by each burst length 16 multiplied by the bit width 4 bytes, finally obtained the value is 1024, translates into 16 the system just is 0x00001000.
So to really write the data in the DDR, we also need to modify the code. 
It's not too far from here to succeed.

Zedboard How to control DDR read/write from PL end (v)