Dual Port RAM

I only claimed that you lose 80% of the performance improvement of the
next generation (I mean differentally), not 80% of the whole
performance.

This debate can go on and on. I suppose we both made our points...
Peter

On Oct 31, 12:33 pm, "KJ" <Kevin.Jenni...@Unisys.com> wrote:
> > 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?
> 
> 
>

KJ, You like standards.
We just finished implementing PCIexpress. When I look at the complexity
of that standard, I just cringe. I cannot fathom why one needs so much
stuff to communicate data. But then I am old frugal and basic guy who
believes in simplicity.
Talking about a FIFO, what other standard interface do you want, except
data-in, data-out, 2 clocks, 2 enables, 4 flags and perhaps a reset?
Isn't that about as generic as it can get? Why would Altera do it
differently, except that they don't have a hard-coded 550 MHz one...
:-(
I vote for smarter synthesis tool that interprete your intentions in
the best possible way.
Peter Alfke

On Oct 31, 12:33 pm, "KJ" <Kevin.Jenni...@Unisys.com> wrote:
> 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

KJ,

This is actually a fairly common usage  model for the Xilinx dual port 
RAMs. It lets you, for example store two words per clock on one port and 
read them one word per clock on the opposite port at perhaps a faster 
clock rate. The data width and address width vary inversely so that 
there are always 18k or 16K bits in the memory (18K for the widths that 
support the parity bit).  For example, if you set one port for 36 bit 
width, that port has a depth of 512 words.  If you then set the other 
port for 18 bit width, it has a 1K depth, and the extra address bit (the 
  extra bits are added at the lsbs) essentially selects the low or high 
half of the 36 bit width for access through the 18 bit port.  Similarly, 
a 9 bit wide port is 2K deep and accesses a 9 bit slice of that 36 bit 
word for each access, with the slice selected with the 2 lsbs of the 9 
bit wide port's address.

I've found the easiest way to deal with the dual port memories is to 
instantiate the primitives.  Xilinx has made it far easier with the 
virtex 4 which has a common BRAM element for all aspect ratios with 
generics on it to define the width.  Previously, you needed to 
instantiate the specific primitive with the right aspect ratios on each 
port.  I found it easiest to develop a wrapper for the memory that uses 
the width of the address and data to select the BRAM aspect ratio and 
instantiate as many as are needed to obtain the data width, that way the 
hard work is done just once.  This is especially true with the older 
style primitives.

There is also a way to use the two ports as two completely independent
half-size RAMs, by making sure thet the two ports never overlap their
addressing. The division does not even have to be 50:50 and the widths
can differ, as can clock and enables. There is some room for
creativity...
Peter Alfke

On Oct 31, 6:49 pm, Ray Andraka <r...@andraka.com> wrote:
> KJ,
>
> This is actually a fairly common usage  model for the Xilinx dual port
> RAMs. It lets you, for example store two words per clock on one port and
> read them one word per clock on the opposite port at perhaps a faster
> clock rate. The data width and address width vary inversely so that
> there are always 18k or 16K bits in the memory (18K for the widths that
> support the parity bit).  For example, if you set one port for 36 bit
> width, that port has a depth of 512 words.  If you then set the other
> port for 18 bit width, it has a 1K depth, and the extra address bit (the
>   extra bits are added at the lsbs) essentially selects the low or high
> half of the 36 bit width for access through the 18 bit port.  Similarly,
> a 9 bit wide port is 2K deep and accesses a 9 bit slice of that 36 bit
> word for each access, with the slice selected with the 2 lsbs of the 9
> bit wide port's address.
>
> I've found the easiest way to deal with the dual port memories is to
> instantiate the primitives.  Xilinx has made it far easier with the
> virtex 4 which has a common BRAM element for all aspect ratios with
> generics on it to define the width.  Previously, you needed to
> instantiate the specific primitive with the right aspect ratios on each
> port.  I found it easiest to develop a wrapper for the memory that uses
> the width of the address and data to select the BRAM aspect ratio and
> instantiate as many as are needed to obtain the data width, that way the
> hard work is done just once.  This is especially true with the older
> style primitives.

Peter Alfke wrote:

> KJ, You like standards.
> We just finished implementing PCIexpress. When I look at the complexity
> of that standard, I just cringe. I cannot fathom why one needs so much
> stuff to communicate data. But then I am old frugal and basic guy who
> believes in simplicity.

Could this have been made any faster, by relaxing some of the standard ?
(and would that have a cost, like interopability ?)

-jg

"KJ" <Kevin.Jennings@Unisys.com> writes:

<snip>

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

More like it was an Altera-driven "standard" that Xilinx never
supported, so it never got to be vendor independent.

Hmmm, maybe we should all get together and write a Xilinx LPM
library....

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

Surely not :-)

Cheers,
Martin
-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

   

"KJ" <Kevin.Jennings@Unisys.com> wrote in message 
news:1162320665.907686.101530@h48g2000cwc.googlegroups.com...
>
> Ben Jones wrote:
>
>> 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.

For the smaller "building block" components, I'd say that's not much of an 
issue at all. After all, how many different interfaces can you think of for 
an accumulator or shift register? Most of the differences between vendors 
seem to be superficial (e.g. naming) at that level. The problem I have with 
these low-level blocks is that they go against the basic principle of 
abstraction; instead of hiding complex functions behind simple interfaces, 
they do the exact opposite. And they hold back designers by perpetuating the 
"TTL 7400" design mentality.

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

I think that would be great. Of course, vendors' in-house synthesis tools 
are unlikely to support that kind of system except for portability between 
their own device families.

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

I don't think anything prevents it, other than whatever all-pervading force 
there is in the universe which prevents people from agreeing about things. 
:-)

The OpenFPGA initiative have a working group on core interfacing. There's 
LPM (obsolete IMHO). There's OCP. There's no shortage of people proposing 
ideas for standard interfaces, but there is a shortage of time, money and 
energy to do anything about it. I think you'll find most engineers in favour 
of standardization to some extent, but there's no one single driving force 
for adoption. Some people also see it as a barrier to innovation. (It isn't, 
but still, some people see it that way.)

> 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?

No. But I'm willing to bet that any engineer worth their salt would be able 
to write the appropriate glue logic to convert one to the other without 
working up a sweat.

In some cases, for example if a customer is using a processor-based system 
design environment such as Platform Studio (X) or SOPC builder (A), the 
"proprietary" interface to (say) a DDR SDRAM controller is hidden away, to a 
great extent, because the tools provide a system-level abstraction.

One thing that greater standardization would do is make it much easier for 
third-party IP core developers to create and sell vendor-agnostic IP. If 
that really is a viable business model nowadays...

Here's another thought - in many industries (e.g. consumer electronics and 
eletricals) the quality of the interface is a big differentiating factor for 
the purchaser. Why shouldn't this be true for digital interfacing standards 
too? A customer might have a preference for a CoreConnect-based system over 
an AMBA-based system, or vice versa, based on which of the interface's 
features are relevant to their needs.

BTW I'm not sure how much of this I really fervently believe in, just trying 
to illuminate the issue a bit.

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

I would only say it's a question inertia, rather than malice. On a related 
note, what do engineers hate more - risk of vendor lock-in, or breaking of 
backwards compatibility?

It's certainly an interesting issue!

         -Ben- 

The main reason I don't instantiate memory primitives is because of the
restrictions on address and data types (to SLV). I usually have an
integer subtype for the address (the array index when inferring
memory), and store anything from integer to enumerated (i.e. state
variables) to whole records in them. You can't do that with the
primitives, without putting a wrapper around it, and then when you try
to examine the contents of the memory during simulation, they're all
just bits, and you have to manually convert back to your record, enum,
etc. Inferring memory from arrays, especially in applications where the
memory is not tied to some sort of pre-existing data and address bus,
also allows a more functional descriptive style, rather than an
implementation-specific style. I focus on the behavior first, then
tweak the implementation to get the performance I need (if any tweaking
is needed).

The syntesis tools have started recognizing sub-word write enables in
inferred memories, which allows inferring memories with wider data
paths on the output than the input, now they just need to recognize
muxing on the output to allow inferring memories with wider inptuts
than outputs.

Andy


Ray Andraka wrote:
> KJ,
>
> This is actually a fairly common usage  model for the Xilinx dual port
> RAMs. It lets you, for example store two words per clock on one port and
> read them one word per clock on the opposite port at perhaps a faster
> clock rate. The data width and address width vary inversely so that
> there are always 18k or 16K bits in the memory (18K for the widths that
> support the parity bit).  For example, if you set one port for 36 bit
> width, that port has a depth of 512 words.  If you then set the other
> port for 18 bit width, it has a 1K depth, and the extra address bit (the
>   extra bits are added at the lsbs) essentially selects the low or high
> half of the 36 bit width for access through the 18 bit port.  Similarly,
> a 9 bit wide port is 2K deep and accesses a 9 bit slice of that 36 bit
> word for each access, with the slice selected with the 2 lsbs of the 9
> bit wide port's address.
>
> I've found the easiest way to deal with the dual port memories is to
> instantiate the primitives.  Xilinx has made it far easier with the
> virtex 4 which has a common BRAM element for all aspect ratios with
> generics on it to define the width.  Previously, you needed to
> instantiate the specific primitive with the right aspect ratios on each
> port.  I found it easiest to develop a wrapper for the memory that uses
> the width of the address and data to select the BRAM aspect ratio and
> instantiate as many as are needed to obtain the data width, that way the
> hard work is done just once.  This is especially true with the older
> style primitives.

KJ wrote:

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

EXACTLY.

The few times I needed an SDRAM interface, I had to write it myself.
Everyone has example interface cores and such, but mostly they're
tailored to talk to a generic microprocessor bus.  If your logic
doesn't work that way, then you spend more time fighting the generic
back-end interface and it ends up being faster to write the whole
module yourself.

-a

Peter Alfke wrote:
> KJ, You like standards.
> We just finished implementing PCIexpress. When I look at the complexity
> of that standard, I just cringe. I cannot fathom why one needs so much
> stuff to communicate data. But then I am old frugal and basic guy who
> believes in simplicity.

It's designed to ease the job of the person writing the host driver,
and, more important, the end user stuffing the card into his no-name
PC.  Making an interface generic enough to be usable over a wide range
of disparate uses isn't trivial.  USB and FireWire are the same way:
complexity for the engineers allows simplicity for the users.

You'd rather we go back to jumpers or DIP switches for I/O card base
address select?   Why should the end user care about where the card
lives in the address space?

-a