I have a 16K chunk of dual-port video memory implemented using block RAMs in Verilog, using eight RAMB16_S18_S18 primitives. The Kestrel's CPU is able to freely read from and write to these RAMs. Likewise, the video fetch unit similarly can read from them.

The problem I'm seeing is that the video fetch circuitry can see the video data I've preloaded with defparam statements, but the CPU *cannot*. When it reads from the block RAM, it merely sees $0000 for the first time. After the CPU writes to block memory, both ports see the same value. Clearly, each bit of these dual-port RAMs are implemented using two SRAM cells, one for the A port, the other for B port. INIT_xx appears to only be initializing the A-port values. B-port memory assumes its power-on default values.

I've so far not been able to find a resolution to this bug (if you ask me). This behavior is entirely contrary to http://tinyurl.com/7x8e2u3 , which is both infuriating and something which the Kestrel depends on for proper operation.

Strangely, this behavior doesn't seem to happen with the program memory blocks. I'm absolutely confused by this.

Has anyone any tips for pre-initializing memory for both ports?

What's wrong with using COREGEN within ISE to add an initialized block RAM? It will ask you for all variables including INIT variables, whether all zeros/etc. or load a file from specific location...
Sounds like you do everything by Verilog text though...

Yes, I do everything through Verilog, precisely because I want to minimize my dependency on Xilinx-specific tools. The Kestrel is intended to be open-source and as portable as possible to other platforms as I can reasonably make it (this is a practical matter, for no two members of the Silicon Valley Forth Interest Group seems to have a common FPGA development board).

However, I'm starting to now suspect the problem lies not with the RAMBs, as such, but with the relative timing between the fetch instruction and the generation of the CYC_O and STB_O signals from the CPU. While correct for writing, they appear to be a half-cycle off for reading. I'm not 100% sure about this, again, because things seem to work for program memory.

I have to run to work; I'll continue to look further into this when I get home again. Uugh, I hate having to run when you're hot on the trail of a persnickety bug.

Since you use a Xilinx part, you may want ask the question on the Xilinx forums.
Alot of folks their are extremely knowledgeable on Xilinx parts and eager to teach/learn.

Looks like you're working on the wishbone I/F, with the CYC and STB signals...

I've never seen this behavior, but I don't think I've ever used initialized RAM with dual ports.

What happens if you switch the A/B ports of the block RAM ?

Good idea; I'll try it just to be safe.

However, I think I know what might be happening. It just occurred to me that the instruction memory accesses occur with the RAM's enable pin pegged true. However, data fetches qualify their enables against CYC_O and STB_O. Since the opcode for reading the data bus would have expired by the time CYC_O, STB_O, and ACK_I are true, it never gets the chance to read the data presented on the RAM port.

I'll need to watch the simulation vectors more carefully, and pay particular attention to the RAM's enable input. I'm willing to bet that's what's happening.

The next question now is how to fix this problem.

I've confirmed that ACK timing is the cause of this issue. Whoops.