Hi all,
Is there any pipelined 6502 ? I know that 6502 use fetch stage as a pipeline way to fetch instruction, but I mean something more than that.
I'm currently working on a processor (6502) which uses 6 pipeline stages, 2 caches, and one MMU. So I want to know whether my job is suitable for the community.

Thank you.

P.S : Sorry for my bad English !

Welcome. Most of the bus cycles are used, so there's probably not much more that could be done. The 65CE02 eliminated almost all the dead bus cycles so there were 31 op codes that only took one cycle each, and others that had a dead bus cycle here and there also got those eliminated. It also added other powerful features. Unfortunately the 65CE02 is not being made today like the 65c02 and 65816 are, and it only reached 10MHz, unlike the 65c02 which is conservatively rated for 14MHz and usually tops out at 25MHz for individual processors, and over 200MHz for those that are at the heart of custom microcontrollers for dedicated purposes in industrial, automotive, and other applications. For languages other than assembly language, languages where you're constantly dealing with 16-bit quantities, the 65816 will perform much better than the '02. My '816 Forth runs two to three times as fast as my '02 Forth at a given clock speed. For the '02 however, in the programmable logic section of this forum you'll see that a few different members have done ones in FPGAs that do dozens of MHz, and a couple of the enthusiasts are (very slowly) working on 32-bit versions. Mike's 65m32 merges operands up to 24 bits with the instruction so it gets read all in one cycle.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I don't know of any (overlapped) pipelined 6502's. There was another project a while back that was very ambitious to potentially create a superscalar 6502. As Garth says the 6502 uses the bus very efficiently. The only overlapped pipelining is updating the register and flags of the previous instruction during the next instruction fetch.

I sounds like you have a handle on how to pipeline the 6502. I am curious to know more details. Is the core going to be open-source ? Do you have design specifications on the net somewhere ?
Pipelining the 6502 is tricky because of it's addressing modes and the fact that one of the operands can be a memory operand. Memory indirect modes require two memory operations which would stall the pipeline for at least a couple of cycles before the execute stage.

What kind of MMU are you planning ?

_________________
http://www.finitron.ca

Welcome, manili! As Rob says, I think you may be the first, and many of us here will be very interested to see your progress.

(Garth, I think you may have missed that the idea is to run with caches - so the CPU and caches run at some high speed, which is decoupled from the speed of the external memory system, which in turn only sees cache line loads and stores.)

GARTHWILSON, Rob Finch, BigEd thank you very much for your replies.

First thing first, I'm not an experienced processor designer or even 6502 expert. This project is my final B.S. project, so please bear with me.
The processor will be open-source for sure but I need some time to complete it.

It has 6 stages :
1. Prefetch
2. Fetch/Decode
3. Effective Address
4. Read Data
5. Execution
6. Write Back

In each cycle Prefetch unit will fetch 1-3 (depending on Decode unit request) op-codes/operands from I-Cache.
Decode unit has a 3*8 bits register and a 3*8 bits net from Prefetch unit. Each cycle it has 1-3 op-codes/operands in the register. So if an op-code need 1 or 2 operands they are already in the register. During decoding process Decode unit can tell the Prefetch unit, how many bytes has been used, so they will be filled for the next cycle.
Effective Address unit could find the real address from operands/memory it has some inputs from X register, Y register and even can talk to D-Cache to find the effective address (if we are in indirect mode addressing).
Read Data unit's job is simple, if you are using an immediate operand, it will be just a way to pass. Otherwise if the input is an address you can get the real operand from D-Cache (note that direct/indirect mode has been handled in previous stage).
Execution unit has an ALU to both calculate status register's next state and the result of operation on operands.
Write Back unit will update all registers and D-Cache with the results provided from previous stage.
MMU is just a very simple unit (still no kind of protections or TLB or ...) it uses WISHBONE methodology to talk to outside of the processor world. All I-Cache/D-Cache requests will use this unit to talk to memory or peripherals. So this is a bottleneck!

If you think the project is going to be interesting I can tell you more about it.

Thank you very much.

Yes, certainly interesting to me! Allow me to make some observations - apologies if this adds nothing:

I would recommend you use diagrams to capture and review your microarchitecture - and I would recommend you do a lot of design work before you do too much implementation work. There's no substitute for thinking ahead.

There will always be lots of possibilities for improvements or enhancements - beware of the temptation to do too much. You may well get suggestions here - many will be good ones - but if you try to do everything then you will never finish. Making a working pipelined implementation will be a major achievement, and once you reach that stage you can revisit and enhance. The more enhancements you add, the longer it will take to get it working.

In your case, doing this for your B.S., it's especially important that you do finish something - if it would have 10% more performance but is not working, that's not such a good project.

Be sure to put at least as much effort into test cases and testing as you do into the processor itself. Hopefully you are already aware of the many 6502 test suites - they will be useful, but will not be sufficient to test a pipelined implementation thoroughly.

I wish you well in this endeavour!

Thank you very much for your advices. Well the processor is already under verification (i.e. it has been coded 70% - 80%) and the pipeline is working but I'm not sure if I could make the the performance better. By-the-way I think if I couldn't make it better, maybe it's going to be a new step for other people.

I will send the diagram till tonight.

Thanks a lot.

One of the worst cases for pipelining and caching is a program which modifies the next instruction's bytes, either its opcode or operand. Do you plan on detecting and stalling in that situation, or disallowing such use?

That situation happens a fair bit in existing 6502 code, usually for dispatches and memory addressing tricks. In the standard 65xx CPUs, the writes of the prior instruction will take effect before the read of the next instruction, so it can happily trundle along without a hitch and always see the current value of the instruction bytes.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Thanks White Flame.
That was interesting . I didn't notice that. Would you like give me an assembly code example. Maybe I can plan to protect code area with the MMU. But before that I need to completely understand the problem.

Thank you very much.

P.S. AFAIK no modern processor allows you to edit the code area, how could it become possible on 6502 ?

Unless something I'm not aware of happened in the modern world, all processors that aren't pure Harvard (and most aren't) can self-modify code.

But they might need an explicit cache flush command. Or (perhaps) they might need some few cycles to elapse between writing a byte and executing it.

I can integrate I-Cache/D-Cache into a single cache to solve this problem entirely, But this sounds odd to me because if you try to do so you will get an "Access Violation" error. Even if the processor can't provide such an error the OS will do so. So I think this is the programmer's fault and it's not my processor's job to handle these kind of problems.

Note that when the OS loads a program, it must place bytes in memory and then later they will be run as code. So, it's always necessary to have some way to write memory and then execute it.

WhiteFlame observes something much stronger: in some 6502 code, the write will be very shortly before the execute.

I think I recall that when the 68000 was enhanced to make the 68010 (or perhaps the 68020) the introduction of an instruction buffer (or cache, in the second case) broke code which wrote then executed without much time between.

1. What do you think of adding an instruction to bypass the D-Cache ?
2. I still didn't understand the problem, you mean some instructions write on part of memory which is location of another instruction? So why is this important to handle because I think this is programmer's fault? But if it's vital to handle this kind of problems, would you like give me an assembly code example?
3. Do you know a good free tool to draw my microarchitecture?

Thanks a lot

Consider: if you're going to run some code from RAM, how does that code get there?

But in the 6502 case it's useful (for higher performance) sometimes to modify code within the current process too. (Not that the 6502 has an idea of different processes!) Here's a thread with examples of self-modifying code:
viewtopic.php?t=1255

Edit: another example is the BBC Micro's NMI handler: it is rewritten each time the NMI task changes, for example the NMI handler is one piece of code for disk reads and another for disk writes. For efficiency the NMI vector in ROM points directly to RAM.

Here's a thread about diagram tools:
viewtopic.php?f=1&t=3109