Final design, generic version, still has around 60 slices (there's some random variation in each run). Connected to single block RAM, it meets 8 ns constraint out of the box, and 7 ns with SmartExplorer pushing.

The Spartan-6 version has 120 LUTs, around 50 slices when synthesized without any placement constraints, and around 6.6 ns with SmartExplorer. I tried hand placement of a couple of things, but that only made things worse. I'll have to test some more with that, but I doubt there is much improvement possible.

Longest path in nearly all cases is microcode ROM->register file->ALU adder->ALU shifter->DB out mux->RAM. Nothing fancy, really, and nothing that suggests any possible improvement. In earlier timing runs that I did, the output mux may have been optimized away, so I got some slightly better results.

Off to a very good start! I'll watch this with interest.

Strange. After adding support for I and D flags, including CLI/SEI/CLD/SED, the slice count dropped to 55.

Adding support for CLV, and overflow detection in the ALU, kept it at 55.

A cute feature when running the simulator is that it will print the 3-letter name of the opcode that it is working on. That makes it easier to track with the assembly code of test programs.

This is great!

Will this be possible to get running on other FPGA architectures, or will it be completely tied to Spartan 6 & 7?

The goal is to make it generic so that it can be targeted for any architecture, but with the structure of the FPGA in mind. For instance, each little combinatorial block is made so that it fits in 6-input LUTs. It will still work on an older 4-input LUT, but it won't be so efficient.

If I need 7+ inputs, I try everything I can to push some of the logic somewhere else. Likewise, when I need less than 6, I try to add some functionality. That's the reason I ended up with a block RAM, because I could not figure out a (good) way to do the instruction decoding with only 6 inputs (especially not with the irregular 65C02 extensions thrown in).

When the generic model is ready, I want to try to hand optimize for Spartan, by providing an alternative implementation of some of the modules (that's the main reason for the current, small, modules, such as the ALU, ABL, and ABH), so you can simply remove the generic version of the model, and replace it with the Spartan-6 specific. Somebody else may be able to provide targeted code for other FPGAs.

For example, the adder/logic block in the ALU should fit in a single LUT per bit on Spartan 6/7, using 2 inputs for the R/M inputs, and 3 for the operation select bits. When using the carry chain logic, you need two signals (Generate and Propagate). The Spartan 6 can split the LUT6 into a pair of LUT5s to generate those two signals, as long as you restrict yourself to total of 5 inputs.

More strangeness. Adding one more flop results in now needing 52 slices.

Another example of designing with LUT6 constraints:

I had a problem with the logic for the C flag update, that required adding an extra input to the mux. The LUT had a free input, but I had already used up all the possible cases for the select signals:



But then I realized that the CLC/SEC options are not necessary. Instead, I can use the microcode to instruct the ALU to calculate 00+00+0 for CLC, or 00+FF+1 for SEC, and then combine the first 3 cases by grabbing ALU carry out.

All NMOS 6502 opcodes have been added, as well as overflow flag handling. Plenty of room left in the microcode ROM.

Next step is running Klaus Dormann's test suite (without BCD), and see what's still broken/missing.

Update: test suite revealed a couple of errors, mostly in the flag handling. Bugs have been fixed, and it now passes the test (BCD tests still disabled).

Reset handler has been added as well. Whenever reset is detected, control is transferred to dedicated microcode address. As soon as reset is released, microcode is executed which copies the reset vector to the address bus. Only a single cycle reset pulse is needed.

I've added support for IRQ.

One small quirk is that the SEI/CLI instructions have 1 cycle pipeline delay to setting/clearing the I flag. The effect is that SEI instruction, immediately followed by IRQ on the next cycle will allow the IRQ to be taken. However, the SEI is not lost. The I flag will be set on the stack, so it will return from the interrupt handler with further interrupts disabled.

I don't think this should impact any real world code. Had the IRQ arrived one cycle earlier, it would be taken anyway. The only difference is that the interrupt handler may be surprised to find I=1 in the saved status register.

I'm just going to leave it like this for now.

Probably true, but perhaps worth checking that CLI; SEI will catch a pending interrupt.

I did check that, and it works. Both CLI and SEI have the same behavior, so that leaves a single cycle opportunity for IRQ to be taken.

The 'I' at the left means interrupt is pending. The 'I' near the right reflects the flag bit. In cycle 7 the I flag is cleared, and in cycle 9, it starts pushing the PC to the stack.

Edit: SYNC:1 means it's starting a new instruction decode. During the IRQ handling it shows IR=ea (NOP), but that's not valid, because the IRQ handling is done in microcode. The instruction shown is the next one in the stream. There's not even a real IR. That register only exists in simulation for debugging.

Slice count still about the same. It moves up and down a bit doing re-synthesis, probably because the tools are not deterministic.

I took a quick look at the timing output. It's showing about 15 ns delay, but most of that appears to be routing/fanout. I'm not going to worry about timing right now. The synthesis is running with 'optimize for area' settings.

I think that with manual instantiation/placement, both area and speed should improve at the same time.

Congrats on the progress, Arlet! Following this project with interest.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Nice progress.


Reminds me to HuC6280: "a change in the interrupt flag with SEI/CLI will only prevent/allow interrupts AFTER the next instruction is executed"

Pfff... just spent hours trying to get the code to run on real hardware. Turned out I had copied all my verilog sources to the ISE directory, but not the microcode ROM hex file. And because I changed the format, the old code was no longer functional.

It looks like it's finally working now. I can see the expected signals on the address bus. Now, let's see if I can write some code to blink an LED.