Software emulation of the P2

Seairth

I have been quietly working on a software emulation of the P2 (hence the occasional question about the internal working of the chip). I want for three reasons (and then some):

1. I want to be able to debug code, but the P2 doesn't have an in-circuit debugger.
2. I want to have a better understanding of the way the chip works, including all of its caveats.
3. I want to play with the P2, but don't have the funds to get the FPGA.

I actually started off with excellent prior work done in this area, namely with Gear. However, that didn't really help me achieve my second goal, and working some of the new functionality looked a bit daunting. So I have started from scratch. While it would be great to write a perfect emulator, I realize that there are a number of features that would be difficult to implement without considerable effort (e.g. pin I/O, accurate clock timing, etc.). So my first version will only address the following features:

• Up to 8 cogs running simultaneously
• Full instruction set (I/O will likely be static data from/to files)
• 4-stage pipeline (probably not implemented like the actual hardware, but it will hopefully be logically correct)
• Each clock cycle will take as long as it needs, so each cycle may take different amounts of time
• Written in C# for fast prototyping (yes, I love a lot of other languages that would be good for their own reasons, but this is what I chose for now)

And here we go!

Seairth

So the 4-stage pipeline, based on Chip's short description of the stages, has been fairly easy to implement. Well, up until recently. There are a few instructions that use the R bit as the I bit when indicating immediate addressing (and to complicate it, the address is in the D field, not the S field). This means that the instruction must be decoded in either the first or second stage. But the instruction won't actually be executed until the fourth stage. So, that means that the decoded instruction (which is made up of the INST field, sometimes one or two of the bit fields, sometimes the D field, and sometimes the S field), has to pass along in some meaningful way to the fourth stage. So, how is it done? My current thought is to simply map each of the "complex" instruction bit patterns into a "simple" indexed value (since the actual number of instructions is fairly small).

But if anyone has a better approach, I'd certainly like to hear it.

Dr_Acula

What a cool project - keep us posted, this sounds really interesting!

Cluso99

Seairth: Sounds like a very interesting project.

There are over 300 instructions when you add all those 000011 opcodes and the few other opcodes that are duplicated when the zcri bits are used. I mapped these instructions and posted them in the docs thread recently because I needed this info to decode the instructions in my P2 debugger. You may find some of this info of use to you.

Certainly a 'super' bit decodes could work, together with the instructions to form a jump/decode table where you can execute each particular instruction or group of instructions. A PC certainly could do this, and if you wanted to perform cycle accurate coding, then each instruction could have a set of trailing nops.

Reinhard

Seairth, this is a very cool project.

Maybe you know about this:

http://propeller.wikispaces.com/pPropellerSim

Can be a good template to start.

Please let us know more about ;-)