Is there a testbench for opcodes ( instruction set exersizer) ?
Ale
Posts: 2,363
Hello all,
I am looking for a testbench, piece of code, instruction set exersizer for the propeller 1. The propeller manual has some examples for the different alu opcodes, but getting the info out of the manual means lots of copy, paste and conversion... I'd like some frendlier format...
I know that I did some tests a couple of years back as I did my propeller assembler/simulator... I could use that and hack a script together...
any ideas ?
I am looking for a testbench, piece of code, instruction set exersizer for the propeller 1. The propeller manual has some examples for the different alu opcodes, but getting the info out of the manual means lots of copy, paste and conversion... I'd like some frendlier format...
I know that I did some tests a couple of years back as I did my propeller assembler/simulator... I could use that and hack a script together...
any ideas ?
Comments
Are you looking to execute an arbitrary instruction with arbitrary parameters, and check the results?
The propforth build automation does specific instructions, and logs the results, and allows us to compare the current results with previous results.
For the most part, if the code succeeds in building the same identical kernel, it must work, so we don't need to check each instruction as part of the regular build automation.
But you could easily use the same tool, and create a new test to exercise each instruction to any extent desired, run it automaticaly, and automatically check the results for differences (using your own code on the workstation etc)
Unfortunately its in forth, the tests must be written as interactive execution (which follows what you would do in test development anyway), and then you have to deal with scripting which is not so bad.
I'd have a look at propforth later, maybe I can modify it for my needs. Thanks !
OpenSpin, PropGCC GAS and other have to generate binary parts for instructions. I've been tempted to look in those to see how they actually generates an instruction opcode from a mnemonic but I haven't looked yet. They must have some sort of lookup table for the 7 bit opcode and then generate the remaining bits as needed depending on the instruction.
For the P2, I've been tempted to take the relevant parts of Chip .txt file and then run a <insert favorite scripting language here> program against it to break out the opcodes and mnemonics...oince the dust settles down. You could do the same thing with the relevant part of the P1 .pdf but it would be nice to find a usable table some place.
Edit: OK, now that I see what you are looking for, you can probably ignore most of the above post.
What are you actually wanting to test? A simulator of FPGA implementation?
There is an instruction set exerciser for the Z80 that I use to verify the ZiCog Z80 emulator which uses a cunning technique you might want to think about.
Basically what it does is to write an instruction into a buffer and then jump to that buffer to execute it. Also in that buffer is any data the instruction should operate on and space for it to write results. Now you calculate a CRC of the results. Do this for all your instructions and preferably with lots different test data for each, zero, maximum int, positive, negative etc.
Run such a program on a real device and record the results. Now run the same program on you simulator and compare the results. In the case of the Z80 instruction exerciser the check sums are incorporated into the program so it can check as it runs.
The neat thing here is that it actually accumulates CRCs over many test cases. You only need to log one CRC for each instruction, say. In this way the amount of data you need to log is vastly smaller and can ultimately end up in the program itself.
This at least tells you how well the simulator matches a real device. It does not tell you what is wrong when in instruction fails. Then you have to do a bit more work.
http://forums.parallax.com/showthread.php/153208-PASM-Single-Line-SImulation
C.W.
I believe my test code used a script that specified an instruction along with the initial conditions of the zero and carry flags, and the initial value of the cog memory location that is used. The tester would execute the instruction and then print out the values of the flags and the memory location. I ran the tester on the hardware and under spinsim, and I compared the outputs to make sure the matched.
The script file may take a little bit of work. There are 64+ instructions, and each instruction would have 4 or 5 tests for typical and boundary conditions. That's only about 300 lines in the script file.
For instance, the manual doesn't say what happens when the shift amount is zero (for ROR)... I would guess that the C flag is loaded with bit 0. I'll have to test in a real prop .
Here is the script:
Here is how the testbench looks like:
and here the results, just ROR and a bit of ROL
$FFFF_FFFD + $0000_0003 = $0000_0000 z = 1, c = 1
$FFFF_FFFD + $FFFF_FFFD = $0000_0000 z = 1, c = 0 // It should be 1...
I also noticed (again, most probably) that RCR and RCL do not work like in the 6809 or z80... the carry is shifted in so many times as bits are specified in s,
Tricks and traps
I haven't check all the opcodes yet, I'm at CMP. I look at the manual and at the results... more comprehensive will be when I write some code...something like what Heater said, a simple Spin server with serial io and a small PASM routine that does the required test... I have a suitable board with me.... now to see which version of BST works in Mavericks.... None . BST does not work ...
Let's get PropTool... then...
At some point I'll have to do the same exercise to compare my P2 simulator with the P2 FPGA emulator. Thanks for starting this thread and posting your work.
EDIT: I attached a zip file that contains the Spin program I wrote. testbench.c is the source for the Spin file, which I converted using cspin 0.68. The program starts a PASM cog that runs an instruction given the initial values, and returns the results.
I seem not to see how to implement ADDABS correctly, I mean the C flag behaviour. According to the manual:
0xFFFF_FFFD + 3 = 0 + Carry set
0xFFFF_FFFD + (-3) = 0 and carry clear !
The manual says: The C flag is set (1) if the summation resulted in an unsigned carry...
And for MOVS, MOVI and MOVD, the C flag is not specified at all... it looks like this odd parity on S... sometimes
The manual says (page 256, v1.2)
Note 3: ADDABS C out: If S is negative, C = the inverse of unsigned borrow (for D-S).
Note 4: SUBABS C out: If S is negative, C = the inverse of unsigned carry (for D+S).
If we take the carry from ADDABS for positive S and the borrow from SUB for negative S, without inverting it, we get what is displayed in the table for ADDABS.
For SUBABS the carry can be the ADD carry for negative numbers and the borrow from SUBABS.
any thoughts ?
I will edit it for clarity..
Now, NEGxx.
According to the manual NEGNC is opcode 0x101101 = 45d and when tested using Davi'd code I get the following..
If we look at the result they change with Z instead of with C... and NEGZ (0x101110, 46d) seems to have the same behaviour but changes with C instead of with Z:
It seems NEGNC & NEGZ have the wrong encoding...