P2 Simulator

I've updated spinsim with the information contained in the July 14 P2 document that Chip posted. This version of spinsim supports most of the P2 instructions that match instructions in the P1. Most of the new non-P1 P2 instructions are not supported yet, but I will implement them as more information becomes available about them.
In addition to spinsim, the attached zipfile contains a utility called qasm that converts PASM instructions to DAT LONG values. The resulting file can then be compiled by an existing P1 compiler, such as the Prop Tool or BST. The zipfile also contains a P2 version of the pfth Forth interpreter. Windows executables of spinsim and qasm are included. Executables for other platforms need to be built from the source files. Read the readme.txt files for more information.
In addition to spinsim, the attached zipfile contains a utility called qasm that converts PASM instructions to DAT LONG values. The resulting file can then be compiled by an existing P1 compiler, such as the Prop Tool or BST. The zipfile also contains a P2 version of the pfth Forth interpreter. Windows executables of spinsim and qasm are included. Executables for other platforms need to be built from the source files. Read the readme.txt files for more information.
Comments
I'll need to grab it and build it.
Thanks!
setbyts movbyts msgin msgout xzero xinit xcont qfrac qvector qrotate clkset setdacs setxfrq getxcos getxsin sethlk setbrk setcy setci setcq setcfrq setcmod
This version will run binary files produced by the PNut assembler, which is included with Chip's FPGA updates. You can generate a binary file under PNut without being attached to an FPGA board by typing Ctrl-M to switch to the list view, and then typing Ctrl-M again to return back to the editor mode.
As in previous releases, a Windows executable for spinsim is included. Executables for other platforms need to be built using the makefile. Read the readme.txt file for more information.
This is cool!
One question (so far), in the example below, I assume the first group of numbers is the CNT value, should that reset with a REBOOT command? I'm not sure how the hardware actually operates...it may only zero out when power is applied but I thought a reset would go back to 0.
Cog 0: 00000021 0003 f467f603 setb 1fb, #003, cram[1fb] = f Cog 0: 00000022 0004 fd60381a F getct 01c, 01a Cog 0: 00000023 0004 fd60381a getct 01c, 01a, cram[1c] = 23 Cog 0: 00000024 0005 fa803819 F addct1 01c, 019 DEBUG> reboot Cog 0: 00000025 0000 00000000 F nop 000, 000 Cog 0: 00000026 0000 00000000 I nop 000, 000 Cog 0: 00000027 0000 f467f600 F setb 1fb, #000 Cog 0: 00000028 0000 f467f600 setb 1fb, #000, cram[1fb] = 1 DEBUG>
Now all we need is some simulated LEDs!
Thanks for sharing this...it should provide much distraction and aid!
BTW not sure if MOVBYTS and SETBYTS are missing because of lack of docs but here's a quick outline.
SETBYTS simply copues the lower 8 bits of the S reg into all the byte positions of the Dreg.
MOVBYTS copies the bytes in D reg in the order specified in the S reg.
for example
movbyts reg1,#%%0123
does a endian swap of the bytes in reg1.Hope this helps.
Cheers
Brian
Did you follow any particular reference for understanding the instructions?
The opcode list is really overwhelming. I'm sure there is a "fun subset" hiding there somewhere.
Not having a simple reference is a great barrier to me. I like Rick's google doc - maybe that can be expanded.
Forgive me, but I abandoned the intravenous information forum feeding habit long ago (withdrawl was worse than quitting cigarettes and coffee), and haven't even tried to keep up. Hopefully I can remain distant enough so that this thing doesn't consume me again. I did go back to coffee, but I'll never smoke again.
Your work always piques my interest, and I have applications in mind for the new chip, so I need to be in touch with it a little. I just wish Chip's infinite tinkering would stop.
@ozpropdev, thanks for the information on MOVBYTS and SETBYTS. I'll implement them when I have a chance.
@jazzed, I used the instructions_xx.txt document that Chip includes with his FPGA updates, and also the Google docs document that he maintains. I also used Rick's google doc. However, for some of the instructions I had to resort to searching the P2 forum and study example code.
EDIT: There are also several instructions where I just used my best guess at how they work. Some of the cordic instructions are implemented using C functions, such as log and exp. I currently don't simulate the cordic pipeline.
Steve!
We are almost there. The only plans I have left are to see about putting the pixel mixer instructions from P2-Hot in, and then getting the smartpin designed. Neither is too complex.
A lot of the tinkering comes from using what we've already got and discovering hitch-ups in the git-along that need releasing.
We're very close, anyway.
- Fixed a problem with the "-l" option in the P1 mode
- Added support for the SETBYTS and MOVBYTS instructions
- Added support for the QROTATE, QFRACT and QVECTOR instructions
- Added wait logic for the GETQX and GETQY instructions
- Implemented the SETHLK instruction and the associated code for handling LOCK interrupts
- Fixed a problem with the "JMP S" instruction
- Fixed several problems with the PTRA/PTRB logic.
Fixed the REP instruction
Fixed multi-long RDLONG and WRLONG preceded by a SETQ in the hubexec mode
Fixed the ALTS, ALTD, ALTR and ALTI instructions
Fixed the "PAR" value passed by COGINIT when preceded with a SETQ
Fixed the CALLD instruction when calling from cog memory to cog memory
How up-to-date is spinsim ? I'm not really interesting (at this point) in smart pins and such, but more on the normal opcodes for arithmetic and memory access...
I've added support for a few instructions, and also fixed several instructions that weren't quite right. I haven't added SKIP, SKIPF, etc. Those will be in the next update.
I modified conion.c so that it should work with the Mac now. I'd appreciate if someone with a Mac could try building spinsim, and then try running it in the debug mode. You can run one of the test programs in the verify directory as follows:
./spinsim -b -t -d verify/testops.bin
This will start up in the debug mode. Type "help" to see all the commands. Type "step" to step one cycle. You can then just press enter to repeat the step command. Type "stepx" to step to each executed instruction, and type "run" to run continuously. You can then type Control-] ("ctrl" and "]" keys together) to break out and return to the debugger. Hopefully, this will work on a Mac now.
So the only instructions that haven't been implemented are the ones related to Smartpins and a few others. Specifically, the remaining unimplemented instructions are xzero, xinit, xcont, clkset, setdacs, setxfrq, getxcos, getxsin, setbrk, setcy, setci, setcq, setcfrq, setcmod, getrnd and xoro32.
after a long break I started again,
to deal with the propeller.
Dave Hein's spinsim has excited me to simulate the periphery.
Currently I have only the counter in NCO mode.
I have modified the file spinsim.c only.
All changes I have marked with //myr.
As a test I used the binary,
which is a very simple IQ modulator.
Compiled with SimpleIDE in Cog - mode.
/** * This is the main TwoPhase90Degree program file. * produce 2 signals with 90 Degree Phase difference */ #include "propeller.h" #define phase1 16 #define phase2 17 #define pin 1 #define f 10000 int main () { DIRA |= 1<<phase1; DIRA |= 1<<phase2; DIRA |= 1<<pin; PHSA = -0x41EB00; PHSB = 0x40000000; FRQA = 54 * f; // for 80MHz Clock FRQB = FRQA; CTRA = (4<<26) + phase1; // NCO 0 degree CTRB = (4<<26) + (phase2<<9); // NCO 90 degree while(1) { OUTA = OUTA ^ pin; } }
I have simulated 5000 loops (log.txt)One looks beautiful as in the background the hardware works,
while a software loop runs in the foreground.
Cog 0: 2156 02b a0bfe807 mov 1f4, 007 R=00000000 CNT: 0x86C DIRA: 0x30002 OUTA: 0x20000 BPIN RISING EDGE FRQA: 0x83D60 CTRA: 0x10000010 PHSA: 0x401D9300 DIRB: 0x0 OUTB: 0x0 FRQB: 0x83D60 CTRB: 0x10002200 PHSB: 0x801D9300 PHSB - PHSA: 0x40000000 ===================================================== . . . Cog 0: 4144 02c 5c7c0029 jmp 000, #029 CNT: 0x1030 DIRA: 0x30002 OUTA: 0x30000 APIN RISING EDGE FRQA: 0x83D60 CTRA: 0x10000010 PHSA: 0x801A3080 DIRB: 0x0 OUTB: 0x0 FRQB: 0x83D60 CTRB: 0x10002200 PHSB: 0xC01A3080 PHSB - PHSA: 0x40000000 ===================================================== . . . Cog 0: 6132 029 a0bc0ff4 mov 007, 1f4 R=00030000 CNT: 0x17F4 DIRA: 0x30002 OUTA: 0x10000 BPIN FALLING EDGE FRQA: 0x83D60 CTRA: 0x10000010 PHSA: 0xC016CE00 DIRB: 0x0 OUTB: 0x0 FRQB: 0x83D60 CTRB: 0x10002200 PHSB: 0x16CE00 PHSB - PHSA: 0x40000000 ===================================================== . . . Cog 0: 8120 02a 6cfc0e01 xor 007, #001 R=00010001 CNT: 0x1FB8 DIRA: 0x30002 OUTA: 0x0 APIN FALLING EDGE FRQA: 0x83D60 CTRA: 0x10000010 PHSA: 0x136B80 DIRB: 0x0 OUTB: 0x0 FRQB: 0x83D60 CTRB: 0x10002200 PHSB: 0x40136B80 PHSB - PHSA: 0x40000000 =====================================================
In this version P1 mode is expected.
I've missunderstand the meaning from APIN/BPIN.
Now I have a test.c which run correct on QuickStartBoard
and a improved spinsim.c .
spinsim -v8 -Y test.binary
I wrote spinsim in 2010 so that I could run Spin programs on a PC. It interprets Spin bytecodes and provides some debug information. There are Spin objects included that work like FullDuplexSerial and FSRW that interface with the PC. A month or so after the initial release I added a mode that interprets P1 opcodes directly. In 2011 I added support for the P2 as part of the PropGCC project. I update it a few times a year to keep up with the latest changes in the P2.