GW1N BSRAM access time confusion

[zzattack]

Preface: seasoned programmer, but completely new to hardware design.

I'm confused about the BSRAM available on the simple and cheap GW1N that I'm targeting. For my use case, I have a piece of state machine where on one clock cycle I determine a memory address from which I want to fetch data. On a later clock cycle, I want to retrieve said stored data. I'm using a BSRAM configured in (true) dual port mode.

Relevant timing diagrams for the BSRAM are given in UG285E, and look as follows for the configuration that I picked (Read Mode = Bypass, Write Mode = Normal):


This suggests to me that if on clock cycle n I update AD <= my_address, then on clock cycle n+1 the data I want to retrieve should be available on the DO of the port. The address update is done in an 'always @' block which triggers off the posedge on the same clock signal that is fed to the BRAM.
From my testing however, I must add one additional clock cycle of delay before I can sample the data on the BRAM output. Is this expected, and if so, where is the flaw in my expectation?

[ataradov]

Address is sampled on the positive edge. Depending on how you count, on the first clock cycle your 'always @' block writes the address. On the next clock cycle BRAM samples that address, and one cycle later the data is latched on the output.

This is why you typically see address presented to the BRAM asynchronously.

It may be easier to tell what is going on if you show the test code and results of the simulation.

[zzattack]

Aha, then that perfectly aligns with what I'm observing.

What about the other direction, i.e. writing?

Suppose that
 - on clock cycle 0 I change DIN=0xAA, WRE=1
 - on clock cycle 1 I change DIN=0xBB, WRE=0
 - on clock cycle 2 I change DIN=0xCC

Which value ends up getting stored in the BRAM?

[NorthGuy]

I'm not familiar with GOWIN, but I guess "bypass" means that it bypasses a built-in BRAM output register.

Once the BRAM receives a clock edge where WRE bit is zero (#6 in your diagram) it starts reading. This process takes some time. Once the data appear on the bus, it will be seen by combinatorial logic in your code (if any) and will eventually make it to one of your registers. If your clock is slow enough, this will happen before the next clock edge (#7). If the clock is too fast, your tools should fail timing analysis.

If you use a local BRAM output register ("no bypass" mode I guess), the data will only make to this local register and will be latched by the register at the next clock cycle (#7), which is faster and therefore allows using faster clock. The local BRAM register will expose the data to your combinatorial logic (if any) and the result will eventually arrive to one of your registers, hopefully before the next clock edge (#8). I suspect this is what you're doing.

[ataradov]

What about the other direction, i.e. writing?

It would be far easier if you provided short HDL code samples rather than verbal descriptions, which could be ambiguous.

- on clock cycle 0 I change DIN=0xAA, WRE=1

What do you mean by "on clock cycle"? Is this the values presented to the BRAM after this clock transition, or the values clocked in by the BRAM?

Any time there is a clock transition and BRAM WRE=1, the data that is on the input at that time is written. So, if those values are from BRAM point of view, then 0xAA would be written.