DSP algorithm implementations for FPGA systems
Thank you, Altera (from all of the IC Designers here at Xilinx).
The DSP block looks interesting. Guess that is case of keeping up with
All in all, this part looks like a huge improvement over earlier
families. It still doesn't address the SRL16 capabilities, which I use
not only for the many small delays found in typical DSP designs, but
also to provide a capability for reloading LUT contents. This part is
certainly usable for DSP, and closes the gap between the big 2
Austin Lesea wrote:
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
And thanks for ranting and raving :-)
Ray Andraka wrote: [excerpt]
Do you mean that you can configure a logic element as an SRL16, load
it with bits, then reconfigure it as something other than an SRL16?
Without doing "normal" partial reconfiguration of the device?
Nope. Configure as an SRL16, shift in 16 bits, then use the address inputs
to select 1-of-16, exactly as a LUT configuration selects 1-of-16.
Eric Smith wrote:
And I'm sure the folks at Altera that came up with Block RAMs, embedded
SerDes and LVDS, the Nios soft processor, the on-die hard-core (ARM)
processor, and the entire MAX product family would like to thank you for
your recognition of their ideas.
Let's face it, there are many good reasons why these two companies are at
the top of the programmable-logic heap. Both have come up with some very
good ideas and both have taken ideas from the competition and improved on
them. As Muzaffer Kal said:
"Isn't competition great?"
Thanks Xilinx. ;)
Rick "rickman" Collins
Ignore the reply address. To email me use the above address with the XY
Please ask Peter for translation.
Seriously, we didn't invent them, we just placed them in a fabric, and
supported them in the FPGA. And as it turns out, you can get a patent for
just that kind of assembly of non patentable items arranged in a new or
novel way together to perform an improved function. Altera, and we have
lots of patents, and now that the legal hassling is over, we can apply all
of our efforts to supplying our customers with the best possible products.
I appeciate all of the comments, and it is absolutely critical that Xilinx
listen to customers, because that is what we did with Virtex, and Virtex II
(and are still doing).
No time to fiddle around, I have the next two product generations to help
design, document, and support.
Austin, pls don't work get too frustrated in you efforts to come out
with CDR and a workable embedded processor solution in the next
Both companies have been innovative and have a range of firsts.
Basically being first just gives a time to market advantage which is
followed by the other company following. Sad to see Xilinx
ppl(engineers??) stoop to altera bashing.
Oder wie sie sagen in Rom:
(Ich kann Deutschen lesen, Danke)
(But excuse my written German, as I am not up to the colloquialisms or
I am having a little fun, but I am too busy now, so you too, have some fun.
I'm happy to see both sides of the (multi-sided) coin represented in the newsgroup
and appreciate the visits by the folks close to the silicon and the tools (even
Synplicity's CTO, Ken McElvain visits on occasion).
Austin Lesea <austin...@xilinx.com> wrote in message
(my father was from Sibu, Romania, and spoke 7 languages. I did not inherit
much of his talents, I am afraid)
Some people sometime miss the fact, that german lost the vote for the
american language by just one vote. . . . .
A lot of people in Germany tried to tell me this story when I lived there,
aber die Geschichte ist einfach nicht wahr. Here's an excerpt from The
"... switching to a language other than English, but it's not known how
serious this was--probably not very. Nonetheless there's a 150-year-old
legend that English was almost replaced, not by Hebrew but by German.
Supposedly it lost by one vote, cast by a German-speaking Lutheran minister
named Frederick Muhlenberg. Some say the vote took place in the Pennsylvania
legislature and that Muhlenberg voted against it because he didn't want
Pennsylvania to be isolated from the rest of the nation. Another version,
commonly heard in Germany, says the proposal would have passed except that a
German-speaking legislator went to the toilet at the crucial moment.
It never happened, of course. In the 18th century German speakers
constituted a significant fraction of the population only in Pennsylvania
(remember the Pennsylvania Dutch?), and even the most fanatical British
haters weren't crazy enough to think they could change the national language
by legislative fiat. But the story isn't pure invention. Here's what really
happened, courtesy of Dennis Baron, professor of English at the University
of Illinois at Urbana-Champaign:
In 1794 a group of German speakers in Virginia petitioned Congress to
publish federal laws in German as well as English. The intention was not to
supplant English but simply to supplement it. A House committee recommended
publishing German translations of the laws, but on January 13, 1795, "a vote
to adjourn and sit again on the recommendation" (apparently an attempt to
keep the measure alive rather than killing it immediately) failed by a vote
of 42-41. Frederick Muhlenberg (1750-1801) was in fact Speaker of the House
at the time, but how he voted is unknown. Tradition has it that he stepped
down to cast a negative vote, apparently being the German-speaking
equivalent of an Oreo. Not that it mattered. The vote was merely procedural;
its success would not have guaranteed passage of the measure, and in any
case German translations of federal statutes are a far cry from making the
German the official language of the U.S. A similar measure came up a month
later and was also voted down, as were subsequent attempts in later years.
The Muhlenberg story was widely publicized by Franz Loher in his 1847
History and Achievements of the Germans in America. He wrongly set the event
in the Pennsylvania legislature, over which Muhlenberg had previously
presided, and also wrongly claimed that Muhlenberg was reviled by his fellow
German speakers for selling them out. Germans did get on Muhlenberg's case
for later casting the deciding vote in favor of the Jay Treaty, which was
viewed as anti-German; his brother-in-law stabbed him and he lost the next
election in 1796. Loher conflated this genuine controversy with the trivial
language debate and the legend has survived ever since.
The truth is that the U.S. has never had an official language. Several
states have declared English official at one time or another, most recently
in response to the influx of Spanish speakers. The so-called English
Language Amendment (ELA) to the U.S. Constitution, which would give English
official status, has been before Congress since 1981, and given the
country's sour mood it may yet pass. But even if one concedes the usefulness
of a common language in unifying the country, one might as well attempt to
legislate the weather."
Be careful what you ask for, because you might just get it. You asked
for my input, so here it is.
I am not a high speed data/telecom vendor and I don't do gigabit IO. I
use FPGAs for general purpose system "glue" and data movement
operations. There is sometimes a little DSP thrown in for good measure.
As it turns out, the single biggest limitation in FPGAs that I am facing
is software. I need to be able to design a modular set of interfaces
that can be loaded into the chip in different combinations at run time.
There is no PC and no platform to run tools such as JBITS. There is a
small micro and a sizable hunk of Flash memory. If I could store a dozen
interchangable pieces that can be loaded into an FPGA in different
combinations, it would save me from having to design perhaps as many as
hundreds of different complete designs as distinct bit files.
Any progress in this area? Not much point in making the chips bigger and
bigger if your software doesn't keep up.
Doesn't System Ace solve some of your problems? It must be good (as Altera has
copied it, too!)
Seriously, Altera has a product similar to System ACE (maybe better?).
I apoloize for the cheap shot, it was not intended to come across the way some have
told me it did.
Thanks to those who let me know I was out of line.
Does either solve some of your issues?
But I don't see how System Ace helps me at all. I looked at Ace a long
time ago when it was first announced and realized that it was a way for
designers of large systems to add huge configuration memories to their
designs. I not trying to find a way to facilitate the selective
downloading of hundreds of different designs. I am trying to find a way
to eliminate the need for hundreds (or even thousands if we are very
successful) of different designs.
I know I have posted about this before, and the answer has always been,
"We don't currently have a partial reconfiguration option, but have you
looked at JBITS?" JBITS seems to be a good way to punt the problem off
to the customers and leaves a lot to be desired in the way of design
verification. But on the off chance that there has been some progress
made in the last three months, I will explain in detail again.
I am designing a very small DSP board which will use even smaller
daughter modules to provide various types of IO. On the first iteration
of this design we had two daughter module sites and used two FPGAs (one
each) to provide the interface functionality to a common board bus to
memory. This allowed us to check the ID of each daughter module at reset
and load the FPGA with the design (bit stream) corresponding to the
daughter module. Perfect!
Now we are using four daughter modules per DSP board in the same amount
of space. But we just don't have the space to use four FPGAs. In fact,
we have less space due to the increased memory size and the relocation
of a few parts that were in the locations of the two new daughter
modules. So we have combined the former three FPGAs into one and added
two more interfaces. This is going to make the number of FPGA bit
streams jump to enormous numbers if we allow any module to be plugged
into any site.
Example: if we have just 3 different modules (which is our goal by the
end of the year) we will need to support up to 3**4 = 81 different
designs. Of course we can pare this down enormously by requiring only to
support fixed locations for each combination (ie AABB and not ABAB or
BABA...). But that still makes for 15 combinations. When we add three
more new daughter module types next year, we will have an even larger
number of designs to support.
So the problem could be dealt with quite easily if we could use a
modular design where the FGPA could be thought of as having blocks for
each design and loading the corresponding interface into its own block.
Even if we had to design four different designs for each module type,
that would be 4*N rather than some geometric progression.
As it is we expect that part of selling a board set to a customer will
include the possibility of having to do a P&R of the modules along with
a full qualification of that P&R including temperature testing. This
will not be cheap and will significantly affect our business model.
Any chance this can change your business model and find a way to support
partial reconfiguration? This is not reconfiguration on the fly. Perhaps
a better term would be modular design and configuration?
It can be ignored, but you will notice that there is no real information
on these pages. But it is a start. Too bad that I am using Spartan IIE
and this is only available for VirtexII and E. We will see if they come
out with updates for Spartan lines.