From: maxascent on

Hi I am trying to infer a Xilinx dual port block ram with different
address and data widths. I want to infer it in my code and then get
Synplify to recognise it. I can do this if the address and data are the
same but dont know how if they are different.

Thanks

J
From: John_H on
Wmaxascent wrote:
> Hi I am trying to infer a Xilinx dual port block ram with different
> address and data widths. I want to infer it in my code and then get
> Synplify to recognise it. I can do this if the address and data are the
> same but dont know how if they are different.
>
> Thanks
>
> J

When I recently asked the Synplicity folks if there was *any*
appropriate syntax to imply different widths for Synplify inferred
memories, I was told there was none.
From: KJ on

"maxascent" <maxascent(a)yahoo.co.uk> wrote in message
news:SJ6dnWa9V6M9ftjY4p2dnA(a)giganews.com...
>
> Hi I am trying to infer a Xilinx dual port block ram with different
> address and data widths. I want to infer it in my code and then get
> Synplify to recognise it. I can do this if the address and data are the
> same but dont know how if they are different.

I'm completely missing out on what possible use it would be to have
different address widths.....memory needs to be addressed, if you give it a
partial address just what do you think should come out? Simple example
would be a 3 bit address on one port and a 2 bit address on the other. On
the one port you can go from 000 to 111 the other from 00 to 11....so what
do you want coming out of the memory when the two bit address is set to 00?
The data that is located at memory 000? Or the data from 100? I think if
you'll ponder on this for a bit you'll realize that different address widths
make no logical sense at all.

In any case, what you need to do is size your dual port memory to a single
address and data size. Next put a wrapper around it that
1. Instantiates the dual port memory
2. Adds whatever logic you require to define the mapping between the
different data bus sizes.

KJ


From: Andy Ray on
KJ wrote:
> "maxascent" <maxascent(a)yahoo.co.uk> wrote in message
> news:SJ6dnWa9V6M9ftjY4p2dnA(a)giganews.com...
>> Hi I am trying to infer a Xilinx dual port block ram with different
>> address and data widths. I want to infer it in my code and then get
>> Synplify to recognise it. I can do this if the address and data are the
>> same but dont know how if they are different.
>
> I'm completely missing out on what possible use it would be to have
> different address widths.....memory needs to be addressed, if you give it a



As well as different address widths the ports have different data widths
and depths as viewed from each port. The same number of bits are
accessible from both ports.

It can be useful in avoiding mux's but I tend to find requires direct
instantiation of the appropriate block ram component: RAMB16_Sm_Sn.

Cheers,

Andy.
From: Ben Jones on

"KJ" <kkjennings(a)sbcglobal.net> wrote in message
news:POF1h.1806$wX.413(a)newssvr12.news.prodigy.com...
>
> I'm completely missing out on what possible use it would be to have
> different address widths.....memory needs to be addressed, if you give it
> a partial address just what do you think should come out? Simple example
> would be a 3 bit address on one port and a 2 bit address on the other. On
> the one port you can go from 000 to 111 the other from 00 to 11....so what
> do you want coming out of the memory when the two bit address is set to
> 00? The data that is located at memory 000? Or the data from 100?

Both, surely?

Imagine a 64-bit RAM with two ports. One port has 6 bits of address and 1
bit of data; the other has 1 bit of address and 32 bits of data. On address
port A, you put a value 0-63 and you get the single corresponding bit of the
contents. On address port B, you put a value 0-1 and you get either bits
0-31 or bits 32-63 of the contents. Generalize to whatever widths you want.

I'm not sure why none of the synthesis tools support this, but it's true,
they don't. I've always ended up instantiating something to get this
behaviour. :-(

Cheers,

-Ben-