Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 21525

Article: 21525
Subject: Re: [REQ] download function of Xilinx CPLD
From: Thomas Hellerforth <hellerforth@amo.de>
Date: Fri, 24 Mar 2000 11:59:03 +0100
Links: << >>  << T >>  << A >>
Hi,
look at xilinx application note xapp 137: "configuring virtex fpgas 
from parallel eproms with a cpld". There you find a kind of schematic, 
you can use.

Chih-Zong Lin schrieb:
> 
> Dear sir:
> I am using Virtex XCV600 + CPLD 9536 + EPROM in my design.
> The design of Virtex has been finished.
> The CPLD+EPROM is used for downloading program image into FPGA.
> 
> I am wondering is there any source code/binary for CPLD
> so that I can use in my design?
> 
> Thanks.
> 
> Miller

best regards
-- 
Thomas                               //\\\\ 
                                    | ~ ~ |
                                   (  O O  )
 ___________________________oOOo______( )_____oOOo________
|    ____   __ __                      .                  |  
|   /    \_/  /  \ Thomas Hellerforth (hellerforth@amo.de)|
|  / /|           | AMO GmbH           (241) 8867-115     |
| / __  |\_/|     | Huyskensweg 25                        | 
|/_/  |_|   |_\__/  52074 Aachen, Germany                 |
|                                                         |   
|                                           Oooo          |
|_________________________________oooO______(  )__________|
                                  (  )       ) /
                                   \ (      (_/
                                    \_)
Article: 21526
Subject: Re: No- FPGA openness
From: a@z.com
Date: Fri, 24 Mar 2000 08:40:52 -0500
Links: << >>  << T >>  << A >>
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.

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

Greg Alexander wrote:

> In article <38db2d65.178191536@news.dial.pipex.com>,
> eml@riverside-machines.com.NOSPAM wrote:
> >On 23 Mar 2000 21:47:20 GMT, galexand@sietch.bloomington.in.us (Greg
> >Alexander) wrote:
> >
> >>Sorry, I thought you'd read some of my other posts...
> >
> >Are you serious? There are a lot of good, professional, engineers in
> >this NG. Sometimes it pays to read, and not write. It also reduces the
> >S/N.
>
> There are a lot of pompous asses too.  People who stare at disbelief at
> every newbie constantly insisting that the problems the professionals
> tackle with on a daily basis are far too difficult for a newbie to even
> understand are pompous asses and there's no other way around it, no
> matter how much hardware they've designed.
>         Everyone here takes the title professional too seriously.  In the
> software movement we've learned that professional means that you're
> managed by someone probably incompetent and that your software is released
> not when it's done but when the management says it needs to be done -- not
> a purely positive status (though there are advantages I guess).  In the
> hardware world you guys seem to still think that professional is a
> bonus just because you can't afford to do chip or PCB fab with your own
> money.

Article: 21527
Subject: Re: No- FPGA openness
From: Ray Andraka <randraka@ids.net>
Date: Fri, 24 Mar 2000 14:08:31 GMT
Links: << >>  << T >>  << A >>
Depends on how amny iobs are switching at once.  I had a customer last year who
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:

> 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.
>
> 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, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21528
Subject: Re: No- FPGA openness
From: Ray Andraka <randraka@ids.net>
Date: Fri, 24 Mar 2000 14:16:36 GMT
Links: << >>  << T >>  << A >>


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, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21529
Subject: Re: FPGA openness
From: Ray Andraka <randraka@ids.net>
Date: Fri, 24 Mar 2000 14:29:31 GMT
Links: << >>  << T >>  << A >>
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.

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.E8A07BF5@ids.net>, Ray Andraka wrote:
> >Greg,
> >
> >Out of curiousity, about how many FPGA designs have you done?
>
> Obviously 0.  I'm trying to find the information to get started.
> Out of curiosity, do you really think that people are all as limited as
> people who know what the limits are supposed to be?

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


Article: 21530
Subject: Re: FPGA openness
From: Ray Andraka <randraka@ids.net>
Date: Fri, 24 Mar 2000 14:33:50 GMT
Links: << >>  << T >>  << A >>
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.

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

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


Article: 21531
Subject: Re: No- FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 24 Mar 2000 14:36:17 GMT
Links: << >>  << T >>  << A >>
In article <38DB7064.6019191A@z.com>, a@z.com wrote:
>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.
Article: 21532
Subject: Re: No- FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 24 Mar 2000 14:42:01 GMT
Links: << >>  << T >>  << A >>
In article <38DB78BD.CD29A0F3@ids.net>, Ray Andraka wrote:
>
>
>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.
Article: 21533
Subject: Re: FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 24 Mar 2000 14:55:10 GMT
Links: << >>  << T >>  << A >>
In article <38DB7BC3.889F0994@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.  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.
Article: 21534
Subject: Re: FPGA openness
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Fri, 24 Mar 2000 15:00:20 +0000
Links: << >>  << T >>  << A >>
On Fri, 24 Mar 2000 09:58:04 +0100, Andreas Doering
<doering@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

"Logic: Not recommended for new designs." 
Article: 21535
Subject: Re: FPGA openness
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Fri, 24 Mar 2000 15:00:21 +0000
Links: << >>  << T >>  << A >>
On 23 Mar 2000 23:03:28 GMT, gah@ugcs.caltech.edu (glen herrmannsfeldt)
wrote:

>Brian Drummond <brian@shapes.demon.co.uk> writes:
>
>(snip.  If you don't know how we got here, read the other posts.)
>
>>You're right! Get yourself a TTL Data Book, a soldering iron (or
>>wire-wrap gun), a bag of 74LSTTL, a good scope and get busy. Good
>>experience, nothing secretive or inaccessible there, and precious little
>>investment either. (hey you did ask .... only it was straight 74TTL back
>>then!)
>
>A few years ago, I thought about exactly this problem.  When I was
>growing up, and apparently you, too, we had 74xx TTL to play with.
>The reason we had that, at $0.25/chip, was that computer makers were
>buying it in large quantities.  Now that computers are made with VLSI,
>and are more and more integrated, will those TTL chips still be available?
>
>I remember building things like digital clocks out of TTL.  A great
>way to learn about digital logic.  How are our kids going to learn this?

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

"Logic: Not recommended for new designs."  
Article: 21536
Subject: Re: FPGA openness
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Fri, 24 Mar 2000 15:00:22 +0000
Links: << >>  << T >>  << A >>
On 23 Mar 2000 17:44:11 GMT, galexand@sietch.bloomington.in.us (Greg
Alexander) wrote:

>In article <9nfkdssa8jmmqgecu3kad1p4f5625pnjvg@4ax.com>, Brian Drummond wrote:
>>On 22 Mar 2000 23:26:45 GMT, galexand@sietch.bloomington.in.us (Greg
>>Alexander) wrote:

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

- Brian

"Logic: Not recommended for new designs."
Article: 21537
Subject: Altering Xilinx FPGA version/ID after PAR
From: "Jamie Sanderson" <jamie@nortelnetworks.com>
Date: Fri, 24 Mar 2000 10:29:18 -0500
Links: << >>  << T >>  << A >>
Greetings;

There are a few things I'd like to do with Xilinx FPGA's (xc4000 or xcv/e).
However, I think they could both be implemented in similar ways.

First of all, I'd like to have a version/revision value within the FPGA
which would automatically track the one used in the Design Manager.

The second thing I want is to generate multiple bit files from a single one,
each of those files containing a unique identifier.

JBits seems like a potential candidate, but it's not particularly available.
Another possibility is the FPGA editor, but I don't believe you can run it
non-interactively.

Any ideas? For the first case, what I'd envision would be a black box which
could be instantiated into your code. It would have version and revision
outputs which match what is given in Design Manager. I wouldn't expect it to
simulate properly, but that's a minor issue. In the second case, the same
black box could be manipulated by an executable which you run on your bit
file, and which you provide the identifiers you require.

Thanks for reading this!

Cheers,
Jamie


Article: 21538
Subject: Re: FPGA openness
From: husby@fnal.gov (Don Husby)
Date: Fri, 24 Mar 2000 15:49:48 GMT
Links: << >>  << T >>  << A >>
Sigh.

galexand@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 <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab                          Phone: 630-840-3668
Batavia, IL 60510                                         Fax: 630-840-5406
Article: 21539
Subject: Re: FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 24 Mar 2000 16:05:54 GMT
Links: << >>  << T >>  << A >>
In article <8bg2qr$cqp$1@info3.fnal.gov>, Don Husby wrote:
>Sigh.
>
>galexand@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.
Article: 21540
Subject: Re: Clock disabling
From: "Andrew Brown" <andrewbr@nortelnetworks.com>
Date: Fri, 24 Mar 2000 16:11:45 -0000
Links: << >>  << T >>  << A >>
No cigars or miracle cures - just some ideas !

"bob elkind" <eteam@aracnet.com> wrote in message
news:38DA7546.4BC6E0BC@aracnet.com...
> This is an interesting entry level brain teaser...
> So here's my run at the problem...
>              ________          ________
> clk A   ____|        |________|        |________
>                ________          ________
> clk B   ______|        |________|        |______
>
> clk B is generated from clk A, through an AND gate.
> There is some (positive) delay between clk A (leading edge) and clk B
(leading edge).

Clocks can be generated in a number of ways . For example (This isn't a
recommendation - just starting a discussion !)

                        _______
 Main Clock             |     |
------------------------|     |          Clock A
          |             | and |-----------------
          |       '1' --|  1  |
          |             |_____|
          |
          |             _______
          |             |     |
          --------------|     |          Clock B
                        | and |-----------------
              Control --|  2  |
                        |_____|

With this scheme the delay through 'and-1' will equal the delay through
'and-2' when control is '1' - which is when the clock is generated - so the
skew is minimised !  The delay is different when the control is '0' but as
Clock B is disabled - who cares !

Ofcourse the control for the and gate needs to be synchronous so ...
                     ________________________   ______
                     |  ______              |   |    |
            Clock A  |  |    |              |--O|    |          Control
          --------------|    |                  | FF
|-------------------buf---
                        | FF |------------------|    |
                 Cont --|    |                  |____|
                        |____|

The two flops here use clock A (it would be hard to re-enable clock B is
they used that clock !), they'd also need to be floorplanned quite tightly.
The buffer shown may be needed to ensure that the clock is reenabled during
the low period of clock A to avoid glitches !

> For extra credit, come up with a circuit that will drive the AND gate
which will
> enable/disable clk B, without any "runt" pulses or clock glitches.
>
> -- Bob Elkind

> Nicolas Matringe wrote:
> >
> > Hi all
> > I was wondering if it was possible to have 2 clock domains (same
> > frequency) with the possibility to turn one of them off to reduce power
> > consumption (this would be done by pulling a pin high or low for
> > example)
> > --
> > Nicolas MATRINGE           DotCom S.A.

I'd stick with enabled flops and accept that the clock will be driven
throughout the chip.


A.


Article: 21541
Subject: Gate logic
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Fri, 24 Mar 2000 09:18:04 -0700
Links: << >>  << T >>  << A >>
eml@riverside-machines.com.NOSPAM 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.
>
   What is FSM?

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

Ben.
-- 
"We do not inherit our time on this planet from our parents...
 We borrow it from our children."
The Lagging edge of technology:
http://www.jetnet.ab.ca/users/bfranchuk/woodelf/index.html
Article: 21542
Subject: Re: No- FPGA openness
From: husby@fnal.gov (Don Husby)
Date: Fri, 24 Mar 2000 16:18:28 GMT
Links: << >>  << T >>  << A >>
galexand@sietch.bloomington.in.us (Greg Alexander) wrote:
> There are a lot of pompous asses too.  People who stare at disbelief at
> every newbie constantly insisting that the problems the professionals
> tackle with on a daily basis are far too difficult for a newbie to even
> understand are pompous asses and there's no other way around it, no
> matter how much hardware they've designed.

Usually, comp.arch.fpga is helpful to newbies.  If you want to have a
sensible discussion about hacking FPGAs, there are many here who could
participate.  There are many of us who have hacked at the FPGA tools
and can speak from experience.  You are not one of them.

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



--
Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab                          Phone: 630-840-3668
Batavia, IL 60510                                         Fax: 630-840-5406
Article: 21543
Subject: Re: FPGA openness
From: Dave Vanden Bout <devb@xess.com>
Date: Fri, 24 Mar 2000 11:22:57 -0500
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------D2703B39D9682F6AFFDE603A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> 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

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 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||


--------------D2703B39D9682F6AFFDE603A
Content-Type: text/x-vcard; charset=us-ascii;
 name="devb.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dave Vanden Bout
Content-Disposition: attachment;
 filename="devb.vcf"

begin:vcard 
n:Vanden Bout;Dave
tel;fax:(919) 387-1302
tel;work:(919) 387-0076
x-mozilla-html:FALSE
url:http://www.xess.com
org:XESS Corp.
adr:;;2608 Sweetgum Drive;Apex;NC;27502;USA
version:2.1
email;internet:devb@xess.com
title:FPGA Product Manager
x-mozilla-cpt:;-16464
fn:Dave Vanden Bout
end:vcard

--------------D2703B39D9682F6AFFDE603A--

Article: 21544
Subject: Re: FPGA openness
From: "Andrew Brown" <andrewbr@nortelnetworks.com>
Date: Fri, 24 Mar 2000 16:27:45 -0000
Links: << >>  << T >>  << A >>
"Greg Alexander" <galexand@sietch.bloomington.in.us> wrote in message
news:8bfvke$rkd$1@jetsam.uits.indiana.edu...
> In article <38DB7BC3.889F0994@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.


Article: 21545
Subject: Re: FPGA openness
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 24 Mar 2000 16:31:57 GMT
Links: << >>  << T >>  << A >>
	I've come to the conclusion that you are a flamer and a troll,
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                                 nweaver@cs.berkeley.edu
Article: 21546
Subject: Re: FPGA openness
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Fri, 24 Mar 2000 09:35:10 -0700
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> 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.
> 
Most of all that is done simulating, the design in software, a good
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.
-- 
"We do not inherit our time on this planet from our parents...
 We borrow it from our children."
The Lagging edge of technology:
http://www.jetnet.ab.ca/users/bfranchuk/woodelf/index.html
Article: 21547
Subject: Re: Clock disabling
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 24 Mar 2000 16:36:09 GMT
Links: << >>  << T >>  << A >>
	A quick & dirty solution:  Use a 2x clock as an input.  Have
clock A be the output of a divide-by-two clock divider.  Have clock B
be the output of a divide-by-two clock divider with a clock enable on
the flip flop, both driving out to bufgs to the rest of the chip.
Also, gives you a nice clean duty cycle in the process, if you ever
need the falling edge.

-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
Article: 21548
Subject: Re: FPGA openness
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Fri, 24 Mar 2000 12:23:22 -0500
Links: << >>  << T >>  << A >>


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?
>
> --
> "We do not inherit our time on this planet from our parents...
>  We borrow it from our children."
> The Lagging edge of technology:
> http://www.jetnet.ab.ca/users/bfranchuk/woodelf/index.html

Article: 21549
Subject: Re: FPGA openness
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Fri, 24 Mar 2000 12:35:46 -0500
Links: << >>  << T >>  << A >>


eml@riverside-machines.com.NOSPAM wrote:

> On 23 Mar 2000 23:03:28 GMT, gah@ugcs.caltech.edu (glen
> herrmannsfeldt) wrote:
>
> >I remember building things like digital clocks out of TTL.  A great
> >way to learn about digital logic.  How are our kids going to learn this?
> >
> >They will have to learn starting with FPGA's.  Probably small ones, though.
> >An FPGA starter kit equivalent to a bag full of 74xx chips would not
> >be a bad way to learn digital logic design.  I was part of a discussion
> >at FCCM95 on just this subject.
> >
> >-- glen
>
> I think it's very hard to learn digital design with FPGAs - much
> better to have a big PCB, a scope, lots of TTL, a hairdryer and a
> freezer can. You really need to get in and physically see the signals
> to understand what's going on.

I 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



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search