UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Scholar ronnywebers
Scholar
689 Views
Registered: ‎10-10-2014

MPSoC VIP example : write_data and read_data are always 4 bursts - is this expected behaviour?

I'm running the MPSoC VIP example in Vivado 2018.2

When I check the waveforms, I can see that a 32-bit write and read occur like 4 bursts. Is this expected behaviour?

i.e. here's a screenshot of the AXI GPIO where 0xFFFF.FFFF is written to reg0, to set the outputs high. However as far as my AXI knowledge goes, looking at the waveforms, the same data is written to the addresses of reg1, reg2, and reg3 of the AXI GPIO, which seems unwanted to me (?). Can this burst write turned off?

write burst.png

 

the code from the testbench looks like this (1 added 1 read before writing to the GPIO pins) :

        // first read the reg
        tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.read_data(32'hA0000000,4, read_data, resp);
tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.write_data(32'hA0000000,4, 32'hFFFFFFFF, resp); tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.read_data(32'hA0000000,4, read_data, resp);

same goes for a read, it looks to me like these are 4 bursts?

read burst.png

** kudo if the answer was helpful. Accept as solution if your question is answered **
12 Replies
Scholar ronnywebers
Scholar
653 Views
Registered: ‎10-10-2014

Re: MPSoC VIP example : write_data and read_data are always 4 bursts - is this expected behaviour?

additional info : the number of bursts depends on the last 4 bit of the address : 

  • when writing on offset 0x00 : 4 bursts
  • when writing on offset 0x04 : 3 bursts
  • when writing on offset 0x08 : 2 bursts
  • when writing on offset 0x0C : 1 'burst'

then on 0x10, the above repeats (4-3-2-1) and so on

I'm thinking this is because the M_AXI bus is configured to be 128-bit wide ... but that would mean that I always need to write 128-bit at once, and I cannot address a single register on offset '0x00' ... that would be strange ...

** kudo if the answer was helpful. Accept as solution if your question is answered **
Moderator
Moderator
630 Views
Registered: ‎03-25-2019

Re: MPSoC VIP example : write_data and read_data are always 4 bursts - is this expected behaviour?

Hi @ronnywebers,

These successive writes are not a burst. Actually, this behaviour is due to the 128bit data width of the AXI HPM. The AXI interconnect will split a 128bit write to 4 writes of 32bit. I'm not sure why it is behaving like this exactly, but this won't lead to unnecessary writes to the next addresses (in your example reg1, reg2...) and this is because the wstrb signal is only set for the address you have written on:

axi1.png

wstrb signal indicates which byte lanes hold valid data. So, if this signal is not set then the data is not taken into considaration even the the wvalid and wready are asserted.

This behaviour won't harm, but if you want to get rid of it, you could set the AXI HPM data width to 32bit:

32.png

Best regards,
Abdallah
-------------------------------------------------------------------------------
Please don't forget to reply, kudo and accept as a solution
Scholar ronnywebers
Scholar
592 Views
Registered: ‎10-10-2014

Re: MPSoC VIP example : write_data and read_data are always 4 bursts - is this expected behaviour?

@abouassi thank you for the explanation, I missed the WSTRB signals, thanks for pointing that out!

I could indeed change the bus size to 32-bits. I'm thinking of using the M_AXI_HPM0_LPD bus to controll the AXI4-Lite interfaces of all my custom IP's :

Screenshot 2019-07-15 at 12.12.56.png

However, I'm still wondering if there's either something wrong with they Zynq MPSoC VIP, or the Example project of the VIP uses an unluckily chosen 128-bit wide M_AXI_HPMx interface. The example only writes at reg0 (GPIO_DATA at offset 0x0000) of the AXI GPIO, however trying to write to reg1 (GPIO_TRI at offset 0x0004) actually fails with the provided example code and VIP.

Let me explain further :

To test things further, I added a simple custom IP with a single AXI4-Lite IP interface that contains 32 registers (Vivado -> Tools -> Create and package new custom IP ->  ... so I just use the templates that Vivado generates, as-is, and package that as an IP). These 32 registers allow an easy 'loopback' test. Next I added this IP to the BD, so the BD looks as follows:

bd with axi4-lite IP 32 regs.png

The custom IP sits at address 0xA000.1000

To keep a long story short, I manage to correctly write values to reg0, reg1, reg2 and reg3 using a single 128-bit write transfer, and read these 4 registers back using a single 128-bit read transfer :

        #300;
        $display ("-1- writing 128-bits at @0xA0001000");
        tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.write_data(32'hA0001000,16, 128'h44444444_33333333_22222222_11111111, resp);
        
        tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.read_data(32'hA0001000,16,read_data_128,resp);
        $display ("%t, @0xA0001000 : 32'h%x",$time, read_data_128[31:0]);  
        $display ("%t, @0xA0001004 : 32'h%x",$time, read_data_128[63:32]);
        $display ("%t, @0xA0001008 : 32'h%x",$time, read_data_128[95:64]);        
        $display ("%t, @0xA000100C : 32'h%x",$time, read_data_128[127:96]);

note that I added this to the TB:

   reg [127:0] read_data_128;

The result looks like this in the TCL console :

[5010] : M_AXI_HPM0_FPD : *ZYNQ_MPSoC_BFM_INFO : Starting Address(0xa0001000) -> AXI Write -> 16 bytes
[5315] : M_AXI_HPM0_FPD : *ZYNQ_MPSoC_BFM_INFO : Done AXI Write for Starting Address(0xa0001000) with Response 'OKAY'
[5315] : M_AXI_HPM0_FPD : *ZYNQ_MPSoC_BFM_INFO : Starting Address(0xa0001000) -> AXI Read -> 16 bytes
[5495] : M_AXI_HPM0_FPD : *ZYNQ_MPSoC_BFM_INFO : Done AXI Read for Starting Address(0xa0001000) with Response 'OKAY'
             5495000, @0xA0001000 : 32'h11111111
             5495000, @0xA0001004 : 32'h22222222
             5495000, @0xA0001008 : 32'h33333333
             5495000, @0xA000100C : 32'h44444444

Now, with these contents in the registers, I perform a 32-bit write to reg0, with the value 0x55555555, so the value of 0x11111111 gets overwritten with 0x55555555. After that, I read back the 4 registers with a single 128-bit read transfer. The result now looks like this :

[5795] : M_AXI_HPM0_FPD : *ZYNQ_MPSoC_BFM_INFO : Starting Address(0xa0001000) -> AXI Write -> 4 bytes
[6045] : M_AXI_HPM0_FPD : *ZYNQ_MPSoC_BFM_INFO : Done AXI Write for Starting Address(0xa0001000) with Response 'OKAY'
[6045] : M_AXI_HPM0_FPD : *ZYNQ_MPSoC_BFM_INFO : Starting Address(0xa0001000) -> AXI Read -> 16 bytes
[6225] : M_AXI_HPM0_FPD : *ZYNQ_MPSoC_BFM_INFO : Done AXI Read for Starting Address(0xa0001000) with Response 'OKAY'
             6225000, @0xA0001000 : 32'h55555555
             6225000, @0xA0001004 : 32'h22222222
             6225000, @0xA0001008 : 32'h33333333
             6225000, @0xA000100C : 32'h44444444

The waveforms show that there are actually 4 separate transfers, but only the first one has WSTRB set to 0xF, as you explained :

4 transfers - reg0 ok.png

so far, so good. But when I write 0x66666666 to reg1, the following happens:

-1- writing 128-bits at @0xA0001000
[5010] : M_AXI_HPM0_FPD : *ZYNQ_MPSoC_BFM_INFO : Starting Address(0xa0001000) -> AXI Write -> 16 bytes
[5315] : M_AXI_HPM0_FPD : *ZYNQ_MPSoC_BFM_INFO : Done AXI Write for Starting Address(0xa0001000) with Response 'OKAY'
[5315] : M_AXI_HPM0_FPD : *ZYNQ_MPSoC_BFM_INFO : Starting Address(0xa0001000) -> AXI Read -> 16 bytes
[5495] : M_AXI_HPM0_FPD : *ZYNQ_MPSoC_BFM_INFO : Done AXI Read for Starting Address(0xa0001000) with Response 'OKAY'
             5495000, @0xA0001000 : 32'h11111111
             5495000, @0xA0001004 : 32'h22222222
             5495000, @0xA0001008 : 32'h33333333
             5495000, @0xA000100C : 32'h44444444
-0- writing 4 registers with 32-bits data at @0xA0001000
[5795] : M_AXI_HPM0_FPD : *ZYNQ_MPSoC_BFM_INFO : Starting Address(0xa0001000) -> AXI Write -> 4 bytes
[6045] : M_AXI_HPM0_FPD : *ZYNQ_MPSoC_BFM_INFO : Done AXI Write for Starting Address(0xa0001000) with Response 'OKAY'
[6045] : M_AXI_HPM0_FPD : *ZYNQ_MPSoC_BFM_INFO : Starting Address(0xa0001004) -> AXI Write -> 4 bytes
[6355] : M_AXI_HPM0_FPD : *ZYNQ_MPSoC_BFM_INFO : Done AXI Write for Starting Address(0xa0001004) with Response 'OKAY'
[6355] : M_AXI_HPM0_FPD : *ZYNQ_MPSoC_BFM_INFO : Starting Address(0xa0001000) -> AXI Read -> 16 bytes
[6535] : M_AXI_HPM0_FPD : *ZYNQ_MPSoC_BFM_INFO : Done AXI Read for Starting Address(0xa0001000) with Response 'OKAY'
             6535000, @0xA0001000 : 32'h55555555
             6535000, @0xA0001004 : 32'h00000000
             6535000, @0xA0001008 : 32'h33333333
             6535000, @0xA000100C : 32'h44444444

so reg1 does not get the value 0x66666666, but gets overwritten with zeroes. The waveforms cofirm this:

32-bit transfer to reg1 goes wrong.png

This looks like a bug to me : either the s00_axi_wdata[31:0] get's the wrong value (0x00000000) at the time reg1 (with offset 0x4) gets written, or the WSTRB should not have been toggled. Or am I missing something?

The same test can be done on reg2 and reg3, with the same wrong result that the regs get overwritten with zeroes.

My conclusion is that only reg0 can be correctly written using 32-bit transfers. Reg1, reg2 and reg3 get overwritten with zeroes when using 32-bit transfers on the 128-bit bus. 

So the example project that comes with the VIP and demonstrates how to write to the AXI GPIO IP works a bit 'by accident', as soon as you change the address to reg1 of the AXI GPIO, things don't work.

Maybe the other question/cause is simply that 32-bit transfers are not allowed on a 128-bit AXI interface ... for that I'd need to dive into the AXI specs from ARM. But intuitively, this sounds like a severe limitation of AXI, so I would think AXI 128 bit interfaces could cope with 'partial/smaller' transfers of 32-bit, indeed by using WSTRB to validate the transfer were needed.

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
Explorer
Explorer
574 Views
Registered: ‎03-31-2016

Re: MPSoC VIP example : write_data and read_data are always 4 bursts - is this expected behaviour?

In AXI it is the responsiblity of the master to align the data to the correct bit positions when doing an unaligned transfer.

That is with a 128-bit interface if you want to write  0x12345678 to a 0x00 address it should be on the bus like this

WDATA: 0x00000000_00000000_00000000_12345678
WSTRB: 0x000F

For an address of 0x04 it must go on the bus like this

WDATA: 0x00000000_00000000_12345678_00000000
WSTRB: 0x00F0

 

Without more of your write generation code its hard to say exactly what is going on but it seems you are only accounting for the WSTRB shift and not the data shift.

I would suggest that you look at the Sxx ports of the interconnect to see what is actually being generated by the VIP

0 Kudos
Scholar ronnywebers
Scholar
553 Views
Registered: ‎10-10-2014

Re: MPSoC VIP example : write_data and read_data are always 4 bursts - is this expected behaviour?

thanks @necare81 for explaining the unaligned transfer. As you say it's the responsibility of the AXI master to put data in the correct position and set WSTRB accordingly, I can asume it's the responsibility of hte MPSoC VIP in this case? So as I am just using the API of the VIP to control it, I can not influence the handling of data and WSTRB when writing 32-bit to an unaligned 0x4 offset, I asume it's up to the VIP to handle this for me?

Here's my testbench code (only the part that I added to the MPSoC VIP example). So just after reset, I perform the following writes and reads :

        // test 1: write each of the 4 registers using 4x separate 32-bit transfer, then dump using 128-bit transaction
        #300;
        $display ("-1- writing 128-bits at @0xA0001000");
        tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.write_data(32'hA0001000,16, 128'h44444444_33333333_22222222_11111111, resp);
        
        tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.read_data(32'hA0001000,16,read_data_128,resp);
        $display ("%t, @0xA0001000 : 32'h%x",$time, read_data_128[31:0]);  
        $display ("%t, @0xA0001004 : 32'h%x",$time, read_data_128[63:32]);
        $display ("%t, @0xA0001008 : 32'h%x",$time, read_data_128[95:64]);        
        $display ("%t, @0xA000100C : 32'h%x",$time, read_data_128[127:96]);

        // test 0: write each of the 4 registers using 4x separate 32-bit transfer, then dump using 128-bit transaction
        #300;
        $display ("-0- writing 4 registers with 32-bits data at @0xA0001000");
        tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.write_data(32'hA0001000,4, 32'h55555555, resp);
        tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.write_data(32'hA0001004,4, 32'h66666666, resp);
//        tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.write_data(32'hA0001008,4, 32'h77777777, resp);        
//        tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.write_data(32'hA000100C,4, 32'h88888888, resp);

        tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.read_data(32'hA0001000,16,read_data_128,resp);
        $display ("%t, @0xA0001000 : 32'h%x",$time, read_data_128[31:0]);  
        $display ("%t, @0xA0001004 : 32'h%x",$time, read_data_128[63:32]);
        $display ("%t, @0xA0001008 : 32'h%x",$time, read_data_128[95:64]);        
        $display ("%t, @0xA000100C : 32'h%x",$time, read_data_128[127:96]);

 

 here's a screenshot of the HPM0 interface next to the AXI interface of the custom IP:

first write ok 2nd fails.png

The first write (1-2-3) writes 0x5555.5555 to @0xA000.1000 - this data arrives correctly in slv_reg0 of the custom IP. I can indeed observe WSTRB = 0x000F

The 2nd write (4-5-6) should (according to my code) write 0x6666.6666 to @0xA000.1004 - write address phase looks identical to the previous write, except for AWQOS[3:0] = 7 instead of 5. According to UG1037 it is not implemented in Xilinx Endpoint IP, so I guess this is to be ignored (thoudh it's strange the value changes).

However the dataphase seems to be containing wrong WDATA ... as you explained, I would have expected to see the VIP generate this :

WDATA: 0x00000000_00000000_66666666_00000000
WSTRB: 0x00F0

I can see the WSTRB , but the data is absent / zero ...

this looks like a kind of bug (or limitation of the VIP) to me .. ?

 

 

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
Xilinx Employee
Xilinx Employee
544 Views
Registered: ‎10-30-2017

Re: MPSoC VIP example : write_data and read_data are always 4 bursts - is this expected behaviour?

@ronnywebers ,

Please use the write_burst_strb and read_burst APIs to Initiate a single AXI write/read burst transaction on the master port. Please check the Zynq MPSoC VIP (DS941) documentation.

Best Regards,

Srikanth

0 Kudos
Scholar ronnywebers
Scholar
530 Views
Registered: ‎10-10-2014

Re: MPSoC VIP example : write_data and read_data are always 4 bursts - is this expected behaviour?

@savula thanks for your reply, 

Q1) can I conclude that 'write_data' is a wrapper around 'write_burst', with some parameters set to some fixed value?

Q2) is there any aditional doc available besides DS941? Because I have no clue on what to put in each parameter, what are the min/max values, enumerated values, ...? Can we actually see the source code of the MPSoC VIP somewhere to better understand the inner workings, or how are we supposed to know this?

write_burst.png

for example what are the different LOCK types, CACHE types, min max burst size, length, ...? DS941 says that we need to look at the provided example, but the example code is rather limited and just shows a 32-bit AXI write on a 128-bit bus. I think i can also conclude that the provided example should have used a 'write_burst' too then?

 

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
Explorer
Explorer
521 Views
Registered: ‎03-31-2016

Re: MPSoC VIP example : write_data and read_data are always 4 bursts - is this expected behaviour?


@ronnywebers wrote:
tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.write_data(32'hA0001000,16, 128'h44444444_33333333_22222222_11111111, resp); 
...
tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.write_data(32'hA0001000,4, 32'h55555555, resp);
tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.write_data(32'hA0001004,4, 32'h66666666, resp);
// tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.write_data(32'hA0001008,4, 32'h77777777, resp);
// tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.write_data(32'hA000100C,4, 32'h88888888, resp);

If you look at this code you will see that the first time you treated the data as a 128bit vector but the other times you treated it as 32bit vector.  You need to treat it as a 128bit vector all the time and do the the real byte shifting.  Like this

tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.write_data(32'hA0001000,4, 128'h00000000_00000000_00000000_55555555, resp);
tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.write_data(32'hA0001004,4, 128'h00000000_00000000_66666666_00000000, resp);
0 Kudos
Scholar ronnywebers
Scholar
500 Views
Registered: ‎10-10-2014

Re: MPSoC VIP example : write_data and read_data are always 4 bursts - is this expected behaviour?

@necare81 thanks for that answer!

so in the mean time I understand where the '4 bursts' in my original question come from, at this point I could re-phrase my question like this:

when I have an AXI4-Lite slave (like AXI GPIO in the MPSoC VIP example) with 32-bit databus connected to a HPMx bus that is set to be 128 bit wide, can I still perform (unaligned) 32-bit accesses to the individual AXI registers of that AXI GPIO or not?

If you say I can only access the AXI GPIO in the example using 128-bit transfers, then the example provided by Vivado is wrong (imho), or at least a bad example,  as it uses a single 32-bit access to set the 4 IO pins to 0xF, which then accidentaly works because the address is aligned.

Here's an (unmodified) extract of the example testbench that Xilinx provides:

        $display ("running the tb");
        
        tb_ARESETn = 1'b0;
        repeat(20)@(posedge tb_ACLK);        
        tb_ARESETn = 1'b1;
        @(posedge tb_ACLK);
        
        repeat(5) @(posedge tb_ACLK);
          

	    tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.por_srstb_reset(1'b1);
        #200;
        tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.por_srstb_reset(1'b0);
        tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.fpga_soft_reset(32'h1);
        #2000 ;  // This delay depends on your clock frequency. It should be at least 16 clock cycles. 
        tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.por_srstb_reset(1'b1);
        tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.fpga_soft_reset(32'h0);
		#2000 ;  

        //This drives the LEDs on the GPIO output
        tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.write_data(32'hA0000000,4, 32'hFFFFFFFF, resp);
        tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.read_data(32'hA0000000,4, read_data, resp);
        
        
        $display ("LEDs are toggled, observe the waveform");
        
        //Write into the BRAM through GP0 and read back
        tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.write_data(32'hB0000000,4, 32'hDEADBEEF, resp);
        tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.read_data(32'hB0000000,4,read_data,resp);
        $display ("%t, running the testbench, data read from BRAM was 32'h%x",$time, read_data);

    if(read_data == 32'hDEADBEEF) begin
           $display ("AXI VIP Test PASSED");
        end
        else begin
           $display ("AXI VIP Test FAILED");
        end
        $display ("Simulation completed");
        $stop;
    end

Of course, a bit by accident this simulation works with the 32-bit access, because they only access the first register, but it's a bad example imho. What if the IO reg would have been sitting on offset 0x4? It would mean having to first read reg0 .. 3 in a 128-bit transfer, and then write back all 4 registers with reg1 bits modified. That's unusable in practice, and some registers will not even allow a read-modify-write access. 

So at this point I might (but i'm still not sure/convinced) conclude from your answer that it's not possible to connect an AXI4-Lite slave IP with 32-bit databus to a 128-bit wide HPMx bus... I'm wondering if that is a correct conclusion? I would think that AXI could handle these 32-bit transfers on a 128-bit bus somehow more easily. @savula @necare81 @abouassi what are your thoughts on this? 

Maybe a better question is : can I use Xil_Out32 in bare metal to perform a transfer on a 128-bit HPMx bus? If so, then why can the MPSoC VIP not handle this?

Btw @necare81 you can check this Xilinx example for yourself very quickly : launch Vivado -> Open Example Project -> next -> Base Zynq UltraScale+ MPSoC example. Then launch simulation. 

I hope to find some time over the next weeks to test this on a real MPSoC target and use an ILA to compare the VIP with real data

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
Moderator
Moderator
491 Views
Registered: ‎03-25-2019

Re: MPSoC VIP example : write_data and read_data are always 4 bursts - is this expected behaviour?

Hi @ronnywebers,

Please try to use AXI Smartconnect instead of AXI Interconnect and tell me the results.

Best regards,
Abdallah
-------------------------------------------------------------------------------
Please don't forget to reply, kudo and accept as a solution
0 Kudos
Xilinx Employee
Xilinx Employee
482 Views
Registered: ‎10-30-2017

Re: MPSoC VIP example : write_data and read_data are always 4 bursts - is this expected behaviour?

Hi @ronnywebers ,

below is the syntax to send only single 32 bit data to address 32'hB00100008 

tb.mpsoc_sys.Base_Zynq_MPSoC_i.zynq_ultra_ps_e_0.inst.write_burst_strb(32'hB0010008,0,2,0,0,0,0,32'hABCDEF12,1,16'h000F,4,resp);

below is the explanation for it:

ADDR: 32'hB0010008

Len: 0 (as I need only one transfer)

SIZE: 2 (4 bytes of data (32 bit))

BURST: 0 (fixed burst)

LOCK : 0 (Normal access)

CACHE :0 (Non-bufferable)

PROT : 0 (Unprivileged access)

DATA:  32'hABCDEF12 (32 bit Data need to send)

STRB_EN: 1 ( Strobe enabled)

STRB: 16'h000F (4 bytes need to be send out of 16 bytes)

DATASIZE: 4 ( 4 bytes of data)

resp: write response

 

 

Best Regards,
Srikanth
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.

 

 

0 Kudos
Explorer
Explorer
474 Views
Registered: ‎03-31-2016

Re: MPSoC VIP example : write_data and read_data are always 4 bursts - is this expected behaviour?


@ronnywebers wrote:

so in the mean time I understand where the '4 bursts' in my original question come from, at this point I could re-phrase my question like this:

when I have an AXI4-Lite slave (like AXI GPIO in the MPSoC VIP example) with 32-bit databus connected to a HPMx bus that is set to be 128 bit wide, can I still perform (unaligned) 32-bit accesses to the individual AXI registers of that AXI GPIO or not?

Of course, a bit by accident this simulation works with the 32-bit access, because they only access the first register, but it's a bad example imho. What if the IO reg would have been sitting on offset 0x4? It would mean having to first read reg0 .. 3 in a 128-bit transfer, and then write back all 4 registers with reg1 bits modified. That's unusable in practice, and some registers will not even allow a read-modify-write access. 

So at this point I might (but i'm still not sure/convinced) conclude from your answer that it's not possible to connect an AXI4-Lite slave IP with 32-bit databus to a 128-bit wide HPMx bus... I'm wondering if that is a correct conclusion? I would think that AXI could handle these 32-bit transfers on a 128-bit bus somehow more easily. @savula @necare81 @abouassi what are your thoughts on this? 

 


The answer is the AXI Interconnect (or a AXI Width converter IP) must be present to convert the width.  The VIP is set up to simulate the 128-bit master so that is how you must control the VIP.  You code would work without modification if you had setup the VIP as a 32-bit directly connected master.

For writes the WSTRB(aka byte enables) will control what actually gets written.  You AXI-Lite IP will get 4 write requests, only one of which will have the WSTRB set.  That is one reason slaves are required to use WSTRB.

You can take a look at the ARM AXI spec or Xilinx PG059 the AXI Interconnect datasheet and focus on Width Converter section to understand more on how it works