Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How different is a FIFO from a RAM and a ROM in terms of behavioral coding from a synthesis point of view?

319 views
Skip to first unread message

Sreenivas Durbha

unread,
Mar 10, 1999, 3:00:00 AM3/10/99
to

h:(606)323-2199
o:(606)425-3684

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

phil_j...@my-dejanews.com

unread,
Mar 11, 1999, 3:00:00 AM3/11/99
to
Not sure I understand your question. Also, to me behavioral means code that
is written for it's behavior, not synthesis. It may or may not be
synthesizable. We refer to our synthesizable code as RTL code not behavioral.
No big deal, just semantics.

If I were to code FIFO, RAM, or ROM, for synthesis, I would probably be
examining what types of embedded memory the device I am trageting has
(Altera, Xilinx, ASIC, etc). In my experience, you have to code at a very low
level to implement embedded memory. It depends on the vendor's synthesis
library. In one design I did, I had to instantiate each memory block, then
connect them to form a larger memory (I was using DP RAM for use as a FIFO in
a UART model). Very painful, and not very transportable.

If I were writing behavioral code, I would simply use and array. For a ROM,
it will need to be initialized to the known (programmed) values before use.
For RAM, FIFO, you would probably not want to initialize it, as that is how
actual H/W would work (you would read 'X's from it until it was written to).
It depends on what you want to accomplish.

Good Luck,
PJ

In article <7c6tav$j0b$1...@nnrp1.dejanews.com>,

winsome24

unread,
Mar 11, 1999, 3:00:00 AM3/11/99
to
Hi, In lieu of your response I would like to ask one more thing. You said
that you had to describe your memory at a very low level for it to
synthesize. Here, what I am doing is trying to synthesize a RAM, ROM and FIFO
modules (veritably small ones) onto an ORCA2C40 FPGA chip but at the same
time trying to minimize the code as much as possible. Starting at rtl
(behavioral for functional purposes) level I am trying to do it. Doing it at
the structural level was easy from the coding point of view but I did
encounter problems with pin assignment etc. Now I am trying to do the same
memory at a higher level of abstraction. If anyone has experience please
help. Thank you. SD

In article <7c71pv$n5q$1...@nnrp1.dejanews.com>,

El

unread,
Mar 11, 1999, 3:00:00 AM3/11/99
to
In article <7c6tav$j0b$1...@nnrp1.dejanews.com>,
Sreenivas Durbha <wins...@my-dejanews.com> wrote:
>
>
> h:(606)323-2199
> o:(606)425-3684
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
>

Well,

In when using FPGA's, in some cases you can instantiate the FIFO as an LPM
function (look at the ALTERA's csfifo function), but be carful with the
working conditions (as number of clocks per rd/wr operation).

The other way is to use a synchronous dual ported ram from model: In case of
ALTERA it's an LPM function. In case of ORCA - you must run a model generator
called SCUBA. Be aware of that you have to select if you want a simulation or
for synthesis model, and don't forget to switch the models before synthesis
(it's better practice to choose them by the PACKAGE declaration). Of course,
before simulating, you have to compile the model and instantiate it in your
fifo architecture. Then, the rest of the design i usually create 2 counters :
write and read up cyclic pointers. The fifo status pointer is a modulo
substraction of the 2 counters.

!!! the read and write clocks are different !!!
it looks like this (the following code was part of a design before i cutted it
out. it was cutted without checking it !!!) - :
=============================================
ARCHITECTURE behave OF fifo32x4 IS
SIGNAL ram_datain, ram_dataout : std_logic_vector (3 downto 0);
SIGNAL ram_wren : std_logic;
SIGNAL wr_ptr, rd_ptr : std_logic_vector (6 downto 0);
SIGNAL fifo_status_int : std_logic_vector(7 downto 0);
SIGNAL fifo_half_full_flag : std_logic;

component RAM32x4 == DPR model, created by SCUBA. The model should be compiled
port
(
waddr : in std_logic_vector(4 downto 0);
datain : in std_logic_vector(3 downto 0);
clk : in std_logic;
wren : in std_logic;
raddr : in std_logic_vector(4 downto 0);
dataout : out std_logic_vector(3 downto 0)
);
end component;

BEGIN
RAM1 : RAM32x4 == DPR instantiating
port map
(
waddr => wr_ptr(4 downto 0),
datain => ram_datain, == input to the FIFO
clk => wr_clk,
wren => ram_wren,
raddr => rd_ptr(4 downto 0),
dataout => ram_dataout == output from FIFO
);

WRITE_PTR : PROCESS(rst_x,wr_clk)
BEGIN
IF (rst_x='0') THEN
wr_ptr <= "00000";
ram_wren <= '0';
ELSIF (wr_clk'EVENT AND wr_clk='1') THEN
IF (wr_en='1') THEN
wr_ptr <= wr_ptr + 1;

IF (wr_ptr(1)='1' AND wr_ptr(0)='0') THEN
ram_wren <= '1';
ELSE
ram_wren <= '0';
END IF;
ELSE
wr_ptr <= wr_ptr;
ram_wren <= '0';
END IF;
END IF;
END PROCESS;

READ_PTR : PROCESS(rst_x,rd_clk)
BEGIN
IF (rst_x='0') THEN
rd_ptr <= "00000";
ELSIF (rd_clk'EVENT AND rd_clk='1') THEN
IF (rd_en='1') THEN
rd_ptr <= rd_ptr + 1;
ELSE
rd_ptr <= rd_ptr; -- hold state
END IF;
END IF;
END PROCESS;

fifo_status_int(5 downto 0) <= ('0' & wr_ptr(4 downto 0)) - ('0' &
rd_ptr(4 downto 0));

fifo_half_full_flag <= fifo_status_int(5); == polarity bit

Assaf Sarfati

unread,
Mar 11, 1999, 3:00:00 AM3/11/99
to
Sreenivas Durbha wrote:
> How different is a FIFO from a RAM and a ROM in terms of behavioral coding from a synthesis point of view?

>
> h:(606)323-2199
> o:(606)425-3684
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

A FIFO is usually a dual-port RAM with separate counters for read and
write address plus logic to determine the FIFO's state (empty, full,
half-full).

If you use a predefined macro, it had been probably implemented
internally in this way; if you design your own, your code/schematics
depends on your chip's internal RAM and your synthesis tools.

Some chips have dual-port RAM, some have single-port RAM (which requires
some sort of access arbiter) and some don't have RAM (and then you will
have to wastefully implement the storage with registers).

Some tools can convert a high-level entity (array of bits etc.) to RAM;
other tools may have to have the RAM as an external black box.

If the FIFO is an important part of your design, use a chip with
internal dual-port RAM; try to find tools which can infer RAM from
higher-level code to make behavioral simulations easier.

Regards
Assaf Sarfati

El

unread,
Mar 11, 1999, 3:00:00 AM3/11/99
to
In article <7c7nhn$9jb$1...@nnrp1.dejanews.com>,
> > In article <7c6tav$j0b$1...@nnrp1.dejanews.com>,
> > Sreenivas Durbha <wins...@my-dejanews.com> wrote:
> > >
> > >
> > > h:(606)323-2199
> > > o:(606)425-3684
> > >
> > > -----------== Posted via Deja News, The Discussion Network ==----------
> > > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
> > >
> >
> > -----------== Posted via Deja News, The Discussion Network ==----------
> > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
> >
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
>

Why should you work so hard ?
The better way to produce a Sync. DPR for ORCA2 device, is to run the SCUBA
software from your ORCA FOUNDARY design package.
Note that SCUBA may produce model for simulation or for synthesis.

The SCUBA usualy produces the most optimized model for DPR.

Good luck....

0 new messages