21 Sep
2001
21 Sep
'01
3:29 a.m.
The book: "Computer Organization & Design, The Hardware/Software
Interface",
by David A. Patterson and John L. Hennessy is a pretty thorough modern book.
I don't know where to find a bit-slice design book these days.
--tom
At 09:18 AM 9/21/01 +0100, you wrote:
Tony Duell wrote:
I've not come across it, but if it stops with
registers and
the ALU, I don't think I'd call it a 'good book'.
A CPU can be divided into 2 parts. The Data Path (registers, ALU, the
multiplexers between them, etc) and the Control (instruction decoder,
microcode + sequencer, condition logic, etc)
True, I don't recall covering much in the way of control logic - only
very basic stuff like telling the ALU whether to add or subtract, plus
implementing a few flags like zero and carry. Once we got to that stage
they threw us at the 29xx series to look at microcoding, which was all
the rage at the time.
Unfortunately I've lost most of my college notes now, I guess I've moved
too many times :-/ I've been looking for a replacement for the Thewlis
book - can you recommend any which cover CPU logic from the basics of
how to build registers out of gates up to instruction fetching & decoding?
I'm also very keen to get hold of a book covering the bitslice processors
(29xx), any ideas? I can't imagine there's anything left in print now, but
with an author/title or ISBN I might be able to track down a second-hand
copy.
-al
21 Sep
21 Sep
6:30 a.m.
Tom Uban wrote:
The book: "Computer Organization & Design, The Hardware/Software
Interface",
by David A. Patterson and John L. Hennessy is a pretty thorough modern book.
I don't know where to find a bit-slice design book these days.
Two books, which are still smiling at me from the bookshelf here
Try to find this one:
- "Bit Slice Design:Controllers and ALU's"
by Donnamaie E. White ISBN 0-8240-7103-4
Most of this book was online at some time, I didn't find it today :-(
(but i didn't look too hard)
She (?) should have a webpage somewhere.
the other one is:
- "Bit Slice Microprocessor Design" by Mick and Brick
ISBN 0-07-041781-4
It is probably online somewhere.
cheers & have fun,
emanuel
4:35 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 884 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20010922/0207818a/at…
5:48 p.m.
A big part of this problem is that there is such a wide range of what is
collectively referred to as a processor. If you want to know how to design, at
the gate level, a set of registers, you start with how to build a flipflop and
go from there. If you want to consider the datapaths, you figure out what you
want in the way of multiplexers and tristate busses. The remainder is in how to
build a sufficiently fast ALU, and how to design an instruction set. Most
people start with the architecture, and that will dictate much of what's needed
in terms of registers and data steering logic. Concatenating the datapaths in
order to provide the necessary functions is not terribly difficult if the
instruction-set/architecture combination is regular and well-designed.
It's difficult to discuss in advance of a specific set of requirements, however,
because each case varies considerably.
I wouldn't be too hard on authors for not trying to do what can't be done well.
Specific examples are widely available in VHDL and Verilog examples on the WWW.
I find the VHDLs easier and quicker to understand than schematics, even though I
was raised on schematics.
Dick
----- Original Message -----
From: "Tony Duell" <ard(a)p850ug1.demon.co.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Friday, September 21, 2001 7:35 PM
Subject: Re: CPU design at the gate level
The book: "Computer Organization & Design, The Hardware/Software
Interface",
by David A. Patterson and John L. Hennessy is a pretty thorough modern book.
Yes, unfortunately it is a 'modern book'. I read some of Hennessy and
Patterson once, and found it was great at telling me how to analyse a
processor design, and optimise it, and things like that, but it didn't
really tell me how to do the design in the first place.
It seems to have been written for the modern 'engineer' -- the sort that
couldn't design an engine (in the original meaning of 'ingenious
mechanism') if his life depended on it. And as you might have guessed by
now, I have little time for 'engineers' who can't design and build
examples of the things they claim to understand.
You couldn't take that book and learn enough to start wiring up gates and
flip-flops to make a processor :-(
-tony
22 Sep
22 Sep
5:12 a.m.
At 02:35 AM 9/22/01 +0100, you wrote:
>
> The book: "Computer Organization & Design, The Hardware/Software
Interface",
> by David A. Patterson and John L. Hennessy is a
pretty thorough modern
book.
Yes, unfortunately it is a 'modern book'. I read some of Hennessy and
Patterson once, and found it was great at telling me how to analyse a
processor design, and optimise it, and things like that, but it didn't
really tell me how to do the design in the first place.
It seems to have been written for the modern 'engineer' -- the sort that
couldn't design an engine (in the original meaning of 'ingenious
mechanism') if his life depended on it. And as you might have guessed by
now, I have little time for 'engineers' who can't design and build
examples of the things they claim to understand.
You couldn't take that book and learn enough to start wiring up gates and
flip-flops to make a processor :-(
I beg to differ. I feel that the book does a fairly good job of covering
all aspects of processor design to date. It does in fact describe how the
ALU is implemented along with the data paths necessary to feed it. It
also importantly covers the hows and whys of the control plane needed to
make the data path function. The book teaches all of the various arithmetic
concepts (like floating point) which are now expected in modern designs.
With these more basic concepts, it also covers the hows and whys of
performance.
While it does not teach you how to use a wire wrap tool, it does cover
basic logic design concepts (in an appendix) as well. Perhaps in your
case it just has too many references to the popular processors of the
day for your taste. But, just because they are popular today, does not
mean that they cannot be powerful learning tools, even for those who
are interested in the processors of yesteryear...
What it does not do is give you a schematic of a processor and hold your
hand while describing each gate. If this is what you want, then perhaps
the set of (KB11-A central processor unit maintenance manual, PDP-11/45
and PDP-11/50 system maintenance manual, and 11/45-0 engineering drawings)
would be a better instructional set.
Let's face it. No one book is going to teach someone everything that they
need to know to be able to design the next "great" processor. There is
also nothing better to teach a subject than to learn from what others
have done in the past.
--tom
6:01 a.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.
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.
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.
Anybody wishing to go through the process of CPU design, which, BTW, is a
required course in most EE curricula, needs to complete a thorough requirements
analysis just to put some firm limits on what the end-product has got to be.
Dick
----- Original Message -----
From: "Tom Uban" <uban(a)ubanproductions.com>
To: <classiccmp(a)classiccmp.org>
Sent: Saturday, September 22, 2001 8:12 AM
Subject: Re: CPU design at the gate level
At 02:35 AM 9/22/01 +0100, you wrote:
>
> The book: "Computer Organization & Design, The Hardware/Software
Interface",
> by David A. Patterson and John L. Hennessy is
a pretty thorough modern
book.
Yes, unfortunately it is a 'modern book'. I read some of Hennessy and
Patterson once, and found it was great at telling me how to analyse a
processor design, and optimise it, and things like that, but it didn't
really tell me how to do the design in the first place.
It seems to have been written for the modern 'engineer' -- the sort that
couldn't design an engine (in the original meaning of 'ingenious
mechanism') if his life depended on it. And as you might have guessed by
now, I have little time for 'engineers' who can't design and build
examples of the things they claim to understand.
You couldn't take that book and learn enough to start wiring up gates and
flip-flops to make a processor :-(
I beg to differ. I feel that the book does a fairly good job of covering
all aspects of processor design to date. It does in fact describe how the
ALU is implemented along with the data paths necessary to feed it. It
also importantly covers the hows and whys of the control plane needed to
make the data path function. The book teaches all of the various arithmetic
concepts (like floating point) which are now expected in modern designs.
With these more basic concepts, it also covers the hows and whys of
performance.
While it does not teach you how to use a wire wrap tool, it does cover
basic logic design concepts (in an appendix) as well. Perhaps in your
case it just has too many references to the popular processors of the
day for your taste. But, just because they are popular today, does not
mean that they cannot be powerful learning tools, even for those who
are interested in the processors of yesteryear...
What it does not do is give you a schematic of a processor and hold your
hand while describing each gate. If this is what you want, then perhaps
the set of (KB11-A central processor unit maintenance manual, PDP-11/45
and PDP-11/50 system maintenance manual, and 11/45-0 engineering drawings)
would be a better instructional set.
Let's face it. No one book is going to teach someone everything that they
need to know to be able to design the next "great" processor. There is
also nothing better to teach a subject than to learn from what others
have done in the past.
--tom
9:15 a.m.
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.
There's currently talk on the FLEX email list of implementing
a new CPU in an FPGA or CPLD for use in existing SS-30/SS-50 bus
systems in conjunction with things such as Michael Holley's new
floppy controller, as well as reducing the overall board count needed
for a complete system, including I/O and RAM, down to two.
Jeff
--
Home of the TRS-80 Model 2000 FAQ File
http://www.cchaven.com
http://www.geocities.com/siliconvalley/lakes/6757
10:40 a.m.
On Sat, Sep 22, 2001 at 09:01:28AM -0600, Richard Erlacher wrote:
One caution is certainly warranted, however. Fully
synchronous design became
the default method of designing circuits of anysubstance in the mid-late '80's.
The pendulum may be swinging back toward asynchronous design.
http://www.acm.org/technews/articles/2001-3/0921f.html#item13
The ACM article mentions the increased speed of asynchronous designs. As
you said, they are hard to analyze (and keep running); the article turns
that into an advantage by pointing out that hackers can't analyze them
easily either. :)
I don't necessarily buy the reasoning (these articles are pretty
superficial) but the point still bears thinking about.
-- Derek
1:01 p.m.
While it makes sense that clock distribution would increase power consumption, I
don't think that synchronous/vs asynchronous design is the point of the article
to which you refer. Synchronous designs do, however, require that every stage
of the "pipeline" is clocked from the same clock, there are ways of
synchonizing
events between asynchronous modules in a circuit that minimize the risks of
metastability, and that's the principal bugaboo that gave rise to the popularity
of all-synchronous design. Moreover, it requires somewhat more imagination and
resourcefulness to design efficiently interacting asynchronous circuits, which
tend, generally to be a mite thriftier if implemented in discrete components,
yet yield little benefit to the designer of CPLD/FPGA-based logic.
The type of CPU they're referring to in this case, methinks, is a level-latched
rather than edge-triggered-flip-flop based architecture. It has some potential,
but, since it's not the cookbook sort of structure that is taught in colleges
these days, it will be a while before it's fully explored. The MOT 6800 and
MOS-Technology 650x types used that sort of approach, using the "clock" to gate
and steer rather than to trigger events.
Dick
----- Original Message -----
From: "Derek Peschel" <dpeschel(a)eskimo.com>
To: <classiccmp(a)classiccmp.org>
Sent: Saturday, September 22, 2001 1:40 PM
Subject: Re: CPU design at the gate level
On Sat, Sep 22, 2001 at 09:01:28AM -0600, Richard
Erlacher wrote:
> One caution is certainly warranted, however. Fully synchronous design
became
> the default method of designing circuits of
anysubstance in the mid-late
'80's.
The pendulum may be swinging back toward asynchronous design.
http://www.acm.org/technews/articles/2001-3/0921f.html#item13
The ACM article mentions the increased speed of asynchronous designs. As
you said, they are hard to analyze (and keep running); the article turns
that into an advantage by pointing out that hackers can't analyze them
easily either. :)
I don't necessarily buy the reasoning (these articles are pretty
superficial) but the point still bears thinking about.
-- Derek
8:50 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 2365 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20010922/ffff8148/at…
8345
days inactive
8346
days old
9 comments
6 participants
participants (6)
-
ard＠p850ug1.demon.co.uk -
dpeschel＠eskimo.com -
edick＠idcomm.com -
emu＠ecubics.com -
jhellige＠earthlink.net -
uban＠ubanproductions.com