Dual Port RAM

Ben Jones wrote:

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

A netlist of familiar blocks will always
be the starting point for some. But this
is a self-limiting design method because
it does not scale well and is hard to simulate.
A designer that sticks with it will
eventually learn how describe the same
output ports with HDL and simulation.

About all a vendor can do about this
is to provide some non-trivial examples
that show how to make the RTL viewer draw
the schematics to an HDL spec. (hint)

The biggest roadblock to portability
are the RAM and FIFO blocks that are not
describable in RTL because of asynchronous
arbitration. I would much prefer to do
my own arbitration *and* infer a simpler block.

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

I can. A synch fifo using one read port and one
write port from an inferred dpram.

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

Me too.

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

Ay, there's the rub.
Those who write portable code want it all portable.
Those cursed with a crusty but popular design will pray
for a part that covers all the old gizmos.

         -- Mike Treseler

Mike I do not doubt that you can design your own asynchronous
arbitration logic, but is that what you want to spend your time on?
Ditto with Hamming-code error correction, and Ethernet controllers and
PCIexpress. And do you want to stop us from "hardening" these
functions, where they take a tenth of the area, and some run twice as
fast as the soft equivalent?
And do you think the many less experienced users want to do this?
Sorry for the rhetorical question...
Peter Alfke, Xilinx Applications

On Nov 1, 11:16 am, Mike Treseler <mike_trese...@comcast.net> wrote:
> > The biggest roadblock to portability
> are the RAM and FIFO blocks that are not
> describable in RTL because of asynchronous
> arbitration. I would much prefer to do
> my own arbitration *and* infer a simpler block.
> 
>

Peter Alfke wrote:
> Mike I do not doubt that you can design your own asynchronous
> arbitration logic, but is that what you want to spend your time on?

No. I would probably waste a tick, and synch things up.

> Ditto with Hamming-code error correction, and Ethernet controllers and
> PCIexpress. And do you want to stop us from "hardening" these
> functions, where they take a tenth of the area, and some run twice as
> fast as the soft equivalent?

No. I was talking about RAM functions.

> And do you think the many less experienced users want to do this?

With your existing tools.


       -- Mike Treseler

Mike, the RAM-support circuits (FIFO controller and ECC) each take
about a tenth of the area and run twice as fast as you (or anybody
else) could design them in the fabric. We do our best to eliminate the
inefficiency of programmable logic in those fairly standardized
functions where flexibility is hardly needed. That's how we improve
performance and reduce chip size.
You know that of course...
Peter Alfke

On Nov 1, 11:52 am, Mike Treseler <mike_trese...@comcast.net> wrote:
> Peter Alfke wrote:
> > Mike I do not doubt that you can design your own asynchronous
> > arbitration logic, but is that what you want to spend your time on?No. I would probably waste a tick, and synch things up.
>
> > Ditto with Hamming-code error correction, and Ethernet controllers and
> > PCIexpress. And do you want to stop us from "hardening" these
> > functions, where they take a tenth of the area, and some run twice as
> > fast as the soft equivalent?No. I was talking about RAM functions.
>
> > And do you think the many less experienced users want to do this?With your existing tools.
> 
>        -- Mike Treseler

Hi

Just to clear up any confusion as to what I wanted in the first place. I
was looking to use a dual port ram with different address and data widths
on side a and b. I have checked with Synplicity and it is currently not
possible to infer a ram of this type. So you need to use Coregen instead.
Apparently they are looking at implementing it in a future release.

Cheers

 

Ray Andraka gave the pertinent answer to your question. The rest of us
meandered about...
Peter

On Nov 1, 12:11 pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> Hi
>
> Just to clear up any confusion as to what I wanted in the first place. I
> was looking to use a dual port ram with different address and data widths
> on side a and b. I have checked with Synplicity and it is currently not
> possible to infer a ram of this type. So you need to use Coregen instead.
> Apparently they are looking at implementing it in a future release.
> 
> Cheers

maxascent wrote:
> Hi
> 
> Just to clear up any confusion as to what I wanted in the first place. I
> was looking to use a dual port ram with different address and data widths
> on side a and b. I have checked with Synplicity and it is currently not
> possible to infer a ram of this type. So you need to use Coregen instead.
> Apparently they are looking at implementing it in a future release.

Coregen would be overkill to create the RAM. As Mr. Andraka mentioned, 
just instantiate the primitives. Way easier.

"Peter Alfke" <alfke@sbcglobal.net> wrote in message 
news:1162345630.497517.281500@h48g2000cwc.googlegroups.com...
> 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.
But again, you're probably standards compliant on the physical pin side but 
what about on the 'other' side?  A communication's bridge exists because it 
connects TWO disparate interfaces, so what is the standard interface that is 
used internal to the FPGA that you're bridging over to PCIexpress?

And I agree with you about frugality.  The 'internal to the chip' standard 
interface should be something robust yet something that when used in simple 
comm situations reduces down (via the magic of synthesis logic optomization) 
to something darn close to the bare minimum.  Certainly there are cases 
where anything over the bare minimum might be too much, but those tend to be 
exceptions (i.e. relatively small logic that can be hand optomized in the 
grand scheme of the entire FPGA design).

> 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...
OK, let's discuss the fifo.  Specifically let's take the EIA standard 
lpm_fifo.  That entity defines the input for a hunk-o-code that implements a 
fifo.  If I instantiate an lpm_fifo and target that to the appropriate 
Xilinx part will I get that 550 MHz performance?  If so, then you've 
provided an example of where standardizing on the interface is a 'good' 
thing.  If not, then can you explain what is so burdensome about the entity 
definition of lpm_fifo that makes that 550 MHz unachievable?

We're not talking about getting extra functionality, we're talking about 
getting the same function.  The synthesis operation, once it saw 'lpm_fifo' 
and targetting brand X could know that there is a hard coded thingy to 
implement it....that's what we pay the synthesis tool to do, right?

Now granted the 'lpm_fifo' is not necessarily the best and grandest thing to 
talk about optomizing but you brought up the fifo.  Things like controllers 
come to mind as well (i.e. I2C, DDR, SDRAM, PCI, blah, blah, blah).  Many of 
these are really communication's bridges that hook two different busses 
together to exchange information.  One one side (the physical pin side) we 
have all the standards, on the other side...well...a bit lacking (IMO) in 
calling things a standard....and yet things like Wishbone or Avalon or what 
have you that were all thought through of as being an 'inside the chip' comm 
bus really do synthesize and logically optomize quite well.

After getting over the worry (if there is any) about people jumping ship 
because their code could now be truly portable to brand A, B, C.... you 
should also recognize that it would also be a productivity improvement 
because it would improve code reuse and aid in simply division of labor 
because you wouldn't have these ad hoc, "let me pass you this signal it will 
happen two clock cycles before that" type of thing.

Perhaps instead of bantering about specific examples that we each seem to 
think bolster our points you can give us the Xilinx view of
- Standardized internal interfaces, good for business?  (Xilinx that is)
- What standards work for these internal interfaces are you compliant with?
- What push for improving these standards are you participating in?

In my view this internal interface should scale well (i.e. not get 
burdensome in wasting logic resources in the synthesized design) if I want 
to use it inside a VHDL architecture to communicate between processes all 
the way up to it being an external interface (if I so choose).

> I vote for smarter synthesis tool that interprete your intentions in
> the best possible way.
So do I.

KJ 

"Ben Jones" <ben.jones@xilinx.com> wrote in message 
news:eia1b7$dfm1@cnn.xsj.xilinx.com...
>
> "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.
No, I'm thinking of bigger blocks...the things you wouldn't want to have to 
write the code for because it is just a sub-function of the overall design. 
Bridges to SDRAM, DDR, PCI, compression, image processing and security 
algorithms.  Not your simple TTL type of stuff.

>
>>> 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.
Why not?  Once they see the standardized entity called 'ddr_controller' they 
would instantiate their own hard coded IP algorithm for talking to the 
bloody thing.  I'm not interested in re-inventing the wheel, just in reusing 
that wheel.

>> 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. :-)
But it's not really an all-pervading force.  If it were we wouldn't have any 
standards like PCI, I2C, PCI Express, DDR....on and on and on.  So where is 
the list of interface standards for inside the chip?  Wishbone is about it 
for FPGAs...and it needs some work but it's not bad.  So do the big guys all 
support Wishbone?  Build it into their system design tools? 
Ummmm....well....no....what do they support?  Well, here is the Brand A 
'standard', brand X standard etc.
>
> 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.)
I agree

>
>> 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.
And I'll bet that any engineer worth their salt would also rather not keep 
re-inventing the wheel and doing needless bus translators.

>
> 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.
Yes, they all have their own way of making our lives 'easier'....in their 
minds at least.

>
> 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.
Choosing a standard based on features and performance that are relevant is 
exactly the right thing.  That's not what you're basing your decision on 
between 'X' and 'A'.

KJ 

"Mike Treseler" <mike_treseler@comcast.net> wrote in message 
news:4qsa4oFoka7cU1@individual.net...
>
>>> 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?
>
> I can. A synch fifo using one read port and one
> write port from an inferred dpram.

But you didn't answer the question....reworded to 'What is the name of that 
standard IP'?  lpm_fifo is the only one that I can think of that fits your 
functional description.  Writing the function yourself (while you may want 
to do it anyway) does not qualify it as a 'standard'.  You write good code 
Mike, but not everything you write is ready to be called a standard ;)

KJ