Programmers have been a problem for us, the users, as well as for the PLD
vendors. That's why they'r so much behind the in-situ-programming features,
and that's why they support it so happily. If you use THEIR hardware to
program their device, there's never a problem. (or that's what they say)
I bought a universal programmer in the late '80's that, according to the
vendor, programmed the devices I wanted to use. After I had it, I found that
it didn't program the parts, damaging them instead, and they were not cheap
parts. I found that it was necessary to have adapters for many of the devices
I wanted to program. I found that, while I'd bought a small,
fit-in-the-briefcase programmer, I needed a sample case full of adapters,
which were both costly and fragile.
Some of the vendors of programmable logic do publish the algorithms for their
ISP programming tools, which you can then implement in your own
hardware/software combination. Unfortunately, I've seen no spec's on how to
develop the configuration of the hardware.
more below ...
Dick
----- Original Message -----
From: "Tony Duell" <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Monday, April 15, 2002 6:23 PM
Subject: Re: TTL computing
> > > Well, 'programming' a PAL (or a PROM) includes both selecting the fuse
> > > you want to blow and then blowing it. IIRC (and it's been a long time
> > > since I looked at this), actually blowing the fuse was _similar_
> > > (although not identical) for both PROMs and PALs. Selecting the desired
> > > fuse was pretty different.
> > >
> > Back in the '70's, one used a Data I/O Model 29 (?) which was very
expensive,
> > and for which the software updates cost quite a bit. There were, however,
>
> That was one problem I had with GALs. I built the Elektor GAL programmer,
> which worked pretty well. That was until the manufacturers changed the
> spec of the GAL slightly, I then had to buy a software update (at least),
> and maybe an add-on board. And then Elektor stopped supporting it, so I
> was stuck with a programmer which could only program devices that were
> next-to-impossible to obtain...
>
> > > But I still don't know of any PAL where you can take the fuse map (on a
> > > computer), transform it if necessary and then upload it to a PROM-only
> > > programmer that you've plugged the PAL into, And expect the PAL to work
> > > at the end of it.
> > >
> > Well, if I had a PROM-only programmer, I'd interpret the designation of
> > PROM-ONLY as meaning it was a waste of time to try to program a PAL with
it.
>
> The whole point is, that before there were PALs, then all programmers
> were PROM (or EPROM) only. But AFAIK no early PALs could be programmed in
> such programmers, you had to buy/build a new one.
>
EPROMS, for some reason, didn't have these limitations. Programming was
simple and the spec's were in many of the databooks.
>
> Let me give you an example where the converse is true, so you can
> understand what I am getting at. The TMS7000 microcontroller. This can be
> programmed as a 2764 EPROM, if you make a pin-swapping adapater. In other
> words, if you wire the right pins on the microcontroller to a 28 pin
> header, you can program it in any EPROM programmer.
>
There were several vendors, including both TI and Mitsubishi, who made parts
that worked that way.
>
> So an EPROM-only programmer will program TMS7000s.
>
I see what you mean. However, most microcontroller makers provided simple
means for you to program their field-programmable parts. Motorola had a
number of devices that, if you applied the right signals at reset, would go
into a bootloader that programmed the internal EPROM from the serial port.
Others required you wire up a programming circuits with a source EPROM that
their circuit downloaded to the internal program store.
>
> >
> > However, the technique of selecting the fuse was the only real difference,
> > electrically between the two device types, and that was described in the
early
> > app-notes. Unfortunately, the 1986 databook I have at my feet is not
early
>
> Learn to read, please. I am not disputing it was documented (I have the
> original MMI PAL databook and it's in there). I am disputing it's the
> same as selected a bit in a normal bipolar PROM.
>
Which book would that be?
>
Does it surprise you that the access mode to the fuse array is different?
It's a totally different device type. The means for "blowing" a fuse is the
same, but the means of addressing the fuses is different, and changes with
different device types. It's hardly worth considering, since you won't find
many bipolar PALs any more. They've been replaced by GALs. Oddly enough,
back in '84-'85, when these devices were new, the programming methods were
documented. Now that there are many more varieties of these parts, the
documentation's disappeared from their databooks.
>
> > Over the years, the makers of these devices have gotten tight-lipped about
the
> > programming algorithms because the home-built devices, even those built by
> > knowledgable engineers, caused them such a service headache. If your
local
>
> I have never understood this...
>
> The process of programming a fuse in a bipolar PROM and in a PAL is much
> the same. Similary the process of programming a flash cell in a
> microcontroller, a flash PROM and a GAL are also much the same as each
> other. And yet most (but not all, agreed) microcontroller, flash PROM and
> EPROM manufacturers do document their programming algorithms, but few, if
> any, of the PLD manufacturers do. Why are PLDs the only devices that
> cause support problems.
>
Believe me, I've got no idea, but that business of "support headaches" comes
up every time I broach the subject with the factory applications guys. They
probably feel they've got to protect their technology. One of the "universal"
programmers I have had a programming language, which I obtained. The purpose
of this thing was to allow one to write programs to implement new algorithms
for new devices. It also allows one to add SSI/MSI and memory devices to the
test library. Unfortunately, about the time I got that software, the mfg's
became really difficult to deal with as far as their device programming
algorithms were concerned. <sigh>
>
> > > Will you please forget the 'serious work'. Will you please accept that
> > > there are people who design and build electronic circuits for fun. This
> > > appears to be an alien concept for you.
>
> > I'll do that when you quit suggesting that the entire industry and its
> > nomenclature are wrong just because it doesn't suit the dabblers in
obsolete
>
> Well, considering your beloved 'industry' can't agree on what these terms
> mean (hint : I've seen manufacturers call something 'microcode' that
> anyone else would call machine code for a microprocessor), I am not sure
> anyone can be that arogant as to what the terms mean.
>
> And to claim that microcode is not a special case of a state machine is
> plain wrong!
>
They'll listen to you when you become part of a market that uses 100K pieces
per week of their various parts. In the meantime, you're just a hobbyist and
not even a customer of theirs. You, and most other hobbyists, get your parts
from the leavings of those guys who buy the 100K pieces per week, and then
surplus out what they don't need. The industry doesn't care, even, that
hobbyists exist. You're a retailer's customer.
>
> > > The current advances in processor speed have come largely from just
> > > increasing the clock rate. There haven't been any major changes in CPU
> > > design to use those clock cylces more efficiently....
> > >
> > That's only a small part of the acceleration. The use of multiple
piplelines
> > accounts for much of the performance increase along with increased
datapath
> > width, and other little features. The gradual increase in interest in
> > parallelism is also going to help quite a bit, so we'll be seeing even
more
> > pipelines in the future.
> > >
> > > But somebody stuck with old, slow, TTL, just might hit on some way to
get
> > > more performance out of it (because it's all they've got, and they need
> > > the performnce). The trick they discover just might also be useful to
> > > speed up ASICs (or FPGAs, or ...)
> > >
> > And just exactly HOW would they extract more performance from it? A new
>
> I've read some moronic statements on this list, but this is one of the
> best (or worst)!
>
> Are you incapable of believing that the multiple pipelines you just
> mentioned could not have been built in TTL. Of course they could. OK,
> they'd not be as fast as an FPGA or ASIC implementation, but so what.
> They would be faster than a traditional processor built in TTL. And that
> would be enough to prove that the design worked, and that this was a way
> of speeding up other processors.
>
They WERE built in TTL, back when TTL was the relevant technology and they had
no better options. Even back then, it was more sensible to simulate the new
architecture to see whether it really offered the enhancement it seemed to
offer. If that worked out, hardware was built. Today, that hardware is built
in a programmable hardware scheme of one sort or another.
>
> > architecture would require new software, both in development tools and in
OS
> > and as applications. Just verifying that their innovation would take
several
> > hundred lifetimes, and the generation of a full set of software would take
> > that one individual working alone, until well after the next big-bang.
>
> Never underestimate what hobbyists can do. FWIW, plenty of hobbyists have
> designed their own processors and produced at least a monitor program for
> them. And it doesn't take that long.
>
So what? Every EE student has had to do that in order to get his sheepskin.
It's part of a required course. Building his own processor and coming up with
something useful are quite different.
>
> > > That's a lot of 'maybes', sure. And I don't think it's likely. But I
also
> > > don't think it's impossible...
> > >
> > It's highly unlikely, simply because it's WAY too much work to twiddle the
> > hard-wiring and WAY too slow to use TTL, and uses WAY too much power so
folks
>
> As I mentioned above (although you seem to be incapable of seeing it),
> the actual speed doesn't matter. Just that it shows a significant speedup
> over another architecture built with the same technology.
>
>
> Also the power consumption is hardly a problem either. My old 11/45 has a
> 250W PSU for the CPU boards (only). Many PC power supplies can now exceed
> that. 2 or 3 PSUs taken from old PCs will power any TTL-based processor
> you're likely to build.
>
a 9-volt battery is probably capable of powering any CPU I'd be likely to
build.
>
> > doing serious development, even at the amateur level, use simulators to
>
> I will use a simulator when somebody makes one that I can trust. Meaning
> that it passes all of my little test circuits. Since that's not happened
> yet, I don't feel I can trust the results of the simulator.
>
Well, the industry has relied on them since back when I was in college. If
you don't trust someone else's work, proven over two or three decades of
constant use by hundreds of thousands of engineers, write one that's better.
>
> Even then, there's no reason to believe the traces from the simulator
> have any relation to reality unless you've actually verified them against
> a logic analyser.
>
So do that! I do it from time to time.
>
> > evaluate performance of new architectures, and programmable hardware to
verify
> > their findings.
>
> Some do, others don't. Period.
>
> > >
> > That's not to say a person's WRONG in fiddling with discrete logic. It's
just
>
> Well, I'm glad I'm not 'wrong' in your eyes. That would have really
> worried me -- NOT!
>
> Incidentally, a board I am designing at the moment contains a
> microcontroller, an 8 bit latch, a 3 to 8 decoder (for which a '138 is
> _perfect_ with just the right enables), a 2 input AND, a 2 input NAND and
> an inverter. Will you please tell me why a PLD is superior to a single
> 74x00 for those last 3 gates?
>
It probably isn't, but you could, of course, reduce the entire combinatorial
circuit to a small PLD, but I don't know the details.
>
> > not terribly likely to be of much use. Like masturbation, it's unlikely
to
> > hurt anyone and produces momentary amusement.
>
> It (TTL design) has kept me amused most of my life...
>
> > > And that's _exactly_ what building TTL circuits is for some of us. Now
> > > will you please try to understand this!
> > >
> > I've got no problem with that. I do, however, disagree that the industry
> > nomenclature is misapplied because it COULD or even SHOULD have been used
> > differently.
>
> As I said above, even the industry can't agree on what some of these
> terms mean...
>
> HP refer to the machine code for the NUT processor in the HP41 as
> 'microcode' sometimes. In a sense it is, on the ground that the NUT +
> this machine code forms an emulated processor that runs HP41 bytecodes.
> But it's somewhat streching the definition.
>
> The PERQ hard disk controller (and ethernet interface for that matter)
> consists of a 2910 sequencing a PROM (I think it's 24 bits wide, but I
> doesn't really matter). The outputs of that PROM control various bits of
> the data path for the disk controller (or ethernet interface). The
> bitpatterns in that PROM are called 'microcode' in some documentation and
> 'state machine' in other documentation. Which is correct? (IMHO both!).
>
Microcode was a term cooked up to distinguish between the code executed by the
"micrologic" as it emulated the target system. It was a term essential to the
concept on which some computers were built. A small, very fast, by comparison
with the target, computer executes a program that implements the target
architecture. Certainly not a ridiculous construct. This gave rise to
questions about how one might implement a fast processor to execute the target
task without a full implementatation of a target architecture separate from
the microengine. Voila! ... now you have the RISC.
>
> DEC used to use the term 'microprocessor' to mean any simple processor
> (often built from TTL, and very specialised in purpose, like a comms
> controller) that ran microcode. This one I think is plain wrong, but...
>
Nomenclature is dated. Before the widespread acceptance of monolithic
microprocessors, those made from microelectronics, TTL, for example were
referred to in some environments, not just DEC, as microprocessors. If you
had what was essentially a computer, CPU, ROM, RAM, etc, implementing a CPU,
you had to have a term, microcode, for the code it executed. You had to have
a well-defined language for such a beast, and software to manipulate it. The
product of that software was the microcode. If you used AMD's tools, (AMDASM)
you certainly had a development system you could use, if you chose to do so,
and that gave you a means for producing microcode for your system. Of course,
it was just the code used to implement the CPU you designed, and you had to
produce tools for your target architecture yourself.
Received on Tue Apr 16 2002 - 08:52:30 BST