Prop2 FPGA files!!! - Updated 19 November 2017 - Version 27a

18384868889105

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: 8,321
    edited June 20 Vote Up0Vote Down
    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: 10,622
    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



  • 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.
  • 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: 10,622
    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: 8,321
    edited June 21 Vote Up0Vote Down
    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: 5,308
    edited June 21 Vote Up0Vote Down
    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: 8,321
    edited June 21 Vote Up0Vote Down
    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.
  • 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: 8,321
    edited June 21 Vote Up0Vote Down
    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.
  • 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.
  • 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! :)
    Melbourne, Australia
  • TorTor Posts: 1,803
    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. :)
    Melbourne, Australia
  • 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: 8,321
    edited July 5 Vote Up0Vote Down
    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: 5,308
    edited July 6 Vote Up0Vote Down
    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: 8,321
    edited July 6 Vote Up0Vote Down
    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.
  • 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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • 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
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
Sign In or Register to comment.