Shop OBEX P1 Docs P2 Docs Learn Events
RDLUT/WRLUT with auto-incrementing address - Page 5 — Parallax Forums

RDLUT/WRLUT with auto-incrementing address

1235»

Comments

  • Chip, below is a table of #s and the resulting index values. PTRx not relevant and omitted.

    rev A is P2 silicon
    rev B1 is my idea of yesterday
    rev B2 is my idea of today
    876543210
       #s		   index for rev
    1supiiiii	 A	 B1	 B2
    
    1x0000000	 0	 0	 0	assemble to this if index=0
    1x0000001	+1	+1	+1
    1x0001111	+15	+15	+15
    1x0010000	-16	+16 !	-16
    1x0011111	-1	+31 !	-1
    
    1x0100000	n/a	-32	+16
    1x0100001	n/a	-31	+17
    1x0101111	n/a	-17	+31
    1x0110000	n/a	-16	-32
    1x0111111	n/a	-1	-17
    
    1x1000000	 0	+16 !	+16 !
    1x1000001	+1	+1	+1
    1x1001111	+15	+15	+15
    1x1010000	-16	-16	-16
    1x1011111	-1	-1	-1
    
    1x1100000	 0	+16 !	+16 !
    1x1100001	+1	+1	+1
    1x1101111	+15	+15	+15
    1x1110000	-16	-16	-16
    1x1111111	-1	-1	-1
    
    ! indicates B1 or B2 not same as A
    

    I've even had a go at the Verilog change:

    Existing
    // rev B1
    wire [5:0] ptr_nx	= ix[s6] ? {ix[s4], ix[s4] || ~|ix[s3:s0], ix[s3:s0]}	// ptra/ptrb-update with -16..+16 scaled index
    				 : ix[s5:s0];					// ptra/ptrb-static with -32..+31 scaled index
    

    Proposed
    // rev B2
    wire [5:0] ptr_nx	= ix[s6] ? {ix[s4], ix[s4] || ~|ix[s3:s0], ix[s3:s0]}	// ptra/ptrb-update with -16..+16 scaled index		
    				 : {ix[s4], ix[s5]^ix[s4], ix[s3:s0]};		// ptra/ptrb-static with -32..+31 scaled index
    

    An index of -16..+15 will encode the same in rev B2 as rev A, if you assemble S to 1s0000000 when index=0.
  • Bumping this in case it was overlooked.
  • Maintaining binary compatibility between the fpga/test silicon and final silicon is a great idea. Thanks for this suggestion, @TonyB_. I hope @cgracey can implement it this way!
  • cgraceycgracey Posts: 14,133
    After I rest, I'll get into that. Too tired now.
  • jmgjmg Posts: 15,140
    ersmith wrote: »
    Maintaining binary compatibility between the fpga/test silicon and final silicon is a great idea. Thanks for this suggestion, @TonyB_. I hope @cgracey can implement it this way!

    Yes, certainly worth keeping. I was unclear if that table was binary compatible ( at least in all present use cases), or if it just improved the compatibility % ?
    ie +16 appears more than once in the B2 column & 0 appears more than once in Rev A column ?
  • TonyB_TonyB_ Posts: 2,105
    edited 2019-01-11 21:44
    There are two changes proposed from rev A:

    1. Use spare #s bit to extend Index range to -32..+31 when PTRx is not updated
    2. Replace two superfluous PTRx+0 update instructions with PTRx+16

    Here is a table that includes PTRx:
    #s          Expression      Address used         PTRx after instr       Index
    
    1x0iiiiii   PTRx[Index]     PTRx + Index*Scale   PTRx                   -32..+31
    1x11iiiii   PTRx++[Index]   PTRx                 PTRx ++= Index*Scale   -16..-1,+1..+16
    1x10iiiii   ++PTRx[Index]   PTRx + Index*Scale   PTRx ++= Index*Scale   -16..-1,+1..+16
    

    Rev B1 and B2 in the top post on this page have the same functionality but only B2 is binary-compatible with rev A, therefore two sets of tools can be avoided with B2.
  • jmgjmg Posts: 15,140
    TonyB_ wrote: »
    Rev B1 and B2 in the top post on this page have the same functionality but only B2 is binary-compatible with rev A, therefore two sets of tools can be avoided.

    That was what I hoped, does that mean the table case where A != B2, never occur in actual code use ?
  • jmg wrote: »
    TonyB_ wrote: »
    Rev B1 and B2 in the top post on this page have the same functionality but only B2 is binary-compatible with rev A, therefore two sets of tools can be avoided.

    That was what I hoped, does that mean the table case where A != B2, never occur in actual code use ?

    Yes, provided that (a) index=0 is always assembled to #s=1x0000000 and (b) people can control themselves and not use an index outside -16..+15 with rev A, or there is an assembler switch.

    1x01xxxxx is not a valid #s value for rev A. I don't know what would happen if it is created "by hand" and the same question could apply to invalid opcodes for other instructions, I imagine.
  • TonyB_ wrote: »
    There are two changes proposed from rev A:

    1. Use spare #s bit to extend Index range to -32..+31 when PTRx is not updated
    2. Replace two superfluous PTRx+0 update instructions with PTRx+16

    Here is a table that includes PTRx:
    #s          Expression      Address used         PTRx after instr       Index
    
    1x0iiiiii   PTRx[Index]     PTRx + Index*Scale   PTRx                   -32..+31
    1x11iiiii   PTRx++[Index]   PTRx                 PTRx ++= Index*Scale   -16..-1,+1..+16
    1x10iiiii   ++PTRx[Index]   PTRx + Index*Scale   PTRx ++= Index*Scale   -16..-1,+1..+16
    

    Rev B1 and B2 in the top post on this page have the same functionality but only B2 is binary-compatible with rev A, therefore two sets of tools can be avoided with B2.

    I have a feeling this change was not implemented before all the analogue innovations. If so, Chip could you please look at this again sometime? Perhaps when sorting out the bugs and other outstanding issues. Here's the link to my original post:
    http://forums.parallax.com/discussion/comment/1453877/#Comment_1453877

    The only downside is that it would be a little bit harder to patch instructions to change the index, if that is ever needed. The much bigger upside is that rev A and rev B could use the same toolset.
  • cgraceycgracey Posts: 14,133
    TonyB_ wrote: »
    TonyB_ wrote: »
    There are two changes proposed from rev A:

    1. Use spare #s bit to extend Index range to -32..+31 when PTRx is not updated
    2. Replace two superfluous PTRx+0 update instructions with PTRx+16

    Here is a table that includes PTRx:
    #s          Expression      Address used         PTRx after instr       Index
    
    1x0iiiiii   PTRx[Index]     PTRx + Index*Scale   PTRx                   -32..+31
    1x11iiiii   PTRx++[Index]   PTRx                 PTRx ++= Index*Scale   -16..-1,+1..+16
    1x10iiiii   ++PTRx[Index]   PTRx + Index*Scale   PTRx ++= Index*Scale   -16..-1,+1..+16
    

    Rev B1 and B2 in the top post on this page have the same functionality but only B2 is binary-compatible with rev A, therefore two sets of tools can be avoided with B2.

    I have a feeling this change was not implemented before all the analogue innovations. If so, Chip could you please look at this again sometime? Perhaps when sorting out the bugs and other outstanding issues. Here's the link to my original post:
    http://forums.parallax.com/discussion/comment/1453877/#Comment_1453877

    The only downside is that it would be a little bit harder to patch instructions to change the index, if that is ever needed. The much bigger upside is that rev A and rev B could use the same toolset.

    I did implement the +16, but not in a way that is completely binary compatible. I may need to go back and do it a little bit differently.
Sign In or Register to comment.