Bram reading error, first read never return value

[taoluwork]

Hi Experts,

I run into a trouble using BRAM, my first time read never returned a value, as shown below

My values initialized are 01, 02 03, 02, 01,00. So I should read 01 at address 00, read 02 at address 01. But my return data delayed one read. Also I don't know why the address changed XX,00, 01,00 like this pattern.

Design: I run into this in simulation stage. I designed a module which can pass the co-sim perfectly. The bram is an array on interface in HLS design, initialized using .coe file loaded from GUI. I'm using stand-alone block mem generator, no registers used for input or output. And I also receive warning about  miss-match master type BRAM_CTRL and BRAM_others. 

So how do I fix this wierd error. All I need is dataout return the correct value after addr+enable read. For example, in C code, my "v = ByteCode[0]" should return the address[0] value but this failed right now. All clues are appreciated! Thanks.

Taurus

[drjohnsmith]

I Assume you rusing a registered BRAM,

    so you have to allow one clock for the address to get through ( at least )

[taoluwork]

Thanks for your reply.

Yes, you are definitely right. But if you see my pic, that enable last one clock. But my data delayed one entire reading time, longer than just one or two clock. Again, address[0] should read 01, address[1] should read 02. However, in my wave, value 02 returned even after the address[2]'s read. In one word, either my address[0] or address[1] 's read did not work and delayed the whole procedure (seemingly, to me).

So is that the fact that bram addressed starting from 01? If that's the case, why addr00's read has a corresponding enable?

[taoluwork]

I have a pic with clk.

Do you see more possible errors?

[dpaul24]

@taoluwork,

Cross check if your coe file is populating the BRAM as IT SHOULD be.

[taoluwork]

Inspired by @drjohnsmith , I managed to change the wave from top one to bot one by adding a forced LATENCY directive in my reading function. Now, whenever ena is triggered, we got correct value next clk. So the previous issue seems to be "it really takes long (about 12clk) from addr is provided to value is returned, no matter when enable is set". I'm still learning BRAM and I don't know why. Is it normal for BRAM to react so low? Any explaination is most welcomed.

[taoluwork]

@dpaul24 Thanks for the reminder. I think .coe was fine there. And I guess the issue was about latency.

[dpaul24 · Accepted solution]

@taoluwork,

I have never populated BRAMs with coe files but have written and read from BRAM blocks.

1. I see your addr bus going to Xs and the again taking values. That's not a good design, fix it.

2. Whenever I use BRAMs I introduce a register stage in the end (You have the while while generating the BRAM module using the IP Catalog). The read cycle latency is then 2 clock cycles after the address for reading is placed on the addr bus. You can try this approach.

[taoluwork]

@dpaul24 ,

Thank you so much for your advices, I finally managed to lock the letancy to 2 clk and use directive in my HLS file to adjust the control module.

However, I run into another issue that the data return from BRAM is always slightly late than the clock edge and when I use them to calculate, a glitch is generated. Could you please have a look at my another post? Thank you!

https://forums.xilinx.com/t5/Simulation-and-Verification/Wierd-glitch-at-beginning-of-clock/m-p/948156#M25216