1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr 2017

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 21450

Article: 21450
Subject: Re: FPGA openness
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 22 Mar 2000 13:43:30 -0800
Links: << >>  << T >>  << A >>
Thanks, Andy. Right on!
I didn't want to fuel these fires, and upset some highly emotional people.
But you explained it so well, and it has more credibility, coming from a user.

There is simply no way any one person in his or her lifetime can write
software that can even remotely compete in quality and performance with what
Xilinx ( and Altera etc. ) have spent and are spending hundreds of thousands
of man-hours on.
Always with the sole intent to make it easier to design with the chips,
because that's where we all make our money from.

Peter Alke

==================================
Andy Peters wrote:

> Greg Alexander wrote in message <8bapci$i0h$1@jetsam.uits.indiana.edu>...
> >That's quite a pity.  Every single time I"ve purchased hardware tied to
> >proprietary software the proprietary software, no matter how good, sucked
> >ass in the end and never ever did what I really wanted.  No matter how
> >good, bug free, and featureful your proprietary software is and how naive,
> >buggy, and underfeatured the software I write will be, I ALWAYS prefer my
> >own.
>
> So, let me get this straight.  You're a software guy - a Linux hacker, as
> you say - and you think that you're just going to be able to, in your spare
> time, write a synthesis tool, a placement engine, a router, and a timing
> analyzer?  Is your background in writing code for synthesis tools?  Logic
> minimization?  All the other stuff that's under the hood of these tools?
> And do you think that your stuff, starting from scratch, will somehow be
> "better" than, say, Xilinx', who've had a ten-year head start on you (and a
> lot more resources to throw at the problem)?
>
> I would imagine that most of us who design with FPGAs for a living would
> much rather have the silicon vendors do the hard stuff -- the design
> software -- so we can get on with our jobs, which is building hardware.
>
> > Have any of you hardware types ever seriously lived a Linux hacker life?
>
> No.  Should I?  And why?  Some of us prefer to be paid for our work.
>
> Have you gone on tour and mixed live rock bands?  Should you?
>
> -- a
> -----------------------------------------
> Andy Peters
> Sr Electrical Engineer
> National Optical Astronomy Observatories
> 950 N Cherry Ave
> Tucson, AZ 85719
> apeters (at) noao \dot\ edu
>
> "Money is property; it is not speech."
>             -- Justice John Paul Stevens

Article: 21451
Subject: Re: FPGA Part Selection Advice
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 22 Mar 2000 16:47:51 -0500
Links: << >>  << T >>  << A >>
David Neely wrote:
>
> Hey all,
>
> Just wanted to ask the newsgroup for a little help. I need to select a part
> for a very small FPGA (or CPLD as the case may be) with about 20-25 pins
> max.
>
> The big gimmick is speed - The part needs to be able to handle ~200 MHz on
> the pins and internally. So far, the GAL22V10 from Lattice seems to be a
> good choice....can anyone make any further recommendations?
> Altera/Xilinx/Alcatel for example??
>
> I wonder if I am forgetting something :Þ
>
> Thanks,
> David Neely
> Junior Engineer

Based on your requirements for package size, you won't find an FPGA to
fit. The smallest FPGA package I have found is a 100 pin TQFP. So you
should concentrate on the CPLDs. But 200 MHz is fast even for CPLDs. I
am not so familiar with these devices so I can't recommend anything.

--

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: 21452
Subject: Re: No- FPGA openness
From: Ray Andraka <randraka@ids.net>
Date: Wed, 22 Mar 2000 22:18:52 GMT
Links: << >>  << T >>  << A >>
That assumes that all devices have pretty much the same architecture, doesn't it?

Ben Franchuk wrote:

> Hobson Frater wrote:
> >
> > Greg,
> >
> > I'm not familiar with your level of knowledge about Xilinx and our products,
> > so please forgive me if the following is not what you're looking for.
> >
> > The bitstream specs for Xilinx devices, indeed most programmable devices from
> > most companies, are proprietary.  This is done to ensure that our customers'
> > designs aren't copied or reverse-engineered (well at least not without a lot
> > of trouble) by our customers' competitors.
> >
> I still can see how it would prevent reverse engineering, but I am lost
> on how that prevents designs from being copied if a simple Rom is being
> used to hold the bit stream. The disadvantage of the closed information
> is that one is tied to the manufacturer to provide the ONLY source of
> software for programing the device. A better idea would have standard
> bit stream format, and have the manufactures supply a conversion program
> to their encrypted format. This would provide hopefully more FPGA
> software
> and more people using FPGA's
>
> --
> "We do not inherit our time on this planet from our parents...
>  We borrow it from our children."
> The Lagging edge of technology:
> http://www.jetnet.ab.ca/users/bfranchuk/woodelf/index.html

--
-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: 21453
Subject: Re: Clock disabling
From: "Jared Church" <jaredc@icpdd.nec.com.au>
Date: Thu, 23 Mar 2000 09:46:04 +1100
Links: << >>  << T >>  << A >>
This would creat a skew between the two clocks if you are using both at the
same time at any point - so you'd probably be better to use a and gate for
both of them to give a similar delay.

eg

clk1 <= mast_clk and '1' ;
clk2 <= mast_clk and enable ;

Then define clk1 and clk2 as being clock nets which should go through the
process of clock tree synthesis which your asic vendor may do for you.

of course then you could have separate enables for each clock if oyu wanted
as well.

You'd probably want to make sure that the enable was fixed in a certain
position to avoid glitches from switching the clock on and off - but then
based on the initial problem you probably wouldn't want to turn one of them
on and off anyway.

jc

<boniolopez@my-deja.com> wrote in message
news:8batsh$7pk$1@nnrp1.deja.com...
>
>
> Hi Nicolas,
> Im not sure if it would good solution and would be glad if Mr. Peter
> Alfke and other expert comments following:
> Why not make 2 clock domains one with clk1 and one with clk2.
> Clk2<=clk1 and enable_from_external_pin;
> If you make ASIC this should not cause problem, in FPGA place clk2 on
> secondary buffer (BufG).
> Correct me, if I am wrong.
>
> remove_this_bonio.lopez@gmx.ch_remove_this
> In article <38D63858.2A94786B@dotcom.fr>,
> Nicolas Matringe <nicolas@dotcom.fr> wrote:
> > Hi all
> > I am working on a design which may be used in two products, one of
> which
> > won't need some functions of the design. I don't want to have 2
> designs
> > (we won't make 2 ASICs).
> > I was wondering if it was possible to have 2 clock domains (same
> > frequency) with the possibility to turn one of them off to reduce
> power
> > consumption (this would be done by pulling a pin high or low for
> > example)
> > --
> > Nicolas MATRINGE DotCom S.A.
> > Conception electronique 16 rue du Moulin des Bruyeres
> > Tel 00 33 1 46 67 51 11 92400 COURBEVOIE
> > Fax 00 33 1 46 67 51 01 FRANCE
> >
>
>
> Sent via Deja.com http://www.deja.com/

Article: 21454
Subject: Re: FPGA openness
From: ldoolitt@recycle (Larry Doolittle)
Date: 22 Mar 2000 23:07:20 GMT
Links: << >>  << T >>  << A >>
Andy Peters (apeters.Nospam@nospam.noao.edu.nospam) wrote:

: [ chop ] you think that you're just going to be able to, in your spare
: time, write a synthesis tool,

http://icarus.com/eda/verilog/
(needs some work, I know, but the core is there)

: a placement engine, a router,

http://www.eecg.toronto.edu/~vaughn/vpr/vpr.html

: and a timing analyzer?

Someone would have to volunteer for this one, probably based on
ACS or one of the libre VHDL/Verilog simulators.

: Is your background in writing code for synthesis tools?

See Icarus, above, or http://www-asim.lip6.fr/alliance/

: Logic minimization?

Classical logic minimization isn't terribly relevant for today's
FPGA architecture.  The vpr code above handles some of what's left.

:  All the other stuff that's under the hood of these tools?

Such as "project managers" and other GUI bits I don't want?

: And do you think that your stuff, starting from scratch, will somehow be
: "better" than, say, Xilinx', who've had a ten-year head start on you (and a
: lot more resources to throw at the problem)?

Quoting from the original post:
>> Every single time I"ve purchased hardware tied to
>> proprietary software the proprietary software, no matter how good, sucked
>> ass in the end and never ever did what I really wanted.  No matter how
>> good, bug free, and featureful your proprietary software is and how naive,
>> buggy, and underfeatured the software I write will be, I ALWAYS prefer my
>> own.

So no, he doesn't think he can do "better".  But he (and I) _would_ be
happier, because we understand what the limitations are, and can
address them as _we_ need, independent of someone else's market research.

: I would imagine that most of us who design with FPGAs for a living would
: much rather have the silicon vendors do the hard stuff -- the design
: software -- so we can get on with our jobs, which is building hardware.

... and wrestling with license managers, and begging for more money
to pay for continued use of the software.

Peter Alfke (peter@xilinx.com) wrote:

: There is simply no way any one person in his or her lifetime can write
^^^^^^^^^^
: software that can even remotely compete in quality and performance with what
: Xilinx ( and Altera etc. ) have spent and are spending hundreds of thousands
: of man-hours on.

OK, but how about a whole Internet full of people?  That mindset
belongs in the 1980's.  Essentially, you are telling your customers
to "shut up and get back on the couch."

: Always with the sole intent to make it easier to design with the chips,
: because that's where we all make our money from.

So release the bloody bitstream format already!  Peter, I respect you
technically, but I also know who gives you your paycheck, and I know
the rules that corporations are legally obliged to follow.  Those rules
have everything to do with money, and nothing to do with customer's
control over their design.  In particular, the intent of Xilinx's
software is to lock their customers into Xilinx's chips.  Ditto for
Altera.

I'm about to shell out some taxpayers' money for a commercial package,
because the free stuff isn't there yet, and never will be if Xilinx
has its way.  That doesn't mean I'm happy.

I know this question gets hashed over in c.a.f every six months or so,
and I guarantee that pattern will continue until the problem is fixed.
Here's a scenario for how that will happen: some startup puts together
an FPGA, tries to sell it, goes belly up.  Rather than selling the
charred remains to Xilinx, it releases the tested and functional (but
not profitable) chip design to the world.

Sorry for the interruption.  You can now return to the usual fare of
"Why can't I make the stoopid software tools do what I want" questions.

- Larry Doolittle  <LRDoolittle@lbl.gov>
Article: 21455
Subject: Re: FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 22 Mar 2000 23:26:45 GMT
Links: << >>  << T >>  << A >>
In article <8bb5r9$27bv$1@noao.edu>, Andy Peters wrote:
>Greg Alexander wrote in message <8bapci$i0h$1@jetsam.uits.indiana.edu>...
>>That's quite a pity.  Every single time I"ve purchased hardware tied to
>>proprietary software the proprietary software, no matter how good, sucked
>>ass in the end and never ever did what I really wanted.  No matter how
>>good, bug free, and featureful your proprietary software is and how naive,
>>buggy, and underfeatured the software I write will be, I ALWAYS prefer my
>>own.
>
>So, let me get this straight.  You're a software guy - a Linux hacker, as
>you say - and you think that you're just going to be able to, in your spare
>time, write a synthesis tool, a placement engine, a router, and a timing
>analyzer?  Is your background in writing code for synthesis tools?  Logic
>minimization?  All the other stuff that's under the hood of these tools?
>And do you think that your stuff, starting from scratch, will somehow be
>"better" than, say, Xilinx', who've had a ten-year head start on you (and a
>lot more resources to throw at the problem)?

Nope.  By reinventing the problem we can avoid all that.  First off, I
have little interest in a complete synthesis tool.  I also have little
interest in a complete placement engine or even a complete router.  The
timing analyzer worries me but I'm certain that if I could find timing
specs for the chips (which I haven't been able to do so far -- anyone
have any ideas?) that I'd be able to tackle the problem.  At worst case I
may find that the thing is undebuggable without the purchase of a pricey
logic analyzer -- spending $300 for a low-end logic analyzer makes me a lot happier than spending$100 for software that doesn't do what I want.
Here, I'll explain my complete gameplan so far:
I'm looking at the XS40 board with an XC4005XL on it, which is a
Xilinx FPGA with a 14x14 grid of FLBs.  A quick browse of the datasheet
shows what attributes must be associated with each FLB, so I'd start out
by making something that takes a textual input description of each FLB
(listing the inputs for each MUX and the logic functions for each of the
three function generators; or the setup info if the FLB is to be used for
RAM), something directly analogous to the bitstream with just the slightest
abstraction for routing (perhaps naming the blocks and using block/output
names -- i.e. "f1=1,1.yq" or even "f1=stackbit1.yq" instead of being so aware
about the actual routing capabilities of the chip.  Hopefully a converter
to/from the bitstream and the simple text format would take me a couple
weekends...nothing too special...for example, if the routing resources
don't allow a connection between 1,1.yq and f1, it will just barf and exit
and I'll be forced to go back to the datasheet and manually re-place the
blocks involved.  Probably I'll find that setup just a step or two too
cumbersome to work with directly in vi, so I'll probably start work on
over-simplified GUI where I can drag around named FLBs and it'll highlight
connections that I've specified to other named FLBs that aren't allowed in
that placement.
Because it would be a bidirectional converter, I'd look at a lot
of the preexisting bitstreams I have to look for how automated software
uses the resources provided on the things to give me some ideas...but even
the obvious capabilities of the FLBs on such a device seem sufficient for
me to implement the processor I'm after, so I'm not betting too much on
being able to use existing designs as inspiration.
I am inexperienced but I hope to be able to have the chip mostly
asynchronous and timing worked out by a combination between trial and
error and eyeballing how I think it ought to work.  I would be surprised
if I don't develop an intuitive feel for it after a few months of messing
around on weekends, esp. for such a small FPGA.  I'm certainly not ruling
out the possibility that I'll never get anything to work right at all on
it, though.
I don't need synthesis because I'll be laying it out like legos: a
stack here, an adder there -- "oh damn no way to route that, let's scoot
the adder over" (you /have/ played with legos enough to know the creative
process, right? -- you don't really get a functional or heirarchical view,
if you don't have pieces that fit you have to figure out how to do it with
the pieces you have and if it turns out that you need something to be two
blocks tall instead of three blocks tall you may well end up rebuilding
the rest of your lego contraption -- directly analogous to a lack of
synthesis and place&route software, methinks) -- and attempting to just
build one processor, not a whole bunch of little things where I need the
ultimate in flexibility.
At any rate, I'd be doing it for my own fun.  I would enjoy failing
at designing a processor in FPGA from the ground up a lot more than I would
enjoy succeeding at performing the task with the use of tools that piss me
off.  I'm very picky about my tools, and I can guarantee you that any
Windows software targetted at "students" would piss me off at every step
of the way.
I fully expect for someone to reply that I'm stupid to expect the
commercial world doing all their Important Engineering for Real World
much too important for a mere college student to understand to give a darn
about some kid who just wants to fool around...but, well...where did you
start?  If we couldn't have fun with this stuff, none of us that are any
good at it would even bother.  If there isn't a version of the chip
suitable for a kid to mess around with then odds are there won't be any
adults who really know what they're doing when they mess around with it.

>I would imagine that most of us who design with FPGAs for a living would
>much rather have the silicon vendors do the hard stuff -- the design
>software -- so we can get on with our jobs, which is building hardware.

Don't confuse using a tool for doing work.  At any rate, I agree that any
vendor who doesn't sell synthesis and P&R tools would be doing a
disservice to a lot of its customer base...but any vendor who makes their
hardware impossible to use without a specific set of P&R tools is also
doing a disservice.  Perhaps I have a hcoice between Brand A and Brand B,
but that isn't any choice at all compared to homegrown.
Probably most people who design with FPGAs for a living use them
simply as limited programmable ASICs.  That's a fine use for them.  I want
to use them as FPGAs, though.  I have been given the knowledge of what the
FLBs do and to use them as if they were something else would be
intolerable for me, at least to start out.  In other words, when I say AND
gate, I expect an AND gate, but if I say AND gate and I know that it'll
cleverly transform that into a lookup table in an FLB while attempting to
cleverly take advantage of the 2 other inputs that the function generator
affords...that's a lot of work going down behind my back, a lot of
exciting things happening that I want to be involved in.  Maybe in the end
my answer isn't nearly as ingenius as what Xilinx's software would have
come up with...but on the other hand, what if it's 100x better than what
Xilinx's software would've come up with?  What if it's just as good?
Unless you know exactly how Xilinx's software works, which I assume
you don't -- apparently it's not widely published information -- you
can't have absolute faith in it.  I've been burned by prepackaged software
often enough that I'm reflexively mistrusting of it -- perhaps you
reflexively trust it because you've had good experiences with similar
software or perhaps you just don't care much about how efficient it is
since you know you don't have the time to do it all by hand so even if it
does badly, at least it gets the job done.  The point is that neither your
trust nor my mistrust are justified unless we get the source or at least
some strong understanding of what's possible, and that's what I'm after.

Related work:
www.ultratechnology.com is the page for a company financed by a
single individual (some might call him crazy) attempting to finish
prototyping the F21 Minimal Instruction Set Computing (MISC)
microprocessor.  Chuck Moore designed the chip from the ground up.  His
CAD and simulation software were all written by him.  I can't find the
figures right now but IIRC the object code of his CAD+simulation
environment was well under 32k.  He didn't do automated layout (though I
assume that since his CAD software is at basically the same level as his
programming language that when he had to do repetitive tasks he didn't do
them by hand) at all.  I think he draws each transistor one at a time.  He
has working silicon.  You can buy the MuP21 which was developed with the
same software (I think), and the F21 is most likely only one prototyping
stage away from working perfectly.
Now you're thinking that Chuck Moore is an established
professional (I think ShBoom/Patriot Scientific 1000 were his work in more
traditional technology) who spent the last 15 (or more) years of his life
full time developing that software and those chips -- obviously not a
valid comparison to me.  However, if I'm working on FPGA then my
prototyping rounds will take just a few minutes and cost me nothing
whereas each prototype he developed took months to get back from fab
and packaging then took all sorts of time to analyze and each and every
fab run (at least for the f21) was itself an economic crisis for the owner
of ultratechnology (which is why F21e prototype isn't being fabbed right
now).  It's apparently a well-established fact that software development
productivity increases more than linearly as compile/link time decreases
(eXtreme Programming).  In addition, I won't be starting over totally from
scratch -- my object code will probably be much larger than 25k and it
won't be hand-crafted (Chuck Moore invented Forth and his CAD/sim software
runs on an extremely unique and low-level derivative).  I think these
advantages should simplify my task by several orders of magnitude and bring
it into the range of what's feasible for me to complete eventually.

At any rate, I'd much rather spend my next month banging my head
on timing issues than trying to reverse-engineer their bitstream,
something they can be confident their competitors have already done if
there's any point to it (it's not a very difficult task).

>> Have any of you hardware types ever seriously lived a Linux hacker life?
>
>No.  Should I?  And why?  Some of us prefer to be paid for our work.

So do I.  I bet I'll be paid more (no cash involved) than your salary
affords you if I ever boot up my own little toy processor on FPGA.  I dare
you to buy that type of satisfaction with your 6-figure salary.  Money is
not the ends, money is the means.
At any rate, hardcore Linux hackers are, almost without exception,
paid extremely well.  If you can make fantastic technological toys for your
own edutainment, it shows a lot to a potential employer.  If you would do
the stuff for the love of doing it, it usually implies greater competence
than just the random Joe with a degree.
My point in asking the question was actually to discover if you
had seen "the light."  Many programmers can remember the first day they
allocated more than 64k (or 640k) of RAM without hassling with segments
or an extended memory manager -- the first time they wrote a program for a
real 32-bit OS.  Not many of them willingly went back to DOS after that.
Well I can remember the first time I was exposed to software that was
broken but that, for the first time, I could fix because I had the
knowledge and the source code to do so.  I, for one, am not going back.
Once you realize how much more can be accomplished by cooperation than by
secrecy and attacks (suing over Patent violations, for example), I can't
imagine anyone who really loves their art would go back.  If you don't
give up the love.
10 year old closed source software that crashes when you try to
run it you have no choice but to throw away.  10 year old open source
software that crashes when you try to run it you can recompile with -g
(debugging symbols) and load up in gdb (GNU DeBugger) and fix.  Do you
want to contribute to the trashcan or to someone else's debugging
nightmare?  I'd prefer my progeny be a cursed debugging nightmare rather
than a completely useless bitbucket filler.

>Have you gone on tour and mixed live rock bands?  Should you?

If I had the opportunity and the opportunity cost were low (if I could do
it for just a summer, for example), I would certainly consider doing it.
If one of my larger goals were to make a better mixer, I'd certainly take
the opportunity to go out and see how the things are used.  Since your
goal is to make intellectual property, it seems like you kind of have an
obligation to yourself to learn how successful people work with
intellectual property: by sharing.
Article: 21456
Subject: Re: No- FPGA openness
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Wed, 22 Mar 2000 16:45:36 -0700
Links: << >>  << T >>  << A >>
Rickman wrote:

> There are a lot of reasons for not giving out the bit stream format
> details. Some have to do with preventing reverse engineering, but most
> have to do with the interests of the company making the hardware. But
> they are valid reasons nonetheless.
>
> One big reason is that the software can give an FPGA vendor a
> competitive edge. For quite a while Altera was touted as having much
> more user friendly software as compared to Xilinx. I can't say if this
> was really true since I am not an Altera user. But I know people who
> chose them as their FPGA vendor for this reason. I also don't think that
> users perceive such a significance in the tools today.
>

My favorite tools are pencils and spell checkers.
How ever the market for FPGA's is not for the one time
computer hobbist ,or student but rather well funded companies,
thus a few grand for software is small change when the IC's are few
$100 each, so I can under stand the way the software tools are. Does any one use simple PAL's any more for$.79 each?

> The existance of third party tools can be seen as a threat to an FPGA
> vendor for this reason. About 10 years ago a third party FPGA tools
> vendor, Neocad, came out with a set of tools that was not targeted to
> any one vendor. One big selling advantage was that they would allow you
> to port your designs between different vendors if you decided to change.
> Combine that with the improved operation of the place and route portion
> of the tools and now the FPGA vendors were looking at reduced software
> sales. In fact more than one FPGA vendor dropped their own tools and
> offered Neocad as their sole source of tools.

Are they selling HARDWARE or SOFTWARE?, I thought it was hardware.

> Xilinx decided that they needed the Neocad as an inhouse product and
> bought the company. After a couple of years, they came out with a new
> set of Xilinx tools based on the old Neocad tools. I can't say exactly
> why Xilinx did this, but it did take the Neocad tools off the market.
>

> In any event, if you feel you can produce better FPGA tools than can the
> vendors, why don't you feel that you can produce better chips? There are
> projects which will allow you to share a wafer and produce a very small
> quantity of chips at a reasonable price. Likely the cost of the chips
> are less than the cost of the designer to lay them out. Why not go for
> it and do an open source FPGA?

I have no desire to go into the FPGA market, as I was not the one
wanting to do software rewrite? As for a open source FPGA,
I don't think one can do that cause most likely the FPGA's internal
designs at patented.

>
> BTW, Neocad initially met with resistance from Xilinx, but after they
> persisted and started shipping tools in spite of the Xilinx policy,
> Xilinx changed course and assisted them with detailed internal
> information on even the new chips. Maybe you will get this kind of
> support once you have reached a point of credibility in the FPGA
> community.
>

Who knows.

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

Hmm I wonder if the next generation of FPGA's could
have tiny leds on the outside, to show the data flowing like on
star trek's enginering console.

--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
The Lagging edge of technology:
http://www.jetnet.ab.ca/users/bfranchuk/woodelf/index.html
Article: 21457
Subject: Re: No- FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 22 Mar 2000 23:57:18 GMT
Links: << >>  << T >>  << A >>
In article <38D93BB6.65D94188@yahoo.com>, Rickman wrote:
>Ben Franchuk wrote:
>>
>> I still can see how it would prevent reverse engineering, but I am lost
>> on how that prevents designs from being copied if a simple Rom is being
>> used to hold the bit stream. The disadvantage of the closed information
>> is that one is tied to the manufacturer to provide the ONLY source of
>> software for programing the device. A better idea would have standard
>> bit stream format, and have the manufactures supply a conversion program
>> to their encrypted format. This would provide hopefully more FPGA
>> software
>> and more people using FPGA's
>>
>> --
>> "We do not inherit our time on this planet from our parents...
>>  We borrow it from our children."
>> The Lagging edge of technology:
>> http://www.jetnet.ab.ca/users/bfranchuk/woodelf/index.html
>
>There are a lot of reasons for not giving out the bit stream format
>details. Some have to do with preventing reverse engineering, but most
>have to do with the interests of the company making the hardware. But
>they are valid reasons nonetheless.
>
>One big reason is that the software can give an FPGA vendor a
>competitive edge. For quite a while Altera was touted as having much
>more user friendly software as compared to Xilinx. I can't say if this
>was really true since I am not an Altera user. But I know people who
>chose them as their FPGA vendor for this reason. I also don't think that
>users perceive such a significance in the tools today.

It seems like adding more software to the pool of programs that support
Xilinx FPGAs would be a good thing (esp. open source programs hwich
are likely supported by a large and rabbid group of hackers and which
likely support operating systems and features that no commercial software
would ever bother with).  The best that could happen would be that said
hackers find specs for the XC4005XL and can afford an XS40 board and
develop all of their software for Xilinx and this software is something
that Xilinx could brag about.  The worst that could happen would be if the
hackers got specs for all FPGAs and made a really phenomenal development
environment for all FPGAs that is better than any out by any vendor:
neither changes the balance -- both can only make Xilinx more attractive.
If instead a whole bunch of hackers just make crappy useless software and
they only make it for Xilinx...WHO CARES?  Yet another piece of crap
sitting in some far corner of an overcrowded Linux archive.  Big whoop.
The software vendors can gain from the FPGA specs being
proprietary, but the FPGA vendors (unless they are maintaining a monopoly
on software, which at least Xilinx does not appear to) have nothing to
lose by opening it up unless they get some kickbacks from the software
vendors.  Unless, of course, their software totally sucks and they know
that opening up their specs would immediately result in a dozen smaller,
faster, better route&place engines being released, a possibility I will
not rule out.

>The existance of third party tools can be seen as a threat to an FPGA
>vendor for this reason. About 10 years ago a third party FPGA tools
>vendor, Neocad, came out with a set of tools that was not targeted to
>any one vendor. One big selling advantage was that they would allow you
>to port your designs between different vendors if you decided to change.
>Combine that with the improved operation of the place and route portion
>of the tools and now the FPGA vendors were looking at reduced software
>sales. In fact more than one FPGA vendor dropped their own tools and
>offered Neocad as their sole source of tools.
>
>Xilinx decided that they needed the Neocad as an inhouse product and
>bought the company. After a couple of years, they came out with a new
>set of Xilinx tools based on the old Neocad tools. I can't say exactly
>why Xilinx did this, but it did take the Neocad tools off the market.

See, if Neocad really did up the ante in the routing game, then Neocad
tremendously helped FPGA.  Rather than redesigning their interconnect,
probably a very expensive operation, it was shown that simply redesigning
the software can make a huge difference, something they'd apparently not
taken into account if some third party software was actually capable of
beating them.  Upping the standards may have cost them a little bit in the
short term but I'm sure it helped increase people's respect for FPGAs.
Also once the software is respected as having evolved for a while and
being the result of 10 years of work, as you've observed, fewer people in
your shoes will have trouble believing that it's really worth as much as
the pricetag is.
Back when Neocad was an issue, I get the impression that Linux
wasn't, and Neocad also apparently wasn't an issue because Xilinx et al
were sharing everything with everyone -- in other words, is anything
resources, they would get the specs if they tried hard enough, probably
direct from Xilinx...  Nobody has apparently done the gamble to see what
resources are available if you really open it up to just let random Joe
Blow mess around with the things.

>I won't say that I miss the Neocad tools. They were written by a group
>of Unix hackers that understood little about hardware design. The user
>interface on the tools was case sensitive so that users had to mix case
>on nearly every command typed. The tools were written to control what
>you did instead of helping. For example, if after placement, the tools
>constrains with routing delays added, you would not be allowed to try to
>route the design. This did not work well for tristate busses where the
>guestimated delays were about twice the actual delays.

Had it been open source, you could have quick-fixed the guesstimates and
you'd never be sitting there "I KNOW YOU THINK THIS WON'T WORK, BUT IT
WILL, JUST ROUTE THE !#$!@#$ING THING !#$!@#!!!" because the author will always have respected the users (or is at least easily correctable :)). Misapplied Unix hackers doing a bad job doesn't mean Unix hackers are all stupid, you know. I've had almost no exposure to commercial engineering tools, but even in my limited exposure I can point you to high-priced engineering software that was obviously written by idiots...therefore you shouldn't use any high-priced engineering software? >So all in all, I feel that the Unix hackers did a very poor job of >writing an FPGA tool set. I think the only part that was better than the >proprietary tools was the router which could be run on a network of Sun >workstations overnight or the weekend to give you a lot more compute >time to solve the routing problem. > >In any event, if you feel you can produce better FPGA tools than can the >vendors, why don't you feel that you can produce better chips? There are >projects which will allow you to share a wafer and produce a very small >quantity of chips at a reasonable price. Likely the cost of the chips >are less than the cost of the designer to lay them out. Why not go for >it and do an open source FPGA? I can produce better FPGA tools /FOR ME/. I certainly don't have the expertise to design real chips (it seems like you'd start with the easy development environment then go on to the Real Thing, rather than vice versa). There are good odds that if a couple linux hackers make cheap little overspecified tools, that will encourage someone else to buy an FPGA without worrying about whether or not they'll be able to get it to work. Look at xess.com, their question/answer section has two separate postings about Linux. Their bitstream-upload software (xstools) has been ported to Linux at least twice. There is obviously interest. But when I say "I want Linux Software", I don't mean I want a port of the crappy Windows software...I want something that meets the standards for being Linux Software (with an upper-case S) -- open-source, targetted at people who could understand everything if they had the time, and runs on Linux. The last requirement is the least important one. I'm sure there are some lurkers here and if I find teh specs I'm after and I come back in 4 months saying "HOORAY, IT BOOTED!!" I know for certain after the impression I'm making here that any lurkers who aren't already designing FPGAs will say "hey wow! If that kid can do it, anyone can" and they'll go out and buy FPGAs without even the slightest hesitation. >BTW, Neocad initially met with resistance from Xilinx, but after they >persisted and started shipping tools in spite of the Xilinx policy, >Xilinx changed course and assisted them with detailed internal >information on even the new chips. Maybe you will get this kind of >support once you have reached a point of credibility in the FPGA >community. And how do you propose I get there? I'm not Foosoft, I'm a kid trying to write his own software to design his own processor. I have no interest in being part of a mass-market. I have no interest in other people using my software -- I'll share it because other people shared their little hacks and I've found them useful, but not because I expect to have market influence individually. I want to design a processor in FPGA. I don't want to be a politician or a vendor or otherwise spend my entire time fighting Xilinx. I want to provide them money and in return receive a chip that I can use. Article: 21458 Subject: Re: 4000XLA bitgen problem? From: galexand@sietch.bloomington.in.us (Greg Alexander) Date: 22 Mar 2000 23:57:58 GMT Links: << >> << T >> << A >> In article <38D931FE.4239F0F2@hia.nrc.ca>, 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? If I had source I'd tell you. :P Article: 21459 Subject: Re: FPGA openness From: galexand@sietch.bloomington.in.us (Greg Alexander) Date: 23 Mar 2000 00:13:49 GMT Links: << >> << T >> << A >> In article <38D93E81.1EA5522D@xilinx.com>, Peter Alfke wrote: >Thanks, Andy. Right on! >I didn't want to fuel these fires, and upset some highly emotional people. >But you explained it so well, and it has more credibility, coming from a user. > >There is simply no way any one person in his or her lifetime can write >software that can even remotely compete in quality and performance with what >Xilinx ( and Altera etc. ) have spent and are spending hundreds of thousands >of man-hours on. >Always with the sole intent to make it easier to design with the chips, >because that's where we all make our money from. I can't design with the chips at all since I can't run your software. More importantly, it's patently absurd that 100000 people with$1000000000 will do a better job than 1 person with pennies in his pocket
at software design or engineering.  Compare and contrast: FrameMaker's
justify and hyphenation engines vs. TeX's justify and hyphenation engines.
Adobe made FrameMaker, they're one of the most respected names in desktop
publishing, and they doubtless had a huge and well-funded team working on
FrameMaker, yet its hyphenation and justification sucks compared to TeX's,
which, so far as I know, was written just by Donald Knuth.
Ultima 9 vs. Quake.  Ultima 9 was written by an established and presumably
large team of well-funded developers in a big company and is known for
crashing constantly.  The various versions of Quake have had programming
input from less than 4 people and almost all of the work is just by John
Carmack -- idsoftware reliably releases games that are faster, more
stable, and less delayed than other companies despite being such a small
team.
In a weird way: Linux vs. Windows.  I've read the linux-0.01 source,
pretty much entirely Linus's work, and I tell you that if Windows had
started out anything like that and maintained that spirit, it wouldn't be
well known for crashing during screensavers.
If there aren't any glaring examples in ya'll's lives, it's probably only
because you deal primarily in such proprietary software.

Even more importantly, I have no intention of making better
synthesis, route, and place tools than Xilinx did.  I don't even want
those tools.  I want different tools.  You sell an expensive hammer when
what I want is a screwdriver.  Maybe I'll never make a decent hammer for
the rest of my life -- that wouldn't surprise me...at least today I
don't have any ideas forming in my head about how to design R&P software
and I know nothing of synthesis.  But I'll be damned if my screwdriver
isn't 100x better at turning screws than your hammer is.
I guess a better analogy would be that most people want a hammer
and you make a screw that is a lot better than nails for some uses.  Your
customers still want to make hammer motions so your software is great at
converting that swinging motion into something that will turn your
revolutionary *grin* screws.  I, however, want to make turning motions to
use your screws but your hammer is glued to the screws (in the way) so I
can't figure out if it's Philips or some bizarre Torx screw.  Of course,
your hammer would work equally well if you made it so that I could still
see the screw, but you guys have decided not to make that so.
Article: 21460
Subject: Re: No- FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 23 Mar 2000 01:01:06 GMT
Links: << >>  << T >>  << A >>
In article <38D95B1F.9B3E2A6@jetnet.ab.ca>, Ben Franchuk wrote:
>Rickman wrote:
>
>> There are a lot of reasons for not giving out the bit stream format
>> details. Some have to do with preventing reverse engineering, but most
>> have to do with the interests of the company making the hardware. But
>> they are valid reasons nonetheless.
>>
>> One big reason is that the software can give an FPGA vendor a
>> competitive edge. For quite a while Altera was touted as having much
>> more user friendly software as compared to Xilinx. I can't say if this
>> was really true since I am not an Altera user. But I know people who
>> chose them as their FPGA vendor for this reason. I also don't think that
>> users perceive such a significance in the tools today.
>>
>
>My favorite tools are pencils and spell checkers.
>How ever the market for FPGA's is not for the one time
>computer hobbist ,or student but rather well funded companies,
>thus a few grand for software is small change when the IC's are few
>$100 each, so I can under stand the way the software tools are. >Does any one use simple PAL's any more for$.79 each?

If I knew how to make PC boards without screwing myself over with
capacitance at high frequencies, I certainly would buy simple PALs, now
that I know that the FPGA development world doesn't have any interest in
being my friend. :)  Too bad I don't think I could quite implement an
entire Forth processor in a single PAL. :)
Article: 21461
Subject: Giving fpga's unique id
From: kgbee@my-deja.com
Date: Thu, 23 Mar 2000 01:56:08 GMT
Links: << >>  << T >>  << A >>
I have an application which uses up to 16 4028xla's. I would
like each part to have a unique ID so I can write to that
part's registers over common address & data buses. One
way to do this is to daisy chain a 4bit ID value. The 1st
device gets "0000" using pulldowns. It adds 1 to this
and sends it to the next part, etc. This takes very little
logic but does require 8 pins.
Is there a better way to do this? Can something be done during
configuration without having to generate many unique bit files?
Les

Sent via Deja.com http://www.deja.com/
Article: 21462
Subject: Re: FPGA openness
From: Ray Andraka <randraka@ids.net>
Date: Thu, 23 Mar 2000 02:16:30 GMT
Links: << >>  << T >>  << A >>
Ya know Greg, you can get as close to the hardware as you want with the current
tools and you'll get up to speed on the gory details of the FPGA a heck of a lot
faster using the stuff that is already out there, even if it has a few bugs.  You
have a choice: you can spend all your time figuring out how to connect two CLBs
together, or you can spend your time actually working with the FPGA and doing
something with it.

What you are describing is pretty much the way the first XC2000 software worked
(and the way the Epic chip editor in the current tools works).  If you want to,
you can write the equation for every CLB, and manually route the signals between
them using this tool. In fact, using it you bypass the entire
schematic/synthesis, translate, map, and place and route flow.  Why, I'll bet the
guys at NeoCad spent a great deal of time playing with XDE (the chip editor in
the old XACT tools) before they every wrote their first line of code.  Entering a
design this way is not for the faint of heart though: it is tedious and error
prone.  Moving to the capture side, you can still get pretty close to the
hardware though, all the way down to instantiating exactly the primitive you want
and where you want it placed.  Granted, that doesn't help you much if you are
looking for the abiltiy to generate new configurations on the fly.  Fortunately,
many of the applications for reconfigurability can work with a relatively small
set of configurations, perhaps with some LUTs twiddled (something that J-Bits is
good for).  I think before you tried to write your own tools, you'd be wise to
understand the gory details of the PFGA architecture.  As it is, you seem to feel
you grok the CLBs well.  It is apparent in you post though, that you don't have
any understanding of the routing architecture.  The fact of the matter is the
lion's share of the bits in the bitstream are for setting up the routing
resources, not for setting the CLB functions.  If you are really serious about
writing your own tools, I would suggest you work in the chip editor using a long
series of simple configurations, generate bitstreams for each one and examine the
differences in the generated bit streams.  With alot of hard work you can get
something close enough to write bitstreams directly (that's pretty much how
Neocad got their tool up).  For the $100 bucks (and just one weekend is worth a heck of a lot more than$100 to me), I think buying the student edition would be
worth it, if for nothing more than an investigative tool.  It also gives you the
advantage of being able to work at a higher level to figure out what works well
and doesn't work well in the FPGA architecture without getting lost in the low
level detail.  I for one, have done the pip pushing, and I can tell you  that it
is something I avoid like the plague.  BTW, getting the bitstream format under
NDA is not exactly unheard of, even for graduate students.

Greg Alexander wrote:

> In article <8bb5r9$27bv$1@noao.edu>, Andy Peters wrote:
> >Greg Alexander wrote in message <8bapci$i0h$1@jetsam.uits.indiana.edu>...
> >>That's quite a pity.  Every single time I"ve purchased hardware tied to
> >>proprietary software the proprietary software, no matter how good, sucked
> >>ass in the end and never ever did what I really wanted.  No matter how
> >>good, bug free, and featureful your proprietary software is and how naive,
> >>buggy, and underfeatured the software I write will be, I ALWAYS prefer my
> >>own.
> >
> >So, let me get this straight.  You're a software guy - a Linux hacker, as
> >you say - and you think that you're just going to be able to, in your spare
> >time, write a synthesis tool, a placement engine, a router, and a timing
> >analyzer?  Is your background in writing code for synthesis tools?  Logic
> >minimization?  All the other stuff that's under the hood of these tools?
> >And do you think that your stuff, starting from scratch, will somehow be
> >"better" than, say, Xilinx', who've had a ten-year head start on you (and a
> >lot more resources to throw at the problem)?
>
> Nope.  By reinventing the problem we can avoid all that.  First off, I
> have little interest in a complete synthesis tool.  I also have little
> interest in a complete placement engine or even a complete router.  The
> timing analyzer worries me but I'm certain that if I could find timing
> specs for the chips (which I haven't been able to do so far -- anyone
> have any ideas?) that I'd be able to tackle the problem.  At worst case I
> may find that the thing is undebuggable without the purchase of a pricey
> logic analyzer -- spending $300 for a low-end logic analyzer makes me a > lot happier than spending$100 for software that doesn't do what I want.
>         Here, I'll explain my complete gameplan so far:
>         I'm looking at the XS40 board with an XC4005XL on it, which is a
> Xilinx FPGA with a 14x14 grid of FLBs.  A quick browse of the datasheet
> shows what attributes must be associated with each FLB, so I'd start out
> by making something that takes a textual input description of each FLB
> (listing the inputs for each MUX and the logic functions for each of the
> three function generators; or the setup info if the FLB is to be used for
> RAM), something directly analogous to the bitstream with just the slightest
> abstraction for routing (perhaps naming the blocks and using block/output
> names -- i.e. "f1=1,1.yq" or even "f1=stackbit1.yq" instead of being so aware
> about the actual routing capabilities of the chip.  Hopefully a converter
> to/from the bitstream and the simple text format would take me a couple
> weekends...nothing too special...for example, if the routing resources
> don't allow a connection between 1,1.yq and f1, it will just barf and exit
> and I'll be forced to go back to the datasheet and manually re-place the
> blocks involved.  Probably I'll find that setup just a step or two too
> cumbersome to work with directly in vi, so I'll probably start work on
> over-simplified GUI where I can drag around named FLBs and it'll highlight
> connections that I've specified to other named FLBs that aren't allowed in
> that placement.
>         Because it would be a bidirectional converter, I'd look at a lot
> of the preexisting bitstreams I have to look for how automated software
> uses the resources provided on the things to give me some ideas...but even
> the obvious capabilities of the FLBs on such a device seem sufficient for
> me to implement the processor I'm after, so I'm not betting too much on
> being able to use existing designs as inspiration.
>         I am inexperienced but I hope to be able to have the chip mostly
> asynchronous and timing worked out by a combination between trial and
> error and eyeballing how I think it ought to work.  I would be surprised
> if I don't develop an intuitive feel for it after a few months of messing
> around on weekends, esp. for such a small FPGA.  I'm certainly not ruling
> out the possibility that I'll never get anything to work right at all on
> it, though.
>         I don't need synthesis because I'll be laying it out like legos: a
> stack here, an adder there -- "oh damn no way to route that, let's scoot
> the adder over" (you /have/ played with legos enough to know the creative
> process, right? -- you don't really get a functional or heirarchical view,
> if you don't have pieces that fit you have to figure out how to do it with
> the pieces you have and if it turns out that you need something to be two
> blocks tall instead of three blocks tall you may well end up rebuilding
> the rest of your lego contraption -- directly analogous to a lack of
> synthesis and place&route software, methinks) -- and attempting to just
> build one processor, not a whole bunch of little things where I need the
> ultimate in flexibility.
>         At any rate, I'd be doing it for my own fun.  I would enjoy failing
> at designing a processor in FPGA from the ground up a lot more than I would
> enjoy succeeding at performing the task with the use of tools that piss me
> off.  I'm very picky about my tools, and I can guarantee you that any
> Windows software targetted at "students" would piss me off at every step
> of the way.
>         I fully expect for someone to reply that I'm stupid to expect the
> commercial world doing all their Important Engineering for Real World
> Tasks involving Large Salaries and Deadlines and all tehse other things
> much too important for a mere college student to understand to give a darn
> about some kid who just wants to fool around...but, well...where did you
> start?  If we couldn't have fun with this stuff, none of us that are any
> good at it would even bother.  If there isn't a version of the chip
> suitable for a kid to mess around with then odds are there won't be any
> adults who really know what they're doing when they mess around with it.
>
> >I would imagine that most of us who design with FPGAs for a living would
> >much rather have the silicon vendors do the hard stuff -- the design
> >software -- so we can get on with our jobs, which is building hardware.
>
> Don't confuse using a tool for doing work.  At any rate, I agree that any
> vendor who doesn't sell synthesis and P&R tools would be doing a
> disservice to a lot of its customer base...but any vendor who makes their
> hardware impossible to use without a specific set of P&R tools is also
> doing a disservice.  Perhaps I have a hcoice between Brand A and Brand B,
> but that isn't any choice at all compared to homegrown.
>         Probably most people who design with FPGAs for a living use them
> simply as limited programmable ASICs.  That's a fine use for them.  I want
> to use them as FPGAs, though.  I have been given the knowledge of what the
> FLBs do and to use them as if they were something else would be
> intolerable for me, at least to start out.  In other words, when I say AND
> gate, I expect an AND gate, but if I say AND gate and I know that it'll
> cleverly transform that into a lookup table in an FLB while attempting to
> cleverly take advantage of the 2 other inputs that the function generator
> affords...that's a lot of work going down behind my back, a lot of
> exciting things happening that I want to be involved in.  Maybe in the end
> my answer isn't nearly as ingenius as what Xilinx's software would have
> come up with...but on the other hand, what if it's 100x better than what
> Xilinx's software would've come up with?  What if it's just as good?
> Unless you know exactly how Xilinx's software works, which I assume
> you don't -- apparently it's not widely published information -- you
> can't have absolute faith in it.  I've been burned by prepackaged software
> often enough that I'm reflexively mistrusting of it -- perhaps you
> reflexively trust it because you've had good experiences with similar
> software or perhaps you just don't care much about how efficient it is
> since you know you don't have the time to do it all by hand so even if it
> does badly, at least it gets the job done.  The point is that neither your
> trust nor my mistrust are justified unless we get the source or at least
> some strong understanding of what's possible, and that's what I'm after.
>
>         Related work:
>         www.ultratechnology.com is the page for a company financed by a
> single individual (some might call him crazy) attempting to finish
> prototyping the F21 Minimal Instruction Set Computing (MISC)
> microprocessor.  Chuck Moore designed the chip from the ground up.  His
> CAD and simulation software were all written by him.  I can't find the
> figures right now but IIRC the object code of his CAD+simulation
> environment was well under 32k.  He didn't do automated layout (though I
> assume that since his CAD software is at basically the same level as his
> programming language that when he had to do repetitive tasks he didn't do
> them by hand) at all.  I think he draws each transistor one at a time.  He
> has working silicon.  You can buy the MuP21 which was developed with the
> same software (I think), and the F21 is most likely only one prototyping
> stage away from working perfectly.
>         Now you're thinking that Chuck Moore is an established
> professional (I think ShBoom/Patriot Scientific 1000 were his work in more
> traditional technology) who spent the last 15 (or more) years of his life
> full time developing that software and those chips -- obviously not a
> valid comparison to me.  However, if I'm working on FPGA then my
> prototyping rounds will take just a few minutes and cost me nothing
> whereas each prototype he developed took months to get back from fab
> and packaging then took all sorts of time to analyze and each and every
> fab run (at least for the f21) was itself an economic crisis for the owner
> of ultratechnology (which is why F21e prototype isn't being fabbed right
> now).  It's apparently a well-established fact that software development
> productivity increases more than linearly as compile/link time decreases
> (eXtreme Programming).  In addition, I won't be starting over totally from
> scratch -- my object code will probably be much larger than 25k and it
> won't be hand-crafted (Chuck Moore invented Forth and his CAD/sim software
> runs on an extremely unique and low-level derivative).  I think these
> advantages should simplify my task by several orders of magnitude and bring
> it into the range of what's feasible for me to complete eventually.
>
>         At any rate, I'd much rather spend my next month banging my head
> on timing issues than trying to reverse-engineer their bitstream,
> something they can be confident their competitors have already done if
> there's any point to it (it's not a very difficult task).
>
> >> Have any of you hardware types ever seriously lived a Linux hacker life?
> >
> >No.  Should I?  And why?  Some of us prefer to be paid for our work.
>
> So do I.  I bet I'll be paid more (no cash involved) than your salary
> affords you if I ever boot up my own little toy processor on FPGA.  I dare
> you to buy that type of satisfaction with your 6-figure salary.  Money is
> not the ends, money is the means.
>         At any rate, hardcore Linux hackers are, almost without exception,
> paid extremely well.  If you can make fantastic technological toys for your
> own edutainment, it shows a lot to a potential employer.  If you would do
> the stuff for the love of doing it, it usually implies greater competence
> than just the random Joe with a degree.
>         My point in asking the question was actually to discover if you
> had seen "the light."  Many programmers can remember the first day they
> allocated more than 64k (or 640k) of RAM without hassling with segments
> or an extended memory manager -- the first time they wrote a program for a
> real 32-bit OS.  Not many of them willingly went back to DOS after that.
> Well I can remember the first time I was exposed to software that was
> broken but that, for the first time, I could fix because I had the
> knowledge and the source code to do so.  I, for one, am not going back.
> Once you realize how much more can be accomplished by cooperation than by
> secrecy and attacks (suing over Patent violations, for example), I can't
> imagine anyone who really loves their art would go back.  If you don't
> give up the love.
>         10 year old closed source software that crashes when you try to
> run it you have no choice but to throw away.  10 year old open source
> software that crashes when you try to run it you can recompile with -g
> (debugging symbols) and load up in gdb (GNU DeBugger) and fix.  Do you
> want to contribute to the trashcan or to someone else's debugging
> nightmare?  I'd prefer my progeny be a cursed debugging nightmare rather
> than a completely useless bitbucket filler.
>
> >Have you gone on tour and mixed live rock bands?  Should you?
>
> If I had the opportunity and the opportunity cost were low (if I could do
> it for just a summer, for example), I would certainly consider doing it.
> If one of my larger goals were to make a better mixer, I'd certainly take
> the opportunity to go out and see how the things are used.  Since your
> goal is to make intellectual property, it seems like you kind of have an
> obligation to yourself to learn how successful people work with
> intellectual property: by sharing.

--
-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: 21463
Subject: Re: Clock nets using non-dedicated resources
From: "Gerard Auclair" <gauclair@odyssee.net>
Date: Wed, 22 Mar 2000 23:38:13 -0500
Links: << >>  << T >>  << A >>
Hi,

try the following:

Under the "Path Filter" menu select "Custom Filters"
and then select either "Select sources" or "Select destination"

Under Source Element Type, select "Clocks"

You will get all signals in your design the tools had identified as clocks.

Hope this help,

Gerard Auclair
Marconi Communications

<boniolopez@my-deja.com> wrote in message
news:8b5mrk$k76$1@nnrp1.deja.com...
> Hi all,
> I'm not very new in FPGA design but I can't find the issue of following
> problem:
>
>
> WARNING:Timing:33 - Clock nets using non-dedicated resources were found
> in this
>    design. Clock skew on these resources will not be automatically
>    during path analysis. To create a timing report that analyzes clock
> skew for
>    these paths, run trce with the '-skew' option.
>
>
>
> I'm quite sure to use in my design the deducted clock resources only
> (and connected to BufG or Buf GP). I think the syntheses tool can'
> recognise some part in my design and form it so, that clock some FF
> with the gated signal. But I cant find where.
>
> THE QUESTION: How I can find out where  the Alliance 2.1i found the non-
> dedicated resources(which signal is such clock)?
>
> Any help will be appreciated,
> Bonio
> Remove_this_Bonio.lopez@gmx.ch_remove_this
>
>
>
> Sent via Deja.com http://www.deja.com/

Article: 21464
Subject: Re: Clock disabling
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 23 Mar 2000 00:05:59 -0500
Links: << >>  << T >>  << A >>
This will not work very well in an FPGA. First of all the AND gate using
a 1 input will be optimized out. Secondly the routing delays will likely
be at least as large as the gate delay, so you will still not be able to
match the delays.

If you are planning on using this chip in two different board designs,
you can use two separate clock input pins. Then one clock can be
disabled by connecting it to ground on the board. No gate needed and you
will have much more closely matched clock routing delays.

Jared Church wrote:
>
> This would creat a skew between the two clocks if you are using both at the
> same time at any point - so you'd probably be better to use a and gate for
> both of them to give a similar delay.
>
> eg
>
> clk1 <= mast_clk and '1' ;
> clk2 <= mast_clk and enable ;
>
> Then define clk1 and clk2 as being clock nets which should go through the
> process of clock tree synthesis which your asic vendor may do for you.
>
> of course then you could have separate enables for each clock if oyu wanted
> as well.
>
> You'd probably want to make sure that the enable was fixed in a certain
> position to avoid glitches from switching the clock on and off - but then
> based on the initial problem you probably wouldn't want to turn one of them
> on and off anyway.
>
> jc
>
> <boniolopez@my-deja.com> wrote in message
> news:8batsh$7pk$1@nnrp1.deja.com...
> >
> >
> > Hi Nicolas,
> > Im not sure if it would good solution and would be glad if Mr. Peter
> > Alfke and other expert comments following:
> > Why not make 2 clock domains one with clk1 and one with clk2.
> > Clk2<=clk1 and enable_from_external_pin;
> > If you make ASIC this should not cause problem, in FPGA place clk2 on
> > secondary buffer (BufG).
> > Correct me, if I am wrong.
> >
> > remove_this_bonio.lopez@gmx.ch_remove_this
> > In article <38D63858.2A94786B@dotcom.fr>,
> > Nicolas Matringe <nicolas@dotcom.fr> wrote:
> > > Hi all
> > > I am working on a design which may be used in two products, one of
> > which
> > > won't need some functions of the design. I don't want to have 2
> > designs
> > > (we won't make 2 ASICs).
> > > I was wondering if it was possible to have 2 clock domains (same
> > > frequency) with the possibility to turn one of them off to reduce
> > power
> > > consumption (this would be done by pulling a pin high or low for
> > > example)
> > > --
> > > Nicolas MATRINGE DotCom S.A.
> > > Conception electronique 16 rue du Moulin des Bruyeres
> > > Tel 00 33 1 46 67 51 11 92400 COURBEVOIE
> > > Fax 00 33 1 46 67 51 01 FRANCE
> > >
> >
> >
> > Sent via Deja.com http://www.deja.com/

--

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: 21465
Subject: Re: FPGA openness
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 23 Mar 2000 00:17:53 -0500
Links: << >>  << T >>  << A >>
...interesting but long rant snipped...
> Sorry for the interruption.  You can now return to the usual fare of
> "Why can't I make the stoopid software tools do what I want" questions.
>
>        - Larry Doolittle  <LRDoolittle@lbl.gov>

LOL, I like your style, Larry. You have converted me and I now agree
that the bitstream specs should be released to the world so that the
greater community can try to make better screwdrivers and hammers and
other tools that have not been thought of yet.

And of course the FPGA vendors can not be blamed for any problems from
using these tools, but that is one of the reasons that they don't want
to see third party tools. They are afraid of the support questions from
it.

FPGA vendors not releasing the bitstream info is a little like a
microprocessor vendor not releasing the binary instruction information.
It's not like any of those freeware compiliers are very good anyway. Gnu
what I mean?  ;)

BTW, why can't I make my FPGA tools do what I want?

--

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: 21466
Subject: Re: Clock nets using non-dedicated resources
From: =?iso-2022-jp?B?GyRCMEIwZhsoQiAbJEI3chsoQg==?= <yasui149@oki.co.jp>
Date: Thu, 23 Mar 2000 14:19:41 +0900
Links: << >>  << T >>  << A >>
Hi,
Let's run trce with -v 1 option.
trce -v 1 -skew design.ncd design.pcf
one detail path will be reported in .twr file. see around  "TS_gpp1_dup0"
constraint. and check the source and destination clock name.

Article: 21467
Subject: Re: FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 23 Mar 2000 05:31:39 GMT
Links: << >>  << T >>  << A >>
In article <38D97E76.2DD0F61D@ids.net>, Ray Andraka wrote:
>Ya know Greg, you can get as close to the hardware as you want with the current
>tools and you'll get up to speed on the gory details of the FPGA a heck of a lot
>faster using the stuff that is already out there, even if it has a few bugs.  You
>have a choice: you can spend all your time figuring out how to connect two CLBs
>together, or you can spend your time actually working with the FPGA and doing
>something with it.

One way to look at it is that I want to drill a single hole in a single
piece of wood and you are pointing out to me how great a drill press is.
Why would I pay the cost of a large featureful system if I don't want the
features?  I don't just mean financial cost, I mean in terms of complexity
and disk space and flexibility.

The other way is that no matter how good, fast, fully-featured, clever,
and bug free that software is and no matter how bad, slow, under-featured,
naive, and buggy my software is (and by "my software" I refer to any
software that I really understand -- it need not be written by me, but I
do need the source), I would much prefer to have my software.

>What you are describing is pretty much the way the first XC2000 software worked
>(and the way the Epic chip editor in the current tools works).  If you want to,
>you can write the equation for every CLB, and manually route the signals between
>them using this tool. In fact, using it you bypass the entire
>schematic/synthesis, translate, map, and place and route flow.  Why, I'll bet the
>guys at NeoCad spent a great deal of time playing with XDE (the chip editor in
>the old XACT tools) before they every wrote their first line of code.  Entering a
>design this way is not for the faint of heart though: it is tedious and error
>prone.  Moving to the capture side, you can still get pretty close to the
>hardware though, all the way down to instantiating exactly the primitive you want
>and where you want it placed.  Granted, that doesn't help you much if you are
>looking for the abiltiy to generate new configurations on the fly.  Fortunately,
>many of the applications for reconfigurability can work with a relatively small
>set of configurations, perhaps with some LUTs twiddled (something that J-Bits is
>good for).  I think before you tried to write your own tools, you'd be wise to
>understand the gory details of the PFGA architecture.  As it is, you seem to feel
>you grok the CLBs well.  It is apparent in you post though, that you don't have
>any understanding of the routing architecture.  The fact of the matter is the
>lion's share of the bits in the bitstream are for setting up the routing
>resources, not for setting the CLB functions.  If you are really serious about
>writing your own tools, I would suggest you work in the chip editor using a long
>series of simple configurations, generate bitstreams for each one and examine the
>differences in the generated bit streams.  With alot of hard work you can get
>something close enough to write bitstreams directly (that's pretty much how

You mean I should reverse-engineer it?  If it's so reasonably trivial to
reverse-engineer it then obviously competitors already have so there's no
point in even trying to keep it proprietary, so they should save me a
little time and just give me the specs.  After all, keeping it closed is
only useful if it never gets reverse-engineered at all, but it's harmful
even if it gets reverse-engineered often.

>  For the $100 bucks (and just one weekend is worth a >heck of a lot more than$100 to me), I think buying the student edition would be
>worth it, if for nothing more than an investigative tool.  It also gives you the
>advantage of being able to work at a higher level to figure out what works well
>and doesn't work well in the FPGA architecture without getting lost in the low
>level detail.  I for one, have done the pip pushing, and I can tell you  that it
>is something I avoid like the plague.  BTW, getting the bitstream format under
>NDA is not exactly unheard of, even for graduate students.

Why should I sign away parts of my future just to get information I should
Article: 21468
Subject: Re: No- FPGA openness
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 23 Mar 2000 00:35:01 -0500
Links: << >>  << T >>  << A >>
Greg Alexander wrote:
> If I knew how to make PC boards without screwing myself over with
> capacitance at high frequencies, I certainly would buy simple PALs, now
> that I know that the FPGA development world doesn't have any interest in
> being my friend. :)  Too bad I don't think I could quite implement an
> entire Forth processor in a single PAL. :)

After reading the excellent post by Larry Doolittle, I have to apologize
to the people requesting the programming information for FPGAs. I think
I was a bit arrogant like many designers who feel that the tools may not
be good, but what could a few individuals do about it?

I understand that you are not trying to show the FPGA companies how to
write better software, although I think that could be done. But rather
you are just trying to get enough information so that you can "play"
with the software and see what kind of ideas you could develop on your
own.

I don't see any reason why this should not be supported. At this point I
don't see why any of the vendors would want to keep their programming
information secret. I think the only reason that they do it is because
the greater FPGA user community does not care enough about it to make an
impact.

--

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: 21469
Subject: Re: Giving fpga's unique id
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 23 Mar 2000 00:47:32 -0500
Links: << >>  << T >>  << A >>
kgbee@my-deja.com wrote:
>
> I have an application which uses up to 16 4028xla's. I would
> like each part to have a unique ID so I can write to that
> part's registers over common address & data buses. One
> way to do this is to daisy chain a 4bit ID value. The 1st
> device gets "0000" using pulldowns. It adds 1 to this
> and sends it to the next part, etc. This takes very little
> logic but does require 8 pins.
> Is there a better way to do this? Can something be done during
> configuration without having to generate many unique bit files?
> Les
>
> Sent via Deja.com http://www.deja.com/

Yes, just have four inputs on each chip. Then hardwire the inputs on

Or you can use a single wire in and one out as a serial version of the
read, increment and output that you have suggested. A single wire can be
used if you indicate a one and a zero with pulse widths and you have a
timing reference in each chip.

--

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: 21470
Subject: Re: Giving fpga's unique id
Date: Wed, 22 Mar 2000 21:52:40 -0800
Links: << >>  << T >>  << A >>
<kgbee@my-deja.com> wrote in message news:8bbtji$bok$1@nnrp1.deja.com...
> I have an application which uses up to 16 4028xla's. I would
> like each part to have a unique ID so I can write to that
> part's registers over common address & data buses. One
> way to do this is to daisy chain a 4bit ID value. The 1st
> device gets "0000" using pulldowns. It adds 1 to this
> and sends it to the next part, etc. This takes very little
> logic but does require 8 pins.
> Is there a better way to do this?

I'm not sure this counts as better, but it's different.  Given that you have
a CPU around anyway, you can have a single bit in and a single bit out (of
each FPGA).  You have the CPU attempt to write "0" to some register in the
FPGAs.  Only the FPGA that has its single bit input set active registers the
write and then sets its address decoders to the "0" you just wrote.  All
FPGAs then shuft the single bit input to their outputs.  The CPU next writes
"1" to the same register, and the 2nd FPGA in the chain picks up this decode
address, the CPU writes "2" for the 3rd FPGA, etc.

You do need software control of the first single bit input, however.  I
don't know how you're configuring these FPGAs, but if possible I'd be
tempted to use something like CClk or DIn for this bit.  Heck, you can cheat
even more and use the FPGA's configuration data output pin as your single
bit output, since there's some fixed number of clocks been the serial data
input and output.  (And then you run the serial data input to a general
purpose I/O pin on the FPGA, since I don't believe the FPGA can read that
pin directly, although I could be wrong here.  Someone should correct me if
so.)

Article: 21471
Subject: Re: Giving fpga's unique id
From: Andreas Doering <doering@iti.mu-luebeck.de>
Date: Thu, 23 Mar 2000 08:31:00 +0100
Links: << >>  << T >>  << A >>
kgbee@my-deja.com wrote:
> Is there a better way to do this? Can something be done during
> configuration without having to generate many unique bit files?
> Les
You can use a boundary-scan user register.
If you instantiate the BSCAN hard macro you get SEL and TDO1/TDO2 and so
forth.
This allows you to implement a custom shift register which can be filled
by the normal BSCAN chain.
If you have BSCAN anyway on your board you need no additional
pins at all.
Andreas

--
---------------------------------------------------------------
Andreas C. Doering
Medizinische Universitaet zu Luebeck
Institut fuer Technische Informatik
Ratzeburger Allee 160
D-23538 Luebeck Germany

Tel.: +49 451 500-3741, Fax: -3687
Email: doering@iti.mu-luebeck.de
Home: http://www.iti.mu-luebeck.de/~doering
quiz, papers, VHDL, music

"The fear of the LORD is the beginning of ... science" (Proverbs 1.7)
----------------------------------------------------------------
Article: 21472
Subject: Re: No- FPGA openness
From: "Kelly Hall" <hall@iname.com>
Date: Wed, 22 Mar 2000 23:41:32 -0800
Links: << >>  << T >>  << A >>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Ben Franchuk" <bfranchuk@jetnet.ab.ca> wrote in message
news:38D95B1F.9B3E2A6@jetnet.ab.ca...
> Does any one use simple PAL's any more for \$.79 each?

Yup - the zero power series from Atmel and the Xilinx nee Philips
Cool Runners are great where you need some logic, save some power,
and minimize board space.

Just because PALs don't get much press any more doesn't mean that no
one is using them.  Kind of like diodes, I guess.

Kelly

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>

iQA/AwUBONnKq+O3tORmHE48EQJE6wCg3+AmF9oFIzWiOsvbtNNhMDpxX4gAoN9O
7OB/EilMrGpMbPcDCgJ8Yo0r
=nE+z
-----END PGP SIGNATURE-----

Article: 21473
Subject: FPGA & single point failure
From: "EDM" <edemarchi@hotmail.com>
Date: Thu, 23 Mar 2000 09:17:51 +0100
Links: << >>  << T >>  << A >>
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: 21474
From: dcp79807@pdp.csie.nctu.edu.tw (Chih-Zong Lin)
Date: 23 Mar 2000 09:10:50 GMT
Links: << >>  << T >>  << A >>

Dear sir:
I am using Virtex XCV600 + CPLD 9536 + EPROM in my design.
The design of Virtex has been finished.

I am wondering is there any source code/binary for CPLD
so that I can use in my design?

Thanks.

Miller