P2 Instruction Verification

Dave Hein · 2018-10-12 02:58

A while ago I wrote some programs that I use to verify that the instructions that I implemented in spinsim match the FPGA. Since I don't have a P2 yet, I was hoping that Chip, Peter or someone else that has a P2 could run the programs on their P2. The attached zipfile contains the program source in C along with P2 executable binary files and the text output from the FPGA. It also contains loadp2.exe, which is a Windows command-line program that loads binary files to the P2. I also include the loadp2_src directory that contains the source for loadp2 so it can be built for other platforms, such as Mac, Linux or Cygwin.

A program is loaded as follows:

loadp2 -t -f 80000000 -m ff -b 115200 testopsa.bin

The -t option causes the terminal emulator to run, -f sets the system clock frequency, -m sets the clock mode, and -b sets the baud rate. If the clock rate is changed from 80MHz the baud rate should be changed proportionately. For 160MHz the baud rate should be 230400.

Could someone please run the 5 binary files and save the outputs to text files, and then post the resulting output files. The output is saved by redirecting the output to a file. I watch the serial activity LED on the PropPlug to determine when the program is complete, and then hit the ESCAPE key to exit loadp2.

KeithE · 2018-10-12 03:28

If Parallax were willing, they (or someone that they trust with RTL) could produce a C++ model from the P2 Verilog using Verilator.

Here's an example:

https://zipcpu.com/zipcpu/2017/07/26/cpu-sim-debugger.html

cgracey · 2018-10-12 10:10

Dave, I've got it spitting out all kinds of text, but how do I direct that text into a file? It's more than I can copy from the command prompt window.

Thanks for making these tests!!!!

evanh · 2018-10-12 11:14

I'm guessing

loadp2.exe [parameters] >dump.txt

cgracey · 2018-10-12 11:49

That worked, Evanh! Thanks.

Dave, here are the dump files:

cgracey · 2018-10-12 11:51

I'm really glad you put this together, Dave. I'm anxious to see if you discover anything surprising.

Dave Hein · 2018-10-12 13:12

Chip, thanks for running the tests and posting the output files. Four out of the Five test programs match exactly. The only one that doesn't match is testopsa. This program tests all of the ALT instructions. Every ALT instruction fails except for ALTI. I believe you already mentioned that there was a problem with the ALT instructions. The attached zipfile contains a cleaned up version of testopsa.dump, and the file testopsa.diff, which is the result of running "diff testhdwa.txt testopsa.dump >testopsa.diff".

cgracey · 2018-10-12 13:24

Yes, I thought of mentioning that, but was hoping your test would show it, so that is great!

The ALTx instructions which try to add a negatve number to D don't work, because S[17:9] doesn't get sign-extended, as it should.

That is fantastic that everything else seems to be okay. I am really relieved that you got such a test together. Now I have confidence and a lot of little things I haven't had time to check, exactly. Everything is looking pretty good, so far.

I've had a few instances where I thought I ruined the chip, but it was just my setup and programming issues. The chip is still running just fine.

cgracey · 2018-10-12 13:31

Thanks for putting up that result file. I will look at it when I'm back on the computer.

__red__ · 2018-10-12 23:38

Oh, that's pretty cool @"Dave Hein"

I ran it in spinsim with -p and I saw output. When I tried to run it with verbosity or have it list executed instructions I see vast numbers of waitx 7

What am I missing?

cgracey · 2018-10-12 23:52

Dave Hein wrote: »

Chip, thanks for running the tests and posting the output files. Four out of the Five test programs match exactly. The only one that doesn't match is testopsa. This program tests all of the ALT instructions. Every ALT instruction fails except for ALTI. I believe you already mentioned that there was a problem with the ALT instructions. The attached zipfile contains a cleaned up version of testopsa.dump, and the file testopsa.diff, which is the result of running "diff testhdwa.txt testopsa.dump >testopsa.diff".

Dave, I looked at the .diff file, but it doesn't make any sense to me.

The failure of the ALTx instructions (excepting ALTI) is that S[17:9] is not sign-extended before getting added into D. Is there any way you could verify that that is, indeed, what is causing the error?

Cluso99 · 2018-10-13 00:02

Dave,
Have run those instructions which are in P1 on the P1? It would be nice to know what instructions have different C and Z results for the tips and traps thread.

Dave Hein · 2018-10-13 00:23

It runs OK without verbosity on, but there seems to be a bug when it is on. The "waitx 7" is after a call, so the waitx is invalidated in the instruction pipeline when the call is made, and then executed after the ret instruction is executed. The call is done during hubexec, and the routine is in cog memory. The bug probably has something to do with switching from cog execution to hubexec, and executing an instruction that waits on the cycle counter. spinsim does things a little differently when verbosity is on versus when it's off.

I'll look into it.

__red__ · 2018-10-13 01:00

Thanks - not a big deal unless it is to you. What I'm trying to do is to try and get the raw PASM2.

What I should probably do is run the image through a disassembler.

btw - I tried to send you ( @"Dave Hein" ) but as I don't seem to be able to see an outbox or sent items in the forum I'm not sure if you got it or whether my browser ate it.

Dave Hein · 2018-10-13 01:54

I looked at it a bit more, and it appears that spinsim is working correctly. I was thinking that "waitx 7" should only wait 7 cycles, but that would be "waitx #7". So it's actually waiting the number of cycles in cog mem location 7. The program calls sleep(1) at the beginning, which causes it to wait 80 million cycles. Try executing the following command:

spinsim -t -v3 -80000300 testopsa.bin

This will tell spinsim to run 80 million + 300 cycles. spinsim runs about one-tenth real-time speed on my PC, so the waitx takes about 10 seconds instead of 1 second.
The p2gcc project contains a disassembler in the p2dump utility. You would run it by typing

p2dump -data -dis -hub 400 testopsa.bin

I didn't receive a PM from you. I'll send you a PM, and you should see the envelope in the upper left of the screen indicate that you have a message.

__red__ · 2018-10-13 02:37

Thanks, that helps a lot.

I think we can trust the PM functionality enough now - I wrote a much shorter version of my original PM.

Thanks,

Red

Dave Hein · 2018-12-23 23:50

I thought I would ping this thread in case anybody is using loadp2 with the P2 Eval board. loadp2 has 3 command-line options to control the frequency, mode and baud rate. The default frequency and baud rate are 80MHz and 115200 baud. The p2gcc serial driver assumes a frequency of 80MHz. If the chip is run at a higher frequency the baud rate will be proportionately higher.

I'm supposed to get my P2 board on the 28th, and I'll test out the p2gcc code at the time. I'll probably make some changes to the serial driver so the baud rate will be independent of the chip frequency.

evanh · 2018-12-24 07:13

I can't offer any testing until early Jan.

jmg · 2018-12-24 07:20

Dave Hein wrote: »

I thought I would ping this thread in case anybody is using loadp2 with the P2 Eval board. loadp2 has 3 command-line options to control the frequency, mode and baud rate. The default frequency and baud rate are 80MHz and 115200 baud. The p2gcc serial driver assumes a frequency of 80MHz...

Why does a downloader need frequency ? Is it a two stage loader, that changes the SysCLK from RCFAST ? (but then it needs to know more than just frequency)
There was a python P2 loader around somewhere too ?

avsa242 · 2018-12-24 11:51

https://forums.parallax.com/discussion/168850/python-p2-loader this one, I think?

Cheers,
Jesse

EDIT: Moved irrelevant comments to the referenced thread.

Dave Hein · 2018-12-24 12:35

jmg wrote: »

Dave Hein wrote: »

I thought I would ping this thread in case anybody is using loadp2 with the P2 Eval board. loadp2 has 3 command-line options to control the frequency, mode and baud rate. The default frequency and baud rate are 80MHz and 115200 baud. The p2gcc serial driver assumes a frequency of 80MHz...

Why does a downloader need frequency ? Is it a two stage loader, that changes the SysCLK from RCFAST ? (but then it needs to know more than just frequency)
There was a python P2 loader around somewhere too ?

Yes, loadp2 is a two stage loader. One reason I do this so that I can load into a location other than zero. Because of this, loadp2 needs to know the frequency and mode to initialize the P2. Currently, loadp2 is setup for the FPGA P2 running at 80MHz. I'll add another setup for the P2 Eval board, and there are also the custom settings using the -f and -m options.

P2 Instruction Verification

Comments