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

VHDL model with dynamic memory allocation

1,034 views
Skip to first unread message

Gerhard Angst

unread,
Jan 29, 1997, 3:00:00 AM1/29/97
to


Hello,

A friend of me is looking for a VHDL RAM Model
that uses dynamic memory allocation in order
to provide low Simulation-Memory consumption
when the RAMs are getting larger.

Does anyone know where I can find some example code ?

Thanks,
Gerhard Angst
g...@concept.de

Bert Molenkamp

unread,
Jan 30, 1997, 3:00:00 AM1/30/97
to

g...@concept.de (Gerhard Angst) writes:
>
>
> Hello,
>
> A friend of me is looking for a VHDL RAM Model
> that uses dynamic memory allocation in order
> to provide low Simulation-Memory consumption
> when the RAMs are getting larger.
>
> Does anyone know where I can find some example code ?
>
>


package memory_types is
type mem;
type pointer is access mem;
type mem is
record
address : natural;
content : integer;
nxt : pointer;
end record;
procedure search_address(variable current : inout pointer; addr : in natural);
procedure read_memory (variable location : inout pointer; signal data : out integer);
procedure write_memory (variable location : inout pointer; data : in integer);
end memory_types;

package body memory_types is
procedure search_address(variable current : inout pointer; addr : in natural) is
variable previous : pointer := null;
begin
while current.address < addr and current.nxt /= null loop
previous := current;
current := current.nxt;
end loop;
-- current.address >= addr or end reached
if current.address /= addr
then
if current.address < addr
then -- append at end of list
current.nxt := new mem'(addr,0,null);
current:=current.nxt;
else -- insert in list
previous.nxt := new mem'(addr,0,previous.nxt);
current := previous.nxt;
end if;
end if;
end search_address;

procedure read_memory (variable location : inout pointer; signal data : out integer) is
begin
data <= location.content;
end read_memory;

procedure write_memory (variable location : inout pointer; data : in integer) is
begin
location.content:=data;
end write_memory;
end memory_types;


use work.memory_types.all;
entity memory is
port (RWn : in bit;
address : in natural;
data_in : in integer;
data_out : out integer);
end memory;

architecture behaviour of memory is
begin
process (RWn,address,data_in)
variable location : pointer := null;
variable root : pointer := new mem'(0,0,null);
begin
location:=root;
search_address(location,address);
if RWn='0' then -- write to memory
write_memory(location,data_in);
end if;
read_memory(location,data_out);
end process;
end behaviour;


Egbert Molenkamp
Dept. of Computer Science
University of Twente
PO Box 217
7500 AE Enschede
the Netherlands
email: mole...@cs.utwente.nl

jos de laender vh14 7461

unread,
Jan 30, 1997, 3:00:00 AM1/30/97
to

In article <5cpmii$e...@pandora.cs.utwente.nl>,

mole...@donau.cs.utwente.nl (Bert Molenkamp) writes:
|> g...@concept.de (Gerhard Angst) writes:
|> >
|> >
|> > Hello,
|> >
|> > A friend of me is looking for a VHDL RAM Model
|> > that uses dynamic memory allocation in order
|> > to provide low Simulation-Memory consumption
|> > when the RAMs are getting larger.
|> >
|>


This uses a simple linked list to store the memory contents.
I would only prefer this (fairly simple) solution if you don't expect
too many entries (= occupied addresses) during your simulation.

If you do expect this, you should use some (balanced) binary tree
scheme
to store the entries, because then the lookup time increases only
log2(N), while in the simple list it grows N.

I once implemented such a balanced binary tree for that same purpose.
(In fact I used a partly balanced variant, called Red-Black tree) I'm
not able to give you the code, but it was a quite direct implementation
starting from following (very good) algorithms book :

-- The RB-tree algorithm is explained clearly in
-- 'Introduction to Algorithms' by
-- Cormen/Leiserson/Rivest (MIT 1990)

Kind regards,

ir. Jos De Laender
Alcatel Bell
Antwerp, Belgium

Kenji Iwamura

unread,
Feb 3, 1997, 3:00:00 AM2/3/97
to Gerhard Angst

Gerhard Angst wrote:
> A friend of me is looking for a VHDL RAM Model
> that uses dynamic memory allocation in order
> to provide low Simulation-Memory consumption
> when the RAMs are getting larger.
>
> Does anyone know where I can find some example code ?

Hi,

Hamburg VHDL Archive has a SRAM model which uses dynamic
memory allocation. Visit the below URL.

http://tech-www.informatik.uni-hamburg.de/vhdl/models/sram/sram.html

There is also a static memory allocation version of SRAM model.
I once tried the static one.

Both models are depending on Synopsys' std_logic_arith and/or
std_logic_unsigned packages, so you need the Synopsys packages
to analyze them.

Regards,
--
Kenji Iwamura
Texas Instruments Japan Limited | k-iw...@ti.com

Jon Connell

unread,
Feb 6, 1997, 3:00:00 AM2/6/97
to

jos de laender vh14 7461 wrote:
>
> In article <5cpmii$e...@pandora.cs.utwente.nl>,
> mole...@donau.cs.utwente.nl (Bert Molenkamp) writes:
> |> g...@concept.de (Gerhard Angst) writes:
> |> > A friend of me is looking for a VHDL RAM Model
> |> > that uses dynamic memory allocation in order
> |> > to provide low Simulation-Memory consumption
> |> > when the RAMs are getting larger.
> |> >
> This uses a simple linked list to store the memory contents.
> I would only prefer this (fairly simple) solution if you don't expect
> too many entries (= occupied addresses) during your simulation.
>
> If you do expect this, you should use some (balanced) binary tree
> scheme
> to store the entries, because then the lookup time increases only
> log2(N), while in the simple list it grows N.

Why not use a four dimensional array where each dimension represents
8 bits of the 32-bit address? Every time you need a new segment,
you can allocate 256 bytes of memory on the fly. Slicing the
input address into a four element array slice is easy and the whole
thing will be really fast.

No source. Just an idea...
--
Advice, n.: the smallest current coin.
-- Ambrose Bierce, "The Devil's Dictionary"

E-Mail : Jon.C...@hl.siemens.de
WWW : http://homepages.munich.netsurf.de/Jonathan.Connell/
Fax : +49 89 4133-2692 | Tel : +49 89 4133-2687

Jeff Koehler

unread,
Feb 10, 1997, 3:00:00 AM2/10/97
to

Kenji Iwamura wrote:

>
> Gerhard Angst wrote:
> > A friend of me is looking for a VHDL RAM Model
> > that uses dynamic memory allocation in order
> > to provide low Simulation-Memory consumption
> > when the RAMs are getting larger.
> >

We are using a model from RAVIcad that stores the rows of an SGRAM in
separate files. I cannot give you code snippets, but you can contact
them at:
RAVIcad Inc.
408.720.6120 USA (California)

Perhaps you could implement the idea yourself. Keep in mind this will
create
a large number of files, and may be inefficient in terms of resources
other than memory. It may, however, allow you to model a relatively
large
memory space.

Jak

---
+---+---+---+---+---+---+tm Jeff Koehler
||koe...@tsath.lkg.dec.com
| | | | | | | Hub Products Engineering ||
------------------------
| d | i | g | t | a | l | Networking Prod. Business|| Go Packers
!!
| | | | | | | Littleton, Mass. U.S.A. || (Reggie deserves a
ring)
+---+---+---+---+---+---+ 508.486.5356 ||
------------------------

vhdl...@aol.com

unread,
Feb 11, 1997, 3:00:00 AM2/11/97
to

>> Gerhard Angst wrote:
>> > A friend of me is looking for a VHDL RAM Model
>> > that uses dynamic memory allocation in order
>> > to provide low Simulation-Memory consumption
>> > when the RAMs are getting larger.
>> >

I have a RAM model that uses dynamic memory allocation in the book
"VHDL Answers to Frequently Asked Questions". Check my web site
for TOC.
--=============================================
-- Ben Cohen, Hughes Aircraft Co, RE- R1/B507
-- ** "VHDL Coding Styles and Methodologies",
-- ISBN 0-7923-9598-0 Kluwer Academic Publishers, 1995.
-- ** "VHDL Answers to Frequently Asked Questions"
-- ISBN 0-7923-9791-6 Kluwer Academic Publishers, 1997.
-- FTP site: users.aol.com /vhdlcohen/vhdl
-- Web page: http://members.aol.com/vhdlcohen/vhdl
-- (310) 334-7389, fax: (310) 334-1749
--=============================================


0 new messages