FPGA openness
Hobson Frater
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.
Now, I can read what you've said about the software in two different ways.
Again, I apologize if I've misunderstood you.
The first way I could read it is that you believe that you need to have
windows as well as our software running in the system in which your Xilinx
device will operate. That is, you need to have the software on the board you
are designing. This is not the case. The software is used purely in the
development of the design, not for interfacing with the device. Once the
design is finished and the bitstream has been generated, there is no need for
the software to be present in order for the device to work the way you've
designed it to work.
The other way I could read your comments is that you understand that the
software is for design development purposes only and that you just don't want
to have to use it. As the above information may indicate, since the spec is
proprietary, there is really no other way to generate a bitstream than to use
the software. I would mention, too, that our devices have many complex
features and can get quite large. Designing something like this by hand
rather than using archetecture-specific mapping and placement & routing
software would be extremely difficult. The bitstreams themselves range from
~54K bits to the tens of millions of bits.
Now, that said, there *is* a tool available for quickly modifying bitstreams
(not creating them from scratch). It is called JBits, and you can read more
about it at http://www.xilinx.com/xilinxonline/jbits.htm
I hope this helps.
Regards,
Hobson Frater
Xilinx Customer Applications
Greg Alexander wrote:
> Is there anywhere for me to get the bitstream specs for xilinx chips? I
> want to buy the chip and then interface with it, I have no interest in
> buying the chip and then something to interface with it, and then
> installing windows to use the interface (in other words, I'm not going to
> use Foundation or XSE or whatever, even if they are good, but I still want
> to program the things).
Greg Alexander
Greg Alexander
>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.
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.
Could you please have that info posted on xilinx's page? The
whole "we're a stupid secretive company who doesn't want people to
actually use our hardware" part isn't anywhere on their page -- I've
looked a lot. Have any of you hardware types ever seriously lived a Linux
hacker life? From our side, the hardware world is tremendously secretive
and it's glaringly obvious how you guys get hurt with this stupidity (see
a recent thread about soldering BGA, for example). It makes you look very
immature even though the hardware world has, in some ways, accomplished a
lot more than the software world.
Do you know of any exceptions? If there aren't any, I declare the
PLD market fundamentally stupid (would Intel design chips whose process
they didn't understand? come on), and I will move on. I want a
programmable logic device -- programmable not by you or by your software,
but by me and my software. I want the device, not the software. I cannot
express strongly enough my intolerance for proprietary software. You're
cutting off a whole market there.
>Now, I can read what you've said about the software in two different ways.
>Again, I apologize if I've misunderstood you.
>
>The first way I could read it is that you believe that you need to have
>windows as well as our software running in the system in which your Xilinx
>device will operate. That is, you need to have the software on the board you
>are designing. This is not the case. The software is used purely in the
>development of the design, not for interfacing with the device. Once the
>design is finished and the bitstream has been generated, there is no need for
>the software to be present in order for the device to work the way you've
>designed it to work.
It's teh second way.
>The other way I could read your comments is that you understand that the
>software is for design development purposes only and that you just don't want
>to have to use it. As the above information may indicate, since the spec is
>proprietary, there is really no other way to generate a bitstream than to use
>the software. I would mention, too, that our devices have many complex
>features and can get quite large. Designing something like this by hand
>rather than using archetecture-specific mapping and placement & routing
>software would be extremely difficult. The bitstreams themselves range from
>~54K bits to the tens of millions of bits.
Putting up with software that sucks is much more difficult for me. I know
what I'm asking for.
>Now, that said, there *is* a tool available for quickly modifying bitstreams
>(not creating them from scratch). It is called JBits, and you can read more
>about it at http://www.xilinx.com/xilinxonline/jbits.htm
I'll look into that, thanks.
Gordon Brebner
gale...@sietch.bloomington.in.us (Greg Alexander) wrote:
> Do you know of any exceptions? If there aren't any, I declare the
>PLD market fundamentally stupid (would Intel design chips whose process
>they didn't understand? come on), and I will move on. I want a
>programmable logic device -- programmable not by you or by your software,
>but by me and my software. I want the device, not the software. I cannot
>express strongly enough my intolerance for proprietary software. You're
>cutting off a whole market there.
Welcome to the FPGA world, Greg. This is a sad fact of life for people
who actually want to do interesting "soft" things with the technology,
rather than just pretend that it's a dumb ASIC.
The most recent commendable exception to the secrecy rule was the Xilinx
6200 (and its ancestor the Algotronix CAL1024). As a result, just about
all of the innovative work on exploring the capabilities of reconfigurable
circuitry as a novel computing paradigm has been done using this part.
For example, I have written all of my own programming tools over the
past ten years. Unfortunately, this part was chopped a couple of years
ago because the bulk buyers of FPGAs don't want anything more than a
straight hardware ASIC substitute.
I know that various people have reverse engineered bitstream formats,
e.g. the Xilinx XC4000 series, so that some knowledge is out there, but
gained by inordinate wastage of people's time.
The only redeeming feature at Xilinx at the moment is that the efforts
of the JBits people are currently being tolerated. Apart from that, it's
a sad fact that the major providers just don't want to move on from
being simple logic array providers.
Gordon.
Ben Franchuk
>
> 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.
>
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
Greg Alexander
>I know that various people have reverse engineered bitstream formats,
>e.g. the Xilinx XC4000 series, so that some knowledge is out there, but
>gained by inordinate wastage of people's time.
Do you know where I could find any of this information? I don't have the
time/resources to reverse engineer any of it myself, but if the
information can be obtained without planting me firmly on the defendant
side of a case with Xilinx, I might just buy one of their chips.
>The only redeeming feature at Xilinx at the moment is that the efforts
>of the JBits people are currently being tolerated. Apart from that, it's
>a sad fact that the major providers just don't want to move on from
>being simple logic array providers.
JBits looks a little bit promising. I'll look into that more.
Thanks.
Andy Peters
>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
Ben Franchuk
>
> 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)?
True they have had more resources, and time to develop the code,but you
can bet marketing pressure to get the product out the door. This is a PC
vs Mac
type problem we have here. Both people have valid view points, but OPEN
is generaly a lot better than closed, look at LINUX vs WINDOWS.
>
> 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.
>
I agree let the COMPUTER grid away at the problems,but lets not
hide information. Well software XYZ has a bug that generates the wrong
routing table in the final output format. How can you find such a bug
if nobody but the vender can read the format and they don't time to
modify
the software?
Rickman
>
> 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
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.
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.
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
guestimated incorrectly that your paths would not meet your timing
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.
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?
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.
--
Rick Collins
rick.c...@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
Ray Andraka
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 rand...@ids.net
http://users.ids.net/~randraka
Peter Alfke
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.
>
Larry Doolittle
: [ 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 (pe...@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 <LRDoo...@lbl.gov>
Greg Alexander
>Greg Alexander wrote in message <8bapci$i0h$1...@jetsam.uits.indiana.edu>...
>>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.
>
>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
love your art then by some measures you're already dead. I'm not going to
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.
Ben Franchuk
> 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.
Greg Alexander
>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
>
>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
stopping Neocad from happening again? Neocad was a company with
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
>guestimated incorrectly that your paths would not meet your timing
>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.
Kelly Hall
Hash: SHA1
"Ben Franchuk" <bfra...@jetnet.ab.ca> wrote in message
news:38D95B1F...@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-----
Greg Alexander
>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.
>
>Xilinx ( and Altera etc. ) have spent and are spending hundreds of thousands
>of man-hours on.
>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.
Greg Alexander
>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.
>>
>
>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.
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. :)
Ray Andraka
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:
--
Rickman
> 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 <LRDoo...@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.c...@XYarius.com
remove the XY to email me.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design
Arius
Greg Alexander
>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.
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
get for free?
Rickman
> 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.
e...@riverside-machines.com.nospam
GNU hacking, but it's time for a reality check. When I last tried
Alliance, it was completely unusable for any real work. I haven't
tried Icarus, but imagine how a commercial product would fare on this
NG if all that could be said for it was "needs some work, I know, but
the core is there". FreeHDL seems to be alive, just, but I'm not
holding my breath. The general problems of placement and routing have
been done to death, but they're no use by themselves.
Timing analysis is completely different, is non-trivial, and requires
a detailed understanding of the silicon. You need a parasitic
extractor, a good propagation delay model, knowledge of the effects of
voltage, process, and temperature variations, and probably lots of
other things I've never even heard of, before you can even start on
the 'easy' bits. The people who understand this sort of stuff are
unlikely to have enough free time to give away all their knowledge for
nothing. And how do you test a timing analyser? You need a lot of
people, a lot of money, several years, and a lot of angry users.
By comparison, writing a kernel or a compiler, or most of the other
bits you find in GNU (aka Linux, more-or-less), is kid's stuff, and
can be done (and has, many times) by a clever college student. They're
self-contained problems; anyone can test a compiler. However, some guy
sitting in his bedroom on a rainy weekend is never going to be able to
test or fix a timing analyser, however clever he is. That's why we
have commercial software.
Evan
On 22 Mar 2000 23:07:20 GMT, ldoolitt@recycle (Larry Doolittle) wrote:
>Andy Peters (apeters...@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 (pe...@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.
>
Greg Alexander
e...@riverside-machines.com.NOSPAM wrote:
>I'm all in favour of open source, and I've done more than my share of
>GNU hacking, but it's time for a reality check. When I last tried
>Alliance, it was completely unusable for any real work. I haven't
>tried Icarus, but imagine how a commercial product would fare on this
>NG if all that could be said for it was "needs some work, I know, but
>the core is there". FreeHDL seems to be alive, just, but I'm not
>holding my breath. The general problems of placement and routing have
>been done to death, but they're no use by themselves.
You haven't even followed the conversation. I say again:
If there exists closed-source software that is good, fast,
bug-free, clever, etc., and open-source software that is bad, slow, buggy,
naive, etc...I will still prefer the open-source program for my own
entertainment. Perhaps if I were working somewhere and getting the
product out the door were a lot more important than the experience of
getting it there, I would chose differently.
>Timing analysis is completely different, is non-trivial, and requires
>a detailed understanding of the silicon. You need a parasitic
>extractor, a good propagation delay model, knowledge of the effects of
>voltage, process, and temperature variations, and probably lots of
>other things I've never even heard of, before you can even start on
>the 'easy' bits. The people who understand this sort of stuff are
>unlikely to have enough free time to give away all their knowledge for
>nothing. And how do you test a timing analyser? You need a lot of
>people, a lot of money, several years, and a lot of angry users.
>
>By comparison, writing a kernel or a compiler, or most of the other
>bits you find in GNU (aka Linux, more-or-less), is kid's stuff, and
>can be done (and has, many times) by a clever college student. They're
>self-contained problems; anyone can test a compiler. However, some guy
>sitting in his bedroom on a rainy weekend is never going to be able to
>test or fix a timing analyser, however clever he is. That's why we
>have commercial software.
Xilinx goes to lengths to make Xilinx-FPGA-oriented tools NOT doable
by a college student, so your entire statement is rendered meaningless.
If Intel went that far to make it so only MS could make protected mode
OSs, you can bet your ass that Linux wouldn't be where it is. I'm certain
that timing analysis is a more complex task than putting together the
heart of a kernel, but that is not the same as saying that it is an
untouchable problem.
Ray Andraka
you want to play with what can the FPGA do, or you want to play with tools for
the FPGA. If you really want to play with the FPGA to see what you can do
with it, you'll get there much faster using the tools that are out there
instead of rolling your own. When you need to run out to the store, I doubt
you start by building the car to go in. Rather, you probably drive a mass
produced car that fits your needs reasonably well but not perfectly. On the
otherhand, if your desire is to learn how to make the tools then don't expect
to use them to make useful things in the FPGA for quite a long time,
especially if you only do it on weekends.
That said, it would be nice to have more openness with respect to the
bitstream, but I also understand the reluctance to do so. First, opening the
bitstream gives considerably more visibility into the phsyical construction of
the FPGA, something the FPGA vendors would understandably not want to give
away to the competition. Second is the issue of support. The support for
just the sanctioned tools flow is already a huge burden, and I think much more
than a software only package. For software only support, you have a fairly
well defined platform, so realistically the environment the software runs in
is pretty well controlled. Now add to that mix the fact that with FPGA
designs, people are also creating hardware. There are plenty of designs out
there that, well how should we put this delicately...are not implemented very
well for an FPGA. The support space is exponentially larger than the software
only one. Now, if you start opening up to other tools, the support is even
less constrained. Finally there is the issue of percieved design security.
Granted a bitstream can be copied directly for a blatant rippoff, but at least
the reverse engineering is made more difficult (not impossible) if the
bitstream format and function is not disclosed. As I hinted in my previous
post, it is possible to get a fairly good handle on the bitstream with alot of
tedious work, but that is onerous enough that it represents more work than
doing an original design.
Greg Alexander wrote:
> In article <38d9f2b2...@news.dial.pipex.com>,
> e...@riverside-machines.com.NOSPAM wrote:
> >I'm all in favour of open source, and I've done more than my share of
> >GNU hacking, but it's time for a reality check. When I last tried
> >Alliance, it was completely unusable for any real work. I haven't
> >tried Icarus, but imagine how a commercial product would fare on this
> >NG if all that could be said for it was "needs some work, I know, but
> >the core is there". FreeHDL seems to be alive, just, but I'm not
> >holding my breath. The general problems of placement and routing have
> >been done to death, but they're no use by themselves.
>
> You haven't even followed the conversation. I say again:
> If there exists closed-source software that is good, fast,
> bug-free, clever, etc., and open-source software that is bad, slow, buggy,
> naive, etc...I will still prefer the open-source program for my own
> entertainment. Perhaps if I were working somewhere and getting the
> product out the door were a lot more important than the experience of
> getting it there, I would chose differently.
>
> >Timing analysis is completely different, is non-trivial, and requires
> >a detailed understanding of the silicon. You need a parasitic
> >extractor, a good propagation delay model, knowledge of the effects of
> >voltage, process, and temperature variations, and probably lots of
> >other things I've never even heard of, before you can even start on
> >the 'easy' bits. The people who understand this sort of stuff are
> >unlikely to have enough free time to give away all their knowledge for
> >nothing. And how do you test a timing analyser? You need a lot of
> >people, a lot of money, several years, and a lot of angry users.
> >
> >By comparison, writing a kernel or a compiler, or most of the other
> >bits you find in GNU (aka Linux, more-or-less), is kid's stuff, and
> >can be done (and has, many times) by a clever college student. They're
> >self-contained problems; anyone can test a compiler. However, some guy
> >sitting in his bedroom on a rainy weekend is never going to be able to
> >test or fix a timing analyser, however clever he is. That's why we
> >have commercial software.
>
> Xilinx goes to lengths to make Xilinx-FPGA-oriented tools NOT doable
> by a college student, so your entire statement is rendered meaningless.
> If Intel went that far to make it so only MS could make protected mode
> OSs, you can bet your ass that Linux wouldn't be where it is. I'm certain
> that timing analysis is a more complex task than putting together the
> heart of a kernel, but that is not the same as saying that it is an
> untouchable problem.
--
Brian Drummond
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...
however a couple of weekends could see you hack together an interface
between your textual format, whatever it is, and (say) the EDIF format
input to the Xilinx tools.
> 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?)
> 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.
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?
Which would only leave the relatively small Bitgen as a proprietary
tool. I could live with that!
> 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!)
>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...
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...
- Brian
Ben Franchuk
>
> 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!)
>
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. The one thing I find funny is sales
of the tiny logic devices - the single gate suff, used to patch chips
up.
Fuse pals are still around, but programers still cost a bit yet, with
little software for linux. I really wonder how long eprom/flash devices
last? Ben.
Nicholas C. Weaver
Greg Alexander <gale...@sietch.bloomington.in.us> wrote:
>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.
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.
And do you realize what the cost is for a set of tools for
ASIC development? Custom VLSI development? FPGA tools are cheap, you
can often get a free set of the student tools included in textbooks on
logic design.
>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.
Finally, athough buggy, most of the bugs show up when you
REALLY push the tools.
>>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
>get for free?
A) You aren't really signing away much/any of your future.
You really can't operate at the bleeding edge of research without
being willing to sign the occasional NDA.
B) Why do you think this information should be free? Xilinx
is in the business of selling FPGAs, and there is a fair amount of
interesting intellectual property stuck away in those bitfiles. The
tools are close enough to free for a hobbyiest-level project,
considering the complexity of the tools and the parts.
C) As the LogicBlox people at xilinx (their Java based
module generator system) told us a couple years ago, "Java decompilers
are really good. Nudge nudge, wink wink".
--
Nicholas C. Weaver nwe...@cs.berkeley.edu
Andy Peters
>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.
But, an FPGA sitting in space by itself is fairly useless. So, you need a
PC board. Are you going to write your own board-layout software, too? In
that arena, you've got some advantages, because all of the relevant file
formats (gerber, edif, etc) are documented.
But how much money do you want to burn through when you design your board,
and it doesn't work, and you don't know whether it's your FPGA design, or
your board design, or the tools? One-off four-layer PCBs ain't cheap. The
design I'm working on now has an eight-layer board.
Good board-design tools aren't cheap. Signal integrity analysis tools that
can back-annotate to your board layout aren't cheap. Multiple board revs
REALLY aren't cheap. I didn't even mention the fact that high-speed board
design is, in itself, an art and it's something you just don't "pick up."
If you're a student and your time is 'free,' then have at it. If you've got
a schedule and a boss, your perspective changes.
-- andy
ps: I looked at that freeware VHDL simulator, Symphony. No graphical
waveform display. That limits its usefulness, eh?
Ruben Leote Mendes
: 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.
Ruben - etr...@ua.pt
Greg Alexander
>I understand your point. However, I think there are two things here. Either
>you want to play with what can the FPGA do, or you want to play with tools for
>the FPGA. If you really want to play with the FPGA to see what you can do
>with it, you'll get there much faster using the tools that are out there
>instead of rolling your own. When you need to run out to the store, I doubt
>you start by building the car to go in. Rather, you probably drive a mass
>produced car that fits your needs reasonably well but not perfectly. On the
>otherhand, if your desire is to learn how to make the tools then don't expect
>to use them to make useful things in the FPGA for quite a long time,
>especially if you only do it on weekends.
No, I totally disagree. Without specs, I know that I will always be
LIMITED to their software, so it's not a training wheels situation. Also,
I'm not going to go to extreme lengths (installing Windows) just to make
their software run since their software doesn't do what I want. Also, I
don't want to learn VHDL and all these high level lanugages and
interfaces, I simply want to do the thing by hand. I don't want to build
a car from pieces. This is simply a preference, and one that Xilinx
shouldn't be disallowing.
>That said, it would be nice to have more openness with respect to the
>bitstream, but I also understand the reluctance to do so. First, opening the
>bitstream gives considerably more visibility into the phsyical construction of
>the FPGA, something the FPGA vendors would understandably not want to give
>away to the competition. Second is the issue of support. The support for
It's a well-known industry fact that everything that can be
reverse-engineered has already been reverse-engineered by the competition
so all they're hurting is their customers.
>just the sanctioned tools flow is already a huge burden, and I think much more
>than a software only package. For software only support, you have a fairly
>well defined platform, so realistically the environment the software runs in
>is pretty well controlled. Now add to that mix the fact that with FPGA
>designs, people are also creating hardware. There are plenty of designs out
>there that, well how should we put this delicately...are not implemented very
>well for an FPGA. The support space is exponentially larger than the software
>only one. Now, if you start opening up to other tools, the support is even
>less constrained. Finally there is the issue of percieved design security.
I don't see why Xilinx would have any obligation to support Joe Blow Linux
Hacker trying to use his cheap obviously unsupported homegrown bitstream
generation software.
>Granted a bitstream can be copied directly for a blatant rippoff, but at least
>the reverse engineering is made more difficult (not impossible) if the
>bitstream format and function is not disclosed. As I hinted in my previous
>post, it is possible to get a fairly good handle on the bitstream with alot of
>tedious work, but that is onerous enough that it represents more work than
>doing an original design.
They sell FPGAs that are given a command and then they disable read back
until reprogramming. Anyone willing to go to the lengths to get around
that would also be willing to go to the lengths to reverse-engineer the
bitstream.
Greg Alexander
>On 22 Mar 2000 23:26:45 GMT, gale...@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 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 :)
Greg Alexander
>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.
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.
Ray Andraka
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).
Greg Alexander wrote:
--
Andy Peters
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.
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.
-- a
Ben Franchuk
> 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.
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.
I like forth,but not as a cpu,
because some data access is still better the standard way,
like data records.
---
Greg Alexander
>In article <8bca7r$k50$1...@jetsam.uits.indiana.edu>,
>Greg Alexander <gale...@sietch.bloomington.in.us> wrote:
>
>>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.
>
> 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?
> And do you realize what the cost is for a set of tools for
>ASIC development? Custom VLSI development? FPGA tools are cheap, you
>can often get a free set of the student tools included in textbooks on
>logic design.
If it were free it would only just barely be good enough, and then only
because there would be less overhead to reverse-engineering it.
>>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.
> Finally, athough buggy, most of the bugs show up when you
>REALLY push the tools.
As a Forth fan I believe in the power of simplicity. You aren't one, but
your inexperience with the field doesn't make you qualified to state what
is possible in another paradigm.
>>>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
>>get for free?
>
> A) You aren't really signing away much/any of your future.
>You really can't operate at the bleeding edge of research without
>being willing to sign the occasional NDA.
I'd be signing away my right to share the software. That's a right to
die for.
> B) Why do you think this information should be free? Xilinx
>is in the business of selling FPGAs, and there is a fair amount of
>interesting intellectual property stuck away in those bitfiles. The
>tools are close enough to free for a hobbyiest-level project,
>considering the complexity of the tools and the parts.
Their competitors have already reverse-engineered Xilinx's products.
Isn't that obvious to everyone?
> C) As the LogicBlox people at xilinx (their Java based
>module generator system) told us a couple years ago, "Java decompilers
>are really good. Nudge nudge, wink wink".
Thanks, I'm looking into the JBits thing when I get a chance.
Greg Alexander
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).
Greg Alexander
>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.
Greg Alexander
>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.
>
>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.
Greg Alexander
>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.
>>
>
>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)
Nicholas C. Weaver
Greg Alexander <gale...@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.
glen herrmannsfeldt
>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
Greg Alexander
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?
Greg Alexander
>"Andy Peters" <apeters...@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?
glen herrmannsfeldt
(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
Ray Andraka
Out of curiousity, about how many FPGA designs have you done?
Greg Alexander wrote:
--
Ben Franchuk
> 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.
Gary Watson
news:8bca7r$k50$1...@jetsam.uits.indiana.edu...
> In article <38D97E76...@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.
>
> 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.
I had a similar discussion with Xilinx back in 1988 or thereabouts, when
they wanted me to pay $5000 for a piece of software so I could see if the
Xilinx parts would be suitable for my application. I said to the Xilinx guy
that they should give me the software for free like MMI did with Palasm, and
if it worked they would make their money by selling me chips (after all, the
tools only work with Xilinx chips). The Xilinx salesman explained that
Xilinx is a *software* company, not a chip company. They only make chips so
they can sell their development tools.
I decided that I would ignore Xilinx for ten years, and revisit the issue.
Twelve years on, I've decided to give them another chance, and so I'm
looking at the Xilinx parts again. I'm sure they don't realize that they
lost out on selling millions of Xilinx parts to go into my designs because
they wouldn't give me their tools. I've been making do with PALs all
these years...
[As a side note, the issue in 1988 was whether you could really fit my
intended design into their parts. I had an existing design, drawn by hand
onto a bunch of C size sheets of vellum. The Xilinx guy was unwilling to
refund my $5000 if the design didn't fit into the target part, even though a
rough gate count made us think it should fit easily. He offered us a 30 day
eval, but we judged that this would not be long enough.]
--
Gary Watson
ga...@nexsan.sex (Change dot sex to dot com to reply!!!)
Nexsan Technologies Ltd.
Derby DE21 7BF ENGLAND
http://www.nexsan.com
Brian Drummond
<bfra...@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
Jim Granville
- 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 <br...@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 ?
Catalin Baetoniu
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.
>
e...@riverside-machines.com.nospam
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
e...@riverside-machines.com.nospam
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
Andreas Doering
> The new tools use a binary
> file instead, so that option is not as available.
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: doe...@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)
----------------------------------------------------------------
Greg Alexander
>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?
Greg Alexander
>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.
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?
Greg Alexander
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.
Greg Alexander
>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.
a...@z.com
If I would come on a software newsgroup and claim I prefer to develop software
in machine language and write my own compiler, assembler and OS because the
existing tools are not open source and might have bugs that I cannot control,
and tweak the bits by trial and error until my application works you could
then call me a pompous ass.
I and others here have already pointed to the place you should look at if you
really want to go your way and that is XDL. However, I begin to think that you
are here only to promote your Linux/open source agenda - not that I have
something against it but this is not relevant to the subject we discuss here,
FPGA design.
I also tried to point out that hardware and software design are different
things and your chance of success at hardware design with a software approach
is very slim. If you felt hurt by the way I said it I am sorry, I had no
intention to do that. You want to do everything your own way from scratch and
that is OK for me. You also want to convince us that this is the right way to
do it and I do not agree with that.
This is my last post to this thread,
Catalin Baetoniu
Ray Andraka
insisted on a wirewrap prototype. It had lots of memory around it, and needed
to run internally at 96 MHz. The memory speeds limited memory access to 16
MHz. In that case, I was able to stagger memory access to the 5 memory banks
to limit the number wires switching at a time. I also set all the IOBs to slow
slew rate. The device, in case you were wondering was an XC4036XLA-09 in a BGA
package mounted on a BGA to wirewrap adapter. Worked just fine (and the
power/ground was surprisingly clean at the FPGA pins). If I had run all the
memory access on the same cycle it probably would not have worked. So yes, you
can do FPGAs with wire wrap IF you are very careful about the design.
Andy Peters wrote:
> 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.
>
> -- 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
Ray Andraka
Greg Alexander wrote:
> 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).
I thought part of the reason you wanted to roll your own was because you didn't
want to pollute your PC with windoze.
>
>
> >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.
That's fine for simple PLDs. FPGAs have somewhat limited routing resources
compared with the logic. Its the routing resource you are paying for, and its
the place and route that make the FPGA tools. I think you are lumping the FPGA
tool with the design entry/synthesis tools, yet they are two distinctly
different pieces. I feel your pain WRT not getting what you want out of the
synthesis. However, the FPGA tool (from translate to bit stream) really is
quite deterministic, and you can easily work it to gt out exactly what you put
in. Heck, that's why I have a preference for schematic entry. You may find it
alot easier to do what you want by making a front end tool to generate the
primitives and netlist, including placement if that's what you like and then
feeding that output to the FPGA tool
Ray Andraka
what is out there before condemning it. By working with the existing tools
for a while, you'll get a) a real good feel for the FPGA architecture, what
works, what's fast and whats not, b) an understanding of what the strengths
and weaknesses of the current tools are, and c) some focus for your
improvement efforts. You previously mentioned you are using one of the
smaller 4000 series parts on an XESS board. That part is supported by the
student edition of the software. Why, XESS sells a bundled package with
their board, the student edition software (without VHDL, mind you) and a
lab text book for about $200. I think that package is one of the best
values for someone starting out with FPGAs. Learn the basics in a proven
framework, then venture outside the box to fix the problems you find. The
tools really are pretty robust. Where they break is when you start pushing
the corners. Most of the problems I've encountered are related to detailed
placement in the design.
My point is, I don't think the tools are nearly as limiting as you percieve
them to be. How can you know what the limits are if you've never touched
the tools or the devices????
Greg Alexander wrote:
> In article <38DAA773...@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?
--
Ray Andraka
for Jan Gray's series of articles on implementing a RISC in an FPGA.
As for testing, true you can't stick a probe in the chip, but then there are few
chips these days that you can do that too. Instead, there are other techniques
including simulation, test vectors, dedicated test points, and my favorite, using
reconfiguration to modify the circuit to get at the data you want to observe.
Ben Franchuk wrote:
> 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
--
Greg Alexander
>Hi Greg,
>
>If I would come on a software newsgroup and claim I prefer to develop software
>in machine language and write my own compiler, assembler and OS because the
>existing tools are not open source and might have bugs that I cannot control,
>and tweak the bits by trial and error until my application works you could
>then call me a pompous ass.
No I wouldn't. I'm a strong proponent of knowing the whole system as far
down as you can stomach. My views are probably among the minority for
MicroSoft-oriented software professionals, but I would be surprised if you'd
find many competent and experienced software engineers who don't agree
with me that, if you have the time, there's no reason not to build a
system from bits. I happen to have an open source assembler, compiler,
and OS, so I don't need to write them to understand them...but even so,
I've written a compiler and have done serious investigations into the
internals of other compilers.
Also there is a level of complexity here. The compiler I wrote
was 69 lines of C code but gave me a very comfortable level of abstraction
compared to ASM. A compiler written to be used by other people and
written to support complex features (such as gcc) would of course be
much larger and would not be a weekend project for me -- it would require
a year or more of dedicated work most likely. Similarly, I am not trying
to make generalized route&place software. I don't need to spend that 90%
of the time adding 10% of the features and I don't even need many of the
remaining 90% of the features. I'm not trying to implement a very complex
chip -- it's not like I'm trying to clone the x86 or anything.
>I and others here have already pointed to the place you should look at if you
>really want to go your way and that is XDL. However, I begin to think that you
>are here only to promote your Linux/open source agenda - not that I have
>something against it but this is not relevant to the subject we discuss here,
>FPGA design.
No, /my way/ does not include any choices made by other people except in
the actual hardware. I don't want to work with the OS that Xilinx has
chosen, I do not want to pay for an oversized toolset when all that I want
is makebits. I do not want to read manuals describing how to use makebits
when I could instead be reading a manual describing the actual format
output by makebits. Allowing someone else to make the choices about the
actual hardware is a choice forced by economic reality (as much as I'd
love to build my own chip or even fab, I know that's not going to happen),
but allowing someone else to make choices about the software is not
anything forced by natural laws.
You're right that XDL or similar low-level use of Xilinx's
software is the closest compromise I'm likely to get without a bunch of
time and resources wasted on reverse-engineering, but that doesn't make it
what I'm after.
>I also tried to point out that hardware and software design are different
>things and your chance of success at hardware design with a software approach
>is very slim. If you felt hurt by the way I said it I am sorry, I had no
I never said what approach I would use. The only thing I'm borrowing from
the software approach is a "can do" attitude. My own ideas for design
were more like the lego approach. I certainly didn't learn programming
through a "software approach" -- the useful methods of approaching
problems relating to software were things I figured out well after I
learned how to code. I do not believe that because I can write software I
can design chips, I think that because I can LEARN to write software that
I can also LEARN to design chips.
I didn't learn software from the ASM level up, but at the same
time I didn't have an ASM manual until after I already knew how to program
(and when I got one, you can be sure I crashed that 286 a-plenty learning
ASM in DEBUG.EXE).
Some may think that my knowledge of software engineering will
prove disadvantageous as I try to move on to other things because I may
have assumptions that aren't justified in other fields, but perhaps your
knowledge of hardware engineering handicaps your abilities to assess what
is possible.
At the very least, Chuck Moore (designer of Forth, SH-Boom, MuP21,
F21, i21) has proven that the minimalist philosophy that he has found works
so well for software can also work for hardware. Jeff Fox (the guy
financing the F21 and in general informing people of the wonders of Chuck
Moore's minimal ideas -- www.ultratechnology.com) often tells anecdotes of
how he finds hardware engineers constantly in disbelief of what Chuck's
done and has developed a short patience because of the many times he's
seen engineers be blatantly rude to Chuck when Chuck is trying to explain
what he's accomplished. I figured that Jeff Fox was talking about some
small group of engineers, but I see from here that the "can't do" and
"only can be done my way" attitudes /are/ prevelant among hardware
engineers.
Thanks to those of you who pointed out that Xilinx's software does allow
low-level interfacing through command-line DOS programs. It does open up
another option that I may eventualy decide to use.
>intention to do that. You want to do everything your own way from scratch and
>that is OK for me. You also want to convince us that this is the right way to
>do it and I do not agree with that.
No, I have no interest in convincing you that this is the right way to do
it. Unfortunately, Xilinx has interest in convincing me that this is the
wrong way! I wish to be allowed to go my own route without paying gobs of
money to support people going different routes. I expect and prefer that
other people go different routes because what I'm doing isn't much good
for producing chips as a day job.
Greg Alexander
>
>
>Greg Alexander wrote:
>
>> 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).
>
>I thought part of the reason you wanted to roll your own was because you didn't
>want to pollute your PC with windoze.
They released source. I can read source, even Windows source, without
using Windows. Their release of source directly aided the several
individuals who have written Linux programs to use their boards.
>> 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.
>
>That's fine for simple PLDs. FPGAs have somewhat limited routing resources
>compared with the logic. Its the routing resource you are paying for, and its
>the place and route that make the FPGA tools. I think you are lumping the FPGA
>tool with the design entry/synthesis tools, yet they are two distinctly
>different pieces. I feel your pain WRT not getting what you want out of the
>synthesis. However, the FPGA tool (from translate to bit stream) really is
>quite deterministic, and you can easily work it to gt out exactly what you put
>in. Heck, that's why I have a preference for schematic entry. You may find it
>alot easier to do what you want by making a front end tool to generate the
>primitives and netlist, including placement if that's what you like and then
>feeding that output to the FPGA tool
In the end I would be surprised if I would stick to manual place&route
(i.e., if I get myself into a position where I'm making chips more for the
result than for the experience, I would not be looking for software based
on open sourceness but on quality and I may well chose Xilinx's software),
but I definitely need to understand it for now. I don't care so much about
the end product (though if I ever get a working processor going I sure will
be happy), but I demand to understand all steps. The last step of generating
the bitstream is simple enough I don't need source to understand it, so
it's only practical issues keeping me from just accepting my fate and
getting ahold of makebits/bitgen/whatever it's called.
Brian Drummond
<doe...@iti.mu-luebeck.de> 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
Good suggestion.
I *knew* I'd seen something about an ASCII format yesterday but I
couldn't find it... searching the online documentation for XDL doesn't
help at all either!
- Brian
Brian Drummond
wrote:
>Brian Drummond <br...@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?
The same applies to some extent in the software world... in the days of
64K machines you could reasonably expect to understand what they did.
You had to, because installing a new printer could involve re-writing
the BIOS!
I'm not sure that even Linux encourages people to learn quite that
much...
>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.
>
Maybe we can approach this through JBits...
As I understand it you can't control the routing, only the logic. But it
ought to be quite easy to generate a "raw" bitstream with predetermined
interconnect, which can be customised by logic.
Treat the FPGA as a very large PAL for example, or as a set of PALs
interconnected in a well-defined manner. For example, some connected to
input pins, some to output pins, some connected as feedback structures
to build state machines, and some as registers or memory.
Or several "raw" bitstreams, specialised for different purposes (e.g.
2-layer or more neural net type topologies)
Timing analysis would have to be along the lines of "count the logic
levels, add the route delay and multiply by the speed grade" ...
suboptimal for sure, but better than nothing. Routing delays could be a
table of constants since the routing is fixed.
Then folks like Greg could choose one of these bitstreams and "program"
it by inserting the contents of the logic blocks with whatever tools he
wanted. There would have to be a verifier to compare the "don't touch"
parts of the bitstream (routing etc) with the original...
Brian Drummond
Alexander) wrote:
>In article <9nfkdssa8jmmqgecu...@4ax.com>, Brian Drummond wrote:
>>On 22 Mar 2000 23:26:45 GMT, gale...@sietch.bloomington.in.us (Greg
>>Alexander) wrote:
>>>[...] 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?
Well I gotta admire the attitude!
>>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.
>
>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),
Heh, don't be telling me what you can't do with LSTTL...
(actually it's pretty useful up to broadcast quality, but high res
starts stretching its capabilities. And as Evan pointed out, you'll
learn a lot by real hardware hacking, that you'll never learn by merely
programming an FPGA)
>>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 :)
Alas... if only ...
I must apologise for misleading you by accident.
I went hunting for a bitgen that I could download without paying any
money. Found one right away. BUT though it's only 6K, it uses a number
of rather large DLL's, not all of which were available from the same
place.
So reverse engineering with DEBUG ... well if I said it wasn't an option
you'd cry bullshit ... so I'll just say it's only for the eXtreme
masochist.
On the other hand if you're really thinking of buying the Xess board,
notice that they'll throw in the Xilinx tools at a substantial discount.
I agree that XDL/Bitgen are about as close to what you want as you can
get without a _lot_ of work.
Best of luck whichever route you take.
Greg Alexander
>Not at all. It's just that I think it makes more sense to first work with
>what is out there before condemning it. By working with the existing tools
>for a while, you'll get a) a real good feel for the FPGA architecture, what
>works, what's fast and whats not, b) an understanding of what the strengths
>and weaknesses of the current tools are, and c) some focus for your
>improvement efforts. You previously mentioned you are using one of the
>smaller 4000 series parts on an XESS board. That part is supported by the
>student edition of the software. Why, XESS sells a bundled package with
>their board, the student edition software (without VHDL, mind you) and a
>lab text book for about $200. I think that package is one of the best
>values for someone starting out with FPGAs. Learn the basics in a proven
>framework, then venture outside the box to fix the problems you find. The
>tools really are pretty robust. Where they break is when you start pushing
>the corners. Most of the problems I've encountered are related to detailed
>placement in the design.
$209 for board+book+foundation 1.5 (student edition), of which I only want
board+makebits/bitgen/whatever
$109 for board
So for $100 I could basically buy something I could write if Xilinx
released full specs.
What's $100 to you? To me it's about 14 hours of mostly paper-shuffling
work involving framemaker. Alternatively, it's about a third of a month's
rent or most of a month's food.
Sure, I /could/ get a job using more of my "qualifications" (easier to do
some places than here, but still possible here) and I /could/ be earning 2
or 3 times my current hourly rate and I /could/ be working full time and
all that crap...but what I have now is comfortable, affords me a lot of
free time, and works for me. If you think $100 should be worth it to me
so that I can use makebits, then you should think that $100 is worth it
just to get me something better to do than post here. :)
Think of how much time Xilinx would have saved you if they'd just
released bitstream specs. :)
>My point is, I don't think the tools are nearly as limiting as you percieve
>them to be. How can you know what the limits are if you've never touched
>the tools or the devices????
It would be nice if they'd let me try to do it the cheap way before
forcing me to buy the tools rather than vice versa.
Don Husby
gale...@sietch.bloomington.in.us (Greg Alexander) wrote:
> 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.
So, the problem isn't really with the commercial software, the problem is
that you're paranoid and think the bugs are out to get you? Somehow
a piece of software used by thousands of people to do real designs has
a bug with your name on it? And when you discover this bug, you will
be stopped dead in your tracks because Xilinx will never be able to fix
it? But if YOU had the bitstream format, you'd have anal-retentive
control over your destiny and can spend hundreds of man-hours writing
and debugging code to solve this problem that would otherwise cost
you ~$100 for the commercial software, a few megabytes of disk space,
and a .001% chance that you might discover a bug that will take Xilinx
a day or two to fix?
You sound like my ex-wife, who fancied herself an artiste and kept
whining about how her life was too easy and how a real artist has
to struggle with the "human condition" before she can be creative.
She didn't buy Isaac Newton's theory about standing on the shoulders
of giants, because it's safer to be wallowing around in the giant's
toe-cheese with the illusion that with "a couple of weekends of work"
and you will be soaring high over his head. (Last I heard, she
was applying her artistic talents as a janitor in a health club.)
Well, it's a nice dream, Greg, and maybe it's sometimes true for real
artists and geniuses, but it's clear from your posts that you barely
have a clue. That you haven't even seen the commercial tools that you
fear so much. That you haven't ever done an FPGA design.
As has been mentioned by others, there are many places to hack into
the FPGA design flow. You would do yourself, and possibly the rest of
the world a service by looking into this (although I wouldn't dare
suggest that you are motivated to do something useful for the rest of
the world.) If you came to comp.arch.fpga for advice, this is it:
trying to hack the bitstream is a waste of your time. Even if someone
gave you the bitstream format, it would be a waste of your time.
Buy the student edition of the Xilinx tools. If it upsets you to
put $100 into the corrupt kapitalistic software-industrial complex,
then steal it. If it upsets your tummy to use a program for which
you have no source code, take a pill and get over it. If you find
your 13 Gigabyte disk is running out of space, you can probably
afford to delete your Captain Kirk .gif files. Use the software.
Find out what it can and cannot do. Get back to us in a couple of
weeks and maybe we can have an intelligent discussion about FPGAs.
> 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 ...
> No, I won't have, because I have no interest in making tools useful for
> anyone else.
.. and ...
> I'd be signing away my right to share the software. That's a right to
> die for.
--
Don Husby <hu...@fnal.gov> http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab Phone: 630-840-3668
Batavia, IL 60510 Fax: 630-840-5406
Greg Alexander
>Sigh.
>
>gale...@sietch.bloomington.in.us (Greg Alexander) wrote:
>> 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.
>
>So, the problem isn't really with the commercial software, the problem is
>that you're paranoid and think the bugs are out to get you? Somehow
>a piece of software used by thousands of people to do real designs has
>a bug with your name on it? And when you discover this bug, you will
No, I mean that every time my design doesn't work, I'll be fairly certain
it's my fault, but I won't be 100% certain. Bugs are only a tiny part of
the joy of understanding the software. They are a part of it and worth
mentioning it, but even if I knew their code was 100% bug free, which I
couldn't, I wouldn't want their code. As it is, from reading this group
for just a few days I know that there are bugs in their code that have got
real engineers working on real problems that they have declined to
publicize in a notable manner.
>be stopped dead in your tracks because Xilinx will never be able to fix
>it? But if YOU had the bitstream format, you'd have anal-retentive
>control over your destiny and can spend hundreds of man-hours writing
>and debugging code to solve this problem that would otherwise cost
>you ~$100 for the commercial software, a few megabytes of disk space,
>and a .001% chance that you might discover a bug that will take Xilinx
>a day or two to fix?
Getting rid of the bugs is small compared to the peace of mind of
understanding the software. If all I cared about was the bug, that would
be one thing, but I don't even want the software, let alone its bugs!
>You sound like my ex-wife, who fancied herself an artiste and kept
>whining about how her life was too easy and how a real artist has
>to struggle with the "human condition" before she can be creative.
>She didn't buy Isaac Newton's theory about standing on the shoulders
>of giants, because it's safer to be wallowing around in the giant's
>toe-cheese with the illusion that with "a couple of weekends of work"
>and you will be soaring high over his head. (Last I heard, she
>was applying her artistic talents as a janitor in a health club.)
Newton stood on the shoulders of giants because the giants were scientists
and a natural law I learned long ago is "scientists like to publish." If
Xilinx PUBLISHED I'd gladly stand on their shoulders. But instead they've
constructed a platform and asked me to purchase some room on the platform
but requested that I not look over the edge to see what's holding it up.
I'm somewhat worried that it will fall down (bugs), but more importantly I
want to understand what's holding it up. I'm not trying to make a chip to
sell it, I'm trying to make a chip to have the experience of making a
chip, and if I'm just after the experience, I'm going to understand as
much of it as I can if I have the choice.
>Well, it's a nice dream, Greg, and maybe it's sometimes true for real
>artists and geniuses, but it's clear from your posts that you barely
>have a clue. That you haven't even seen the commercial tools that you
>fear so much. That you haven't ever done an FPGA design.
I have no clue about FPGA, and at one time, neither did you.
>As has been mentioned by others, there are many places to hack into
>the FPGA design flow. You would do yourself, and possibly the rest of
>the world a service by looking into this (although I wouldn't dare
>suggest that you are motivated to do something useful for the rest of
>the world.) If you came to comp.arch.fpga for advice, this is it:
>trying to hack the bitstream is a waste of your time. Even if someone
>gave you the bitstream format, it would be a waste of your time.
That's why she's your ex-wife. Your judging of activities by OTHER people
as complete wastes of time is stupid. I don't mind if you don't have any
intention to do what I'm doing, but I don't see why you mind that I do it.
Your ex-wife may have an idea there, working as a janitor. If you
approach it right, a janitorial job can be great: You're a slave to no
one. The vast majority of the time most janitors are unsupervised and,
more importantly, once you're "just a janitor" you can quit and go
anywhere else you want. You don't have anyone demanding that your mind
be doing any particular thing, conforming to anything, only that your body
go through the motions. I'd rather be a janitor than a lot of other
things, that's for sure. (of course, a lot of janitors don't realize
their freedom and are, as such, slaves)
>Buy the student edition of the Xilinx tools. If it upsets you to
>put $100 into the corrupt kapitalistic software-industrial complex,
>then steal it. If it upsets your tummy to use a program for which
>you have no source code, take a pill and get over it. If you find
"take a pill and get over it." I was recently making fun of the uncoived
opinion of the unwashed masses that aesthetic sense should be dealt with
so trivially. Nice to see the same stupid viewpoint in here. Perhaps
your ex-wife should have taken her drugs to make her boring and more like
what you wanted?
>your 13 Gigabyte disk is running out of space, you can probably
>afford to delete your Captain Kirk .gif files. Use the software.
I don't know what the fuck that's all about, I assume you're just
comparing me too much to your ex-wife, since none of that has any
basis in any reasonable argument.
>Find out what it can and cannot do. Get back to us in a couple of
>weeks and maybe we can have an intelligent discussion about FPGAs.
No we can't because I bet pennies to dollars (you're the high-paid
professional) that you don't know shit about what really goes on inside
that software because all you're concerned about is the fact that it
works.
Ben Franchuk
> 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?
>
As a hobbyist, I looked at what little there was on HDL's and went
back to drawing schematics. I have yet to a nice small RTL compiler
and simulator. FPGA's also don't decompose to normal logic, that also
make things harder,and FPGA's can have too much over head for the logic
used.
Take carries in ADDERS, carry propagation takes a lot of CLB's
unless you use ripple carry ( a long time ) or a chip with
fast ripple carry.(A faster long time).
A ripple carry is two-gate delays, and that speed 1/3 (see note)
that of the CLB logic. That implies for simple logic,a FPGA is 1/3
slower than real gates. Note: I am guessing at the 1/3 figure as I don't
have
a data sheet handy.
Don Husby
> There are a lot of pompous asses too. People who stare at disbelief at
> every newbie constantly insisting that the problems the professionals
> tackle with on a daily basis are far too difficult for a newbie to even
> understand are pompous asses and there's no other way around it, no
> matter how much hardware they've designed.
Usually, comp.arch.fpga is helpful to newbies. If you want to have a
sensible discussion about hacking FPGAs, there are many here who could
participate. There are many of us who have hacked at the FPGA tools
and can speak from experience. You are not one of them.
We stare at you in disbeleif because it's warranted. That you seem to
think you understand the problem without ever having done an FPGA design
is a measure of how clueless you really are. "There's no other way around it."
This is not pomposity. This is reality. Pomposity is you taking
the position that we are the ones who are clueless.
> Everyone here takes the title professional too seriously. In the
> software movement we've learned ....
You guys don't own guns do you? At least we professionals don't take ourselves
so seriously as to call ourselves a "movement".
Dave Vanden Bout
> smaller 4000 series parts on an XESS board. That part is supported by the
> student edition of the software. Why, XESS sells a bundled package with
> their board, the student edition software (without VHDL, mind you) and a
> lab text book for about $200. I think that package is one of the best
> values for someone starting out with FPGAs. Learn the basics in a proven
I've stayed out of this religious war on purpose, but I do need to correct this statement just a bit. The Xilinx Student Edition software version 1.5 does have VHDL and Verilog capabilities. (The older version 1.3 only had ABEL and schematics.) But thank you for the complimentary statements about our products.
Now you can all go back to the jihad.
--
|| Dr. Dave Van den Bout XESS Corp. (919) 387-0076 ||
|| de...@xess.com 2608 Sweetgum Dr. (800) 549-9377 ||
|| http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||
Ben Franchuk
>
> You just have to design your logic with the FPGA structure in mind :-). Look
> for Jan Gray's series of articles on implementing a RISC in an FPGA.
>
> As for testing, true you can't stick a probe in the chip, but then there are few
> chips these days that you can do that too. Instead, there are other techniques
> including simulation, test vectors, dedicated test points, and my favorite, using
> reconfiguration to modify the circuit to get at the data you want to observe.
>
feature of FPGA's. In hardware with the EXCESS amount of programmability
FPGA's
do have the advantage of being able to provide test points and logic
checks that are often ignored do to lack of gates on simpler designs.
A traditional front panel, now can make a come back along with state
checking the machine with a long shift register taking a snapshot of the
machine.
Nicholas C. Weaver
your posts are becoming more ridiculous and deliberately inflamative,
george.
You have asked for the advice of the experts, and ignored the
advice.
You accuse people of not "bothering to understand what's going
on", when those in this group are intimatly concerned with how the
tools operate and the architectures being targeted.
If I send you a free copy of the student edition Xilinx tools,
will you go away? We have a couple of textbook evaluation copies with
CDs in the back, sitting in our office. I could also toss you a copy
of the Altera student tools, same thing there.
To everyone else, let us no longer respond to this thread of
george's. Ignore it, and it should go away.
--
Nicholas C. Weaver nwe...@cs.berkeley.edu
Andrew Brown
news:8bfvke$rkd$1...@jetsam.uits.indiana.edu...
> In article <38DB7BC3...@ids.net>, Ray Andraka wrote:
> >Not at all. It's just that I think it makes more sense to first work
with
> >what is out there before condemning it.
To be fair - i haven't seen him condem it. Sure, he thinks it's crap and
won't install it - but i reckon thats more of a preference for him than a
bitch at the tools. I agree he'd learn a lot about the architecture by
doing it but there's nothing wrong with learning the hard way if thats what
he wants.
Greg -
As for FPGA vendors releasing specs for things they consider trade secrets -
forget it.
Sure, the competition MAY have cracked it already, but that doesn't mean
that the vendors are going to make it easy for them (they may have missed
something). You wouldn't expect Intel to hand AMD the source code for the
Xeon just because AMD have something compatable ! If they released the
specs they would be telling us a lot more about the internal architecure of
the chip than an API would say about the algorithms used in a software
library.
So, if your going to do this i'm afraid it's time to reverse engineer the
bit-stream. But be careful - and invalid bit stream can physically damage
the chip, and that's going to cost you more than buying the software.
> Think of how much time Xilinx would have saved you if they'd just
> released bitstream specs. :)
Actually it wouldn't save them time. As a (commercial) user, i'd still
expect Xilinx to produce the tools - even if they produce the specs. So
they have to publish more.
> >My point is, I don't think the tools are nearly as limiting as you
percieve
> >them to be. How can you know what the limits are if you've never touched
> >the tools or the devices????
>
> It would be nice if they'd let me try to do it the cheap way before
> forcing me to buy the tools rather than vice versa.
I'd be interested out of curiosity ... but it'll never happen ...
A.
Theron Hicks
Ben Franchuk wrote:
> 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)?
>
> True they have had more resources, and time to develop the code,but you
> can bet marketing pressure to get the product out the door. This is a PC
> vs Mac
> type problem we have here. Both people have valid view points, but OPEN
> is generaly a lot better than closed, look at LINUX vs WINDOWS.
Perhaps you should use a different model. Compare linux or windows against Mac.
I am not a fan of apple but the fact is that they do not have a buggy op system.
The reason is that the whole system is _closed_. Similarily the Xilinx system is
closed in the sense that they do ALL the hardware and in a sense, all the
software. (i.e. the FPGA programming software, not _unfortunately_, the PC op
system on which I am running.) Thus the system seems to work quite well. I am a
new Xilinx customer but frankly I am impressed. The software works as designed
(mostly). The hardware works as designed (mostly). The customer support is
good. They take the time to make sure that my questions are answered fully. The
only problem I see at present is in the documentation. All the stuff is there
but it is somewhat disorganized. (perhaps this is due to the fact that it covers
so many devices.) The only serious problem I had with my first design was in
getting the bitstream to properly activate the FPGA from a serial EEPROM.
(master serial mode. They claim that slave serial is the most popular. Not for
a single FPGA system.... A little more frustrating, for my master serial system
I needed to have done activate at clock 4 not clock 1. The software has that
option but it was buried a little deep and I didn't know that I needed to be
concerned about it.
All in all a pretty decent product that does what it is intended to do. The
target market is not the few hackers out there but the millions of potential
applications in industry. Think about it, do you want to waste your support
money on the 1 or 2 unit customer or the 10,000 to ??? unit customer. I'll go
with the quantity any day and so did Xilinx apparently.
>
>
> >
> > 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.
> >
> I agree let the COMPUTER grid away at the problems,but lets not
> hide information. Well software XYZ has a bug that generates the wrong
> routing table in the final output format. How can you find such a bug
> if nobody but the vender can read the format and they don't time to
> modify
> the software?
Theron Hicks
e...@riverside-machines.com.NOSPAM wrote:
> On 23 Mar 2000 23:03:28 GMT, g...@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 take it you can really see the electrons flowing. OK.. The scope is roughly
equivalent to a timing analyser.
>
>
> 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
Theron Hicks
e...@riverside-machines.com.NOSPAM wrote:
> On 23 Mar 2000 23:03:28 GMT, g...@ugcs.caltech.edu (glen
> herrmannsfeldt) wrote:
>
> >I remember building things like digital clocks out of TTL. A great
> >way to learn about digital logic. How are our kids going to learn this?
> >
> >They will have to learn starting with FPGA's. Probably small ones, though.
> >An FPGA starter kit equivalent to a bag full of 74xx chips would not
> >be a bad way to learn digital logic design. I was part of a discussion
> >at FCCM95 on just this subject.
> >
> >-- glen
>
> I think it's very hard to learn digital design with FPGAs - much
> better to have a big PCB, a scope, lots of TTL, a hairdryer and a
> freezer can. You really need to get in and physically see the signals
> to understand what's going on.
>
> I've been doing some interviewing recently, for VHDL people. All were
> electronic engineers, and also claimed to know and use VHDL. Out of
> about 10 or 12 people:
>
> (1) about half couldn't draw up a gate-level 2->1 multiplexer
> (2) most didn't know what a JK was
> (3) almost nobody could design a gate-level counter, or
> (4) knew how to create an FSM from scratch, with pencil and paper
> (5) very few knew anything about line termination
> and so on.
>
Evan,
Where are you hiring?
1. I can draw a gate level 2:1 MUX
2. I do know what a JK is and how to use it.
( I would have to look up how to build one from gates.)
3. Gate level counter... Once I got a gated D flip-flop then I could do it.
(Or anything higher level.) But why would you want to for most real world
applications? (posible exceptions high speed or low noise.. Or special count
sequence. Then see FSM.)
4. FSM... No problem.
5. Line termination.. No problem here. Series, Thevenin, or whatever.
6. How about line impedances of a PCB trace?
7. How about ground planes?
Now to be fair...
1. What are you paying?
2. How about job security?
3. How about unpaid overtime?
4. How about fringes?
Please do not misunderstand me but, do you see my point? Perhaps you cannot
draw the best candidates because your company is not the best employer? I
really don't know so please do not be offended. I just know that some companies
and some engineers deserve each other. When the two match up its great.
Unfortunately that does not always happen.
Don Husby
> In article <8bg2qr$cqp$1...@info3.fnal.gov>, Don Husby wrote:
> >gale...@sietch.bloomington.in.us (Greg Alexander) wrote:
> Getting rid of the bugs is small compared to the peace of mind of
> understanding the software.
Right, I got it from your first few posts. This is a spiritual thing
for you. Nothing is stopping you from understanding. I'm just saying
you'd get a little more credibilty on that point if you took the time
to do some of that unsderstanding before shooting your mouth off.
And, like the religous fanatics, if you feel you have to flog yourself
in order to unsderstand it, be my guest.
(I'll leave a break here for you to point out how intolerant I am. It's
my spiriual quest to make fun of people who flog themselves. I hope
you have no problem with that.)
> >Well, it's a nice dream, Greg, and maybe it's sometimes true for real
> >artists and geniuses, but it's clear from your posts that you barely
> >have a clue. That you haven't even seen the commercial tools that you
> >fear so much. That you haven't ever done an FPGA design.
>
> I have no clue about FPGA, and at one time, neither did you.
When I had no clue about FPGAs, I had the sense not to go spouting
off about it.
> That's why she's your ex-wife. Your judging of activities by OTHER people
> as complete wastes of time is stupid.
Stupid? That sounds pretty judgemental. Pot, kettle, black.
I reserve the right to make any judgements I want. I stick by them.
She was a kook. She did hard time in the nut house to prove it.
I thank my lucky stars that she's my ex wife.
> I don't mind if you don't have any
> intention to do what I'm doing, but I don't see why you mind that I do it.
I don't mind. But I have an opinion. Is this a problem?
> Your ex-wife may have an idea there, working as a janitor.
I don't think she'd agree with that.
> "take a pill and get over it." I was recently making fun of the uncoived
> opinion of the unwashed masses that aesthetic sense should be dealt with
> so trivially.
I'll stack my aesthetic sense against yours any day. Let's do lunch.
> >your 13 Gigabyte disk is running out of space, you can probably
> >afford to delete your Captain Kirk .gif files. Use the software.
>
> I don't know what the fuck that's all about, I assume you're just
> comparing me too much to your ex-wife, since none of that has any
> basis in any reasonable argument.
Yes you do. It's an ad-hominem attack for the purpose of pointing out
how silly your disk-space worries are. That you chose to respond in
kind *without* apparent purpose allows me you use the "pot,kettle,black"
rule again.
> >Find out what it can and cannot do. Get back to us in a couple of
> >weeks and maybe we can have an intelligent discussion about FPGAs.
>
> No we can't because I bet pennies to dollars (you're the high-paid
> professional) that you don't know shit about what really goes on inside
> that software because all you're concerned about is the fact that it
> works.
I'll stack my knowledge of the FPGA and the software internals against
yours any day. You'll lose your pennies, but you might learn something.
Let's do lunch.
Jason T. Wright
wrote:
>[snip]
> The only serious problem I had with my first design was in
>getting the bitstream to properly activate the FPGA from a serial EEPROM.
>(master serial mode. They claim that slave serial is the most popular. Not for
>a single FPGA system.... A little more frustrating, for my master serial system
>I needed to have done activate at clock 4 not clock 1. The software has that
>option but it was buried a little deep and I didn't know that I needed to be
>concerned about it.
>
I've always used master serial for the first device in a chain. But, I've
usually also included the option to do "slave serial" to use the download
cable. (My current design uses in-circuit programmable EEPROMs, so "master
serial" is the only mode used.)
Jason T. Wright
Cygnion Corp
Jason T. Wright
Jason T. Wright
Cygnion Corporation
Gary Watson
news:38DB7BC3...@ids.net...
> Not at all. It's just that I think it makes more sense to first work with
tools
> for a while, you'll get a) a real good feel for the FPGA architecture,
what
> works, what's fast and whats not, b) an understanding of what the
strengths
> and weaknesses of the current tools are, and c) some focus for your
> improvement efforts.
I think an analogy would be if Microsoft and Intel introduce a new PC which
is pretty attractive, but all the opcodes are secret and the only supplied
programming language is Visual Basic. No opportunity to write assembly, or
c, or lisp, or anything else. Microsoft would argue that you can do
virtually any legitimate task under Visual Basic, and that ought to be good
enough for you. If you don't like it, buy somebody else's PC. Microsoft
and Intel might argue that this is the only way that they can guarantee a
crash-free environment. I suspect that most people would simply shrug their
shoulders, buy a copy of MS Office, and get on with using the system,
particularly if the crash-free promise turned out to be mostly true. What
Greg is proposing is breaking the seals on the PC, reverse engineering the
machine language, working out a little assembler, maybe writing a c
compiler, etc etc until he's got it running Linux. Depending upon the
eventual goal, it isn't an unrealistic idea. A number of people have
completely reverse-engineered games consoles and wrote PC simulators for
them. Is it wrong to learn how to be a computer scientist by starting with
6502 machine language and then working up? Must people start at Visual C++
and work their way down? Philosophically, I think issuing the bits to a
Xilinx is an excellent way to get a detailed understanding of how the CLBs
work.
Now to throw cold water on what I just said: There's no way in hell that
Xilinx wants Greg or anybody else making their tools unnecessary. As they
told me back in 1988, Xilinx is first and foremost a software company. They
want to license you their intellectual property in bite-size, 12 month,
chunks. Their corporate strategy implies that it would be suicidal to help
people circumvent their profitable tools.
What I think Greg wants is a FPGA equivalent of PIC. They virtually give
away the development tools so that you will use their (sucky)
microprocessors. Works for them, apparently. It's just another way of
doing business.
What I don't understand is why Xilinx doesn't publish the bitstream format
for the low-end parts, which only require the $100 software package (which I
have recently discovered is often given away to prospective customers). It
doesn't seem that they stand to lose much revenue. What would be even more
amusing is if Altera published the Xilinx bitstream (which no doubt they
reverse-engineered long ago), and in retaliation, Xilinx published the
Altera bitstream....
--
Gary Watson
ga...@nexsan.sex (Change dot sex to dot com to reply!!!)
Nexsan Technologies Ltd.
Derby DE21 7BF ENGLAND
http://www.nexsan.com
e...@riverside-machines.com.nospam
<hick...@egr.msu.edu> wrote:
>Now to be fair...
>1. What are you paying?
>2. How about job security?
>3. How about unpaid overtime?
>4. How about fringes?
>
>Please do not misunderstand me but, do you see my point? Perhaps you cannot
>draw the best candidates because your company is not the best employer? I
>really don't know so please do not be offended. I just know that some companies
>and some engineers deserve each other. When the two match up its great.
>Unfortunately that does not always happen.
It's not my company - they're just currently paying my bills. They're
good employers, cubicles notwithstanding, pay well, they're
leading-edge (3G wireless), and they've got an IPO on the way. The
problem is simply that it's very difficult to find *any* engineers in
the UK at the moment. If anyone wants to relocate to Cambridge mail
me, and I'll give you details. They've got positions in FPGA/ASIC,
DSP, and algorithm development.
Evan
Don Husby
> What would be even more
> amusing is if Altera published the Xilinx bitstream (which no doubt they
> reverse-engineered long ago),
I'm curious to know why you think Altera would spend the effort do decode
Xilinx's bitstream format. What could they possibly do with it?
The data sheets pretty-much tell you what the internal architecture does.
They know that somewhere in the bit stream, there's a bit that controls
switch X, why would they care which particular bit it is?
muzo
>FPGA Hardware design is _hard_ and the
>software tools quality is not the main problem. When the program you are
>developing does not work the way you expect it you use a debugger,
>set-up breakpoints, step trough your code and whatever else you software
>people do when you hunt bugs. Normally you cannot stop an FPGA and you
>cannot look inside it to see what went wrong.
I'd say this is a problem related to software tools quality. Is there
any reason why anyone can't design a built in test tool to capture the
running state of an FPGA, set triggers for start and stop of the
capture, even stop execution etc.? What makes you thing that any
software which controls realtime events can be stopped more easily
than an FPGA? One can design great debugging tools for FPGAs and very
recently FPGA vendors are waking up to this too.
> Another major difference
>is that software is usually sequential while inside the FPGA everything
>happens in parallel.
There are systems with multiple processors controlling realtime
events. Things happen in parallel there too.
What I am trying to say is that there is not much difference between
debugging sopthisticad systems, whethere they are hardware or software
systems.
Peter Alfke
Gary Watson wrote:
Now to throw cold water on what I just said: There's no way in hell that
Xilinx wants Greg or anybody else making their tools unnecessary. As they
told me back in 1988, Xilinx is first and foremost a software company.
No way! We make 95% of our revenue from chips. We say that we are a "solutions company" offering tools, cores, chips, and support. But our revenue comes from chip sales.
They
want to license you their intellectual property in bite-size, 12 month,
chunks. Their corporate strategy implies that it would be suicidal to help
people circumvent their profitable tools.
Wrong again! The tools are hardly profitable, and need not be profitable. They are expensive in R&D, and they are vital to our chip sales. But they are not a major stream of revenue.
What I don't understand is why Xilinx doesn't publish the bitstream format
for the low-end parts, which only require the $100 software package (which I
have recently discovered is often given away to prospective customers). It
doesn't seem that they stand to lose much revenue. What would be even more
amusing is if Altera published the Xilinx bitstream (which no doubt they
reverse-engineered long ago), and in retaliation, Xilinx published the
Altera bitstream....
If a designers hangs himself in the gory details of the architecture, routing, and the bitstream generation, we cannot say: "Sorry, Charly, your fault". Since he is our customer, with perhaps substantial hardware purchases, we would have to bail him out. We would have not only a moral, but also a financial incentive to do that.
This kind of support could become a nightmare. It's complicated enough,
the way it is.
We do have a feel for how much time and effort our customers invest
in their designs that, ultimately, get implemented in our parts. And we
even understand how much depends on the proper and trouble-free operation
of our chips, often completely out of proportion to the chip price.
Therefore, we have to, and we want to, provide good support.
Just my opinion
Peter Alfke
muzo
>> I've been doing some interviewing recently, for VHDL people. All were
>> electronic engineers, and also claimed to know and use VHDL. Out of
>> about 10 or 12 people:
>>
>> (1) about half couldn't draw up a gate-level 2->1 multiplexer
>> (2) most didn't know what a JK was
>> (3) almost nobody could design a gate-level counter, or
>> (4) knew how to create an FSM from scratch, with pencil and paper
>> (5) very few knew anything about line termination
>> and so on.
this reminds me the dilbert cartoon where a couple of bearded, bald
guys talk about having to code only with ones and zeros and dilbert
tops them off with "then you are lucky, we didn't even have ones. We
had to write code only with zeros". Most people these days are not
designing with ones and zeros. With million gate SoC designs, you
can't fill a chip by desiging at the level of 2x1 muxes or JK
flip-flops. You have to use HDLs and behavioral compilers etc.
Rickman
George) is just saying that he wants to get enough information from
Xilinx so that he can develope his own basic, crude, but effective tools
to design FPGAs in the way he wants and without being dependant on
anyone who won't share the source for the software. That's it, end of
request.
As a result, dozens of people (including myself initially) try to talk
him out of this "silly" idea and tell him he should conform to doing
FPGA design the way that we do it. Some of us even go so far as to adopt
hostile tones and make posts asking others to ignore this person and his
request.
If that is not intolerance, then I don't know what is. Don seems to have
a lot of issues because this guy reminds him of his ex-wife and her
eccentric behavior. Fine, but you divorced the ex-wife because you
didn't want to deal with her anymore, I assume. Why not just ignore Greg
and consider you two to be divorced?
Nicholas goes so far as to call Gred "a flamer and a troll". I don't see
any of this. I see a person who has very specific ideas of what he wants
to do and is asking for help or support in doing them. Perhaps he is a
little harsh in his criticism of Xilinx and the users who tolerate the
supposed offences by them. But he is far from inflammatory in my
opinion. In fact this whole thread is opening my eyes to see how
defensive and narrow minded we seem to be as a group.
I have been a reader of a mailing list of Forth users which includes a
few people who have worked with Charles Moore on Forth chips. I don't
know that any of these chips will become mainstream commercial sucesses,
but they are very interesting from an academic sense and show what can
be done by a single person or a small team starting from nothing an
attacking a huge problem from scratch. As someone posted in an earlier
message, they succeeded in producing several chips while relying on
almost no tools from the outside. That is saying a lot!
So why do you (in the plural sense) need to feel so hostile toward
someone who wants to walk a different path and persue different goals
than your own? How about if we "all just learn to get along?"
BTW, on the suggestion of some others that bitgen is the only part of
the tools that contain the "secret" bitstream information. If that was
all there was to hiding the info, then it would be a weekend task to
reverse-engineer bitgen and role your own. It would be especially easy
to test since you can run both your own and the Xilinx one side by side
on a number of test cases.
But I would be willing to bet that much of the details of the file
format that goes into bitgen are not explained anywhere. So even if you
figure out bitgen, you still have to figure out what all the control
points are and what they do.
Don Husby wrote:
>
> gale...@sietch.bloomington.in.us (Greg Alexander) wrote:
> > In article <8bg2qr$cqp$1...@info3.fnal.gov>, Don Husby wrote:
>
> > >gale...@sietch.bloomington.in.us (Greg Alexander) wrote:
> > Getting rid of the bugs is small compared to the peace of mind of
> > understanding the software.
>
> Right, I got it from your first few posts. This is a spiritual thing
> for you. Nothing is stopping you from understanding. I'm just saying
> you'd get a little more credibilty on that point if you took the time
> to do some of that unsderstanding before shooting your mouth off.
> And, like the religous fanatics, if you feel you have to flog yourself
> in order to unsderstand it, be my guest.
> (I'll leave a break here for you to point out how intolerant I am. It's
> my spiriual quest to make fun of people who flog themselves. I hope
> you have no problem with that.)
>
> > >Well, it's a nice dream, Greg, and maybe it's sometimes true for real
> > >artists and geniuses, but it's clear from your posts that you barely
> > >have a clue. That you haven't even seen the commercial tools that you
> > >fear so much. That you haven't ever done an FPGA design.
> >
> > I have no clue about FPGA, and at one time, neither did you.
>
> When I had no clue about FPGAs, I had the sense not to go spouting
> off about it.
>
> > That's why she's your ex-wife. Your judging of activities by OTHER people
> > as complete wastes of time is stupid.
>
> Stupid? That sounds pretty judgemental. Pot, kettle, black.
> I reserve the right to make any judgements I want. I stick by them.
> She was a kook. She did hard time in the nut house to prove it.
> I thank my lucky stars that she's my ex wife.
>
> > I don't mind if you don't have any
> > intention to do what I'm doing, but I don't see why you mind that I do it.
>
> I don't mind. But I have an opinion. Is this a problem?
>
> > Your ex-wife may have an idea there, working as a janitor.
> I don't think she'd agree with that.
>
> > "take a pill and get over it." I was recently making fun of the uncoived
> > opinion of the unwashed masses that aesthetic sense should be dealt with
> > so trivially.
>
> I'll stack my aesthetic sense against yours any day. Let's do lunch.
>
> > >your 13 Gigabyte disk is running out of space, you can probably
> > >afford to delete your Captain Kirk .gif files. Use the software.
> >
> > I don't know what the fuck that's all about, I assume you're just
> > comparing me too much to your ex-wife, since none of that has any
> > basis in any reasonable argument.
>
> Yes you do. It's an ad-hominem attack for the purpose of pointing out
> how silly your disk-space worries are. That you chose to respond in
> kind *without* apparent purpose allows me you use the "pot,kettle,black"
> rule again.
>
> > >Find out what it can and cannot do. Get back to us in a couple of
> > >weeks and maybe we can have an intelligent discussion about FPGAs.
> >
> > No we can't because I bet pennies to dollars (you're the high-paid
> > professional) that you don't know shit about what really goes on inside
> > that software because all you're concerned about is the fact that it
> > works.
>
> I'll stack my knowledge of the FPGA and the software internals against
> yours any day. You'll lose your pennies, but you might learn something.
> Let's do lunch.
>
> --
> Don Husby <hu...@fnal.gov> http://www-ese.fnal.gov/people/husby
> Fermi National Accelerator Lab Phone: 630-840-3668
> Batavia, IL 60510 Fax: 630-840-5406
--
Rick Collins
rick.c...@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
Rickman
> they wanted me to pay $5000 for a piece of software so I could see if the
> Xilinx parts would be suitable for my application. I said to the Xilinx guy
> that they should give me the software for free like MMI did with Palasm, and
> if it worked they would make their money by selling me chips (after all, the
> tools only work with Xilinx chips). The Xilinx salesman explained that
> Xilinx is a *software* company, not a chip company. They only make chips so
> they can sell their development tools.
>
> I decided that I would ignore Xilinx for ten years, and revisit the issue.
> Twelve years on, I've decided to give them another chance, and so I'm
> looking at the Xilinx parts again. I'm sure they don't realize that they
> lost out on selling millions of Xilinx parts to go into my designs because
> they wouldn't give me their tools. I've been making do with PALs all
> these years...
>
> [As a side note, the issue in 1988 was whether you could really fit my
> intended design into their parts. I had an existing design, drawn by hand
> onto a bunch of C size sheets of vellum. The Xilinx guy was unwilling to
> refund my $5000 if the design didn't fit into the target part, even though a
> rough gate count made us think it should fit easily. He offered us a 30 day
> eval, but we judged that this would not be long enough.]
>
> --
>
> Gary Watson
> ga...@nexsan.sex (Change dot sex to dot com to reply!!!)
> Nexsan Technologies Ltd.
> Derby DE21 7BF ENGLAND
> http://www.nexsan.com
I have the same problem with paying for the software. But you should try
to distinguish between a lousy salesman and a lousy company. I don't
think Xilinx has ever considered themselves to be a software company.
They charge for the tools just because they need to balance the revenue
against the costs of providing each the hardware and the software. The
software costs are so large that if they just absorbed that cost into
the hardware revenue stream, they would have to charge enough more for
the chips that they would lose some of the high volume sales and their
competition would gain. So instead they will give away tools if a
customer is likely to be a high volume user of parts. This is why I
think you got a lousy salesman. He should have reconized the potential
gain and gotten you a free copy.
The only companies that don't charge for their tools are the ones that
can't compete directly on an equal footing. They get their sales by
being novel in some way, like Atmel. They have a hard time competing
with Xilinx or Altera if you just look at the parts. There are a few
niche applications which they do well, but for the most part if they did
not give away their tools, they would not get many customers.
Rickman
> Everything we give out, we have to support. We are, therefore,
> reluctant to give out "unnecessary" details: NOT to keep them secret
> from Altera, NOT to make more money on the software sale, but
> fundamentally to limit our support cost.
>
> If a designers hangs himself in the gory details of the architecture,
> routing, and the bitstream generation, we cannot say: "Sorry, Charly,
> your fault". Since he is our customer, with perhaps substantial
> hardware purchases, we would have to bail him out. We would have not
> only a moral, but also a financial incentive to do that.
>
> This kind of support could become a nightmare. It's complicated
> enough, the way it is.
> We do have a feel for how much time and effort our customers invest in
> their designs that, ultimately, get implemented in our parts. And we
> even understand how much depends on the proper and trouble-free
> operation of our chips, often completely out of proportion to the chip
> price.
> Therefore, we have to, and we want to, provide good support.
>
> Just my opinion
> Peter Alfke
>
Peter, I want to understand this line of reasoning since I really don't
see the rational behind keeping the bitstream secret. Are you saying
that if Xilinx gave out the bitstream format and a customer of the chips
bought a third party toolset or rolled his own tools that Xilinx would
offer some form of support for issues related to loading the chips from
these tools? I can't see the basis for that.
Some others have posted analogies to microprocessors and the binary
instruction formats. I don't think that Intel or anyone else feels the
need to support any third party code generators in any way. If the chip
executes the instructions the way it is documented, then they are done.
Likewise, if a given bitsteam generated from third party tools does not
work in a Xilinx part, why would anyone expect Xilinx to even take a
look at the generated bitstream?
As I see it, that is the main reason that a user buys a Xilinx toolset.
You get support directly from the source. I looked at buying Neocad
software years ago and one of the many reasons that I didn't was because
they were "third party" and would never be able to supply a complete
support package. They never made any indication that Xilinx would
support their products in any way. In fact they said that Xilinx
initially was very uncooperative in providing any info on the bitstream
or chip designs. But they worked around that and Xilinx ultimately
decided that it was in their own interests to provide information to
Neocad, very much like what Greg is asking for. Information without
obligation for support.
Ray Andraka
muzo wrote:
> ...
> designing with ones and zeros. With million gate SoC designs, you
> can't fill a chip by desiging at the level of 2x1 muxes or JK
> flip-flops. You have to use HDLs and behavioral compilers etc.
Not so! I think it is much more important to make heavy use of hierarchy so
that you can reuse design pieces. Even where I am using HDLs, I'm still
doing alot of low level design (down at the primitives level). And yes, I
am doing million gate designs. I'm just finishing one now that reports
999,376 equivalent gates at the tools output in the fuller chip of the two
chip design - it runs at 134MHz in a 70 % full Virtex1000 -4. Guess what?
A good deal of the design was done at the primitive level complete with
floorplanning in the VHDL source. How long did it take? about 600 hours
including design verification. About 20% of that time was algorithm
development in Matlab.
--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email rand...@ids.net
http://users.ids.net/~randraka
e...@riverside-machines.com.nospam
>Theron Hicks <hick...@egr.msu.edu> wrote:
>>> I've been doing some interviewing recently, for VHDL people. All were
>>> electronic engineers, and also claimed to know and use VHDL. Out of
>>> about 10 or 12 people:
>>>
>>> (1) about half couldn't draw up a gate-level 2->1 multiplexer
>>> (2) most didn't know what a JK was
>>> (3) almost nobody could design a gate-level counter, or
>>> (4) knew how to create an FSM from scratch, with pencil and paper
>>> (5) very few knew anything about line termination
>>> and so on.
>
>this reminds me the dilbert cartoon where a couple of bearded, bald
>guys talk about having to code only with ones and zeros and dilbert
>tops them off with "then you are lucky, we didn't even have ones. We
>had to write code only with zeros". Most people these days are not
>designing with ones and zeros. With million gate SoC designs, you
>can't fill a chip by desiging at the level of 2x1 muxes or JK
>flip-flops. You have to use HDLs and behavioral compilers etc.
I can't agree. I use HDLs all the time, to fill "million gate"
devices. HDLs and behavioural compilers are just tools. You can
have the best chisel in the world, but it's not going to turn you into
Michelangelo.
Evan
Gary Watson
news:38DBF184...@yahoo.com...
> > I had a similar discussion with Xilinx back in 1988 or thereabouts, when
> > they wanted me to pay $5000 for a piece of software so I could see if
the
> > Xilinx parts would be suitable for my application. I said to the Xilinx
guy
> > that they should give me the software for free like MMI did with Palasm,
and
> > if it worked they would make their money by selling me chips (after all,
the
> > tools only work with Xilinx chips). The Xilinx salesman explained that
> > Xilinx is a *software* company, not a chip company. They only make
chips so
> > they can sell their development tools.
> >
> > I decided that I would ignore Xilinx for ten years, and revisit the
issue.
> > Twelve years on, I've decided to give them another chance, and so I'm
> > looking at the Xilinx parts again. I'm sure they don't realize that
they
> > lost out on selling millions of Xilinx parts to go into my designs
because
> > they wouldn't give me their tools. I've been making do with PALs all
> > these years...
> I have the same problem with paying for the software. But you should try
> to distinguish between a lousy salesman and a lousy company. I don't
> think Xilinx has ever considered themselves to be a software company.
> They charge for the tools just because they need to balance the revenue
> against the costs of providing each the hardware and the software. The
> software costs are so large that if they just absorbed that cost into
> the hardware revenue stream, they would have to charge enough more for
> the chips that they would lose some of the high volume sales and their
> competition would gain. So instead they will give away tools if a
> customer is likely to be a high volume user of parts. This is why I
> think you got a lousy salesman. He should have reconized the potential
> gain and gotten you a free copy.
In 1988 I worked for a very small company. They weren't going to give me a
free copy of the development tools. My next job, though, was for a large
company where 100,000 piece production runs were not uncommon, and we once
did $1M in a year just on AMD PALs. Since I didn't know Xilinx I simply
didn't use them. I guess I was also still mad about the earlier experience,
so I didn't bother to learn.
At the small company in 1988, we weren't insisting on getting the software
for free. We simply wanted to be sure that our project would fit in one
part, and that it would run at the necessary speed. If after entering the
design and running the simulation the part didn't achieve our goals, we
wanted our $5000 back (more precisely, we wouldn't pay the five grand until
the simulation yielded the desired results). At that moment in history,
Xilinx represented a new and largely unproven idea and it was not obvious at
all to me that a real-world design would work well in the parts available at
that time, and we didn't have $5000 extra to throw away. An ASIC would have
only cost us $40k, because that's what we had been quoted, and would have
been several times faster I'm sure (the project was a minicomputer
emulator). I guess the boss was afraid of being ripped off, and was doubly
concerned when it appeared that Xilinx didn't have enough confidence in
their parts to let us have the software for the three or four months it
would have taken to learn the package, enter the design, and conduct the
simulation. If it worked, we would have paid the invoice, and started to
order modest quantities of FPGAs.
The Xilinx sales guy said that he would find us a service bureau who would
quote us on typing in our paper schematics and running the simulation. This
never happened, but even if it did, I doubt that it would have been cheaper
than buying the Xilinx software.
I don't want to leave the impression that I'm still torqued at Xilinx, in
fact, to the contrary, they seem to be making all the right noises. A
Xilinx FAE is coming to see me next week, and I'm going to go ahead and
order the tools that I need. It's just a shame the $100 package wasn't
around back in 1988.
Stuart Clubb
wrote:
>It's not my company - they're just currently paying my bills. They're
>good employers, cubicles notwithstanding, pay well, they're
>leading-edge (3G wireless), and they've got an IPO on the way. The
>problem is simply that it's very difficult to find *any* engineers in
>the UK at the moment. If anyone wants to relocate to Cambridge mail
Evan, I would like to re-qualify this ever so "slightly":
"It's very difficult to find any _good_ engineers in the UK"
The emphasis is on good as I can always find you average "grind-away"
guys that will move "for a few dollars more". Smart engineers are
already working out that have a significantly higher "worth" than
previously many of the giants of Electronic Engineering employment
would have them believe. Good engineers can be found but will only be
prepared to work for you if you are willing to offer the following:
Attractive workplace
Appropriate tools for the job
Responsibility and direct control ("make a difference" culture)
Challenge and variety in the job
Sensible salary
Bonuses/stock
Possibly even company cars (where required) or additional perks.
>me, and I'll give you details. They've got positions in FPGA/ASIC,
>DSP, and algorithm development.
Just out of interest, what DO they pay Evan?
Being a small (in number) organisation, Saros does not have to suffer
the trauma of recruiting that often. However, it just so happens that
we now have a new opening for an additional Internal
Application/Support Engineer to be based in our Wallingford Offices.
So if you are reading this and may be interested, contact me on my
work mail:
stuart "at" saros "dot" co "dot" uk
Cheers
Stuart
An employee of Saros Technology:
Model Technology, Exemplar Logic, TransEDA, Renoir.
www.saros.co.uk
Kelly Hall
Hash: SHA1
"Greg Alexander" <gale...@sietch.bloomington.in.us> wrote in message
news:8be3d8$npn$3...@jetsam.uits.indiana.edu...
> See, here's an application of eXtreme Programming: the productivity
> increases MORE THAN LINEARLY as your compile/link time decreases
> linearly.
I don't think the function is linear; in fact, I doubt it's even
monotonic. Once the compile/link time gets below a certain point,
there's a temptation for the brain to never get a chance to stop and
think about what's going on. This leads to the phenomenon called
'random walk programming' where the programmer starts fiddling with
code until "it works" without taking the time to understand what's
making the thing fail in the first place. I saw a lot of this
teaching C... I'm sure the whole thing is highly
programmer-dependent. Personally, I spend a lot more time running
lint than I do running the linker, or especially the debugger.
Kelly
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
iQA/AwUBON1xQ+O3tORmHE48EQLnQgCgw9eCi5w0VIIpmP01ycaI/59VZ5kAoOUm
bSf6Xuq9Ih6AEoFM565jg6z1
=1NuC
-----END PGP SIGNATURE-----
Zoltan Kocsi
> gale...@sietch.bloomington.in.us (Greg Alexander) wrote:
> > There are a lot of pompous asses too. People who stare at disbelief at
> > every newbie constantly insisting that the problems the professionals
> > tackle with on a daily basis are far too difficult for a newbie to even
> > understand are pompous asses and there's no other way around it, no
> > matter how much hardware they've designed.
>
> Usually, comp.arch.fpga is helpful to newbies. If you want to have a
> sensible discussion about hacking FPGAs, there are many here who could
> participate. There are many of us who have hacked at the FPGA tools
> and can speak from experience. You are not one of them.
He has never said that. He asked for the bitstream info and he was told
that if he needed that info, he was an ass.
> We stare at you in disbeleif because it's warranted.
IMHO, you stare at him at disbelief because you don't get his point.
> That you seem to
> think you understand the problem without ever having done an FPGA design
> is a measure of how clueless you really are.
I've done FPGA design, using the usual tools. I still would like to know
the bitstream. What is my level of cluelessness ? I'd be interested to
hand craft bitstreams, for fun. Does it degrade me a lot ?
> "There's no other way around it."
> This is not pomposity. This is reality. Pomposity is you taking
> the position that we are the ones who are clueless.
Well, he is right in the sense that a lot of people here does not seem
to have a clue about what he's talking about. He does not want to start
a one-man project to write open source FPGA toolchain (although I'm sure
he would join such a project as would I). He doesn't want to hack an
FPGA that can do video morphing in real-time. He wants to play with
that damned chip and do something which he would not be paid for but
from what he would learn a lot, plus it would be fun.
I remember when I built a 7-bit Johnson counter from germanium transistors.
It occupied most of my desk and drove 14 miniature lamps - a lit semicircle
running around on a circle (except when any FF went the wrong way :-).
It had absolutely no use whatsoever apart from me learning a lot about
flip-flops, counters, shift registers and so on.
Today you have FPGAs instead of Ge transistors. Ge transistors were fully
documented and you did not have to buy tools to use them. You could use
them even in reverse mode (C and E exchanged, was sometimes useful in
perverse designs) because you got all the info. FPGAs you can't use,
even if you bought them, for the company reserves the right to render
them operable.
It is like buying a radio but not being able to tune it without buying
the TunePack (tm) (available for both Windows'95 (tm) and WindowsNT (tm))
software, great discounts for educational institutes and bulk buyers.
Back to his unorthodox way of designing the FPGA: The fact that he
does not want to follow the traditional way of designing an FPGA does
not make him clueless. New things usually coming out from people who
don't follow the road. 99.99% of them makes a long sidetrack and comes
back to the road where all the others are marching. The 0.01% is the
one who is worth of not building a concrete fence on the roadside.
Give them a chance, let them try. If you ar right and the only way
of designing a chip is using the tools, or if Peter Afke is right and
making an FPGA tool is impossible without pouring millions of dollars
into a project like that, he'll buy the tools or give up and learn
plumbing. Why not give him the opportunity to try ?
> You guys don't own guns do you? At least we professionals don't take ourselves
> so seriously as to call ourselves a "movement".
He probably left out the word "free". Free software believers
have an agenda and goal and they are numerous enough so the
"movement" is warranted. They also are taken quite seriously
by some big companies because they smell big money.
All the above, however, has not much to do with Greg's original
request about the bitstream. He is not the first one and will not
be the last one to request it and then being told to piss off.
While I understand the vendors' coming up with all sorts of stuff
about why keeping the bitstream info secret will help us design
better chips and will also help to make the world a better place,
I can't really grasp why some of the "we professionals" mentioned
above jump on him for asking and stating that he does not want to
buy the Xilinx tools nor Windows to run them on ?
I, by the way, am quite curious why exactly the FPGA vendors keep
the bitstream info closed ? Both the "protecting the customers'
designs" and the "so that we don't have to support it" are quite
fishy PR-talk, as has been shown in the thread.
Obviously they're not going to tell but it's still an interesting
question (well, to me, at least).
Zoltan
--
+------------------------------------------------------------------+
| ** To reach me write to zoltan in the domain of bendor com au ** |
+--------------------------------+---------------------------------+
| Zoltan Kocsi | I don't believe in miracles |
| Bendor Research Pty. Ltd. | but I rely on them. |
+--------------------------------+---------------------------------+
Rickman
> I don't want to leave the impression that I'm still torqued at Xilinx, in
> fact, to the contrary, they seem to be making all the right noises. A
> Xilinx FAE is coming to see me next week, and I'm going to go ahead and
> order the tools that I need. It's just a shame the $100 package wasn't
> around back in 1988.
I understand your frustration. Xilinx has been run in somewhat different
ways over the years. Quite often I have wondered if the people running
it (or not running it as it sometimes appears from the lack of internal
organization or cooperation would indicate) really understand their
customers.
The $100 is really more of a marketing gimick than a truly useful
evaluation method. For some people this size limitation of this package
is not a problem, but for most, likely such as yourself, they can't do
anything useful in a 10K part (or what ever the largest part is that is
supported by this package).
As it happened, I got a similar package from Lucent which supports up to
a 30 K gate part. This was just the part that I wanted to use. So I was
set. But I expect that most of the time people basically waste a bit of
time playing with the cheap package and then have to buy the expensive
package to do their real work. The time they spent costs more than the
full package so that they likely should have just bought the thing in
the first place and been working on the full design from the start.
But I guess you have to come up the learning curve one way or the other
and it is hard to make that time useful to your project. Often the first
project you do ends up as a poor job, so it should be one that does not
tax the parts or the tools.