Prev: Have you experience to program the APA series using FlashPro Lite?
Next: xilkernel cache
From: Martin Thompson on 1 Nov 2006 05:46
"KJ" <Kevin.Jennings(a)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(a)trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html


From: Andy on 1 Nov 2006 11:40
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.

From: Andy Peters on 1 Nov 2006 12:22
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

From: Andy Peters on 1 Nov 2006 12:29
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

From: KJ on 1 Nov 2006 23:02

"Peter Alfke" <alfke(a)sbcglobal.net> wrote in message
news:1162345630.497517.281500(a)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


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Have you experience to program the APA series using FlashPro Lite?
Next: xilkernel cache