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 69450

Article: 69450
Subject: Re: Monolithic state machine or structured state machine?
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Tue, 11 May 2004 16:15:17 +0100
Links: << >>  << T >>  << A >>
On 10 May 2004 16:13:55 -0700, mike_treseler@comcast.net (Mike Treseler)
wrote:

>vax3900 wrote:
> 
>>I am designing a state machine that will be fit into a CPLD (Xilinx XC95xx).
>>The state machine needs to wait certain number of clocks here and there (
>>for example, 80 clocks here, and 160 clocks there ). If I design
>>everything with hand, I would choose structured state machine; that is, a
>>state machine plus a counter. But since I am using VHDL, and the compiler
>>would take care of everything, I think I might be able to make a monolithic
>>state machine with the counter built in ( that is, to add 80 states here,
>>and 160 states there ).
>
>Consider making the counter a separate 
>variable. Saying n:= n + 1 in a
>few places is much cleaner than 
>describing hundreds of extra state transitions.

You need only say n:= n + 1 (I tend to use n - 1) in one place, as the
default action in the state machine process. On entering states where
you need a delay, this is over-ridden with n := delay_length. Then n=0
is simply one of the conditions for leaving the state.

If you use a signal for n, you can use an external "n_eq_z <= '1' when n
= 0 else '0';" or some such to help the synthesiser avoid replicating
the zero detection logic, but I would hope not nowadays!

- Brian


Article: 69451
Subject: Constraints interaction report
From: "Francisco Rodriguez" <prodrig@disca.upv.es>
Date: Tue, 11 May 2004 17:38:26 +0200
Links: << >>  << T >>  << A >>
Hello group,

I'm working on a design with two external clocks in a xc2v3000.
Clocks are dspclk and sysclk, and signals crossing clock domains
come from dspclk and go to sysclk only.

Apart from using blockrams, some signals from dspclk cross to sysclk
using mults and dffs-based synchronizers.
I've used the following UCF constraints to cover those signals crossing clocks:

TIMEGRP "TRG_busnoffs"  = TNM_dspclk EXCEPT FFS;
TIMEGRP "TRG_busffs"=     TNM_dspclk EXCEPT MULTS;
# When crossing from dspclk to sysclk using mults delay is not important:
TIMESPEC "TS_mults2fast" = FROM "TRG_busnoffs" TO "TNM_sysclk" TS_dspclk;
# Crossing from dspclk to sysclk using dffs require maximum setup to minimize
metastability:
TIMESPEC "TS_bus2fast" = FROM TRG_busffs TO TNM_sysclk 3 ns;


After P&R, trace generates a constraints interaction report which states that
some constraint intersection issues exist between sysclk period and TS_mults2fast
(but not TS_bus2fast).

However, from the constraints guide
"PERIOD is a basic timing constraint and synthesis constraint. A clock period
specification
checks timing between all synchronous elements within the clock domain as defined in the
destination element group. The group may contain paths that pass between clock domains
if the clocks are defined as a function of one or the other."

So i think paths coming from mults (clocked by dspclk) should not be included into the
sysclk
period constraint.

Can you help me to understand whats wrong with the constraints?
Or should I simply ignore this section of the constraint report?

A similar constraint intersection exists between the dspclk period and OFFSET IN
constraint,
and I've always thought the period constraint does not cover paths starting in pads.
Am i right?

Regards

Francisco Rodriguez


BTW, I'm using ise 6.2.02i




Article: 69452
Subject: Re: Which board to buy? Status of open source tools?
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 11 May 2004 11:46:38 -0400
Links: << >>  << T >>  << A >>
David Brown wrote:
> 
> "rickman" <spamgoeshere4@yahoo.com> wrote in message
> news:40A01F19.EDA80D9F@yahoo.com...
> > Tom Hawkins wrote:
> > >
> > > jon@beniston.com (Jon Beniston) wrote in message
> news:<e87b9ce8.0405070500.7c9c4bcc@posting.google.com>...
> > > > > Also, what's the status of open source tools?  (I like to tinker on
> > > > > the software end of things, too, and I have a bad case of PowerBook
> > > > > envy, and I haven't seen any software available other than x86 and
> > > > > big-iron UNIX).  Can they go from VHDL/Verilog all the way to
> > > > > downloading the file to the chip?  I see that compilation (Icarus
> > > > > verilog) and downloading (found it in this group's FAQ) work, but
> what
> > > > > about place and route?  Icarus' docs say it's a no-go for this; is
> > > > > there anything else, or must I use the Xilinx tools?  (I guess I
> have
> > > > > a Xilinx bias -- it's all I've used, and I don't see much else for
> > > > > cheap development boards.)
> > > >
> > > > Why bother with Open Source stuff when various incarnations of
> > > > commerical tools are free to use?
> > >
> > > Because in the long term, an open-source tool chain can out perform a
> > > commercial tool.  Case in point: how many Unix/C developers compile
> > > with a commercial alternative to GCC?
> >
> > I have been evaluating tools for the ARM MCU and all my info says that
> > gcc is a less efficient tool than the commercial ones.  I guess it only
> 
> What do you mean by "less efficient" ?  There are big differences between
> run-time efficiency and develop-time efficiency, and the balance choosen
> between these will vary according to user and project.  There is little
> doubt that there are commercial compilers that produce smaller and faster
> code than gcc for many processors (including arm), but developer efficiency
> can be a serious issue too.  I write C code for five different processors,
> amongs other work - it is simply not economically feasible to buy
> top-of-the-range commercial compilers for all of these, while gcc works fine
> for me.  I also find it in many ways to be a more advanced compiler than
> some compilers I have used (especially in terms of compile-time error
> checking).  There are plenty of cases where commercial compilers would make
> most economic sense overall, but it is far from every case.

I am not interested in debating the whole topic of open source tools. 
You have your *opinion* and I have mine.  But your *facts* are not self
evident.  Feel free to use any tool you wish.  And that includes all the
open source FPGA tools... :)


> > stands to reason that the commercial tools must be better, why else
> > would they sell well enough to keep the companies in business?
> >
> 
> There is one, and only one, reason why any company stays in business - it is
> able to persuade enough people that its product is worth the money.  It may
> or may not be the case that the product actually *is* worth the money (to
> the given customer), but the immediate technical qualities of the product
> are only one part of the sale - there are many other relevant issues such as
> support and upgrade paths, and many irrelevant issues such as the
> persuasiveness of the salesfolk, the guilibitity of the purchasing people,
> and the quality of their flashy power-point slides and free pens.  I'm not
> trying to say that commercial compilers are not worth the money - I'm just
> pointing out the naivity of the "it costs more so it must be worth more"
> argument.

Again, you confuse the facts with your opinion.  If I pay for a tool,
then by definition it is worth the money I paid.  You can assume that
products are sold by Machiavellian sales people to Dilbert purchasers,
but in the real world everyone decides for themselves what is best.  End
of story.  

-- 

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

Article: 69453
Subject: Re: FPGA wanted
From: "Stijn Goris" <mepisto@hotmail.com>
Date: Tue, 11 May 2004 15:49:42 GMT
Links: << >>  << T >>  << A >>
Hello Ray,

Can you advice a FPGA that can deliver me the 10 Mbit/s?

thanks
Stijn

"Ray Andraka" <ray@andraka.com> wrote in message
news:40A0CD8A.EF088741@andraka.com...
> I don't think there are any FPGAs that have a hardwired SPI interface, if
they
> did it would be for programming.  That said, any FPGA can be programmed
with
> an SPI interface.  The interface is fairly simple to implement, and 10
Mbit/s
> is easy to achieve.  If you mean to use the SPI as a programming interface
to
> the FPGA, you'll have to use an external device to convert the SPI to one
of
> the programming formats recognized by the FPGA.  A CPLD is sufficient for
that
> task.
>
> Stijn Goris wrote:
>
> > hi all,
> >
> > I m looking for a FPGA with a SPI interface. The SPI interface needs to
be
> > able to send data at a high rate (10 Mbit/s).
> >
> > regards
> > Stijn
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@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
>
>



Article: 69454
Subject: Re: Effects of moisture on CPLD
From: "Dave Marsh" <me@privacy.net>
Date: Tue, 11 May 2004 16:50:46 +0100
Links: << >>  << T >>  << A >>
"Leon Heller" <leon_heller@hotmail.com> wrote in message
news:40a0ebc8$0$25328$cc9e4d1f@news-text.dial.pipex.com...
> "Dave Marsh" <me@privacy.net> wrote in message
> news:40a0dd9d$0$15249$fa0fcedb@lovejoy.zen.co.uk...
> > I have twenty Xilinx XC9572XL VQFP64. Their sealed package has been open
> two
> > months, and stored in an office with no temperature/humidity control.
Now
> I
> > want to get these devices soldered in for a pre-production run.
> >
> > If I put these in without carrying out a baking cycle am I asking for
> > trouble? What are the likely effects due to moisture, and what are
> people's
> > real-life experiences?
>
> Reflow soldering without baking them (probably 120 C for 24 hours) might
> give problems. Hand soldering should be OK: I never have problems, anyway.
>
> Leon
> --
> Leon Heller, G1HSM
> http://www.geocities.com/leon_heller
>

Thanks Leon. That's interesting, as the first few are going to be hand
soldered (and I don't have a proper oven at the moment).

Dave






Article: 69455
Subject: EasyPath
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 11 May 2004 08:52:09 -0700
Links: << >>  << T >>  << A >>
Brian,

You are correct.  The parts have passed a specific suite of tests for 
one or more customer designs.  It turns out that you can test for up to 
about three different designs all at once, and still maintain the same 
time/yield benefit!

At some point in the future, all parts will be 'EasyPath'*--the new 
technologies envisioned (carbon nanotube transistors, spintronics, etc.) 
all lend themselves to building FPGAs, and to "qualifying" parts for 
applications, as no one part will ever have 100% of its nanostructures 
working perfectly (there will always be flaws).

Austin

*under license of course

Brian Drummond wrote:
> On Mon, 10 May 2004 09:21:27 -0700, Jim Lewis <Jim@SynthWorks.com>
> wrote:
> 
> 
>>acm wrote:
>>
>>>Easypath = EasyScrap...
>>>
>>>Hey, buy our excess scrapped inventory!!!!
>>>
>>
>>What is wrong with taking lemons and making Lemonade?
>>
>>Xilinx has taken the enviromentally sound practice
>>of taking parts that would have otherwise gone to the
>>dump, making them into something useful, and selling
>>them.
> 
> 
> I don't believe they have, as I understand it, I don't believe the
> EasyPath parts have actually failed production test.
> 
> As I recall, it was the full testing itself that was expensive, rather
> than the device failures. To take it to extremes, if you can churn out
> wafers full of good devices, but you have to leave each chip sitting on
> the tester for eight hours to prove it, then test costs would be a
> killer.
> 
> That would give a LOT of scope for testing exactly what a customer
> wants, and no more, and passing on the reduced cost of test time. The
> difference is, the rest of the chip is POSSIBLY fully functional, but
> Xilinx haven't spent the money to prove it.
> 
> 
>>To me this reflects engineering brillance.
> 
> 
> Either way...
> 
> - Brian
> 

Article: 69456
Subject: Re: Which board to buy? Status of open source tools?
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 11 May 2004 11:52:53 -0400
Links: << >>  << T >>  << A >>
Tom Hawkins wrote:
> 
> rickman <spamgoeshere4@yahoo.com> wrote in message news:<40A01F19.EDA80D9F@yahoo.com>...
> > Tom Hawkins wrote:
> > >
> > > jon@beniston.com (Jon Beniston) wrote in message
> [snip]
> > > >
> > > > Why bother with Open Source stuff when various incarnations of
> > > > commerical tools are free to use?
> > >
> > > Because in the long term, an open-source tool chain can out perform a
> > > commercial tool.  Case in point: how many Unix/C developers compile
> > > with a commercial alternative to GCC?
> >
> > I have been evaluating tools for the ARM MCU and all my info says that
> > gcc is a less efficient tool than the commercial ones.  I guess it only
> > stands to reason that the commercial tools must be better, why else
> > would they sell well enough to keep the companies in business?
> 
> Certainly when a compiler targets a specific architecture, it can do a
> better job.  But in terms of the number of supported platforms and its
> decent code optimization, it's hard to beat GCC.

I am not going to debate the open source tool question.  I don't care
what you use.  But it is not a *fact* that GCC "out performs" commercial
tools.  


> > > Unfortunately, the track record of open-source FPGA implementation
> > > tools has been dismal.  Icarus is the only open-source tool I know
> > > that attempts Xilinx synthesis.  I believe it handles synthesis and
> > > technology mapping, but has little, if no optimization.
> >
> > I think John Jakson summed it up pretty well, open source FPGA tools are
> > not practical for a number of reasons that have been discussed here many
> > times before.  Some people seem to think that FPGA and ASIC tools are
> > the same as compiliers, but in reality they are very different.
> 
> Sure the algorithms are different, but there are many similarities:
> Like a compiler, most logic optimizations are NP-complete, therefore
> many of the same strategies can be applied.   Both a compiler and a
> synthesizer deal with dataflow analysis and resource allocation.
> Instruction reordering is similar to retiming.  Memory and execution
> timing tradeoffs are somewhat analogous to tradeoffs with area and
> performance.

There may be a few similarities, but you are only looking at technical
issues.  The real problem has to do with the way the FPGA devices keep
changing.  It is a major job for the vendors to keep up with their own
devices, it is not practical for open source tools to always be a
generation or two behind.  

If it is so practical, why has it not been done properly?  As an earlier
poster stated, some projects have been started, but none have produced
anything useful and many have just been dropped.  

> I agree the closer you get to implementation, the less pratical an
> open source tool becomes.  But where is the line drawn?  Clearly
> synthesis falls on our side.  Multi-chip partioning is certainly
> possible.  And with the capabilities of UCF, I would argue placement
> is a canidate as well.

So where are the tools?  Rather than rehash the issue here, google this
group and read what has already been posted over the last two years.  

-- 

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

Article: 69457
Subject: Re: Effects of moisture on CPLD
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 11 May 2004 08:53:37 -0700
Links: << >>  << T >>  << A >>
Dave,

Yes, you would notice a difference!  Not all parts will pop, and those 
that do, may not even be noticed initially.  Later they will fail as 
they will now absorb water like crazy from all of the cracks.

Austin

Dave Marsh wrote:

> "Austin Lesea" <austin@xilinx.com> wrote in message
> news:c7qnr5$n103@cliff.xsj.xilinx.com...
> 
>>Dave Marsh wrote:
>>
>>>I have twenty Xilinx XC9572XL VQFP64. Their sealed package has been open
> 
> two
> 
>>>months, and stored in an office with no temperature/humidity control.
> 
> Now I
> 
>>>want to get these devices soldered in for a pre-production run.
>>>
>>>If I put these in without carrying out a baking cycle am I asking for
>>>trouble? What are the likely effects due to moisture, and what are
> 
> people's
> 
>>>real-life experiences?
>>>
>>>Many thanks,
>>>
>>>Dave
>>
>>Dave,
>>
>>The packages may have absorbed moisture, and if you put them through a
>>normal solder wave machine, you will have popcorn.
>>
>>The devices are prone to crack, and shatter due to the moisture turning
>>to steam, and having no where to go.
>>
>>Parts may be baked before assembly to remove the water.
>>http://www.xilinx.com/bvdocs/whitepapers/wp192.pdf
>>details some of the procedures.
>>
>>Austin
>>
> 
> 
> Thanks Austin - It sounds like we we would definitely notice if there was a
> problem then?! From the white paper it suggests a minimum of a 12 hour cycle
> at 125degC is needed.
> 
> Dave
> 
> 
> 

Article: 69458
Subject: How do I find where P&R has placed my BRAM?
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 11 May 2004 09:47:59 -0700
Links: << >>  << T >>  << A >>
Hi,
I use Data2Mem to load a V2Pro BRAM. I'd rather not lock the position of the
BRAM just yet, so how do I automate the process of finding where place and
route has put my BRAM? Using FPGA viewer is getting to be a pain.
TIA, SYms.



Article: 69459
Subject: Re: Easypath question (was "Hard-tocopy" rant)
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 11 May 2004 19:10:35 +0200
Links: << >>  << T >>  << A >>
Jim Lewis <Jim@SynthWorks.com> writes:

> acm wrote:
> > Easypath = EasyScrap...
> > Hey, buy our excess scrapped inventory!!!!
> >
> What is wrong with taking lemons and making Lemonade?

Drive manufactures have been doing this for years. They just maintain
a defect sector list on the drive.

Petter

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 69460
Subject: Re: EasyPath
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 11 May 2004 19:12:41 +0200
Links: << >>  << T >>  << A >>
Austin Lesea <austin@xilinx.com> writes:

> At some point in the future, all parts will be 'EasyPath'*--the new
> technologies envisioned (carbon nanotube transistors, spintronics,
> etc.) all lend themselves to building FPGAs, and to "qualifying" parts
> for applications, as no one part will ever have 100% of its
> nanostructures working perfectly (there will always be flaws).

I guess it will be a question of time until there will be support in
ISE to map out defects for a given target device? Maybe we'll have
configuration-time mapping of defects in the future.

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 69461
Subject: Re: Effects of moisture on CPLD
From: "Leon Heller" <leon_heller@hotmail.com>
Date: Tue, 11 May 2004 18:26:45 +0100
Links: << >>  << T >>  << A >>
"Dave Marsh" <me@privacy.net> wrote in message
news:40a0f66b$0$15245$fa0fcedb@lovejoy.zen.co.uk...
> "Leon Heller" <leon_heller@hotmail.com> wrote in message
> news:40a0ebc8$0$25328$cc9e4d1f@news-text.dial.pipex.com...
> > "Dave Marsh" <me@privacy.net> wrote in message
> > news:40a0dd9d$0$15249$fa0fcedb@lovejoy.zen.co.uk...
> > > I have twenty Xilinx XC9572XL VQFP64. Their sealed package has been
open
> > two
> > > months, and stored in an office with no temperature/humidity control.
> Now
> > I
> > > want to get these devices soldered in for a pre-production run.
> > >
> > > If I put these in without carrying out a baking cycle am I asking for
> > > trouble? What are the likely effects due to moisture, and what are
> > people's
> > > real-life experiences?
> >
> > Reflow soldering without baking them (probably 120 C for 24 hours) might
> > give problems. Hand soldering should be OK: I never have problems,
anyway.
> >
> > Leon
> > --
> > Leon Heller, G1HSM
> > http://www.geocities.com/leon_heller
> >
>
> Thanks Leon. That's interesting, as the first few are going to be hand
> soldered (and I don't have a proper oven at the moment).

If you get a PCB assembly company to do the others, they should be able to
do the baking for you. They probably do it all the time.

Leon



Article: 69462
Subject: Re: FPGA wanted
From: "valentin tihomirov" <valentin_NOSPAM_NOWORMS@abelectron.com>
Date: Tue, 11 May 2004 21:00:38 +0300
Links: << >>  << T >>  << A >>
Almost any modern FPGA should!


"Stijn Goris" <mepisto@hotmail.com> wrote in message
news:qC6oc.102796$0s2.6160413@phobos.telenet-ops.be...
> Hello Ray,
>
> Can you advice a FPGA that can deliver me the 10 Mbit/s?
>
> thanks
> Stijn
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:40A0CD8A.EF088741@andraka.com...
> > I don't think there are any FPGAs that have a hardwired SPI interface,
if
> they
> > did it would be for programming.  That said, any FPGA can be programmed
> with
> > an SPI interface.  The interface is fairly simple to implement, and 10
> Mbit/s
> > is easy to achieve.  If you mean to use the SPI as a programming
interface
> to
> > the FPGA, you'll have to use an external device to convert the SPI to
one
> of
> > the programming formats recognized by the FPGA.  A CPLD is sufficient
for
> that
> > task.
> >
> > Stijn Goris wrote:
> >
> > > hi all,
> > >
> > > I m looking for a FPGA with a SPI interface. The SPI interface needs
to
> be
> > > able to send data at a high rate (10 Mbit/s).
> > >
> > > regards
> > > Stijn
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@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
> >
> >
>
>



Article: 69463
Subject: Re: FPGA vs Microprocessor: newbie question
From: "Chris Cheung" <chris_cheung66@hotmail.com>
Date: Tue, 11 May 2004 18:06:50 GMT
Links: << >>  << T >>  << A >>

The major advantages of using FPGA - You can have all your modules do 
processing in parallel.  Such as digital filters.  Microprocessor simply cannot do it. 
 
 
>"José da Rocha" <jose_rocha@yahoo.com> wrote in message news:ee84240.-1@WebX.sUN8CHnE...
>Hello. 
>I’m new at the FPGA world. I understand that a FPGA and a microprocessor 
>are NOT similar physical devices. (With a FPGA we can design our own digital functions) 
>I would like to know what are the main reasons to use a FPGA instead 
>of a microprocessor in a real world application ? 
>Can anyone describe me some real world applications where the use of a 
>FPGA is a more suitable solution than the use of a microprocessor and why? 
>
>Thank you very much for your answer 
>
>José da Rocha






Article: 69464
Subject: Re: Which board to buy? Status of open source tools?
From: "nospam" <nospam@hotmail.com>
Date: Tue, 11 May 2004 20:19:15 +0200
Links: << >>  << T >>  << A >>

"Anna Acevedo" <acevedo@xilinx.com> escribió en el mensaje
news:409FD261.DF96BD2C@xilinx.com...
> Digilent Inc  (www.digilentinc.com) has several low cost boards mainly
> used in academia but available to all. Soon they will be releasing a
> Spartan-3 board and in a couple of months a Virtex-II Pro board.
>
> Anna Acevedo - Manager
> Xilinx University Program
>


hi, is there any Virtex-II Pro (with only one PPC core embedded,
XC2VP4-5FG456C), the clock, config ROM, JTAG (maybe also USB) and some RAM
board out there?

cause i've seen some cards from Memec (there's one at about 400dollars with
EDK and 200 without it), but they dont have any RAM, and other boards have
too much peripheals that i dont need and then they have like 20 user I/O
pins available, cause they have keyboard, display, leds, parallel port, A/D,
D/A, video, and a lot of other stuff. If i wanted those peripheals later i
guess i'd get a daughter board, but in the beggining i'd like as much I/O as
possible

another one is the one for gameboy (i dont know it's name) it seems to have
everything i want, just the FPGA is not a Virtex-II Pro

any pointers will be appreciated




> Joel Hardy wrote:
>
> > Howdy all,
> >
> > I'm looking to get an FPGA development board sometime soon.  When I
> > was in college, I played with what was probably the Xess XSB-300E (fun
> > stuff: we made a  PCMCIA interface and plugged it into an iPaq... but
> > that's another story).  That's WAY outside of my price range (<
> > $200US), but the XSA-50 doesn't look too bad.  Any comments on that
> > one?  Also, I found this
> > (www.nuhorizons.com/products/xilinx/spartan3/development-board.html),
> > which looks considerably better to me, especially since my main
> > prospective project would benefit from a large amount of fast RAM.
> > Any advice?  Is there anything else in the sub-$200 I should look at?
> >
> > Also, what's the status of open source tools?  (I like to tinker on
> > the software end of things, too, and I have a bad case of PowerBook
> > envy, and I haven't seen any software available other than x86 and
> > big-iron UNIX).  Can they go from VHDL/Verilog all the way to
> > downloading the file to the chip?  I see that compilation (Icarus
> > verilog) and downloading (found it in this group's FAQ) work, but what
> > about place and route?  Icarus' docs say it's a no-go for this; is
> > there anything else, or must I use the Xilinx tools?  (I guess I have
> > a Xilinx bias -- it's all I've used, and I don't see much else for
> > cheap development boards.)
> >
> > Thanks for the help!
> > - Joel Hardy
>



Article: 69465
Subject: Re: is it possible to design usb only with fpga?
From: "Antonio Pasini" <NOSPAM_pasini.a@tin.it>
Date: Tue, 11 May 2004 18:57:54 GMT
Links: << >>  << T >>  << A >>
>   Is it possible to make a USB 1.1 interface only with FPGA chip, I mean,
> without addtional transceiver chip?

Have a look to http://member.nifty.ne.jp/fpga/freeip/usb/index.html.

I had a look to the VHDL source, and to the schematic.

He's not using any external transceiver, it seems.

Now, if I just learnt japanese at school :-)...




Article: 69466
Subject: Re: EasyPath
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 11 May 2004 11:58:18 -0700
Links: << >>  << T >>  << A >>
Petter,

Being able to map out defects is not the solution:  that is a nightmare 
for customers who demand a repeatable and reliable solution.  It does no 
good to be able to map out a bad resource, unless it is guaranteed to 
not affect the overall performance of the design, and it can be done 
automatically with a 100% chance of success.  Even redundancy today 
accomplished by laser programming has its problems in FPGAs (timing is 
different).

A FPGA is not a disk drive.  A disk drive can not only have a map of bad 
tracks written into it, but the operating system can cooperate by not 
using the bad tracks, and nothing goes wrong.

If I have a bad LUT (for example), how do I know?  Did I test it 
apriori, and then what?  Did I somehow write that information into the 
device (the old non-existant non-volatile memory problem again)?  If so, 
how the heck do I use that information when the bitstream wants to just 
go ahead and configure the part?

It is a very complex problem, one that does not have a solution (today).

EasyPath resolves the problem by limiting the scope of the problem to be 
solved.  A bit like attaching the horse in front of the carriage, 
instead of trying to push the carriage from behind with the horse:  it 
just takes a really tough problem, and simplifies it immensely.

No need to drive around the potholes, the streets are all pre-screened, 
so that there are no potholes (where I want to drive).

The developer still must be able to create the program in the first 
place, which either requires a map of defects (if a perfect device is 
impossible to make), or some kind of automatic fault detection and 
avoidance scheme.  The map of defects would allow the software to get 
that one part running, or the few parts for the prototypes before the 
EasyPath program takes over.  Very much like the disk drive case.  Those 
devices with defect maps then become the expensive units, as they need 
the labor for the maps (and the maps are just a file from the internet 
perhaps).  The EasyPath parts remain the bargain.

Austin



Petter Gustad wrote:
> Austin Lesea <austin@xilinx.com> writes:
> 
> 
>>At some point in the future, all parts will be 'EasyPath'*--the new
>>technologies envisioned (carbon nanotube transistors, spintronics,
>>etc.) all lend themselves to building FPGAs, and to "qualifying" parts
>>for applications, as no one part will ever have 100% of its
>>nanostructures working perfectly (there will always be flaws).
> 
> 
> I guess it will be a question of time until there will be support in
> ISE to map out defects for a given target device? Maybe we'll have
> configuration-time mapping of defects in the future.
> 
> Petter

Article: 69467
Subject: Re: One issue about free hardware
From: mike_treseler@comcast.net (Mike Treseler)
Date: 11 May 2004 12:15:12 -0700
Links: << >>  << T >>  << A >>
Tom Hawkins wrote:
> Richard Stallman wrote:
> > One of the reasons free software is important is so that you can
> > control your computer and make sure you know what it does.
> > It's not enough to be able to see what someone claims is the
> > source code for the program you are using.  To trust it, you have
> > to be able to compile it yourself.

I trust software as long as it works and doesn't bite.
I trust GNU software, not because I can compile
it, but because it works better than any alternative
for many of the things that I do.

> > As hardware becomes more complex, the same issue may arise: how do
> > you know what you hardware really does?  

By using design rules and a simulator 
you trust to generate and verify synth code.

> The bigger problem is the complete lack of an open-source flow from
> RTL to implementation.  There is simply no GCC equivalent for
> compiling digital logic -- every ASIC and FPGA designer is at the
> mercy of commercial tools on the font-end.  (My biggest pet-peeve is
> FPGA synthesis.  FPGAs have had dual-port RAMs for ~7 years now, yet
> we still can't infer dual-port block RAM from HDL.  Arggh!)

I agree that is annoying. But there is more than
one way to skin a cat. If I can't infer a primitive from code, 
I have the option of not using it. 
A pseudo dual-port works fine for synch fifos
and is portable across brands.

> One hurdle to open-source synthesis and place&route is proprietary
> architectures.  The major FPGA vendors refuse to disclose the
> underlying details needed to for a quality PAR tool or physical
> synthesis.

I agree that this is a problem for open-source tool designers,
but at least one FPGA designer spends most of his time 
at the front end, not in PAR. 
The vendor tools are adequate for some designs as is.

> But oddly enough the biggest roadblock to open-source EDA is
> ourselves.  For some reason or another, there is an apparent lack of
> interest and motivation.  Just a few examples:
> 
> 1. Every couple of months the topic of open-source tools arise. 
> Generates quite a bit of discussion, then dies as quickly as it
> started.

Tool development and QA is a full-time job. While I agree
with the open-source philosophy, until I am retired,
trying out beta level tools is just a hobby.

> 2. With Confluence under GPL, I have yet to receive a single bug
> report or source code contribution.

A simple Confluence reference design worked all the way 
through simulation and synthesis might help FPGA guys "get it".
The same example done in vhdl or verilog would be a plus.

> 3. Icarus Verilog, the foremost open-source Verilog implementation,
> still only has one active developer.
> 4. The only semi-successful FPGA packing, placement, and routing
> project halted activity in March, 2000.
> 5.  The one person who came the closest to reverse engineering the
> Virtex bit stream -- the critical step for physical synthesis --
> became frustrated with the lack of support and interest from the FPGA
> community, and finally closed shop on 12/24/2003.

Same answer as above.
Qualified FPGA+tool designers are rare,
and most are working for a living.

> What can we do to improve open-source EDA?

Consider focusing on the front end. 
Gather a few complete examples to get
FPGA guys interested.

      -- Mike Treseler

Article: 69468
Subject: MOCA Design 2005
From: Mike Wirthlin <wirthlin@ee.byu.edu>
Date: Tue, 11 May 2004 13:18:54 -0600
Links: << >>  << T >>  << A >>

* The Mobile Computing Architectures (MOCA) conference is including a reconfigurable computing emphasis area. 


Call For Papers: Papers due June 15, 2004
 
MOCA Design 2005
=================
Mobile Computing Architectures, Design and Implementation
http://www.scism.lsbu.ac.uk/ERA/moca.htm
 
Software Technology Track
Thirty-eighth Annual
HAWAI'I INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES
 
HICSS'38
http://www.hicss.hawaii.edu/
 
Mirror sites: http://hicss.sepa.tudelft.nl/   and http://www.is.cityu.edu.hk/hicss/
 
January 3 - 6, 2005
Hilton Waikoloa Village Resort
on the Big Island of Hawaii
 

Introduction
============
 
Mobile communication systems and handheld consumer appliances (cellular and video phones, MP3
players, global positioning systems, digital cameras, personal digital advisors) are the
emerging areas in computer and communication applications. These new applications demand
a new technology and present new challenges for its designers.
 
The recent advances in wireless computing systems and research for suitable architectural
solutions have emphasized the ideas behind reconfigurable computing: implementing algorithms
in configurable computational space. The mobile computing together with reconfigurable
computing has becoming a new trend in hardware designs and is an important area of active
scientific research.
 

Topics:
=======
 
The list of topics includes but is not limited by the following:
 
 O Reconfigurable computing architectures.
 O Compiling high-level languages for reconfigurable platform
 O Run-time configuration and process management
 O Energy efficient adaptive architectures
 O Communication system algorithms and protocols
 O Image and signal processing algorithms
 O Data compression and security algorithms in mobile systems
 O Other topics related to wireless communication systems
 

Important Deadlines:
====================
 

March 31, 2004      Authors contact Minitrack Chairs for guidance and indication of
appropriate content.  (Optional)
 
June 15, 2004 Authors submit full papers to the appropriate Minitrack following format
and submission instructions on the web site.
 
August 15, 2004     Minitrack Chairs send Acceptance/Rejection notices to Authors.
 
October 1, 2004     Authors submit Final Version of paper electronically to publisher.  
At least one author of each paper must register by this date to attend the conference to
present the paper.  
 
December 1, 2004 Deadline to guarantee your hotel room reservation at the conference rate.
 

Instructions for Paper Submission:
==================================
 
o HICSS papers must contain original material not previously published, or currently submitted
elsewhere.
 
o Consult the conference website for the listing and description of Minitracks for HICSS-38.
 
o (optional)  Contact the Minitrack Chair(s) by email for guidance and verification of
appropriate content.
 
o Do not submit the manuscript to more than one Minitrack Chair.   If unsure of which
Minitrack is appropriate, submit abstract to the Track Chair for guidance. 
 
o Submit your full paper according to the detailed formatting and submission instructions
found on the HICSS website.  Note:  All papers will be submitted in double column publication
format and limited to 10 pages including diagrams and references.
 
 
 

Minitrack Chairman
==================
 
Dr. Toomas P. Plaks
Email: plakst@lsbu.ac.uk
 
London South Bank University
BCIM
103 Borough Road
London SE1 0AA
United Kingdom
 
Co-Chairs
=========
 
Philip Leong 
Chinese Univ. of Hong Kong
China
 
Michael J. Wirthlin              
Brigham Young University           
USA
 
 
 
MOCA Web Page:
==============
http://www.scism.lsbu.ac.uk/ERA/moca.htm
 

HICSS-38 CONFERENCE TRACKS
* Collaboration Systems and Technology - Co-Chair: Jay Nunamaker; E-mail: jnunamaker@cmi.arizona.edu;
Co-Chair: Robert O. Briggs; E-mail: bob@GroupSystems.com
* Complex Systems - Chair: Robert Thomas; E-mail: rjt1@cornell.edu
* Decision Technologies for Management - Chair: Dan Dolk; E-mail: drdolk@nps.navy.mil
* Digital Documents and the Media - Chair: Michael Shepherd; E-mail: shepherd@cs.cal.ca                        
* Emerging Technologies -  Chair: Ralph H. Sprague; E-mail: sprague@hawaii.edu  
* Information Technology in Health Care - Chair: William Chismar;
E-mail: chismar@cba.hawaii.edu
* Internet & the Digital Economy - Co-Chair: David King; E-mail: david.king@jda.com    
Co-Chair: Alan Dennis; E-mail: ardennis@indiana.edu
* Organizational Systems & Technology - Chair: Hugh Watson; Email: hwatson@terry.uga.edu
* Software Technology - Chair: Gul Agha; E-mail: agha@cs.uiuc.edu
 
HICSS conferences are devoted to advances in the information, computer, and system sciences,
and encompass developments in both theory and practice.   Invited papers may be theoretical,
conceptual, tutorial or descriptive in nature.  Submissions undergo a peer referee process and
those selected for presentation will be published in the Conference Proceedings.  Submissions
must not have been previously published.
 

For the latest information; visit the HICSS web site at:    http://www.hicss.hawaii.edu
or the mirror sites   : http://hicss.sepa.tudelft.nl/      and   http://www.is.cityu.edu.hk/hicss/
 

CONFERENCE ADMINISTRATION
Ralph Sprague, Conference Chair                           
Email:  sprague@hawaii.edu
 
Sandra Laney, Conference Administrator
Email:  hicss@hawaii.edu
 
Eileen Robichaud Dennis, Track Administrator
Email: eidennis@indiana.edu
 
2005 CONFERENCE VENUE
Hilton Waikoloa Village (on the Big Island of Hawaii)
425 Waikoloa Beach Drive
Waikoloa, Hawaii 96738
Tel: 1-808-886-1234
Fax: 1-808-886-2900
www.hiltonwaikoloavillage.com
 



Article: 69469
Subject: Re: FPGA vs Microprocessor: newbie question
From: Rene Tschaggelar <none@none.net>
Date: Tue, 11 May 2004 22:10:15 +0200
Links: << >>  << T >>  << A >>
Jos=E9 da Rocha wrote:
> Hello.
> I=92m new at the FPGA world. I understand that a FPGA and a microproces=
sor=20
> are NOT similar physical devices. (With a FPGA we can design our own=20
> digital functions)
>=20
> I would like to know what are the main reasons to use a FPGA instead of=
=20
> a microprocessor in a real world application ?
> Can anyone describe me some real world applications where the use of a =

> FPGA is a more suitable solution than the use of a microprocessor and w=
hy?

There are functionalities that are better done in software and there
are others that are better done in hardware.

Point of interest may be the feasibility, power consumption, required=20
clock speed, ..

Though not generally true, the more trivial the functionality,
the simpler it is to be made in an FPGA. The more complex the=20
functionality, the better it is done with software.
As sidenote, there are microcontrollers available to be put into an
FPGA.

Rene
--=20
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Article: 69470
Subject: Re: is it possible to design usb only with fpga?
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 11 May 2004 13:22:13 -0700
Links: << >>  << T >>  << A >>
Antonio,
Try http://babelfish.altavista.com/ and stick the URL in the Website
translate bit. No Japanese to Italian, but is English OK?
cheers, Syms.

"Antonio Pasini" <NOSPAM_pasini.a@tin.it> wrote in message
news:Sm9oc.239685$rM4.10253575@news4.tin.it...
>
> Now, if I just learnt japanese at school :-)...
>



Article: 69471
Subject: Re: EasyPath
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 11 May 2004 22:34:19 +0200
Links: << >>  << T >>  << A >>
Austin Lesea <austin@xilinx.com> writes:


> Being able to map out defects is not the solution: that is a
> nightmare for customers who demand a repeatable and reliable

The customer has to be aware and understand this. The win is low cost
devices. The drawback is that you would not know the performance of
your device until you run ISE. I think it could be worthwhile for some
(presumably low volume) high density applications where you can do
without a RAM or several LUT's. If I could get a 40K LUT device at 50%
off for an ASIC prototyping application I would go for it.

> If I have a bad LUT (for example), how do I know?  Did I test it
> apriori, and then what?  Did I somehow write that information into the
> device (the old non-existant non-volatile memory problem again)?  If
> so, how the heck do I use that information when the bitstream wants to
> just go ahead and configure the part?

The defect lists could be written out by the test equipment. A
database for each part had to be maintained. ISE could load the defect
list (over the Internet) for the particular target device and avoid
using the defective resources when you run map and par. This is of
course a logistics challenge as well.

configuration-time-mapping is of course a very complex problem. I
should have put a smiley there. But you could think of certain defects
where you map to a spare neighbor LUT and you know in advance that it
would not violate timing. This would require preprocessing and
modification (or running ISE on the embedded PPC :-) of the bitstream
on-the-fly.

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 69472
Subject: Re: FPGA wanted
From: Ray Andraka <ray@andraka.com>
Date: Tue, 11 May 2004 16:56:23 -0400
Links: << >>  << T >>  << A >>
An FPGA certainly can do the conversion, but you'll have to design the circuit
to go in the FPGA to do that conversion.  The FPGA can be viewed as a big box of
uncommitted logic gates.  What you hook them up to do is up to the FPGA
designer.  10MBits/sec is achievable with any modern FPGA.  Pick one based on
your costs and comfort with that FPGA's tools.


Stijn Goris wrote:

> I want to use a RTL8019 chip and want to interface it with a SPI bus
> (datasheet: ftp://210.51.181.211/cn/nic/rtl8019as/spec-8019as.zip). I 'm
> having trouble finding a good way to make the SPI communication. Someone
> stated that an FPGA could do the conversion. Maybee you have a better idea?
>
> kind regards
> Stijn
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:40A0CD8A.EF088741@andraka.com...
> > I don't think there are any FPGAs that have a hardwired SPI interface, if
> they
> > did it would be for programming.  That said, any FPGA can be programmed
> with
> > an SPI interface.  The interface is fairly simple to implement, and 10
> Mbit/s
> > is easy to achieve.  If you mean to use the SPI as a programming interface
> to
> > the FPGA, you'll have to use an external device to convert the SPI to one
> of
> > the programming formats recognized by the FPGA.  A CPLD is sufficient for
> that
> > task.
> >
> > Stijn Goris wrote:
> >
> > > hi all,
> > >
> > > I m looking for a FPGA with a SPI interface. The SPI interface needs to
> be
> > > able to send data at a high rate (10 Mbit/s).
> > >
> > > regards
> > > Stijn
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@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
> >
> >

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@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



Article: 69473
Subject: Re: VHDL Beginner: Reset a counter (instead of "000000000....000000") -
From: Ray Andraka <ray@andraka.com>
Date: Tue, 11 May 2004 16:57:40 -0400
Links: << >>  << T >>  << A >>
And historically, some synthesis tools choked on B, although I don't
think there are any that will balk at it now.

Michael Schöberl wrote:

> >     A <= "000" & X;        -- sometimes I use this
> >
> >     B <= (others => '0');  -- I've also tried this
> >     B(7 downto 0) <= X;
>
> I don't like the second description because in many cases
> it is NOT obvious that there is a default value ...
>
> Imagine someone who inserts something else between
> the "B" lines ... I've seen this in larger processes (default-values
> at the beginning and some declarations later on) ...
> not very easy to read ... :-(
>
> bye,
> Michael

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@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



Article: 69474
Subject: Re: Which board to buy? Status of open source tools?
From: "David Brown" <david@no.westcontrol.spam.com>
Date: Tue, 11 May 2004 22:58:26 +0200
Links: << >>  << T >>  << A >>

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:40A0F55E.2E475D3B@yahoo.com...
> David Brown wrote:
> >
> > "rickman" <spamgoeshere4@yahoo.com> wrote in message
> > news:40A01F19.EDA80D9F@yahoo.com...
> > > Tom Hawkins wrote:
> > > >
> > > > jon@beniston.com (Jon Beniston) wrote in message
> > news:<e87b9ce8.0405070500.7c9c4bcc@posting.google.com>...
> > > > > > Also, what's the status of open source tools?  (I like to tinker
on
> > > > > > the software end of things, too, and I have a bad case of
PowerBook
> > > > > > envy, and I haven't seen any software available other than x86
and
> > > > > > big-iron UNIX).  Can they go from VHDL/Verilog all the way to
> > > > > > downloading the file to the chip?  I see that compilation
(Icarus
> > > > > > verilog) and downloading (found it in this group's FAQ) work,
but
> > what
> > > > > > about place and route?  Icarus' docs say it's a no-go for this;
is
> > > > > > there anything else, or must I use the Xilinx tools?  (I guess I
> > have
> > > > > > a Xilinx bias -- it's all I've used, and I don't see much else
for
> > > > > > cheap development boards.)
> > > > >
> > > > > Why bother with Open Source stuff when various incarnations of
> > > > > commerical tools are free to use?
> > > >
> > > > Because in the long term, an open-source tool chain can out perform
a
> > > > commercial tool.  Case in point: how many Unix/C developers compile
> > > > with a commercial alternative to GCC?
> > >
> > > I have been evaluating tools for the ARM MCU and all my info says that
> > > gcc is a less efficient tool than the commercial ones.  I guess it
only
> >
> > What do you mean by "less efficient" ?  There are big differences
between
> > run-time efficiency and develop-time efficiency, and the balance choosen
> > between these will vary according to user and project.  There is little
> > doubt that there are commercial compilers that produce smaller and
faster
> > code than gcc for many processors (including arm), but developer
efficiency
> > can be a serious issue too.  I write C code for five different
processors,
> > amongs other work - it is simply not economically feasible to buy
> > top-of-the-range commercial compilers for all of these, while gcc works
fine
> > for me.  I also find it in many ways to be a more advanced compiler than
> > some compilers I have used (especially in terms of compile-time error
> > checking).  There are plenty of cases where commercial compilers would
make
> > most economic sense overall, but it is far from every case.
>
> I am not interested in debating the whole topic of open source tools.
> You have your *opinion* and I have mine.  But your *facts* are not self

Much of what I wrote was not opinion, but fact - for the particular case in
question (i.e., my professional compiler usage).  As I said, the situation
will be different for different people - that's also fact.  As for
opinions - we all have plenty of them!

> evident.  Feel free to use any tool you wish.  And that includes all the
> open source FPGA tools... :)
>

Choice is an excellent thing - in the case of fpga development, I choose to
use an open-source tool (Confluence - once I get the hang of it :-), a
closed source paid-for tool (Quartus), a paid-for (but with some source)
component (Nios), and open-source compiler and debugger software
masquerading as closed-source (Gnu-pro compiler toolset for the Nios).  I
like to be able to pick and choose.

Incidently, isn't it interesting that both Altera and Xilinx have
standardised on gcc for the compiler for their soft-processor cores?

>
> > > stands to reason that the commercial tools must be better, why else
> > > would they sell well enough to keep the companies in business?
> > >
> >
> > There is one, and only one, reason why any company stays in business -
it is
> > able to persuade enough people that its product is worth the money.  It
may
> > or may not be the case that the product actually *is* worth the money
(to
> > the given customer), but the immediate technical qualities of the
product
> > are only one part of the sale - there are many other relevant issues
such as
> > support and upgrade paths, and many irrelevant issues such as the
> > persuasiveness of the salesfolk, the guilibitity of the purchasing
people,
> > and the quality of their flashy power-point slides and free pens.  I'm
not
> > trying to say that commercial compilers are not worth the money - I'm
just
> > pointing out the naivity of the "it costs more so it must be worth more"
> > argument.
>
> Again, you confuse the facts with your opinion.  If I pay for a tool,
> then by definition it is worth the money I paid.  You can assume that
> products are sold by Machiavellian sales people to Dilbert purchasers,
> but in the real world everyone decides for themselves what is best.  End
> of story.
>

By your definitions, you must be a perfect customer.  Are you suggesting
that you have never bought something that was not a good buy?  I'm sure you
make careful decisions about purchasing an expensive development tool - most
of us do that (at least, those of us who are fortunate enough to be able to
make such purchasing decisions ourselves).  But there is a long way between
the extremes of the mythical perfect customer and the mythical perfect
salesman and idiot customer combination.






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