CPU design at the gate level

From: ajp166 <ajp166_at_bellatlantic.net>
Date: Tue Nov 6 18:37:48 2001

Tony,

There is a trick... half the calcs result in the same thing. remove the
mirrored states and your more than halfway there.

Allison
-----Original Message-----
From: Tony Duell <ard_at_p850ug1.demon.co.uk>
To: classiccmp_at_classiccmp.org <classiccmp_at_classiccmp.org>
Date: Tuesday, November 06, 2001 7:00 PM
Subject: Re: CPU design at the gate level


>>
>> Tony,
>>
>> Faster as in is sub 150ns are fairly common and cheap. Whats
>
>It's still slower than F-TTL I think.
>
>> problemtic is that the ALU must do about 8-16 different operations
>> so that would be at least a 512kN part or larger.
>
>Well, a 16 bit ALU in a single EPROM (or a pair of 8-bit wide ones) is a
>non-starter. You'd need 32 data inputs (2 16 bit words), say 4 or 5
>function select inputs, carry in. That's about 38 inputs, so 38 address
>lines to the EPROM, or 256 gigawords. Ouch!.
>
>8 bits is possible, but still pushing it (around 4M bytes of EPROM -- 16
>data inputs, 5 function selects, carry in, so 22 address lines).
>
>4 bits is trivial (8 data inputs, 5 selects, Cin, so 14 total, or 32K
>nybbles).
>
>If you're going to cascade EPROMs for more bits, even if you use
lookahead
>carry, then the time taken for the ALU to calculate a result is around
>twice the access time of the EPROMs (once to calcuate P,G, and a
possibly
>incorrect result, once to correct the result for the Cin signal produced
>as a result of P and G from lower ALUs).
>
>You might be able to save some time by having multiple EPROMs (or the 2
>halfs of the output word of a single EPROM) calculate the 2 possible
>results (Cin =0 and Cin =1). Then select between them using
(distributed)
>multiplexers debending on the actually state of Cin, which should be
faster
>then another EPROM access.
>
>-tony
>
Received on Tue Nov 06 2001 - 18:37:48 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:34:14 BST