Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 76150

Article: 76150
Subject: Re: Searching for rad tolerant, non-volatile (once programmable) FPGA (or CPLD).
From: usenet_10@stanka-web.de (Thomas Stanka)
Date: 26 Nov 2004 00:22:03 -0800
Links: << >>  << T >>  << A >>
mitrusc1980-newsgroup@yahoo.com.br (Marcio A. A. Fialho) wrote:
> After searching the Web, I've found out that Actel manufactures micro
> antifuse FPGAs. These would be fine, but I would like to know if are
> there any other alternatives besides Actel FPGAs.

Since Xilinx stopped manufacturing such fpgas, I know no alternative
fpga supplier for Actel.
You could of course contact Xilinx to see if a reprogramable device is
suitable for you.

> The device should have around 2500 user gates or more.

What to you mean with "user gates"? 2input-NAND? 4 input LUT
When an RH1020 is to small you need an RT54SX32S. But be aware,
there's currently a relability problem when using the RT54SX-S
devices.

> Reliability is a concern to us, and availability of a similar or
> equivalent, in System Programmable (ISP), part would be a plus.

When using the 5V IO, you will have trouble finding a reprogrammable
equivalent.

> P.S: ASICs (Field Gate Arrays) would be OK, provided it cost less than
> US$10,000.00 and takes less than a month or two to be fabricated. In
> case we opt for an ASIC, only around 3-5 units would be produced.

I know no alternative when spending 30-50k$ for that number. AFAIK
there are Actel fpgas above 10k$ per device.

Article: 76151
Subject: Re: Programming flash connected to CPLD via JTAG
From: wkopp@gmx.net (woko)
Date: 26 Nov 2004 00:47:11 -0800
Links: << >>  << T >>  << A >>
> http://www.universalscan.com
> 
Thanks for your input. It seems that the trial version of
universalscan supports flashprogramming and hopefully my AM29F010 too!
That would be the easyest solution, the price seens to be fair if it
keeps the promises.

Wolfgang

Article: 76152
Subject: Re: 386 IP Core
From: David <david.nospam@westcontrol.removethis.com>
Date: Fri, 26 Nov 2004 11:14:59 +0100
Links: << >>  << T >>  << A >>
On Thu, 25 Nov 2004 22:12:57 +0100, Marcin Olak wrote:

> Hello,
> 
>> Why bother with 80386?
> 
>     Anyone can write programmes for embedded systems with 386 processor
> using tools, everybody's familliar with. It's just mere PC-AT. No additional
> knowledge needed to program it.
> 

No - the great majority of programmers and tools for x86 processors are
for non-embedded systems.  If you have a big enough and fast enough
embedded x86 system, you can pretend that embedded issues like efficiency,
memory footprint, and limited resources don't matter, and then allow your
pc-programmers to work on it.  That gives you access to cheaper
programmers and lower time-to-market, at a higher cost of hardware.  But
you won't get that kind of performance from an 386 core on an fpga - a
cheapo embedded x86 chip will give you ten times the performance for a
tenth of the cost.



>> With other CPU architectures you can run your
>> CPU faster, get better system performance, and use less LUT in your
>> FPGA.
> 
>     In some cases time-to-market factor may have the biggest priority : )
> 
> greetings!
> Marcin Olak


Article: 76153
Subject: Re: Choice of FPGA device -- my view on benchmarks
From: Nick <brakepiston@REMOVEyahoo.co.uk>
Date: Fri, 26 Nov 2004 11:24:10 +0000
Links: << >>  << T >>  << A >>
I thought I'd give my 2 cents on this matter.

Altera and Xilinx both make excellent products. They make state of the
art VLSI circuits, using technologies other manufacturers dream of.
90nm being one of them. 

As with respect on who's the best, that's very hard to say. My
suggestion is, don't listen to Austin or Paul. Or, for that matter
anyone from Altera or Xilinx. They are great people, and always help
out whenever they can on this newsgroup. But, let's face it, they're a
bit biased.

If Austin said Altera is better than Xiinx, he'd be admitting he's no
good at what he does. Same goes for Paul. 

As for benchmarks, I believe what Altera says. Or most of it. What
they can do is what we all do, and that is compare devices that are
available on the market. And, at this point in time, the Stratix II is
the best FPGA on the market. So, if you need it today, go out and buy
a Stratix II.

Having said that, the V4, once in full production, will probably be a
better device. But by that time Altera might have another device in
the pipeline, almost ready to go out.

So there you have it. It's a pedulum effect. Right now, go for Stratix
II. At some point in the future, the advantage will Xilinx's. And at
some other point, it will swing back to Altera. 

The important thing is, of course, that Xilinx and Altera will keep on
making excellent devices, all the better for us users!!

Have a nice day everyone!

On Wed, 24 Nov 2004 07:56:57 -0800, Austin Lesea <austin@xilinx.com>
wrote:

>Varun,
>
>Your best bet is to contact the FAE (Field Applications Engineers) for 
>both campanies, and have them explain exactly what their claims are 
>based on.
>
>What speed grades were compared (e.g. their fastest with our mid-grade)?
>
>What were the settings of the synthesis tools (e.g. their default vs our 
>default -- we default for speed of synthesis, theirs for a compromise of 
>performance)?
>
>What effort was made to use device specific features (e.g. theirs a lot, 
>ours a little)?
>
>What choice of device was made (e.g. their only one choice, versus our 
>three options to best fit: LX for logic, SX for DSP, and FX for 
>networking and comms)?
>
>
>Or, you could do like the other posters' suggest:  IGNORE IT and do your 
>own benchmark by examining specifications and trying out some intended 
>critical logic, and/or examining the offering of IP from each company 
>(and its perfomance).
>
>Who is to say which device is 'better'?  Only after careful study, and 
>use of specific features that may offer an improvement can one make a 
>decision.  And that decision only holds for that one (type of) design!
>
>The "speed superiority" claims appeared three days after we announced 
>the availability of three V4 parts as engineering samples.....compared 
>to their unavailability.  Hey it ain't fun when your foundry can't 
>supply the parts to you, is it?
>
>Our 90nm offerings are succeeding because we did engage early with our 
>fab partners, and did shake the process out.  If you wait until the 
>process is stable, you will wait forever.  If you don't want the 
>process, you are dependent on other larger customers of the fab.....and 
>maybe they are making 130nm ASICs and are perfectly happy to wait until 
>someone else has paid for the 90nm wafer starts to shake out the new 
>process.  And who will use the triple oxide process for reduce leakage 
>and power on currents?  No one but an FPGA vendor.  No process, no 
>performance.
>
>Our fabs like us for our willingness to be full partners in the 
>development of a new advanced process.  I think our customers understand 
>that sometimes there will be rough spots in a new introduction of a new 
>product on a new process, but overall we continue to offer superior 
>products (in my opinion).
>
>Austin
>
>
>Varun Jindal wrote:
>
>> hello all,
>> 
>> i have been reading a lot about performance comparisons between
>> leading FPGA chip makers on hteir web-sites. both claim improvement
>> upon the other by metrics of 20 - 40 % .... though none has ever
>> described what exactly was compared.
>> 
>> are there resources available on the net, which compare different
>> architecture in detail (and also impartially) .. !! ??
>> 
>> -- Varun.


Article: 76154
Subject: Quartus Debian Install
From: Matthias Braeunig <mb.atelier@web.de>
Date: Fri, 26 Nov 2004 14:44:11 +0100
Links: << >>  << T >>  << A >>
Hello!
as I see there are people here using Altera Quartus II.
Has anyone succeeded installing Quartus on systems other than RedHat?
I'm looking for hints how to run the installer with csh on a Debian
Linux with kernel 2.6.8. Any help is greatly appreciated.
Mat

--

Article: 76155
Subject: Re: how to evaluate the needed number of gate?
From: "Mouarf" <mouarf@chezmoi.fr>
Date: Fri, 26 Nov 2004 15:50:28 +0100
Links: << >>  << T >>  << A >>
OK,

I've tried a simple project in Lattice ispLever software and it tells me the 
number of pin used, number of registers and the number of logic pterms.
Are the pterms equivalent to macrocell?

"General Schvantzkoph" <schvantzkoph@yahoo.com> schrieb im Newsbeitrag 
news:pan.2004.11.25.18.51.15.32873@yahoo.com...
> On Thu, 25 Nov 2004 13:05:14 +0100, Mouarf wrote:
>
>> hello all,
>>
>> For a hobbyist purpose, I want to drive an LCD display (320x240) with a 
>> CPLD
>> or FPGA in a standalone device (weather station). I've already played 
>> with
>> FPGA and VHDL for some projects but I was never involved in the hardware
>> part of such projects.
>>
>> The CPLD would have to read data (bitmap picture) from a dual port RAM 
>> and
>> write it to the 4 bit data input of the LCD controller (+control lines,
>> clock...). On the other side of the RAM, a microcontroller will update
>> sometimes the content of the picture to be displayed.
>>
>> I would like to know how to estimate the number of gate needed for the
>> project in order to buy the cheapest CPLD that fits the number of gate.
>>
>> Do I need first to design the VHDL part and synthetize to know the number 
>> of
>> gate and then choose the CPLD?
>>
>> I do not really understand the difference between CPLD and FPGA and what 
>> is
>> better for me.
>>
>> For a  CPLD, the configuration is non volatile and in the FPGA it is
>> volatile so a reconfiguration is needed on each start (via configuration
>> EEPROM or JTAG programming) but the FPGA is much more powerfull. Correct?
>>
>> Is a CPLD enough for my project? I'm turning around Xilinx XC9536 which
>> seems to be very often used nowadays, is it a good choice for this 
>> project?
>>
>>
>> Many thanks by advance.
>
> Since this a learning experience for you I'd suggest that you design,
> simulate and synthesize it before you attempt to build any hardware. The
> best way to get a feel for what a logic family is capable of is to try
> a number of designs. After a while you'll be able to look at a project and
> know what the right device is.
> 



Article: 76156
Subject: Re: FPGA development board
From: nospam4u_jack@yahoo.com (Jack// ani)
Date: 26 Nov 2004 07:00:59 -0800
Links: << >>  << T >>  << A >>
"Alex Gibson" <me@privacy.net> wrote in message news:<30j6d7F313dh0U4@uni-berlin.de>...
> "Jack// ani" <nospam4u_jack@yahoo.com> wrote in message 
> news:86040da6.0411200551.6609a567@posting.google.com...

I was expecting Leon to solve my query! It appears that he is out or
no more interested in me.

BTW, I got answer to all the questions except one: What is the
frequency to crystal oscillator used here
http://www.geocities.com/leon_heller/pld_starter.html , it is
mentioned no where! I'm still in a hope that some one will help me! I
think is should be 50Mhz…but not sure.

Thanks

Article: 76157
Subject: Re: how to evaluate the needed number of gate?
From: "Antti Lukats" <antti@case2000.com>
Date: Fri, 26 Nov 2004 16:15:26 +0100
Links: << >>  << T >>  << A >>

"Mouarf" <mouarf@chezmoi.fr> wrote in message
news:41a742ca$0$2337$626a14ce@news.free.fr...
> OK,
>
> I've tried a simple project in Lattice ispLever software and it tells me
the
> number of pin used, number of registers and the number of logic pterms.
> Are the pterms equivalent to macrocell?

no



Article: 76158
Subject: Re: how to evaluate the needed number of gate?
From: "Mouarf" <mouarf@chezmoi.fr>
Date: Fri, 26 Nov 2004 16:42:56 +0100
Links: << >>  << T >>  << A >>
and are the macrocells almost equivalent between devices of the same range 
from different manufacturers?



"Antti Lukats" <antti@case2000.com> schrieb im Newsbeitrag 
news:co7gt3$4gl$04$1@news.t-online.com...
>
> "Mouarf" <mouarf@chezmoi.fr> wrote in message
> news:41a742ca$0$2337$626a14ce@news.free.fr...
>> OK,
>>
>> I've tried a simple project in Lattice ispLever software and it tells me
> the
>> number of pin used, number of registers and the number of logic pterms.
>> Are the pterms equivalent to macrocell?
>
> no
>
> 



Article: 76159
Subject: Re: Searching for rad tolerant, non-volatile (once programmable)
From: Duane Clark <junkmail@junkmail.com>
Date: Fri, 26 Nov 2004 09:31:30 -0800
Links: << >>  << T >>  << A >>
Marcio A. A. Fialho wrote:
> I'm looking for a rad-tolerant, non-volatile (preferably programmable
> at once) FPGA or CPLD, for a new project (a satellite instrument).
> 
> ...
> P.S: ASICs (Field Gate Arrays) would be OK, provided it cost less than
> US$10,000.00 and takes less than a month or two to be fabricated. In
> case we opt for an ASIC, only around 3-5 units would be produced.
> 

Hmmm... have you checked the prices of rad hard parts? You might be in 
for a rude shock, even with Actel FPGAs.

Article: 76160
Subject: Re: Quartus Debian Install
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Fri, 26 Nov 2004 23:23:59 GMT
Links: << >>  << T >>  << A >>
Hi Mat,

> as I see there are people here using Altera Quartus II.
> Has anyone succeeded installing Quartus on systems other than RedHat?
> I'm looking for hints how to run the installer with csh on a Debian
> Linux with kernel 2.6.8. Any help is greatly appreciated.
> Mat

I'm running Quartus on a Gentoo box having used any sort of kernel ranging
from 2.4.18 through my current 2.6.9 (and having done 1 successful run on
2.6.10-rc2), and tcsh version 6.13. I have never had any real issues with
the installer as long as I ran it from a normal console window.

If I run it from a KDE kommand window, for some reason the backspace key
gets remapped to something useless, but since the installation procedure
mainly involves hitting Enter a few times, then typing a path, and then
hitting Enter a few more times again I don't think that that's a
show-stopper. Just type "stty sane" once the script finishes.

Once installed, if Quartus won't run on your machine, take a good look at
the $QUARTUS/adm/qenv.csh script, and make sure that the settings the
script automatically makes for a RedHat machine are also set in the
non-Redhat part of the settings script (around line 111). The important
ones are QUARTUS_MWWM and LD_ASSUME_KERNEL. Both of these should be
unnecessary on a Debian machine, unless you compiled your glibc with NTPL
threading support, in which case you should definitely add an
LD_ASSUME_KERNEL=2.4 line.

There's a few more possible hiccups and glitches I've found in the field,
but as long as you're using a fairly vanilla installation you should be
able to run Quartus just fine.

My biggest gripe with the Linux port is that the mouse wheel won't work. If
you feel that this is a feature you's like to see as well, complain to
Altera, and to Mainsoft, who are the cause of all this trouble because it's
their platform layer that doesn't support the mouse wheel. The more people
that complain about this, the better.

Best regards,



Ben
Sasco


Article: 76161
Subject: Re: Choice of FPGA device -- my view on benchmarks
From: "Simon Peacock" <nowhere@to.be.found>
Date: Sat, 27 Nov 2004 17:06:34 +1300
Links: << >>  << T >>  << A >>
I would like to second Nick's opinion...
The key thing to remember is that Altera and Xilinx are competitors... so of
course each's product is better than the other and benchmarks are just
that... 'bench' marks.. Altera and Intel have been playing the smoke and
mirrors of benchmarking for years.... even MS is getting into the act
against Linux ...
There are pros and cons for both implementations but I think the most
important is the software used to create the FPGA.  That's what it boils
down too in the long run..
There's an old saying... if you don't like the weather in Florida  wait a
few minutes and it'll change.. same is true for FPGA's. Unless you need
bleeding edge either manufacturer will do... I/O is another thing.. Xilinx
seems to support LVDS better than Altera... (especially BUS LVDS)..
Also the way you write code will affect the benchmark to some degree too...

So my advice to someone is write your code using no built in libraries..
then compile using free tools on both... look at the speeds, delays etc...
is it what you want ? is it everything you need ?  Do both manufacturers
work ?
Then throw that out and ask your Xilinx and Altera agents who will give the
best price ??  We had a 30% discount for not using Altera in our design :-)
When it all comes down to it its not who's better... but if they both
work... which gives you the best profit .. its no good having a product
that's too expensive to sell!

A somewhat sceptical approach.

Simon

"Nick" <brakepiston@REMOVEyahoo.co.uk> wrote in


> I thought I'd give my 2 cents on this matter.
>
> Altera and Xilinx both make excellent products. They make state of the
> art VLSI circuits, using technologies other manufacturers dream of.
> 90nm being one of them.
>
> As with respect on who's the best, that's very hard to say. My
> suggestion is, don't listen to Austin or Paul. Or, for that matter
> anyone from Altera or Xilinx. They are great people, and always help
> out whenever they can on this newsgroup. But, let's face it, they're a
> bit biased.
>
> If Austin said Altera is better than Xiinx, he'd be admitting he's no
> good at what he does. Same goes for Paul.
>
> As for benchmarks, I believe what Altera says. Or most of it. What
> they can do is what we all do, and that is compare devices that are
> available on the market. And, at this point in time, the Stratix II is
> the best FPGA on the market. So, if you need it today, go out and buy
> a Stratix II.
>
> Having said that, the V4, once in full production, will probably be a
> better device. But by that time Altera might have another device in
> the pipeline, almost ready to go out.
>
> So there you have it. It's a pedulum effect. Right now, go for Stratix
> II. At some point in the future, the advantage will Xilinx's. And at
> some other point, it will swing back to Altera.
>
> The important thing is, of course, that Xilinx and Altera will keep on
> making excellent devices, all the better for us users!!
>
> Have a nice day everyone!
>
> On Wed, 24 Nov 2004 07:56:57 -0800, Austin Lesea <austin@xilinx.com>
> wrote:
>
> >Varun,
> >
> >Your best bet is to contact the FAE (Field Applications Engineers) for
> >both campanies, and have them explain exactly what their claims are
> >based on.
> >
> >What speed grades were compared (e.g. their fastest with our mid-grade)?
> >
> >What were the settings of the synthesis tools (e.g. their default vs our
> >default -- we default for speed of synthesis, theirs for a compromise of
> >performance)?
> >
> >What effort was made to use device specific features (e.g. theirs a lot,
> >ours a little)?
> >
> >What choice of device was made (e.g. their only one choice, versus our
> >three options to best fit: LX for logic, SX for DSP, and FX for
> >networking and comms)?
> >
> >
> >Or, you could do like the other posters' suggest:  IGNORE IT and do your
> >own benchmark by examining specifications and trying out some intended
> >critical logic, and/or examining the offering of IP from each company
> >(and its perfomance).
> >
> >Who is to say which device is 'better'?  Only after careful study, and
> >use of specific features that may offer an improvement can one make a
> >decision.  And that decision only holds for that one (type of) design!
> >
> >The "speed superiority" claims appeared three days after we announced
> >the availability of three V4 parts as engineering samples.....compared
> >to their unavailability.  Hey it ain't fun when your foundry can't
> >supply the parts to you, is it?
> >
> >Our 90nm offerings are succeeding because we did engage early with our
> >fab partners, and did shake the process out.  If you wait until the
> >process is stable, you will wait forever.  If you don't want the
> >process, you are dependent on other larger customers of the fab.....and
> >maybe they are making 130nm ASICs and are perfectly happy to wait until
> >someone else has paid for the 90nm wafer starts to shake out the new
> >process.  And who will use the triple oxide process for reduce leakage
> >and power on currents?  No one but an FPGA vendor.  No process, no
> >performance.
> >
> >Our fabs like us for our willingness to be full partners in the
> >development of a new advanced process.  I think our customers understand
> >that sometimes there will be rough spots in a new introduction of a new
> >product on a new process, but overall we continue to offer superior
> >products (in my opinion).
> >
> >Austin
> >
> >
> >Varun Jindal wrote:
> >
> >> hello all,
> >>
> >> i have been reading a lot about performance comparisons between
> >> leading FPGA chip makers on hteir web-sites. both claim improvement
> >> upon the other by metrics of 20 - 40 % .... though none has ever
> >> described what exactly was compared.
> >>
> >> are there resources available on the net, which compare different
> >> architecture in detail (and also impartially) .. !! ??
> >>
> >> -- Varun.
>



Article: 76162
Subject: microblaze using SysGen
From: "Terrence Mak" <stmak@se.cuhk.edu.hk>
Date: Sat, 27 Nov 2004 12:20:21 +0800
Links: << >>  << T >>  << A >>
Hi,

Matlab SysGen provide a microblaze module that we can have the design of 
microblaze processor together with other FPGA logic solely defined in the 
SysGen design environment. But when I try to place more than one microblaze 
module, says two microblaze communication through some FPGA logics, SysGen 
fails to compile such a case. Are there any solutions to achieve 
multi-microblaze in one chip?

Many thanks,
Terrence 



Article: 76163
Subject: Re: Choice of FPGA device -- my view on benchmarks
From: austin <austin@xilinx.com>
Date: Fri, 26 Nov 2004 20:42:13 -0800
Links: << >>  << T >>  << A >>
Nick,

Hmmm.

We introduced V4 before SII (as in announced shipments to customers).

We shipped thousands of V4 ES parts, more than S2.

We shipped both LX60, LX25, and SX35 (three devices from the family).

We are getting ready to ship all the others.

In production on 90nm a full year ahead (Spartan 3).

So how are they 'ahead' this time?

One family, no processor(s), no MGTs, no built in FIFOs, ....

Too many deficiencies to name.

But, you are right, don't take my word for it.  How could I possibly be 
fair?

I'll leave the marketing to the marketeers.

But when I see patently false statements, I will respond.

Austin



Nick wrote:

> I thought I'd give my 2 cents on this matter.
> 
> Altera and Xilinx both make excellent products. They make state of the
> art VLSI circuits, using technologies other manufacturers dream of.
> 90nm being one of them. 
> 
> As with respect on who's the best, that's very hard to say. My
> suggestion is, don't listen to Austin or Paul. Or, for that matter
> anyone from Altera or Xilinx. They are great people, and always help
> out whenever they can on this newsgroup. But, let's face it, they're a
> bit biased.
> 
> If Austin said Altera is better than Xiinx, he'd be admitting he's no
> good at what he does. Same goes for Paul. 
> 
> As for benchmarks, I believe what Altera says. Or most of it. What
> they can do is what we all do, and that is compare devices that are
> available on the market. And, at this point in time, the Stratix II is
> the best FPGA on the market. So, if you need it today, go out and buy
> a Stratix II.
> 
> Having said that, the V4, once in full production, will probably be a
> better device. But by that time Altera might have another device in
> the pipeline, almost ready to go out.
> 
> So there you have it. It's a pedulum effect. Right now, go for Stratix
> II. At some point in the future, the advantage will Xilinx's. And at
> some other point, it will swing back to Altera. 
> 
> The important thing is, of course, that Xilinx and Altera will keep on
> making excellent devices, all the better for us users!!
> 
> Have a nice day everyone!
> 
> On Wed, 24 Nov 2004 07:56:57 -0800, Austin Lesea <austin@xilinx.com>
> wrote:
> 
> 
>>Varun,
>>
>>Your best bet is to contact the FAE (Field Applications Engineers) for 
>>both campanies, and have them explain exactly what their claims are 
>>based on.
>>
>>What speed grades were compared (e.g. their fastest with our mid-grade)?
>>
>>What were the settings of the synthesis tools (e.g. their default vs our 
>>default -- we default for speed of synthesis, theirs for a compromise of 
>>performance)?
>>
>>What effort was made to use device specific features (e.g. theirs a lot, 
>>ours a little)?
>>
>>What choice of device was made (e.g. their only one choice, versus our 
>>three options to best fit: LX for logic, SX for DSP, and FX for 
>>networking and comms)?
>>
>>
>>Or, you could do like the other posters' suggest:  IGNORE IT and do your 
>>own benchmark by examining specifications and trying out some intended 
>>critical logic, and/or examining the offering of IP from each company 
>>(and its perfomance).
>>
>>Who is to say which device is 'better'?  Only after careful study, and 
>>use of specific features that may offer an improvement can one make a 
>>decision.  And that decision only holds for that one (type of) design!
>>
>>The "speed superiority" claims appeared three days after we announced 
>>the availability of three V4 parts as engineering samples.....compared 
>>to their unavailability.  Hey it ain't fun when your foundry can't 
>>supply the parts to you, is it?
>>
>>Our 90nm offerings are succeeding because we did engage early with our 
>>fab partners, and did shake the process out.  If you wait until the 
>>process is stable, you will wait forever.  If you don't want the 
>>process, you are dependent on other larger customers of the fab.....and 
>>maybe they are making 130nm ASICs and are perfectly happy to wait until 
>>someone else has paid for the 90nm wafer starts to shake out the new 
>>process.  And who will use the triple oxide process for reduce leakage 
>>and power on currents?  No one but an FPGA vendor.  No process, no 
>>performance.
>>
>>Our fabs like us for our willingness to be full partners in the 
>>development of a new advanced process.  I think our customers understand 
>>that sometimes there will be rough spots in a new introduction of a new 
>>product on a new process, but overall we continue to offer superior 
>>products (in my opinion).
>>
>>Austin
>>
>>
>>Varun Jindal wrote:
>>
>>
>>>hello all,
>>>
>>>i have been reading a lot about performance comparisons between
>>>leading FPGA chip makers on hteir web-sites. both claim improvement
>>>upon the other by metrics of 20 - 40 % .... though none has ever
>>>described what exactly was compared.
>>>
>>>are there resources available on the net, which compare different
>>>architecture in detail (and also impartially) .. !! ??
>>>
>>>-- Varun.
> 
> 

Article: 76164
Subject: Re: how to evaluate the needed number of gate?
From: "vax, 9000" <vax9000@gmail.com>
Date: Sat, 27 Nov 2004 01:40:13 -0500
Links: << >>  << T >>  << A >>
Mouarf wrote:

> and are the macrocells almost equivalent between devices of the same range
> from different manufacturers?

An easy answer is that you would like to download software from each of
those manufacturers try your design on each of them. I am going to do just
that.

vax, 9000

Article: 76165
Subject: Re: Choice of FPGA device -- my view on benchmarks
From: hmurray@suespammers.org (Hal Murray)
Date: Sat, 27 Nov 2004 01:41:45 -0600
Links: << >>  << T >>  << A >>
>So my advice to someone is write your code using no built in libraries..
>then compile using free tools on both... look at the speeds, delays etc...
>is it what you want ? is it everything you need ?  Do both manufacturers
>work ?

Anybody have a rule-of-thumb on how much performance you give up if
you don't tweak your code to take advantage of a vendor's
features/quirks?  (both software and hardware)

Are the free tools appropriate if we are discussing volumes big enough
to be worth arguing about?

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 76166
Subject: Re: Choice of FPGA device -- my view on benchmarks
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 27 Nov 2004 01:18:03 -0800
Links: << >>  << T >>  << A >>
Simon Peacock wrote:

>>So my advice to someone is write your code using no built in libraries..
>>then compile using free tools on both... look at the speeds, delays etc...
>>is it what you want ? is it everything you need ?  Do both manufacturers
>>work ?

Mike Treseler wrote:

Yes, start with your own functional synthesis code
and compare utilization and static timing for all
devices under consideration.

That's also a good way to design portable code.
Synthesis in 2004 is surprisingly efficient, and there's
not much on the chip besides the clock PLL that can't
be inferred from your own code.

Hal Murray wrote:

> Anybody have a rule-of-thumb on how much performance you give up if
> you don't tweak your code to take advantage of a vendor's
> features/quirks?  (both software and hardware)

My rule is try it and see.
It doesn't take long to run static
timing to get the exact answer for the
actual routed design.

Sometimes I can catch the synth on small inefficiencies,
but then it often kicks my rear on bigger things.
And if I spend even one minute fussing with each of
50,000 logic cells, I'd probably be brewing mocha lattes today.

      -- Mike Treseler

Article: 76167
Subject: XST question
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sat, 27 Nov 2004 15:23:34 +0100
Links: << >>  << T >>  << A >>
Hello everybody,

Iam using ISE 6.2 with XST as synthesis tool. So far so good. But Now I have
a design with plenty of timing margin (just 36 MHz ;-) and the goal is to
fit it into a XC2S50E.
At the end, it doesnt.
So looking a little closer to the reports, I saw in the MAP report something
like this.

blabla
1000 LUTs used
300 LUTs used a s route-thru.

How is this to understand? I understand it this way, that XST (and the other
tools) use a LUT to feed data into a FF, but only 1 input is used, so the
LUT has no real function, maybe only a inversion. Is this how it works?
So how can I tell the software not to use LUTs as route thru, even if this
will decrease timing performance? I mean it is tecnically possible to use th
BY input to feed data into a FF.

Regards
Falk




Article: 76168
Subject: dual-write port BRAM with XST/Webpack
From: darkgold@lycos.co.uk (Kotek Barajazz)
Date: 27 Nov 2004 07:42:40 -0800
Links: << >>  << T >>  << A >>
Hi I was wondering if anyone here can help me. 

I need to infer a true dual port BRAM with seperate clk, addr, data,
en and wr lines on a Spartan-3 device but according to the XST manual
this is not supported and after googling for a couple of days I've
come to a dead end.

I need this in order to provide an external memory interface to some
shared memory and the design is so simple and clean at the moment that
I really want avoid having to use an async FIFO which would need alot
of re-jigging to the upper levels and make things quite ugly.

Does anyone know if this is even possible with the free ISE Webpack
tools? Or will it require me buying some other software?  This is my
first FPGA design and is more of a hobby that may have some commercial
potential so I cant really justify spending lots of $$$ for something
I may only require the use of once.

Many thanks in advance.

Article: 76169
Subject: Re: Choice of FPGA device -- my view on benchmarks
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Sat, 27 Nov 2004 11:29:22 -0500
Links: << >>  << T >>  << A >>
Hi Hal,

> Are the free tools appropriate if we are discussing volumes big enough
> to be worth arguing about?

The Quartus II Web Edition is almost fully-featured when it comes to 
push-button place & route.  Web Edition provides all synthesis & fitter 
options intended for optimizing design performance and/or area, with the 
exception of the physical synthesis options.  Physical synthesis can be a 
huge boost on many designs (10-15%?), so its ommision is a bit of a downside 
to using the Web Edition.  It may be included in a future edition of the 
product.

The other issue is device support.  If you require a large Stratix II 
device, they are not shipped with the Web Edition, so you will not be able 
to evaluate those devices.

Regards,

Paul Leventis
Altera Corp.






Article: 76170
Subject: Re: dual-write port BRAM with XST/Webpack
From: "Karl Olsen" <kro@nospam.post3.tele.dk>
Date: Sat, 27 Nov 2004 17:55:33 +0100
Links: << >>  << T >>  << A >>
Kotek Barajazz <darkgold@lycos.co.uk> wrote:

> I need to infer a true dual port BRAM with seperate clk, addr, data,
> en and wr lines on a Spartan-3 device but according to the XST manual
> this is not supported and after googling for a couple of days I've
> come to a dead end.
>
> I need this in order to provide an external memory interface to some
> shared memory and the design is so simple and clean at the moment that
> I really want avoid having to use an async FIFO which would need alot
> of re-jigging to the upper levels and make things quite ugly.
>
> Does anyone know if this is even possible with the free ISE Webpack
> tools? Or will it require me buying some other software?  This is my
> first FPGA design and is more of a hobby that may have some commercial
> potential so I cant really justify spending lots of $$$ for something
> I may only require the use of once.

You cannot infer dual-port BRAM with Webpack, but you can instantiate
primitives.  See
http://groups.google.dk/groups?hl=en&lr=&selm=vGhO5.241%24ey5.18887%40news000.worldonline.dk

Karl Olsen




Article: 76171
Subject: Re: Choice of FPGA device -- my view on benchmarks
From: nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
Date: Sat, 27 Nov 2004 17:24:05 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <W6idnWZS49YksjXcRVn-jg@megapath.net>,
Hal Murray <hmurray@suespammers.org> wrote:
>>So my advice to someone is write your code using no built in libraries..
>>then compile using free tools on both... look at the speeds, delays etc...
>>is it what you want ? is it everything you need ?  Do both manufacturers
>>work ?
>
>Anybody have a rule-of-thumb on how much performance you give up if
>you don't tweak your code to take advantage of a vendor's
>features/quirks?  (both software and hardware)

Placement and careful pipelining are big wins.  My AES design of a few
years ago was about 1/2 the size and 2x the performance of the
academic synthesized versions because I hand-mapped to the Virtex
E/Spartan II family including placement.

Placement alone can be a good 20%+ performance win (and better
tooltimes as well, as I'm rediscovering), the application-specific
mapping gave the area savings, and architecturally-aware pipelining is
a HUGE win on the performance.

So just one data point, but taking advantages of layout, architectural
mapping, and specific quirks (eg, the BlockRAMs are the right size to
do both the AES S-box and ONE of the Galios multiplies of the
mix-column operation.  The register can be used independantly of the
LUT under MOST conditions.  SRL16s need an output register but are
good for retiming chains, etc) are hugely critical for area &
performance.

>Are the free tools appropriate if we are discussing volumes big enough
>to be worth arguing about?

To my mind, the reason to select Brand A vs Brand X should come down
to two major things:

Familiarity.  I'm a Brand X guy, because I'm more familiar with the
architecture (and Xilinx has given a lot of support to UC Berkeley
over the years, which has created this familiarity).

NON-FPGA features:  For the work I'm currently doing (working on
NIDS-in-FPGA), the MGTs are an absolute essential for the network
interfaces, and the processor may become useful in the very near-term
future, so its very useful to have in place.
-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Article: 76172
Subject: Re: dual-write port BRAM with XST/Webpack
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 27 Nov 2004 09:36:52 -0800
Links: << >>  << T >>  << A >>
Kotek Barajazz wrote:

> I need to infer a true dual port BRAM with seperate clk, addr, data,
> en and wr lines on a Spartan-3 device but according to the XST manual
> this is not supported and after googling for a couple of days I've
> come to a dead end.
> 
> I need this in order to provide an external memory interface to some
> shared memory and the design is so simple and clean at the moment that
> I really want avoid having to use an async FIFO which would need alot
> of re-jigging to the upper levels and make things quite ugly.

A fifo-like controller requires one read-only port
and one write-only port. Such a two port description
infers the "true dual port BRAM" just fine,
but with the extra read and write controls tied off.
As an added benefit, the description is portable
across vendors. Related posting:

http://groups.google.com/groups?q=infer+RAM_B4_S16_S16

      -- Mike Treseler

Article: 76173
Subject: Q:iMPACK:583 - '1' error
From: "Jack Zhu" <jackzhu@dcn.davis.ca.us>
Date: Sat, 27 Nov 2004 11:25:14 -0800
Links: << >>  << T >>  << A >>
Hi,

I got this error message from my laptop while on my work place desktop it
didn't have this at all.
The message is this:
    ERROR: iMPACK:583 - '1': The idcode read from the device does not match
the idcode in the bsdl file.
Both PCs are running Win2k/SP4. I am using the latest iMPACK 6.3.02i. Can
somebody help me to explain
why this is happening and how to fix it?

Jack



Article: 76174
Subject: Re: Spartan 3 output voltage level
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 27 Nov 2004 15:28:43 -0500
Links: << >>  << T >>  << A >>
Lawrence Kiss wrote:
> 
> Thanks for the reply Peter.
> 
> My 8051 specifies a minimum high logiv level at .7*VCC = 3.5V.  What is the
> gaurentee that the Spartan 3 will ever output a 3.3V signal?  I would think
> that I need to pull up to VCC=5V not 3.3V.

I am pretty sure you can use a voltage divider connected to Vcc rather
than ground to protect the Spartan 3 input and give you a higher Vin
voltage.  

       |     Vcc5           |
       |      |             |
       |      /             |
       |      \ R1          |
 8051  |      /             | Spartan 3
       |      \             |
       |      |     R2      |
    In |------+----\/\/-----| Out
       |                    |
       |                    |

You need to find an appropriate ratio to give you both high and low
voltages that meet your input spec.  The absolute values will be set by
considering the max input current at the Spartan 3 when the output is
pulled above Vcc3.  

In reality, I don't think the resistor divider is needed since the
Spartan output will be pulled above the 3.3 volt rail until the
protection diodes clamp, at Vcc3+0.5 IIRC.  But the divider can give you
a bit more noise margin on the high side at the expense of noise margin
on the low side.  

-- 

Rick "rickman" Collins

rick.collins@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



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search