OpenCores
URL https://opencores.org/ocsvn/single_port/single_port/trunk

Subversion Repositories single_port

Compare Revisions

  • This comparison shows the changes necessary to convert path 
    /
    from Rev 7 to Rev 8
    ↔ Reverse comparison
  •

Rev 7 → Rev 8

/trunk/doc/single_port.html
1,21 → 1,21
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta http-equiv="CONTENT-TYPE"
content="text/html; charset=iso-8859-1">
<title></title>
<meta name="GENERATOR" content="StarOffice/5.2 (Win32)">
<meta name="AUTHOR" content="Robert Paley">
<meta name="CREATED" content="20020728;14095738">
<meta name="CHANGEDBY" content="Robert Paley">
<meta name="CHANGED" content="20020728;15514460">
<style>
 
<!--
29,214 → 29,218
</style>
</head>
<body>
<p align="right"><font size="3"></font></p>
<p align="right"><font size="3"></font></p>
<h1 style="text-align: center;"><font size="4" style="font-size: 16pt;">Description
<h1 style="text-align: center;"><font size="4" style="font-size: 16pt;">Description
of single_port memory and test environment.</font></h1>
<h2>Abstract: </h2>
<p><span style="">A VHDL simulation model for an asynchronous single port
memory is described. The memory is implemented as three different architectures,
a simple one and 2 ones which are optimized for efficient use of simulator
memory. Data and address buses are unconstrained, so multiple instances with
different address and data bus widths can be implemented in one single design.
</span>A testbench is also provided.<br>
</p>
<p><span style="">A VHDL simulation model for an asynchronous single port
memory is described. The memory is implemented as three different architectures,
a simple one and 2 ones which are optimized for efficient use of simulator
memory. Data and address buses are unconstrained, so multiple instances
with different address and data bus widths can be implemented in one single
design. </span>A testbench is also provided.<br>
</p>
<h2>Port Interface:</h2>
<table width="757" border="1" cellpadding="5" cellspacing="4">
<col width="108"> <col width="118"> <col width="483"> <thead> <tr
<col width="108"> <col width="118"> <col width="483"> <thead> <tr
valign="top">
<th width="108">
<th width="108">
<p>Port Name</p>
</th>
<th width="118">
</th>
<th width="118">
<p>Type</p>
</th>
<th width="483">
</th>
<th width="483">
<p>Description</p>
</th>
</tr>
</thead> <tbody>
<tr valign="top">
<td width="108">
</th>
</tr>
</thead> <tbody>
<tr valign="top">
<td width="108">
<p>rnwtQ</p>
</td>
<td width="118">
</td>
<td width="118">
<p>Time</p>
</td>
<td width="483">
</td>
<td width="483">
<p>Time delay from rnw = read until data appears on q data bus.</p>
</td>
</tr>
<tr valign="top">
<td width="108">
</td>
</tr>
<tr valign="top">
<td width="108">
<p>d</p>
</td>
<td width="118"> STD_LOGIC_VECTOR<br>
</td>
<td width="483">
</td>
<td width="118"> STD_LOGIC_VECTOR<br>
</td>
<td width="483">
<p>Input data bus,&nbsp;unconstrained</p>
</td>
</tr>
<tr valign="top">
<td width="108">
</td>
</tr>
<tr valign="top">
<td width="108">
<p>q</p>
</td>
<td width="118">
</td>
<td width="118">
<p>STD_LOGIC_VECTOR<br>
</p>
</td>
<td width="483">
</p>
</td>
<td width="483">
<p>Output data bus,&nbsp;unconstrained</p>
</td>
</tr>
<tr valign="top">
<td width="108">
</td>
</tr>
<tr valign="top">
<td width="108">
<p>a</p>
</td>
<td width="118">
</td>
<td width="118">
<p>STD_LOGIC_VECTOR<br>
</p>
</td>
<td width="483">
</p>
</td>
<td width="483">
<p>Address bus, unconstrained</p>
</td>
</tr>
<tr valign="top">
<td width="108">
</td>
</tr>
<tr valign="top">
<td width="108">
<p>rnw</p>
</td>
<td width="118">
</td>
<td width="118">
<p>STD_LOGIC</p>
</td>
<td width="483">
</td>
<td width="483">
<p>Read not write port</p>
</td>
</tr>
<tr valign="top">
<td width="108">
</td>
</tr>
<tr valign="top">
<td width="108">
<p>dealloc_mem</p>
</td>
<td width="118">
</td>
<td width="118">
<p>BOOLEAN</p>
</td>
<td width="483">
</td>
<td width="483">
<p>When set to true, deallocate linked list memory.</p>
</td>
</tr>
</tbody>
</td>
</tr>
</tbody>
</table>
<h2>Functional Description:</h2>
<p><span style="">The first architecture is called ArrayMemNoFlag, and implements
the memory core as an array of STD_LOGIC_VECTOR. This is the simplest architecture.
It is provided for comparison with the models below but not recommended
for use in your design.<o:p></o:p></span></p>
<p><span style="">The second architecture is called ArrayMem, and implements
the memory core as an array of BIT_VECTOR. This arrangement allows less
workstation memory to be used than the ArrayMemNoFlag architecture. Use
this architecture if most addresses in the simulated memory are written
at least once.<o:p></o:p></span></p>
<span style="">The third architecture is called LinkedList, and implements
the memory core as a linked list of arrays of BIT_VECTOR. Each array in
the linked list is a page of memory whose size is specified with the constant
PAGEDEPTH in the package linked_list_mem_pkg. This arrangement allows less
workstation memory to be used than either the ArrayMemNoFlag or ArrayMem
architectures because memory representing the array data is only allocated
if the memory is actually written to. To de-allocate the memory in the linked
list, set dealloc_mem to true. Use this architecture if a significant portion
of your simulated memory (which need not be contiguous) is never written
to.<br>
<br>
All 3 architectures are asynchronous and triggered with any change of </span><span
style="">d, a or rnw</span> (and dealloc_mem for the LinkedList architecture).
<span style="">When rnw = '0', the data on bus "d" is loaded into the memory
at the location specified by the addres bus "a". When rnw = '1', the data
located in memory address "a" is loaded onto the output data bus "q". If
a memory location is read which was not written to during the current simulation,
'U's are loaded onto the memory bus.</span><br>
<p><span style="">The first architecture is called ArrayMemNoFlag, and implements
the memory core as an array of STD_LOGIC_VECTOR. This is the simplest architecture.
It is provided for comparison with the models below but not recommended for
use in your design.<o:p></o:p></span></p>
<p><span style="">The second architecture is called ArrayMem, and implements
the memory core as an array of BIT_VECTOR. This arrangement allows less workstation
memory to be used than the ArrayMemNoFlag architecture. Use this architecture
if most addresses in the simulated memory are written at least once.<o:p></o:p></span></p>
<span style="">The third architecture is called LinkedList, and implements
the memory core as a linked list of arrays of BIT_VECTOR. Each array in the
linked list is a page of memory whose size is specified in single_port_pkg.
This arrangement allows less workstation memory to be used than either the
ArrayMemNoFlag or ArrayMem architectures because memory representing the array
data is only allocated if the memory is actually written to. To de-allocate
the memory in the linked list, set dealloc_mem to true. Use this architecture
if a significant portion of your simulated memory (which need not be contiguous)
is never written to.<br>
<br>
All 3 architectures are asynchronous and triggered with any change of </span><span
style="">d, a or rnw</span> (and dealloc_mem for the LinkedList architecture).
<span style="">When rnw = '0', the data on bus "d" is loaded into the memory
at the location specified by the addres bus "a". When rnw = '1', the data
located in memory address "a" is loaded onto the output data bus "q". If a
memory location is read which was not written to during the current simulation,
'U's are loaded onto the memory bus.</span><br>
<h2>Functional Timing:</h2>
<p><span style="">The single port memory is asynchronous and is triggered
on any change of d, a or rnw. When rnw is cleared to '0', the write occurs
at the same time as rnw'transaction. When a read occurs, with rnw = '1'
, data appears on the Q bus rnwtQ ns after rnw is set to '1'. The below
sample timing diagram illustrates both a read and write operation.</span><br>
</p>
<p><span style="">The single port memory is asynchronous and is triggered
on any change of d, a or rnw. When rnw is cleared to '0', the write occurs
at the same time as rnw'transaction. When a read occurs, with rnw = '1' ,
data appears on the Q bus rnwtQ ns after rnw is set to '1'. The below sample
timing diagram illustrates both a read and write operation.</span><br>
</p>
<p><img src="../images/timing.jpg" name="Graphic1" align="left"
width="958" height="251" border="0">
<br clear="left">
</p>
<br clear="left">
</p>
<h2>Testbench Description:</h2>
<p>The test bench is arranged as a client server architecture as specified
by Bergeron<a class="sdfootnoteanc" name="sdfootnote1anc"
href="#sdfootnote1sym"><sup>1</sup></a>. A diagram illustrating the testbench
is given below.<br>
<br>
<img src="../images/tbschematic.jpg" name="Graphic2" align="left"
<p>The test bench is arranged as a client server architecture as specified
by Bergeron<a class="sdfootnoteanc" name="sdfootnote1anc"
href="#sdfootnote1sym"><sup>1</sup></a>. A diagram illustrating the testbench
is given below.<br>
<br>
<img src="../images/tbschematic.jpg" name="Graphic2" align="left"
width="838" height="371" border="0">
<br clear="left">
Two tests are specified in tc_single_port component. The first test writes
data to two logical memory pages, and then reads them back verifying the correct
data. The test case writes an error message to the console for every miscompare.
The second case verifies that the single_port memory model outputs unknowns
to the q bus if a read occurs for an unwritten memory location. Six configurations
are specified in the test bench architecture tb_single_port, running both
tests for each single_port architecture. <br>
</p>
<br clear="left">
Two tests are specified in tc_single_port component. The first test writes
data to two logical memory pages, and then reads them back verifying the
correct data. The test case writes an error message to the console for every
miscompare. The second case verifies that the single_port memory model outputs
unknowns to the q bus if a read occurs for an unwritten memory location.
Six configurations are specified in the test bench architecture tb_single_port,
running both tests for each single_port architecture. <br>
</p>
<h2>Usage:</h2>
<p>A Makefile is used to compile and run all of the tests in a Unix or like
environment, such as Cygwin. The compilation and simulation is targetted to
the SymphonyEDA tool available at <a href="http://www.symphonyeda.com">www.symphonyeda.com</a>.</p>
<p>A Makefile is used to compile and run all of the tests in a Unix or like
environment, such as Cygwin. The compilation and simulation is targetted
to the SymphonyEDA tool available at <a
href="http://www.symphonyeda.com">www.symphonyeda.com</a>.</p>
<p>The source files and Makefile are located in {top}/VHDL<br>
<br>
To compile: make com</p>
<br>
To compile: make com</p>
<p>To simulate all of the tests: make sim<br>
</p>
</p>
<p>To clean the compiled library: make clean</p>
<p>The tests are labeled :</p>
<ul>
<li>ll_error</li>
<li>ll_main</li>
<li>mem_main<br>
</li>
<li>mem_error<br>
</li>
<li>memnoflag_main<br>
</li>
<li>memnoflag_error<br>
</li>
<li>ll_error</li>
<li>ll_main</li>
<li>mem_main<br>
</li>
<li>mem_error<br>
</li>
<li>memnoflag_main<br>
</li>
<li>memnoflag_error<br>
</li>
</ul>
<p>To simulate any of these tests, type make {testname}</p>
<p>Please contact Robert Paley at <a href="mailto:rpaley_yid@yahoo.com">rpaley_yid@opencores.org</a>
or Michael Geng at <a href="mailto:vhdl@michaelgeng.de">vhdl@michaelgeng.de</a>
if you have any questions or comments. </p>
<div id="sdfootnote1">
<p>Please contact Robert Paley at <a href="mailto:rpaley_yid@yahoo.com">rpaley_yid@opencores.org</a>
or Michael Geng at <a href="mailto:vhdl@michaelgeng.de">vhdl@michaelgeng.de</a>
if you have any questions or comments. </p>
<div id="sdfootnote1">
<p class="sdfootnote" style="margin-bottom: 0.2in;"><a
class="sdfootnotesym" name="sdfootnote1sym" href="#sdfootnote1anc">1</a>Writing
Testbenches , Functional Verification of HDL Testbenches. Chapter 6 &#8211;
ISBN 0-7923-7766-4</p>
</div>
class="sdfootnotesym" name="sdfootnote1sym" href="#sdfootnote1anc">1</a>Writing
Testbenches , Functional Verification of HDL Testbenches. Chapter 6 &#8211; ISBN
0-7923-7766-4</p>
</div>
<br>
<br>
<br>
</body>
/trunk/VHDL/linked_list_mem_pkg.vhd
48,6 → 48,9
-- CVS Revision History
--
-- $Log: not supported by cvs2svn $
-- Revision 1.2 2005/10/12 19:39:27 mgeng
-- Buses unconstrained, LGPL header added
--
-- Revision 1.1.1.1 2003/01/14 21:48:10 rpaley_yid
-- initial checkin
--
63,6 → 66,7
USE WORK.single_port_pkg.all;
 
PACKAGE linked_list_mem_pkg IS
CONSTANT PAGEDEPTH : INTEGER := 256; -- memory page depth
-- pointer to one data word in the memory
-- The reason for using a pointer here is that it seems to be the only way to keep the model
-- independent of the data width
69,8 → 73,8
TYPE data_ptr IS ACCESS BIT_VECTOR;
-- data memory array type definition
TYPE mem_array_typ IS ARRAY (0 TO PAGEDEPTH-1) OF data_ptr;
-- Define memory page linked list cell. This cell contains,
-- the mem_array, starting page address, valid data array, and
-- Define memory page linked list cell. This cell contains
-- the mem_array, starting page address, valid data array and
-- the pointer to the next element in the linked list.
TYPE mem_page_typ;
-- pointer to next item in the linked list.
90,7 → 94,7
 
END PACKAGE linked_list_mem_pkg;
 
PACKAGE BODY LINKED_LIST_MEM_PKG IS
PACKAGE BODY linked_list_mem_pkg IS
-- --------------------------------------------------
-- The purpose of this procedure is to write a memory location from
-- the linked list, if the particular page does not exist, create it.
167,4 → 171,4
deallocate(delete_cell_v); -- Deallocate current cell from memory.
END LOOP;
END PROCEDURE deallocate_mem;
END PACKAGE BODY LINKED_LIST_MEM_PKG;
END PACKAGE BODY linked_list_mem_pkg;
/trunk/VHDL/single_port_pkg.vhd
47,6 → 47,9
-- CVS Revision History
--
-- $Log: not supported by cvs2svn $
-- Revision 1.3 2005/10/25 18:26:52 mgeng
-- PAGENUM constant removed because the address bus width provides this information
--
-- Revision 1.2 2005/10/12 19:39:27 mgeng
-- Buses unconstrained, LGPL header added
--
63,18 → 66,17
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.NUMERIC_STD.ALL;
 
PACKAGE single_port_pkg IS
CONSTANT PAGEDEPTH : INTEGER := 256; -- memory page depth
-- Address bus type for internal memory
SUBTYPE addr_typ IS NATURAL;
-- Operations testbench can do.
TYPE do_typ IS ( init , read , write , dealloc , end_test );
PACKAGE single_port_pkg IS
-- Address bus type for internal memory
SUBTYPE addr_typ IS NATURAL;
-- Operations testbench can do.
TYPE do_typ IS ( init , read , write , dealloc , end_test );
 
TYPE to_srv_typ IS RECORD -- Record passed from test case to test bench
do : do_typ;
addr : INTEGER;
data : INTEGER;
event : BOOLEAN;
TYPE to_srv_typ IS RECORD -- Record passed from test case to test bench
do : do_typ;
addr : INTEGER;
data : INTEGER;
event : BOOLEAN;
END RECORD to_srv_typ;
END PACKAGE single_port_pkg;
 

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.