Dual Port RAM

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

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.

"maxascent" <maxascent@yahoo.co.uk> wrote in message 
news:SJ6dnWa9V6M9ftjY4p2dnA@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 

KJ wrote:
> "maxascent" <maxascent@yahoo.co.uk> wrote in message 
> news:SJ6dnWa9V6M9ftjY4p2dnA@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.

"KJ" <kkjennings@sbcglobal.net> wrote in message 
news:POF1h.1806$wX.413@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- 

For some reason when reading the original post I was reading that what
was needed was independent control of both address and data over the
multiple ports implying a certain number of memory bits accessible from
port A and another (different) number from port B.

>From the two responses it would appear that all we're talking about is
two independent data bus sizes.  Address size of the various ports is a
calculated value determined from the data bus size and memory size.

Ben Jones wrote:
> 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. :-(
>
Not sure what support you think you're not getting.  Memory can be
inferred from plain vanilla VHDL with synthesis tools.  Data bus sizing
(and the implied address bus sizing) is a wrapper around that basic
memory structure and gets synthesized just fine...so it is supported.

If what you mean by 'not supported' is that there isn't a pre-defined
instance that you can plop down into your code and parameterize, then
you're going into the Mr. Wizard territory which leads you to vendor
specific implementations.  Avoiding the vendor specific stuff is
usually a better approach in most cases.  To have vendor independent
useful modules like this, these modules should be standardized.  This
is exactly the type of thing that LPM attempted to do.  LPM languishes
as a standard though because it didn't get updated to include new and
useful modules.  Presumably this is because the FPGA vendors would
rather go the Mr. Wizard path and try to lock designers in to their
parts for irrational reasons rather than enhance standards like LPM so
that designers can remain vendor neutral at design time and let the
parts selection be based on rational reasons like cost, function and
performance.

KJ

"KJ" <Kevin.Jennings@Unisys.com> wrote in message 
news:1162303126.746950.165570@i42g2000cwa.googlegroups.com...
> From the two responses it would appear that all we're talking about is
> two independent data bus sizes.  Address size of the various ports is a
> calculated value determined from the data bus size and memory size.

Yup, that's what I would assume (since nothing else makes sense :-))

>> 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. :-(

> Not sure what support you think you're not getting.  Memory can be
> inferred from plain vanilla VHDL with synthesis tools.  Data bus sizing
> (and the implied address bus sizing) is a wrapper around that basic
> memory structure and gets synthesized just fine...so it is supported.

The *functionality* is supported, but the optimal mapping to the technology 
is not. Or wasn't last time I looked. If I write that plain vanilla VHDL, I 
have never seen a synthesis tool create an asymetrically-ported RAM from it; 
I always got a RAM with a multiplexor on the output (or worse, a bunch of 
DFFs).

> If what you mean by 'not supported' is that there isn't a pre-defined
> instance that you can plop down into your code and parameterize, then
> you're going into the Mr. Wizard territory which leads you to vendor
> specific implementations.  Avoiding the vendor specific stuff is
> usually a better approach in most cases.

In many cases, I would agree, so long as you don't end up crippling your 
design's performance as a result, and spending money on silicon features 
that you're not going to use. After all, they were put there to help you 
make your design as efficient as possible (which managers usually like).

Certainly making sure that vendor-specific functions are isolated in the 
code so they can be swapped out at will is a sensible practice. As is making 
a careful risk assessment whenever you consider using a feature that only 
one vendor or device family supports.

> Presumably this is because the FPGA vendors would
> rather go the Mr. Wizard path and try to lock designers in to their
> parts for irrational reasons

With all due respect, I think you presume too much. There are many problems 
with wizards and core generators for things like RAMs and arithmetic 
elements - mostly, they are the wrong level of abstraction for most designs. 
Nevertheless, IP cores from FPGA vendors serve two major purposes. Firstly, 
they help designers get the most out of the silicon in those cases where 
synthesis tools are not sophisticated enough to produce optimal results. 
Secondly, they allow designers to buy large blocks of standards-compliant 
IP - such as error correction cores, DDR controllers, and what have you - 
instead of designing them in-house.

I'm not denying that there is a risk of vendor lock-in, but I'd dispute that 
it's the motivating factor for vendors to develop IP. Certainly when members 
of the IP development team that I belong to here at Xilinx sit down with the 
marketing department and discuss roadmaps, the questions that come up are 
always "What are customers asking for? What is good/bad about our current 
product? What new features do we need?", not "How can we ensnare more 
hapless design engineers today?". :-)

Cheers,

         -Ben- 

Ben Jones wrote:

> > Presumably this is because the FPGA vendors would
> > rather go the Mr. Wizard path and try to lock designers in to their
> > parts for irrational reasons
>
> With all due respect, I think you presume too much.
Perhaps I do, since I don't work for the FPGA vendors I can only
speculate or presume.

> There are many problems
> with wizards and core generators for things like RAMs and arithmetic
> elements - mostly, they are the wrong level of abstraction for most designs.
Maybe.  I find there lack of a standard on the 'internal' side to be
the bigger issue.

> Nevertheless, IP cores from FPGA vendors serve two major purposes. Firstly,
> they help designers get the most out of the silicon in those cases where
> synthesis tools are not sophisticated enough to produce optimal results.
I agree, they are good at that.  I don't believe that a unique entity
is required in order to produce the optimal silicon.  Once the
synthesis hits a standardized entity name it would know to stop and
pick up the targetted device's implementation.

> Secondly, they allow designers to buy large blocks of standards-compliant
> IP - such as error correction cores, DDR controllers, and what have you -
> instead of designing them in-house.
And just exactly which standard interfaces are we talking about?  DDRs
have a JEDEC standard but the 'user' side of that DDR controller
doesn't have a standard interface.  So while you take advantage of the
IC guy's standards to perform physical interfaces, you don't apply any
muscle to standardizing an internal interface.  The ASIC guys have
their standard, Wishbone is an open specification, Altera has theirs,
Xilinx has theirs.....all the vendors have their own 'standard'.

Tell me what prevents everyone from standardizing on an interface to
their components in a manner similar to what LPM attempts to do?  The
chip guys do it for their parts, the FPGA vendors don't seem to want to
do anything similar on the IP core side.  This doesn't prevent each
company from implementing the function in the best possible way, it
simply defines a standardized interface to basically identical
functionality (i.e. it turns read and write requests into DDR signal
twiddling in the case of a DDR controller).

Can you list any 'standard' function IP where the code can be portable
and in fact is portable across FPGA vendors without touching the code?
Compression?  Image processing?  Color space converters?  Memory
interfaces? Anything?  All the vendors have things in each of those
categories and each has their own unique interface to that thing.

>
> I'm not denying that there is a risk of vendor lock-in, but I'd dispute that
> it's the motivating factor for vendors to develop IP.
I was only suggesting that it was an incentive...which you seem to
agree with.

KJ

The user community "pressures" the FPGA (and other IC) evndors to come
up with better and cheaper solutions. That's called progress. We love
it!

We respond with new and improved chip families. We get some help from
IC processing technology, i.e. "Moore's Law", especially in the form of
cost reduction, and a little bit of speed improvement (less with any
generation). We also have to fight negative effects, notably higher
leakage currents.

Real progress comes from better integration of popular functions.
That's why we now include "hard-coded" FIFO and ECC controllers in the
BlockRAM, Ethernet and PCIe controllers, multi-gigabit transceivers,
and microprocessors. Clock control with DCMs and PLLs, as well as
configurable 75-ps incremental I/O delays are lower-level examples.
These features increase the value of our FPGAs, but they definitely are
not generic.

If a user wants to treat our FPGAs in a generic way, so that the design
can painlessly be migrated to our competitor, all these powerful,
cost-saving and performance-enhancing features (from either X or A)
must be avoided. That negates 80% of any progress from generation to
generation. Most users might not want to pay that price.

And remember, standards are nice and necessary for interfacing between
chips, but they always lag the "cutting edge" by several years. Have
you ever attended the bickering at a standards meeting?...

Cutting edge FPGAs will become ever less generic.
That's a fact of life, and it helps you build better and less costly
systems.
Peter Alfke
===========

Peter Alfke wrote:
> Real progress comes from better integration of popular functions.
> That's why we now include "hard-coded" FIFO and ECC controllers in the
> BlockRAM, Ethernet and PCIe controllers, multi-gigabit transceivers,
> and microprocessors.
None of that is precluded, I'm just saying that I haven't heard why it
could not be accomplished within a standard framework.  Why would the
entity (i.e. the interface) for brand X's FIFO with ECC, Ethernet,
blah, blah, blah, not use a standard user side interface in addition to
the external standards?  Besides facilitating movement (which is not
the only concern) it promotes ease of use in the first place.

> Clock control with DCMs and PLLs, as well as
> configurable 75-ps incremental I/O delays are lower-level examples.
I agree, those are good examples of some of the easiest things that
could have a standardized interface....although I don't think you
really agree with my reading of what you wrote ;)

> These features increase the value of our FPGAs, but they definitely are
> not generic.
I said standardized not 'generic'.  I was discussing the interface to
that nifty wiz bang item and saying that the interface could be
standardized, the implementation is free to take as much advantage of
the part as it wishes.

>
> If a user wants to treat our FPGAs in a generic way, so that the design
> can painlessly be migrated to our competitor, all these powerful,
> cost-saving and performance-enhancing features (from either X or A)
> must be avoided. That negates 80% of any progress from generation to
> generation. Most users might not want to pay that price.
My point was to agree on a standard interface for given functionality
not some dumbed down generic vanilla implementation of that function.

To take an example, and using your numbers, are you suggesting that the
performance of a Xilinx DDR controller implemented using the Wishbone
interface would be 80% slower than the functionally identical DDR
controller that Xilinx has?  If so, why is that?  If not then what
point were you trying to make?

>
> And remember, standards are nice and necessary for interfacing between
> chips, but they always lag the "cutting edge" by several years.
I don't think any of the FPGA vendors target only the 'cutting edge'
designs.  I'm pretty sure that most of their revenue and profit comes
from designs that are not 'cutting edge' so that would give you those
'several years' to get the standardized IP in place.

> Have
> you ever attended the bickering at a standards meeting?...
>
Stop bickering so much.  The IC guys cooperate and march to the
drumbeat of the IC roadmap whether they think it is possible or not at
that time (but also recognizing what the technology hurdles to get
there are).  There is precedent for cooperation in the industry.

> Cutting edge FPGAs will become ever less generic.
Again, my point was standardization of the entity of the IP, not
whether it is 'generic'.

> That's a fact of life, and it helps you build better and less costly
> systems.
But not supported by anything you've said here.  Again, my point was
for a given function, why can't the interface to that component be
standardized?  Provide an example to bolster your point (as I've
suggested with the earlier comments regarding the Wishbone/Xilinx DDR
controller example).

KJ

KJ