FPGA Groups

FPGA Groups (http://www.fpgacentral.com/group/index.php)
-   FPGA (http://www.fpgacentral.com/group/forumdisplay.php?f=14)
-   -   Inferring Dual Port Block RAM (http://www.fpgacentral.com/group/showthread.php?t=50769)

Tom Hawkins 11-14-2003 06:22 PM

Inferring Dual Port Block RAM
 
Is it possible to infer a dual port block RAM
when the ports have different memory dimensions?

Say port A has address and data width of 8 and 8,
while port B has address and data with of 9 and 4,
for instance.

Instead of using a 2 dimensional array, one could
define one long array then do appropriate
bit selection off the 1D array for addressing:

reg [0:2047] memory; // 256x8 or 512x4.

Port A Addressing (pseudo code):

memory[addr_a * 8 : addr_a * 8 + 7]
// Invalid Verilog, I know.

Port B Addressing:

memory[addr_b * 9 : addr_b * 9 + 3]


Or another, more Verilog friendly way, would be to
use a 2D array with the data as the least common denominator:

reg [3:0] memory [0:512]; // 512x4

Port A Addressing:

{memory[{addr_a, 1b'0}], memory[{addr_a, 1b'1}]}

Port B Addressing:

memory[addr_b]


Has anyone had success inferring asymmetric dual-port
block ram?

-Tom

--
Tom Hawkins
Launchbird Design Systems, Inc.
952-200-3790
http://www.launchbird.com/

Mike Treseler 11-14-2003 07:55 PM

Re: Inferring Dual Port Block RAM
 
Tom Hawkins wrote:
> Is it possible to infer a dual port block RAM
> when the ports have different memory dimensions?


It's possible to infer a single-direction dual
port ram from code, but the dimensions are
restricted by the device block size.

Brand X devices and brand A stratix devices have
real dual-port ram available, but last I checked,
synthesis punts on inference.

> Say port A has address and data width of 8 and 8,
> while port B has address and data with of 9 and 4,
> for instance.
>
> Instead of using a 2 dimensional array, one could
> define one long array then do appropriate
> bit selection off the 1D array for addressing:


If a single-direction design is ok, you could
certainly infer some legal sized blocks and wrap
logic around them to handle your byte selects.

For a true dual port, you might have to instance
the blocks.

-- Mike Treseler



Mark van de Belt 11-14-2003 08:47 PM

Re: Inferring Dual Port Block RAM
 

"Tom Hawkins" <[email protected]> schreef in bericht
news:[email protected] om...
> Is it possible to infer a dual port block RAM
> when the ports have different memory dimensions?
>
> Say port A has address and data width of 8 and 8,
> while port B has address and data with of 9 and 4,
> for instance.
>
> Instead of using a 2 dimensional array, one could
> define one long array then do appropriate
> bit selection off the 1D array for addressing:
>
> reg [0:2047] memory; // 256x8 or 512x4.
>
> Port A Addressing (pseudo code):
>
> memory[addr_a * 8 : addr_a * 8 + 7]
> // Invalid Verilog, I know.
>
> Port B Addressing:
>
> memory[addr_b * 9 : addr_b * 9 + 3]
>
>
> Or another, more Verilog friendly way, would be to
> use a 2D array with the data as the least common denominator:
>
> reg [3:0] memory [0:512]; // 512x4
>
> Port A Addressing:
>
> {memory[{addr_a, 1b'0}], memory[{addr_a, 1b'1}]}
>
> Port B Addressing:
>
> memory[addr_b]
>
>
> Has anyone had success inferring asymmetric dual-port
> block ram?
>
> -Tom
>
> --
> Tom Hawkins
> Launchbird Design Systems, Inc.
> 952-200-3790
> http://www.launchbird.com/


Hello Tom,

I have created asymmetric blockrams, but always with the aid of library
components or IP cores. I have posted a similar question yesterday for some
VHDL code.

The only problem with the asymmetric blockrams is the translation of the
bits to the addresses on the smaller port. I have found that the LSB's of
the smaller port (port B in your example) must be inverted to get the MSB's
of the port A on the lowest addresses on the B port (MSB of port A first on
the output of port B)

Mark van de Belt




All times are GMT +1. The time now is 12:35 PM.

Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved