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 21500

Article: 21500
Subject: Re: FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 23 Mar 2000 21:41:09 GMT
Links: << >>  << T >>  << A >>
In article <38da513e@news.ua.pt>, Ruben Leote Mendes wrote:
>Larry Doolittle <ldoolitt@recycle> wrote:
>
>: 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 be a LOT happier too. :)
>
>I already said this in the opencores mailing list but nobody answered so here
>it goes again:
>
>I am willing to help reverse engineer the FPGA bitstreams and help to write
>placing/routing software. I don't have all the necessary skills myself but
>I truly believe that this is not an impossible task if enough people join
>the effort.
>
>If there is enough interest I can setup a mailing list so that we can start
>working on it. First thing to do is look for existing tools. Larry's post
>has very promising links.
>
>Later we will need the existing vendor tools to reverse engineer the tools
>themselves and/or the bitstreams they generate. I have access to several
>tools from different vendors (Xilinx, Altera, Cypress, ...) in my university.
>Of course it would be much better if they released the information and we
>didn't need to waste time reverse engineering it but I am not going to sit
>and wait. 
>
>So if you are crazy enough to try it then send me an email or followup
>in this posting.

I'm not too interested in those tasks (I am not too interested in making
tools for general consumption, at least not as an initial goal).  However,
the job has to some extent already been done:
	http://www.eecg.toronto.edu/~vaughn/vpr/vpr.html
(that link courtesy of Larry Doolittle).
Article: 21501
Subject: Re: FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 23 Mar 2000 21:42:59 GMT
Links: << >>  << T >>  << A >>
In article <38DA5A87.915F601F@ids.net>, Ray Andraka wrote:
>You don't need to use VHDL to enter your design.  You can do it as a schematic,
>even using primitives at the tool front end, or if you go into the EPIC editor, you
>can directly edit (or create) the CLBs and routes without using any of the front
>end tools.  The only thing between the epic output and the bitstream is the
>bitstream converter.  In the old tools (XACT6), you also had an option of writing
>an XNF file directly as an alternative to mainstream design entry tools.  The XNF
>is an ascii text netlist of the CLB cell primitives.  The new tools use a binary
>file instead, so that option is not as available.   Older versions of the new tools
>would read xnf files, but I'm not sure the latest one does.  With these hooks,
>there really isn't anything that the device can do that you can't get to (although
>some of the device features are only available through the editor, like the
>tristate registers in the 4000XLA parts).

First off, even if their software is good and mine is bad, I'd prefer
mine.  I've explained that several times before.

Second off, their software may be capable of doing what I want but my
software will be better -- it will be more suited to my environment and,
more importantly, I will understand it.  Even the most bug-free program
has bugs and I would prefer to have the bugs be in source taht I
understand rather than in source where I'm constantly second-guessing the
author.
Article: 21502
Subject: Re: No- FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 23 Mar 2000 21:47:20 GMT
Links: << >>  << T >>  << A >>
In article <8bdqmn$2e6a$1@noao.edu>, Andy Peters wrote:
>Greg Alexander wrote in message <8bdlam$n6g$2@jetsam.uits.indiana.edu>...
>>In article <8bdifm$22iu$1@noao.edu>, Andy Peters wrote:
>>>Greg Alexander wrote in message <8bbqci$jdq$1@jetsam.uits.indiana.edu>...
>>>>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. :)
>>>
>>>Hey, you hit on something there that you probably don't even realize.
>>>Assume you were able to code your own FPGA development tools, and you've
>got
>>>a bit-stream for your nifty Forth processor, and it fits easily into one
>of
>>>the Xilinx Spartan devices.
>><snip "why don't you design your own board" section>
>>
>>Designing my own board is more out of my reach than designing my own FPGA
>>configuration.  Also, it's not as interesting to me.  I don't want to
>>design a board, I want to design a chip.  I don't want to fight existing
>>software, I want to write my own.  I'm not even too interested in learning
>>from the past because I learned the fun way that it's often a lot of fun
>>to reinvent the wheel without even realizing it ever rolled before.
>
>Well, perhaps you should re-read my post.  Summary: if you don't put the
>FPGA onto a circuit board (and with the edge-rates involved, it won't work
>if done in wire-wrap - been there, done that), the FPGA is useless.

Sorry, I thought you'd read some of my other posts...  I've been
specifically looking at the XS40 board with an XC4005XL, the board is by
XEss and has rather a lot built in and is very inexpensive.  The board is
as open as anything needs to be (they released source to their Windows
tools to upload to/test the board and they released schematics in some
form).

>Unless, of course, your design effort is intended as nothing more than an
>exercise in academic masturbation.  In which case, you'll never really know
>if any of your hard work was worthwhile without building and verifying
>hardware.
>
>Excuse me, a quick rev of one of my FPGAs has finished routing.  I have to
>reprogram the config EEPROM so I can continue testing my actual hardware in
>a real system so we can ship the board to our paying customer who will give
>us real money.

See, here's an application of eXtreme Programming: the productivity
increases MORE THAN LINEARLY as your compile/link time decreases linearly.
You're waiting for your FPGA to route.  Maybe you aren't even waiting very
long.  At any rate, with my software, there would be no interrupting wait
(i.e., the wait would be less than the time it takes you to type the
command, ideally) because it would not be doing intelligent things and
would not need to think.  I bet the increase in productivity won't
make up for the primitiveness of the tools, but it's another thing in my
favor.

	If you abandon complexity, even complexity you think you need to
get the job done, you'll be amazed at how much you can do with so little.
Article: 21503
Subject: Re: FPGA - CPU's
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 23 Mar 2000 21:56:16 GMT
Links: << >>  << T >>  << A >>
In article <38DA7CF3.38971438@jetnet.ab.ca>, Ben Franchuk wrote:
>Andy Peters wrote:
>
>> Well, perhaps you should re-read my post.  Summary: if you don't put the
>> FPGA onto a circuit board (and with the edge-rates involved, it won't work
>> if done in wire-wrap - been there, done that), the FPGA is useless.
>> 
>
>That really depends on the amount of lines with high-speed edge rates.
>If the only line at a high frequency is the master clock wire wrap
>design
>would be as ok.It really boils down to layout and PCB is better at that.

It would be a processor driving VGA and reading SRAM hopefully almost as
fast as the SRAM can go (both the VGA coproc and the instruction fetch
will be accessing the SRAM).  I don't know much about high-frequency
digital design, but I suspect that would be enough to plant me firmly in
the "you'd better do this on PCB" position.  Good thing a cheap PCB has
already been located.

>I really don't see all the advantage of pipe lining cpu's
>if you still have wait for memory as the cpu is now faster
>than memory, and buffering of data and address will give you access
>time of 1/2 the memory speed.

My CPU would not be pipelined.  I don't know enough about the speed of the
various components involved to guess whether it'll be I/O bound, but at
least the RAM on hte board I'm looking at is SRAM, hopefully fast.

>I like forth,but not as a cpu,
>because some data access is still better the standard way,
>like data records.

After writing the below paragraph I'm pretty sure you mean about CPU data
access, but I'll leave the paragraph anyways.  I don't know exactly what
you mean about data records in that case.  There are some things that are
more awkward in a stack CPU but there are plenty of things that are very
awkward in a register CPU too so I consider it a worthwhile tradeoff
(though obviously not for everyone).

In case you're refering to Forth as a language:
	Forth allows the most transparent use of data records of any
language I've ever seen if I get how you mean the phrase: when you make an
array, you typically use CREATE or VARIABLE and then you ALLOT the space
after the variable to hold the data.  Well another hting you can do is
CREATE a word and use DOES> to define what the word does.  You can define
teh word to pop a value off of the stack, multiply it by the record size,
and use it as an offset into the table.  You can define separate words for
each field in your table.  You can make a word look at the incoming text
stream and have it automatically do string-based lookups that way.  It
doesn't have too much built in, but it sure does allow a lot.

	I wouldn't say that forth is for everyone, but enough things are
possible with Forth that don't seem like they should be so easy with such
a simple system (a similar effect as with emergent properties, but not
really) that I consider it at the very least a worthwhile exercise and at
the most a horrible addiction. :)  (I won't be throwing away gcc any time
soon, though, that's for sure)
Article: 21504
Subject: Re: FPGA openness
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 23 Mar 2000 22:01:11 GMT
Links: << >>  << T >>  << A >>
In article <8be1re$nn5$1@jetsam.uits.indiana.edu>,
Greg Alexander <galexand@sietch.bloomington.in.us> wrote:
>>	I don't think your analogy is reasonable.  Even to do a very
>>simple thing on a modern FPGA, you are GOING to want to use the tools
>>provided.  So it's not like "I have to drill a single hole in a block
>>of wood", it's more like "I have to mill away this, this, and this",
>>even for a very simple operation.  So you wolud want to use a milling
>>machine, not just a hand drill.
>
>It's bad enough that Xilinx thinks it knows what tools I want.  Who are
>you?

	A graduate Student at the University of California at
Berkeley, a member of the reconfigurable computing research group at
berkeley.  I'm currently working on alternate FPGA architectures, as
well as architecting a virtex based student project board.

>>>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.
>>
>>	It seems that this is a political and moral issue for you, not
>>just a practical issue.  Practically, the complexity of modern FPGAs
>>and modern tools are such that you won't be able to write the software
>>yourself, or even debug the software.
>
>You seem to think I want to make complex software.  More importantly,
>it's a proven fact that one person can accomplish as much as a team.
>Since I'm redefining the problem, not just the solution, I can take
>significant shortcuts.  I'm not interested in making a full-featured
>development environment to sell.

	The modern FPGAs are complex targets, some large level of
complexity will be required.  And, if you concentrate on just one part
of the problem (EG, better placement mechanisms), the available tools
are modular ensugh that it is reasonable to start with the existing
flows and add in your new passes and operations.

	Also, there are a fair number of research software which is
freely available, such as VPR.  However, these are generally oriented
towards much simpler, abstracted devices.

	Oh, and have you read xapp 151?
http://www.xilinx.com/xapp/xapp151.pdf
	It has a lot of information on various parts of the virtex
bitstream.  Not everything you want (it leaves out a lot of info on
what the routing bits do/represent), but it is a good guideline to
start with, and includes info about frame organization, CRC coding,
etc.

-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
Article: 21505
Subject: Re: FPGA openness
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 23 Mar 2000 22:17:16 GMT
Links: << >>  << T >>  << A >>
"Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> writes:

>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)?

Well, there are other possibilities.  One is that he might want to use
an available, maybe open-source, synthesis/place/route/timing analyzer tool,
and only need to write the final step, converting the result into
a bits file.  Now, for that case he can probably get away with generating
the lca file and running makebits on that.  It would be nice to have a
linux makebits, though.

A project that I was working on before, though since have gone onto
other projects, would have needed to know where some bits were.

I was working on a systolic array processor, which contained a linear 
array of Xilinx chips, or would have if we had built it.  Each chip
would have the same logic, but the constants would change.  Some in
what xilinx would call ROM, but more like PROM.  Each chip would initialize
with different values.  I also needed to be able to change the bits
of an adder.  Most of the logic was adding constants and comparing the 
results.  By building constant adders, and changing the constants by
changing the LUT values and carry logic bits, I could have built such
logic in a much smaller space than most other ways of getting the constants
in.  A system might have had hundreds of Xilinx chips in an array, so
logic minimization was important.  (Actually speed/chips, I had to be
careful with the routing.)

I actually had some results from ppr before the decision to do the project
differently (using ASICs) came through.

>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.

Well, consider Linux and Windows.  While many people are happy with 
Windows, it is nice that some people aren't, and want to work on other
operating systems.  Consider how it would be if Intel didn't publish
the instruction set of their processors, and someone wanted to port Linux
to it?  You could ask why we weren't happy with the software that Intel
provides (they used to actually sell software for their chips) or that
Microsoft provides.  I actually would be interested in working on
place and route software for FPGA's.  Xilinx does provide a lot of 
information about the chips, probably enough to do synthesis, place and
route, and timing analysis, so that one could probably write all the
way up to, but not including, makebits.

>> 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?

I won't argue with this one.

-- glen
Article: 21506
Subject: Re: FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 23 Mar 2000 22:29:01 GMT
Links: << >>  << T >>  << A >>
In article <8be477$nla$1@agate.berkeley.edu>, Nicholas C. Weaver wrote:
>In article <8be1re$nn5$1@jetsam.uits.indiana.edu>,
>Greg Alexander <galexand@sietch.bloomington.in.us> wrote:
>>>	I don't think your analogy is reasonable.  Even to do a very
>>>simple thing on a modern FPGA, you are GOING to want to use the tools
>>>provided.  So it's not like "I have to drill a single hole in a block
>>>of wood", it's more like "I have to mill away this, this, and this",
>>>even for a very simple operation.  So you wolud want to use a milling
>>>machine, not just a hand drill.
>>
>>It's bad enough that Xilinx thinks it knows what tools I want.  Who are
>>you?
>
>	A graduate Student at the University of California at
>Berkeley, a member of the reconfigurable computing research group at
>berkeley.  I'm currently working on alternate FPGA architectures, as
>well as architecting a virtex based student project board.
>
>>>>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.
>>>
>>>	It seems that this is a political and moral issue for you, not
>>>just a practical issue.  Practically, the complexity of modern FPGAs
>>>and modern tools are such that you won't be able to write the software
>>>yourself, or even debug the software.
>>
>>You seem to think I want to make complex software.  More importantly,
>>it's a proven fact that one person can accomplish as much as a team.
>>Since I'm redefining the problem, not just the solution, I can take
>>significant shortcuts.  I'm not interested in making a full-featured
>>development environment to sell.
>
>	The modern FPGAs are complex targets, some large level of
>complexity will be required.  And, if you concentrate on just one part
>of the problem (EG, better placement mechanisms), the available tools
>are modular ensugh that it is reasonable to start with the existing
>flows and add in your new passes and operations.

I don't want any form of automatic placement software.  More importantly,
they aren't modular enough.  To really be modular you need to be able to pick
them up and take them somewhere else and use them there.  In other words,
they need to be compiled to machine-independent byte code (i.e. Java) or
source needs to be provided.  A module that's not portable is not very
modular.

>	Also, there are a fair number of research software which is
>freely available, such as VPR.  However, these are generally oriented
>towards much simpler, abstracted devices.

VPR is unusable because it doesn't seem to be possible to use it to
generate bitstreams for the FPGAs I want (if any).

>	Oh, and have you read xapp 151?
>http://www.xilinx.com/xapp/xapp151.pdf
>	It has a lot of information on various parts of the virtex
>bitstream.  Not everything you want (it leaves out a lot of info on
>what the routing bits do/represent), but it is a good guideline to
>start with, and includes info about frame organization, CRC coding,
>etc.

Yes, but without routing I'm kind of screwed.  Do you know if any similar
documents exist with info about the XC4000XL family?
Article: 21507
Subject: Re: FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 23 Mar 2000 22:37:15 GMT
Links: << >>  << T >>  << A >>
In article <8be55c$kcl@gap.cco.caltech.edu>, glen herrmannsfeldt wrote:
>"Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> writes:
>
>>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)?
>
>Well, there are other possibilities.  One is that he might want to use
>an available, maybe open-source, synthesis/place/route/timing analyzer tool,
>and only need to write the final step, converting the result into
>a bits file.  Now, for that case he can probably get away with generating
>the lca file and running makebits on that.  It would be nice to have a
>linux makebits, though.

That wasn't really my intention, but now that I have seen VPR it has been
an option I've considered.  Is makebits free?  If makebits is free and I
can get it to work somehow from a Linux comandline (if that's really all I
need then I will put up with the hassle of DOSemu or even WinE), I'll buy
a chip. :)
	As I understand it makebits is a tiny tiny program, and is at
almost hte same level as I was originally refering to as "write something
up in a couple weekends" (reads in some intelligible/standardized format
and converts it almost directly into bitstream).  Is this correct?

<snip>
>>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.
>
>Well, consider Linux and Windows.  While many people are happy with 
>Windows, it is nice that some people aren't, and want to work on other
>operating systems.  Consider how it would be if Intel didn't publish
>the instruction set of their processors, and someone wanted to port Linux
>to it?  You could ask why we weren't happy with the software that Intel
>provides (they used to actually sell software for their chips) or that
>Microsoft provides.  I actually would be interested in working on
>place and route software for FPGA's.  Xilinx does provide a lot of 
>information about the chips, probably enough to do synthesis, place and
>route, and timing analysis, so that one could probably write all the
>way up to, but not including, makebits.

In a quick skim I didn't find enough info for timing analysis.  Could you
point me in the right direction?  It was them providing me with enough
information to do manual place and route that made me want to know the
bitstream so badly -- once I knew what the FPGA actually was there was
just no way that I could even consider programming it in VHDL (at least
not for initial entertainment-targetted projects).  If I wasn't bothering
with VHDL then I really have no interest in their software.  Why would I
buy and install a huge software package if all I want is a (most likely
TINY) makebits program?
Article: 21508
Subject: Re: FPGA openness
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 23 Mar 2000 23:03:28 GMT
Links: << >>  << T >>  << A >>
Brian Drummond <brian@shapes.demon.co.uk> writes:

(snip.  If you don't know how we got here, read the other posts.)

>You're right! Get yourself a TTL Data Book, a soldering iron (or
>wire-wrap gun), a bag of 74LSTTL, a good scope and get busy. Good
>experience, nothing secretive or inaccessible there, and precious little
>investment either. (hey you did ask .... only it was straight 74TTL back
>then!)

A few years ago, I thought about exactly this problem.  When I was
growing up, and apparently you, too, we had 74xx TTL to play with.
The reason we had that, at $0.25/chip, was that computer makers were
buying it in large quantities.  Now that computers are made with VLSI,
and are more and more integrated, will those TTL chips still be available?

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
Article: 21509
Subject: Re: FPGA openness
From: Ray Andraka <randraka@ids.net>
Date: Thu, 23 Mar 2000 23:23:38 GMT
Links: << >>  << T >>  << A >>
Greg,

Out of curiousity, about how many FPGA designs have you done?

Greg Alexander wrote:

> In article <9nfkdssa8jmmqgecu3kad1p4f5625pnjvg@4ax.com>, Brian Drummond wrote:
> >On 22 Mar 2000 23:26:45 GMT, galexand@sietch.bloomington.in.us (Greg
> >Alexander) wrote:
> >
> >>      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
> >[...]  Hopefully a converter
> >>to/from the bitstream and the simple text format would take me a couple
> >>weekends...nothing too special..
> >
> >There is no way...
>
> Oh bullshit.  Don't be telling me what I can and cannot do unless you're
> also going to tell me how to do what you don't think I can do without
> your help.  Otherwise you're exercising arrogance or ignorance or similar,
> and certainly not contributing anything useful.  If you stop me from
> trying, what will you have accomplished?
>
> >>      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.
> >
> >You needn't use them via the Windows interface if you don't want to,
> >they work equally well from the command line. (and I believe,  work
> >under Linux?)
>
> Not officially, at least.  You can get them to run under Wine apparently
> but why pay for software that I will only be able to run sketchily at best
> that I blatantly DO NOT WANT?
>
> >>      I don't need synthesis because I'll be laying it out like legos: a
> >>stack here, an adder there --
> >
> >ok...
> >
> >one of the major back-end tasks is placement. Given a really good
> >placement, most of the other back-end tasks run pretty smoothly...
> >routing can be an order of magnitude faster, and the finished design can
> >be 30% faster... Currently the best way of placing logic is to use the
> >floorplanner, which is a graphical tool to allow you to place logic by
> >hand, using the hierarchy derived from the EDIF input file as a guide.
> >Yet the Xilinx floorplanner is relatively weak.
> >
> >Someone could add a LOT of value by writing a decent placement tool that
> >reads the input to the floorplanner (.fnf) file, performs an intelligent
> >placement, and writes a file in floorplanner output format (.mfp).
> >Both these files are pure ASCII (last time I looked ... in search of a
> >MAP/floorplanner bug! ) and the floorplanner or your replacement can be
> >seamlessly integrated into the design flow from a script or a batch
> >file.
> >
> >This is a significant part of the whole process, with (it looks to me)
> >an easy way in for an open source effort. That is ... an easy interface,
> >which makes the task a self-contained problem. I'm not saying the task
> >itself is easy!
> >
> >It's a classic problem that will soak up all the ingenuity you can throw
> >at it. If your tool can't place all the logic, the PAR tool will happily
> >place the rest, so you don't have to solve the whole problem at once.
> >
> >And the benefits of using your tool (or otherwise) are easily measured
> >by comparing both place&route times, and the speed of the finished
> >device, with an un-floorplanned place and route.
>
> I have no interest in making software for other people as part of this
> project.  I want to write the software necessary to do my own work and no
> more or less.  I'm not looking for weaknesses in existing software to let
> me get my foot in the door, I simply have no interest at all in the
> existing software (unless it's open source,t hen I could understand it and
> make it my own).
>
> >Now there's a challenge to the open-source folks!
> >
> >An open-source router would be more difficult, unless Xilinx documented
> >the .NCD file format. They go some way toward this by providing an NCD
> >to ASCII file reader ncdread.exe (but no tool that does the reverse).
> >Maybe they could be persuaded to document this format if (say) the open
> >source community showed they were serious by cracking the placement
> >problem? Peter?
>
> No, I stand firmly by my current judgement that Xilinx doesn't give a hoot
> about product quality, they just want to sell 'em.
>
> >Which would only leave the relatively small Bitgen as a proprietary
> >tool. I could live with that!
>
> No, becasue bitgen is small and simple and I could write something vageuly
> similar in a few weekends, yet i'd be paying significant money for it and
> keeping around significant bloat on my disk for it.  No thanks.
>
> >>      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.
> >
> >You're right! Get yourself a TTL Data Book, a soldering iron (or
> >wire-wrap gun), a bag of 74LSTTL, a good scope and get busy. Good
> >experience, nothing secretive or inaccessible there, and precious little
> >investment either. (hey you did ask .... only it was straight 74TTL back
> >then!)
>
> heh.  I was going for FPGA because it's convenient: relatively
> inexpensive, relatively high speed (so I can drive video, for
> example...I'm not sure what the limiters with discrete logic are, but I'm
> not confident you can drive video like that easily), much easier to
> prototype, etc.  I only looked into FPGAs recently because a browse of a
> Xilinx datasheet revealed how convenient the things should be to program.
>
> >>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.
> >
> >Now if THAT's the issue then I think you can use Xilinx software and
> >sleep a little more easily.
> >
> >Because everything up to the final bit file is visible in excruciating
> >detail, if you really _want_ to look at it. e.g. using FPGA Editor or
> >ncdread...
>
> Why would I waste my time second-checking their work when I could waste my
> time second-checking my own?
>
> >The only step between the .ncd file and the bitstream is a 6k program
> >called bitgen.exe. In every other step, at least you can inspect the
> >results and see what it's doing. But you rarely need to...
>
> If it's really only 6k then I could probably reverse-engineer it with
> DEBUG.EXE :)

--
-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: 21510
Subject: StateCAD
From: "Domagoj" <Domagoj@engineer.com>
Date: Fri, 24 Mar 2000 00:29:02 +0100
Links: << >>  << T >>  << A >>
Hi,
 What do you think about StateCAD ?
Is it worth to spend some time to learn it,
and does it pay off ? Is it mostly used for
simulation or synthesis ?
Thanks.
--

-------------------------------------------
-             Domagoj              -
- Domagoj@engineer.com -
-------------------------------------------


Article: 21511
Subject: Re: FPGA openness
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Thu, 23 Mar 2000 17:06:01 -0700
Links: << >>  << T >>  << A >>
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.
> 

The problem is that a FPGA is not a visible device,
You can't stick a logic probe and say why is that not the right logic 
level.  I Don't think the FPGA manufactures have tiny LED's blinking
away
on the chips with a teany-weeny front panel.

I tend to find that for my design work ( very little )
the FPGA logic blocks never quite fit well, with odd sizes
... 6 input nand gate, or ALU block. The logic blocks are too
much of a black art... ops black box to flow data flow around.
Some day I will design that cpu, but not from FPGA's as
find them over kill in use of logic blocks for random logic.
Ben.
 
-- 
"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: 21512
Subject: debugger
From: Anurag Tiwari <atiwari@cs.wright.edu>
Date: Thu, 23 Mar 2000 21:01:13 -0500
Links: << >>  << T >>  << A >>

Hi

Is there any good tool available for Symbolic debugging of FPGA designs
using Readback and clk stepping/stopping and if could co-simulate the
Software and the Hardware together using the same tool to debug software
and harware simultaneously.

AT


Article: 21513
Subject: Re: FPGA openness
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Fri, 24 Mar 2000 02:03:40 +0000
Links: << >>  << T >>  << A >>
On Thu, 23 Mar 2000 09:38:57 -0700, Ben Franchuk
<bfranchuk@jetnet.ab.ca> wrote:

>Brian Drummond wrote:
>> 
>> You're right! Get yourself a TTL Data Book, a soldering iron (or
>> wire-wrap gun), a bag of 74LSTTL, a good scope and get busy.
>
> Well DAMIT they don't make TTL any more. Well not the more complex
>stuff anymore as that is being phased out. Soon all that will be left
>are a few buffers and latches.

Good point...
I was startled by one manufacturer's linecard a couple of years back
which included the following gem...

"Logic: Not recommended for new designs."

No comment!

- Brian
Article: 21514
Subject: SPLD Usage ?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 24 Mar 2000 14:49:57 +1200
Links: << >>  << T >>  << A >>
The side comment below, and others, lead me to ask :

- What broad uses are SPLD devices being put to ?

- What's the most PLD you have used in 1 system ?


Looking back on the last few projects where we used SPLD
the solutions were rather more diverse than the 'memory decoder'
examples these were targeted at originally.

 Here are some to start the examples rolling
- 24 Pin PLD as TxUART/Buffer. Chained 25 on one PCB.
   ( Was lower cost than any UART solution )

- 20 Pin 0.67c PLD used as ADC/DAC, alongside 20 pin uC

- 24 Pin PLD used as LED drive, and Button Scan.
  Using saturating counters, this can be squeezed into
  a 3 wire protocal.

Jim G.


glen herrmannsfeldt wrote:
> 
> Brian Drummond <brian@shapes.demon.co.uk> writes:
> 
> (snip - openness thread )
> 
> >You're right! Get yourself a TTL Data Book, a soldering iron (or
> >wire-wrap gun), a bag of 74LSTTL, a good scope and get busy. Good
> >experience, nothing secretive or inaccessible there, and precious little
> >investment either. (hey you did ask .... only it was straight 74TTL back
> >then!)
> 
> A few years ago, I thought about exactly this problem.  When I was
> growing up, and apparently you, too, we had 74xx TTL to play with.
> The reason we had that, at $0.25/chip, was that computer makers were
> buying it in large quantities.  Now that computers are made with VLSI,
> and are more and more integrated, will those TTL chips still be available?

The 'lowly' logic market remains $2B (!) in size.
Certainly some tail end LOGICs are being EOL'd, ( as are tail end
FPGA's,
many years sooner than their LOGIC counteparts ! ).

Interesting new devices are the single gate logics.

> 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.

Why not start teaching with SPLD ?
A DIP package is still very learner friendly, and slip proof.

In the days before $3 Flash uC, I recall hearing the problems with 
students frying the $90US windowed devices.
A TQFP FPGA device looks to have the same problem ?
Article: 21515
Subject: Re: How to solder FPGA in BGA package ?
From: steve (Steve Rencontre)
Date: Fri, 24 Mar 2000 03:00 +0000 (GMT Standard Time)
Links: << >>  << T >>  << A >>
In article <8ba0t1$7u2$1@nnrp1.deja.com>, rob_dickinson@my-deja.com () 
wrote:

[most snipped]

> if your
> going to build more than a few then get to grips with designing jtag
> into your system from the floor up, ie don't finish your design and
> then wonder how to add jtag.

Tough if you've got something like an Intel 82259 Ethernet chip with a 
totally useless NAND-tree test mode instead of JTAG :-(((

--
Steve Rencontre, Design Consultant
http://www.rsn-tech.demon.co.uk
Article: 21516
Subject: Re: No- FPGA openness
From: Catalin Baetoniu <starnet@home.com>
Date: Fri, 24 Mar 2000 04:06:31 GMT
Links: << >>  << T >>  << A >>
Hi Greg,

I read with interest (and some disbelief too) your posts. You must
understand that this is a hardware newsgroup and you look at the problem
from a software perspective. 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. Another major difference
is that software is usually sequential while inside the FPGA everything
happens in parallel. We are also fighting things like set-up and hold
time problems, ground bounce, noise, asynchronous logic glitches,
metastability. In the eleven years I spent designing with FPGAs I found
my share (a rather large one) of bugs in the software tools but in the
end the limiting factor was always my own capacity to design well and
not the tools themselves. The fact that the tools are closed/open source
or run on Windows/Unix/Linux has no relevance at all for me (and
probably for most of the people in this newsgroup). While the Xilinx
software has lots of bugs (anybody that knows of any bug free software
raise your hand now) the company is making a tremendous effort of
documenting and solving them - the Xilinx Online Answers Database is
more important to me than any open source effort. 

The issue of the proprietary nature of the Xilinx bitstream never dies
in this newsgroup. Even in this thread offers and ideas of
reverse-enginnering the bitstream format were mentioned. However I think
this is a false problem (unless you really want to steal somebody else's
design). The important data format is not the bit file format (what you
download into your FPGA) but the ncd format (the placed and routed FPGA
data file). The problem here is not that the bit format is unknown but
that you can go from ncd to bit (using bitgen) but not the other way
around. And the ncd format is _open_. You can write whatever place and
route program you want and you can generate your own ncd files _without_
using Xilinx software. 

If your problem is you cannot stand Windows then you have to wait until
Xilinx ports their tools to Linux - I wouldn't hold my breath until
then. If you are really serious about doing FPGA design from scratch you
can start right now - all you need is bitgen.exe, xdl.exe and all the
relevant data files for your target FPGA. XDL is a tool Xilinx
distributes but does not document that enables you to translate ncd
format files (binary) to xdl format (ASCII) _and_ also xdl to ncd. You
might even be able to run bitgen and xdl in Linux using some DOS
emulator and you definitely do not need Windows. Add your vi editor, a
couple of years of very hard work and there you are. In the process do
not forget to avoid asynchronous design, register all your input and
output signals in your IOBs and use at least two FFs in series when you
cross a clock domain boundary. And do not rely on eyeballing, in
hardware design it doesn't work ;-). 

And yes, I think that Xilinx should distribute bitgen, xdl and all the
required data files free, publish the XDL file format and keep the
bitstream format proprietary. 

Regards,
Catalin Baetoniu

Greg Alexander wrote:
> 
> In article <8bdqmn$2e6a$1@noao.edu>, Andy Peters wrote:
> >Greg Alexander wrote in message <8bdlam$n6g$2@jetsam.uits.indiana.edu>...
> >>In article <8bdifm$22iu$1@noao.edu>, Andy Peters wrote:
> >>>Greg Alexander wrote in message <8bbqci$jdq$1@jetsam.uits.indiana.edu>...
> >>>>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. :)
> >>>
> >>>Hey, you hit on something there that you probably don't even realize.
> >>>Assume you were able to code your own FPGA development tools, and you've
> >got
> >>>a bit-stream for your nifty Forth processor, and it fits easily into one
> >of
> >>>the Xilinx Spartan devices.
> >><snip "why don't you design your own board" section>
> >>
> >>Designing my own board is more out of my reach than designing my own FPGA
> >>configuration.  Also, it's not as interesting to me.  I don't want to
> >>design a board, I want to design a chip.  I don't want to fight existing
> >>software, I want to write my own.  I'm not even too interested in learning
> >>from the past because I learned the fun way that it's often a lot of fun
> >>to reinvent the wheel without even realizing it ever rolled before.
> >
> >Well, perhaps you should re-read my post.  Summary: if you don't put the
> >FPGA onto a circuit board (and with the edge-rates involved, it won't work
> >if done in wire-wrap - been there, done that), the FPGA is useless.
> 
> Sorry, I thought you'd read some of my other posts...  I've been
> specifically looking at the XS40 board with an XC4005XL, the board is by
> XEss and has rather a lot built in and is very inexpensive.  The board is
> as open as anything needs to be (they released source to their Windows
> tools to upload to/test the board and they released schematics in some
> form).
> 
> >Unless, of course, your design effort is intended as nothing more than an
> >exercise in academic masturbation.  In which case, you'll never really know
> >if any of your hard work was worthwhile without building and verifying
> >hardware.
> >
> >Excuse me, a quick rev of one of my FPGAs has finished routing.  I have to
> >reprogram the config EEPROM so I can continue testing my actual hardware in
> >a real system so we can ship the board to our paying customer who will give
> >us real money.
> 
> See, here's an application of eXtreme Programming: the productivity
> increases MORE THAN LINEARLY as your compile/link time decreases linearly.
> You're waiting for your FPGA to route.  Maybe you aren't even waiting very
> long.  At any rate, with my software, there would be no interrupting wait
> (i.e., the wait would be less than the time it takes you to type the
> command, ideally) because it would not be doing intelligent things and
> would not need to think.  I bet the increase in productivity won't
> make up for the primitiveness of the tools, but it's another thing in my
> favor.
> 
>         If you abandon complexity, even complexity you think you need to
> get the job done, you'll be amazed at how much you can do with so little.
Article: 21517
Subject: ERROR:NgdHelpers:312
From: "J.R." <j_robby@hotmail.com>
Date: Fri, 24 Mar 2000 07:12:45 -0000
Links: << >>  << T >>  << A >>
Hi Folks,

I am using Foundation 2.1i& Synopsys FPGA compiler II.
When I exported the .xnf file of a VHDL design into design manager, I got
the following error:
/***
ERROR:NgdHelpers:312 - logical block "inst11_inst111_inst1113" of type
   "BLK_1113" is unexpanded.
**/
This problem occurs for the components in which I used 'generic' in their
VHDL description.
Below is a sample code.
Any help is much appreciated.


/**** SAMPLE CODE ****/
entity BLK_1113 is
    generic(Proc_width : integer :=14);
port

IP_S,IN_S,CLK,CLR, MODE_IN: IN std_logic;
DOUT : buffer std_logic_vector(1 to Proc_width);
MODE_OUT : out std_logic
);
end BLK_1113;
architecture Arch_BLK_1113 of BLK_1113 is
signal A,B : std_logic_vector(Proc_width downto 1);
signal IN_EQ_p1 ,IN_EQ_m1 ,A15_IN,B15_IN : std_logic;

begin

process(mode_in,CLK,clr)
begin
if (CLR='1') then

for i in Proc_width downto 1 loop
A(i) <= '0';
B(i) <= '0';
DOUT(i) <='0';
end loop;

else
if(CLK='1' and (not CLK'stable)) then
if(mode_in='1') then
for i in Proc_width downto 1 loop
DOUT(i) <= A(i);
end loop;

else
 DOUT(Proc_width)<=A(Proc_width);

for i in 1 to Proc_width-1 loop
DOUT(i) <= DOUT(i+1);
end loop;
end if;

if(IN_EQ_p1='1') then
B(Proc_width)<='0';
for i in 1 to Proc_width-2 loop
B(i) <= A(i+1);
end loop;

else
B(Proc_width)<=B15_IN;
for i in 1 to Proc_width-2 loop
B(i) <= B(i+1);
end loop;

end if;

if(IN_EQ_m1='1') then
A(Proc_width)<='1'; --- CHECK IT OUT
for i in 1 to Proc_width-2 loop
A(i) <= B(i+1);
end loop;
else
A(Proc_width)<=A15_IN;
for i in 1 to Proc_width-2 loop
A(i) <= A(i+1);
end loop;
end if;
MODE_OUT <= MODE_IN;
end if;
end if;
end process;

IN_EQ_p1 <= IP_S and (not IN_S);
IN_EQ_m1 <= IN_S and (not IP_S);
B15_IN   <= not(IN_S xor IP_S);
A15_IN   <= IN_S xor IP_S;

end Arch_BLK_1113;

/****************************/


Article: 21518
Subject: Re: No- FPGA openness
From: eml@riverside-machines.com.NOSPAM
Date: Fri, 24 Mar 2000 08:57:21 GMT
Links: << >>  << T >>  << A >>
On 23 Mar 2000 21:47:20 GMT, galexand@sietch.bloomington.in.us (Greg
Alexander) wrote:

>Sorry, I thought you'd read some of my other posts...  

Are you serious? There are a lot of good, professional, engineers in
this NG. Sometimes it pays to read, and not write. It also reduces the
S/N.

Evan

Article: 21519
Subject: Re: FPGA openness
From: Andreas Doering <doering@iti.mu-luebeck.de>
Date: Fri, 24 Mar 2000 09:58:04 +0100
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> The new tools use a binary
> file instead, so that option is not as available.  
But the new tools have XDL, which is a low level ASCII 
representation of an NCD - including routing

Greg Alexander wrote:
> Even the most bug-free program
> has bugs and I would prefer to have the bugs be in source taht I
> understand rather than in source where I'm constantly second-guessing the
> author.
In my experience the way from XDL - bitgen -> device 
is nearly bug free. Greg has all options to start from this point.

I think, you (Greg) should start with that and roll your own tools 
down to XDL. If you are there, you can still start looking around
for the bitgen option. 
I guess that final step is than not hard anymore. 
And maybe you have convinced XILINX by then that free tools 
are so superior that it is worth allowing the free tool geniusses to 
support their chips.

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: 21520
Subject: Re: FPGA openness
From: eml@riverside-machines.com.NOSPAM
Date: Fri, 24 Mar 2000 09:01:36 GMT
Links: << >>  << T >>  << A >>
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.

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: 21521
Subject: Re: FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 24 Mar 2000 10:08:09 GMT
Links: << >>  << T >>  << A >>
In article <38DAA773.E8A07BF5@ids.net>, Ray Andraka wrote:
>Greg,
>
>Out of curiousity, about how many FPGA designs have you done?

Obviously 0.  I'm trying to find the information to get started.
Out of curiosity, do you really think that people are all as limited as
people who know what the limits are supposed to be?
Article: 21522
Subject: Re: No- FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 24 Mar 2000 10:15:46 GMT
Links: << >>  << T >>  << A >>
In article <38DAE9AA.4B3504E9@home.com>, Catalin Baetoniu wrote:
>Hi Greg,
>
>I read with interest (and some disbelief too) your posts. You must
>understand that this is a hardware newsgroup and you look at the problem
>from a software perspective. 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. Another major difference
>is that software is usually sequential while inside the FPGA everything
>happens in parallel. We are also fighting things like set-up and hold
>time problems, ground bounce, noise, asynchronous logic glitches,
>metastability. In the eleven years I spent designing with FPGAs I found

This is where eXtreme Programming principles helps me: my compile time
will be about 1 second (how long does it take bitgen to run?) so I can try
and try again.  I can test each part individually directly tied to IOBs
then if it breaks when I add an adder to the chip I know where the problem
is.

>my share (a rather large one) of bugs in the software tools but in the
>end the limiting factor was always my own capacity to design well and
>not the tools themselves. The fact that the tools are closed/open source
>or run on Windows/Unix/Linux has no relevance at all for me (and
>probably for most of the people in this newsgroup). While the Xilinx
>software has lots of bugs (anybody that knows of any bug free software
>raise your hand now) the company is making a tremendous effort of
>documenting and solving them - the Xilinx Online Answers Database is
>more important to me than any open source effort. 
>
>The issue of the proprietary nature of the Xilinx bitstream never dies
>in this newsgroup. Even in this thread offers and ideas of
>reverse-enginnering the bitstream format were mentioned. However I think
>this is a false problem (unless you really want to steal somebody else's
>design). The important data format is not the bit file format (what you
>download into your FPGA) but the ncd format (the placed and routed FPGA
>data file). The problem here is not that the bit format is unknown but
>that you can go from ncd to bit (using bitgen) but not the other way
>around. And the ncd format is _open_. You can write whatever place and
>route program you want and you can generate your own ncd files _without_
>using Xilinx software. 
>
>If your problem is you cannot stand Windows then you have to wait until
>Xilinx ports their tools to Linux - I wouldn't hold my breath until
>then. If you are really serious about doing FPGA design from scratch you
>can start right now - all you need is bitgen.exe, xdl.exe and all the
>relevant data files for your target FPGA. XDL is a tool Xilinx
>distributes but does not document that enables you to translate ncd
>format files (binary) to xdl format (ASCII) _and_ also xdl to ncd. You
>might even be able to run bitgen and xdl in Linux using some DOS
>emulator and you definitely do not need Windows. Add your vi editor, a
>couple of years of very hard work and there you are. In the process do
>not forget to avoid asynchronous design, register all your input and
>output signals in your IOBs and use at least two FFs in series when you
>cross a clock domain boundary. And do not rely on eyeballing, in
>hardware design it doesn't work ;-). 
>
>And yes, I think that Xilinx should distribute bitgen, xdl and all the
>required data files free, publish the XDL file format and keep the
>bitstream format proprietary. 

I don't want them to port their tools -- that will never happen because I
don't want programs that run in Linux, I want programs written for Linux
hackers -- i.e., open programs.  But if they just ported bitgen and made
it available for free, that would be all that i really need or expect from
them.  For example, if I could get bitgen (which is the only program I've
claimed to be able to write -- it is very simple as I understand it) then
I would even be willing to accept the hassle of setting up dosemu to run
it from the linux commandline.  But why would I want to get some
multi-megabyte package just for bitgen?
Article: 21523
Subject: Re: No- FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 24 Mar 2000 10:20:23 GMT
Links: << >>  << T >>  << A >>
In article <38db2d65.178191536@news.dial.pipex.com>,
eml@riverside-machines.com.NOSPAM wrote:
>On 23 Mar 2000 21:47:20 GMT, galexand@sietch.bloomington.in.us (Greg
>Alexander) wrote:
>
>>Sorry, I thought you'd read some of my other posts...  
>
>Are you serious? There are a lot of good, professional, engineers in
>this NG. Sometimes it pays to read, and not write. It also reduces the
>S/N.

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.
	Everyone here takes the title professional too seriously.  In the
software movement we've learned that professional means that you're
managed by someone probably incompetent and that your software is released
not when it's done but when the management says it needs to be done -- not
a purely positive status (though there are advantages I guess).  In the
hardware world you guys seem to still think that professional is a
bonus just because you can't afford to do chip or PCB fab with your own
money.
Article: 21524
Subject: Re: FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 24 Mar 2000 10:23:06 GMT
Links: << >>  << T >>  << A >>
In article <38DB2E1C.77F3524E@iti.mu-luebeck.de>, Andreas Doering wrote:
>Ray Andraka wrote:
>> The new tools use a binary
>> file instead, so that option is not as available.  
>But the new tools have XDL, which is a low level ASCII 
>representation of an NCD - including routing
>
>Greg Alexander wrote:
>> Even the most bug-free program
>> has bugs and I would prefer to have the bugs be in source taht I
>> understand rather than in source where I'm constantly second-guessing the
>> author.
>In my experience the way from XDL - bitgen -> device 
>is nearly bug free. Greg has all options to start from this point.
>
>I think, you (Greg) should start with that and roll your own tools 
>down to XDL. If you are there, you can still start looking around
>for the bitgen option. 
>I guess that final step is than not hard anymore. 

I would agree, but that is a tiny tiny piece of software, why would I pay
so much money for it?  More importantly, I'll never achieve satisfaction
with that software, I'll always be running it through DOSemu and I'll
never quite understand how it works.  There'll always be a nagging
suspicion that perhaps it's buggy or similar.  If you work with
proprietary software on a daily basis you are completely used to the
suspicion, you don't even let t enter your concious mind, but I've known
another way and it's really hard to go back.
	
>And maybe you have convinced XILINX by then that free tools 
>are so superior that it is worth allowing the free tool geniusses to 
>support their chips.

No, I won't have, because I have no interest in making tools useful for
anyone else.


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