Use BRAM as ROM (Xilinx)

Hi all,
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

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:
> Hi all,
> 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

Lancer wrote:

> 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

On 24 May 2007 07:35:52 -0700, Peter Alfke <alfke@sbcglobal.net>
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

On 24 Mai, 16:35, Peter Alfke <a...@sbcglobal.net> wrote:
> 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:
>
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

On May 25, 12:11 am, Antti <Antti.Luk...@googlemail.com> wrote:
> On 24 Mai, 16:35, Peter Alfke <a...@sbcglobal.net> wrote:
>
> > 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:
>
> 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

On 25 Mai, 16:33, johnp <johnp3+nos...@probo.com> wrote:
> On May 25, 12:11 am, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
>
>
> > On 24 Mai, 16:35, Peter Alfke <a...@sbcglobal.net> wrote:
>
> > > 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:
>
> > 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- Zitierten Text ausblenden -
>
> - 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

Alan wrote:
>
> 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

On 25 May 2007 10:57:53 -0700, Brian Davis <brimdavis@aol.com> wrote:
[snip]

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

Regards,
Allan

I was part of the team that found the problem, in response to a
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:
> On 25 May 2007 10:57:53 -0700, Brian Davis <brimda...@aol.com> wrote:
> [snip]
>
> Thanks for that Brian.  This solved a 3 year old bug that I had never
> been able to explain before.
>
> Regards,
> Allan