I'm in the process of updating spinsim, and I noticed something strange about the signx instruction. The description in the P2 instruction document says
"Trim away right bits of D by S[4:0]. D = D & ($FFFF_FFFE << S[4:0])".
That's clearly not correct. I implemented a sign extension in spinsim that copies D[S[4:0]] to all the bits to the left, and that produces that same results as the hardware. I basically did D = (D << S[4:0]) >> S[4:0], where >> is performed as an arithmetic right shift.
I'm in the process of updating spinsim, and I noticed something strange about the signx instruction. The description in the P2 instruction document says
"Trim away right bits of D by S[4:0]. D = D & ($FFFF_FFFE << S[4:0])".
That's clearly not correct. I implemented a sign extension in spinsim that copies D[S[4:0]] to all the bits to the left, and that produces that same results as the hardware. I basically did D = (D << S[4:0]) >> S[4:0], where >> is performed as an arithmetic right shift.
Sorry about that. I'll fix that in the documentation momentarily.
Thanks, Chip. That looks better. The instruction document is very useful and easy to read, and it does a good job describing how the instructions work.
I did some more testing of spinsim versus the v19 FPGA, and I found that there are several instructions in the FPGA that aren't setting the carry flag. These instructions are adds, addsx, subs, subsx, cmpsx, sumc, sumnc, sumz and sumnz. The instruction document say that these instructions are supposed to set the carry flag on signed overflows. However, the FPGA always sets the carry flag to zero for these instructions. Is this intentional? Should the document be corrected, or is the FPGA wrong?
I did some more testing of spinsim versus the v19 FPGA, and I found that there are several instructions in the FPGA that aren't setting the carry flag. These instructions are adds, addsx, subs, subsx, cmpsx, sumc, sumnc, sumz and sumnz. The instruction document say that these instructions are supposed to set the carry flag on signed overflows. However, the FPGA always sets the carry flag to zero for these instructions. Is this intentional? Should the document be corrected, or is the FPGA wrong?
It would be very unusual for any carry-in opcodes to not also carry-out, as their whole point is extended math ops ?
I did some more testing of spinsim versus the v19 FPGA, and I found that there are several instructions in the FPGA that aren't setting the carry flag. These instructions are adds, addsx, subs, subsx, cmpsx, sumc, sumnc, sumz and sumnz. The instruction document say that these instructions are supposed to set the carry flag on signed overflows. However, the FPGA always sets the carry flag to zero for these instructions. Is this intentional? Should the document be corrected, or is the FPGA wrong?
It sounds like something's wrong in the FPGA. I was working on that section of Verilog a few weeks back. I must have broken something. I will look at it now.
I ran my tests at 60 MHz also. I've attached a zip file that contains the hardware results, spinsim results and the C program that generated it. I ran the program under spinsim and on a DE2-115 FPGA loaded with v19. The two result files differ only for the opcodes I mentioned earlier, and for rolbyte, which has an error in spinsim. All of the other opcodes have matching results including the C and Z flags.
I ran my tests at 60 MHz also. I've attached a zip file that contains the hardware results, spinsim results and the C program that generated it. I ran the program under spinsim and on a DE2-115 FPGA loaded with v19. The two result files differ only for the opcodes I mentioned earlier, and for rolbyte, which has an error in spinsim. All of the other opcodes have matching results including the C and Z flags.
Thanks for checking all that stuff, Dave. I'm kind of embarrassed that I don't have a test suite to rerun often.
Hey, are you sure that CMPSX is problematic? It looks okay to me, so far. It's really like CMPX with a signed carry output, not an overflow output. Definitely, all those others you mentioned are of the same ilk.
CMPSX is probably a problem in spinsim. The source code shows that I was experimenting with an alternate formula for computing the C flag. Also, the FPGA is producing non-zero C flag values for CMPSX, so it may be correct.
CMPSX is probably a problem in spinsim. The source code shows that I was experimenting with an alternate formula for computing the C flag. Also, the FPGA is producing non-zero C flag values for CMPSX, so it may be correct.
Yeah, CMPSX seems to be working fine.
On those others, I'm stumped at the moment because it looks too simple to fail.
I found it. I was using the carry out to detect overflow, when I should have looked at the MSB of the sum. Recompiling now.
To speed this circuit up, I had made some changes a few weeks ago. I never tested these overflow-out instructions and the ROM doesn't use them, so I never saw a problem. I'm really glad someone noticed this.
I added another 50 instructions to my test program, and I now have about 120 instructions verified between spinsim and the FPGA. I did run into a problem with bmask. It seems like the description is inverted with respect to the FPGA. Probably need to add a "!" to the description.
I also looked at the C flag logic for CMPSX again. For CMPS I just use "cflag = value1 < value2". For CMPSX I ended up using "cflag = value1 < ((int64_t)value2 + cflag)". This is the same logic I used in the P1 code. The int64_t cast is needed to handle the case when value2 is 0x7fffffff and cflag is 1. The instruction document defines setting C = overflow of (D - (S + C)). I found the word "overflow" a little confusing. To me it implies that the value of (D - (S + C)) doesn't fit in 32 bits, such as (0x7fffffff - (-1)). I think the description in the Propeller manual is a little clearer.
Chip
All V20 images flashed on all FPGA boards Ok.
Thanks, Ozpropdev, for trying those out. There is a six- or seven-step process to making each image. I have to really concentrate when doing these. I'm glad they all work okay. I only checked the 16-cog A9 image and relied on careful adherence to the steps to make the rest.
Late in the game, but, can you add one instruction to support John Gustafson's 'posit' floating point proposal? Add an instruction to count leading zeroes or leading 1's in a word. I know this is easily coded in a two-instruction loop, but one instruction cycle would be ideal.
Late in the game, but, can you add one instruction to support John Gustafson's 'posit' floating point proposal? Add an instruction to count leading zeroes or leading 1's in a word. I know this is easily coded in a two-instruction loop, but one instruction cycle would be ideal.
Welcome!
We have an ENCOD instruction which returns the bit number of the first "1" in S into D. You can use a NOT instruction beforehand to look for 0's, then an 'XOR D,#$1F' afterwards to get the number of leading 1's. So, two or three instructions (4 or 6 clocks) get you the number of leading 1's or 0's.
Late in the game, but, can you add one instruction to support John Gustafson's 'posit' floating point proposal? Add an instruction to count leading zeroes or leading 1's in a word. I know this is easily coded in a two-instruction loop, but one instruction cycle would be ideal.
Welcome!
We have an ENCOD instruction which returns the bit number of the first "1" in S into D. You can use a NOT instruction beforehand to look for 0's, then an 'XOR D,#$1F' afterwards to get the number of leading 1's. So, two or three instructions (4 or 6 clocks) get you the number of leading 1's or 0's.
I checked the v20 FPGA with my test programs, and the C and Z flags now look correct with the operators that were failing in the v19 image. So the 130+ operators that I tested all match spinsim except for one -- MUXBYTS. It looks like MUXBYTS isn't writing the result to the D register in v20.
I checked the v20 FPGA with my test programs, and the C and Z flags now look correct with the operators that were failing in the v19 image. So the 130+ operators that I tested all match spinsim except for one -- MUXBYTS. It looks like MUXBYTS isn't writing the result to the D register in v20.
Ah, there's a good reason for this!
One instruction has changed, after all, but I hadn't propagated it through my own docs, yet.
MUXBYTS is now MUXQ and it does something different and more useful:
'
' Atomic masked write
' d = (d & !mask) | (s & mask)
'
SETQ mask 'set 32-bit mask
MUXQ d,s 'copy s bits into d bits per mask
There needed to be a way to write bit fields into registers atomically. This is really useful for DIRA/DIRB/OUTA/OUTB operations where you want to safely modify some bits without being interrupted.
MUXNITS and MUXNIBS are useful for 2-bit and 4-bit graphics, but MUXBYTS was rather superfluous. I use MUXQ in the interpreter to write bitfields into registers. And remember that the instruction following SETQ is always protected from interrupts.
Thanks for the explanation. I'll remove MUXBYTS from my test program, and add MUXQ to another test program I'm going to write for instructions that use SETQ.
No, but your post made me ask again. Last we emailed them, somebody was going to send us a data sheet for a 128-bit fuse block that is available for the ONC18 process.
Did you ask about FLASH, EEPROM, OTP ROM, etc too? You could use any of these for the fuses too.
Comments
Thanks for pointing that out
"Trim away right bits of D by S[4:0]. D = D & ($FFFF_FFFE << S[4:0])".
That's clearly not correct. I implemented a sign extension in spinsim that copies D[S[4:0]] to all the bits to the left, and that produces that same results as the hardware. I basically did D = (D << S[4:0]) >> S[4:0], where >> is performed as an arithmetic right shift.
Sorry about that. I'll fix that in the documentation momentarily.
Done.
It would be very unusual for any carry-in opcodes to not also carry-out, as their whole point is extended math ops ?
You may have already seen this - new image at 12:44 ? - but no mention of what changed.
http://forums.parallax.com/discussion/comment/1414420/#Comment_1414420
It sounds like something's wrong in the FPGA. I was working on that section of Verilog a few weeks back. I must have broken something. I will look at it now.
I'm only running at 60MHz, but good idea to check that.
I recompiled and the problem seems to be in the overflow sensor, not the decoding.
Thanks for checking all that stuff, Dave. I'm kind of embarrassed that I don't have a test suite to rerun often.
Hey, are you sure that CMPSX is problematic? It looks okay to me, so far. It's really like CMPX with a signed carry output, not an overflow output. Definitely, all those others you mentioned are of the same ilk.
Yeah, CMPSX seems to be working fine.
On those others, I'm stumped at the moment because it looks too simple to fail.
To speed this circuit up, I had made some changes a few weeks ago. I never tested these overflow-out instructions and the ROM doesn't use them, so I never saw a problem. I'm really glad someone noticed this.
I also looked at the C flag logic for CMPSX again. For CMPS I just use "cflag = value1 < value2". For CMPSX I ended up using "cflag = value1 < ((int64_t)value2 + cflag)". This is the same logic I used in the P1 code. The int64_t cast is needed to handle the case when value2 is 0x7fffffff and cflag is 1. The instruction document defines setting C = overflow of (D - (S + C)). I found the word "overflow" a little confusing. To me it implies that the value of (D - (S + C)) doesn't fit in 32 bits, such as (0x7fffffff - (-1)). I think the description in the Propeller manual is a little clearer.
The documentation updates to cover new SKIP/SKIPF/EXECF/XBYTE behavior will be done soon.
The instruction spreadsheet hasn't changed.
Fingers crossed the V20 image is the final release and the 4th July has two meanings in history now!
All V20 images flashed on all FPGA boards Ok.
Thanks, Ozpropdev, for trying those out. There is a six- or seven-step process to making each image. I have to really concentrate when doing these. I'm glad they all work okay. I only checked the 16-cog A9 image and relied on careful adherence to the steps to make the rest.
I hope to get the docs updated today.
Late in the game, but, can you add one instruction to support John Gustafson's 'posit' floating point proposal? Add an instruction to count leading zeroes or leading 1's in a word. I know this is easily coded in a two-instruction loop, but one instruction cycle would be ideal.
We have an ENCOD instruction which returns the bit number of the first "1" in S into D. You can use a NOT instruction beforehand to look for 0's, then an 'XOR D,#$1F' afterwards to get the number of leading 1's. So, two or three instructions (4 or 6 clocks) get you the number of leading 1's or 0's.
That's perfect, Chip. Thanks.
Ah, there's a good reason for this!
One instruction has changed, after all, but I hadn't propagated it through my own docs, yet.
MUXBYTS is now MUXQ and it does something different and more useful:
There needed to be a way to write bit fields into registers atomically. This is really useful for DIRA/DIRB/OUTA/OUTB operations where you want to safely modify some bits without being interrupted.
MUXNITS and MUXNIBS are useful for 2-bit and 4-bit graphics, but MUXBYTS was rather superfluous. I use MUXQ in the interpreter to write bitfields into registers. And remember that the instruction following SETQ is always protected from interrupts.
And I do not see any difference between fuses and OTP, isn't that basically the same?
confused again today,
Mike