Shop OBEX P1 Docs P2 Docs Learn Events
New FPGA files for next silicon version - 5th/final release - contains new ROM!! - Page 4 — Parallax Forums

New FPGA files for next silicon version - 5th/final release - contains new ROM!!

124»

Comments

  • cgraceycgracey Posts: 14,133
    Just posted 5th/final release at top of thread for what will be built in Prop2 silicon, v2.
  • Flashed v33k images into all 4 boards Ok.
    Will run some boot tests ASAP.
  • cgraceycgracey Posts: 14,133
    ozpropdev wrote: »
    Flashed v33k images into all 4 boards Ok.
    Will run some boot tests ASAP.

    Thanks, Ozpropdev.
  • Dave HeinDave Hein Posts: 6,347
    edited 2019-02-21 16:16
    cgracey wrote: »
    ersmith wrote: »
    cgracey wrote: »
    It's critical, of course, that this latest version of PNut be used to assemble your programs, so that PTRx expression are assembled correctly.

    Wasn't the last proposal for the PTRx encoding backward compatible? It'd be really nice if we didn't have to have separate sets of tools for the P2ES and the next chip :(.

    I implemented what was simplest in logic, because the PTRx computation circuitry was near critical-path and I didn't want to possibly slow things down.

    I need to document what the new scheme is, though you can run PNut and see the output for different expressions. There's not a whole lot to it, and I don't know exactly where it breaks compatibility. Need to look at it.
    So how was the encoding for PTRx changed? Is this how it turned out?
    1S1PNNNNN -16..-1, +1..+15, for NNNNN != 00000
    1S1P00000 +16
    1S0NNNNNN -32..+31
    

  • cgraceycgracey Posts: 14,133
    Dave Hein wrote: »
    cgracey wrote: »
    ersmith wrote: »
    cgracey wrote: »
    It's critical, of course, that this latest version of PNut be used to assemble your programs, so that PTRx expression are assembled correctly.

    Wasn't the last proposal for the PTRx encoding backward compatible? It'd be really nice if we didn't have to have separate sets of tools for the P2ES and the next chip :(.

    I implemented what was simplest in logic, because the PTRx computation circuitry was near critical-path and I didn't want to possibly slow things down.

    I need to document what the new scheme is, though you can run PNut and see the output for different expressions. There's not a whole lot to it, and I don't know exactly where it breaks compatibility. Need to look at it.
    So how was the encoding for PTRx changed? Is this how it turned out?
    1S1PNNNNN -16..-1, +1..+15, for NNNNN != 00000
    1S1P00000 +16
    1S0NNNNNN -32..+31
    

    I don't remember and I'm not at home right now where my computer is.

    If you run the latest PNut that comes with the new'silicon FPGA files, you can look at the encodings.

    Pointer-modifying offsets of -16 to +16 are allowed, while random non-modifying offsets can range from -32 to +31.
  • Dave HeinDave Hein Posts: 6,347
    edited 2019-02-21 21:32
    I assembled some code with various PTRx indexes, and the results match the description in my previous post. So the v32 encoding is a subset of the v33 if the P bit is set to the index sign bit when the U bit is zero. Currently, the P2 assemblers set the P bit to zero.

    My test code is as follows:
                        dat
                                org
    000  00 00 00 00    r0      long    0
    001  00 01 04 FB            rdlong  r0, ptra
    002  80 01 04 FB            rdlong  r0, ptrb
    003  00 01 04 FB            rdlong  r0, ptra[0]
    004  01 01 04 FB            rdlong  r0, ptra[1]
    005  0F 01 04 FB            rdlong  r0, ptra[15]
    006  10 01 04 FB            rdlong  r0, ptra[16]
    007  11 01 04 FB            rdlong  r0, ptra[17]
    008  1E 01 04 FB            rdlong  r0, ptra[30]
    009  1F 01 04 FB            rdlong  r0, ptra[31]
    00a  00 01 04 FB            rdlong  r0, ptra
    00b  80 01 04 FB            rdlong  r0, ptrb
    00c  00 01 04 FB            rdlong  r0, ptra[0]
    00d  3F 01 04 FB            rdlong  r0, ptra[-1]
    00e  31 01 04 FB            rdlong  r0, ptra[-15]
    00f  30 01 04 FB            rdlong  r0, ptra[-16]
    010  2F 01 04 FB            rdlong  r0, ptra[-17]
    011  22 01 04 FB            rdlong  r0, ptra[-30]
    012  21 01 04 FB            rdlong  r0, ptra[-31]
    013  20 01 04 FB            rdlong  r0, ptra[-32]
    014  41 01 04 FB            rdlong  r0, ++ptra
    015  C1 01 04 FB            rdlong  r0, ++ptrb
    016  41 01 04 FB            rdlong  r0, ++ptra[1]
    017  4F 01 04 FB            rdlong  r0, ++ptra[15]
    018  40 01 04 FB            rdlong  r0, ++ptra[16]
    019  5F 01 04 FB            rdlong  r0, --ptra
    01a  DF 01 04 FB            rdlong  r0, --ptrb
    01b  5F 01 04 FB            rdlong  r0, --ptra[1]
    01c  51 01 04 FB            rdlong  r0, --ptra[15]
    01d  50 01 04 FB            rdlong  r0, --ptra[16]
    01e  7F 01 04 FB            rdlong  r0, ptra--
    01f  FF 01 04 FB            rdlong  r0, ptrb--
    020  7F 01 04 FB            rdlong  r0, ptra--[1]
    021  71 01 04 FB            rdlong  r0, ptra--[15]
    022  70 01 04 FB            rdlong  r0, ptra--[16]
    023  61 01 04 FB            rdlong  r0, ptra++
    024  E1 01 04 FB            rdlong  r0, ptrb++
    025  61 01 04 FB            rdlong  r0, ptra++[1]
    026  6F 01 04 FB            rdlong  r0, ptra++[15]
    027  60 01 04 FB            rdlong  r0, ptra++[16]
    
  • jmgjmg Posts: 15,140
    Dave Hein wrote: »
    I assembled some code with various PTRx indexes, and the results match the description in my previous post. So the v32 encoding is a subset of the v33 if the P bit is set to the index sign bit when the U bit is zero. Currently, the P2 assemblers set the P bit to zero.

    I think you are saying this can be made binary compatible, if the older version assembler is modified slightly, in how it handles unused bits ?
    It would be great if binary compatible of P2 & P2+ is possible.

  • evanhevanh Posts: 15,126
    edited 2019-07-11 13:22
    Chip,
    Something has niggled at me every time I look at it - The mnemonic naming of SETR vs ALTR. They have entirely different meanings of "R". This doesn't happen with S and D naming. I'd like to see R be reserved for only meaning the Result Register as per ALTR instruction.

    Also note ALTI uses SETR's interpretation rather than ALTR's.

    I'd like to choose a different letter for bitfield [27:19] uses. Conveniently, SETR is the only mnemonic name that would change in assemblers. The rest is all documentation.

    EDIT: How about "O" for opcode?

  • cgraceycgracey Posts: 14,133
    edited 2019-07-11 18:39
    evanh wrote: »
    Chip,
    Something has niggled at me every time I look at it - The mnemonic naming of SETR vs ALTR. They have entirely different meanings of "R". This doesn't happen with S and D naming. I'd like to see R be reserved for only meaning the Result Register as per ALTR instruction.

    Also note ALTI uses SETR's interpretation rather than ALTR's.

    I'd like to choose a different letter for bitfield [27:19] uses. Conveniently, SETR is the only mnemonic name that would change in assemblers. The rest is all documentation.

    EDIT: How about "O" for opcode?

    I hear what you are saying, but I think there is more to this. I'm not at my computer now, so I can't look.
  • evanhevanh Posts: 15,126
    You'll be filling a whole notebook of things to do. :D Good weather I hope.

  • evanhevanh Posts: 15,126
    bump, for Chip to check out.
  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    bump, for Chip to check out.

    What should we call it, if not SETR?
  • evanhevanh Posts: 15,126
    edited 2020-03-27 08:20
    SETO is reasonably suitable in my books.

    EDIT: Regarding ALTI, it's correctly labelled as is. I was confused with ALTI's working D register field allotments vs its prefixing actions.

    EDIT2: PS: The reason I dug this up now is because I bumped into it while scouring the forum for your post with the floor-plan of the revC change.
  • Cluso99Cluso99 Posts: 18,066
    SETOP ???
  • TonyB_TonyB_ Posts: 2,108
    edited 2020-03-27 11:25
    evanh wrote: »
    cgracey wrote: »
    What should we call it, if not SETR?

    SETO is reasonably suitable in my books.

    It should be SETx where x is a single letter. SETO seems good.

    Format of typical instruction:
    EEEE OOOOOOO OOI DDDDDDDDD SSSSSSSSS        <ins>    D,S/#
    
    However I've never really liked EEEE, where presumably E is for Execution. CCCC for Conditions would conflict with C flag bit so that's out. I think opcode[31:28] would be best represented by FFFF for Flags and this would be the smallest change possible both visually and alphabetically.

    Format of typical instruction then looks like:
    FFFF OOOOOOO OOI DDDDDDDDD SSSSSSSSS        <ins>    D,S/#
    
    or FOIDS for short:

    F for Flags (for conditional execution)
    O for Opcode
    I for Immediate
    D for Destination
    S for Source
  • evanhevanh Posts: 15,126
    Hijack foul! :)
  • evanh wrote: »
    Hijack foul! :)

    Hijack foul! = Great idea! ? :)
  • Smallest change alphabetically?

    May no aspect be unconsidered, gotta love this forum
Sign In or Register to comment.