Data width is 128 bits but only LSB 32-bits are valid

My AXI4 master and slave data width is 128 but each slave register size is of 32 bit.As per the design the lsb 32 bits of the data bus are valid. In my AXI4 vip the strobe is geting randomized. The valid attributes for are: Burst = FIxed , length = 0 , size = 32 bits.I forced Strobe to 16’000F But I am not getting write and read values from the registers same.
So how to make LSB 32 bits as valid.

1 Like

just issue a write or read transfer of size 32bit by constraining AxSIZE to value 2. like say
constraint awsize_c {awsize <= 2;}
constraint arsize_c {arsize <= 2;}
Goal here is just to issue a transaction of size 32 bit only.

In reply to voraravi:

I would say it should be == rather than <= …


``` verilog

constraint awsize_c {awsize == 2;}
constraint arsize_c {arsize == 2;}

In reply to Subrahmanyam:

If your application wants narrow transfer, you can go with <= or if your application wants just 32 bit use ==.

Thank you for the suggestions. I have written this below .

module allign( input [127:0] axi_in_data,
                  input [15:0] in_strobe ,
                  output reg [15:0]out_strobe,
                  output reg [127:0] axi_out_data
                ) ;
  bit [7:0] temp [];
  typedef bit [31:0] a;
  bit [127:0] wdata;
  bit [127:0] wdata2;
  bit [31:0] wdata1;
  integer i,j;
  assign wdata = axi_in_data;
  assign axi_out_data = wdata2;
  assign out_strobe = 16'h000f;

  task automatic masking(bit [15:0] strobe);
    begin
    temp=new[4];
    j=0;
    for(i = 0; i<16; i=i+1) begin
      if(strobe[i]==1) begin
        temp[3-j] = wdata[8*i+:8];
        j=j+1;
      end
    end
    wdata1=a'(temp); // unpacked to packed array casting
    wdata2 = {96'h0,wdata1};
    end
  endtask

  always@(*) begin
    masking(in_strobe);
  end
 endmodule

In reply to voraravi:

According to DUT ,only LSB 32 bits are valid and I am using write and read API which will automatically set the AxSIZE = 3’b010.

In reply to krishna_:

Suggestion: use a queue array instead of a dynamic array.


task automatic masking(bit [15:0] strobe);
    for(i = 0; i<16; i=i+1) begin
       if(strobe[i]==1) begin
           temp.push_front(wdata[8*i+:8]);    //use push_front if you want to least significant
       end                                    //byte of wdata to be stored at higest index of
    end                                       //temp or else if least significant byte to be 
endtask                                       //stored at lower index of temp use push_back 

In reply to voraravi:

Thank you for your suggestion sir. I will definitely consider queue inspite of an array.

Hi,
I have a general query on narrow transfer:
If I want to send 8-bit of data on 32-bit wide bus what could be AWSIZe value ? Assume start address = 0
To support narrow transfer there could be two approach:

  1. AWSIZE = Maximum bus width 32-bit in this case
    AWSIZE = 2 ( 2^2 = 4 byte= 32 bit) and play with wstrb
    i.e wstrb = 4’b0001 lower level driver or UVC will do this configuration while driving
  2. AWSIZE = 0 ( 2^0 = 1 byte = 8bits) this approach would calculate number of data to be sent on bus with (awlen+1)(2^awsize8) // some glue logic around this to sent wstrb

in approach-1 we don’t care about awsize and purely depends on wstrb and in approach-2 is awsize followed by wstrb

From standard axi spec point of view which is correct?

@voraravi , @Subrahmanyam could you please help?

Hi @smit_patel ,

Form Spec.
/*
Size is communicated using the AWSIZE and ARSIZE signals on the write request and read request channels,
respectively. In this specification, AxSIZE indicates AWSIZE and ARSIZE.
*/

AWSIZE = Maximum bus width 32-bit in this case is not a maximum bus size. It Indicates the maximum number of bytes in each data transfer within a transaction.

As per Spec.
/*
Size must not exceed the data width of an interface, as determined by the DATA_WIDTH property.
*/

I think both approaches are ok whatever the AxSIZE as long as proper strobe values are provided.

1 Like

Hi @suraj_10
Thank you for your response.
I also believe that both approaches are fine.
Thank you.