MiZ702 Learning notes 13--zynq interacting with PL via Axi-lite

In the MIZ702 study notes 7--try homemade with bus IP, I mentioned the simple usage of axi4-lite, driving the next running lights, only involved in the write bus. Today, I want to use the previous VGA module, the Axi4-lite read and write are applied. This article is mainly about the introduction of ideas, as well as the method of Axi4-lite reading. Some details please read the MIZ702 study note 7--try homemade with bus IP.

The specific idea is shown in the following diagram:

So this time, we need two axi4-lite bus, one is responsible for the VGA module to provide RGB data (write), a read the VGA module provides scanning coordinates information (read).

By clicking the plus sign, you can add an additional Axi4-lite bus to us:

So we can see two sets of bus frames in our IP project:

This looks like when IP is packaged:

We will S00 this bus as write data, and will use S01 as the reading bus. Of course a bus is both readable and can be written, but VGA this project decided to read and write must be peer-to-non-reusable.

The others are the same as they were before, and the next axi4-lite read and write. PL in order to communicate with PS, it needs some logic to support. And these are the logic that, when we generate the Axi4-lite IP, Vivado automatically generates it for us. We have little to do, just need to add some content, just like the MiZ702 study note 7--Try homemade with the bus IP mentioned.

In this project, for the bus is to write to the VGA module to send RGB data, "write" We just need to add their own logic to:

reg [11:0]rlcd_rgb;

Always @ (Posedge s_axi_aclk)

Begin

if (S_axi_aresetn = = 1 ' b0)

Begin

Rlcd_rgb <= ' D0;

End

Else

Begin

Rlcd_rgb <= s_axi_wdata[11:0];

End

End

Assign Lcd_rgb = Rlcd_rgb;

For the bus to read, we need to make a slight change to the framework:

Write Bus test modification!!!!!!!!!

wire[31:0]wlcd_xy;//= {ten ' d0,lcd_xy};

Assign Wlcd_xy = {ten ' d0,lcd_xy};

Assign Slv_reg_rden = Axi_arready & S_axi_arvalid & ~axi_rvalid;

Always @ (*)

Begin

Address Decoding for reading registers

Case (AXI_ARADDR[ADDR_LSB+OPT_MEM_ADDR_BITS:ADDR_LSB])

2 ' h0:reg_data_out <= wlcd_xy;//slv_reg0;

2 ' h1:reg_data_out <= slv_reg1;

2 ' h2:reg_data_out <= slv_reg2;

2 ' h3:reg_data_out <= slv_reg3;

Default:reg_data_out <= 0;

Endcase

End

Here in fact, also changed a place, originally was Reg_data_out <= slv_reg0; I changed it to Reg_data_out <= wlcd_xy so that the value of Wlcd_xy can be read through the bus.

In return to this frame diagram:

Here, our Axi IP has the ability to interact with ZYNQ and VGA, it is the bridge between PS and PL, now we are only a VGA IP, and this IP is a common IP, yes, "MiZ702 study notes 12--encapsulation of a common VGA IP," said , we will modify the program slightly, in the IP packaging, we can get.

Finally, we add these IP, respectively, to complete the hardware to build the connection. Actually, I'll mention some details.

We configure the output clock for the ZNYQ:

Where FCLK0 general add Zynq kernel is the default, here is mainly to axi4-lite IP to provide clock, size I set is 250M, and then prompt error.

FCLK1 set it to 25M, mainly to the VGA IP to provide the clock, should be VGA scan is 25M.

Once the hardware platform is ready, you can start programming the SDK. First of all, we have to access to the Axi4-lite IP according to the address, through the Xparameter.h this header file can be learned S00 this bus address:

/* Definitions for driver Myvgaip */

#define Xpar_myvgaip_num_instances 1

/* Definitions for peripheral myvgaip_0 */

#define xpar_myvgaip_0_device_id 0

#define Xpar_myvgaip_0_s00_axi_baseaddr 0x43c00000

#define Xpar_myvgaip_0_s00_axi_highaddr 0X43C0FFFF

But the header file does not see S01 the address of the bus, but it can be assumed that the S00 bus broadband is 32-bit, and the first address is 0x43c00000, then if the address is a continuous bus S01 the first address should be 0x43c1ffff.

By looking at SYSTEM.HDF, you can be sure that the above assumptions are correct:

It is then defined as follows:

#define Rgb_axi_baseaddr 0x43c00000

#define Lcdxy_axi_baseaddr 0x43c10000

First, the color bar test, first through the XIL_IN32, this function read the bus, the VGA module output coordinate values. Where the lower 11 bits are the y-coordinate values, the high 11 bits are the x-coordinate values:

temp = Xil_in32 (LCDXY_AXI_BASEADDR);

Lcd_ypos = temp & 0x7ff;

Lcd_xpos = (temp>>11) & 0x7ff;

You can test the horizontal color bar:

Horizontal color Bar

if (lcd_ypos >= 0 && Lcd_ypos < (V_DISP/8) *)

Xil_out32 (RGB_AXI_BASEADDR, RED);

Else if (Lcd_ypos >= (V_DISP/8) * && Lcd_ypos < (V_DISP/8) *)

Xil_out32 (RGB_AXI_BASEADDR, GREEN);

Else if (Lcd_ypos >= (V_DISP/8) * && Lcd_ypos < (V_DISP/8))

Xil_out32 (RGB_AXI_BASEADDR, BLUE);

Else if (Lcd_ypos >= (V_DISP/8) && Lcd_ypos < (V_DISP/8))

Xil_out32 (rgb_axi_baseaddr, white);

Else if (Lcd_ypos >= (V_DISP/8) && Lcd_ypos < (V_DISP/8)

Xil_out32 (RGB_AXI_BASEADDR, BLACK);

Else if (Lcd_ypos >= (V_DISP/8) && Lcd_ypos < (V_DISP/8) *6)

Xil_out32 (RGB_AXI_BASEADDR, YELLOW);

Else if (Lcd_ypos >= (V_DISP/8) *6 && Lcd_ypos < (V_DISP/8) *7)

Xil_out32 (RGB_AXI_BASEADDR, CYAN);

Else if (Lcd_ypos >= (V_DISP/8) *7 && Lcd_ypos < (V_DISP/8) *8)

Xil_out32 (RGB_AXI_BASEADDR, ROYAL);

The results are as perfect as imagined.

Next test, bus color bar:

There's a problem with vertical scanning,

if (lcd_xpos >= 0 && Lcd_xpos < (H_DISP/8) *)

Xil_out32 (RGB_AXI_BASEADDR, RED);

Else if (Lcd_xpos >= (H_DISP/8) * && Lcd_xpos < (H_DISP/8) *)

Xil_out32 (RGB_AXI_BASEADDR, GREEN);

Else if (lcd_xpos >= (H_DISP/8) * && Lcd_xpos < (H_DISP/8))

Xil_out32 (RGB_AXI_BASEADDR, BLUE);

Else if (Lcd_xpos >= (H_DISP/8) && Lcd_xpos < (H_DISP/8))

Xil_out32 (rgb_axi_baseaddr, white);

Else if (Lcd_xpos >= (H_DISP/8) && Lcd_xpos < (H_DISP/8)

Xil_out32 (RGB_AXI_BASEADDR, BLACK);

Else if (Lcd_xpos >= (H_DISP/8) && Lcd_xpos < (H_DISP/8) *6)

Xil_out32 (RGB_AXI_BASEADDR, YELLOW);

Else if (Lcd_xpos >= (H_DISP/8) *6 && Lcd_xpos < (H_DISP/8) *7)

Xil_out32 (RGB_AXI_BASEADDR, CYAN);

Else

Xil_out32 (RGB_AXI_BASEADDR, ROYAL);

The result is not as perfect as it should be:

We find that the edges of the color bars are jagged, why? The reason is that the horizontal color bar scanning is based on the value of Lcd_ypos, longitudinal color bar scanning is based on Lcd_xpos. The VGA scan is a horizontal scan, which means that X's update frequency is n times the y update frequency.

That is to say, Axi4-lite Read and write speed with the Lcd_ypos change, but did not fully follow the Lcd_xpos value.

Some readers may want to ask, before the Axi4-lite IP to provide a 250M clock, and VGA scanning is 25M, how can speed not keep up?

This can only be said that Axi4-lite itself, is not suitable for a large number of transmission of data this matter. Axi4-lite is only suitable for doing some simple IO control, configuration register with.

Remember when you chose the bus type?

We chose Lite, but there are other types of options, such as: AXI4, and Axistream types. These are our next tasks.

Recently, Luffy opened 4, it is too handsome, my ultimate purpose is to show him on the VGA, but the first choice of the wrong bus type, can only be looked at:

Summarize:

Although the final result is not successful, but the process can still learn a lot of things, here is a good example of the advantages of ZYNQ:

1, using the PL part to drive VGA, fully play the advantages of FPGA. For PS share of the not small task.

2, the use of PS to complete the provision of data, data convenient storage, and more changeable, just make up for the shortcomings of the FPGA.

In the next tutorial, we will start to explore AXI4 and Axistream, will improve the sub-project, it is here. Dongguan today actually snow, do not say to take the hair dryer to warm up. Go home tomorrow, wish me bon voyage ~ ~

Project documents, will be uploaded later ~ ~ ~

MiZ702 Learning notes 13--zynq interacting with PL via Axi-lite