please see embedded remarks below.
Dick
-----Original Message-----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Friday, August 27, 1999 1:04 PM
Subject: Re: PDP era and a question
>
> addressing only the comment quoted below . . .
>
> Really, Tony, I think you overemphasize the importance of the individual
> user to the semiconductor manufacturers. The level of competition for
the
> FPGA business has escalated to where the
development software, previously
> costing several K-bucks US, now costs as little as $100, and, in the case
of
> ALTERA, is quite free. Now, that's not the
complete package with all the
> bells and whistles, but it's enough to build a device from start to
finish.
You've misunderstood me...
There are several points here.
Firstly, it doesn't matter how cheap the software is if you can't use it.
It depends more on how you define "can't" than anything else, though.
To run one of those 'free' development systems,
I'd have to get a new PC
that I couldn't maintain and an 'OS' that I would find unpleasant to use.
I had the same feeling when just about all the useable CAD/CAE software was
limited to VMS and UNIX. I bought and limped along with what I could get
for the PC, back then using DOS and customized drivers for the appropriate
display, which, back then, alone, cost about as much as my then new logic
analyzer. What that is, Tony, is a matter of preference. YOU have to
decide where YOU spend your money.
In yesterday's newspaper I noted that the local discount house (Best-Buy for
those who care) was offering a major-brand 350 MHz Celeron-based computer
system without monitor but with AGP video, 6.4 GB HDD, 64 MB memory, CDROM,
FDD, v.90 modem, keyboard, all for $399 US. A really nice (I recently
bought one when the "appropriate display" (19") mentioned above developed
a
margin problem.) 17" monitor for $199. That means that for what I typically
earn in a couple or three days after taxes and expenses, I can buy a whole
computer system capable of doing this FPGA stuff.
I recently read that the folks who sell these FPGA's have no problem at all
giving you the necessary data to enable you to configure their parts. They
won't give you a disassembly tool or whatever that would be, but they'll
tell you enough so you can build your own configuration tools to support
their parts. They won't hold your hand and they won't debug your work, but
they will give you a spec so you don't have to buy their software or use it.
The total cost would (instead) buy some useful physical
test equipment or
tools.
I bought a 20-year old 250 MHz 'scope not long ago with what that system at
Best Buy would cost. Now, I shopped for a year in order to find the thing,
but that's what I got for $600.
Secondly, I like all my software to be open-source so that I can fix
bugs. Now, I can quite understand why commercial software isn't like
this. What I am commenting on is the fact that I _can't_ write my own
FPGA tools if I wanted to.
All software is open-source if you have the dough to buy the sources. Not
all of us are willing to pay the required 6.23*10^23 bucks for what we'd
otherwise get for less than $1k for just the objects.
Let me give you an example. If I want to program a PDP11 in assembler, I
can either buy the DEC assembler (which, quite rightly, costs money), or
I can get down the manual and either hand-assemble the code or write an
assembler myself. I can add in whatever features I want in the latter
case as well.
With FPGA tools, you can't write your own. Manufacturers have given a
number of reasons, most of them (IMHO) bogus as to why they won't release
the configuration specs. But with one exception (the XC6200 series), now
discontinued, there has never been an FPGA (or CPLD) where you can go
from schematic/description to a finished chip without some 'undocumented'
process. It's like having a processor where the binary opcodes are not
documented anywhere, and where the manufacture actively prevents this
sort of information getting out.
Again, it's just a matter of preference. Most people get by this hurdle
with little trouble.
FWIW, I have 'hand assembled' configurations for the XC6216. It wasn't
that hard, and writing a few simple tools would have made it a lot easier.
>
> I really doubt that it would turn out to be illegal to take the old 11-70
or
> whatever schematic and essentially clone it in an
FPGA, but I doubt a
clever
> rebuilder would want to do that anyway. It might
be either equally good
in
You wouldn't. FPGA design is most certainly not the same as TTL-type
design, and simply translating circuits will result in something that
doesn't work.
> The technology in FPGA's these days is such that it enables devices to
> operate between 10 and 50 times the speed of the old TTL logic designed
in
Hmmm.. A good TTL design will go at 50MHz, no trouble. FPGAs are between
500MHz and 2.5GHz? That sounds high to me. It certainly sounds high
compared to the real-world speeds (not what the manufacturers claim) for
common FPGA devics. A factor of 2 or 3 up on TTL, maybe.
There's a brocheure lying about here somewhere from a company which offers a
XILINX look-alike which operates with delays of about half those of the
fastest XILINX, though there's some question about the universality of that
claim, but they certainly explain why their routing delays are shorter.
Prop-delays of 1ns are claimed for the combinatorial logic in several
vendors' parts, and the claim of 25 MHz for 7400-series TTL was quite
generous. It would propagate into a light load and single flops would keep
up at 25 MHz. I remember a countdown chain which generated a bunch of
system timing from a 24.576 MHz clock, which was a harmonic of nearly all
the telecom clocks as well as baud rates. That one didn't work until one
substituted 74S-series TTL. HTTL and LSTTL wouldn't do it. The clock-to-Q
of the flops just wouldn't meet the required setup times. Now, it worked
fine once we rebuilt the counter chain so it ran at half that rate. Lots of
'70's TTL MSI would work at rates in excess of 30 MHz, but only for small
circuits. You could run one shift register at that rate, but if you needed
to shift longer words, you might be in trouble. It was even worse with
counters. If you then needed to decode the outputs of a 16-bit counter . .
. you see my point, I'm sure. These same problems are encountered in
FPGA's, but the circuits whose timing is critical can be planned out in such
a way that the penalties for routing delays are minimized. What's more,
because adding a pipeline register doesn't mean putting another package on
the board, you can do that. Pipeline registers increase operating frequency
while increasing the latency. They make decoding much safer.
-tony