Altera's new family Stratix
Muzaffer Kal
adders. Isn't competition great?
http://www.altera.com/products/devices/stratix/stx-index.jsp
Muzaffer Kal
http://www.dspia.com
DSP algorithm implementations for FPGA systems
Austin Lesea
Thank you, Altera (from all of the IC Designers here at Xilinx).
Austin
Ray Andraka
problems with their arithmetic mode. They put an XOR gate in front of
the LUT to permit use as an adder-subtractor. Likewise, the sload and
sclear are added logic to make loadable and clearable accumulators
possible in one level of logic. How about adders with muxed or gated
inputs? Nope, still need two levels for those. The carry save
architecture is interesting, and should help to speed up arithmetic.
It is also interesting to note that the carry chain now goes across
rows,which should help tremendously with routing congestion in
data-flow designs (bravo).
The DSP block looks interesting. Guess that is case of keeping up with
the Joneses.
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
considerably.
Austin Lesea wrote:
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email r...@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
John_H
with the logic built in (rather than external LE-based logic). Whether the
functionality is completely there for SRL16 replacement I haven't gotten
into. The 512 bit rams look like a nice alternative to the CLB SelectRAMs
in my designs. The one extra thing we now have in Brand A that Brand X
doesn't have is the big memory blocks: 512kbit (versus 18kbit or 4kbit).
And thanks for ranting and raving :-)
Ray Andraka wrote: [excerpt]
Eric Smith
> 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.
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?
Tim
"Eric Smith" wrote
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.
Ray Andraka
WE pin of an SRL16 is held low, it is indistinguishable from a LUT (except
the router is not free to permute the pins and the BX and BY pins are
blocked). When WE is high, new 'LUT' data gets shifted in the D pin on
each clock. What this means is that you can substitute SRL16s for LUTs in
your design to obtain LUTs that can have their contents reloaded without
having to go through any device reconfiguration. It is real low overhead
too. We use it in our FIR filters so that customers can reload the
coefficients without having to reconfigure, or worse pass the design
through PAR again. Our filter macros permit default coefficients at
compile time which are used to set up the INIT attributes on the SRL16's,
but then the user is free to reload the filter by shifting in new LUT
contents. This is real handy for block adaptive filters too, not to
mention constant multipliers.
Eric Smith wrote:
--
Peter Ormsby
Austin Lesea <austin...@xilinx.com> wrote in message
news:3C6806F4...@xilinx.com...
> Imitation is the sincerest form of flattery.
>
> Thank you, Altera (from all of the IC Designers here at Xilinx).
>
> Austin
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?"
-Pete-
rickman
Thanks Xilinx. ;)
--
Rick "rickman" Collins
rick.c...@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Ray Andraka
they've been done right: The big memory could be a big win in lots of
applications. The 512 bit memories are numerous enough to use for the
small delay queues I've been harping about. The mutlipliers, if they
really run at the 250 MHz advertised in the datasheet are quite a bit
faster than the ones in the currently available virtexII, and it looks like
they line up nicely with the LABs so you don't need to surround them with a
bunch of pipeline registers just to get the performance. The row
architecture reduces the bit pitch to a minor issue, and it looks like it
lines up nicely with the LAB pitch. I have been impressed by the DSP IP
Altera has been turning out over the last year or so. It is evident that
they are very serious about getting a stake in the DSP market. Now it
looks they'll have decent silicon to put it on. Looks like it could be a
serious contender.
rickman wrote:
--
ls_user
Please ask Peter for translation.
regards
The Amateur
Austin Lesea
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
arpit.desai
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
decade.
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.
Austin Lesea
Oder wie sie sagen in Rom:
Caveat Emptor.
Austin
(Ich kann Deutschen lesen, Danke)
(But excuse my written German, as I am not up to the colloquialisms or
the venarcular)
Austin Lesea
Whose frustrated?
I am having a little fun, but I am too busy now, so you too, have some fun.
Austin
John_H
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).
jakab tanko
Some Hungarian:
Altera nyomaba se lephet Xilinxnek, legalab ket evvel vannak lemaradva!
Some Romanian:
Viata e frumoasa...Altera are DSP!
:-)
Have fun translating it,
jakab
Austin Lesea <austin...@xilinx.com> wrote in message
news:3C6990D5...@xilinx.com...
gyp
but I think it is going to be at the same period).
So be patient and keep on using Xilinx'stuff!
Austin Lesea
Austin
(my father was from Sibu, Romania, and spoke 7 languages. I did not inherit
much of his talents, I am afraid)
Falk Brunner
news:3C6990D5...@xilinx.com...
> "Kunde passen auf."
>
> Oder wie sie sagen in Rom:
>
> Caveat Emptor.
>
> Austin
>
> (Ich kann Deutschen lesen, Danke)
;-))))
Some people sometime miss the fact, that german lost the vote for the
american language by just one vote. . . . .
--
MfG
Falk
Jim Kearney
> 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
Straight Dope:
"... 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."
rickman
>
> Rick,
>
> 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
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.
Austin Lesea
Good points.
Doesn't System Ace solve some of your problems? It must be good (as Altera has
copied it, too!)
Austin
Austin Lesea
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?
Austin
rickman
using your sense of humor with comments like these.
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?
Magnus Homann
http://www.xilinx.com/ise/marketing/index.htm
(Just ignore that it says 'marketing' in the link...)
Homann
--
Magnus Homann, M.Sc. CS & E
d0a...@dtek.chalmers.se
rickman
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.