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 21550

Article: 21550
Subject: Re: FPGA openness
From: husby@fnal.gov (Don Husby)
Date: Fri, 24 Mar 2000 17:42:34 GMT
Links: << >>  << T >>  << A >>
galexand@sietch.bloomington.in.us (Greg Alexander) wrote:
> In article <8bg2qr$cqp$1@info3.fnal.gov>, Don Husby wrote:

> >galexand@sietch.bloomington.in.us (Greg Alexander) wrote:
> Getting rid of the bugs is small compared to the peace of mind of
> understanding the software.

Right, I got it from your first few posts.  This is a spiritual thing
for you.  Nothing is stopping you from understanding.  I'm just saying
you'd get a little more credibilty on that point if you took the time
to do some of that unsderstanding before shooting your mouth off.
And, like the religous fanatics, if you feel you have to flog yourself
in order to unsderstand it, be my guest.
(I'll leave a break here for you to point out how intolerant I am.  It's
my spiriual quest to make fun of people who flog themselves.  I hope
you have no problem with that.)

> >Well, it's a nice dream, Greg, and maybe it's sometimes true for real
> >artists and geniuses, but it's clear from your posts that you barely
> >have a clue.  That you haven't even seen the commercial tools that you
> >fear so much.  That you haven't ever done an FPGA design.
> 
> I have no clue about FPGA, and at one time, neither did you.

When I had no clue about FPGAs, I had the sense not to go spouting
off about it.

> That's why she's your ex-wife.  Your judging of activities by OTHER people
> as complete wastes of time is stupid.

Stupid? That sounds pretty judgemental.  Pot, kettle, black.
I reserve the right to make any judgements I want.  I stick by them.
She was a kook.  She did hard time in the nut house to prove it.
I thank my lucky stars that she's my ex wife.

> I don't mind if you don't have any
> intention to do what I'm doing, but I don't see why you mind that I do it.

I don't mind.  But I have an opinion.  Is this a problem?

> Your ex-wife may have an idea there, working as a janitor.
I don't think she'd agree with that.

> "take a pill and get over it."  I was recently making fun of the uncoived
> opinion of the unwashed masses that aesthetic sense should be dealt with
> so trivially.

I'll stack my aesthetic sense against yours any day.  Let's do lunch.

> >your 13 Gigabyte disk is running out of space, you can probably
> >afford to delete your Captain Kirk .gif files.  Use the software.
> 
> I don't know what the fuck that's all about, I assume you're just
> comparing me too much to your ex-wife, since none of that has any
> basis in any reasonable argument.

Yes you do.  It's an ad-hominem attack for the purpose of pointing out
how silly your disk-space worries are.  That you chose to respond in
kind *without* apparent purpose allows me you use the "pot,kettle,black"
rule again.

> >Find out what it can and cannot do.  Get back to us in a couple of
> >weeks and maybe we can have an intelligent discussion about FPGAs.
> 
> No we can't because I bet pennies to dollars (you're the high-paid
> professional) that you don't know shit about what really goes on inside
> that software because all you're concerned about is the fact that it
> works.

I'll stack my knowledge of the FPGA and the software internals against
yours any day.  You'll lose your pennies, but you might learn something.
Let's do lunch.




--
Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab                          Phone: 630-840-3668
Batavia, IL 60510                                         Fax: 630-840-5406
Article: 21551
Subject: Re: FPGA openness
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Fri, 24 Mar 2000 12:49:39 -0500
Links: << >>  << T >>  << A >>


eml@riverside-machines.com.NOSPAM wrote:

> On 23 Mar 2000 23:03:28 GMT, gah@ugcs.caltech.edu (glen
> herrmannsfeldt) wrote:
>
> >I remember building things like digital clocks out of TTL.  A great
> >way to learn about digital logic.  How are our kids going to learn this?
> >
> >They will have to learn starting with FPGA's.  Probably small ones, though.
> >An FPGA starter kit equivalent to a bag full of 74xx chips would not
> >be a bad way to learn digital logic design.  I was part of a discussion
> >at FCCM95 on just this subject.
> >
> >-- glen
>
> I think it's very hard to learn digital design with FPGAs - much
> better to have a big PCB, a scope, lots of TTL, a hairdryer and a
> freezer can. You really need to get in and physically see the signals
> to understand what's going on.
>
> I've been doing some interviewing recently, for VHDL people. All were
> electronic engineers, and also claimed to know and use VHDL. Out of
> about 10 or 12 people:
>
> (1) about half couldn't draw up a gate-level 2->1 multiplexer
> (2) most didn't know what a JK was
> (3) almost nobody could design a gate-level counter, or
> (4) knew how to create an FSM from scratch, with pencil and paper
> (5) very few knew anything about line termination
> and so on.
>

Evan,
    Where are you hiring?
1.    I can draw a gate level 2:1 MUX
2.    I do know what a JK is and how to use it.
       ( I would have to look up how to build one from gates.)
3.    Gate level counter... Once I got a gated D flip-flop then I could do it.
(Or anything higher level.)  But why would you want to for most real world
applications?  (posible exceptions high speed or low noise..  Or special count
sequence.  Then see FSM.)
4.    FSM... No problem.
5.    Line termination.. No problem here.  Series, Thevenin, or whatever.
6.    How about line impedances of a PCB trace?
7.    How about ground planes?

Now to be fair...
1.    What are you paying?
2.    How about job security?
3.    How about unpaid overtime?
4.    How about fringes?

Please do not misunderstand me but, do you see my point?  Perhaps you cannot
draw the best candidates because your company is not the best employer?   I
really don't know so please do not be offended.  I just know that some companies
and some engineers deserve each other.  When the two match up its great.
Unfortunately that does not always happen.

>
> But then, if you just use FPGAs with an HDL, or even with schematics
> to some extent, how are you ever going to learn these things?
>
> Evan

Article: 21552
Subject: Re: FPGA openness
From: Jason.Wright@ericsson. (Jason T. Wright)
Date: Fri, 24 Mar 2000 17:57:45 GMT
Links: << >>  << T >>  << A >>
On Fri, 24 Mar 2000 12:23:22 -0500, Theron Hicks <hicksthe@egr.msu.edu>
wrote:

>[snip]
>  The only serious problem I had with my first design was in
>getting the bitstream to properly activate the FPGA from a serial EEPROM.
>(master serial mode.  They claim that slave serial is the most popular.  Not for
>a single FPGA system....  A little more frustrating, for my master serial system
>I needed to have done activate at clock 4 not clock 1.  The software has that
>option but it was buried a little deep and I didn't know that I needed to be
>concerned about it.
>
I've always used master serial for the first device in a chain.  But, I've
usually also included the option to do "slave serial" to use the download
cable.  (My current design uses in-circuit programmable EEPROMs, so "master
serial" is the only mode used.)


Jason T. Wright
Cygnion Corp
Article: 21553
Subject: Re: FPGA openness
From: Jason.Wright@ericsson. (Jason T. Wright)
Date: Fri, 24 Mar 2000 17:58:31 GMT
Links: << >>  << T >>  << A >>
On Fri, 24 Mar 2000 12:23:22 -0500, Theron Hicks <hicksthe@egr.msu.edu>
wrote:

>[snip]
>  The only serious problem I had with my first design was in
>getting the bitstream to properly activate the FPGA from a serial EEPROM.
>(master serial mode.  They claim that slave serial is the most popular.  Not for
>a single FPGA system....  A little more frustrating, for my master serial system
>I needed to have done activate at clock 4 not clock 1.  The software has that
>option but it was buried a little deep and I didn't know that I needed to be
>concerned about it.
>
I've always used master serial for the first device in a chain.  But, I've
usually also included the option to do "slave serial" to use the download
cable.  (My current design uses in-circuit programmable EEPROMs, so "master
serial" is the only mode used.)

Jason T. Wright
Cygnion Corporation
Jason T. Wright
Cygnion Corp
Article: 21554
Subject: Re: 4000XLA bitgen problem?
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Fri, 24 Mar 2000 10:33:50 -0800
Links: << >>  << T >>  << A >>
Due to the absence of any useful replies, let me rephrase the question:
For medium density designs (~50% CLB utilization), is it unusual to see
bitgen -t -u reporting untied nodes as seen in the console output and the
.bgn report in the lowest level (verx/revx) design directory?

I note that the flow now defaults to continuing as if nothing untoward was
happening, whereas it used to be regarded as something of a sin to leave
floating nodes in a production CMOS design. 

regards, tom

Tom Burgess wrote:
> 
> Just wondered if anyone else has seen the same problem
> - namely that when I run bitgen with tie enabled it seems to bog
> down toward the end tying down single nodes. When it finally completes, the
> bitgen report says that some nodes are still untied - I've seen as many as
> 1023 untied nodes on a 70% utilized 4013XLA. I don't remember
> makebits being this bad with 90% utilized plain old 4000 parts. The -u option
> makes no difference, since no nets are flagged critical. I'm running
> Fndtn 2.1i SP5 (128M RAM). The support database and hotline were not particularly
> helpful on this issue.
> 
> Is the untied nodes number bogus, and if not, should I be concerned?
> 

Tom Burgess
-- 
Digital Engineer
Dominion Radio Astrophysical Observatory
P.O. Box 248, Penticton, B.C.
Canada V2A 6K3
Email:        tom.burgess@hia.nrc.ca
Article: 21555
Subject: Re: FPGA openness
From: "Gary Watson" <gary@nexsan.sex>
Date: Fri, 24 Mar 2000 18:37:00 -0000
Links: << >>  << T >>  << A >>
Ray Andraka <randraka@ids.net> wrote in message
news:38DB7BC3.889F0994@ids.net...
> Not at all.  It's just that I think it makes more sense to first work with
> what is out there before condemning it.  By working with the existing
tools
> for a while, you'll get a) a real good feel for the FPGA architecture,
what
> works, what's fast and whats not, b) an understanding of what the
strengths
> and weaknesses of the current tools are, and c) some focus for your
> improvement efforts.

I think an analogy would be if Microsoft and Intel introduce a new PC which
is pretty attractive, but all the opcodes are secret and the only supplied
programming language is Visual Basic.  No opportunity to write assembly, or
c, or lisp, or anything else.  Microsoft would argue that you can do
virtually any legitimate task under Visual Basic, and that ought to be good
enough for you.  If you don't like it, buy somebody else's PC.  Microsoft
and Intel might argue that this is the only way that they can guarantee a
crash-free environment.  I suspect that most people would simply shrug their
shoulders, buy a copy of MS Office, and get on with using the system,
particularly if the crash-free promise turned out to be mostly true.  What
Greg is proposing is breaking the seals on the PC,  reverse engineering the
machine language, working out a little assembler, maybe writing a c
compiler, etc etc until he's got it running Linux.  Depending upon the
eventual goal, it isn't an unrealistic idea.  A number of people have
completely reverse-engineered games consoles and wrote PC simulators for
them.  Is it wrong to learn how to be a computer scientist by starting with
6502 machine language and then working up?  Must people start at Visual C++
and work their way down?   Philosophically, I think issuing the bits to a
Xilinx is an excellent way to get a detailed understanding of how the CLBs
work.

Now to throw cold water on what I just said:  There's no way in hell that
Xilinx wants Greg or anybody else making their tools unnecessary.  As they
told me back in 1988, Xilinx is first and foremost a software company.  They
want to license you their intellectual property in bite-size, 12 month,
chunks.  Their corporate strategy implies that it would be suicidal to help
people circumvent their profitable tools.

What I think Greg wants is a FPGA equivalent of PIC.  They virtually give
away the development tools so that you will use their (sucky)
microprocessors.  Works for them, apparently.  It's just another way of
doing business.

What I don't understand is why Xilinx doesn't publish the bitstream format
for the low-end parts, which only require the $100 software package (which I
have recently discovered is often given away to prospective customers).  It
doesn't seem that they stand to lose much revenue.  What would be even more
amusing is if Altera published the Xilinx bitstream (which no doubt they
reverse-engineered long ago), and in retaliation, Xilinx published the
Altera bitstream....


--

Gary Watson
gary@nexsan.sex  (Change dot sex to dot com to reply!!!)
Nexsan Technologies Ltd.
Derby DE21 7BF  ENGLAND
http://www.nexsan.com





Article: 21556
Subject: Re: FPGA openness
From: eml@riverside-machines.com.NOSPAM
Date: Fri, 24 Mar 2000 18:55:46 GMT
Links: << >>  << T >>  << A >>
On Fri, 24 Mar 2000 12:49:39 -0500, Theron Hicks
<hicksthe@egr.msu.edu> wrote:

>Now to be fair...
>1.    What are you paying?
>2.    How about job security?
>3.    How about unpaid overtime?
>4.    How about fringes?
>
>Please do not misunderstand me but, do you see my point?  Perhaps you cannot
>draw the best candidates because your company is not the best employer?   I
>really don't know so please do not be offended.  I just know that some companies
>and some engineers deserve each other.  When the two match up its great.
>Unfortunately that does not always happen.

It's not my company - they're just currently paying my bills. They're
good employers, cubicles notwithstanding, pay well, they're
leading-edge (3G wireless), and they've got an IPO on the way. The
problem is simply that it's very difficult to find *any* engineers in
the UK at the moment. If anyone wants to relocate to Cambridge mail
me, and I'll give you details. They've got positions in FPGA/ASIC,
DSP, and algorithm development.

Evan
 
Article: 21557
Subject: Re: FPGA openness
From: husby@fnal.gov (Don Husby)
Date: Fri, 24 Mar 2000 19:14:03 GMT
Links: << >>  << T >>  << A >>
"Gary Watson" <gary@nexsan.sex> wrote:
> What would be even more
> amusing is if Altera published the Xilinx bitstream (which no doubt they
> reverse-engineered long ago),

I'm curious to know why you think Altera would spend the effort do decode
Xilinx's bitstream format.  What could they possibly do with it?
The data sheets pretty-much tell you what the internal architecture does.
They know that somewhere in the bit stream, there's a bit that controls
switch X, why would they care which particular bit it is?



--
Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab                          Phone: 630-840-3668
Batavia, IL 60510                                         Fax: 630-840-5406
Article: 21558
Subject: Re: FPGA openness
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 24 Mar 2000 12:02:01 -0800
Links: << >>  << T >>  << A >>

--------------8AB2FDE5D90CEDA832C4B37C
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit



Gary Watson wrote:

> Now to throw cold water on what I just said:  There's no way in hell that
> Xilinx wants Greg or anybody else making their tools unnecessary.  As they
> told me back in 1988, Xilinx is first and foremost a software company.

No way!  We make 95% of our revenue from chips. We say that we are a "solutions
company" offering tools, cores, chips, and support. But our revenue comes from
chip sales.

> They
> want to license you their intellectual property in bite-size, 12 month,
> chunks.  Their corporate strategy implies that it would be suicidal to help
> people circumvent their profitable tools.

Wrong again! The tools are hardly profitable, and need not be profitable. They
are expensive in R&D, and they are vital to our chip sales. But they are not a
major stream of revenue.

> What I don't understand is why Xilinx doesn't publish the bitstream format
> for the low-end parts, which only require the $100 software package (which I
> have recently discovered is often given away to prospective customers).  It
> doesn't seem that they stand to lose much revenue.  What would be even more
> amusing is if Altera published the Xilinx bitstream (which no doubt they
> reverse-engineered long ago), and in retaliation, Xilinx published the
> Altera bitstream....

Everything we give out, we have to support. We are, therefore, reluctant to
give out "unnecessary" details: NOT to keep them secret from Altera, NOT to
make more money on the software sale, but fundamentally to limit our support
cost.

If a designers hangs himself in the gory details of the architecture, routing,
and the bitstream generation, we cannot say: "Sorry, Charly, your fault". Since
he is our customer, with perhaps substantial hardware purchases, we would have
to bail him out. We would have not only a moral, but also a financial incentive
to do that.

This kind of support could become a nightmare. It's complicated enough, the way
it is.
We do have a feel for how much time and effort our customers invest in their
designs that, ultimately, get implemented in our parts. And we even understand
how much depends on the proper and trouble-free operation of our chips, often
completely out of proportion to the chip price.
Therefore, we have to, and we want to, provide good support.

Just my opinion
Peter Alfke


--------------8AB2FDE5D90CEDA832C4B37C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<p>Gary Watson wrote:
<blockquote TYPE=CITE>Now to throw cold water on what I just said:&nbsp;
There's no way in hell that
<br>Xilinx wants Greg or anybody else making their tools unnecessary.&nbsp;
As they
<br>told me back in 1988, Xilinx is first and foremost a software company.</blockquote>
No way!&nbsp; We make 95% of our revenue from chips. We say that we are
a "solutions company" offering tools, cores, chips, and support. But our
revenue comes from chip sales.
<blockquote TYPE=CITE>They
<br>want to license you their intellectual property in bite-size, 12 month,
<br>chunks.&nbsp; Their corporate strategy implies that it would be suicidal
to help
<br>people circumvent their profitable tools.</blockquote>
Wrong again! The tools are hardly profitable, and need not be profitable.
They are expensive in R&amp;D, and they are vital to our chip sales. But
they are not a major stream of revenue.
<blockquote TYPE=CITE>What I don't understand is why Xilinx doesn't publish
the bitstream format
<br>for the low-end parts, which only require the $100 software package
(which I
<br>have recently discovered is often given away to prospective customers).&nbsp;
It
<br>doesn't seem that they stand to lose much revenue.&nbsp; What would
be even more
<br>amusing is if Altera published the Xilinx bitstream (which no doubt
they
<br>reverse-engineered long ago), and in retaliation, Xilinx published
the
<br>Altera bitstream....</blockquote>
<b>Everything we give out, we have to support. </b>We are, therefore, reluctant
to give out "unnecessary" details: NOT to keep them secret from Altera,
NOT to make more money on the software sale, but fundamentally to limit
our support cost.
<p>If a designers hangs himself in the gory details of the architecture,
routing, and the bitstream generation, we cannot say: "Sorry, Charly, your
fault". Since he is our customer, with perhaps substantial hardware purchases,
we would have to bail him out. We would have not only a moral, but also
a financial incentive to do that.
<p>This kind of support could become a nightmare. It's complicated enough,
the way it is.
<br>We do have a feel for how much time and effort our customers invest
in their designs that, ultimately, get implemented in our parts. And we
even understand how much depends on the proper and trouble-free operation
of our chips, often completely out of proportion to the chip price.
<br>Therefore, we have to, and we want to, provide good support.
<p>Just my opinion
<br>Peter Alfke
<br>&nbsp;</html>

--------------8AB2FDE5D90CEDA832C4B37C--

Article: 21559
Subject: Re: No- FPGA openness
From: muzo <muzok@nospam.pacbell.net>
Date: 24 Mar 2000 15:09:13 EST
Links: << >>  << T >>  << A >>
Catalin Baetoniu <starnet@home.com> wrote:
>FPGA Hardware design is _hard_ and the
>software tools quality is not the main problem. When the program you are
>developing does not work the way you expect it you use a debugger,
>set-up breakpoints, step trough your code and whatever else you software
>people do when you hunt bugs. Normally you cannot stop an FPGA and you
>cannot look inside it to see what went wrong.

I'd say this is a problem related to software tools quality. Is there
any reason why anyone can't design a built in test tool to capture the
running state of an FPGA, set triggers for start and stop of the
capture, even stop execution etc.? What makes you thing that any
software which controls realtime events can be stopped more easily
than an FPGA? One can design great debugging tools for FPGAs and very
recently FPGA vendors are waking up to this too.

> Another major difference
>is that software is usually sequential while inside the FPGA everything
>happens in parallel. 

There are systems with multiple processors controlling realtime
events. Things happen in parallel there too.
What I am trying to say is that there is not much difference between
debugging sopthisticad systems, whethere they are hardware or software
systems.


Article: 21560
Subject: Re: FPGA openness
From: muzo <muzok@nospam.pacbell.net>
Date: 24 Mar 2000 15:33:09 EST
Links: << >>  << T >>  << A >>
Theron Hicks <hicksthe@egr.msu.edu> wrote:
>> I've been doing some interviewing recently, for VHDL people. All were
>> electronic engineers, and also claimed to know and use VHDL. Out of
>> about 10 or 12 people:
>>
>> (1) about half couldn't draw up a gate-level 2->1 multiplexer
>> (2) most didn't know what a JK was
>> (3) almost nobody could design a gate-level counter, or
>> (4) knew how to create an FSM from scratch, with pencil and paper
>> (5) very few knew anything about line termination
>> and so on.

this reminds me the dilbert cartoon where a couple of bearded, bald
guys talk about having to code only with ones and zeros and dilbert
tops them off with "then you are lucky, we didn't even have ones. We
had to write code only with zeros". Most people these days are not
designing with ones and zeros. With million gate SoC designs, you
can't fill a chip by desiging at the level of 2x1 muxes or JK
flip-flops. You have to use HDLs and behavioral compilers etc.
Article: 21561
Subject: Chip-to-Chip benchmarks?
From: husby@fnal.gov (Don Husby)
Date: Fri, 24 Mar 2000 20:59:38 GMT
Links: << >>  << T >>  << A >>

Anyone have an example of driving a 32- or 64-bit wide bus
between 2 FPGAs at 100MHz or better?  



--
Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab                          Phone: 630-840-3668
Batavia, IL 60510                                         Fax: 630-840-5406
Article: 21562
Subject: Re: FPGA openness
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 24 Mar 2000 17:44:01 -0500
Links: << >>  << T >>  << A >>
I can't believe the hostility I am seeing here. This guy (Greg, not
George) is just saying that he wants to get enough information from
Xilinx so that he can develope his own basic, crude, but effective tools
to design FPGAs in the way he wants and without being dependant on
anyone who won't share the source for the software. That's it, end of
request. 

As a result, dozens of people (including myself initially) try to talk
him out of this "silly" idea and tell him he should conform to doing
FPGA design the way that we do it. Some of us even go so far as to adopt
hostile tones and make posts asking others to ignore this person and his
request. 

If that is not intolerance, then I don't know what is. Don seems to have
a lot of issues because this guy reminds him of his ex-wife and her
eccentric behavior. Fine, but you divorced the ex-wife because you
didn't want to deal with her anymore, I assume. Why not just ignore Greg
and consider you two to be divorced? 

Nicholas goes so far as to call Gred "a flamer and a troll". I don't see
any of this. I see a person who has very specific ideas of what he wants
to do and is asking for help or support in doing them. Perhaps he is a
little harsh in his criticism of Xilinx and the users who tolerate the
supposed offences by them. But he is far from inflammatory in my
opinion. In fact this whole thread is opening my eyes to see how
defensive and narrow minded we seem to be as a group. 

I have been a reader of a mailing list of Forth users which includes a
few people who have worked with Charles Moore on Forth chips. I don't
know that any of these chips will become mainstream commercial sucesses,
but they are very interesting from an academic sense and show what can
be done by a single person or a small team starting from nothing an
attacking a huge problem from scratch. As someone posted in an earlier
message, they succeeded in producing several chips while relying on
almost no tools from the outside. That is saying a lot!

So why do you (in the plural sense) need to feel so hostile toward
someone who wants to walk a different path and persue different goals
than your own? How about if we "all just learn to get along?"


BTW, on the suggestion of some others that bitgen is the only part of
the tools that contain the "secret" bitstream information. If that was
all there was to hiding the info, then it would be a weekend task to
reverse-engineer bitgen and role your own. It would be especially easy
to test since you can run both your own and the Xilinx one side by side
on a number of test cases. 

But I would be willing to bet that much of the details of the file
format that goes into bitgen are not explained anywhere. So even if you
figure out bitgen, you still have to figure out what all the control
points are and what they do. 


Don Husby wrote:
> 
> galexand@sietch.bloomington.in.us (Greg Alexander) wrote:
> > In article <8bg2qr$cqp$1@info3.fnal.gov>, Don Husby wrote:
> 
> > >galexand@sietch.bloomington.in.us (Greg Alexander) wrote:
> > Getting rid of the bugs is small compared to the peace of mind of
> > understanding the software.
> 
> Right, I got it from your first few posts.  This is a spiritual thing
> for you.  Nothing is stopping you from understanding.  I'm just saying
> you'd get a little more credibilty on that point if you took the time
> to do some of that unsderstanding before shooting your mouth off.
> And, like the religous fanatics, if you feel you have to flog yourself
> in order to unsderstand it, be my guest.
> (I'll leave a break here for you to point out how intolerant I am.  It's
> my spiriual quest to make fun of people who flog themselves.  I hope
> you have no problem with that.)
> 
> > >Well, it's a nice dream, Greg, and maybe it's sometimes true for real
> > >artists and geniuses, but it's clear from your posts that you barely
> > >have a clue.  That you haven't even seen the commercial tools that you
> > >fear so much.  That you haven't ever done an FPGA design.
> >
> > I have no clue about FPGA, and at one time, neither did you.
> 
> When I had no clue about FPGAs, I had the sense not to go spouting
> off about it.
> 
> > That's why she's your ex-wife.  Your judging of activities by OTHER people
> > as complete wastes of time is stupid.
> 
> Stupid? That sounds pretty judgemental.  Pot, kettle, black.
> I reserve the right to make any judgements I want.  I stick by them.
> She was a kook.  She did hard time in the nut house to prove it.
> I thank my lucky stars that she's my ex wife.
> 
> > I don't mind if you don't have any
> > intention to do what I'm doing, but I don't see why you mind that I do it.
> 
> I don't mind.  But I have an opinion.  Is this a problem?
> 
> > Your ex-wife may have an idea there, working as a janitor.
> I don't think she'd agree with that.
> 
> > "take a pill and get over it."  I was recently making fun of the uncoived
> > opinion of the unwashed masses that aesthetic sense should be dealt with
> > so trivially.
> 
> I'll stack my aesthetic sense against yours any day.  Let's do lunch.
> 
> > >your 13 Gigabyte disk is running out of space, you can probably
> > >afford to delete your Captain Kirk .gif files.  Use the software.
> >
> > I don't know what the fuck that's all about, I assume you're just
> > comparing me too much to your ex-wife, since none of that has any
> > basis in any reasonable argument.
> 
> Yes you do.  It's an ad-hominem attack for the purpose of pointing out
> how silly your disk-space worries are.  That you chose to respond in
> kind *without* apparent purpose allows me you use the "pot,kettle,black"
> rule again.
> 
> > >Find out what it can and cannot do.  Get back to us in a couple of
> > >weeks and maybe we can have an intelligent discussion about FPGAs.
> >
> > No we can't because I bet pennies to dollars (you're the high-paid
> > professional) that you don't know shit about what really goes on inside
> > that software because all you're concerned about is the fact that it
> > works.
> 
> I'll stack my knowledge of the FPGA and the software internals against
> yours any day.  You'll lose your pennies, but you might learn something.
> Let's do lunch.
> 
> --
> Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
> Fermi National Accelerator Lab                          Phone: 630-840-3668
> Batavia, IL 60510                                         Fax: 630-840-5406


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 21563
Subject: Re: FPGA openness
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 24 Mar 2000 17:51:48 -0500
Links: << >>  << T >>  << A >>
> I had a similar discussion with Xilinx back in 1988 or thereabouts, when
> they wanted me to pay $5000 for a piece of software so I could see if the
> Xilinx parts would be suitable for my application.  I said to the Xilinx guy
> that they should give me the software for free like MMI did with Palasm, and
> if it worked they would make their money by selling me chips (after all, the
> tools only work with Xilinx chips).  The Xilinx salesman explained that
> Xilinx is a *software* company, not a chip company.  They only make chips so
> they can sell their development tools.
> 
> I decided that I would ignore Xilinx for ten years, and revisit the issue.
> Twelve years on, I've decided to give them another chance, and so I'm
> looking at the Xilinx parts again.  I'm sure they don't realize that they
> lost out on selling millions of Xilinx parts to go into my designs because
> they wouldn't give me their tools.    I've been making do with PALs all
> these years...
> 
> [As a side note, the issue in 1988 was whether you could really fit my
> intended design into their parts.  I had an existing design, drawn by hand
> onto a bunch of C size sheets of vellum.  The Xilinx guy was unwilling to
> refund my $5000 if the design didn't fit into the target part, even though a
> rough gate count made us think it should fit easily.  He offered us a 30 day
> eval, but we judged that this would not be long enough.]
> 
> --
> 
> Gary Watson
> gary@nexsan.sex  (Change dot sex to dot com to reply!!!)
> Nexsan Technologies Ltd.
> Derby DE21 7BF  ENGLAND
> http://www.nexsan.com

I have the same problem with paying for the software. But you should try
to distinguish between a lousy salesman and a lousy company. I don't
think Xilinx has ever considered themselves to be a software company.
They charge for the tools just because they need to balance the revenue
against the costs of providing each the hardware and the software. The
software costs are so large that if they just absorbed that cost into
the hardware revenue stream, they would have to charge enough more for
the chips that they would lose some of the high volume sales and their
competition would gain. So instead they will give away tools if a
customer is likely to be a high volume user of parts. This is why I
think you got a lousy salesman. He should have reconized the potential
gain and gotten you a free copy. 

The only companies that don't charge for their tools are the ones that
can't compete directly on an equal footing. They get their sales by
being novel in some way, like Atmel. They have a hard time competing
with Xilinx or Altera if you just look at the parts. There are a few
niche applications which they do well, but for the most part if they did
not give away their tools, they would not get many customers. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 21564
Subject: Re: FPGA openness
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 24 Mar 2000 18:12:28 -0500
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Everything we give out, we have to support. We are, therefore,
> reluctant to give out "unnecessary" details: NOT to keep them secret
> from Altera, NOT to make more money on the software sale, but
> fundamentally to limit our support cost.
> 
> If a designers hangs himself in the gory details of the architecture,
> routing, and the bitstream generation, we cannot say: "Sorry, Charly,
> your fault". Since he is our customer, with perhaps substantial
> hardware purchases, we would have to bail him out. We would have not
> only a moral, but also a financial incentive to do that.
> 
> This kind of support could become a nightmare. It's complicated
> enough, the way it is.
> We do have a feel for how much time and effort our customers invest in
> their designs that, ultimately, get implemented in our parts. And we
> even understand how much depends on the proper and trouble-free
> operation of our chips, often completely out of proportion to the chip
> price.
> Therefore, we have to, and we want to, provide good support.
> 
> Just my opinion
> Peter Alfke
> 

Peter, I want to understand this line of reasoning since I really don't
see the rational behind keeping the bitstream secret. Are you saying
that if Xilinx gave out the bitstream format and a customer of the chips
bought a third party toolset or rolled his own tools that Xilinx would
offer some form of support for issues related to loading the chips from
these tools? I can't see the basis for that. 

Some others have posted analogies to microprocessors and the binary
instruction formats. I don't think that Intel or anyone else feels the
need to support any third party code generators in any way. If the chip
executes the instructions the way it is documented, then they are done.
Likewise, if a given bitsteam generated from third party tools does not
work in a Xilinx part, why would anyone expect Xilinx to even take a
look at the generated bitstream? 

As I see it, that is the main reason that a user buys a Xilinx toolset.
You get support directly from the source. I looked at buying Neocad
software years ago and one of the many reasons that I didn't was because
they were "third party" and would never be able to supply a complete
support package. They never made any indication that Xilinx would
support their products in any way. In fact they said that Xilinx
initially was very uncooperative in providing any info on the bitstream
or chip designs. But they worked around that and Xilinx ultimately
decided that it was in their own interests to provide information to
Neocad, very much like what Greg is asking for. Information without
obligation for support. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 21565
Subject: Re: Altering Xilinx FPGA version/ID after PAR
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 24 Mar 2000 18:53:32 -0500
Links: << >>  << T >>  << A >>
Jamie Sanderson wrote:
> 
> Greetings;
> 
> There are a few things I'd like to do with Xilinx FPGA's (xc4000 or xcv/e).
> However, I think they could both be implemented in similar ways.
> 
> First of all, I'd like to have a version/revision value within the FPGA
> which would automatically track the one used in the Design Manager.
> 
> The second thing I want is to generate multiple bit files from a single one,
> each of those files containing a unique identifier.
> 
> JBits seems like a potential candidate, but it's not particularly available.
> Another possibility is the FPGA editor, but I don't believe you can run it
> non-interactively.
> 
> Any ideas? For the first case, what I'd envision would be a black box which
> could be instantiated into your code. It would have version and revision
> outputs which match what is given in Design Manager. I wouldn't expect it to
> simulate properly, but that's a minor issue. In the second case, the same
> black box could be manipulated by an executable which you run on your bit
> file, and which you provide the identifiers you require.
> 
> Thanks for reading this!
> 
> Cheers,
> Jamie

Jamie, I would have loved to have had such a capability in my FPGA.
Instead I settled for putting the bitfile into the flash PROM including
the header with the date and file name information. This does a lot to
achieve the goal of being able to distinguish FPGA versions. 

As to the unique identifier, otherwise known as a serial number (SN), I
figured this was just too tricky to bother with and added a Dallas one
wire part to the board. They make many different types of parts which
will actually communicate over a single wire (plus ground) by using an
open collector IO with pulse width distinguishing a 1 from a 0. We
implemented the one wire protocol in our DSP and the DS2430 gives us a
48 bit unique SN, 64 bits of PROM and 256 bits of EEPROM. We use the
PROM to store board revision info and the EEPROM to store configuration
details like default baud rate and load options. 

Just a thought...


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 21566
Subject: Clock on non-dedicate pin
From: spyng@my-deja.com
Date: Sat, 25 Mar 2000 04:28:03 GMT
Links: << >>  << T >>  << A >>
hi,

  other than GCK0-3, is there anyway to have a clock signal without
using dedicate Pin?

  I need to input two external clock to my FPGA board, but unfortunately
 the board is design such that only one external clock is possible.
  So, i am trying to inject the second external clock to a I/O, but the
design refuse to map.

  skew of the second clock is not important to me, I just want a clock
in a normal I/O pin!

  thanks
spyng


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 21567
Subject: Re: FPGA openness
From: Ray Andraka <randraka@ids.net>
Date: Sat, 25 Mar 2000 04:37:12 GMT
Links: << >>  << T >>  << A >>


muzo wrote:

> ...
> designing with ones and zeros. With million gate SoC designs, you
> can't fill a chip by desiging at the level of 2x1 muxes or JK
> flip-flops. You have to use HDLs and behavioral compilers etc.

Not so!  I think it is much more important to make heavy use of hierarchy so
that you can reuse design pieces.  Even where I am using HDLs, I'm still
doing alot of low level design (down at the primitives level).  And yes, I
am doing million gate designs.  I'm just finishing one now that reports
999,376 equivalent gates at the tools output in the fuller chip of the two
chip design - it runs at 134MHz in a 70 % full Virtex1000 -4.  Guess what?
A good deal of the design was done at the primitive level complete with
floorplanning in the VHDL source.  How long did it take?  about 600 hours
including design verification. About 20% of that time was algorithm
development in Matlab.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21568
Subject: Re: Chip-to-Chip benchmarks?
From: stefanludwig@my-deja.com
Date: Sat, 25 Mar 2000 05:52:53 GMT
Links: << >>  << T >>  << A >>
Hi Don,
check out Xilinx's application note 234, SelectLink.
http://www.xilinx.com/applications/slcv/selectlink.htm
It's up to 256 bits wide, up to 311 MHz per pin. Quite a lot of
bandwidth.
It's also only for Virtex and Virtex-E devices.
Stefan
In article <8bgkvp$iu3$1@info3.fnal.gov>,
husby@fnal.gov (Don Husby) wrote:
>
> Anyone have an example of driving a 32- or 64-bit wide bus
> between 2 FPGAs at 100MHz or better?
>
> --
> Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby
> Fermi National Accelerator Lab Phone: 630-840-3668
> Batavia, IL 60510 Fax: 630-840-5406


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 21569
Subject: Re: FPGA openness
From: eml@riverside-machines.com.NOSPAM
Date: Sat, 25 Mar 2000 10:09:25 GMT
Links: << >>  << T >>  << A >>
On 24 Mar 2000 15:33:09 EST, muzo <muzok@nospam.pacbell.net> wrote:

>Theron Hicks <hicksthe@egr.msu.edu> wrote:
>>> I've been doing some interviewing recently, for VHDL people. All were
>>> electronic engineers, and also claimed to know and use VHDL. Out of
>>> about 10 or 12 people:
>>>
>>> (1) about half couldn't draw up a gate-level 2->1 multiplexer
>>> (2) most didn't know what a JK was
>>> (3) almost nobody could design a gate-level counter, or
>>> (4) knew how to create an FSM from scratch, with pencil and paper
>>> (5) very few knew anything about line termination
>>> and so on.
>
>this reminds me the dilbert cartoon where a couple of bearded, bald
>guys talk about having to code only with ones and zeros and dilbert
>tops them off with "then you are lucky, we didn't even have ones. We
>had to write code only with zeros". Most people these days are not
>designing with ones and zeros. With million gate SoC designs, you
>can't fill a chip by desiging at the level of 2x1 muxes or JK
>flip-flops. You have to use HDLs and behavioral compilers etc.

I can't agree. I use HDLs all the time, to fill "million gate"
devices. HDLs and behavioural compilers are just tools. You can
have the best chisel in the world, but it's not going to turn you into
Michelangelo.

Evan

Article: 21570
Subject: Re: Altering Xilinx FPGA version/ID after PAR
From: eml@riverside-machines.com.NOSPAM
Date: Sat, 25 Mar 2000 10:10:32 GMT
Links: << >>  << T >>  << A >>
On Fri, 24 Mar 2000 10:29:18 -0500, "Jamie Sanderson"
<jamie@nortelnetworks.com> wrote:

>Greetings;
>
>There are a few things I'd like to do with Xilinx FPGA's (xc4000 or xcv/e).
>However, I think they could both be implemented in similar ways.
>
>First of all, I'd like to have a version/revision value within the FPGA
>which would automatically track the one used in the Design Manager.
>
>The second thing I want is to generate multiple bit files from a single one,
>each of those files containing a unique identifier.
>
>JBits seems like a potential candidate, but it's not particularly available.
>Another possibility is the FPGA editor, but I don't believe you can run it
>non-interactively.
>
>Any ideas? For the first case, what I'd envision would be a black box which
>could be instantiated into your code. It would have version and revision
>outputs which match what is given in Design Manager. I wouldn't expect it to
>simulate properly, but that's a minor issue. In the second case, the same
>black box could be manipulated by an executable which you run on your bit
>file, and which you provide the identifiers you require.
>
>Thanks for reading this!
>
>Cheers,
>Jamie

I'd like to do this as well, so it would be interesting to hear how
you get on. I can't see that you'll get the GUI version/revision info
though, since this is just private to the GUI. Why don't you just
maintain a revision register in your device? Your problem then is just
identifying this register, or the serial number register, in the
bitfile.

I haven't looked at Jbits but, if it doesn't do the job, this
procedure might work. Have a 16-bit revision number implemented as a
CLB ROM element, and locate this ROM at a known CLB location. Generate
an 'll' file from Bitgen ('-l' option). Search the ll file for lines
containing your known CLB location (the ll format is documented in the
file). This will give you the bit number, frame number, and frame
offset for all 16 bits in your ID. The trick now is to identify these
bits in your bitfile; see xapps 138 and/or 151.

As an aside, this is what I do to get around the Xilinx GUI
revision/version structure. My rebuild makefile always builds in a
fixed directory (xproj/current in my setup), and you rely on a source
control system to retrieve the important files (only) from previous
builds. You then don't need multiple directories to keep a huge amount
of redundant information.

Evan

Article: 21571
Subject: Re: FPGA & single point failure
From: Tom Burgess <tom.burgess@home.com>
Date: Sat, 25 Mar 2000 10:23:43 GMT
Links: << >>  << T >>  << A >>
Seeing the lack of responses, I can guess that many were mystified by your
use of the unfamiliar terms "clue point" and "redound". The context is
not sufficient to make them clear, to me at least. What's disconcerting
is that the rest of the message appears to be mostly coherent English.

regards, tom

EDM wrote:
> 
> I've got a problem with a space mission payload system.  I want to use a
> FPGA as a clue point of a payload electronic unit. Can anybody clarify me
> how do I manage the concept of "single point failure tolerant" in the
> system, If I cannot redound the board where this FPGA is included. Do I
> redound the FPGA itself inside the board? Is it possible? And is it normally
> foreseen? Or is there anything else that I have to take into account? Or
> other good solutions that you can suggest me?
> 
> Thanks for any advice and suggestion you can give me
> 
> --
> 
> edemarchi@hotmail.com
Article: 21572
Subject: Re: Clock on non-dedicate pin
From: Jaroslaw Kubica <jkubica@sigma.krakow.pl>
Date: Sat, 25 Mar 2000 11:15:11 GMT
Links: << >>  << T >>  << A >>
What is the type of your FPGA device and what tools do you use?
Regards,
Jarek

spyng@my-deja.com wrote:

> hi,
>
>   other than GCK0-3, is there anyway to have a clock signal without
> using dedicate Pin?
>
>   I need to input two external clock to my FPGA board, but unfortunately
>  the board is design such that only one external clock is possible.
>   So, i am trying to inject the second external clock to a I/O, but the
> design refuse to map.
>
>   skew of the second clock is not important to me, I just want a clock
> in a normal I/O pin!
>
>   thanks
> spyng
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Article: 21573
Subject: Re: No- FPGA openness
From: Zoltan Kocsi <root@127.0.0.1>
Date: 25 Mar 2000 23:11:44 +1000
Links: << >>  << T >>  << A >>
husby@fnal.gov (Don Husby) writes:

> galexand@sietch.bloomington.in.us (Greg Alexander) wrote:
> > There are a lot of pompous asses too.  People who stare at disbelief at
> > every newbie constantly insisting that the problems the professionals
> > tackle with on a daily basis are far too difficult for a newbie to even
> > understand are pompous asses and there's no other way around it, no
> > matter how much hardware they've designed.
> 
> Usually, comp.arch.fpga is helpful to newbies.  If you want to have a
> sensible discussion about hacking FPGAs, there are many here who could
> participate.  There are many of us who have hacked at the FPGA tools
> and can speak from experience.  You are not one of them.

He has never said that. He asked for the bitstream info and he was told
that if he needed that info, he was an ass.

> We stare at you in disbeleif because it's warranted.  

IMHO, you stare at him at disbelief because you don't get his point.

> That you seem to
> think you understand the problem without ever having done an FPGA design
> is a measure of how clueless you really are.  

I've done FPGA design, using the usual tools. I still would like to know 
the bitstream. What is my level of cluelessness ? I'd be interested to 
hand craft bitstreams, for fun. Does it degrade me a lot ?

> "There's no other way around it."
> This is not pomposity.  This is reality.  Pomposity is you taking
> the position that we are the ones who are clueless.

Well, he is right in the sense that a lot of people here does not seem
to have a clue about what he's talking about. He does not want to start 
a one-man project to write open source FPGA toolchain (although I'm sure 
he would join such a project as would I). He doesn't want to hack an 
FPGA that can do video morphing in real-time. He wants to play with 
that damned chip and do something which he would not be paid for but 
from what he would learn a lot, plus it would be fun. 

I remember when I built a 7-bit Johnson counter from germanium transistors.
It occupied most of my desk and drove 14 miniature lamps - a lit semicircle
running around on a circle (except when any FF went the wrong way :-). 
It had absolutely no use whatsoever apart from me learning a lot about
flip-flops, counters, shift registers and so on. 

Today you have FPGAs instead of Ge transistors. Ge transistors were fully 
documented and you did not have to buy tools to use them. You could use 
them even in reverse mode (C and E exchanged, was sometimes useful in 
perverse designs) because you got all the info. FPGAs you can't use, 
even if you bought them, for the company reserves the right to render 
them operable. 

It is like buying a radio but not being able to tune it without buying 
the TunePack (tm) (available for both Windows'95 (tm) and WindowsNT (tm)) 
software, great discounts for educational institutes and bulk buyers. 

Back to his unorthodox way of designing the FPGA: The fact that he 
does not want to follow the traditional way of designing an FPGA does
not make him clueless. New things usually coming out from people who
don't follow the road. 99.99% of them makes a long sidetrack and comes
back to the road where all the others are marching. The 0.01% is the
one who is worth of not building a concrete fence on the roadside.
Give them a chance, let them try. If you ar right and the only way
of designing a chip is using the tools, or if Peter Afke is right and
making an FPGA tool is impossible without pouring millions of dollars 
into a project like that, he'll buy the tools or give up and learn
plumbing. Why not give him the opportunity to try ?

> You guys don't own guns do you?  At least we professionals don't take ourselves
> so seriously as to call ourselves a "movement".

He probably left out the word "free". Free software believers
have an agenda and goal and they are numerous enough so the
"movement" is warranted. They also are taken quite seriously 
by some big companies because they smell big money.

All the above, however, has not much to do with Greg's original
request about the bitstream. He is not the first one and will not
be the last one to request it and then being told to piss off.

While I understand the vendors' coming up with all sorts of stuff
about why keeping the bitstream info secret will help us design
better chips and will also help to make the world a better place,
I can't really grasp why some of the "we professionals" mentioned
above jump on him for asking and stating that he does not want to 
buy the Xilinx tools nor Windows to run them on ?

I, by the way, am quite curious why exactly the FPGA vendors keep
the bitstream info closed ?  Both the "protecting the customers' 
designs" and the "so that we don't have to support it" are quite
fishy PR-talk, as has been shown in the thread. 
Obviously they're not going to tell but it's still an interesting 
question (well, to me, at least).

Zoltan

-- 
+------------------------------------------------------------------+
| ** To reach me write to zoltan in the domain of bendor com au ** |
+--------------------------------+---------------------------------+
| Zoltan Kocsi                   |   I don't believe in miracles   |  
| Bendor Research Pty. Ltd.      |   but I rely on them.           |
+--------------------------------+---------------------------------+
Article: 21574
Subject: Re: FPGA openness
From: "Gary Watson" <gary@nexsan.sex>
Date: Sat, 25 Mar 2000 14:02:11 -0000
Links: << >>  << T >>  << A >>
Rickman <spamgoeshere4@yahoo.com> wrote in message
news:38DBF184.C9FEFA10@yahoo.com...
> > I had a similar discussion with Xilinx back in 1988 or thereabouts, when
> > they wanted me to pay $5000 for a piece of software so I could see if
the
> > Xilinx parts would be suitable for my application.  I said to the Xilinx
guy
> > that they should give me the software for free like MMI did with Palasm,
and
> > if it worked they would make their money by selling me chips (after all,
the
> > tools only work with Xilinx chips).  The Xilinx salesman explained that
> > Xilinx is a *software* company, not a chip company.  They only make
chips so
> > they can sell their development tools.
> >
> > I decided that I would ignore Xilinx for ten years, and revisit the
issue.
> > Twelve years on, I've decided to give them another chance, and so I'm
> > looking at the Xilinx parts again.  I'm sure they don't realize that
they
> > lost out on selling millions of Xilinx parts to go into my designs
because
> > they wouldn't give me their tools.    I've been making do with PALs all
> > these years...

> I have the same problem with paying for the software. But you should try
> to distinguish between a lousy salesman and a lousy company. I don't
> think Xilinx has ever considered themselves to be a software company.
> They charge for the tools just because they need to balance the revenue
> against the costs of providing each the hardware and the software. The
> software costs are so large that if they just absorbed that cost into
> the hardware revenue stream, they would have to charge enough more for
> the chips that they would lose some of the high volume sales and their
> competition would gain. So instead they will give away tools if a
> customer is likely to be a high volume user of parts. This is why I
> think you got a lousy salesman. He should have reconized the potential
> gain and gotten you a free copy.

In 1988 I worked for a very small company.  They weren't going to give me a
free copy of the development tools.  My next job, though, was for a large
company where 100,000 piece production runs were not uncommon, and we once
did $1M in a year just on AMD PALs.  Since I didn't know Xilinx I simply
didn't use them.  I guess I was also still mad about the earlier experience,
so I didn't bother to learn.

At the small company in 1988, we weren't insisting on getting the software
for free.  We simply wanted to be sure that our project would fit in one
part, and that it would run at the necessary speed.  If after entering the
design and running the simulation the part didn't achieve our goals, we
wanted our $5000 back (more precisely, we wouldn't pay the five grand until
the simulation yielded the desired results).  At that moment in history,
Xilinx represented a new and largely unproven idea and it was not obvious at
all to me that a real-world design would work well in the parts available at
that time, and we didn't have $5000 extra to throw away.  An ASIC would have
only cost us $40k, because that's what we had been quoted, and would have
been several times faster I'm sure (the project was a minicomputer
emulator).  I guess the boss was afraid of being ripped off, and was doubly
concerned when it appeared that Xilinx didn't have enough confidence in
their parts to let us have the software for the three or four months it
would have taken to learn the package, enter the design, and conduct the
simulation.  If it worked, we would have paid the invoice, and started to
order modest quantities of FPGAs.

The Xilinx sales guy said that he would find us a service bureau who would
quote us on typing in our paper schematics and running the simulation.  This
never happened, but even if it did, I doubt that it would have been cheaper
than buying the Xilinx software.

I don't want to leave the impression that I'm still torqued at Xilinx, in
fact, to the contrary, they seem to be making all the right noises.  A
Xilinx FAE is coming to see me next week, and I'm going to go ahead and
order the tools that I need.  It's just a shame the $100 package wasn't
around back in 1988.

--

Gary Watson
gary@nexsan.sex  (Change dot sex to dot com to reply!!!)
Nexsan Technologies Ltd.
Derby DE21 7BF  ENGLAND
http://www.nexsan.com







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