Use BRAM as ROM (Xilinx)

Peter wrote:
>
> I am convinced that the problem is in all Virtex and Spartan devices
>
 Aaaaack! Even in pre-Virtex-2 BRAMS?

>
> And I also do not see any fix that would maintain BRAM access time.
>
 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...

>
> And it takes a peculiar set of non-deterministic circumstances
> to result in an error.
>
 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 )

>
> But I did not think about the DCM losing lock  :-(
>
 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

Brian, there is a perfect cure: disable the clock.
The problem can only occur when the clock is enabled.
Peter

On May 29, 7:34 pm, Brian Davis <brimda...@aol.com> wrote:
> Peter wrote:
>
> > I am convinced that the problem is in all Virtex and Spartan devices
>
>  Aaaaack! Even in pre-Virtex-2 BRAMS?
>
>
>
> > And I also do not see any fix that would maintain BRAM access time.
>
>  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...
>
>
>
> > And it takes a peculiar set of non-deterministic circumstances
> > to result in an error.
>
>  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 )
>
>
>
> > But I did not think about the DCM losing lock  :-(
>
>  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

Peter wrote:
>
> Brian, there is a perfect cure: disable the clock.
>
 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