Virtex 4 BRAM readback: Data corruption in BRAMs not being accessed

[rtorrego]

Hi everyone,

We are doing a readback into some of the BRAMs of our architecture (configured as dual port RAM). To avoid data corruption we disable the clock and set the enable pin to '0' prior to the readback (in both ports). We do this just in the BRAMs we are going to readback.

However, we are getting data corruption in other BRAMs in the system (i.e. in the program memory of a uBlaze. What makes it freeze). Does this make any sense?

We could expect any problems if these BRAMs, not being accessed, were placed in the same column and in the same clock region, as they are "mapped" into the same readback frame, but we are not in this situation.

Is there any other restriction we are missing?

Thanks in advance.

Regards
Raúl

[austin]

Raul,

A readback reads everything back, hence any BRAm being clocked may be disturbed if their clock is running and it is enabled.

How do you read back a single BRAM?  Through the configuration interface it is not possible, you must read an entire frame, and when done in sequence, that means more than one BRAM gets readback.  If done with the verify operation in Impact, that is the entire chip, not just BRAMs.

[rtorrego]

Hi Austin,

Thanks for the reply.

Sorry, I should have specified more:

We are performing the readback via the internal ICAP and a self-designed FSM. For reading a "single" BRAM we only read the 64 frames (64 minor addresses) of a concrete TOP, ROW and COLUMN (being the block type: BRAM content). I have written "single" because, actually, in those frames, the content of the 4 BRAMs that share the above FAR address is present.

So, just reading these 64 frames, and provided that the uBlaze program memories are far away, we didn't expect they to get corrupted.

Regards
Raul

[jimwe]

Raul,

Note that in order to get 64 frames out of the ICAP you will actually perform 65 frames of reading. The BRAMs in the next BRAM column to the right will all be affected unless the 64 frames are for the last BRAM column in the row.

Jim Wesselkamper

[rtorrego]

Hi Jim,

I will double check that. I'm sure they are not in the same column, but they could be in the next one...

Thanks for the answer. I will come back with a result.

Regards

Raul

[rtorrego]

Hi everyone!

We have already checked the placement of the BRAMs containing the program memory of the uBlaze and the problem remains. Even more, sometimes, designs with uBlaze's BRAMs far away from the BRAM being read fail, while others with the BRAMs in the next column work properly.

We have not been able to obtain any relation between the placement of the BRAMs and the behaviour. Anyway, once we have a design that works, if we "export" (with constraints in the UCF) the placement of the BRAMs to an other design, this second one also works. So at this moment this is the way we use to continue working...

Thanks everyone for your help

Regards

Raúl