Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 86 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

18384868889160

Comments

  • Didn't realize we now have a command line .spin2 file loader. I do remember Peter requesting it.

    Thanks for pointing that out
  • 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.
  • cgraceycgracey Posts: 14,133
    edited 2017-06-20 21:38
    Dave Hein wrote: »
    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.

    Done.
  • 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?
  • jmgjmg Posts: 15,140
    Dave Hein wrote: »
    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 ?


    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



  • cgraceycgracey Posts: 14,133
    Dave Hein wrote: »
    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.
  • cgraceycgracey Posts: 14,133
    It looks too simple to fail. I'm cutting the pie in half and recompiling. I'm thinking maybe it's not sensing the overflow instruction group.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    It looks too simple to fail. I'm cutting the pie in half and recompiling. I'm thinking maybe it's not sensing the overflow instruction group.
    If it seems to be coded correctly, could this be a MHz-too-high issue ?

  • cgraceycgracey Posts: 14,133
    edited 2017-06-21 02:57
    jmg wrote: »
    cgracey wrote: »
    It looks too simple to fail. I'm cutting the pie in half and recompiling. I'm thinking maybe it's not sensing the overflow instruction group.
    If it seems to be coded correctly, could this be a MHz-too-high issue ?

    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.
  • Dave HeinDave Hein Posts: 6,347
    edited 2017-06-21 03:05
    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.
  • cgraceycgracey Posts: 14,133
    edited 2017-06-21 03:09
    Dave Hein wrote: »
    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.
  • cgraceycgracey Posts: 14,133
    Dave Hein wrote: »
    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.
  • cgraceycgracey Posts: 14,133
    edited 2017-06-21 03:47
    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.
  • cgraceycgracey Posts: 14,133
    Okay. It's fixed!
  • 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.
  • cgraceycgracey Posts: 14,133
    I posted a new release (v20) at the top of this thread.

    The documentation updates to cover new SKIP/SKIPF/EXECF/XBYTE behavior will be done soon.

    The instruction spreadsheet hasn't changed.
  • Thanks Chip!
    Fingers crossed the V20 image is the final release and the 4th July has two meanings in history now! :)
  • TorTor Posts: 2,010
    ozpropdev wrote: »
    Thanks Chip!
    Fingers crossed the V20 image is the final release and the 4th July has two meanings in history now! :)
    The other one is of course 4th July 1976, when my roof was covered in snow. I took a picture too. It was a cold cold summer..

  • Chip
    All V20 images flashed on all FPGA boards Ok. :)
  • cgraceycgracey Posts: 14,133
    ozpropdev wrote: »
    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.

    I hope to get the docs updated today.
  • Chip,

    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.

  • cgraceycgracey Posts: 14,133
    edited 2017-07-05 19:16
    MSwann wrote: »
    Chip,

    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.
  • cgracey wrote: »
    MSwann wrote: »
    Chip,

    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.

    That's perfect, Chip. Thanks.
  • Dave HeinDave Hein Posts: 6,347
    edited 2017-07-06 20:21
    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.
  • cgraceycgracey Posts: 14,133
    edited 2017-07-06 23:28
    Dave Hein wrote: »
    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.
  • Cluso99Cluso99 Posts: 18,066
    Yanomani wrote: »
    Hi Chip

    Did OnSemi already forwarded any news about the fuse layout?

    Henrique
    cgracey wrote: »
    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.
  • Flash and EEPROM would defeat the reason for fuses, the one-time-programmable thing to secure a chip.

    And I do not see any difference between fuses and OTP, isn't that basically the same?

    confused again today,

    Mike
Sign In or Register to comment.