RAMB16_S9

Try this link

It has some information about how to use the memory. Although it is not in verilog (the course is about VHDL), it should be helpful.

Milind

Hi, I have read these materials before I wrote the code, and I have just re-read it, seems like the way that I instantiate the code is write. I don't know why the data is not there though. Does anyone have an example or something? Thanks, Ann

re-read it, seems like the way that I instantiate the code is write. I don't know why the data is not there though. Does anyone have an example or something? Thanks, Ann

I looked at your code segments earlier and it looks 100% correct. The state machine goes through 256 writes to the same address. The first write to that address should produce a valid read value. As long as your clock is verifiably there, I'd suggest you could have a mistake in the code that reports the read value *suggesting* that the read value is zero when it isn't.

I hope you find the trouble.

- John_H (by the way, your posts aren't wrapping when sent causing some problems in other newsreaders)

Hi, for some reason, the write line have to toggle high and low for me to write and read data back. I thought for this kind of memory module, you only need WE to be high to write, and WE to be low when you read. If in my state machine, I have 10 write cycle where I set WE

If you're simulating, look for the wr_en being assigned 0 outside the always block you showed us; this would present odd behavior.

The Block RAM absolutely does not require the WE edge. The WE level is sampled on the rising edge of the clock to the BlockRAM with specific setup and hold requirements.

Are you simulating, using ChipScope, looking at test points, or other?

write and read data back. I thought for this kind of memory module, you only need WE to be high to write, and WE to be low when you read. If in my state machine, I have 10 write cycle where I set WE

Hi, I am simulating using ModelSim. I saw that WE do get "0" and the address coming in is changing, but still data out is always 0 for some reason :-\ Thanks, Ann

Make sure you are correctly using glbl.v:

This is sometimes tricky to get right because of the various timescale in each module. However, look at the waveforms and make sure that you wait long enough for glbl.GSR to go low so the BRAM output registers actually pass the data out of the module.

Paul

Ann wrote:

coming in is changing, but still data out is always 0 for some reason :-\ Thanks, Ann

Hi, It works now. But for some reason, the data read out is one cycle late. Is this how it supposed to be. For example, I set it up so that it store value 0 at address 0, 1 at address 1, 2 at 2, 3 at 3 etc. But when I read back, address 1 read back 0, address 2 read back 1, address 3 read back 2, etc. Thanks, Ann

Keep in mind that the write data goes to the write address at the sampling clock edge. Read data comes from the read address sampled on the clock edge becoming valid a few nanoseconds later. If you're looking at what the address is in your simulation when you look at the data that's coming back from the BlockRAM, they will be one cycle skewed because the address you see is the address for the read data AFTER the clock edge.

These memories are synchronous. Look at the Xilinx page on the primitive -

- and you'll see the logic table for the BlockRAM. Note that there are three different modes for reading and writing at the same time for this single port memory set by a parameter. The RAMB16_S9_S9 is a dual-port memory that allows independent read and write addresses to the same memory array.

late. Is this how it supposed to be. For example, I set it up so that it store value 0 at address 0, 1 at address 1, 2 at 2, 3 at 3 etc. But when I read back, address 1 read back 0, address 2 read back 1, address 3 read back

2, etc. Thanks, Ann

For some reason, this only works in simulation, when I probe the pins on the chip, nothing shows up. If i have the WE toggle, then it works, I can see the data whenever WE is low. If after setting WE to 1'b1 for 20 cycles, I set WE to low all the time, no data on the scope. I triggered on the negative edge WE on the Oscilloscope and WE looks like it went to 1.2 V so not quiet a "1" and data[0] went to like 1.02 and that's it, nothing else happens. Same thing happens when I trigger on the rising edge of data[0].

If your probes show that electrically the signals are not what you expect in a digital signal, the power supplies to your chip may be wrong. Please check your device for appropriate voltages to Vcco, Vccaux, and Vccint relative to ground. Have you verified that the chip is programming correctly? Are you driving an unusual load such as a 30 ohm resistor? Do you have your I/O signal format specified in your constraints as LVCMOS? LVTTL? 2mA? 24ma? What frequency is the design running?

If the rest checks out, bottom line is if the I/O are bad, the design will run bad. A transition on WE may give the signal enough "oomph" to get past the invalid logic level to something that registers.

With 1.2V and 1.02V signals, something is very wrong. It's certainly not the RAMB16_S9 primitive that's having troubles.

the chip, nothing shows up. If i have the WE toggle, then it works, I can see the data whenever WE is low. If after setting WE to 1'b1 for 20 cycles, I set WE to low all the time, no data on the scope. I triggered on the negative edge WE on the Oscilloscope and WE looks like it went to 1.2 V so not quiet a "1" and data[0] went to like 1.02 and that's it, nothing else happens. Same thing happens when I trigger on the rising edge of data[0].

Hi, I have checked, Vcco, Vccaux, and Vccint are correct, other designs work fine. The input clk is 30 MHz and I have used this frequency before for all my other designs, and the chip can handle it. But the question is how come it works right when I toggle the WE signal. It works exactly like how you would expected it to. It's only when I have WE high for write then 0 the rest of the way, then it's didn't behave like the ModelSim Simulation, I am really confused!!! In my ucf file I didn't add any constraint to the signal. I don't see a reason to, but should I? Thanks, Ann

The reason the problems exist is that your I/O isn't valid. Bottom line, if you have bad input, you'll probably get bad output.

If your write enable has some "reason" to be 1.2V logic high for LVCMOS33, toggling the signal low then high will present a higher voltage until the signal again reaches a DC level of 1.2V. You get a valid state for a short amount of time before you get an invalid.

Show me why the I/O are not giving valid digital levels and you'll find why your design isn't "working."

work fine. The input clk is 30 MHz and I have used this frequency before for all my other designs, and the chip can handle it. But the question is how come it works right when I toggle the WE signal. It works exactly like how you would expected it to. It's only when I have WE high for write then 0 the rest of the way, then it's didn't behave like the ModelSim Simulation, I am really confused!!! In my ucf file I didn't add any constraint to the signal. I don't see a reason to, but should I? Thanks, Ann