Prev: Have you experience to program the APA series using FlashPro Lite?
Next: xilkernel cache
From: KJ on 1 Nov 2006 23:34

"Martin Thompson" <martin.j.thompson(a)trw.com> wrote in message
news:ulkmv8mwx.fsf(a)trw.com...
> "KJ" <Kevin.Jennings(a)Unisys.com> writes:
>
>
> More like it was an Altera-driven "standard" that Xilinx never
> supported, so it never got to be vendor independent.
>
But it is a standard issued by a recognized body. But I've yet to hear what
is soooo burdensome about LPM that it couldn't be supported...'specially
since there aren't that many 'useful' functions in there to begin with. And
technically speaking I believe Xilinx 'does' support LPM, but from what I
hear, not very well.

We should be way beyond standardizing on things as low level as the LPM
stuff....but we're not....

KJ


From: KJ on 1 Nov 2006 23:36

"Ray Andraka" <ray(a)andraka.com> wrote in message
news:wXT1h.25863$v81.58(a)newsfe18.lga...
> 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
<snip>
I was misinterpreting the original post as wanting to independently vary
address and data widths. Bus resizing for various reasons has many
applications, I agree.

KJ


From: Peter Alfke on 1 Nov 2006 23:39
The issue is with hard-coded blocks.
Soft logic can be changed, manipulated, improved, reduced to your
heart's desire.
Hard-coded logis is the way it is.
If we implement a standard, that's it. Nobody can modify it without
seriously affecting performance.
If we had not implemented "first-word-fall-through" in the FIFO
controller,(we did), it would have been almost impossible to add,
without serious performance loss.
We do think about these things, but very often there is not "one
standard". And if you implement one way, the other method suffers.
These designs are not incremental, it is very easy to burn your
bridges.
And iti srather unlikely that brand A will pick exactly the same
size/speed/power/versatility trade-off that we at brand X do.
So much for standards. They come with their own bag of trade-offs,
usually reduced speed and increased complexity. Very easy to see in
memory-related circuits (like FIFOs). We had a self-imposed edict: It
has to work at 550 MHz, worst-case at the fastest speed grade.
Otherwise we went back to the drawing board. Same thing for the DSP
highly-glorified multiplier/accumulators.
If you add a 1-ns external gate to a 550 MHz design, the performance
drops to 355 MHz. Math is brutal. Very few people like that. Dedicated
logic is fast and small, patches are slow and big. That's life.
Peter Alfke

On Nov 1, 8:02 pm, "KJ" <kkjenni...(a)sbcglobal.net> wrote:
> "Peter Alfke" <a...(a)sbcglobal.net> wrote in messagenews: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

From: Martin Thompson on 2 Nov 2006 04:58
"KJ" <kkjennings(a)sbcglobal.net> writes:

> "Martin Thompson" <martin.j.thompson(a)trw.com> wrote in message
> news:ulkmv8mwx.fsf(a)trw.com...
> > "KJ" <Kevin.Jennings(a)Unisys.com> writes:
> >
> >
> > More like it was an Altera-driven "standard" that Xilinx never
> > supported, so it never got to be vendor independent.
> >
> But it is a standard issued by a recognized body. But I've yet to hear what
> is soooo burdensome about LPM that it couldn't be supported...'specially
> since there aren't that many 'useful' functions in there to begin
> with.

That's true - my *impression* at the time (which was around 2000) was
that Xilinx didn't want to make migration between vendors too easy.
That's just my impression mind, I don't know what actually went on.
Based on what I read around the LPM website.

> And technically speaking I believe Xilinx 'does' support LPM, but
> from what I hear, not very well.
>

That's interesting - any idea how?

> We should be way beyond standardizing on things as low level as the LPM
> stuff....but we're not....
>

In some ways we are - I've never instantiated an LPM_COUNTER, an
incrementing variable does the job for me :-)

Cheers,
Martin

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


From: KJ on 2 Nov 2006 06:23

"Martin Thompson" <martin.j.thompson(a)trw.com> wrote in message
news:uhcxi890m.fsf(a)trw.com...
> "KJ" <kkjennings(a)sbcglobal.net> writes:
>
>> "Martin Thompson" <martin.j.thompson(a)trw.com> wrote in message
>> news:ulkmv8mwx.fsf(a)trw.com...
>> > "KJ" <Kevin.Jennings(a)Unisys.com> writes:
>> >
>> >
>> > More like it was an Altera-driven "standard" that Xilinx never
>> > supported, so it never got to be vendor independent.
>> >
>> But it is a standard issued by a recognized body. But I've yet to hear
>> what
>> is soooo burdensome about LPM that it couldn't be supported...'specially
>> since there aren't that many 'useful' functions in there to begin
>> with.
>
> That's true - my *impression* at the time (which was around 2000) was
> that Xilinx didn't want to make migration between vendors too easy.
> That's just my impression mind, I don't know what actually went on.
> Based on what I read around the LPM website.
>
>> And technically speaking I believe Xilinx 'does' support LPM, but
>> from what I hear, not very well.
>>
>
> That's interesting - any idea how?

No, just from the (possibly misguided) impression that I got over the years.
Googling would seem to indicate that you're correct that they don't have any
support for it directly but Synplify does support LPM, so you can get LPM on
X by using S (which is what I was thinking since I do have and use S).
Googling a bit more and you'll see that Lattice and Actel both claim to
support it.

One of the hits that I got on the Xilinx site gives the following two
defintions for 'LogiBLOX' and 'LPM'. The word for word match in the
definitions would seem to indicate that something petty (or perceived
protection of the turf) is keeping them apart.

http://www.xilinx.com/publications/products/cpld/logic_handbook.pdf

LogiBLOX - Formerly called X-Blox. Library of logic modules, often with
user-definable

parameters, like data width. Very similar to LPM.

LPM - Library of Parameterized Modules. Library of logic modules, often with
userdefinable

parameters, like data width. Very similar to LogiBlox.

>
>> We should be way beyond standardizing on things as low level as the LPM
>> stuff....but we're not....
>>
>
> In some ways we are - I've never instantiated an LPM_COUNTER, an
> incrementing variable does the job for me :-)
>
Yeah....in many ways I don't like holding up LPM since most of what is in
there is nothing I would instantiate simply because it is (and always has
been) too low level and easier to infer directly in the code. It is an
example though of a standard that had the basic idea of what I'd like to see
happening....just not high enough functionality and didn't get updated to
add new stuff to match what is going on in the world.

KJ


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