FPGA Journal Article
Kevin Morris
about FPGAs and the re-birth of the electronics hobbyist. My theory is
that electronics as a hobby went through a "dark age" period, maybe
from the early/mid 1970s until recently becuase of the inaccessibility
and cost of designing with state-of-the-art technology. Radio Shack
shifted their focus from 50-in-1 project kits and hobbyist parts to
selling toys, cell-phones, and stereo equipment.
Now, with the emergence of low-cost, high-capability FPGAs, development
boards, and design software, I see a new age of hobbyist activity
beginning (as often evidenced in this group).
I'm looking for a few people that would be willing to express views on
this topic for the article.
I know, Austin will probably post a strong technical argument that
Xilinx FPGAs are uniquely attractive to the hobbyist, somebody from
Altera will send me a Cubic Cyclonium prototyping paperweight (they're
very cool), and Actel and Lattice people will post just to remind us
that they have low-cost kits too, but I'm primarily interested in some
info from real, live, "working" hobbyists.
Any takers?
Hal Murray
Both Microchip/PIC and Atmel/AVR have starter kits under $100,
available from Digikey.
Anybody got a list of hobbyist friendly vendors? I'm thinking
of places like Digilent.
The problem with FPGAs and CPLDs that I see is getting the raw
parts in small quantities at hobbyist friendly stores.
Most distributors are interested in large volumes. They aren't
really setup for hobbyists.
The Xilinx store still doesn't carry the small Coolrunner IIs.
Digikey doesn't stock any of them.
--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
Antti Lukats
news:1137096913.2...@o13g2000cwo.googlegroups.com...
Spartan3E VQ100 on single sided toner transfer made PCB
http://xilant.com/content/view/35/2/
DIL24 (GAL like) Spartan3-100 based module works as
MMC card in card reader
http://xilant.com/content/view/33/55/
my FPGA protoboard pictures are lost unfortunatly
xilinx isnt actually the best for hobby because of the 3 power supplies
required
sometimes you can get it with 2 power supplies (if VCCIO is 2.5)
so all other vendors have an small advantage here, with the true single
supply
chips being the best, in generic it really looks like it may come to
DIY electronic rebirth again - if I can help here I would be glad -
there are so many thing any FPGA board can do because of
its reprogrammability
for true do it all yourself hobby bastler Lattice XP in TQ144
is possible the easiest to handle
so what info are you looking and what is it where you look
for takers ?
Actel has no low kits (no real low cost). for xilinx/lattice
kit prices start from 50USD 50EUR, for Altera has been same
all actel kits are 149USD+
the only interesting Actel thing is the Fusion starterkit and
that costs already 399EUR
--
Antti Lukats
http://www.xilant.com
Jim Granville
> I'm writing a feature article for FPGA Journal (www.fpgajournal.com)
> about FPGAs and the re-birth of the electronics hobbyist. My theory is
> that electronics as a hobby went through a "dark age" period, maybe
> from the early/mid 1970s until recently becuase of the inaccessibility
> and cost of designing with state-of-the-art technology. Radio Shack
> shifted their focus from 50-in-1 project kits and hobbyist parts to
> selling toys, cell-phones, and stereo equipment.
>
> Now, with the emergence of low-cost, high-capability FPGAs, development
> boards, and design software, I see a new age of hobbyist activity
> beginning (as often evidenced in this group).
There is also a parallel in the Microcontroller sector.
With most new devices having FLASH and OnChip debug, the level
of entry for capable in-system debug, has dropped.
SiLabs have a sub $10 USB ToolStick, Zilog had some sub $10
demos, and I think now have $39 Eval/Demo Boards.
Freescale have a new $50 promo USB system...
>
> I'm looking for a few people that would be willing to express views on
> this topic for the article.
> I know, Austin will probably post a strong technical argument that
> Xilinx FPGAs are uniquely attractive to the hobbyist, somebody from
> Altera will send me a Cubic Cyclonium prototyping paperweight (they're
> very cool), and Actel and Lattice people will post just to remind us
> that they have low-cost kits too, but I'm primarily interested in some
> info from real, live, "working" hobbyists.
Lattice have the OpenSource Mico8, and their MachXO means you can get
a tiny, but working, SoftCPU in one low cost chip.
AS Assembler has added support for the Mico8, giving a second ASM tool flow.
>
> Any takers?
<paste>
Hal Murray wrote:
> The Xilinx store still doesn't carry the small Coolrunner IIs.
> Digikey doesn't stock any of them.
Yes, alas, more signs of 'big company syndrome' from Xilinx :(
How hard can it have been to have ensured the newish '32A/64A'
were there, before they yanked the older ones.... ?
( and in the new packages too ?! )
With the Webstore as it is now, users might think any/all of
a) They do not want these in new designs
b) There is some supply problem, with smaller CPLDs
c) Xilinx is phasing out emphasis on smaller CPLDs
[Xilinx are now last in release of new CPLD devices..]
-jg
Brian Drummond
wrote:
>I'm writing a feature article for FPGA Journal (www.fpgajournal.com)
>about FPGAs and the re-birth of the electronics hobbyist. My theory is
>that electronics as a hobby went through a "dark age" period, maybe
>from the early/mid 1970s until recently becuase of the inaccessibility
>and cost of designing with state-of-the-art technology. Radio Shack
>shifted their focus from 50-in-1 project kits and hobbyist parts to
>selling toys, cell-phones, and stereo equipment.
er, no, I wouldn't have said the late 70's or 80s were in any way a dark
age for the hobbyist...
admittedly around 1980 all a hobbyist had to play with was the Z80 or
6502, but at the time they WERE state of the art. It was probably the
last time a hobbyist could build a computer, modify or even write the
BIOS, and actually understand pretty much every detail of a machine
capable of running the leading OS and applications.
>Now, with the emergence of low-cost, high-capability FPGAs, development
>boards, and design software, I see a new age of hobbyist activity
>beginning (as often evidenced in this group).
If anything, it's a return to those days, with Linux in the place of
CP/M, (though Linux is too big to _really_ understand), and with WebPack
in the place of that fat orange book (you know the one), 16-pin sockets,
and the wire wrap tool.
Pete A will probably maintain the fat book was actually bright red!
>I'm looking for a few people that would be willing to express views on
>this topic for the article.
> but I'm primarily interested in some
>info from real, live, "working" hobbyists.
Digital clock, 1978.
FM tuner, 1979.
Dictation type cassette recorder, hacked for hi-fi stereo headphone use,
in progress summer 1980. Yes, the summer the Walkman came out. Grrr...
Richard Russell Board (Z80, 32k later 64k RAM; a BBC OS (not BBC Micro!)
and later CPM 1982,3,4) An oddball (but good!) in the ZX80, ZX81 era.
Mahogany laptop (64180 based) ca 1987, but it was getting obsolete
faster than I could finish it...
Vacuum tube amp restorations, various.
Some deaf microphones, ca 1995, until I gave up and used commercial
capsules. (The electronics and enclosures were my own though)
Don't know if these count.
...then working from home and non-electronic hobbies started taking
over...
- Brian
Austin Lesea
Actually, I do have some possible places for you to go look:
University robotics competitions
The DARPA intelligent vehicle crowd (Berkeley's motorcycle used V2 Pro
for vision, just too bad they used a two wheel vehicle, and it fell over
and were disqualified!). The Mars rovers used Virtex' for control, but
they have six wheels!
Amateur radio software defined radio: ARRL Magazine has their technical
rag, http://www.arrl.org/qex/
which has had articles of SDR using both Xilinx and Altera FPGAs. There
is even a hobby project SDR that comes with a FPGA.
Good luck,
Austin
Anonymous
time line. I was etching my own PC boards, hand assembling boards, and
burning my own proms up to the early 90s. The "dark age" was probably in the
90s when everything switched over to surface mount.
I think the renaissance now is hacking WITHOUT a soldering iron, e.g.
hacking tivo or ipod software, building custom mame video machines,
re-flashing boxes like linksys routers, etc.
"Kevin Morris" <ke...@techfocusmedia.com> wrote in message
news:1137096913.2...@o13g2000cwo.googlegroups.com...
Mike Harrison
>I'm writing a feature article for FPGA Journal (www.fpgajournal.com)
>about FPGAs and the re-birth of the electronics hobbyist. My theory is
>that electronics as a hobby went through a "dark age" period, maybe
>from the early/mid 1970s until recently becuase of the inaccessibility
>and cost of designing with state-of-the-art technology. Radio Shack
>shifted their focus from 50-in-1 project kits and hobbyist parts to
>selling toys, cell-phones, and stereo equipment.
I think it was more about the fact that it became less possible to build things for less money than
you could buy them for...
>
>Now, with the emergence of low-cost, high-capability FPGAs, development
>boards, and design software, I see a new age of hobbyist activity
>beginning (as often evidenced in this group).
>
>I'm looking for a few people that would be willing to express views on
>this topic for the article.
>
>I know, Austin will probably post a strong technical argument that
>Xilinx FPGAs are uniquely attractive to the hobbyist, somebody from
>Altera will send me a Cubic Cyclonium prototyping paperweight (they're
>very cool), and Actel and Lattice people will post just to remind us
>that they have low-cost kits too, but I'm primarily interested in some
>info from real, live, "working" hobbyists.
>
>Any takers?
I assume you are aware of www.fpga4fun.com - you should certainly ask for input there.
A few assorted ramblings, in no particular order....
I think a major development has been the availability of free devtools - for a long, long time PLDs
and later FPGAs were the exclusive territory of the professionals due to the high entry cost of the
software, not to mention the steep learning curve and cost of the computing power needed at the
time. Few hobbyists would have the patience to wait through multi-hour compile times.
I think the FPGA hobbyist thing has happened more by accident than anything else due to the
availability of cheap devboards and free software, rather than any conscious effort by FPGA
suppliers.
I don't think the FPGA companies have yet really woken up to the needs of the low-volume user
market. Contrast this with companies like Microchip in the MCU arena, who have always had a policy
of supporting the lower volume users, not necessarily hobbyists in particular, but by catering for
low-volumes this happens anyway - easy availability of chips in sensible packages at low volumes
makes a big difference, and many hobbyist/student users go on to be professional users, which in
the long term has to be good for the business of the companies whose products they first started
playing with .
I'm a little surprised that we haven't yet seen (well not that I've noticed - apologies if I've
missed you...) any of the many hobbyist oriented suppliers that have appeared in the MCU area in
recent years start looking at making very low cost FPGA boards - for example a PCB with a 40 pin DIL
footprint containing a small FPGA, config device and JTAG connector maybe be quite popular.
As long as FPGAs are the preserve of distributors like Avnet, low-volume/hobbyist takeup is going to
be limited. Packaging is an obvoius barrier, and I doubt that many FPGA hobbyists venture further
than using ready-made demo boards.
On the other hand I also wonder how many hobbyists actually have a need for the speed and power that
an FPGA provides - there are so many fun thnigs that can be done with microcontrollers, how many
hobbyists have the time and inclination to venture into the sort of speeds and complexities that
need FPGAS (and have the test gear to support it).
I would be somewhat skeptical about FPGAs being anything to do with a 'rebirth of the electronics
hobbyist', if such a rebirth is indeed occurring. Unless maybe you consider a move by some of the
people that were messing with MCUs into FPGAs a shift from a software to a hardware activity, which
is tenuous at best..! OK, a few hobbyists are moving into work that is of much greater complexity
than was possible without FPGAs but I doubt that there are many who have seen FPGAs as a way into
electronics in general.
From a personal point of view, although an electronics professional, I also manage to do the
occasional hobby project, and recently ventured into the world FPGAs for a project that would simply
not have been worth the effort doing without the availability of a cheap FPGA devboard and software
to base it on : www.electricstuff.co.uk/ektapro.html (lower half of page), and I already have plans
for another couple of 'fun' FPGA projects.
Phil Tomson
Kevin Morris <ke...@techfocusmedia.com> wrote:
>I'm writing a feature article for FPGA Journal (www.fpgajournal.com)
>about FPGAs and the re-birth of the electronics hobbyist. My theory is
>that electronics as a hobby went through a "dark age" period, maybe
>from the early/mid 1970s until recently becuase of the inaccessibility
>and cost of designing with state-of-the-art technology. Radio Shack
>shifted their focus from 50-in-1 project kits and hobbyist parts to
>selling toys, cell-phones, and stereo equipment.
Well, I would say that the 'dark age' began more in the early to mid 80's when
everything started going surface mount. Lots of people experimented with 74XX
parts back when they were in DIP packages.
>
>Now, with the emergence of low-cost, high-capability FPGAs, development
>boards, and design software, I see a new age of hobbyist activity
>beginning (as often evidenced in this group).
>
>I'm looking for a few people that would be willing to express views on
>this topic for the article.
>
>I know, Austin will probably post a strong technical argument that
>Xilinx FPGAs are uniquely attractive to the hobbyist, somebody from
>Altera will send me a Cubic Cyclonium prototyping paperweight (they're
>very cool), and Actel and Lattice people will post just to remind us
>that they have low-cost kits too, but I'm primarily interested in some
>info from real, live, "working" hobbyists.
it doesn't matter who makes the kits, per se, it's the fact that for $100 now
you can buy an FPGA starter kit with 300,000 to 400,000 gates or so (and a
good amount of memory). I really think the Xilinxs, Alteras, Lattices, etc. don't
know what they've got. Perhaps they don't want to be bothered with a
consumer/hobbyist market, however, I think that a company like Radio Shack
could really capitalize on this: kind of like a return to the 50-in-1 project
kits we had as kids, only now it could be 50,000 in one with an FPGA board,
memory, USB interface, etc. They could setup a website where people could
download & share code. They could sell addons: sensor boards, etc. Given the
success of Lego Mindstorms (and there's the new Lego NXT robotics kits coming
out this summer) it seems to me that there is an opportunity for consumer level
FPGA kit priced under $200.
Software engineers could be a good market for an FPGA kit aimed at
helping them to create hardware accelerators for software - maybe a relatively
small market right now, but it could really grow if hardware acceleration
became 'easy' (or at least 'easier').
Also, look at the success of Make magazine: it seems to indicate that there's
potentially a big market of makers, tinkerers, hardware hackers, etc.
>
>Any takers?
>
I think the advent of open source FPGA related design software will also help
bring in more hobbyists.
Phil
Peter Alfke
digital circuits, and I have made my rules:
It must be something that cannot be done with just a microprocessor.
That means it must be something fast. Audio, video, radio, robotics
come to mind.
Or, for FPGAs, it must be a platform that allows all sorts of
variations. Like the Swis Army knife of electronics.
Most likely it must be something that appeals to a limited number of
people. That way the toy industry has not yet made it available for $
9.99. (That was the death of some of my keyboard synthesizer projects
in the 'seventies.)
I think a secondary light-triggered (slave) flash unit would be very
useful for all those small digital cameras, but that does not need an
FPGA... :-(
Peter Alfke
Francesco
(even if I think that the starter kit are still too expensive for
people that want electronics as an hobby)
I'm going to write some articles for an italian magazine (Fare
Elettronica) about FPGA.
This magazine is for people that like electronics as hobby.
In my articles I'll talk about the Xilinxs FPGA and in 5 aticles I will
introduce people to this technology.
Francesco
John Adair
I'll start by saying I represent manufacturer making low cost boards but I
can pass offline some of the feedback we get from users of our products
particularly our Raggedstone1 and low cost modules that we sell also.
Generally I would say that the fact that FPGA boards like ours now cost less
that it takes to fill my car with fuel so that the start-up cost is nearly
inconsequential to most hobby engineers. Coupled to that you get free fully
function tools from most silicon vendors, and that achieving timing in
designs at frequencies below say 50MHz is now easy, the marriage of factors
is allowing hobbyists to use the technology. Looking back to say 10 years
ago most of these factors didn't exist or were very limited and the barrier
to hobby use was hugh. I can be contacted through our support email or
telephone number, available on our website, if you want a bit more feedback.
John Adair
Enterpoint Ltd. - Home of Raggedstone1. The Low Cost Spartan3 PCI
Development Board.
http://www.enterpoint.co.uk
"Kevin Morris" <ke...@techfocusmedia.com> wrote in message
news:1137096913.2...@o13g2000cwo.googlegroups.com...
Alex Gibson
"Peter Alfke" <pe...@xilinx.com> wrote in message
news:1137114655.9...@g44g2000cwa.googlegroups.com...
Why not an fpga synthesizer project ?
Projects like that appeal to people.
Things like the fpga4fun projects.
Something like a music visualiser like the ones in winamp etc
most micros aren't powerful enough for that.
Or a software am radio.
Use a fpga to replicate a couple of dollar tranny radio.
Or some simple dsp projects like filters without using system
generator or core generator.
Pitch shifter, simple wah effect etc
Update all the old analog type projects the hobby magazines have/had for
fpga.
One company could probably capture a lot of the hobbyist market if they
produced a pdf magazine or quarterly with these sort of projects.
As others have said provide the source code and maybe even an area to share
projects.
A bit like the Atmel applications journal when it started out.
I'm still surprised non of the fpga companies have targeted the
US board of education market like parallax has with the basic stamp.
Use a s3e or s3 starter kit or dip module, with a "simple" soft-core that
has a basic compiler for it
that hides the internals.
Simplify the schematics with like an icon based design environment like
corechart
http://www.elabtronics.com/products_cat_CoreChart.htm
Could also easily target this at robotics as well.
Get them using your products from 12 years onwards.
Could stimulate designs like this by having a circuit cellar
design contest and targeting it at the hobby market.
Alex
Jan Panteltje
<pe...@xilinx.com> wrote in
<1137114655.9...@g44g2000cwa.googlegroups.com>:
OK I wanted to shut up on this, no I am no hobbyist, but I once was one.
Still I tinker with stuff on the side.
No running light etc.. is the interest of the 'current tinkerer'.
Yes, high speed video.
The current tinkerer (in me) needs an FPGA board with H264 decoder
capable of doing H264 main profile, something like this:
Stream #0.0, 50.00 fps(r): Video: h264, yuv420p, 1920x1088
The current tinkerer knows there is no real H264 acceleration graphics
card with Linux driver, the current tinkerer also want to decode any
encrypted....
The current tinkerer KNOWS systems change every few years, and wants to keep
using the same hardware as long as possible, the current tinkerer wants
VGA DVI and perhaps HDCP, and the current tinkerer wants Ethernet RJ45
100 MB/s to connect to the board.. and Linux soft like WebPack-8.1 to program
it.
The current tinkerer knows he needs a dual core Pentium 4 3.2 to pull
it all of in software (better then that, even dual Opteron does not hack it
actually), so here comes the price advantage of the FPGA solution.
But only for so long, until the first H264 chips or accelerated graphics
cards are on the market.
So, throw in the H262 codec IP (or just the decoder) with the required
soft and 'demo board', make sure it has that VGA (without earth noise
problems), and RJ45 connector... and put it in the web shop.
Hey I have it all working in C, have the source... developing a H264 decoder
is some job.... maybe one of those C to HDL compilers... dunno.
So the real hobbyist I was in the sixties build his own vidicon camera and TVs
and what not... do not underestimate the real hobbyist ;-)
And that kind of person will go for FPGA.
The E Hobbyist was never 'dead', look at all the micro boards, then PICs, but
indeed these demo FPGA boards are much more then that, they are universal
building blocks.
Just make sure it has the right IO.
John Adair
We are half way there at the moment and a lot more is coming to fill in the
gaps.So wait and see.
John Adair
Enterpoint Ltd. - Home of Raggedstone1. The Low Cost Spartan-3 Development
Board.
http://www.enterpoint.co.uk
"Alex Gibson" <ne...@alxx.org> wrote in message
news:42pjalF...@individual.net...
John Larkin
<ke...@techfocusmedia.com> wrote:
I *used* to be an electronics hobbyist, but now I do it full-time.
The trend here is increasingly towards digital and software,
increasingly away from actual electricity. The tools of choice become
PCs and green eyeshades, same as the gear needed to be an accountant.
This is partly because it's less messy, and because universities can
replace expensive lab benches and test equipment with cheap laptop PCs
that the students have to buy themselves. Hell, you can get an "EE"
degree now without studying electromagnetics!
I walked through the EE department at Cornell and counted screens. PC
screens outnumbered oscilloscope screens by about 6:1.
That's fine by me: I design instrumentation that's analog intense, and
the uPs and FPGAs play supporting roles. But a lot of kids are missing
the luxury boat if the only numbers they know how to count are 0 and
1.
John
dani...@aol.com
You are welcome to contact me directly. You know what they say about
opinions... I have one, too. You can check out my hobby-ish activites
at:
http://www.fpga-games.com (self-funded hobby)
http:///www.engr.sjsu.edu/crabill (some funds from Ahhhnold and the
State of California)
I'm standing on the shoulders of great people like Mr. Mike J from FPGA
Arcade over at:
Also, I think another very interesting product for recreational
learning is the XGS, see:
Of course, you could implement the whole XGS in a small FPGA, but for
someone with a CS background (or none at all) a product like the XGS
might be a very enticing first step into the world of electronics.
Eric Crabill
Speaking for Myself
Symon
news:cikfs115adje37jml...@4ax.com...
>
> I walked through the EE department at Cornell and counted screens. PC
> screens outnumbered oscilloscope screens by about 6:1.
>
> That's fine by me: I design instrumentation that's analog intense, and
> the uPs and FPGAs play supporting roles. But a lot of kids are missing
> the luxury boat if the only numbers they know how to count are 0 and
> 1.
>
I design the same stuff. However, I find I'm using my PC more and more.
Simulating it and getting the design right first spin is much nicer than
fixing it later, at least that's what the CEO says. I have software on my PC
that (I hear) uses lots of 0's and 1's together to model real numbers.
Lovely! ;-)
Cheers, Syms.
p.s. But you're right. I don't own a boat.
John Larkin
wrote:
So, I wonder, how many people here are exclusively logic designers,
and how many are more general EEs, who deal with the analog, power,
thermal, and other aspects of electronic design?
John
Jon Elson
Kevin Morris wrote:
>I'm writing a feature article for FPGA Journal (www.fpgajournal.com)
>about FPGAs and the re-birth of the electronics hobbyist. My theory is
>that electronics as a hobby went through a "dark age" period, maybe
>
>
Well, I'm not really a hobbyist, but a VERY small business (just me, and
sometimes
a part-timer to help solder boards.) But, the level of stuff I'm doing
(in my home
business) is maybe close to hobby level. You might look at my web pages on
that project, and see if it is of interest :
http://pico-systems.com/motion.html
All of the "control" or "controller" products have at least one FPGA in
them.
The PPMC has one FPGA and 2 CPLDs for the basic set. No way could I have
done these without FPGAs. I have never used a development board, just
bludgeoned
ahead with my best guess of what the prototype should look like. And,
just 2-layer
boards, too.
Jon
Eric Smith
> I have struggled for decades to come up with enticing demo projects for
> digital circuits, and I have made my rules:
> It must be something that cannot be done with just a microprocessor.
> That means it must be something fast. Audio, video, radio, robotics
> come to mind.
What? No traffic lights and vending machines? :-)
It's always entertaining when people pop up in various newsgroups
(including this one), wanting help with their vending machine project,
and insisting that it isn't homework.
Eric Smith
> (even if I think that the starter kit are still too expensive for
> people that want electronics as an hobby)
I can't claim to know the economics of hobbyists elsewhere in the world,
but IMNSHO in the US, someone who can't afford to spend USD $99 on
something needed for their hobby doesn't realy qualify as a "hobbyist".
People routinely spend orders of magnitude more than that on hobbies
other than electronics.
And yes, I remember back when I was a starving college student. Even
then I managed to spend much more than $99/year on hobby items, though
perhaps I shouldn't have.
One guy I knew back then complained that he couldn't afford a $100
computer (a Timex/Sinclair or the like), even though he typically spent
well over $100 per month on accessorizing his sports car. It's a matter
of priorities.
Piotr Wyderski
> My theory is that electronics as a hobby went through a "dark age"
> period, maybe from the early/mid 1970s until recently becuase of the
inaccessibility
> and cost of designing with state-of-the-art technology.
I think it is not true. Hobbyists do not need state-of-the-art technology,
they need satisfaction -- this is the key difference compared to
professional
electronics. For one person a simple LED blinker is perfectly enough,
somebody else is happy when his three transistor AM radio is working,
there also are hobbyists doing DSP using FPGAs just for fun.
The next problem is related with the lack of appropriate technologies.
SMD parts were useless, because we didn't know how to produce
good enough single layer PCBs at home, not to mention double layer
boards. Now we have two competitive technologies (optical, based on
photoactive resins and the second one, called "thermotransfer", which
directly transfers the pattern from a sheet of paper printed by a laser
printer onto the copper surface using a flatiron and two rags). We've
even learned how to make precise two-sided PCBs using that technologies.
Now the SMD components in TQFP/SO/TSSOP are no longer a
problem. But we still don't know how to solder BGAs and QFNs...
> Radio Shack shifted their focus from 50-in-1 project kits
I think that kits are a big misunderstanding, because you just need to
connect provided parts as described on a provided diagram. Even
a chimp could do it. The trick is to design the device yourself, from
scratch. It needn't be perfect, it sometimes produces smoke, but it's
_yours_.
> (as often evidenced in this group).
Hmm, really? ;-) As far as I know the only "pure" hobbyists
here are Antti and myself, the rest is more or less professional.
> I know, Austin will probably post a strong technical argument that
> Xilinx FPGAs are uniquely attractive to the hobbyist
Hard to obtain in small quantities...
> and Actel and Lattice people will post just to remind us
> that they have low-cost kits too
But they do not provide free simulators, so they are virtually useless for
hobbyists.
> but I'm primarily interested in some info from real, live, "working"
hobbyists.
Well, I hope it's useful... . :-)
Best regards
Piotr Wyderski
--
"If you were plowing a field, which would you rather use?
Two strong oxen or 1024 chickens?" -- Seymour Cray
Tobias Weingartner
>
> Any takers?
Real/Complete programming information would be a very good start to a new
hobby phase. But I think that all the FPGA vendors are too scared to give
out this information. Come on, xilinx, altera, etc, etc. What could there
possibly be so secret in the format for how to program your parts? :)
--
[100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
Bob Perlman
<wyde...@mothers.against.spam-ii.uni.wroc.pl> wrote:
>Kevin Morris wrote:
>
>> Radio Shack shifted their focus from 50-in-1 project kits
>
>I think that kits are a big misunderstanding, because you just need to
>connect provided parts as described on a provided diagram. Even
>a chimp could do it.
But you want something for kids to build when they're young, before
they're capable of designing something themselves. Lots of us cut our
teeth on the 50-in-1 sets and Heathkits.
If a kid between the ages of 8 and 15 asked me how to get started in
electronics, I'd:
1) send them to Ramsey Electronics
(http://www.ramseyelectronics.com/), which makes nice, relatively
inexpensive kits of varying complexity.
2) ask them to get off my lawn. (Sort of obligatory at my age.)
Bob Perlman
Cambrian Design Works
Andy Peters
> I have struggled for decades to come up with enticing demo projects for
> digital circuits, and I have made my rules:
> It must be something that cannot be done with just a microprocessor.
> That means it must be something fast. Audio, video, radio, robotics
> come to mind.
I can think of two ideas.
One is an audio digital delay. A CODEC, some analog for the front and
back ends, a rotary encoder, some buttons, an LCD and/or some LEDs for
the user interface, an FPGA for the delay engine and the logic to
handle the user interface, and a couple of SRAM chips for the delay
memory. The delay engine is a pair of address counters and you need a
state machine to handle the memory access, and a couple of shift
registers to do the I2S interface. Hell, while you're at it, add a
digital input level meter and blink some LEDs.
A second is a simple logic analyzer. Of course, the hard part here is
writing a Windows (or Mac OS X or Linux) host program.
-a
Hal Murray
>writing a Windows (or Mac OS X or Linux) host program.
USB seems like the obvious choice, but I don't think any of the low cost
demo boards support that.
Some of them have VGA connectors. If you have a spare monitor you
could do the display output in the FPGA too.
RS-232 is probably good enough to have a lot of fun. 115K works
fine with not-long cables. 1000 points is a reasonably size.
If you have 8 channels, that's 8K bits. Under a second.
Philip Freidin
>I'm writing a feature article for FPGA Journal (www.fpgajournal.com)
>that electronics as a hobby went through a "dark age" period, maybe
>from the early/mid 1970s until recently becuase of the inaccessibility
>shifted their focus from 50-in-1 project kits and hobbyist parts to
>selling toys, cell-phones, and stereo equipment.
I agree that electronics as a hobby is not as vibrant as it has been in
the past, but not on your time line or for your reasons.
My theory is that the decline started no earlier than late 80's and
has not really recovered. But the projects that are now created are
far more complex than those of yester year, but at a level comensurate
with the technology available today.
The decline has little to do with Radio Shack and 50-in-1 kits. While
it is probably true that most electronic hobbyists have at some time
owned and played with these kits, there are probably far more that
had these kits, and after a few hours, they were put away never to be
used again until passed on to some younger cousin. These kits were
way too limited, had fairly poor educational content, and no
direction as to how one might expand, experiment, and learn more.
My theory is that the decline in the late 80's was driven by several
things that started in the early 80's:
- Reasonably cheap personal computers with sufficient software that
hobbyists that may have become electronic hobbyists, instead became
software weenies. The open-source movement now extends this to
colaborative projects that are very challenging, and include the
opportunity for others to use your work, and to get recognition for
your contribution. I am not criticising the O-S movement at all
here, just pointing out that it is an alternative path for
potential electronic hobbyists.
- Many of the things that electronic hobbyists used to build could be
purchased complete and working for less than the raw components
cost. There is not as much fun in building a 7 transistor radio
that has mediocre reception in a cardboard box, versus a buying a
walkman for the same price. Other projects just are not possible,
such as build a CD player or cell phone.
- Many of the components that you might want to buy that are used in
commercial products were not available to hobbyists.
- Many of the challenges that may have enticed an electronic hobbyists
are now replaced by toys such as playstations etc.. that consume
vast amounts of what would have been hobby time. Electronics as a
hobby requires significant study to be able to do interesting
projects. 150 channels of TV probably don't help either.
- Mentors are in short supply. I think the pressures of work have
increased (because electronic work projects are more complex) so
the pool of mentors is diminishing. Their hair is getting thinner
and grayer too.
- Specialization. As the electronics profession has grown over the
last 25 years, the amount of new stuff is such that few if any can
master (or even be reasonably competent) in multiple sub-fields.
This affects the mentor pool, and also the breadth of available
literature that might guide a starting-out electronic hobbyists.
This was driven home for me about 10 years ago when I met with a
world renown Verilog expert, who had no clue that a 74LS74 was a
flipflop!
- Minaturization of packaging makes some products un-useable by
hobbyists, or requires much higher levels of enthusiasm. Surface
mount made the older wire-wrap no longer an easy solution for
projects, as the availability of wire-wrappable sockets is far
more limited, and the latest packages such as QFN and BGA are
beyond almost all hobbyists. I am not saying that this kills the
hobby, but it certainly raises the bar.
>Now, with the emergence of low-cost, high-capability FPGAs, development
>boards, and design software, I see a new age of hobbyist activity
>beginning (as often evidenced in this group).
FPGAs on development boards
http://www.fpga-faq.org/FPGA_Boards.shtml
go along way to allowing any hobbyist to start playing and
experimenting with FPGAs, HDL, simulation, hardware design and
interfacing to the real world. Best of all, there are many low
priced boards available, and all of the software for the low
end products are available free to anyone with a computer and
an internet connection (and a few gig of disk space).
While this re-enables electronic hobbyists to work with current
technology, and pursue it with tools that are similar to what
professionals are using, I don't think this is going to get
anyone to put down their XBOX-360 and start writing VHDL.
>I'm looking for a few people that would be willing to express views on
>this topic for the article.
This group is full of them. I've been an electronics hobbyists for
over 40 years. Sometimes I get to be paid for it (employment), and
sometimes not.
Cheers,
Philip Freidin
Philip Freidin
Fliptronics
spammersarevermin
I don't feel qualified to comment on the dark ages, but in the last
several years have moved from the software side into hardware. I keep
a blog about some of the stuff that I'm doing (www.dtool.com) & read
this group regularly - understanding about 5% of it. I am playing w/ a
Digilant Spartan3 board, & when the Xilinx software doesn't crash, am
making slow progress in understanding how to move from, say a
hardware-based ethernet, to one designed w/ logical tools.
I don' get paid for this stuff - it's just very cool. My wish is for
more tutorials & even more access to free software (Chipscope for more
than 60 days for example), as buying all of the ancillary tools,
chips, hardware, scopes, probes, etc. can get expensive after awhile.
My $.02, Tom
Spamming this account signifies
your unqualified consent to a free security audit
Hahnsolo
younger and just "discovered" the fpga. I was under the impression
that things like this were very expensive, but when I see starter kits
for $150, I had to snatch one up and try it out. For the last 5 months
I have been feverishly programming and learning with Webpack 7.1
implimenting different ideas on codecs, processor cores, and so on.
Now I that I have a handle on whats available and possible on most
platforms I bought my first dev board a couple of days ago. I can't
wait for sun to open up there sparc cores. So many ideas so little
time!!
I can't believe I went through my undergraduate education without
trying fpga's out, and my focus on RF and optics was not very close to
VLSI or control. After 5 months though there are a ton of optics
processing problems that can be sped up with fpgas. Like I said, can't
wait to start debugging!!
So much to do, so little time...
new Hobbyist
Antti Lukats
news:1137338637.9...@g49g2000cwa.googlegroups.com...
no need to wait for sun
commercial quality SPARC core and system on chip library is available now
you need XC3S400 or larger (better larger) to implement a SPARC based system
--
Antti Lukats
http://www.xilant.com
Ray Andraka
>
> Hmm, really? ;-) As far as I know the only "pure" hobbyists
> here are Antti and myself, the rest is more or less professional.
>
There are many of us here who started out as pure hobbyists, but then
grew our passion into a paying endeavor. I started out in the mid '70's
first with dissected radios, tape recorders etc, whatever I could get my
hands on, with radio shack kits (many of which I heavily modified...one
that comes to mind was a regulated power supply where the 2N3055 got hot
enough to melt through the red plastic board/box that soon got a
heatsink and a darlington pair for more output current and a switch to
select output voltages). From there, I started getting into logic.
Between a 1976 Signetics IC databook (which is still on my bookshelf)
and several of Lancaster's cookbooks (some of his circuits would never
get past a critical review, but they were great for learning) I taught
myself digital design. Even built a couple of computers based on the
then brand new 6800 (on an Ohio Scientific board), and then the Z-80
scratch built on wire-wrap boards before graduating from high school in
1979.
Like Philip said, I had a mentor (a friend of the family who is an EE
and was consulting mostly in audio and telephony back in the 60's and
70's) that gave me much of the motivation to make and improve on the
projects in Radio Electronics (which I was subscribed to from 1971 to
1982, I dumped the entire collection when it caused me to exceed my
weight allowance in a move with the Air Force, Killed me, but I couldn't
even give them away).
Phil Tomson
Tobias Weingartner <wein...@cs.ualberta.ca> wrote:
>Kevin Morris wrote:
>>
>> Any takers?
>
>Real/Complete programming information would be a very good start to a new
>hobby phase. But I think that all the FPGA vendors are too scared to give
>out this information. Come on, xilinx, altera, etc, etc. What could there
>possibly be so secret in the format for how to program your parts? :)
>
Indeed. I don't get it either. How much can be reverse engineered from a
bitstream format? This closedness is a real hindrance to the development of
an open source eco-system around FPGAs.
Any university open FPGA architectures being developed out there? While it's
probably too late in the game for a new FPGA company to enter the race, it's
possible that one of the smaller, hungier players might be able to
differentiate themselves by opening up their bitstream formats.
Phil
Peter Alfke
I built radios in high-school days, and was a ham operator during
college years. Later, in Sweden, I designed and built power supplies
and sold a hundred of them as a moonlight operation. Then the usual
audio amplifiers and speaker boxes.
Now the interest is rekindled and I play with the design of my
second-generation programmable clock module (1 Hz to 2.5 GHz with,
hopefully, 30 ps jitter). But this also taught me that, for top-notch
performance, you need the help of several friends and experts (software
design, pc-board lay-out, GHz trickery, test instrumentation) and of a
commercial manufacturer. We built a few hundred of the first generation
"X-Pod", and are using them inside the company on many test benches. So
it's more "skunk works" than hobby activity, but still the same fun.
I have toyed with the idea of a storage scope. The digital part in an
FPGA plus external RAM looks easy. But less than 500 MHz sample rate
seems to make it a toy, and at that rate the A/D becomes quite
expensive, and an input attenuator looks forbidding, But there are neat
examples of using the PC for display and control.
Peter Alfke, from home.
Jim Granville
> Nostalgia...
> I built radios in high-school days, and was a ham operator during
> college years. Later, in Sweden, I designed and built power supplies
> and sold a hundred of them as a moonlight operation. Then the usual
> audio amplifiers and speaker boxes.
> Now the interest is rekindled and I play with the design of my
> second-generation programmable clock module (1 Hz to 2.5 GHz with,
> hopefully, 30 ps jitter).
Digits of precision & granularity ?
But this also taught me that, for top-notch
> performance, you need the help of several friends and experts (software
> design, pc-board lay-out, GHz trickery, test instrumentation) and of a
> commercial manufacturer.
A tad outside the average hobbiest resource pool ?
We built a few hundred of the first generation
> "X-Pod", and are using them inside the company on many test benches. So
> it's more "skunk works" than hobby activity, but still the same fun.
> I have toyed with the idea of a storage scope. The digital part in an
> FPGA plus external RAM looks easy. But less than 500 MHz sample rate
> seems to make it a toy, and at that rate the A/D becomes quite
> expensive, and an input attenuator looks forbidding, But there are neat
> examples of using the PC for display and control.
Yes, scopes are dominated by things other than the FPGA, so are not
ideal demo-examples.
My favourites would be for Xilinx to do a split
a) Freq Ctr & Signal Generator - Smallest/Cheapest FPGA version
b) Freq Ctr & Signal Generator - Money-no-object version
FreqCtr's can become quite complex - so a series of designs would show
users more and more, but still have a HW platform that is
i) FPGA dominated
ii) Clearly ahead of any uC alternative
-jg
Peter Alfke
Jim Granville wrote:
>> Digits of precision & granularity ?
Above 1 MHz limited by time base accuracy, below 1 MHz by display
(just because we are too lazy to make the display floating point...)
>
> > A tad outside the average hobbiest resource pool ?
> >
> Yes, scopes are dominated by things other than the FPGA, so are not
> ideal demo-examples.
DRAM, and PC.
>
> My favourites would be for Xilinx to do a split
> a) Freq Ctr & Signal Generator - Smallest/Cheapest FPGA version
box. Ken Chapman did the control for both of them (PicoBlaze-based), so
you can be convinced it is good.
But it only goes to 80 MHz (?) and the jitter may be more than 100 ps,
since he has no PLL to clean it up further.
>
> b) Freq Ctr & Signal Generator - Money-no-object version
But no arbitrary function, adjustable amplitude or duty cycle. All
those things are possible, but clutter up the design. Maybe there will
also come a USB-controlled derivative that offers more freedom.
Please tell me what people need a frequency counter for. I have thought
of a design for years, including reciprocal counting at low frequency
for high resolution with short capture time. But it died for lack of
interest. We could of course include something in the S3E eval board.
>
> FreqCtr's can become quite complex - so a series of designs would show
> users more and more, but still have a HW platform that is
> i) FPGA dominated
> ii) Clearly ahead of any uC alternative
The S3E eval board accuracy will be limited by its 50 ppm xtal, and the
resolution might be pushed to almost 1 GHz. Display is no problem @ 2 x
16 digits.
A 20 times more accurate time base would cost <$20 extra.
I warned you, this is a hot button with me.
My thesis project, looong ago, was a frequency counter. It's deep in my
genes.
Peter
Jim Granville
Those do sound like the Smallest/Cheapest and 'other end' I was
talking about.
Why stop at 1Hz ?
> Please tell me what people need a frequency counter for. I have thought
> of a design for years, including reciprocal counting at low frequency
> for high resolution with short capture time. But it died for lack of
> interest. We could of course include something in the S3E eval board.
When I say 'Freq Ctr' that is short hand for the higher end Freq Ctrs.
The better ones ( we use a venerable PM6672 here... ) can do
much besides simple frequency.
I'd start with the simplest gated counter designs, and then work up
to Reciprocal and Time-Interval counters, ..maybe Phase too.
A small nudge, and you can make a SigmaDelta ADC display section,
as that's really a % counter.
One idea I have, is for a Dual Readout Recip Counter :
A fast update readout, where the precision is the normal trade
off of update speed.
The second would accumulate precision, so the longer the probe
is held there, the more digits you get.
That gets a little tricky, as the whole system has to never drop
any edges.
Uses: As a software development tool, to verify correct settings.
Common errors are the off-by-one in divisiors etc.
Mostly 2 channel Time-interval, but also frequency.
>
>>FreqCtr's can become quite complex - so a series of designs would show
>>users more and more, but still have a HW platform that is
>>i) FPGA dominated
>>ii) Clearly ahead of any uC alternative
>
> The S3E eval board accuracy will be limited by its 50 ppm xtal, and the
> resolution might be pushed to almost 1 GHz. Display is no problem @ 2 x
> 16 digits.
> A 20 times more accurate time base would cost <$20 extra.
That's fine. It should NOT be limited by the FPGA.
Users would be happy to add timebases as needed - yes, even to
atomic ones :)
For higher end examples, how about calibrate/correct via GPS timebase
(still using the low cost xtal)
That expands further, to give an absolute time reference - wider
audience, and with 2 lines, one could show 'human' time, and the other
the snapshot of the 1 sec time pulse from the GPS, probably to
better than 5ns.
> I warned you, this is a hot button with me.
> My thesis project, looong ago, was a frequency counter. It's deep in my
> genes.
Talking of looong ago, I think my first film-processed project was a
compact 8 digit Freq Ctr, with many old fairchild part numbers.
That was before rubylith....
-jg
Peter Alfke
Jim Granville wrote:
> > Why stop at 1Hz ?
With 1 ppm absolute accuracy, even the Hz is dubious above 1 MHz.
Who is interested in frequencies below 1 MHz? That also goes for the
counter.
Jim, you seem to overestimate the time and energy we here can expend on
sophisticated and increasingly specialized appliations. That's why I
stay with a basic, but extreme design that gives us some real
usefulness and also some bragging rights.
There are always more urgent projects breathing down our necks:
Verifying, testing, finding problems and work-arounds, write
documentation, plan the next generation, prove SEU hardness, deal with
unhappy postings on the newsgroup, give seminars, attend conferences,
analyze the features and find the shortcomings of the "other guy",
support Markeing, but prevent them from exaggerating...
Life is never dull, often challenging, and rarely really frustrating.
Peter Alfke
Hal Murray
>So, I wonder, how many people here are exclusively logic designers,
>and how many are more general EEs, who deal with the analog, power,
>thermal, and other aspects of electronic design?
I've never worked with any "exclusively logic designers". (At
least I don't think I have. Maybe one snuck in that I didn't
notice.)
There is also the other end of the spectrum: firmware/drivers/software.
For most projects that I've worked on, that's a cricital
part of the big picture.
You could also expend up to system architecture and stuff like that.
Antti Lukats
news:dqefe...@enews4.newsguy.com...
Phil, Atmel AT40K/AT94K bitstream format is almost open
eg it is available under NDA from Atmel, and open source reverse engineered
documentation is also available - no NDA :)
As of BIG FPGA companies making their bitstream format public - do not hope!
because the bitstream holds not only the 'known' bits like routing and LUT,
but
also factory stuff
bits that compensate against technology changes, those are 'figured out' by
actual measurement by the FPGA companies AFTER wafers are manufactured
that is the FPGA companies makes their chips to have a little 'fine tuning'
to
be done, this fixing is done by bitgen and is totally invisible for the
normal user.
second there are factory test bits and settings, again something that the
end
user should not mess up
there are some hidden FPGA primitives that are partially visible for the
end user but not useable by end user, like PMV primitive in V4 and S3
there are probably hidden features and primitives that are totally invisble
for the end user as well.
so there are reasons for keeping the bitstream non public.
for Xilinx and Lattice the main bitstream info is in NeoCad "BFD" files,
those are simple ordered lists of bit names, bitgen uses that
info to convert an NCD to bitstream
NCD file is almost 1:1 the same as the XDL file would be so actually
pretty much of the bit info is visible for those who want to see
Antti Lukats
news:1137368392.0...@g47g2000cwa.googlegroups.com...
fpgaarcade
P.S. has everyone read Eric's article about FPGA Gaming in XCELL?
http://www.xilinx.com/publications/xcellonline/xcell_54/xc_pdf/xc_atari54.pdf
Brian Drummond
>In article <slrndsgqr4....@irricana.cs.ualberta.ca>,
>Tobias Weingartner <wein...@cs.ualberta.ca> wrote:
>>Kevin Morris wrote:
>>>
>>> Any takers?
>>
>>Real/Complete programming information would be a very good start to a new
>>hobby phase. But I think that all the FPGA vendors are too scared to give
>>out this information. Come on, xilinx, altera, etc, etc. What could there
>>possibly be so secret in the format for how to program your parts? :)
>>
>
>Indeed. I don't get it either. How much can be reverse engineered from a
>bitstream format? This closedness is a real hindrance to the development of
>an open source eco-system around FPGAs.
Last really open system was the XC6200. But it failed commercially, at
least in part, because it was a finer grained architecture.
FPGA capacities should now be big enough to support a "virtual FPGA"
layer on top of a real FPGA, using only the "public" parts of the
bitstream (e.g BRAM and SRL16 contents, possibly a subset of the
routing) to give a completely open format. Possibly a virtual XC6200,
but probably a coarser grained architecture (mini-Spartan perhaps).
I wonder what size Spartan-3 you would need for a virtual XC6264?
This would lose a lot of capacity and performance (you may need several
LUTs dedicated to routing for every one you can use for logic) but the
result is likely to be at least competitive with the sort of technology
a startup or small player has on offer.
I think it would be big enough to exercise open source development tools
until something better came along...
- Brian
Antti Lukats
news:9p7ns1pch437c81ln...@4ax.com...
it has already been done there was MPGA project that implemented a virtual
"Meta" FPGA
the project is dead vanished/vanishing but its a nice a example of the use
of SRL16 for
virtual FPGA loading
its however far more interessant to implement dynamic bitstream generator
that patches
some parts of the ready made bitstream to modify the algorithm this needs to
no
resources to be vasted for the download of the new config.
Tobias Weingartner
>
> Phil, Atmel AT40K/AT94K bitstream format is almost open
> eg it is available under NDA from Atmel, and open source reverse engineered
> documentation is also available - no NDA :)
Hmm... will google show me this? :)
> As of BIG FPGA companies making their bitstream format public - do not hope!
>
> second there are factory test bits and settings, again something that the
> end user should not mess up
All the better to have documentation, no?
> so there are reasons for keeping the bitstream non public.
I happen to disagree. We are all entitled to our opinions of course.
If the vendors would have a well defined format to "compile" to, and
a good library/port for a program to be able to take this format and
then generate a bitstream, that would be a start. Note, I'd want to
have the source available to be so that I could port this last bit of
"technology" to my favourite OS (by choice or necessity).
I can't believe that these things are anything but simple portable ANSI
C (or some derivative)...
Tobias Weingartner
>
> FPGA capacities should now be big enough to support a "virtual FPGA"
> layer on top of a real FPGA, using only the "public" parts of the
> bitstream (e.g BRAM and SRL16 contents, possibly a subset of the
> routing) to give a completely open format. Possibly a virtual XC6200,
> but probably a coarser grained architecture (mini-Spartan perhaps).
> I wonder what size Spartan-3 you would need for a virtual XC6264?
At that point, why not create an ASIC... (yeah, price, etc, etc)
Peter Alfke
and elsewhere.
The reason for the "secrecy" is not so much fear of giving away secrets
to a competitor, but rather fear of becoming inundated with support
issues. We have about 100,000 designers using our parts, a few dozen
of them exploring and abusing subtle aspects could easily bring our
support hotline (and this newsgroup) to its knees.
Also, the non-open nature of the bitstream provides our customers a
certain level of security against reverse-engineering rip-off.
Our primary obligation is to remain an innovative and profitable
company, to the benefit of our customers, our employees, and our
shareholders. Satisfying exotic academic research is fine, as long as
it does not conflict with the primary obligation.
Just my personal opinion...
Peter Alfke
Scott & Brenda Burris
I was a hobbyist up until the mid to late 80's. Probably the most
ambitious stuff I tried was a 68020 board with dynamic ram, running at
16Mhz, all on a big wire-wrap board. Back then, the board was stuffed
with LSTTL chips. The board was none too reliable -- flex it the wrong
way, and something broke. But on a good day, it worked.
I tried to make some improvements for reliability. I played with
bipolar PALs. Expensive, and I really hated throwing them away when I
made a mistake in programming them. I also tried making my own double
sided printed circuit boards. Lithographic film, developed in a close
bathroom in my apartment. Needless to say, making and drilling these
boards was a fiasco.
So I just stored all my parts away for 15 years or so.
What's changed to get me back into this hobby? Three things.
1) Flash programmable microcontrollers, i.e. PICs and AVRs. None of
this burning EPROM business anymore. No wiring up SRAM or DRAM. Just
program and go.
2) Low cost schematic/PCB design software and PCB boardhouses. I
wouldn't even attempt to make my own boards anymore. And I can get 6
and 8 layer boards, something I'd never attempt as a hobbyist. Woohoo!
Soldering those SMD components is a bit of a challenge, especially the
PQFP208 packages. Of course there are some interesting things in BGA
packages, but I haven't reached the level of craziness to try the
toaster over reflow method.
3) FPGA's! I last looked at programmable logic in the bipolar PAL days.
I happened to be looking through a Digikey catalog one day and noticed
stuff from a company called Xilinx. Hmm, checked their website. Hey,
this is pretty neat stuff! And since Digikey (and Xilinx to a limited
extent, hint, hint) allow small orders, I can actually get parts. In
the 80's, I often had to try going though a rep or Big Distributor, and
most wouldn't deal with me at all.
So nowdays, I typically design a board with a microcontroller on it,
slap a Spartan chip of some sort on it as well, and worry about how to
make it work later. Aside from a few early gotchas, like trying to use
an input only pin on an FPGA as an output, this has worked very well.
I've weaned myself away from schematics for CPLD/FPGA design and taught
myself VHDL. To me at least, it's a very different mindset to think in,
but it's getting easier as I do more designs. I still struggle with
VHDL which looks legal but isn't quite right for synthesis, trying to
interpret some obscure message from WebPack.
Now I'm looking to do even more. I keep checking to see when the Spartan
3E board is available. I've worked with the Spartan 3 eval board from
Digilent, so I'm anxious to see what's next.
And then there's the little matter of the ML403 kit Xilinx offers with
the Virtex 4 FX and the EDK. As a hobbyist, I'm cringing at the thought
of putting $895 into this. At the same time, I'm going, hmm, what could
I do with the PowerPC chip or the MicroBlaze? Hmm, no it's too much
money.... But I keep thinking about it :-) I know Xilinx doesn't
really target people like me, but I keep hoping for a half-price sale or
a hobby bundle on the ML403 (no support, no commercial use or you give
up your first born, etc).
Cheers,
Scott
In article <1137338637.9...@g49g2000cwa.googlegroups.com>,
core...@gmail.com says...
Ray Andraka
>
> I happen to disagree. We are all entitled to our opinions of course.
> If the vendors would have a well defined format to "compile" to, and
> a good library/port for a program to be able to take this format and
> then generate a bitstream, that would be a start. Note, I'd want to
> have the source available to be so that I could port this last bit of
> "technology" to my favourite OS (by choice or necessity).
>
> I can't believe that these things are anything but simple portable ANSI
> C (or some derivative)...
>
The problem is the bitstream is very tightly tied to the architecture of
the FPGA cell. Having a well defined format tightly constrains the FPGA
architecture to the one the bitstream format is published for. What
that means is that either the format has to change for every fpga
variant out there, now and in the future, or the FPGA has to be frozen
in order to comply with the bitstream format.
There is far more coupling between the bitstream in an FPGA and its
hardware than there is between an instruction set and a processor
architecture because of the fine granularity of the configuration of the
FPGA. In other words, an instruction set in a microprocessor controls
relatively few connections between some very complex blocks. The FPGA
bit stream controls many many connections between lots of small simple
blocks, so if the bitstream format is predefined by a standard there is
very little lattitude for evolving the FPGA's structure.
I'm not sure I see what the big push for having bitstream access is.
I've yet to see a compelling need for it that is not addressed by the
existing tools (there is always XDL if you really want to bit bang).
The only reason that seems to surface is to allow outside parties to
develop their own place and route tools. Frankly, I don't think the
complexity of modern FPGAs is such that this type of undertaking can
improve on or even compete with the free place and route tools already
offered by the FPGA vendors in the timeframe between device introduction
and obsolescence. Anyway, for those hadry enough to try, as I said, the
XDL tools do give you enough access to every step of the design flow to
allow you to play with any step you feel compelled to play with.
Rob
generation. If the hobbyist is going to make a comeback in this country
(US) it is going to take more than a low-cost, high capability FPGA. With
the watered down public education serving up a non-challenging, push them
through curriculum, what hope is there for technologists in this country
over the next few decades?
Do you know how many times I've walked into a gas station and encountered a
teen who can't carry through on a simple transaction? The youth today
aren't--for the most part--go getters: they lack direction, motivation, and
personal responsibilty. They are not problem-solvers, they're
problem-makers who go though life thinking that somebody is always going to
wipe their backside. Give them a kit of parts and ask them to make it
work-ha! They might have to read a book!
It has been reported that high school graduates are increasingly choosing
non-technical fields to major in. The technical fields are too challenging,
require too much work, and interfere with the 50hrs/week of playing video
games. Where are the Heathkitter's of the next generation?
I've ranted long enough...........................
"Kevin Morris" <ke...@techfocusmedia.com> wrote in message
news:1137096913.2...@o13g2000cwo.googlegroups.com...
> I'm writing a feature article for FPGA Journal (www.fpgajournal.com)
> about FPGAs and the re-birth of the electronics hobbyist. My theory is
> that electronics as a hobby went through a "dark age" period, maybe
> from the early/mid 1970s until recently becuase of the inaccessibility
> and cost of designing with state-of-the-art technology. Radio Shack
> shifted their focus from 50-in-1 project kits and hobbyist parts to
> selling toys, cell-phones, and stereo equipment.
>
> Now, with the emergence of low-cost, high-capability FPGAs, development
> boards, and design software, I see a new age of hobbyist activity
> beginning (as often evidenced in this group).
>
> I'm looking for a few people that would be willing to express views on
> this topic for the article.
>
> I know, Austin will probably post a strong technical argument that
> Xilinx FPGAs are uniquely attractive to the hobbyist, somebody from
> Altera will send me a Cubic Cyclonium prototyping paperweight (they're
> very cool), and Actel and Lattice people will post just to remind us
> that they have low-cost kits too, but I'm primarily interested in some
> info from real, live, "working" hobbyists.
>
> Any takers?
>
Peter Alfke
his time being lazy do-no-gooders, was Socrates, more than 2400 years
ago. And each generation after him has repeated the complaint, while
benefitting from the progress brought about by those youths, once they
had matured.
Look at the kids coming out of Stanford, starting SUN, Yahoo, and
Google. Most of the detailed work in my company is done by engineers in
their late twenties and thirties, obviously with necessary guidance
from us more experienced folks...
If kids are not interested in science, that is mainly the fault of
educators, industry and management, creating a a bad learning and
career environment.
I prefer the original posting of this thread:
How can FPGAs envigorate individual or personal design activity?
Let's pool ideas, and not complain about our kids and grandkids.
Many of them are smarter than we are.
Peter Alfke, from home
===================
Rob
I appreciate your comments. But do you know how many great civilizations
have come and gone since Socrates, including his [Socrates] own? I'm an old
patriot and my response was mainly driven by my frustration of what I see as
a possible future for this great country. I work for a fortune 500 company
and I don't see many young Americans coming in for internships. I have also
worked with one of our local well-renonowed colleges and I see a majority of
students with visas filling the class rooms, not young Americans. Yes,
there are many great engineers in this country ,and doubtless there will be
many more, but I fear that those numbers will fall.
And don't mis-interpret my message: I'm not against anyone coming to this
country to get an education. To re-state, I'm just frustrated with our
primary education system.
My apologies for deviating from the topic--it just hit a nerve.
Take care,
Rob
"Peter Alfke" <al...@sbcglobal.net> wrote in message
news:1137467887.7...@o13g2000cwo.googlegroups.com...
Jim Granville
make for the lack of inflows, is the 'appliance' nature of much of
the electronics.
No one enters tertiary education expecting to design a stereo, or TV,
plus much of what potential students see is disposable, or close to
disposable.
Then the Dot-bomb tended to tar all technology companies with the same
brush, and the industry is still clawing back from that.
That's why I believe such 'early/wide student' demos, need to have at
least one block that has a wide audience. ie something they can show
their parents, or apply to a club, or sport.
GPS-option Stopwatch is one such item : Give them time displays to the
low ns, just to remind potential students of the reach of the time-domain.
- and make it simple enough for even schools to run as 'canned examples'.
-jg
Kolja Sulimma
>>so there are reasons for keeping the bitstream non public.
> I happen to disagree. We are all entitled to our opinions of course.
> If the vendors would have a well defined format to "compile" to, and
> a good library/port for a program to be able to take this format and
> then generate a bitstream, that would be a start. Note, I'd want to
> have the source available to be so that I could port this last bit of
> "technology" to my favourite OS (by choice or necessity).
>
> I can't believe that these things are anything but simple portable ANSI
> C (or some derivative)...
JBits is a solution to all this. Maybe not a particulary good one, but
you can read, modify, write bitstreams in a platform independant way.
There is no source code available, but java bytecode that you can
essentially call by any language you want on any platform you want.
There are even people at xilinx working on a virtual file system to
mount and modify the configuration of a virtex-4 by the embedded PowerPC.
Kolja Sulimma
Symon
"Scott & Brenda Burris" <slbu...@earthlink.net> wrote in message
news:MPG.1e35a2bc8...@news.west.earthlink.net...
> I'm also one of those rebirth hobbyists.
>
> I was a hobbyist up until the mid to late 80's. Probably the most
> ambitious stuff I tried was a 68020 board with dynamic ram, running at
> 16Mhz, all on a big wire-wrap board. Back then, the board was stuffed
> with LSTTL chips. The board was none too reliable -- flex it the wrong
> way, and something broke. But on a good day, it worked.
>
I'm genuinely surprised. In my experience, wire-wrap boards were the most
reliable boards I've ever had. Especially if you took the time to train the
technician how to wire-wrap properly. The hardest point was trying to stop
them grouping the wires together into "crosstalk-of-death" busses instead of
just connecting them point-to-point. Second hardest was banging into their
heads to connect multi-drop traces every other section first, so you can rip
up and re-route easier later on. Happy days!
Cheers, Syms.
Andy Peters
> >A second is a simple logic analyzer. Of course, the hard part here is
> >writing a Windows (or Mac OS X or Linux) host program.
>
> USB seems like the obvious choice, but I don't think any of the low cost
> demo boards support that.
Getting data from the analyzer hardware to the host computer isn't a
problem. It's cooking up a nice display on said host computer that's
the problem, at least for me. I plead "Hardware guy, your Honor."
I will say that it was easier to get my HID stuff working on Mac OS X
than it was on Windows.
-a
Phil Tomson
NDA's don't count as open. Is the Atmel part 'capable'?
>
>As of BIG FPGA companies making their bitstream format public - do not hope!
>
>because the bitstream holds not only the 'known' bits like routing and LUT,
>but
>also factory stuff
>
>bits that compensate against technology changes, those are 'figured out' by
>actual measurement by the FPGA companies AFTER wafers are manufactured
>that is the FPGA companies makes their chips to have a little 'fine tuning'
>to
>be done, this fixing is done by bitgen and is totally invisible for the
>normal user.
>
>second there are factory test bits and settings, again something that the
>end
>user should not mess up
>
>there are some hidden FPGA primitives that are partially visible for the
>end user but not useable by end user, like PMV primitive in V4 and S3
>
>there are probably hidden features and primitives that are totally invisble
>for the end user as well.
>
>so there are reasons for keeping the bitstream non public.
>
>for Xilinx and Lattice the main bitstream info is in NeoCad "BFD" files,
>those are simple ordered lists of bit names, bitgen uses that
> info to convert an NCD to bitstream
>
>NCD file is almost 1:1 the same as the XDL file would be so actually
>pretty much of the bit info is visible for those who want to see
>
Where can one find more info on NCD and XDL file formats (and what the
acronymns stand for)? Are you implying that if one has this NCD file that one
can figure out the bitstream format?
Phil
Phil Tomson
Kolja Sulimma <ne...@sulimma.de> wrote:
>Tobias Weingartner schrieb:
>
>>>so there are reasons for keeping the bitstream non public.
>
>> I happen to disagree. We are all entitled to our opinions of course.
>> If the vendors would have a well defined format to "compile" to, and
>> a good library/port for a program to be able to take this format and
>> then generate a bitstream, that would be a start. Note, I'd want to
>> have the source available to be so that I could port this last bit of
>> "technology" to my favourite OS (by choice or necessity).
>>
>> I can't believe that these things are anything but simple portable ANSI
>> C (or some derivative)...
>
>JBits is a solution to all this. Maybe not a particulary good one, but
>you can read, modify, write bitstreams in a platform independant way.
>There is no source code available, but java bytecode that you can
>essentially call by any language you want on any platform you want.
It looks like JBits is a University-developed tool. why wouldn't the source
code be available?
>
>There are even people at xilinx working on a virtual file system to
>mount and modify the configuration of a virtex-4 by the embedded PowerPC.
>
interesting.
Phil
Phil Tomson
Ray Andraka <r...@andraka.com> wrote:
>Tobias Weingartner wrote:
>
>>
>> I happen to disagree. We are all entitled to our opinions of course.
>> If the vendors would have a well defined format to "compile" to, and
>> a good library/port for a program to be able to take this format and
>> then generate a bitstream, that would be a start. Note, I'd want to
>> have the source available to be so that I could port this last bit of
>> "technology" to my favourite OS (by choice or necessity).
>>
>> I can't believe that these things are anything but simple portable ANSI
>> C (or some derivative)...
>>
>
>The problem is the bitstream is very tightly tied to the architecture of
>the FPGA cell. Having a well defined format tightly constrains the FPGA
>architecture to the one the bitstream format is published for. What
>that means is that either the format has to change for every fpga
>variant out there, now and in the future, or the FPGA has to be frozen
>in order to comply with the bitstream format.
>
>There is far more coupling between the bitstream in an FPGA and its
>hardware than there is between an instruction set and a processor
>architecture because of the fine granularity of the configuration of the
>FPGA. In other words, an instruction set in a microprocessor controls
>relatively few connections between some very complex blocks. The FPGA
>bit stream controls many many connections between lots of small simple
>blocks, so if the bitstream format is predefined by a standard there is
>very little lattitude for evolving the FPGA's structure.
Sure it might change with each new FPGA (or it might even change more often
than that). Still the information is somewhere. Right now I'm sure there are
internal docs at Xilinx/Altera which document the formats for their tool
developers. What would be so bad if they also put those on the web (with a
caveat of course that says, "you're on your own: we don't support you playing
with the bitstream directly, but if you want to have at it")
>
>I'm not sure I see what the big push for having bitstream access is.
>I've yet to see a compelling need for it that is not addressed by the
>existing tools (there is always XDL if you really want to bit bang).
I guess I'll have to look into this XDL to see what it is. Is it a higher
level description of the bitsteam format?
>The only reason that seems to surface is to allow outside parties to
>develop their own place and route tools. Frankly, I don't think the
>complexity of modern FPGAs is such that this type of undertaking can
>improve on or even compete with the free place and route tools already
>offered by the FPGA vendors in the timeframe between device introduction
>and obsolescence.
You're probably right, but people want to be able to tinker. There's the push
for open source tools as well as academic research into P&R algorithms, etc.
People have lots of reasons for wanting to try these sorts of things.
> Anyway, for those hadry enough to try, as I said, the
>XDL tools do give you enough access to every step of the design flow to
>allow you to play with any step you feel compelled to play with.
I'll have to google for XDL.
Phil
Phil Tomson
But this would require that we know the bitstream format, right? Can you
elaborate a bit (no pun intended) on this dynamic bistream generator idea?
Phil
Phil Tomson
Interesting idea. Are you saying that a XC6200 model would be developed in
HDL and then run through synt, p&r, etc. and that could then be used for
downloading the bitstream to?
...but like you say, you would be taking a big performance/area hit.
If you were going to do that, then why not just create some sort of
higher level Virtual FGPA device (kind of like what a Virtual Machine is to the
software world) that would have lots of nice high-level features (high-level
macros available, etc.) and also be tunable for the underlying architecture
(depending on whether the target was Xilinx, Altera, or Lattice. Just as VMs
allow for easier porting, greater genericity, etc. maybe something like a VFPGA
could have similar advantages? Also, just like the Java VM doesn't care what
underlying architecture it's running on, this sort of thing could potentially
make it easier to port designs between FPGA families... I wonder if it could be
done such that there is a minimal impact on performance and area?
Phil
Martin Thompson
>
> Where can one find more info on NCD and XDL file formats (and what the
> acronymns stand for)? Are you implying that if one has this NCD file that one
> can figure out the bitstream format?
>
> Phil
As I understand it, the XDL is a textual representation of NCD. The
NCD is the native circuit database, which has pretty much everything
required to make a bitstream (logic, placement, routing, startup
values, BRAM contents etc). If you run "xdl -ncd2xdl" you can get the
XDL equivalent, hack it about and then regenerate the NCD from the XDL
and from there go to a bitstream... You can also get a list of all
the resources in the device using the -report mode of "xdl".
Presumably you could create various small designs in XDL, NCD them and
then convert to bitstreams and by diffing the bitstream figure out
what was going on. In theory you could also automoate this...
Cheers,
Martin
--
martin.j...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt
Andy Peters
> Where can one find more info on NCD and XDL file formats (and what the
> acronymns stand for)? Are you implying that if one has this NCD file that one
> can figure out the bitstream format?
If I recall correctly, the NCD format came from Neocad, a company whose
P&R tools were better than Xilinx' own. So Xilinx bought 'em. This
was back when the XC3000s were the bleeding edge.
-a
Phil Tomson
Martin Thompson <martin.j...@trw.com> wrote:
>pt...@aracnet.com (Phil Tomson) writes:
>
>>
>> Where can one find more info on NCD and XDL file formats (and what the
>> acronymns stand for)? Are you implying that if one has this NCD file that one
>> can figure out the bitstream format?
>>
>> Phil
>
>
>As I understand it, the XDL is a textual representation of NCD. The
>NCD is the native circuit database, which has pretty much everything
>required to make a bitstream (logic, placement, routing, startup
>values, BRAM contents etc). If you run "xdl -ncd2xdl" you can get the
>XDL equivalent, hack it about and then regenerate the NCD from the XDL
>and from there go to a bitstream... You can also get a list of all
>the resources in the device using the -report mode of "xdl".
>
>Presumably you could create various small designs in XDL, NCD them and
>then convert to bitstreams and by diffing the bitstream figure out
>what was going on. In theory you could also automoate this...
>
So xdl come with the webpack?
Phil
Eric Smith
> It looks like JBits is a University-developed tool. why wouldn't the source
> code be available?
If it really was developed at a university, the university probably signed
an NDA with Xilinx to get the bitstream details.
Austin Lesea
Is a Xilinx invention, developed here.
Austin
Tobias Weingartner
>
> I'm not sure I see what the big push for having bitstream access is.
Do you happen to have a means to create a bitstream (from whatever
ASCII represented primitives) on for example OpenBSD? Or from a perl
script running on an OpenVMS system?
Your (the vendor's) tools so lovingly provided are not always the ideal
tool for the job, nor is the environment always readily available in
order to use them.
> I've yet to see a compelling need for it that is not addressed by the
> existing tools (there is always XDL if you really want to bit bang).
Yes, but how to convert XDL into something that I can shoot into the FPGA?
> The only reason that seems to surface is to allow outside parties to
> develop their own place and route tools. Frankly, I don't think the
> complexity of modern FPGAs is such that this type of undertaking can
> improve on or even compete with the free place and route tools already
> offered by the FPGA vendors in the timeframe between device introduction
> and obsolescence.
The gist is not really to compete in a space where a company has invested
in millions to create a product, but to play in a space where nobody else
is going.
> Anyway, for those hadry enough to try, as I said, the
> XDL tools do give you enough access to every step of the design flow to
> allow you to play with any step you feel compelled to play with.
But the tools are in the environment of your choosing.
Tobias Weingartner
>
> Tobias, this subject has been discussed ad nauseam, in this newsgroup
> and elsewhere.
Well, talking to actel, they cite "competitor" reasons for not giving
away this information.
> The reason for the "secrecy" is not so much fear of giving away secrets
> to a competitor, but rather fear of becoming inundated with support
> issues. We have about 100,000 designers using our parts, a few dozen
> of them exploring and abusing subtle aspects could easily bring our
> support hotline (and this newsgroup) to its knees.
Xilinx (as much as this is "official" in any way) is citing a fear of
being not able to meet the support issues.
> Also, the non-open nature of the bitstream provides our customers a
> certain level of security against reverse-engineering rip-off.
Bullshit. I can get the bitstream and parts are readily available.
There is little to no need to reverse-engineer your customers' design.
It's right there for me to use, should I care to. Also, should I want
to reverse-engineer things, it would not be *that* hard. I'm sure that
I could get various pieces out of the bitstream that would be usefull
to me (along with traces/etc) in doing a 80% job.
If you want security, provide it. Have a means to program a OTP flash
(or somesuch) piece of hardware on your FPGA with an AES key, and have
the bitstream flash device have its bitstream encrypted with the same
key. At this point, things would considerably more "challenging" to
reverse-engineer. I'm no VLSI designer, but I can't imagine that putting
a simple AES engine onto the FPGA, along with some OTP ram for the key,
would take any significant room. As a bonus, you may be able to offer
the simple AES engine for the FPGA to use once programming is done.
> Our primary obligation is to remain an innovative and profitable
> company, to the benefit of our customers, our employees, and our
> shareholders. Satisfying exotic academic research is fine, as long as
> it does not conflict with the primary obligation.
Certainly. Does the "idea" I have given above (which is available in
many forms on the web, etc) mean that you could use it, implement it,
and have yet another innovative & profitable device on your hands? :)
Open documentation (not necessarily support) tends to foster collaboration
and innovation on many fronts. The "encrypted config bitstream" idea is
hardly new or novel, but I'm sure there are many people out there who would
welcome the chance to get their creative juices flowing...
> Just my personal opinion...
Darn. :)
Tobias Weingartner
>
> And then there's the little matter of the ML403 kit Xilinx offers with
> the Virtex 4 FX and the EDK. As a hobbyist, I'm cringing at the thought
> of putting $895 into this. At the same time, I'm going, hmm, what could
> I do with the PowerPC chip or the MicroBlaze? Hmm, no it's too much
> money.... But I keep thinking about it :-) I know Xilinx doesn't
> really target people like me, but I keep hoping for a half-price sale or
> a hobby bundle on the ML403 (no support, no commercial use or you give
> up your first born, etc).
I know what you feel like. We have the XC2S50 here on some demo boards
from somewhere. They're ok to play around with. Nowadays I'm salivating
over XC3S1500/2000 boards. If I could find something with 3 to 6 of these
on board (even the 1000 version), and good chunk of sram, for less than
$1k, I'd be a very happy camper...
Austin Lesea
-snip-
> If you want security, provide it. Have a means to program a OTP flash
> (or somesuch) piece of hardware on your FPGA with an AES key, and have
> the bitstream flash device have its bitstream encrypted with the same
> key. At this point, things would considerably more "challenging" to
> reverse-engineer. I'm no VLSI designer, but I can't imagine that putting
> a simple AES engine onto the FPGA, along with some OTP ram for the key,
> would take any significant room. As a bonus, you may be able to offer
> the simple AES engine for the FPGA to use once programming is done.
Not that we will not do what you suggest (someday), but reverse
engineering OTP memory is very cheap, and is considered quite insecure.
That is the reason why RAM backed up by a battery is the only solution
that is acceptable to the US federal government (FIPS-41), and to TV set
cable box vendors...
The one time programmable key might be sufficient as a deterrent, and
will certainly slow down the process of ripping off the design. I
agree. But please do not put it forth as being "secure."
Austin
Brian Drummond
>In article <9p7ns1pch437c81ln...@4ax.com>,
>Brian Drummond <br...@shapes.demon.co.uk> wrote:
>>On 15 Jan 2006 21:39:16 GMT, pt...@aracnet.com (Phil Tomson) wrote:
>>Last really open system was the XC6200. But it failed commercially, at
>>least in part, because it was a finer grained architecture.
>>
>>FPGA capacities should now be big enough to support a "virtual FPGA"
>>layer on top of a real FPGA, using only the "public" parts of the
>>bitstream
>>I think it would be big enough to exercise open source development tools
>>until something better came along...
>>
>
>Interesting idea. Are you saying that a XC6200 model would be developed in
>HDL and then run through synt, p&r, etc. and that could then be used for
>downloading the bitstream to?
Something like that; though I doubt the XC6200 would be the best
starting point.
>...but like you say, you would be taking a big performance/area hit.
>
>If you were going to do that, then why not just create some sort of
>higher level Virtual FGPA device (kind of like what a Virtual Machine is to the
>software world) that would have lots of nice high-level features (high-level
>macros available, etc.) and also be tunable for the underlying architecture
>(depending on whether the target was Xilinx, Altera, or Lattice.
It looks possible, especially if the basic elements were a
common-denominator subset of individual targets like Xilinx; e.g.
4-input LUTs followed by registers, with some sort of carry chain.
>Also, just like the Java VM doesn't care what
>underlying architecture it's running on, this sort of thing could potentially
>make it easier to port designs between FPGA families...
But no easier than behavioural VHDL code, in my opinion.
>I wonder if it could be
>done such that there is a minimal impact on performance and area?
ummm, in a sense; if you are willing to use the "native" routing on each
target, and allow each company's "native" tools to perform the routing,
placement, bitstream generation (because they know the details of that
target and its bitstream). And even then, you will lose some performance
on at least some targets.
But that is a completely different issue than trying to keep every level
of the design "open"...
IMO the closest you will get to allowing open tools to participate
WITHOUT taking a big performance hit is the XDL approach. It's a text
version of the NCD format - parseable and even human readable - with
converters to/from NCD format. So you could potentially take an EDIF
netlist and create open source tools to "map" it to an unplaced XDL, or
use the Xilinx mapper and convert its output to XDL. Then create open
source tools to floorplan, place and route in XDL format. Those portions
of the tool flow are where the challenges are; and if you create
something worthwhile, it would be useful to many Xilinx users.
You would realistically then have to use Xilinx tools to convert XDL to
NCD and translate the completed design into a bitstream format. This is
pretty much a straight translation and not very interesting in my book;
though it would be a wart on an otherwise complete open source
toolchain.
- Brian
Peter Alfke
uninhibited free thinking, unburdened by mundane practicality.
But beware that some of your sentences sound not just enthusiastic and
uninhibited, but also ill informed. Life would be easy if the world
were a simple as you see it.
Of course we have evaluated non-volatile storage on an FPGA, and we
offer a decryption engine in every Virtex-4 device that we ship. With
battery-backed-up SRAM key storage, because we know that Flash storage
offers no security worth talking about.
And several smart people at Xilinx (and surely also in Altera) are
still thinking very hard about a technically and economically viable
solution. We gladly take advice. But it has to be more substantial than
what you seem to offer.
Peter Alfke
Phil Tomson
True. The only gains might come when describing memories and other larger
blocks which tend to be different from family to family... but there are other
easier ways of 'genericisizing' those things too.
>
>>I wonder if it could be
>>done such that there is a minimal impact on performance and area?
>
>ummm, in a sense; if you are willing to use the "native" routing on each
>target, and allow each company's "native" tools to perform the routing,
>placement, bitstream generation (because they know the details of that
>target and its bitstream). And even then, you will lose some performance
>on at least some targets.
>
>But that is a completely different issue than trying to keep every level
>of the design "open"...
>
>
>IMO the closest you will get to allowing open tools to participate
>WITHOUT taking a big performance hit is the XDL approach. It's a text
>version of the NCD format - parseable and even human readable - with
>converters to/from NCD format. So you could potentially take an EDIF
>netlist and create open source tools to "map" it to an unplaced XDL, or
>use the Xilinx mapper and convert its output to XDL. Then create open
>source tools to floorplan, place and route in XDL format. Those portions
>of the tool flow are where the challenges are; and if you create
>something worthwhile, it would be useful to many Xilinx users.
>
Is XDL described anywhere? Grammar or BNF? Or is it based on XML? (probably
not likely, but one can wish)
>You would realistically then have to use Xilinx tools to convert XDL to
>NCD and translate the completed design into a bitstream format. This is
>pretty much a straight translation and not very interesting in my book;
>though it would be a wart on an otherwise complete open source
>toolchain.
Well, you have to start somewhere.
Phil
fpga...@yahoo.com
Piotr Wyderski wrote:
> Now the SMD components in TQFP/SO/TSSOP are no longer a
> problem. But we still don't know how to solder BGAs and QFNs...
I showed my homebrew club how to reball and attach Xilinx BG560's
here in my wifes digital convection oven well over a year ago. It takes
a small amount of practice, which gets manageable when you also are
willing to bake and reball. There are lots of trash FPGA's to be had on
boards for a few dollars, and Solderquik preforms make reballing easy.
KISS projects can frequently be pulled off with double sided boards,
which
are cheap from a number of sources. If doing BGA, they need to be
solder
mask over bare copper (SMOBC) to prevent the balls from wicking under
the mask.
There should not be ANY expensive home project from a parts
perspective,
as recycling motherboards, industrial boards, disk drives, graphics
cards,
etc are a wealth of nearly zero cost parts. Design with what you can
salvage,
and that is a lot.
I strongly suggest forming a home brew club locally, or even across the
net, and pooling designs onto a PCB panel ... especially when 4, 6, and
8
layer projects are needed. Most of the budget pcb shops refused
panelled
designs, but you can lower your individual costs by sharing NRE's and
setup charges across 3-10 project boards on the same panel. Just be
sure
that you can cut them apart :)
> Hmm, really? ;-) As far as I know the only "pure" hobbyists
> here are Antti and myself, the rest is more or less professional.
I'm pretty sure there are a LOT more than just a few of us. I made
PCB's
in high school (1967) with masking tape for resist, and stoped making
them
at home when the pcb program showed up for my MacIntosh 128 from
Douglas
Electronics. I even stopped wirewrapping about that time because it was
just
quicker and easier to turn one PCB with data paths and most control
paths
in place, and finish the design with point to point wiring and PAL's.
My first BIG hobby project was a Z80 based 9-track tape formatter for
the TMS100
tape drive I had on my LSI11/23 Unix home computer, which I had to go
buy a TRS-80
to write the firmware for.
My current home computer project is a couple thousand FPGA home super
computer,
which I've been working toward for a couple years now, mostly because I
like big fast
computers, it's one hell of a challenge, and I needed retraining in
building state of the
art computer systems after being a Unix systems programmer for too many
years.
I do knock off flat fee contract hardware and software designs from
time to time, and
I'm also currently looking for projects. I will also be turning some of
the smaller spare
fpga's from my home computer project into low cost student boards -
using environmentally
friendly recycled parts.
John
fpga...@yahoo.com
Piotr Wyderski wrote:
> But they do not provide free simulators, so they are virtually useless for
> hobbyists.
I should probably add that Steve's Icarus Verilog (IV) solves that
problem in the
low cost open source tools department. And it works well targeting
fairly
good sized XC4K's and Spartan chips which are easy to design with since
they only require a 3.3V supply. Pick off an older Seagate drive, and
you
will have a dual 1a linear regulator, 2MB SDRAM, EEPROM with boot
sector, cap's, and a few other parts to build an interesting robot
controller,
stomp box effects processor, home controller, or other project with a
5V
recycled wall wart.
And FpgaC for open source reconfigurable computing (read executing C
code as circuits) is getting off the ground to do the same for C coders
not interested in learning VHDL/Verilog as their only way to program
fpgas.
You will find both FpgaC and IV on sourceforge.
fpga...@yahoo.com
Ray Andraka wrote:
> I'm not sure I see what the big push for having bitstream access is.
> existing tools (there is always XDL if you really want to bit bang).
> develop their own place and route tools. Frankly, I don't think the
> complexity of modern FPGAs is such that this type of undertaking can
> improve on or even compete with the free place and route tools already
> offered by the FPGA vendors in the timeframe between device introduction
> XDL tools do give you enough access to every step of the design flow to
> allow you to play with any step you feel compelled to play with.
Actually, I would like to compile, load and go fair sized algorithms
without
having to spend hours in place and route. I would also like to
dynamically
link library elements on the fly without having to do a xilinx style
design
partition. But these are what software guys want using FPGA's as
computers.
I'm willing to constrain the compiler into bin sorting logic blocks
into acceptable
clock domains, and cross clock domain synchronize when the execution
switches
clock domains. I'm pretty sure that the compiler can generate logic
blocks in RPM's
that will have reasonable performance for testing, and would be just
happy as
a lark if I didn't have to wait for place and route till a project was
completely done.
It comes down to the difference between hardware guys needing to
optimize
cycle times for production needs, and software guys just wanting
something
that will work for testing - two very different ends of the spectrum. I
would be
very happy with place and route tools that I could give a polygon
constraint,
and a few interconnect points to the existing design, and have it
return and
xor'able bit stream referenced to a null design for the polygon that i
could load
on demand. Oh, and it would be really cool, IE necessary, to do that in
under
a second or two, preferably milliseconds.
When there is an fpga vendor that can support partial reconfiguration
on the
fly with dynamic linking of modules with times in the microseconds or
milliseconds
then we will see reconfigurable computing go main stream big time.
Right now
it still feels like compiling my 1401 programs with an N-Pass card deck
compiler
to punched cards. The level of reconfigurability and the granularity of
the tools is
completely bent toward hardware design processes .... some of us would
like
a LOT more.
fpga...@yahoo.com
computing
and self hosted incremental compilers using fpga's as computers would
have
been JHDLbits, a project stalled because the university was (as I
understand
it) unable to get a release to take the project open source because of
NDA
with Xilinx.
A lot of the technology we could use for compile, load and go supported
with
dynamic linking for reconfigurable computing with FpgaC has been
sitting NDA
locked for over a year.
fpga...@yahoo.com
Peter Alfke wrote:
> Tobias, this subject has been discussed ad nauseam, in this newsgroup
> and elsewhere.
> to a competitor, but rather fear of becoming inundated with support
> issues. We have about 100,000 designers using our parts, a few dozen
> of them exploring and abusing subtle aspects could easily bring our
> support hotline (and this newsgroup) to its knees.
That is easily handled by a solid policy of "unsupported" features,
which
can be selectively waved by the company for selected fully paying
customers
which have volume to merit a response.
> Also, the non-open nature of the bitstream provides our customers a
> certain level of security against reverse-engineering rip-off.
Security by obscurity has never worked ... just look at the weekly
exploits
to microsoft windows that result largely due to reverse engineering.
Any engineering team in the world that can manufacture a cloned product
without legal recourse will do exactly that, via reverse engineering if
necessary,
including die probing live parts if necessary. There just has to be an
economic
social, or political incentive first.
> Our primary obligation is to remain an innovative and profitable
> company, to the benefit of our customers, our employees, and our
> shareholders. Satisfying exotic academic research is fine, as long as
> it does not conflict with the primary obligation.
> Just my personal opinion...
> Peter Alfke
exotic academic, or hobby stage, engineering is where garage
innovations
create new industries.
Martin Thompson
> In article <QFTyf.3436$bF.2359@dukeread07>, Ray Andraka wrote:
> > I've yet to see a compelling need for it that is not addressed by the
> > existing tools (there is always XDL if you really want to bit bang).
>
> Yes, but how to convert XDL into something that I can shoot into the FPGA?
>
via NCD (xdl -xdl2ndc) and bitgen
> But the tools are in the environment of your choosing.
>
Ahh well, that is a bit of a limitation :-) They may run under
dosemu... They will under Wine I seem to recall... You could port
that to OpenVMS first :-)
Martin Thompson
I believe so... maybe someone who runs Webpack (we have Foundation
here) can jump in?
Antti Lukats
news:u8xtcb...@trw.com...
for just the purpose of knowing what is in WebPack I have installed
additionally
so I can answer : yes the XDL is included with free WebPack
but the XDL (or NCD) does __not__ contain bitstream info, it does hold the
design info that is not mapped to the bitstream by bitgen later
NCD (that can be viewed as XDL after conversion) is used together
with BFD (NeoCad Bitstream Format Database ?) file by bitgen for
actual bitstream generation.
there are some other files for each family, like GRD, etc I am able to
view pretty much all of the files used by Xilinx tools, (NGC, NCD, etc)
but...
the path from NCD to bitstream is not so 1:1, I have written some
analyzer software for the BFD to see if there is some visible mapping
but the result have been a little confusing so far. oh well I dont have
all the for such a play,
but the reversing of the bitstream info is for sure doable just need
to write some smart analyzer and bit map database auto generation
software and let it run for long time to gather the info for you :)
--
Antti Lukats
fpga...@yahoo.com
Antti Lukats wrote:
> but the reversing of the bitstream info is for sure doable just need
> to write some smart analyzer and bit map database auto generation
> software and let it run for long time to gather the info for you :)
You might want to look a little closer at the license for the web pack,
and any other license you have ever executed with Xilinx, as it wasn't
that long ago that it contained very strong language about reverse
engineering proprietary data.
With the current DMCA state, the law isn't hardly on the side of fair
use for computer software or hardware owners these days. It's
terribly like owning a car, but unable to remove the heads to repair
a valve without getting sued.
Or when the telco's prevented third party phones from being attached
to their systems. When finally lifted an entire industry blossomed
bringing
us cheap cordless phones and digital answering machines that would
never have appeared with the PUC mandated 10 year capital recovery
limitiation on hardware. Ever wonder why WeCo had to over design the
clunky 500 desk set?
fpga...@yahoo.com
remained stuck in the accustic coupler days.
fpga...@yahoo.com
streams
is optimized poorly for reconfigurable computing - if not outright
wrong and
backward. In hardware design you break the design into one or more
clock
domains and fine tune the designs timing constraints in those clock
domains.
For reconfigurable computing, as a comodity general purpose processor
engine
exactly the opposite process needs to occur. The Hardware WILL have
fixed
clock rates available, and maybe even a few setable ones, but in
general the
compiler needs to match code blocks to available clock periods, even if
it's
mismatched by as much as a factor of 2-5. With some basic worst case
timing
data for the target fpga's this is easily done, and the compiler can
bin sort statement
blocks into clock domains on the fly, and emit synchronizers when
necessary to
cross clock domains. This allows statement groups which have horrible
combinatorial
delays to run at one clock speed, and other statement groups with very
flat netlists
and little to no combinatorial delays to run at a faster clock rate ...
"all the compiler
needs" is some clues about general timing costs and the actual runtime
target
capabilities. In some cases this even can be done by fixups by the
'runtime linker"
just prior to loading.
The practial clocking environment for this would be a series of edge
synchronized
clocks spread a factor of two, three, four or five in time (so rising
edges always
match) to avoid synchronizers completely. In such a target execution
environment,
the one hot state machine gating the execution flow can freely cross
clock domains.
Some with a runtime life in days can surely have it's clocks fine
tuned, but for most
applications this granularity is quite reasonable.
Now, how practical its it to hand a netlist with 8 interleaved clock
domains to your
favorite vendors place and route tools, and get back verification of
setup and hold
times for this environment?
Antti Lukats
news:1137688374....@o13g2000cwo.googlegroups.com...
[pretty much anything...]
Atmel bitstream info is all known and its fully runtime reconfigurable
so it makes way more sense to go with Atmel FPGA/FPSLIC if
someones wants self or dynamicall reconfiguring FPGA systems.
Antti
Martin Thompson
> Is XDL described anywhere? Grammar or BNF? Or is it based on XML? (probably
> not likely, but one can wish)
Yes, no, and no :-)
It's described in comments in the XDL file itself:
Here's some of them pasted out of one of mine:
# =======================================================
# The syntax for the design statement is:
# design <design_name> <part> <ncd version>;
# or
# design <design_name> <device> <package> <speed> <ncd_version> ;
# =======================================================
# The syntax for instances is:
# instance <name> <sitedef>, placed <tile> <site>, cfg <string> ;
# or
# instance <name> <sitedef>, unplaced, cfg <string> ;
#
# The syntax for nets is:
# net <name> <type>,
# outpin <inst_name> <inst_pin>,
# .
# .
# inpin <inst_name> <inst_pin>,
# .
# .
# pip <tile> <wire0> <dir> <wire1> , # [<rt>]
# .
# .
# ;
#
etc..etc...
More details then follow on some of the details.
So it is fairly straightforward to understand, assuming you
understand the architecture it's talking about already...
I have made a start on a python parser for XDL which creates a
pysqlite database as the backend. Conekt owns it, but they may be
persuaded to open source it.. I wonder...
Brian Drummond
>>>Also, just like the Java VM doesn't care what
>>>underlying architecture it's running on, this sort of thing could potentially
>>>make it easier to port designs between FPGA families...
>>
>>But no easier than behavioural VHDL code, in my opinion.
>
>True. The only gains might come when describing memories and other larger
>blocks which tend to be different from family to family... but there are other
>easier ways of 'genericisizing' those things too.
Indeed. Any such block should have a completely generic entity,
preferably with a generic architecture, which will at least work for
simulation. If that synthesises down to a million FFs instead of a BRAM,
you can always substitute architecture X or A as appropriate. With
configurations, if the tools support them properly.
- Brian
Tobias Weingartner
>
> Not that we will not do what you suggest (someday), but reverse
> engineering OTP memory is very cheap, and is considered quite insecure.
Sure, a ROM may be such. I dont really care how it's implemented, but
if done as a "persistant write-only" area of the FPGA (from a user's
point of view)... if that is battery backed ram, flash, whatever. I'll
leave the finer details to the VLSI designers... :)
> The one time programmable key might be sufficient as a deterrent, and
> will certainly slow down the process of ripping off the design. I
> agree. But please do not put it forth as being "secure."
Ok, more resistant. :)
Tobias Weingartner
>
> Tobias, we love universities and their students and faculty for their
> uninhibited free thinking, unburdened by mundane practicality.
Ouch. Unfortunately, this is not for university business.
> But beware that some of your sentences sound not just enthusiastic and
> uninhibited, but also ill informed. Life would be easy if the world
> were a simple as you see it.
Life can be as simple as you make it.
> Of course we have evaluated non-volatile storage on an FPGA, and we
> offer a decryption engine in every Virtex-4 device that we ship. With
> battery-backed-up SRAM key storage, because we know that Flash storage
> offers no security worth talking about.
So what you're saying is that for Virtex-4 devices the reason to keep
the bitstream format closed has been reduced by one hurdle. :)
> And several smart people at Xilinx (and surely also in Altera) are
> still thinking very hard about a technically and economically viable
> solution. We gladly take advice. But it has to be more substantial than
> what you seem to offer.
The only advice I was hoping to offer was one of "please reconsider opening
the bitstream format".
Peter Alfke
Tobias Weingartner wrote:
> The only advice I was hoping to offer was one of "please reconsider opening
> the bitstream format".
>
and that is what I strongly take exception to:
"I'm no VLSI designer, but I can't imagine that putting
a simple AES engine onto the FPGA, along with some OTP ram for the key,
would take any significant room. As a bonus, you may be able to offer
the simple AES engine for the FPGA to use once programming is done."
That's what I call simplistic and un-informed advice.
I want to avoid the bovine excrement word...
Peter Alfke
Phil Tomson
Martin Thompson <martin.j...@trw.com> wrote:
>pt...@aracnet.com (Phil Tomson) writes:
>
>
>> Is XDL described anywhere? Grammar or BNF? Or is it based on XML? (probably
>> not likely, but one can wish)
>
>Yes, no, and no :-)
>
>It's described in comments in the XDL file itself:
>
Yes, I discovered this yesterday when I was running xdl and looked at the
outupt. I suppose that's conventient.
Well, I was planning on starting a Ruby-based XDL parser in a week or two.
Looks like it'll be easy. It'll be open source.
Though, I do wonder: once we have an XDL parser, what's the next step?
Phil
Ray Andraka
> Though, I do wonder: once we have an XDL parser, what's the next step?
>
> Phil
Umm, pretty much the same as the next step had someone given you the
bitstream coding. XDL makes it nice because you can play with just one
part of the implementation process and let the existing tools do the
rest, rather than having to reinvent the entire implementation chain.
What more could you want?
Phil Tomson
Ray Andraka <r...@andraka.com> wrote:
>Phil Tomson wrote:
>
>> Though, I do wonder: once we have an XDL parser, what's the next step?
>>
>
>bitstream coding. XDL makes it nice because you can play with just one
>part of the implementation process and let the existing tools do the
>rest, rather than having to reinvent the entire implementation chain.
>What more could you want?
Sure, I understand that. I guess to rephrase my question and expand it:
if we had a an XDL parser and the ability to generate and modify XDL
programatically (and this ability is potentially even more interesting than
being able to parse XDL, I would think) how would you go about using a set of
tools like that?
I ask the question, because how the tool would be used (or how people would
like to make use of the capability ) could help define the features the tool
should have and how it should be developed. I'm looking for some early input
in the design process.
Since bitstreams will likely always be proprietary and it's agreed that XDL
manipulation is the next best thing (at least for Xilinx parts), what's most
important in an XDL tool suite?
In looking at some XDL it just seems like a structural description of the
design using a Xilinx 'library' (with placement info included). The
format itself seems easy enough to parse, however the devil is in the details
(knowing valid placements, routings, pins, finding equivilent mappings, etc.).
While parsing might be easy, making changes or generating completely new XDL
files and determining if they are correct could be very difficult - is the
sort of info that's required even openly available (without NDA)?
Seems like there are lots of possibilities including open source
simulation/synthesis/translation/p&r tools, etc. and long term that might be
the way some might want to use the capability to read(parse) and generate XDL.
However, any of those would be very ambitious projects (and one wonders if
XDL is the right place for doing some of those things). Short term,
what gives the best 'bang for the buck'?
...and here's a concern I have:
If an open source ecosystem were to grow up around
XDL might Xilinx decide that they are uncomfortable with that and at
some point in the future pull the plug by not including the XDL
utility in their tool suite anylonger. The point being that we will still
have to rely on some closed source tools (xdl -> ncd -> bitstream) which
could disappear at any time or be changed so that they no longer operate the
way they do now. Is it a valid concern?
Phil
Antti Lukats
news:dqsue...@enews2.newsguy.com...
no its not a valid concern Xilinx Plan Ahead uses XDL so they can not
remove the XDL support without rewriting Plan Ahead
Antti
Brian Drummond
>In article <3fjAf.9305$bF.2150@dukeread07>,
>Ray Andraka <r...@andraka.com> wrote:
>>Phil Tomson wrote:
>>
>>> Though, I do wonder: once we have an XDL parser, what's the next step?
>if we had a an XDL parser and the ability to generate and modify XDL
>programatically (and this ability is potentially even more interesting than
>being able to parse XDL, I would think) how would you go about using a set of
>tools like that?
>
>I ask the question, because how the tool would be used (or how people would
>like to make use of the capability ) could help define the features the tool
>should have and how it should be developed. I'm looking for some early input
>in the design process.
One option would be help with floorplanning or placement.
My ideas on this are ill-defined, but here are a couple of
suggestions...
(1) (this might be easier at the EDIF stage rather than the XDL stage)
for each register, identify the logic levels to the next register, and
allocate a notional timing to each such level according to its type
(e.g. high for LUT delays, low for carry chain). Sum those timings; the
aim being to find the critical paths and attach a "tight" placement to
them (or modify the existing placement if you think you have found an
improvement)
Initial steps would be experiments to see
(a) if we can reliably identify probable critical paths (i.e. those with
most LUTs between registers
(b) if we can modify placement in XDL and have the Xilinx tools
successfully route the result, without looking for timing improvements.
(c) identify hierarchy from signal names (hence my wondering about EDIF)
and generate placement in a "floorplanner" like manner by regular
placement of buses, registers etc.
(d) then go on to try and beat the Xilinx tools. At which point we might
find their "cloud of LUTs" placement is highly optimised already...
(2) take a post-PAR design which fails timings and a possibly hand
generated (*) list of "problem" components and try to improve placement
for those specific locations. Again, let Xilinx router take over...
(*) related project: parse a .TWR or delay report to generate such a
list.
>Since bitstreams will likely always be proprietary and it's agreed that XDL
>manipulation is the next best thing (at least for Xilinx parts), what's most
>important in an XDL tool suite?
One important thing is to supply missing functionality.
It always bugs me there is no way back into the placer, once the router
has discovered what the placement problems are! Using "MPPR" is a brute
force way of "fiddling" with the placement, discarding the router's
hard-won experience instead of recycling it. The fact that an MPPR set
can show 10% or so variation in fmax on the same design suggests there
is something to be won here.
>However, any of those would be very ambitious projects (and one wonders if
>XDL is the right place for doing some of those things). Short term,
>what gives the best 'bang for the buck'?
A tool which took a failed PAR and its TWR and had, say, 80% chance of
fixing the failing paths quite quickly (i.e. not overnight!) might win a
few friends...
It ( = no.2 above) looks achievable (maybe with sub-100% success rate).
Hand-waving evidence: I have maybe 30% or 50% of the time, moved a
couple of obviously badly placed elements in FPGA editor and met timing.
Other times I have fixed the error I was working on but created 50 more.
But I can only search slower than FPGA editor can draw; a machine could
search many more options and search deeper, looking for disastrous
consequences of a simple looking move. (e.g. if the offending LUT is
halfway up a carry chain, watch out!)
For bonus points, let it replicate that FF (or LUT in a carry chain)
that REALLY needs to be in two opposite corners of the chip at once!
A first pass would probably have to be restricted to single clock domain
designs, or otherwise simplified, as a proof of concept. Also, it would
suffice to rip out the routing where you move something, and let PAR
take over on the result.
>...and here's a concern I have:
>If an open source ecosystem were to grow up around
>XDL might Xilinx decide that they are uncomfortable with that and at
>some point in the future pull the plug by not including the XDL
>utility in their tool suite anylonger. The point being that we will still
>have to rely on some closed source tools (xdl -> ncd -> bitstream) which
>could disappear at any time or be changed so that they no longer operate the
>way they do now. Is it a valid concern?
If XDL helps sell Brand X chips ...
Another valid concern would be - if the open source tools actually DID
embarrass the in-house ones (say, achieve 10% better fmax 50% of the
time), what do Xilinx do? I don't see them discouraging performance
improvements ... I do see them wanting to incorporate the best ideas
into their own tools. But how?
And if they don't embarrass the in-house tools, where's the problem?
- Brian
Phil Tomson
Can XDL go back into PAR?
>
>>Since bitstreams will likely always be proprietary and it's agreed that XDL
>>manipulation is the next best thing (at least for Xilinx parts), what's most
>>important in an XDL tool suite?
>
>One important thing is to supply missing functionality.
>
good point.
>It always bugs me there is no way back into the placer, once the router
>has discovered what the placement problems are! Using "MPPR" is a brute
>force way of "fiddling" with the placement, discarding the router's
>hard-won experience instead of recycling it. The fact that an MPPR set
>can show 10% or so variation in fmax on the same design suggests there
>is something to be won here.
>
>>However, any of those would be very ambitious projects (and one wonders if
>>XDL is the right place for doing some of those things). Short term,
>>what gives the best 'bang for the buck'?
>
>A tool which took a failed PAR and its TWR and had, say, 80% chance of
>fixing the failing paths quite quickly (i.e. not overnight!) might win a
>few friends...
But again, how would we get back into PAR from XDL, can you offer more
details? I suppose if PAR doesn't accept XDL, that it must accept a list of
critical nets and we would generate that based on the knowledge extracted from
the XDL and timing report.
Offer us jobs (telecommuting jobs where we don't have to move to the Bay Area,
please ;-)? Maybe just a cash reward would suffice ;-)
>I don't see them discouraging performance
>improvements ... I do see them wanting to incorporate the best ideas
>into their own tools. But how?
>
>And if they don't embarrass the in-house tools, where's the problem?
I suppose you're right. It's just that in my experience corporations like
control (that's mainly why bitstreams are closed, right?).... what was it I
read recently (I think it was in Businessweek) something about
how most corporate organizations look a lot like the Soviet Politburo and that
while democracy has made huge inroads all over the world, it hasn't made much
progress in corporate America. Seemed apt.
Phil
Alex Gibson
"Eric Smith" <er...@brouhaha.com> wrote in message
news:qhmzhzs...@ruckus.brouhaha.com...
> "Peter Alfke" <pe...@xilinx.com> writes:
>> I have struggled for decades to come up with enticing demo projects for
>> digital circuits, and I have made my rules:
>> It must be something that cannot be done with just a microprocessor.
>> That means it must be something fast. Audio, video, radio, robotics
>> come to mind.
>
> What? No traffic lights and vending machines? :-)
>
> It's always entertaining when people pop up in various newsgroups
> (including this one), wanting help with their vending machine project,
> and insisting that it isn't homework.
But why would you set one of these as an assignment as there are
lots of such projects on the net?
Alex
Antti Lukats
> In article <6gh4t1d9bsi0sfs3s...@4ax.com>,
> Brian Drummond <br...@shapes.demon.co.uk> wrote:
>>On 21 Jan 2006 09:21:06 GMT, pt...@aracnet.com (Phil Tomson) wrote:
>>A tool which took a failed PAR and its TWR and had, say, 80% chance of
>>fixing the failing paths quite quickly (i.e. not overnight!) might win a
>>few friends...
>
> But again, how would we get back into PAR from XDL, can you offer more
> details? I suppose if PAR doesn't accept XDL, that it must accept a list
> of
> critical nets and we would generate that based on the knowledge extracted
> from
> the XDL and timing report.
>
XDL is almost the same as NCD and as NMC (hard macro) is actually also a NCD
I think it is possible to create XDL based hard macros that are converted to
NCD
and renamed to NMC then used again by PAR that could be one way
antti
Brian Drummond
>In article <6gh4t1d9bsi0sfs3s...@4ax.com>,
>Brian Drummond <br...@shapes.demon.co.uk> wrote:
>>On 21 Jan 2006 09:21:06 GMT, pt...@aracnet.com (Phil Tomson) wrote:
>>
>>>In article <3fjAf.9305$bF.2150@dukeread07>,
>>>Ray Andraka <r...@andraka.com> wrote:
>>>>Phil Tomson wrote:
>>>>
>>>>> Though, I do wonder: once we have an XDL parser, what's the next step?
>>One option would be help with floorplanning or placement.
>>
>>My ideas on this are ill-defined, but here are a couple of
>>suggestions...
>>(2) take a post-PAR design which fails timings and a possibly hand
>>generated (*) list of "problem" components and try to improve placement
>>for those specific locations. Again, let Xilinx router take over...
>>
>Can XDL go back into PAR?
No, but it can translate back to a new .ncd file. Which WILL go back
into PAR - look at "re-entrant routing" and/or "guided design" in the
documentation.
>>A tool which took a failed PAR and its TWR and had, say, 80% chance of
>>fixing the failing paths quite quickly (i.e. not overnight!) might win a
>>few friends...
>
>But again, how would we get back into PAR from XDL, can you offer more
>details? I suppose if PAR doesn't accept XDL, that it must accept a list of
>critical nets and we would generate that based on the knowledge extracted from
>the XDL and timing report.
I don't think you need more than the above - and I haven't tried it
since Foundation 3.1. It seemed to work but I don't recall actually
modifying the XDL.
>>For bonus points, let it replicate that FF (or LUT in a carry chain)
>>that REALLY needs to be in two opposite corners of the chip at once!
The more I think about it, the more this one appeals. It's simple,
pragmatic, and fairly testable.
>>>...and here's a concern I have:
>>>If an open source ecosystem were to grow up around
>>>XDL might Xilinx decide that they are uncomfortable with that
>>If XDL helps sell Brand X chips ...
>>
>>Another valid concern would be - if the open source tools actually DID
>>embarrass the in-house ones (say, achieve 10% better fmax 50% of the
>>time), what do Xilinx do?
>Offer us jobs (telecommuting jobs where we don't have to move to the Bay Area,
>please ;-)? Maybe just a cash reward would suffice ;-)
Well, who knows? ;-)
Look at the record so far ... what happened to Neocad, whoever wrote
PlanAhead, and now AccelChip.
Even the late lamented XC6200 originally came from a Scottish startup,
http://algotronix.com/people/tom/album.html
and I honestly believe Xilinx tried to make it fly for a few years.
>>And if they don't embarrass the in-house tools, where's the problem?
>
>I suppose you're right. It's just that in my experience corporations like
>control (that's mainly why bitstreams are closed, right?).... what was it I
>read recently (I think it was in Businessweek) something about
>how most corporate organizations look a lot like the Soviet Politburo and that
>while democracy has made huge inroads all over the world, it hasn't made much
>progress in corporate America. Seemed apt.
Well, IMO we can give them that control by not fighting them on Bitgen
(the uninteresting "translation") AND get most of what we want (openness
on the interesting bits, i.e. where you can win/lose performance) using
XDL.
- Brian
Phil Tomson
Should probably start a development wiki somewhere so we can document some of
these ideas better. That'll have to wait 2 or 3 weeks until after my current
projects are finished...
>>>>...and here's a concern I have:
>>>>If an open source ecosystem were to grow up around
>>>>XDL might Xilinx decide that they are uncomfortable with that
>>>If XDL helps sell Brand X chips ...
>>>
>>>Another valid concern would be - if the open source tools actually DID
>>>embarrass the in-house ones (say, achieve 10% better fmax 50% of the
>>>time), what do Xilinx do?
>>Offer us jobs (telecommuting jobs where we don't have to move to the Bay Area,
>>please ;-)? Maybe just a cash reward would suffice ;-)
>
>Well, who knows? ;-)
>Look at the record so far ... what happened to Neocad, whoever wrote
>PlanAhead, and now AccelChip.
>Even the late lamented XC6200 originally came from a Scottish startup,
>http://algotronix.com/people/tom/album.html
>and I honestly believe Xilinx tried to make it fly for a few years.
>
Well, those were companies.... I'd prefer to stay on the open source side for
most of this, but maybe there's a way to do a startup that's totally open
source (?)
Phil