Independent 16 bit memories are needed (with byte write controls) but dual port is also needed to achieve the cycle times listed. If the stack and zp data was never needed external to the cpu then just the absolute accesses could be degraded to share the 32 bit instruction bus. Accessing stack/ZP through absolute addressing would also have to be altered.

After staring at my state machine for a while I think this could be done without a loss of cycle times provided stack and zp never need to go to external memory also. There is an inherent dead cycle when accessing memory operands because of the pipeline delay that could be used to start a new instruction load instead of using the execute state during an absolute access instruction. I already do this for the indirect accesses. I have a Spartan 3 board with 2 external 16 bit rams that I based my initial design on many years ago, I will look into using that. It will not run as fast and I am not sure there is enough logic to handle the internal stack/zp memories though...

Sounds like an interesting thing to look into, though: on-chip RAM is in very short supply, so a simpler and cheaper external memory system is desirable. If it's a memory system already available on a dev board, even better.
(A dev board will presumably share the address lines for the two 16bit wide RAMs, which might not be general enough for this purpose?)
Cheers
Ed

Are you just referring to main memory or also the stack/zp cache?

If there is not enough fpga resources for this cache this processor design is probably not going to work anyway.

If the main concern is getting rid of the dual porting of main memory then under these conditions it could be made to work without excessive increases in instruction cycle times...

1) The external rams will still need their own address busses. My old Spartan 3 development board happened to have this feature.

2) External memory writes of stack and zp memory are not required.

3) No code execution out of the stack or zp memory is required.

4) Any absolute type operand write or read that accesses stack or zp memory will automatically have zp cycle instruction counts. (yes, even stack memory accesses!)

5) Absolute type writes (sta_a,stx_a,sty_a,sta_ax,sta_ay) will have to become 2 cycle instructions. If cycle consistency is not of a concern then they could be conditional made 2 cycle instructions depending on how full the instruction queue currently is. Consecutive absolute stores drain the 12 byte register quickly.

6) Another signal into the cpu will have to be added to indicate whether to take the operand read data from the 32 bit bus or the 8 bit read bus. I think it would still be useful to have the 8 bit read bus for peripheral reads so the main memory bus can be kept as clean as possible.


If you are interested in this design I would be willing to put some effort into making it. It basically changes my cpu from a Harvard type to a Von-Neumann type architecture without too much loss of throughput.

Sorry, I may have misunderstood. From this statement:

I took you to be saying that all the system memory would need to be dual-ported. But if the idea is to have an on-chip cache, and this cache must be dual-ported, and then external memory is just conventional memory, I was headed in the wrong direction.

(If all the system memory did have to be dual-ported, that's easy and natural on-chip, but the on-chip memory is limited (less than 64k for many of the cheaper FPGAs), and so I was wondering how to implement an adequate memory off-chip, without needing to make it dual-ported.)

Does that make sense?

Ed

I think you had it right, I just was not as clear in my description as I could have been...

In the current implementation both external ram/rom and internal cache (512 bytes) are both dual ported.
The external is dual ported so that I can simultaneously read an instruction and read or write an operand.
The internal dual port allows a multi byte read of an stacked return address or zp indirect address along with a simple byte read or write.

If the external ram/rom is not dual ported then the previous message would require only 5 instructions to potentially slow down. But there is a caveat, the internal cache is no longer a cache but is part of main memory - the external 512 bytes would never be written. If this is not acceptable then a few more instructions would have to be slowed down in order to do all accesses required through the current instruction bus.

In either case the separate address busses would still be needed for the 16 bit external memories unless slowdowns of even a few more instructions are acceptable.

I hope this clears things up, if it does not I can give you a listing of the state machine states for each instruction/event that shows what address is put on the 2 respective busses. There needs to be at least one instruction fetch per instruction to keep the process going.

Thanks for explaining. I don't see that confining page 0 and 1 to on-chip RAM should be any problem.

And, would you still have enough resourses for some cache too?

There really is no other cache unless you want to count the 12 byte instruction register. This is more like a shift register that shifts to the next instruction while shifting in new instruction fetches as there becomes room. When ever there is a branch or jmp or interrupt it gets cleared and starts reloading for the new instruction path.

If I may ask a n00bish question, besides things that have to do with the individual bytes and stuff, whats the difference between having it all be 8 or 32? Can you not just change the registers and bus from 8 to 32 and fix anything else broken (other stuff on the bus?) and have it work beautifully? I assume that certain instructions would have to be done differently in the hardware but that isn't really the point? Because if you want to do stuff on a chip such as a 6502 but you need more than 8 bits you would have to use multiple memory addresses which would be slower than having a 32 bit one yes? Sorry for n00b questions

For a 6502 that is pretty much all things. If you want to do 32 bit arithmetic inside the cpu instead of 8 you could do that but there would not be much existing code that would work also. Immediate instructions would have to be 5 bytes instead of two. Four byte operand values would have to be loaded/stored from/to memory and if they are allowed to be unaligned in memory that would slow down the instruction execution.

This thread's name referring to 32 bits was not referring to operand (register) size at all. I believe the original author of this thread was only referring to the memory interface. By using a 32 bit interface you can load possibly 4 instruction bytes at a time and not just one. This reduces the number of total memory cycles needed to execute a instruction making the cpu run faster for its standard instructions.

If you change the operand size you are pretty much talking about a whole new processor. Hope this answers you inquiry.

I have a von Neumann version of my cpu working (no dual ported memory required). I have only run it on my Spartan 6 with only 1 port of the Bram hooked up. I have been unable to test it with the external rams because I cannot get the video to work correctly on the Spartan 3 development board I have. I have spent the last 4 days on that, I think I will give up on that. I did make a change to the zp/stack 'cache' to accommodate the Spartan 3 and it seems to have given me another 6MHz in fmax on the Spartan 6. It has not ever failed a timing constraint at 91MHz (unless I have built it with optional debug stuff on).

These instructions go from 1 to 2 clocks...
parameter STY_A = 8'h8C; // 3 / 2
parameter STA_A = 8'h8D; // 3 / 2
parameter STX_A = 8'h8E; // 3 / 2
parameter STA_AX = 8'h9D; // 3 / 2
parameter STA_AY = 8'h99; // 3 / 2
parameter STY_Z = 8'h84; // 3 / 2
parameter STA_Z = 8'h85; // 3 / 2
parameter STX_Z = 8'h86; // 3 / 2
parameter STY_ZX = 8'h94; // 3 / 2
parameter STA_ZX = 8'h95; // 3 / 2
parameter STX_ZY = 8'h96; // 3 / 2

In the case that the resulting address is in zp or the stack page these will go from 2 to 3 cycles just like if it were in external ram...
parameter ASL_A = 8'h0E; // 6 / 3
parameter ROL_A = 8'h2E; // 6 / 3
parameter LSR_A = 8'h4E; // 6 / 3
parameter ROR_A = 8'h6E; // 6 / 3
parameter DEC_A = 8'hCE; // 6 / 3
parameter INC_A = 8'hEE; // 6 / 3
parameter ASL_AX = 8'h1E; // 7 / 3
parameter ROL_AX = 8'h3E; // 7 / 3
parameter LSR_AX = 8'h5E; // 7 / 3
parameter ROR_AX = 8'h7E; // 7 / 3
parameter DEC_AX = 8'hDE; // 7 / 3
parameter INC_AX = 8'hFE; // 7 / 3

All other instructions take the same number of cycles as the Harvard architecture. Only the first five have to be different if not executing code or using jump vectors in zp/stack.
The only OS I have is the C64 and it does both so I had to have it this way to test booting of the altered cpu. One thing to note is that stacking operations are NOT written to external memory. If anyone is interested in the Verilog code I will provide it.

It's always good to be able to reference someone else's code!

I'd like to check it out.

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

I included some other files to show how the memory interfacing and debug stuff was done...

Feedback on my code is appreciated, I do not program in this language for a living...

I would also be interested in knowing if anyone is able to implement this in their own system.
Remember to register the addresses and data write before use (just like a Bram) if using asynchronous memories.

Oh wow, you're working on a Commodore 64 project!

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