P2 Simulator
Dave Hein
Posts: 6,347
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.
zip
272K
Comments
I'll need to grab it and build it.
Thanks!
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.
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 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.
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.