Read byte followed by write byte does not match

[aignacio]

In the following scenario (one request followed by another):

1. Write request on any address of hsize = BYTE
2. Read request on the same address before of hsize = BYTE

The contention variable goes high and the ahb3_memory hold putting HREADYOUT = 0 one cc later like in the picture below, leading the read to be invalid (data read does not match with the written value).

Forcing contention to zero fix this specific case...

[rherveille]

Read-Write-Contention detection is required. HREADY going low for 1 cycle is the intended behaviour. What underlying memory model are you using? Does the memory model handle read/write contention? Due to the pipelined nature of the AHB bus, the write must be delayed 1 cycle, such that write/address/write_data are aligned. However if there’s a read from the same address 1 cycle later, then the new data has not been written yet. Thus the read must wait 1 cycle, until the memory-write completes, and then it can continue. I think the issue is caused because ‘raddr_i’ is not held during contention. For test, please add (in ahb3lite_sram1rw.sv) logic contention_reg; always @(posedge HCLK) contention_reg <= contention; and change: .raddr_i (contention_reg ? waddr[MEM_ABITS_LSB +: MEM_ABITS] : HADDR[MEM_ABITS_LSB +: MEM_ABITS]), Thanks, Richard Richard Herveille Managing Director Phone +31 (45) 405 5681 Cell +31 (6) 5207 2230 richard.herveille@roalogic.com On 30/07/2019, 20:27, "Ânderson Ignacio da Silva" <notifications@github.com> wrote: In the following scenario (one request followed by another): 1. Write request on any address of hsize = BYTE 2. Read request on the same address before of hsize = BYTE The contention variable goes high and the ahb3_memory hold putting HREADYOUT = 0 one cc later like in the picture below, leading the read to be invalid (data read does not match with the written value). Forcing contention to zero fix this specific case... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[aignacio]

Hi @rherveille ,
I'm using the GENERIC option on the wrapper and the behavioral rl_ram_1r1w_generic from your repository. I made the changes that you pointed and now the memory is reading wrong in some scenarios, is that another behavioral model that could deal with this situation perfectly? I'm bit curios why this problem just happen in the HSIZE equal to byte/half-word case....in the word case it holds hreadyout in the right manner.

[rherveille]

Read/Write contention is partially handled in the rl_ram_1r1w.sv file. It’s only handled for the case where the full bitsize is written. Basically the write data is copied into a register and then fully returned during the read cycle. There’s a message saying “BE” (byte-enable) is not handled yet. This can be added, but will only work if the memory actually outputs data for those bits that are not being written. Many memories have a “don’t care” behaviour. Alternatively read-write-contention could be handled in the ahb3lite_sram1rw.sv file. The actual write to memory is delayed 1 cycle to align the write/address/write-data (that’s what causes the contention). During the initial cycle the memory is read. So the initial memory content is known. This data can be stored in a register, subsequent writes to the same memory location must then also update the register’s content. When, finally, the same memory location is read, in the cycle after the write(s), the register content is provided instead of the output from the memory. If you’re willing to help debug we can look at implementing this. Unfortunately the memory lacks a testbench. Would you be able to write a testbench for the memory, which highlights these issues? Thanks, Richard Richard Herveille Managing Director Phone +31 (45) 405 5681 Cell +31 (6) 5207 2230 richard.herveille@roalogic.com On 31/07/2019, 12:07, "Ânderson Ignacio da Silva" <notifications@github.com> wrote: Hi @rherveille , I'm using the GENERIC option on the wrapper and the behavioral rl_ram_1r1w_generic from your repository. I made the changes that you pointed and now the memory is reading wrong in some scenarios, is that another behavioral model that could deal with this situation perfectly? I'm bit curios why this problem just happen in the HSIZE equal to byte/half-word case....in the word case it holds hreadyout in the right manner. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[aignacio]

Hi @rherveille
tks for the explanation now I gotcha your point and I can do the tb for the memory model covering these issues for sure, I'll for the rl_ram_1r1w_generic what stands as the one in FPGA cases, also if it's possible I made some small additions to support hexadecimal initial file like the code below, is that possible to include this through some merge req.?

  integer iter;
  reg [DBITS-1:0]  temp  [2**ABITS-1:0];

  initial begin
    if (INIT_MEMORY == 1'b1) begin
      $readmemh(INIT_FILE, temp);
      $display ("Loading memory with the file %s",INIT_FILE);
      $display ("SRAM Words size ----> %d Words",2**ABITS);
      for (int iter=0; iter<2**ABITS; iter++) begin
        if (^temp[iter] === 1'bx) begin
          mem_array[iter] = 32'd0;
        end else begin
          $display ("[ADDRESS = %d][DATA = %h]",iter,temp[iter]);
          mem_array[iter] = temp[iter];
        end
      end
    end
    else begin
      for (int iter=0; iter<2**ABITS; iter++) begin
        mem_array[iter] = 32'd0;
      end
    end
  end

ps.: INIT_FILE/INIT_MEMORY are verilog parameters for the module...

[aignacio]

mem_tb.zip