Use BRAM as ROM (Xilinx)

I make ROMs like this:

-- Mike Treseler

Hi Peter, do you have an XAPP or similar that describes that issue better?

I had an X2P design a few years back that would sometimes corrupt a few bits of its BRAM ROMs when there were clock glitches (during DCM initial lock).

Regards, Allan

Hi Peter,

isnt that address setup time requirement only there for Virtex-4 because of silicon errata? or can the memory corruption occour on other Xilinx FPGA's as well?

Antti

Antti -

As I recall, V2Pro has a similar corruption "feature" for the BRAMS.

John Providenza

ah s....

when I first read it, I assumed its only Virtex-4 related silicon bug. I could not belive the same errata is present and not fixed in more then one Xilinx FPGA Family. guess need read again all datasheets and erratas :(

Antti

When I highlighted the difficulties in using initialized BRAM's as ROM here on comp.arch.fpga couple of years back, Peter suggested that I was being overdramatic [1].

Documentation:

The only documentation I know of (haven't looked for a while) describing the faulty write enable logic is Answer Record 21870, plus the notes in the BRAM sections of the datasheets/user guides.

Answer Record 21870 currently states the problem is limited to V2/P and V4, but the BRAM address setup footnotes also appear in the V5 and S3/E/A/D datasheets and/or user guides.

Neither source mentions DCM unlocks, although it is an obvious failure mechanism to violate the address setup time.

Some of the datasheet notes provide a "sanitized" description of the problem, that does not directly mention data corruption. e.g. DS312-2, v3.5, page 39 :

"DESIGN NOTE: Whenever a block RAM port is enabled (ENA or ENB = High), all address transitions must meet the data sheet setup and hold times with respect to the port clock (CLKA or CLKB), as shown in Table 102, page 144.This requirement must be met even if the RAM read output is of no interest."

Implications:

The only safe way to use an initialized BRAM is to have your DCM startup logic hold all BRAMs disabled until the clocks are present and stable.

If the DCMs ever unlock during operation, the only recovery mechanism is to reconfigure the part ( or to somehow provide BRAM re-initialization in your logic through the other BRAM port, which defeats the whole point of initialization )

If you know ahead of time that a clock is going away, you can deassert the BRAM enable while you switch clock sources.

Unfortunately, many of the systems I've done in the past 4-5 years have external clocks that can come and go, without advance notice, during operation, making this BRAM "feature" quite an annoyance.

Also of note, the use-BRAM-as-logic feature of XST is very likely to be unsafe unless you can force the use of the enable line on the inferred BROM.

Brian

On 25 May 2007 10:57:53 -0700, Brian Davis wrote: [snip]

Thanks for that Brian. This solved a 3 year old bug that I had never been able to explain before.

Regards, Allan

Aaaaack! Even in pre-Virtex-2 BRAMS?

Ideally, the write enable line would actually disable writes when it is deasserted.

Lacking that, the next best thing (for safer Block ROMs) would be a "write protect" attribute (per port, or per BRAM) in the BRAM configuration, that disables the writes completely.

Perhaps the necessary configuration bits already lurk unused in the bitstream, waiting only for a patch to set them free...

Unfortunately, those circumstances as close as your next DCM startup.

Certain simple DCM configurations could use bitgen's wait-for-DCM- lock startup option as a workaround ( but that has its' own problems )

Any loss/glitch of your clock will do, DCM or no DCM; after which a reset alone is not sufficient to recover, the Block ROM must be reloaded.

A hypothetical example:

As you're testing the latest whiz-bang SDR block in the lab, every time you change the rate of the sample clock the #$%^%@! FPGA needs to be re-downloaded, rather than merely reset, because the DSP cores don't bring out the Block ROM enable lines needed to protect their internal coefficient ROMs while the clock synthesizer is retuned.

Brian

What about an async reset coming to the process generating the read addresses? I guess this might also violate setup/hold on w.r.t. the BRAM, corrupting memory contents, or did I get this wrong ?

/Pontus

Using a BUFGCE, instead of the BRAM enable input, would help startup any BRAMs with buried-in-IP enables.

But real world clocking systems that monitor DCM status, or perform automatic clock failovers, CAN NOT USE ENABLE (OR AN ENABLED CLOCK) TO PROTECT BLOCK ROM CONTENTS!!!

Unless, of course, you have mastered the obscure art of Psychic Hardware Design, and can design clock enable logic that knows ahead of time when the DCM will unlock, the DRO suffer a phase hit, or the clock recovery PLL hiccup :)

Brian