30 Oct
2001
30 Oct
'01
3:13 p.m.
What's unfortunate, at least from where I sit, is
that though some sources give
you a schematic or an HDL of a CPU, yet they don't tell you WHY the choices made
in its design were made. Normally such decisions are normally driven by
requirements, be it for performance, or for specific addressing modes, chip
size, or whatever. It seems we never see light shed on such matters.
Sometimes you can find this information on the web. Now that many of the
older computers
are of historical value people are writing things down.
One caution is certainly warranted, however. Fully
synchronous design became
the default method of designing circuits of anysubstance in the mid-late '80's.
One result, of course, was that signal races were easily avoided, and, with the
use of pipelining, it allowed for the acceleration of some processes at the cost
of increased latency. The use of fully sunchronous design drove up CPU cost,
however, and was not an automatically assumed strategy in the early '70's, so
you've got to consider WHEN a design was specified before making any assumptions
about why things were done in a given way.
I thought that that was due more to the fact (core) memory was
asynchronous with a wide
range of cycle times as well as I/O transfers. Only with memory being in
the same box as
the cpu does a more synchronous system make sense.
Classic CPU's were mostly NOT fully synchronous, as
fully synchronous design
required the use of costlier faster logic families throughout a design when that
wasn't necessarily warranted. Today's FPGA and CPLD devices, when used to host
a classic CPU design, eliminate the justifications for asynchronous design
strategies that were popular in the early '70's - late '80's. Their use
essentially requires the design be synchronous, not only because signal
distribution/routing resources are limited, but because propagation delays are
so different from wht they were in the original discrete version.
What is so different a F/F is still a F/F, a gate is still a gate. It is
only that
routing delays are a unknown so you can't use logic that requires timing
delays or
or oneshots. It is only that the programs can't discover when logic can
or cannot change
like a designer can but must use worse case assumptions .It is only in
the case when you
have a single clock that timing calculations are the most accurate.
How ever I suspect most CPU design starts with a clean sheet of paper
lays out goals and basic
design parameters. A good block diagram often can tell you how complex
your system is.
While gates are important the quantify and packaging of the gates define
just how your system
can be laid out. Only after the instruction set is defined do you look
at the logic need
to produce the Computer System, and once you lay things out you have
good idea of
what instructions are needed. Of course everything gets revised again
and again.
http://www.ulib.org/webRoot/Books/Saving_Bell_Books for some interesting
reading.
Also "CMOS circuit design,layout and simulation" ISBN 0-7803-3416-7 is
very good reading for
CPU design at the real gate level.
Ben Franchuk.
--
Standard Disclaimer : 97% speculation 2% bad grammar 1% facts.
"Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk
Now with schematics.
30 Oct
30 Oct
6:31 p.m.
Well, there's a wide gap between core memory, and the designs of the era (pre
'72) when it was common, and the '80's when fully synchronous design became
the
order of the day.
Another thing to keep in mind is that most CPU's of yesteryear are not
integrated circuits, but, rather, board(s) full of the them. I remember looking
at a 16-bit CPU from some Florida company that was being customed up by my then
local circuit house and it occupied a 22x32" panel (very large for the time) of
5-layer circuit board, all in STTL. The outer layers were intended not so much
for containing the RFI as for dissipating the heat, to wit, the entire long
outer edges of the board was mounted to a 3-1/2" square heatsink that drew heat
To: <classiccmp(a)classiccmp.org
Sent: Tuesday, October 30, 2001 10:13 PM
Subject: Re: CPU design at the gate level
'80's.
that
Not all CPU chips of yesteryear were even built with clocked logic. If you look
at the ones with a single clock cycle for a single bus cycle, e.g. 6800, et. al,
you'll find that the clock was a useable as a steering member and a timing
reference, but not necessarily a clock to a set of registers. I'd say FlipFlops
of the R/S and transparent latch sort were much more common than those used for
counting. In fact, I recently revisited the 650x core recently and found that
it could and probably should be built with no clocked flipflops at all, using
the ALU to increment the PC and stack pointer as well as operating on the data
registers. That's what reduced the poundage of silicon in the 650x series
chips, which, aside from their very elegant instruction set, is what bought them
their market share.
What's different is that the style of design
that was used back when the
classics were being worked out was so different from what's done today. Back
then, fully synchronous design meant that all the devices used were of the same
technology and that meant cost impacts whenever fully sunchronous rather than
locally asynchronous, globally syncrhonized structure was used, since that meant
that a nand gate had to have two dual-rank registered inputs and a registered
ouput. Which immediately raised the cost of that 30-cent gate to $4.80. Back
then arrays were a sea of gates, and things changed depending on which gate of
the 4000-6000 identical nands in the array you were using. Today, a small array
consists of a putative 100K gates, of which one's lucky to be able to get the
equivalent of 10K gates in actual practice. Of course they count a 3-input gate
as two gates and a 4-input gate as three, and a D-flop as over a dozen, rather
than the 6 it should really use. Then there's that LUT, which , to the
marketing department represents a lot of logic, even though you have to use the
whole thing just to make a single 5-input AND. Consider how much of the
marketing departments resources you consume with what would have been a 74S133.
> How ever I suspect most CPU design starts
with a clean sheet of paper
> lays out goals and basic
> design parameters. A good block diagram often can tell you how complex
> your system is.
> While gates are important the quantify and packaging of the gates define
> just how your system
> can be laid out. Only after the instruction set is defined do you look
> at the logic need
> to produce the Computer System, and once you lay things out you have
> good idea of
> what instructions are needed. Of course everything gets revised again
> and again.
Well, if you put pencil to paper before the
instruction set is defined, and
before the requirements are firmly defined, you're wasting time, and, sadly, I
doubt that many CPU designs start on a clean sheet of paper these days. They
certainly didn't back in the "old days." There's always the political
baggage.
>
http://www.ulib.org/webRoot/Books/Saving_Bell_Books for some
> interesting reading.
> Also "CMOS circuit design,layout and simulation" ISBN 0-7803-3416-7 is
> very good reading for CPU design at the real gate level.
> Ben Franchuk.
> --
> Standard Disclaimer : 97% speculation 2% bad grammar 1% facts.
> "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk
> Now with schematics.
from the board and had fans attached specially provided
to manage this board's
dissipation requirement. It was quite a thing to
behold!
see additional remarks below, plz.
Dick
----- Original Message -----
From: "Ben Franchuk" <bfranchuk(a)jetnet.ab.ca >What's unfortunate, at least from where I sit,
is that though some sources
give
>you a schematic or an HDL of a CPU, yet they
don't tell you WHY the choices
made
in its design
were made. Normally such decisions are normally driven by
requirements, be it for performance, or for specific addressing modes, chip
size, or whatever. It seems we never see light shed on such matters.
Sometimes you can find this information on the web. Now that many of the
older computers are of historical value people are writing things down.
>One caution is certainly warranted, however. Fully synchronous design became
>the default method of designing circuits of anysubstance in the mid-late
>One result, of course, was that signal races were
easily avoided, and, with
the
>use of pipelining, it allowed for the acceleration
of some processes at the
cost
>of increased latency. The use of fully
sunchronous design drove up CPU cost,
>however, and was not an automatically assumed strategy in the early '70's,
so
>you've got to consider WHEN a design was specified before making any
assumptions
about why
things were done in a given way.
I thought that that was due more to the fact (core) memory was
asynchronous with a wide
range of cycle times as well as I/O transfers. Only with memory being in
the same box as
the cpu does a more synchronous system make sense.
>Classic CPU's were mostly NOT fully synchronous, as fully synchronous design
>required the use of costlier faster logic families throughout a design when
>wasn't necessarily warranted. Today's
FPGA and CPLD devices, when used to
host
>a classic CPU design, eliminate the justifications
for asynchronous design
>strategies that were popular in the early '70's - late '80's. Their
use
>essentially requires the design be synchronous, not only because signal
>distribution/routing resources are limited, but because propagation delays
are
so different
from what they were in the original discrete version.
What is so different a F/F is still a F/F, a gate is still a gate. It is
only that
routing delays are a unknown so you can't use logic that requires timing
delays or
or oneshots. It is only that the programs can't discover when logic can
or cannot change
like a designer can but must use worse case assumptions .It is only in
the case when you
have a single clock that timing calculations are the most accurate.
31 Oct
31 Oct
1:37 a.m.
Richard Erlacher wrote:
Another thing to keep in mind is that most CPU's
of yesteryear are not
integrated circuits, but, rather, board(s) full of the them. I remember looking
at a 16-bit CPU from some Florida company that was being customed up by my then
local circuit house and it occupied a 22x32" panel (very large for the time) of
5-layer circuit board, all in STTL. The outer layers were intended not so much
for containing the RFI as for dissipating the heat, to wit, the entire long
outer edges of the board was mounted to a 3-1/2" square heatsink that drew heat
from the board and had fans attached specially provided to manage this board's
dissipation requirement. It was quite a thing to behold!
see additional remarks below, plz.
Dick
----- Original Message -----
From: "Ben Franchuk" <bfranchuk(a)jetnet.ab.ca>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, October 30, 2001 10:13 PM
Subject: Re: CPU design at the gate level
'80's.
that
Not all CPU chips of yesteryear were even built with clocked logic. If you look
at the ones with a single clock cycle for a single bus cycle, e.g. 6800, et. al,
you'll find that the clock was a useable as a steering member and a timing
reference, but not necessarily a clock to a set of registers. I'd say FlipFlops
of the R/S and transparent latch sort were much more common than those used for
counting. In fact, I recently revisited the 650x core recently and found that
it could and probably should be built with no clocked flipflops at all, using
the ALU to increment the PC and stack pointer as well as operating on the data
registers. That's what reduced the poundage of silicon in the 650x series
chips, which, aside from their very elegant instruction set, is what bought them
their market share.
What's different is that the style of
design that was used back when the
classics were being worked out was so different from what's done today. Back
then, fully synchronous design meant that all the devices used were of the same
technology and that meant cost impacts whenever fully sunchronous rather than
locally asynchronous, globally syncrhonized structure was used, since that meant
that a nand gate had to have two dual-rank registered inputs and a registered
ouput. Which immediately raised the cost of that 30-cent gate to $4.80. Back
then arrays were a sea of gates, and things changed depending on which gate of
the 4000-6000 identical nands in the array you were using. Today, a small array
consists of a putative 100K gates, of which one's lucky to be able to get the
equivalent of 10K gates in actual practice. Of course they count a 3-input gate
as two gates and a 4-input gate as three, and a D-flop as over a dozen, rather
than the 6 it should really use. Then there's that LUT, which , to the
marketing department represents a lot of logic, even though you have to use the
whole thing just to make a single 5-input AND. Consider how much of the
marketing departments resources you consume with what would have been a 74S133.
> How ever I suspect most CPU design
starts with a clean sheet of paper
> lays out goals and basic
> design parameters. A good block diagram often can tell you how complex
> your system is.
> While gates are important the quantify and packaging of the gates define
> just how your system
> can be laid out. Only after the instruction set is defined do you look
> at the logic need
> to produce the Computer System, and once you lay things out you have
> good idea of
> what instructions are needed. Of course everything gets revised again
> and again.
Well, if you put pencil to paper before
the instruction set is defined, and
before the requirements are firmly defined, you're wasting time, and, sadly, I
doubt that many CPU designs start on a clean sheet of paper these days. They
certainly didn't back in the "old days." There's always the political
baggage.
>
http://www.ulib.org/webRoot/Books/Saving_Bell_Books for some
> interesting reading.
> Also "CMOS circuit design,layout and simulation" ISBN 0-7803-3416-7 is
> very good reading for CPU design at the real gate level.
> Ben Franchuk.
> --
> Standard Disclaimer : 97% speculation 2% bad grammar 1% facts.
> "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk
> Now with schematics.
>
--
Standard Disclaimer : 97% speculation 2% bad grammar 1% facts.
"Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk
Now with schematics.
>What's unfortunate, at least from where I
sit, is that though some sources
give
>you a schematic or an HDL of a CPU, yet they
don't tell you WHY the choices
made
in its
design were made. Normally such decisions are normally driven by
requirements, be it for performance, or for specific addressing modes, chip
size, or whatever. It seems we never see light shed on such matters.
Sometimes you can find this information on the web. Now that many of the
older computers are of historical value people are writing things down.
>One caution is certainly warranted, however. Fully synchronous design became
>the default method of designing circuits of anysubstance in the mid-late >One result, of course, was that signal races
were easily avoided, and, with
the
>use of pipelining, it allowed for the
acceleration of some processes at the
cost
>of increased latency. The use of fully
sunchronous design drove up CPU cost,
>however, and was not an automatically assumed strategy in the early '70's,
so
>you've got to consider WHEN a design was specified before making any
assumptions
about why
things were done in a given way.
I thought that that was due more to the fact (core) memory was
asynchronous with a wide
range of cycle times as well as I/O transfers. Only with memory being in
the same box as
the cpu does a more synchronous system make sense.
>Classic CPU's were mostly NOT fully synchronous, as fully synchronous design
>required the use of costlier faster logic families throughout a design when >wasn't necessarily warranted.
Today's FPGA and CPLD devices, when used to
host
>a classic CPU design, eliminate the
justifications for asynchronous design
>strategies that were popular in the early '70's - late '80's. Their
use
>essentially requires the design be synchronous, not only because signal
>distribution/routing resources are limited, but because propagation delays
are
so
different from what they were in the original discrete version.
What is so different a F/F is still a F/F, a gate is still a gate. It is
only that
routing delays are a unknown so you can't use logic that requires timing
delays or
or oneshots. It is only that the programs can't discover when logic can
or cannot change
like a designer can but must use worse case assumptions .It is only in
the case when you
have a single clock that timing calculations are the most accurate.
2:15 a.m.
Richard Erlacher wrote:
What's different is that the style of design that was used back when the
classics were being worked out was so different from what's done today. Back
then, fully synchronous design meant that all the devices used were of the same
technology and that meant cost impacts whenever fully sunchronous rather than
locally asynchronous, globally syncrhonized structure was used, since that meant
that a nand gate had to have two dual-rank registered inputs and a registered
ouput. Which immediately raised the cost of that 30-cent gate to $4.80. Back
then arrays were a sea of gates, and things changed depending on which gate of
the 4000-6000 identical nands in the array you were using.
Never used the stuff. Since they don't make TTL any more I kind was
forced into using
FPGA's. :). Also a FPGA prototype board is cheaper than 150 new TTL.
Mind you now
that I got the FPGA working TTL looks better since I don't have to burn
PROMS.
Of course the problem that 74LS382's and 16x4 non-inverting ram don't
exist today
does make life difficult.
Well, there's a wide gap between core memory, and the designs of the era (pre
'72) when it was common, and the '80's when fully synchronous design became
the
order of the day.
Another thing to keep in mind is that most CPU's of yesteryear are not
integrated circuits, but, rather, board(s) full of the them. I remember looking
at a 16-bit CPU from some Florida company that was being customed up by my then
local circuit house and it occupied a 22x32" panel (very large for the time) of
5-layer circuit board, all in STTL. The outer layers were intended not so much
for containing the RFI as for dissipating the heat, to wit, the entire long
outer edges of the board was mounted to a 3-1/2" square heatsink that drew heat
from the board and had fans attached specially provided to manage this board's
dissipation requirement. It was quite a thing to behold!
And POWER was cheap.
<snip>
Not all CPU chips of yesteryear were even built with
clocked logic. If you look
at the ones with a single clock cycle for a single bus cycle, e.g. 6800, et. al,
you'll find that the clock was a useable as a steering member and a timing
reference, but not necessarily a clock to a set of registers. I'd say FlipFlops
of the R/S and transparent latch sort were much more common than those used for
counting. In fact, I recently revisited the 650x core recently and found that
it could and probably should be built with no clocked flipflops at all, using
the ALU to increment the PC and stack pointer as well as operating on the data
registers. That's what reduced the poundage of silicon in the 650x series
chips, which, aside from their very elegant instruction set, is what bought them
their market share.
Playing around with a TTL style cpu design in a FPGA I found I needed
lots of clock
enables but had I used real TTL I would of just generated the 4 or 5
clocks needed.
Like you said using latches saves about 1/2 the gates needed of a
Flip/Flop and
that saves a good bit. The 6800/6502 memory interface is nice. That is
the style I am
using on my FPGA.
Today, a small array
consists of a putative 100K gates, of which one's lucky to be able to get the
equivalent of 10K gates in actual practice. Of course they count a 3-input gate
as two gates and a 4-input gate as three, and a D-flop as over a dozen, rather
than the 6 it should really use. Then there's that LUT, which , to the
marketing department represents a lot of logic, even though you have to use the
whole thing just to make a single 5-input AND. Consider how much of the
marketing departments resources you consume with what would have been a 74S133.
100K gates Ha! LUT's tend to be really wasteful of multiplexes. A 4-1
multiplexer is
3 logic cells. Mind with the stupid marketing works you can't get the
small
and easy to work with FPGA's cheap but you are expected to buy the large
and
painful chips for $$$. All of my FPGA work is a hobby so I have to stick
to 84
PLCC packages that nobody wants to sell. I like anti-fuse FPGA's idea of
you power up
and go. Reminds me of TTL :).
Well, if you put pencil to paper before the
instruction set is defined, and
before the requirements are firmly defined, you're wasting time, and, sadly, I
doubt that many CPU designs start on a clean sheet of paper these days. They
certainly didn't back in the "old days." There's always the political
baggage.
That is true there is baggage.My two gripes today are
1) No bootstrapping a minimal system in hardware & software - you need
everything to run.
2) Non serviceable equipment and docs.
Ben Franchuk.
--
Standard Disclaimer : 97% speculation 2% bad grammar 1% facts.
"Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk
Now with schematics.
2:55 a.m.
At 08:15 AM 10/31/01, Ben wrote:
That is true there is baggage.My two gripes today are
1) No bootstrapping a minimal system in hardware & software - you need
everything to run.
Take a page from Classic computers as I did and put a dedicated "console
processor" on the front of your FPGA. I've got a board for doing a
"soft"
robot CPU that I hope to get to after BattleBots that has a PIC chip (small
single chip MCU) as the console processor. It loads the main CPU from
either serial EEPROM or from a serial line into the FPGA on power up,
sequences the power, and provides the diagnostic interface when things go
strangely.
2) Non serviceable equipment and docs.
This is truly a pain.
--Chuck
4:39 a.m.
Chuck McManis wrote:
At 08:15 AM 10/31/01, Ben wrote:
Classic Computers??? From where? I am still grumbling that I could not
get
front panel interface on my fpga. I refuse to have a CPU to boot my CPU.
(Note hidden cpu's in HD's count too.) I want to hit reset and have the
CPU load from bootstrap device regardless of main memory. This is the
way I
have the FPGA set up, boot strap from the serial port.In fact if I had a
PROM bootstrap I would have not worked with my system as wire was broke
in the
middle between the FPGA and memory, and took forever to debug as a data
bit would float.
That is true there is baggage.My two gripes today
are
1) No bootstrapping a minimal system in hardware & software - you need
everything to run.
Take a page from Classic computers as I did and put a dedicated "console
processor" on the front of your FPGA. I've got a board for doing a "soft"
robot CPU that I hope to get to after BattleBots that has a PIC chip (small
single chip MCU) as the console processor. It loads the main CPU from
either serial EEPROM or from a serial line into the FPGA on power up,
sequences the power, and provides the diagnostic interface when things go
strangely.
Why use a eprom and counter when you can use 50 million transistors.:)
Only after the fpga works 100% will I burn a prom, as the PC --> FPGA is
good way to test the system.
Ben Franchuk.
BTW the prom for the FPGA is 512k bits or 64KB. I have a whopping 32K of
memory and will use 8k for a OS leaving 24k for programs. Some how a
FPGA config prom bigger than my basic system hints how big is normal
for everything.
--
Standard Disclaimer : 97% speculation 2% bad grammar 1% facts.
"Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk
Now with schematics.
5:12 a.m.
At 10:39 AM 10/31/01, Ben wrote:
The VAX series has had PDP-11 front ends that load microcode, run
diagnostics, power cycle the system and boot the operating system. The
D-series of machines from Xerox had microcode that was loaded from floppy,
the IBM 360 machines did an initial microprogram load from floppy, the DEC
10 series had a PDP-11/40 as its console server, there are others. Its a
tried and true technology.
In my case I actually needed the ability to add op-codes and peripherals on
the fly so I don't use PROM. In the mean time I down load new EEPROM
configs on the fly and reset and go, easy to debug and can be shipped as
final hardware as well.
Take a page
from Classic computers as I did and put a dedicated "console
processor" on the front of your FPGA.
Classic Computers??? From where? I am still grumbling that I could not get
front panel interface on my fpga.
This question doesn't make sense, if you want a front panel design it in,
if you're talking about actually manipulating the bits in the FPGA then use
another FPGA to make a JTAG front panel.
I refuse to have a CPU to boot my CPU.
(Note hidden cpu's in HD's count too.) I want to hit reset and have the
CPU load from bootstrap device regardless of main memory. This is the
way I
have the FPGA set up, boot strap from the serial port.
Perhaps we're quibbling semantics. The role of the PIC in my design is as a
serial port, and it has the ability to program serial EEPROMs so I don't
need a special cable to reload the FPGA data, I just power cycle with a
jumper set.
In fact if I had a
PROM bootstrap I would have not worked with my system as wire was broke
in the
middle between the FPGA and memory, and took forever to debug as a data
bit would float.
I guess you lost me here. You're saying that the FPGA configuration PROM
was disconnected from the FPGA and that was hard to debug and so having an
8 pin PIC chip on board to run diagnostics for you in this sort of case is
worthless and antithetical to your design goals?
I've got a
board for doing a "soft"
robot CPU that I hope to get to after BattleBots that has a PIC chip (small
single chip MCU) as the console processor. It loads the main CPU from
either serial EEPROM or from a serial line into the FPGA on power up,
sequences the power, and provides the diagnostic interface when things go
strangely.
Why use a eprom and counter when you can use 50 million transistors.:)
Only after the fpga works 100% will I burn a prom, as the PC --> FPGA is
good way to test the system. BTW the prom for the FPGA is 512k bits or 64KB. I have
a whopping 32K of
memory and will use 8k for a OS leaving 24k for programs. Some how a
FPGA config prom bigger than my basic system hints how big is normal
for everything.
How is this any different than a PDP-11 where the microcode store might
have more bits than main memory? Its one 8 pin part to hold the
configuration information and one 8 pin part to control it.
--Chuck
6:30 a.m.
Chuck McManis wrote:
The VAX series has had PDP-11 front ends that load
microcode, run
diagnostics, power cycle the system and boot the operating system. The
D-series of machines from Xerox had microcode that was loaded from floppy,
the IBM 360 machines did an initial microprogram load from floppy, the DEC
10 series had a PDP-11/40 as its console server, there are others. Its a
tried and true technology.
I knew most of that, I thought you had a specific web page you got your
material
from
This question doesn't make sense, if you want a
front panel design it in,
if you're talking about actually manipulating the bits in the FPGA then use
another FPGA to make a JTAG front panel.
I was referring to the CPU design and Instruction Set. A hard reset
causes a
bootstrap program to read in off the serial port. I configure the FPGA
from a
host PC. The cpu is a 12/24 bit design.
Bootstrap format:
oooo, octal data
oooooooo] octal address load
oooooooo\ octal program start
<cr><lf> leader/white space
Perhaps we're quibbling semantics. The role of the
PIC in my design is as a
serial port, and it has the ability to program serial EEPROMs so I don't
need a special cable to reload the FPGA data, I just power cycle with a
jumper set.
A handy feature.
I guess you lost me here. You're saying that the
FPGA configuration PROM
was disconnected from the FPGA and that was hard to debug and so having an
8 pin PIC chip on board to run diagnostics for you in this sort of case is
worthless and antithetical to your design goals?
You still have to program the PIC. The fault was with the general memory
bus,
not the FPGA configuration.
In my case I actually needed the ability to add op-codes and
peripherals on
the fly so I don't use PROM. In the mean time I
down load new EEPROM
configs on the fly and reset and go, easy to debug and can be shipped as
final hardware as well.
Fancy stuff there.
How is this any different than a PDP-11 where the
microcode store might
have more bits than main memory? Its one 8 pin part to hold the
configuration information and one 8 pin part to control it.
I used a PDP-8/e and a PDP-S all in one BOX computers. :)
It is hard to get use to several meg of bits in a 8 bit package when you
still
remember using core memory.
Ben Franchuk.
--
Standard Disclaimer : 97% speculation 2% bad grammar 1% facts.
"Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk
Now with schematics.
7:49 a.m.
At 12:30 PM 10/31/01, Ben wrote:
I used a PDP-8/e and a PDP-S all in one BOX computers.
:)
It is hard to get use to several meg of bits in a 8 bit package when you
still remember using core memory.
However the bits in the FPGA simply represent wires in the PDP-8 and where
you had a couple million millimeters of wire in a PDP-8 system you have
less than 100 mm of wire in an FPGA system.
Don't confuse the configuration bits with actual memory, they are routing
resources, and there were just as many in the PDP-8, only the ones on the
PDP-8 are etched into circuit boards. That doesn't mean they didn't exist
however in the form of drawings on Gordon Bell's and others tables.
DTL -> TTL -> LSI -> FPGA, the gates are the same, just the wires got
smaller and the way one manipulates them changed.
(wire wrap -> copper traces -> silicon traces -> data bits)
--Chuck
8:37 a.m.
Chuck said:
DTL -> TTL -> LSI -> FPGA
Sure I'm familliar with the concept, but only from
an overview standpoint. Just what is it with DTL vs
TTL anyway? Why didn't they use TTL from the
start? Was it a eureka genius thing or did it take
advanced transistors to make it possible?
A quick answer would suffice, we got too much
bandwith as it is.
John A (software guy)
This question for me dates back to the early 80's
8:59 a.m.
Simple circuits in DTL were cheap and easy to manufacture. As the speed and
density went up, the cost went up, but not so much with TTL as with DTL.
Apparently there were lots of reasons for this, but I never had much interest in
DTL, so I have to plead ignorance. My early TTL databooks are dated in the
early '70's, and DTL came before then.
Dick
----- Original Message -----
From: "John Allain" <allain(a)panix.com>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, October 31, 2001 3:37 PM
Subject: Re: CPU design at the gate level
Chuck said:
DTL -> TTL -> LSI -> FPGA
Sure I'm familliar with the concept, but only from
an overview standpoint. Just what is it with DTL vs
TTL anyway? Why didn't they use TTL from the
start? Was it a eureka genius thing or did it take
advanced transistors to make it possible?
A quick answer would suffice, we got too much
bandwith as it is.
John A (software guy)
This question for me dates back to the early 80's
9:13 a.m.
On Wed, 31 Oct 2001, John Allain wrote:
Chuck said:
> DTL -> TTL -> LSI -> FPGA
Hey where's RTL? 914's, 923's etc etc
Sure I'm familliar with the concept, but only from
an overview standpoint. Just what is it with DTL vs
TTL anyway? Why didn't they use TTL from the
start? Was it a eureka genius thing or did it take
advanced transistors to make it possible?
A quick answer would suffice, we got too much
bandwith as it is.
I suspect TTL was harder to fabricate
There was non-integrated RTL and DTL logic before ICs not sure about non
integrated TTL...
John A (software guy)
This question for me dates back to the early 80's
Peter Wallace
10:40 a.m.
"Peter C. Wallace" <pcw(a)mesanet.com>om>:
There was non-integrated RTL and DTL logic before ICs
not sure about non
integrated TTL...
I don't think non-integrated TTL is even possible using
standard parts. It relies on multiple-emitter transistors,
and I've never heard of anyone making those available
discretely.
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
greg(a)cosc.canterbury.ac.nz +--------------------------------------+
8:34 a.m.
see below, plz.
Dick
----- Original Message -----
From: "Chuck McManis" <cmcmanis(a)mcmanis.com>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, October 31, 2001 9:55 AM
Subject: Re: CPU design at the gate level
That's because there's nothing to service and nobody to do it. Forget the
doc's. Today's engineering grad's know just which buttons to push, but
can't
read and write. It's a skill set that died over the past generation. When was
the last time you got a manual that told you anything with a piece of hardware?
At 08:15 AM 10/31/01, Ben wrote:
This is too technical an approach, even for today's engineers. People want
the
"thing" to run when they put in the batteries.
That is true there is baggage.My two gripes today
are
1) No bootstrapping a minimal system in hardware & software - you need
everything to run.
Take a page from Classic computers as I did and put a dedicated "console
processor" on the front of your FPGA. I've got a board for doing a
"soft"
robot CPU that I hope to get to after BattleBots that has a PIC chip (small
single chip MCU) as the console processor. It loads the main CPU from
either serial EEPROM or from a serial line into the FPGA on power up,
sequences the power, and provides the diagnostic interface when things go
strangely.
2) Non serviceable equipment and docs.
This is truly a pain.
--Chuck
2 Nov
2 Nov
6:37 a.m.
Ben Franchuk skrev:
Never used the stuff. Since they don't make TTL any
more I kind was
forced into using FPGA's. :).
What? My local electronics shop owner tells me that it isn't as high-profile
nowadays, but it's quite possible to buy 74 series circuits in any good
electronics shop, right?
--
En ligne avec Thor 2.6a.
Anv?nd g?rna mitt staket, fast du beh?ver nog fr?scha upp det lite.
Lupin III, Lupin den otrolige (Lupin III vs. fukusei ningen), TMS 1978
7:45 a.m.
Iggy Drougge wrote:
What? My local electronics shop owner tells me that it
isn't as high-profile
nowadays, but it's quite possible to buy 74 series circuits in any good
electronics shop, right?
74x00's are still common - I still can get that at Radio-shack for $2.00
in a bubble
package here in Canada. It is rare chips ALU's, carry look aheads, 16x4
memory
that you can't find. The $.10 surplus TTL days are long gone. Ben
Franchuk.
--
Standard Disclaimer : 97% speculation 2% bad grammar 1% facts.
"Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk
8:33 a.m.
While it's true that TTL and work-alike CMOS is found everywhere, if you go with
a parts list, you'll find you're unable to get a substantial range of parts
these days. You may be able to find the parts eventually, but the investment in
shipping is prohibitive.
Unfortunately for the builders of "one-of's," like me (spelled one-off's
in some
places, for reasons I don't understand), the programmable logic comes in
packages that are really inconvenient for that purpose. Nowadays, you're
required to use a 1000+ pin BGA package to get the quantity of logic that you'd
like in a 44-pin PLCC. If you're really lucky with the fit, the device will
allow you to use 10% of the gate count the marketing guys said you're paying
for. The result is that you have to use a PGA package that lists for over $1k
per part, or build an adapter board for the cheaper TQFP part, with a total
cost, when you're done, of over $1k per each anyway, and then, to make matters
worse, only one in 7 of these adapter boards will turn out to be properly
soldered, so you waste 6 FPGA's costing $300 each. That's why product
development that once required a cash outlay of $500 now costs $500 million.
Dick
----- Original Message -----
From: "Iggy Drougge" <optimus(a)canit.se>
To: "Ben Franchuk" <classiccmp(a)classiccmp.org>
Sent: Friday, November 02, 2001 1:37 PM
Subject: Re: CPU design at the gate level
Ben Franchuk skrev:
Never used the stuff. Since they don't make
TTL any more I kind was
forced into using FPGA's. :).
What? My local electronics shop owner tells me that it isn't as high-profile
nowadays, but it's quite possible to buy 74 series circuits in any good
electronics shop, right?
--
En ligne avec Thor 2.6a.
Anv?nd g?rna mitt staket, fast du beh?ver nog fr?scha upp det lite.
Lupin III, Lupin den otrolige (Lupin III vs. fukusei ningen), TMS 1978
9:22 a.m.
New subject: One-off vs. One-of (was Re: CPU design at the gate level)
--- Richard Erlacher <edick(a)idcomm.com> wrote:
Unfortunately for the builders of
"one-of's," like me (spelled one-off's
in some places, for reasons I don't understand)...
It's not just spelled "one-off", it's pronounced "one-off" -
as in
"Wan Awf", not "Wan Ov". It's an engineer's term for a
prototype.
I think you are interpreting it as short for "one of a kind" which I
don't think it is exactly an abbreviation for. It might be short for
"run one off the assembly line and stop", though.
Not sure of the history, but it really is "one-off". I first heard the
term used 17 years ago, not that _it_ was new to the industry, but _I_
was new, then.
-ethan
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
1:12 p.m.
New subject: One-off vs. One-of (was Re: CPU design at the gate level)
Well, that's interesting for sure. Having been in engineering since 1963, I
have to say I've heard the term "one-of" countless times, since that's
been the
main thrust of my work since that time, and it is short for one-of-a-kind, while
I started running into the term "one-off" only in the past decade, and, in
fact,
have never actually heard it used, only having seen it written. For that
reason, I always thought of it as one of the countless spelling errors one runs
into in the engineering community more and more as engineers are taught to be
literate less and less.
It surprises me, of course, that a term could be so widely understood, yet used
so seldom by those with whom I've worked, over the past three decades and more,
that I've never heard it used, even once, that I can recall.
I've heard that explanation a number of times, but still am uncomfortable with
it, as it seems to me to be a misuse/abuse of the language. Perhaps I'm being
too pedantic.
Dick
----- Original Message -----
From: "Ethan Dicks" <erd_6502(a)yahoo.com>
To: <classiccmp(a)classiccmp.org>
Sent: Friday, November 02, 2001 4:22 PM
Subject: One-off vs. One-of (was Re: CPU design at the gate level)
--- Richard Erlacher <edick(a)idcomm.com> wrote:
Unfortunately for the builders of
"one-of's," like me (spelled one-off's
in some places, for reasons I don't understand)...
It's not just spelled "one-off", it's pronounced "one-off" -
as in
"Wan Awf", not "Wan Ov". It's an engineer's term for a
prototype.
I think you are interpreting it as short for "one of a kind" which I
don't think it is exactly an abbreviation for. It might be short for
"run one off the assembly line and stop", though.
Not sure of the history, but it really is "one-off". I first heard the
term used 17 years ago, not that _it_ was new to the industry, but _I_
was new, then.
-ethan
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
1:34 p.m.
New subject: One-off vs. One-of (was Re: CPU design at the gate level)
The phrase has been around more than 30 years, even if you kids have been
hanging out amongst those who don't use it.
--
Grumpy Ol' Fred cisin(a)xenosoft.com
On Fri, 2 Nov 2001, Richard Erlacher wrote:
Well, that's interesting for sure. Having been in
engineering since 1963, I
have to say I've heard the term "one-of" countless times, since that's
been the
main thrust of my work since that time, and it is short for one-of-a-kind, while
I started running into the term "one-off" only in the past decade, and, in
fact,
have never actually heard it used, only having seen it written. For that
reason, I always thought of it as one of the countless spelling errors one runs
into in the engineering community more and more as engineers are taught to be
literate less and less.
It surprises me, of course, that a term could be so widely understood, yet used
so seldom by those with whom I've worked, over the past three decades and more,
that I've never heard it used, even once, that I can recall.
I've heard that explanation a number of times, but still am uncomfortable with
it, as it seems to me to be a misuse/abuse of the language. Perhaps I'm being
too pedantic.
Dick
----- Original Message -----
From: "Ethan Dicks" <erd_6502(a)yahoo.com>
To: <classiccmp(a)classiccmp.org>
Sent: Friday, November 02, 2001 4:22 PM
Subject: One-off vs. One-of (was Re: CPU design at the gate level)
>
> --- Richard Erlacher <edick(a)idcomm.com> wrote:
> > Unfortunately for the builders of "one-of's," like me (spelled
one-off's
> > in some places, for reasons I don't understand)...
>
> It's not just spelled "one-off", it's pronounced
"one-off" - as in
> "Wan Awf", not "Wan Ov". It's an engineer's term for a
prototype.
>
> I think you are interpreting it as short for "one of a kind" which I
> don't think it is exactly an abbreviation for. It might be short for
> "run one off the assembly line and stop", though.
>
> Not sure of the history, but it really is "one-off". I first heard the
> term used 17 years ago, not that _it_ was new to the industry, but _I_
> was new, then.
>
> -ethan
>
3:29 p.m.
New subject: One-off vs. One-of (was Re: CPU design at the gate level)
In message <001401c16415$61a86040$9cc762d8(a)idcomm.com>om>, "Richard Erlacher"
writ
es:
Well, that's interesting for sure. Having been in
engineering since 1963, I
have to say I've heard the term "one-of" countless times, since that's
been th
e
[...]
It surprises me, of course, that a term could be so
widely understood, yet use
d
so seldom by those with whom I've worked, over the past three decades and more
,
that I've never heard it used, even once, that I can recall.
Facinating. Now I can't say I've been in engineering that long
(only since about '80 except for a little goofing around in
high school). However, my experience has been almost exactly
the opposite. I've always heard and used one-off. It's been
this thread that has introduced me to the term one-of.
Brian L. Stuart
3 Nov
3 Nov
4:03 a.m.
New subject: One-off vs. One-of (was Re: CPU design at the gate level)
Well, it's not that I've not travelled to both coasts (though I've avoided
Texas
and Arizona) in the course of the last 30 years, but perhaps it's just the
insular nature of the Colorado front-range community. It's not a term I hear in
normal discussions of this sort around here. I asked one of the fellows who's
been working since the '70's at one of the old surplus electronics houses here,
and he's not accustomed to the term "one-off" though, like me, he does
remember
hearing folks using "one-of" to refer to a single item project. He did know
what I meant, however.
Dick
----- Original Message -----
From: <blstuart(a)bellsouth.net>
To: <classiccmp(a)classiccmp.org>
Sent: Friday, November 02, 2001 10:29 PM
Subject: Re: One-off vs. One-of (was Re: CPU design at the gate level)
use
In message
<001401c16415$61a86040$9cc762d8(a)idcomm.com>om>, "Richard Erlacher"
writ
es:
>Well, that's interesting for sure. Having been in engineering since 1963, I
>have to say I've heard the term "one-of" countless times, since
that's been
th
e
[...]
>It surprises me, of course, that a term could be so widely understood, yet >d
>so seldom by those with whom I've worked, over the past three decades and
more
,
that I've never heard it used, even once, that I can recall.
Facinating. Now I can't say I've been in engineering that long
(only since about '80 except for a little goofing around in
high school). However, my experience has been almost exactly
the opposite. I've always heard and used one-off. It's been
this thread that has introduced me to the term one-of.
Brian L. Stuart
2 Nov
2 Nov
4:16 p.m.
New subject: One-off vs. One-of (was Re: CPU design at the gate level)
On Fri, 2 Nov 2001, Richard Erlacher wrote:
Well, that's interesting for sure. Having been in
engineering since 1963, I
have to say I've heard the term "one-of" countless times, since that's
been the
main thrust of my work since that time, and it is short for one-of-a-kind, while
I started running into the term "one-off" only in the past decade, and, in
fact,
have never actually heard it used, only having seen it written. For that
reason, I always thought of it as one of the countless spelling errors one runs
into in the engineering community more and more as engineers are taught to be
literate less and less.
It surprises me, of course, that a term could be so widely understood, yet used
so seldom by those with whom I've worked, over the past three decades and more,
that I've never heard it used, even once, that I can recall.
I've heard that explanation a number of times, but still am uncomfortable with
it, as it seems to me to be a misuse/abuse of the language. Perhaps I'm being
too pedantic.
Dick
I am uncertain if I ever saw it in written form until now, but the
spoken `one off' was rather common in the flight test arena here in San
Diego back in the mid 50s, and I think I may have heard it in a
Westinghouse model shop as far back as the middle 40s.
- don
----- Original Message -----
From: "Ethan Dicks" <erd_6502(a)yahoo.com>
To: <classiccmp(a)classiccmp.org>
Sent: Friday, November 02, 2001 4:22 PM
Subject: One-off vs. One-of (was Re: CPU design at the gate level)
--- Richard Erlacher <edick(a)idcomm.com> wrote:
Unfortunately for the builders of
"one-of's," like me (spelled one-off's
in some places, for reasons I don't understand)...
It's not just spelled "one-off", it's pronounced "one-off" -
as in
"Wan Awf", not "Wan Ov". It's an engineer's term for a
prototype.
I think you are interpreting it as short for "one of a kind" which I
don't think it is exactly an abbreviation for. It might be short for
"run one off the assembly line and stop", though.
Not sure of the history, but it really is "one-off". I first heard the
term used 17 years ago, not that _it_ was new to the industry, but _I_
was new, then.
-ethan
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
11:22 a.m.
Richard Erlacher wrote:
While it's true that TTL and work-alike CMOS is found everywhere, if you go with
a parts list, you'll find you're unable to get a substantial range of parts
these days. You may be able to find the parts eventually, but the investment in
shipping is prohibitive.
Unfortunately for the builders of "one-of's," like me (spelled
one-off's in some
places, for reasons I don't understand), the programmable logic comes in
packages that are really inconvenient for that purpose. Nowadays, you're
required to use a 1000+ pin BGA package to get the quantity of logic that you'd
like in a 44-pin PLCC. If you're really lucky with the fit, the device will
allow you to use 10% of the gate count the marketing guys said you're paying
for. The result is that you have to use a PGA package that lists for over $1k
per part, or build an adapter board for the cheaper TQFP part, with a total
cost, when you're done, of over $1k per each anyway, and then, to make matters
worse, only one in 7 of these adapter boards will turn out to be properly
soldered, so you waste 6 FPGA's costing $300 each. That's why product
development that once required a cash outlay of $500 now costs $500 million.
Dick
Don't forget the $500 minimum order per line item. I suspect you need
all the 1000+ pins since
only 50% of the pins are usable -- the power,ground and configuration
pins take up a lot of space.
Ben Franchuk.
--
Standard Disclaimer : 97% speculation 2% bad grammar 1% facts.
"Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk
1:21 p.m.
With the <$1k cost, per each the $500 minimum is no problem. I get Cypress
CPLD's, by the way, from a distributor that has no such minimum, (wierd) but
they're hostile to coming in and picking the parts up rather than paying the $18
shipping for a $6 order. I long for the old queue at the will-call counter,
where you could swap stories and pick up your parts the day you ordered them,
paying sales tax, but no freight, and always being allowed to verify that the
parts were what you ordered. <sigh>
Dick
----- Original Message -----
From: "Ben Franchuk" <bfranchuk(a)jetnet.ab.ca>
To: <classiccmp(a)classiccmp.org>
Sent: Friday, November 02, 2001 6:22 PM
Subject: Re: CPU design at the gate level
Richard Erlacher wrote:
>
> While it's true that TTL and work-alike CMOS is found everywhere, if you go
with
> a parts list, you'll find you're unable
to get a substantial range of parts
> these days. You may be able to find the parts eventually, but the
investment
in
> shipping is prohibitive.
>
> Unfortunately for the builders of "one-of's," like me (spelled
one-off's in
some
> places, for reasons I don't understand), the
programmable logic comes in
> packages that are really inconvenient for that purpose. Nowadays, you're
> required to use a 1000+ pin BGA package to get the quantity of logic that
you'd
> like in a 44-pin PLCC. If you're really
lucky with the fit, the device will
> allow you to use 10% of the gate count the marketing guys said you're paying
> for. The result is that you have to use a PGA package that lists for over
$1k
> per part, or build an adapter board for the
cheaper TQFP part, with a total
> cost, when you're done, of over $1k per each anyway, and then, to make
matters
worse, only
one in 7 of these adapter boards will turn out to be properly
soldered, so you waste 6 FPGA's costing $300 each. That's why product
development that once required a cash outlay of $500 now costs $500 million.
Dick
Don't forget the $500 minimum order per line item. I suspect you need
all the 1000+ pins since
only 50% of the pins are usable -- the power,ground and configuration
pins take up a lot of space.
Ben Franchuk.
--
Standard Disclaimer : 97% speculation 2% bad grammar 1% facts.
"Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk
2:44 p.m.
Nowadays,
you're
required to use a 1000+ pin BGA package to get the quantity of logic
that
you'd
> like in a 44-pin PLCC. If you're really lucky with the fit, the device
will
If you're a really lousy logic designer you can create crap anywhere, no
need to go the FPGA route.
[the price comments were still more crap]
allow you to use 10% of the gate count the
marketing guys said you're
paying
> for. Don't forget the $500 minimum order per line item.
I suspect you need
all the 1000+ pins since only 50% of the pins are usable -- the power,
ground and configuration pins take up a lot of space.
If you use something like the XV1000 (1 MILLION equivalent gates, then yes
the chip will cost you $1700 and you can design in a complete PDP-11/70,
GT-44 subsystem, RL/RK/RX controllers, SDRAM memory controller, front panel
for blinken lights, full floating point, CIS and EIS instruction sets and a
programmable microstore with about half the damn chip left over.
Sheesh, don't dis 'em if you don't know anything about them.
--Chuck
3 Nov
3 Nov
2:23 a.m.
Chuck McManis wrote:
The above statement is completely untrue. You can get
10 - 100x the "ttl"
equivalent logic in a 44 pin PLCC. Check out the XC9572 some time,
depending on your logic you can replace a whole bunch of TTL and they are
$5.53 each from Digikey, quantity 1. Or go to 84 pin PLCC, still allows you
to do through hole work for $7.00 and get 50% more gates.
That is true but random logic is hard to judge how much will fit in a
FPGA. Normal glue logic often fits well as well as simple I/O devices
like a printer port. It is random state logic, Alu's and memory devices
that don't fit well and that is often what is needed.
Note you can still find the old TTL but you pay a arm and a leg for
them.
A 74LS181 that was $1 in jameco is now $4 here. A 74LS382 is $8.00.
If you need old replacement parts this looks to be the spot.
http://www.rocelec.com/
Note the 74182 is the carry lookahead.
If you're a really lousy logic designer you can
create crap anywhere, no
need to go the FPGA route.
Not in all cases, porting a TTL board to FPGA macros can
take up a
lot of macro cells. The moment you clean up the logic you risk becoming
non portable.
If you use something like the XV1000 (1 MILLION
equivalent gates, then yes
the chip will cost you $1700 and you can design in a complete PDP-11/70,
GT-44 subsystem, RL/RK/RX controllers, SDRAM memory controller, front panel
for blinken lights, full floating point, CIS and EIS instruction sets and a
programmable microstore with about half the damn chip left over.
Four chips are fine -- CPU,I/O and 256Kx16 memory. But ya got have that
front panel!
Makes for a mighty thin RACK mount.:)
--Chuck
Ben franchuk.
PS.Not having used a PDP-11 I could be wrong about the memory.
5:45 a.m.
see below, plz.
Dick
----- Original Message -----
From: "Ben Franchuk" <bfranchuk(a)jetnet.ab.ca
To: <classiccmp(a)classiccmp.org
Sent: Saturday, November 03, 2001 9:23 AM
Subject: Re: CPU design at the gate level
Chuck McManis wrote:
The random logic fits better in the CPLDs than in FPGA's, since the routing
doesn't get as tangled as the device fills up. I don't like the way the XILINX
software deals with CPLD's as opposed to FPGA's, though. It's bad there, but
the ALTERA software has really given me cause to wonder. A part of the problem
is that the software doesn't try to squeeze all it can out of the available
resources. Consequently, any effort at approaching full utilization of
available resources has to be done by hand, which is very time-consuming
therefore costly.
Which sorts of logic are more difficult to implement depends to large extent on
the device architecture. One immediately has to draw a distinction between the
CPLD and the FPGA. The former makes it easy to use the available resources,
though not necessarily "fully" utilize them, while the FPGA simply gives you
more, though it's unlikely you'll approach the level of utilization of possible
with a CPLD. The CPLD has more multiplexing/gating/routing resources per
register than the FPGA, and its timing is generally quite deterministic, while
the FPGA has vastly more register resources, but makes you pay for using them by
consuming lots of routing resources and CLB's for the gating, say, in a big
synchronous counter. That also reduces the overall performance of the counter,
since the routing delays are cumulative. What's more, the timing is impacted by
when the routing software encounters a given construct, hence, a counter that
runs easily at 120 MHz in one design may turn out to run no faster than 80 in
another, all that in a device that is advertised suitable for 250 MHz operation.
The above statement is completely untrue. You can
get 10 - 100x the "ttl"
equivalent logic in a 44 pin PLCC. Check out the XC9572 some time,
depending on your logic you can replace a whole bunch of TTL and they are
$5.53 each from Digikey, quantity 1. Or go to 84 pin PLCC, still allows you
to do through hole work for $7.00 and get 50% more gates.
That is true but random logic is hard to judge how much will fit in a
FPGA. Normal glue logic often fits well as well as simple I/O devices
like a printer port. It is random state logic, Alu's and memory devices
that don't fit well and that is often what is needed.
Note you can still find the old TTL but you pay a arm and a leg for
them.
A 74LS181 that was $1 in Jameco is now $4 here. A 74LS382 is $8.00.
If you need old replacement parts this looks to be the spot.
http://www.rocelec.com/
Note the 74182 is the carry lookahead.
<snip Makes for a mighty thin RACK mount.:)
I've got a 256Kx16 DRAM chip lying on the desk right now. They're not
that
uncommon, but they're not a popular chip in the PC market any longer, since the
evolution of AGP. They were common on VLB and PCI SVGA cards. That would have
made the jaws drop back in the days when folks actually used PDP11/70's.
4:48 a.m.
see below, plz.
Dick
----- Original Message -----
From: "Chuck McManis" <cmcmanis(a)mcmanis.com
To: <classiccmp(a)classiccmp.org
Sent: Friday, November 02, 2001 9:44 PM
Subject: Re: CPU design at the gate level
The above statement is completely untrue. You can get 10 - 100x the "ttl"
equivalent logic in a 44 pin PLCC. Check out the XC9572 some time,
depending on your logic you can replace a whole bunch of TTL and they are
$5.53 each from Digikey, quantity 1. Or go to 84 pin PLCC, still allows you
to do through hole work for $7.00 and get 50% more gates.
I think you've misinterpreted what I meant with "what you'd
like." I once
lamented that I couldn't get a 100K gates in an 8-pin package, an obvious
impossiblility because of the die size, because the presence of the extra pins
made me feel the device contents could be too easily compromised. I'm quite
familiar with the XC9572. and it is available in a 44-pin part. However, it's
not an FPGA, and the fact that it isn't makes a big difference in how much of
the purported gate count you can actually use. With cpld's like the XC9572, you
can use pretty much all the available logic without a hitch, though it still
won't approach their (XILINX's) gate count.
Their marketing guys have decided at some point to take the most extreme
interpretation of "gate-count" i.e. a count based on the definition of a gate
as
a two-input NAND, and they count gates based on the notion that a three-input
nand requires two NANDs plus one as an inverter, so they count it as three
gates. On that basis the usual 6 gates required for a 'D' register become quite
a few more, and, of course, a 32-bit LUT has 32 of them, plus a bunch more to
decode the LUT, right? That's what you consume to build just one functional
gate, though, isn't it? My point was and is that the "gate count" has amost
no
direct correspondence to what you can put into a device. After a while you
learn what each device can do for you and so long as you don't try to switch
If you try to use a couple of their
higher-gate-count parts you'll find they're
not readily available in packages you can use for prototyping without first
mounting the parts on an adapter PCB. The BGA's are notoriously difficult to
attach to such adapters and, since that requires lots of effort, it's costly.
If you'd ever tried this, you'd know what I mean. The parts folks use in
production, e.g. the pqfp and tqfp packages are impossible to use in prototypes
because of their fragility. Getting around that means a large cost. If you're
building a revision of an established product and have a deep-pocketed employer,
you can get by with this, but if you're building a proof of concept, which is
what these devices should do best, being readily reprogrammable, the mechanical
constraints and costs get in the way.
> >Don't forget the $500 minimum order
per line item. I suspect you need
> >all the 1000+ pins since only 50% of the pins are usable -- the power,
> >ground and configuration pins take up a lot of space.
If you look at some of the considerably smaller
(in putative gate count) devices
in PGA packages you will see that Avnet, among others lists these parts at
ridiculous prices, probably because of the limited consumption of that package.
> If you use something like the XV1000 (1
MILLION equivalent gates, then yes
> the chip will cost you $1700 and you can design in a complete PDP-11/70,
> GT-44 subsystem, RL/RK/RX controllers, SDRAM memory controller, front panel
> for blinken lights, full floating point, CIS and EIS instruction sets and a
> programmable microstore with about half the damn chip left over.
I don't think you actually believe that,
though it seems you do believe some of
what their marketing folks tell you. However, the fact you have half the chip
left over is because you can't route to the unused resources and still maintain
timing constraints.
> Sheesh, don't dis 'em if you
don't know anything about them.
They're useable devices, to wit, you
can't do anything these days without 'em,
but they're falsely advertised, not convenient to use over their full range, and
VERY costly to use. I have no respect for their marketing claims, but mainly
have problems with their packaging because it's very difficult and costly to
apply to my particular niche.
> --Chuck
Nowadays,
you're
required to use a 1000+ pin BGA package to get the quantity of logic
that
you'd
> like in a 44-pin PLCC. from one family to another, you can almost rely on what
you learn.
I recently went a round with the Altera folks, only to find that their current
software wouldn't, no matter how hard you tried, produce a fuse map for one of
their "classic" devices that the software that was popular with those devices
(APLUS+) would readily yield. The MaxPlus-2 software requires exactly twice the
resources that the old APLUS+ required to create the same construct. Try
generating a COLF (combinatorial output with latched feedback) macrocell
architecture in the current generation of Altera, or, for that matter, Xilinx,
software and see how much of the device resources it requires. Try building the
logical equivalent of a 74BCT2424 using the current generation software and see
what their devices leave over. Now try to fit that into a device that has the
same pin count.
If you're really lucky with the fit, the
device will
If you're a really lousy logic designer you can create crap anywhere, no
need to go the FPGA route.
allow you to use 10% of the gate count the
marketing guys said you're
paying
> for.
[the price comments were still more crap]
You wouldn't say that if you'd ever had to deal with the actual costs
yourself.
2 Nov
2 Nov
9:49 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1312 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20011102/d3516b1f/at…
1:17 p.m.
Well, if you have to repair a terminal with those adders, carry generators, etc,
in it, there's little you can do without them, aside, perhaps from building a
daughterboard with a bunch of programmable parts, or at least one significant
one. The latter always produces the risk of not providing the races that were
designed into the original circuit and therefore failing due to proper design
practice.
Dick
----- Original Message -----
From: "Tony Duell" <ard(a)p850ug1.demon.co.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Friday, November 02, 2001 4:49 PM
Subject: Re: CPU design at the gate level
Ben Franchuk skrev:
I am not sure if 74xxx parts are still being made, but I suspect some of
the more common ones are, at least in HC(T), etc families.
Even with FPGAs and other programmable logic, there are still times when
a few TTL chips make sense even in a commercial product. A lot of
products seem to consist of a microcontroller and a little external
logic. For the latter it doesn't make sense to use an FPGA in a lot of cases.
Even if they're not being made, there's no trouble in getting the more
common parts still. Simple gates, flip-flops, bus buffers, counters,
muxes, decoders, etc.
What are hard/impossible to find are things like RAMs, ALUs, carry
generators, and so on. In general they are only useful to people making
CPUs and similar processing circuits, where there's enough logic to make
it worth using an FPGA (no, I don't much care for them either...). Very
few people (except on this list) want to make a CPU from MSI chips, so
those chips are not made any more.
-tony
Never used the stuff. Since they don't make
TTL any more I kind was
forced into using FPGA's. :).
What? My local electronics shop owner tells me that it isn't as high-prof=
ile
nowadays, but it's quite possible to buy 74 series circuits in any good
electronics shop, right?
3 Nov
3 Nov
4:34 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1560 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20011103/1fdba9d2/at…
5:01 a.m.
see below, plz.
Dick
----- Original Message -----
From: "Tony Duell" <ard(a)p850ug1.demon.co.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Saturday, November 03, 2001 11:34 AM
Subject: Re: CPU design at the gate level
>
> Well, if you have to repair a terminal with those adders, carry generators,
etc,
Sure, or a minicomputer CPU, a control system, a machine tool, or
whatever else uses them. Believe me, I don't like having to hunt around
for a $1 part to fix a mutli-thousand-dollar (or pound) machine. I'd like
to just go out and buy it.
But, alas, the main market for ICs is not repairers. Nor is it
homebrewers (for whom a board of TTL chips is often a lot easier to debug
than an FPGA, and cheaper as well (a soldering iron is a lot cheaper than
the PC [1] to run the FPGA design tools, even if the latter are free). I
still believe it's educational to make at least one machine from MSI
chips. And also to make one using FPGAs.
[1] I am not sure of the current list price of a modern PC + monitor +
Windows, but in the UK, you can get pre-packaged semi-proprietry machines
for about \pounds 1000. And a bit more if you want soemthing that's
reasonably standard and which you have some hope of being able to upgrade.
I just got an unsolicited email from a vendor in Texas that's asking $279 US
for
what's really an eMachines "eTower-633" (with the trademark badge missing
form
the front of the box) with a 15GB HDD, a DVD drive, 128MB RAM a 56KB modem, and
the usual stuff along with a mouse and keyboard. No monitor and no OS.
Shipping to anywhere in the continental U.S. is $35. A friend of mine bought
one for his own use, and I helped him fiddle with it, and convinced myself that
it's a good and solid enough machine. His hard disk failed and he had a
replacement within a week, so the usual warranty mechanisms are in place as
well.
> in it, there's little you can do without them, aside, perhaps from building
a
> daughterboard with a bunch of programmable parts,
or at least one
significant
Yes, I've had to do that...
> one. The latter always produces the risk of not providing the races that
were
> designed into the original circuit and therefore
failing due to proper
design
practice.
Alas all too true. A lot of the TTL-based stuff from the 1970s has some
poor design practicies in it, but if it works, there's no reason to
attempt to redesign it.
-tony
4 Nov
4 Nov
11:51 a.m.
ard(a)p850ug1.demon.co.uk (Tony Duell):
What are hard/impossible to find are things like RAMs,
ALUs, carry
generators, and so on. In general they are only useful to people making
CPUs and similar processing circuits, where there's enough logic to make
it worth using an FPGA
How about programming an EPROM with a lookup
table to emulate an ALU?
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
greg(a)cosc.canterbury.ac.nz +--------------------------------------+
5 Nov
5 Nov
5:50 a.m.
Greg Ewing wrote:
How about programming an EPROM with a lookup
table to emulate an ALU?
Brings back memories of a harebrained idea I was presented with in all
seriousness some 20 years ago. A CPU implemented entirely in a lookup
ROM. All processor state fed in as address bits and the output reset all
the state bits. A really fast processor, capable of any operation in one
clock. Only problem is the size of the ROM for any reasoable state vector.
The rest of the week was spent figuring out how to reduce the ROM size
by factoring out sub systems which were implemented in this way.
Really wierd - and it went nowhere.....
-- HBP
1:16 p.m.
This isn't as unrealistic as it might seem at first glance. That's the core of
what FPGA's are. Each "CLB" configurable-logic-block, or whatever the
marketing
term is this week, has a set of inputs, address lines, if you will, a lookup
table RAM, and an output bit. This is accompanied with an output register
(implemented in the LUT ramblock, based on the this-state-next-state equations
for the flipflop type), and a multiplexer to bypass that register in cases where
it's not wanted.
The RAM that contains the lookup table also contains the steering term to that
multiplexer, in the form of a feedback bit from the lookup table, and, of
course, an XOR buffer by means of which the output can be set to positive or
negative logic (logically implemented in the RAM as well). All this can be
readily mapped into a memory.
Figuring out the optimal way to do that is, of course, what keeps the FPGA
makers in business. There are all kinds of strategies trading off virtual logic
performance versus virtual routing capability (which is really also controlled
by more RAM locations as well as by how the functions are mapped in to the RAM.
It's all virtual, though.
It requires a big RAM, though, in both width and depth. FPGA's today, are made
with some of those resources physical rather than virtual, including, say, the
mux's, registers, and buffers.
However, back in the '80's, some "hardware simulators" consisted of
little more
than a huge RAM array with very complex software for optimizing the allocation
of feedback and replication. (replication requires more RAM bits, but
simplifies and speeds up certain logical constructs by eleiminating the need for
multiple feedback paths for a single function. I'm sure it's not hard to
envision building any logical construct in a very deep, very wide memory.
Dick
----- Original Message -----
From: "Hans B Pufal" <hansp(a)aconit.org>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, November 05, 2001 12:50 PM
Subject: Re: CPU design at the gate level
Greg Ewing wrote:
How about programming an EPROM with a lookup
table to emulate an ALU?
Brings back memories of a harebrained idea I was presented with in all
seriousness some 20 years ago. A CPU implemented entirely in a lookup
ROM. All processor state fed in as address bits and the output reset all
the state bits. A really fast processor, capable of any operation in one
clock. Only problem is the size of the ROM for any reasoable state vector.
The rest of the week was spent figuring out how to reduce the ROM size
by factoring out sub systems which were implemented in this way.
Really wierd - and it went nowhere.....
-- HBP
5:58 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 449 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20011105/6672b2a0/at…
8215
days inactive
8221
days old
36 comments
13 participants
participants (13)
-
allain＠panix.com -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
blstuart＠bellsouth.net -
cisin＠xenosoft.com -
cmcmanis＠mcmanis.com -
donm＠cts.com -
edick＠idcomm.com -
erd_6502＠yahoo.com -
greg＠cosc.canterbury.ac.nz -
hansp＠aconit.org -
optimus＠canit.se -
pcw＠mesanet.com