Use BRAM as ROM (Xilinx)
Lancer
is it possible to use Spartan 3 BRAM (on my xc3s1000 it should be
432K) as a ROM memory for data storage or folder mounting under
PetaLinux?
How to do this under EDK 8.1?
Thanks
Regards
Lancer
Peter Alfke
then use the BRAM as a ROM, just by never writing new information into
it.
But remember:
Reading from a BRAM is a synchronous operation. You must supply a
clock, and the Data output changes only after the rising edge of the
clock.
Also, in order to guarantee the integrity of the ROM content, you
should not change the addresses during the set-up time window before
the clock, while CE is active. (WE inactive is not sufficient to
protect against all address set-up time violations). This is not
intuitively obvious.
Peter Alfke, Xilinx
=======================
Mike Treseler
> is it possible to use Spartan 3 BRAM (on my xc3s1000 it should be
> 432K) as a ROM memory for data storage
I make ROMs like this:
http://home.comcast.net/~mike_treseler/sync_rom.vhd
-- Mike Treseler
Allan Herriman
wrote:
>Also, in order to guarantee the integrity of the ROM content, you
>should not change the addresses during the set-up time window before
>the clock, while CE is active. (WE inactive is not sufficient to
>protect against all address set-up time violations). This is not
>intuitively obvious.
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
Antti
> You can define the BRAM content through configuration, and you can
> then use the BRAM as a ROM, just by never writing new information into
> it.
> But remember:
> Reading from a BRAM is a synchronous operation. You must supply a
> clock, and the Data output changes only after the rising edge of the
> clock.
> Also, in order to guarantee the integrity of the ROM content, you
> should not change the addresses during the set-up time window before
> the clock, while CE is active. (WE inactive is not sufficient to
> protect against all address set-up time violations). This is not
> intuitively obvious.
> Peter Alfke, Xilinx
> =======================
> On May 24, 7:07 am, Lancer <peppe...@gmail.com> wrote:
>
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
johnp
Antti -
As I recall, V2Pro has a similar corruption "feature" for the BRAMS.
John Providenza
Antti
>
> - Zitierten Text anzeigen -
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
Brian Davis
>
> 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).
>
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
[1] some posts from 2005 "Important BRAM Safety Tip" thread
http://groups.google.com/group/comp.arch.fpga/msg/458bb7a6301318d9
http://groups.google.com/group/comp.arch.fpga/msg/8db1a95b422f744a
http://groups.google.com/group/comp.arch.fpga/msg/67b112027f71ade8
Allan Herriman
[snip]
Thanks for that Brian. This solved a 3 year old bug that I had never
been able to explain before.
Regards,
Allan
Peter Alfke
customer problem, many years after we had shipped the first BRAM. I
then documented it and made sure that the appropriate statements got
into the datasheet/UserGuide.
It is an obscure problem (You have to have CE active nd then violate
the Address set-up time, which you would NOT normally do when you want
to read consistent data).
But I did not think about the DCM losing lock :-(
I am convinced that the problem is in all Virtex and Spartan devices
(if I learn differently, I will post here. This is a day before a
holiday...)
I never consider this a fatal flaw, it is really inherent to the BRAM
design. And it takes a peculiar set of non-deterministic circumstances
to result in an error. And I also do not see any fix that would
maintain BRAM access time.
That's why I brought this to your attention, in our documentation, as
well as in this thread.
I will keep you informed about any developments in this area.
Peter Alfke, Xilinx Applications
On May 25, 1:31 pm, Allan Herriman <allanherri...@hotmail.com> wrote:
Brian Davis
>
> I am convinced that the problem is in all Virtex and Spartan devices
>
>
> 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
Peter Alfke
The problem can only occur when the clock is enabled.
Peter
pontus.s...@gmail.com
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
Brian Davis
>
> Brian, there is a perfect cure: disable the clock.
>
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