Ideas for a faster TTL CPU //6502 related

[ttlworks]

Now for something different: 7485 magnitude comparators.
Since availability of 74F85 and 74AC85 doesn't look good, this posting won't be useful for _this_ project,
but maybe somebody could turn the concept into something useful later in the future (you never know).

Be warned, that it's all untested... and just theory.
Might contain some errors, don't expect things to work at first try.

;---

While flipping through the pages of the 1985 Fairchild 74F data book at Bitsavers,
the picture on page 4-29 (page 74 of the PDF) about cascading 74F85 magnitude comparators had caught my attention:

It somehow reminded me to cascading 74182 carry lookahead chips:



;...

7485 is optimized for speed, so it isn't obvious from the gate level schematic in the 7485 datasheet,
but when drawing a (slower) Bit_sliced version of a magnitude comparator, I'm getting something like this for a single Bit:

The light_blue marked part is the logic which detects A>B, and when re_drawing that part a few times,
it appears to be just subtractor circuitry calculating A-B by inverting B (similar to how SBC works in the 6502 ALU).

;...

So when we have a 4 Bit adder, and we want to build a 4 Bit carry lookahead circuitry for the adder carry output,
in theory we could just take a 7485 magnitude comparator and invert the comparator B input:

;....

Now for a (hypothetical) 4 Bit ALU, with a 7485 based carry chain:

The boxes labeled "LU" are logic units based on 74153 4:1 multiplexers.

[Drass]

Work on the C74-6502 Rev B continues ...

At this point, I’ve looked over most aspects of the new design, and a significant speed hike seems indeed feasible. Several factors are contributing to the improvement:

• Pre-loading input data (Decode Phase)
• WriteFlags pipeline stage
• FET Switch Adder
• RAM microcode store
• 3.3V LVC components

Given that, it’s time to start thinking seriously about signal integrity. Edge-rates will not be any faster, but I am assuming here that a faster clock will allow less time for reflections to die down, and errors may start to creep-in on latching inputs. So the question is, what’s a reasonable trace length to work to?

I spent a few minutes googling around to try to figure it out. Here is what I found:

• Signals on a standard PCB travel at about 6.6inches/ns (https://www.protoexpress.com/blog/signa ... sion-line/).
• Here is another nice reference: http://www.ti.com/lit/an/scaa082a/scaa082a.pdf
• The signal rise time of LVC logic is about 4.5ns (see p. 2-26 http://www.ti.com/lit/ug/scba010/scba010.pdf).
• That suggests a 14 inch trace would meet the 1/2 signal rise-time rule of thumb. (4.5/2 * 6.6 = 14.85) http://www.circuitengineer.com/high-spe ... gineering/
• On the other hand, the LVC document also provides some information on termination. On page 1-27 “If the trace length is greater than four inches, reflections begin to appear on the line and the system may appear noisy and generate unreliable data. The solution to this is to terminate the outputs in an appropriate manner to minimize the reflections.”
• Finally, the Saturn PCB design calculator (http://www.saturnpcb.com/pcb_toolkit/) suggests that for a 4.5ns rise time, 8 (IPC-2251 method) to 21 inches (Frequency Domain Method) is an appropriate length.

So, after some searching, I end up with a range of 4” to 21”, which is too broad a range to be useful.

I may be able to get this new design onto a single densely populated Eurocard-sized PCB (by using TSSOP rather than SOIC parts). But even then, keeping all traces shorter than 4” to be on the safe side is going to be very difficult. If the CPU works as expected, we might see clock speeds above 50MHz. Termination on clock signals will likely be required, but other traces may need to be terminated as well. Unfortunately, short of ordering some test PCBs to check things out, I’m not sure how to get a feel for the tolerances here.

[GARTHWILSON]

See the applicable section of the 6502 primer "Construction: Avoiding AC-Performance Problems," at http://wilsonminesco.com/6502primer/construction.html and the links there, including to a couple of forum topics.

Terminations assume the transmission-line impedance is controlled. If the terminating resistance is not near the characteristic transmission-line impedance, it won't really do any good. Schottky diode terminations work well if you can find diodes that are fast enough; but I don't know where you'll find any fast enough for this.

[ttlworks]

The fastest Schottky diode I know is the LL101, trr=1ns.

Schottky diode arrays from TI:
SN74F1016 16 Bit Schottky diode plus R-C bus termination array, trr=8..10ns
SN74S1053 16 Bit Schottky diode bus termination array, trr=8..16ns
SN74S1051 12 Bit Schottky diode bus termination array, trr=8..16ns
SN74F1056 8 Bit Schottky diode bus termination array, trr=5..7ns

There are smaller Schottky diode arrays, for instance the 3 pin BAT54SW, trr_max=5ns

It's an interesting question, if TVS diode arrays could be used for line termination, too.
Vishay VBUS54GD-FBL, 4 line ESD protection for HDMI,SATA, etc. (don't ask me how to solder that package).

;---

Edit1:
1972 Motorola System Design Handbook has something on page 82 about "Schottky Diode Termination".
Also interesting: page 109, Multilayer ECL board layouts.

The MBD101 Schottky diode used for line termination in the Motorola handbook still is available and in production
as MMBD101 in SOT23 SMD package.

MBD101 seems to have less capacitance than the LL101.

;---

Edit 2:
MMBD352 'Dual Hot Carrier Mixer Diode', the datasheet looks interesting.
MMBD352TL1,SOT-23 (TO-236) package.
MMBD352WT1,SOT-323 (SC-70) package.

[Drass]

Ah, so much to learn, so much to learn ... thanks for the links gents.

I understand that controlled impedance requires that several parameters be managed carefully, including the geometry of the trace itself, the distance to the reference plane, the dielectric material, and so on. Then there are vias and connectors to further complicate matters. There are a few calculators around to figure things out, and I understand also that one can spec the target impedance for traces and the board house will adjust things slightly as required (which sounds very expensive).

Interestingly, I note some LVC family ICs have series resistors built-in on outputs (25Ω for 74LVCR2245s fore example), so I suppose source termination is common enough out there. My hope is to try to keep traces short enough to not have to worry about any of this, but I have a feeling “some restrictions will apply” nevertheless.

[BillO]

ttlworks wrote:

Since availability of 74F85 and 74AC85 doesn't look good,...

How about 74F521 comparators? They are 8 bit, but only show equal or /equal. No > or <.

Or configuring 7ns GAL22V10s as magnitude comparators?

[Drass]

I thought I would share the (very rough) block diagram I’m working with for the new design.

Some optimizations to note:

• The ALU inputs are registered (ALUA, ALUB and ALUC). They are pre-loaded in the cycle prior to the ALU operation.
• The transparent latch (ALUR) at the output of the ALU, prior to the Flags logic, allows the BRanch test logic and writes to the P register to be executed in the cycle following the ALU operation (WriteFlags pipeline stage).
• Inverting and non-inverting buffers work in parallel to connect the Data Bus to the ALUB input. A byte read from memory can therefore be inverted in the cycle prior to an SBC operation at no extra cost, thereby eliminating the need for inverters in the ALU itself.
• ADL/ADH and R/W are registered as well, and are also pre-loaded in the cycle prior to their use.

As with the prior version, microcode is prefetched. The new Decode logic (not shown) enables the CPU to pre-load input registers, and otherwise get a jump on control logic (by decoding the Opcode on the fly). The ALU Execute cycle is made shorter by pre-inverting the B input as necessary. The ALU itself is much faster through the use of a FET Switch Adder. And finally, the WriteFlags pipeline stage takes care of all post-ALU processing.

Taken together, these improvements should make for lots of parallel processing and a much shorter critical path. We’ll have to see whether the concept holds up.

[ttlworks]

74377 is an exotic chip.
It's worth a thought if we could pick up an old idea from Jeff: building registers from 74163 4 Bit counter chips instead of using the 74377.

Hey, maybe we even could toss that 74283 based 16 Bit incrementer out of the design.

Would suggest to take a look at the 65CE02 block diagram:

[ttlworks]

BillO wrote:

How about 74F521 comparators?

74F521 is just an identity comparator like the 74688, no subtractor circuitry inside.
Something like 74AS885 would be better.
Using GAL22V10 would be cheating.

Anyhow, it looks like a carry chain built from FET 2:1 multiplexers\switches would be quite the thing.
Building a carry chain from individual transistors was "plan B", comparators "plan C".

;---

Did a search for counters with three_state outputs, TI and OnSemi, but the results don't look good.

74AS869 8 Bit up/down counter with three_state outputs is a neat chip, but for 50MHz it's too slow.

;---

Edit:
When comparing the NXP 74LVC163 counter wired up as a latch and the NXP 74LVC377 latch,
74LVC163 has slightly less propagation delay than the 74LVC377 (clock to data output),
74LVC377 needs slightly less setup time than the 74LVC163 (data and control input to clock).


NXP 74LVC163 4 Bit counter: VCC = 3.0V .. 3.6V, -40°C .. +85°C
tsu setup time: Dn to CP = 2.5ns_max 1.0ns_typ; /PE to CP = 3.0ns_max 1.2ns_typ
tpd propagation delay: CP to Qn = 1.5ns_min 3.8ns_typ 7.3ns_max

NXP 74LVC377 8 Bit latch: VCC = 3.0V .. 3.6V, -40°C .. +85°C
tsu setup time: Dn to CP = 2.0ns_max 0.7ns_typ; /E to CP = 3.0ns_max 0.2ns_typ
tpd propagation delay: CP to Qn = 1.5ns_min 4.0ns_typ 7.6ns_max

[GARTHWILSON]

The 74_181 keeps coming up, so I thought I'd link to this article:
Inside the vintage 74181 ALU chip: how it works and why it's so strange
http://www.righto.com/2017/03/inside-vi ... ow-it.html
(Someone posted the link on the MoHPC HP calculator forum.)

[ttlworks]

74181 ?
Been there, done that. (page 3, 4, and 5)

Another interesting (but more exotic than the 74181) TTL ALU chip would be the 74381.

Project5474 is about reverse engineering TTL chips, but progress seems to be slow.

There is a detailed AM2903 dissection from 1979.
//AM2903 was a 4 Bit bitslice chip from AMD, containing an ALU and registers.

[ttlworks]

The BCD circuitry in our old TTL CPU design appears to be a bottleneck when trying to go faster than 20MHz.

There is an old article about BCD correction in the NMOS 6502, the interesting part starts here.

Our old TTL CPU design uses 74283 adders for BCD correction.
74283 isn't too fast.
NMOS 6502 does the correction without resorting to an adder:



Edit: cor+ and cor- in the picture above might be generated this way:



Now to make creative use of the 74LVC1G99 (which happens to have an output enable) for building a BCD correction:

Q0 doesn't need to be corrected.
C4 is the ALU carry output, C4' is the carry output after the $A..$F detection.

That 74151 gated with the ALU carry output just detects $A..$F at the ALU output during decimal ADC, nothing fancy there.
Works like this:





Since the 74AC151 worst case timing is agonizingly slow, another approach for detecting $A..$F at the ALU output would be making creative use of fast FET switches
(that sort of switches we would like to use for implementing the carry chain inside the ALU):

[ttlworks]

Of course, detecting $A..$F at the ALU output isn't the end of the ladder,
NMOS 6502 makes creative use of the propagate\generate signals inside the ALU instead.

An oversimplified and not 100% technically exact picture of how the NMOS 6502 does it:
//The red box _could_ be a part of the carry chain, but in the NMOS 6502 chip layout, it isn't.



After omitting the BCD_ADD (ADC BCD) signal for better reliability, I'm getting this:

bcd_det_nmos6502.png (80.29 KiB) Viewed 4090 times

When tinkering a bit with an old test program, I'm getting an alternative approach:

[ttlworks]

And when tinkering with the alternative form of the $A..$F detection,
an implementation of it by resorting to FET switches would look like this:

And an implementation resorting to multiplexers would look like that:

[Drass]

This is really great Dieter! I’ll take a closer look at the [$A..F] Detect circuits.

I made a few mods to the BCD Adjust circuit above. The propagation delay is reduced significantly if we use FET Multiplexers for the adjust logic, as follows:

In this diagram, BCDLC and /BCDLC are the positive and negative outputs of the [$A..$F] Detect ‘151. They are connected to the Data Inputs of the subsequent FET Muxes. The Select Inputs take much longer to resolve, and use only signals which are available already by the time BCDLC arrives. The switching time of the MUXes is therefore taken out of the critical path.

I managed to test the adjust circuits in Logisim, and they both check out — good news.

Cheers!