I'm sure you're right - verification comes after code complete, for this. I don't think this kind of task is a terribly good fit for test-driven design.

The sync/async RAM question comes up all the time - the usual approach is to build a core for traditional async RAM, and then find you need to do something like double-clock the on-chip sync RAM. That can cause something like a 2x clock speed penalty (which of course isn't important if your intent is a 2MHz core, but more important if you wanted to hit 100MHz.)

The other approach is the one Arlet took: design the core for sync RAM in the first place, which is possibly a little more of a brain-teaser. Then, to connect it to off-chip SRAM, you just need a shim which registers the core's outputs on the regular clock. This way, you get the fastest core and it's readily adaptable for both situations.

(At least, that's my understanding... I also think it mightn't be too difficult to take the usual kind of core and rejig it to produce unregistered outputs which are just prior to the clock, such that it now works with clocked memory. But this might depend on the way it's coded.)

Not necessarily test-driven - but writing the verification as you implement each instruction seems to me to be a good approach. But that's just my opinion and I could be wrong.



Yeah, I had seen this on the forums elsewhere and once you get started, it's a pretty important first question to ask.



I took a similar approach, although I think mine is a bit different - I'm clocking the BRAM at 10X and then just pipelining everything to get cycle accuracy. Since the fastest any instruction can be executed is two clock cycles, this seems to be feasible - also, after reading through the 65816 manual that Garth recommended, I realized that implementing the 65C02 / MOS 6502 modes shouldn't be that difficult, so I'm going to target that. This is a lot of fun and I'm looking forward to getting further into the implementation. Running some test ROMs should be a hoot.

Yes, I can see that. Except, it's not exactly every instruction: if your code is suitable factored, then you might be testing say addition or subtraction, or testing say indexed indirect addressing, or testing the various read-modify-write instructions. Testing features, I suppose you could say. There are fewer features than instructions.

Perhaps at the end you'd need to do something more comprehensive, in case you'd given an opcode the wrong addressing mode, or assumed a little too much generality (like, for example, TXS, which unlike the other transfer instructions, doesn't affect the flags.)

But even then, if say you'd already tested the page-crossing behaviour for some addressing mode, you wouldn't need to check that behaviour in every instruction which used that mode.

I've incorporated the ALU into my design and wrote a simple ROM to reset, do NOP, clear out the accumulator and start counting by 1. Now that I look at it, I think there is a bug in the ALU not clearing the zero bit in the status register. It took me a bit to figure out how to pipeline data through the ALU, but looks like it's working. I don't think that implementing the rest shouldn't take too long now.

Check this:

https://github.com/ogamespec/breaks/blo ... MOS_6502.v

_________________
6502 addict