1. Home
  2. Field-Programmable Gate Arrays
  3. BRAM synthesis question

BRAM synthesis question

Hi everyone,

While trying to build a simple VGA driver, I'm running into trouble getting my video-ram (actually, sample ram) to be synthesized as a dual port block-ram - it keeps wanting to use up 25% of my LUTs. I've tried to describe the BRAM as instructed in the xst.pdf documentation, but as soon as I try to read out the BRAM, the Synthesizer turns it into distributed RAM. I wonder if anyone would be so kind as to help me understand why?

The circuit consists of an 8 bit sampler which produces 2's complement data. It is connected to my Spartan-3 kit and I want the data to be displayed by the VGA port, as a primitive oscilloscope - just to verify that I'm getting valid data from the sampler. The display is generated by comparing the current vertical position against the sample ram contents for the current horizontal position, and drawing a pixel if they match - repeat for every position as the VGA display is scanned. This would undoubtedly benefit from more advanced concepts like double-buffering, but I'm slowly working my way up to that.

library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL;

entity main is Port (clk: in STD_LOGIC; sample: in STD_LOGIC_VECTOR(7 downto 0) red, green, blue: out STD_LOGIC)); ... end main;

architecture Behavioural of main is

type bram_type is array (511 downto 0) of signed (7 downto 0); signal BRAM: bram_type; signal BRAM_addra: unsigned (8 downto 0) := "000000000"; signal BRAM_addrb: unsigned (8 downto 0) := "000000000"; signal vert: unsigned (9 downto 0) := "0000000000";

process(clk) -- Read data from the sampler begin if(clk'event and clk='1') then ... BRAM(to_integer(BRAM_addra))

Reply to
Paul Boven
Loading thread data ...

...

Consider a fifo.

-- Mike Treseler

Reply to
Mike Treseler

see

formatting link

The read operation from a BRAM needs to be clocked. Either feed the read address through a register before using it to index the RAM, or register the output of the RAM. Either of these result in a 1 clock delay between the read address and the output data. There are code templates online in the XST users guide. Hope this helps.

Reply to
Dave

Hi Paul, Yeah, if you look at your code, you're trying to do an asynchronous read. I suggest you try simulating your design and also a design where you instantiate a block ram. You'll be able to compare and see clearly what the block ram does. HTH., Syms.

Reply to
Symon

I
e

This is not the first time that someone has tried to read the BRAM asynchronously. I have posted many times, and also inserted a sentence into our documentation that "nothing happens without a clock". Any ideas how we can spread this important (and non-obvious) information even better and wider??? Peter Alfke, Xilinx Applications

Reply to
Peter Alfke

Hi Peter,

Just rename your component from BRAM to BSRAM ! Synchronous RAM !

As a ROM based on BRAM should be renamed by BSROM. (It is not regular to have synchronous ROM, but yes it is synchronous ( need CLK clock ) too when based on Xilinx BRAM )

Regards, Laurent

formatting link

Reply to
job

The problems I see in this newsgroup are a result of hdl designers continuously reinventing templates to infer a block ram by trial and error.

If I worked for Xilinx I would write an ap note in vhdl and verilog for a useful application example that infers block ram from code, and then reference that example in all related documents.

Feel free to use my public template if you like:

formatting link

-- Mike Treseler

Reply to
Mike Treseler

sorry but you may describe LUT as asynchronous ROM ? -> No Clock !

My 0.02

Laurent

formatting link

Reply to
job

This is an FPGA is it not.

Nothing in an FPGA happens without a clock.

Why would anyone think that BRAM would operate differently ??

My .02

donald

Reply to
donald

A world wide advertising campagne include TV commercials?

"And now a serious message from our Xilinx Jedi masters: use the clock!"

--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)
Reply to
Nico Coesel

My mistake was not realizing that - of course - the data on the BRAM are not available instantaneously, but will be available at the next clock cycle, hence the need to register them. I mistakenly thought 'hey, this process block has a clock in its sensitivity list, so why is XST still claiming I'm using it asynchronously?' So I was not "tryin to read the BRAM asynchronously" as Peter wonders, just not having any idea what I was doing ;-)

Thanks for the many helpful replies.

Regards. Paul Boven.

Reply to
Paul Boven

donald wrote: (snip)

Where does this come from? There is no reason one can't do designs that don't use any FF's in an FPGA, though there is a strong incentive to use them.

Because that is the way traditional SRAMs work and people get used to using them that way. Also, most ROMs.

-- glen

Reply to
glen herrmannsfeldt

Except that SRAM traditionally means Static RAM, so one might still not notice. How about BSyRAM?

-- glen

Reply to
glen herrmannsfeldt

Hi Peter, When the synthesis software itself warns the user "The RAM will be implemented on LUTs because you have described an asynchronous read" and they still don't get it, I'm struggling to see what would be of further help? Cheers, Syms.

Reply to
Symon

it's all (public) available:

- XAPP463 ("Using BRAMs in Spartan-3 FPGA") applies also for virtex-2 and with some additions/modifications for the newer virtex parts.

- In the xilinx "synthesis and simulation guide" chapter 4, page 152 pp, there are some (usefull) generic HDL code examples: How to implement a "generic BRAM" in VHDL and/or verilog.

WD

Reply to
Walter Dvorak

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.