Re: Block RAM strange behavior, address off by one

On Apr 17, 11:02 pm, Peter Alfke <a...@xxxxxxxxxxxxx> wrote:
A few ideas:
Are you sure about the content of the various locations?
Could the error have happened when you wrote data into the BRAM?

When reading, read twicein sequence from the same address. Then you
will see whether this is a read pipelining problem, or whether you
really are always reading the wrong information.
The error has to somewhere in your timing.

Be a sleuth!
Peter Alfke

On Apr 17, 7:12 pm, Gabor <g...@xxxxxxxxxxx> wrote:



On Apr 17, 8:13 pm, "M. Hamed" <mhs...@xxxxxxxxx> wrote:

I am getting a strange error with Block RAM on a Spartan 3 FPGA. Every
time I issue a read, the word at the location previous to the given
address is read. For example if I'm reading from address 5, the word
at address 4 is output instead. The data written to the block seems
correct when I view it in ModelSim so I assume it's something with the
read.

This does seem strange. Are your writes and reads always made to
sequential memory locations (i.e. 1, 2, 3, ... in order)? Perhaps the
error is in cycle timing and not address?

Viewing signals at the BRAM input in ModelSim shows the correct
address at the input of port A and the read clock signal goes high but
the wrong word appear at the output. ENA is always 1 and WEA is always
0. The very most recent Write to this same address (from a different
port) also shows the correct value being written.

The design works correctly in RTL but this problem only occurs with
the post-route netlist.

Did anyone encounter a similar problem like this before and can give
me a hint on what's going on.

The only time I've seen something similar was with an old version of
the
BRAM simulation models that needed a slight positive hold time in the
address. In effect it was the behavioral simulation that incorrectly
gave
the read data on the same clock that the address was presented. In
fact
BRAM's are registered in the Spartan 3 (and Virtex 2) series, so the
output data should have changed on the following clock cycle. In the
post-PAR timing simulation, the output changed on the following clock
cycle as expected.

Thank you.- Hide quoted text -

- Show quoted text -

If you generated the block RAM with coregen, there is an option to
preload the RAM with a coe file. You can then simulate the block RAM
both at the RTL and post P&R level, disable the writes in the code
and
see if you read the expected data designated by the coe file at the
desired addresses.

There are some instances when the RTL does not match the post P&R
simulation. i.e. (sensitivity list is incomplete in a combinatorial
process,
improper use of blocking assignments and variables) I don't use the
later two items
in synthesizable code, so I don't have much experience with them, but
then
again, I never get an RTL vs post P&R simulation mismatch because of
them.

Hope this helps,
Newman


.

Relevant Pages

  • Re: Block RAM strange behavior, address off by one
    ... Could the error have happened when you wrote data into the BRAM? ... When reading, read twicein sequence from the same address. ... BRAM simulation models that needed a slight positive hold time in the ... the read data on the same clock that the address was presented. ...
    (comp.arch.fpga)
  • Re: Block RAM strange behavior, address off by one
    ... clock edge, and as a result of the clock edge, you get the data that ... Could the error have happened when you wrote data into the BRAM? ... The error has to somewhere in your timing. ... BRAM simulation models that needed a slight positive hold time in the ...
    (comp.arch.fpga)
  • Re: XilinxSystemGenerator and Simulink
    ... When I run the simulation I never get past the 0ps point and I get the ... Yesterday by editing the config.m file for the filter I eventually got ... the 200KHz clock that the same indeterminate Boolean value error occurred!. ... I've been working on a simulink model built using the Xilinx Blockset ...
    (comp.arch.fpga)
  • Re: regarding "posedge"
    ... clock - it certainly doesn't drive the FF's ... "Hardware Desciption Languages". ... any programming language: ... but I have seen problems in a simulation where an internal ...
    (comp.lang.verilog)
  • Re: Laptop for FPGA design?
    ... clock for clock basis then the 8M Cache iCore7 when running NCVerilog. ... simulation) is quite different. ... a two level cache on the Core2. ... place and routes, but the 6M Core2 wins hands down when doing simulations ...
    (comp.arch.fpga)