Oh, and thanks too for making schematics which show the signal flow! That's what I call a proper schematic.

Here is the ALU nibble completely routed (still needs to be cleaned up a bit). The surrounding white box is 32x24 mm. A full ALU should be twice that, so 32x48 mm, which is about 10% of a Eurocard. The green circles are test points. They just serve as place holders for all external connections (input, output and control signals). Inputs are all on the left, outputs on the right, and controls run vertically. The bottom two signals (partial Carry and Zero flag) should propagate to upper nibble.

I think I'll start working on the PC and AB logic next, to get a better idea of how that's going to look. The PC will also get a ripple carry, but only has 1 gate delay per bit, instead of 2. Of course, it will be twice as long, so total delay should be similar, but slightly less than ALU. The rest of the design won't have any more adders or incrementers. A lot of muxes and registers, and some random logic. I'm trying to fit all the logic in half the Eurocard size, and reserve the other half for the PLA. No idea if that's enough, but we'll see it when we get there.

My plan is to draw schematic and do layout for each subsection, keeping them well separated, and then experiment with different placements on the board. If you keep them apart, it's easy to draw a box around a section, and move it around, without dragging all the connections as well.

Had to rearrange the mux inputs a little bit to make routing easier, so I also updated schematic.

Looks great. Lots to learn here from the approach you’re taking. Looks like traces on three layers?

_________________
C74-6502 Website: https://c74project.com

Yes, red is top, blue is bottom, and orange is one of the middle layers (power). There's a 4th layer for ground that I try to keep empty.

There are ground pours on top/bottom, but they've been switched off for clarity. I've added screenshot of the individual layers. On the orange one I've highlighted the VDD signal, so you can see it reaches the vias that it needs for powering the ICs with reasonably fat traces. I'll put a bypass cap near each of the vias.

Also, at the last stage, I add a bunch of ground vias to stitch all the ground pours together. Couple of other things I'm trying to do: keep like signals together and avoid empty parts (still need to improve that here). This improves plating reliability. And try to avoid cutting ground plane in distinct regions.

See for example the top layer bottom right. There are two vias close together, interrupting the flow of the ground plane. I don't like that, so I'll go fix things like that.

Fixed the interrupted ground by moving via a bit

I thought I had a clever resource-saving trick by registering PC on negative clock edge (everything else switches on positive edge), but then I realized that this trick only leaves the PC with half a clock cycle to do the 16-stage ripple carry. I just reworked the code to switch clock on positive edge instead. Thankfully the impact on logic size is minimal. I still need to calculate AB+1, but add an extra path to load AB+1 directly into AB instead of only in PC.

I'm sure you'll recall that the 6502 uses some lookahead to increment PC - as it's only an incrementer, that's just a wide NOR on the inverted outputs.

I'm supposing you don't have a way to run a static timing analysis?

With current design I have AB register -> incrementer -> mux -> AB/PC register. Using the 74ALVC08 for example, I have max propagation delay of 2.9 ns per gate, which is about max 50 ns for 16 stages. Add a bit for the mux, xor and setup, and it should still be well under 100 ns, which is good enough for me. More importantly, the PC delay is less than ALU delay, which I can't really optimize without special hardware that fall outside the rules.

And of course, a 16 gate chain of AND gates is delightfully simple, both for schematic/layout and understanding.

And realistically, it's only 15 stages, because who lets their code wrap from FFFF to 0000 ?

Yes, it might well be fine, and is certainly simpler, not to carry lookahead.

As I recall, the best guess we have for the critical path in the 6502 is in the control of PC increment: there's work to be done before deciding to increment, and it all has to happen in one cycle.

Possibly this is a non-event with your first revision, where you plan to use an FPGA for the control?

In my case, decision to increment only depends on current {state, IR} combo, both of which are fully registered. In fact, that is true for nearly all control signals in the design. Delay should be equal to one pass through PLA. For instance, I see that the 6502 uses information about branches in the PC increment decision. I have a special state for taking branches. When not taking a branch, state machine goes from DECODE->FETCH->DECODE. When taking a branch it goes from DECODE->BRA0->[BRA1/BRA2]->FETCH. The AB/PC logic only needs to look at the state. In the FETCH state, it takes the AB+1 value, and in the BRA0 state it takes the address from the ALU. Both are calculated in parallel.

Challenge remains to make the PLA both compact and fast. I have some vague ideas, but no concrete plans yet. I'll probably have to do some experimenting first.

(BTW, my original jokey estimate of board size didn't take into account the use of FPGA, so it was an estimate for a fully TTL implementation. Maybe one day we'll know whether I was close or not!)

Here's my new incrementer decision. Mostly depends on state alone, with one exception for 1 byte push/pulls. In those cases, we've already fetched next opcode, but still need to finish current instruction, so opcode can't be loaded in IR yet. My solution is to finish operation, and simply go back to FETCH state and get next opcode again.

ABI is output of incrementer (ripply carry chain, fed by inc_ab).

And then there's another enable signal that determines whether PC should be updated with ABI or not.


ABI can also go directly into AB register. That code is a bit more elaborate, but at the heart it's just a mux.

The implementation of the mux will most likely be done by an internal bus running across the board, with a bunch of 3-state drivers. I thought about using a real mux, but I think the wiring will get too messy.

Hello, I've been following along and find myself intrigued, especially when the Verilog code is posted. Would it be alot of work to post an RTL schematic of the code? If it's too much trouble, maybe just once in awhile. Or am I just being lazy?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I'll try to post more schematics soon. The code should crystallize pretty soon, and then I'll start converting more parts to schematic. For now, it's so much quicker to express thoughts in verilog than in schematic. You could try loading the code in ISE and see what it makes of it, but I'm afraid it's going to be an unreadable maze of wires.

Here's a very quick block diagram of the datapath so far.

A, X, Y, S, M, ABH, ABL, PCH, PCL (and IR, not indicated) are all 8 bit registers.