Shop OBEX P1 Docs P2 Docs Learn Events
New Pin Instructions - Page 3 — Parallax Forums

New Pin Instructions

135

Comments

  • cgraceycgracey Posts: 14,131
    edited 2018-11-13 11:01
    In the next silicon rev, these instructions will be able to affect spans of 1..64 smart pins by using S[11:6] or Q[5:0] as an additional pin count:
    WRPIN/WXPIN/WYPIN D,{#}S
    AKPIN {#}S
    
    	WRPIN   reg,#8			'write reg to mode register of pin[8]
    
    	WRPIN   reg,#7<<6 + 8		'write reg to mode registers of pins[7+8:8]
    
    	SETQ	#3
    	WRPIN 	reg,index		'write reg to mode registers of pins[3+index[5:0]:index[5:0]]
    
    	BITNOT	reg,index		'write reg to mode registers of pins[index[11:6]+index[5:0]:index[5:0]]
    

    If pin 63 is exceeded, the writing wraps to pin 0 and continues upward.

    These instructions take 2 clocks + 1 clock per extra pin.
  • cgraceycgracey Posts: 14,131
    edited 2018-11-13 11:08
    Now, I've just got to come up with the compact common-usage WRPIN variants to enable efficient DAC and mode setting. Then, everything involving multiple smart pins is going to be very efficient.
  • cgraceycgracey Posts: 14,131
    By the way, all these multi-bit/pin changes have already been carefully implemented and tested.
  • Cluso99Cluso99 Posts: 18,066
    cgracey wrote: »
    In the next silicon rev, these instructions will be able to affect spans of 1..64 smart pins by using S[11:6] or Q[5:0] as an additional pin count:
    WRPIN/WXPIN/WYPIN D,{#}S
    AKPIN {#}S
    
    	WRPIN   reg,#8			'write reg to mode register of pin[8]
    
    	WRPIN   reg,#7<<6 + 8		'write reg to mode registers of pins[7+8:8]
    
    	SETQ	#3
    	WRPIN 	reg,index		'write reg to mode registers of pins[3+index[5:0]:index[5:0]]
    
    	BITNOT	reg,index		'write reg to mode registers of pins[index[11:6]+index[5:0]:index[5:0]]
    

    If pin 63 is exceeded, the writing wraps to pin 0 and continues upward.

    These instructions take 2 clocks + 1 clock per extra pin.

    Does that +1 clock mean each pin gets the effect 1 clock later?
  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    Does that +1 clock mean each pin gets the effect 1 clock later?

    Yes, it becomes a ripple instruction. (and can be quite slow if applied to many pins)
  • cgraceycgracey Posts: 14,131
    Cluso99 wrote: »
    cgracey wrote: »
    In the next silicon rev, these instructions will be able to affect spans of 1..64 smart pins by using S[11:6] or Q[5:0] as an additional pin count:
    WRPIN/WXPIN/WYPIN D,{#}S
    AKPIN {#}S
    
    	WRPIN   reg,#8			'write reg to mode register of pin[8]
    
    	WRPIN   reg,#7<<6 + 8		'write reg to mode registers of pins[7+8:8]
    
    	SETQ	#3
    	WRPIN 	reg,index		'write reg to mode registers of pins[3+index[5:0]:index[5:0]]
    
    	BITNOT	reg,index		'write reg to mode registers of pins[index[11:6]+index[5:0]:index[5:0]]
    

    If pin 63 is exceeded, the writing wraps to pin 0 and continues upward.

    These instructions take 2 clocks + 1 clock per extra pin.

    Does that +1 clock mean each pin gets the effect 1 clock later?

    That's right.

    Now you've got me thinking about making all this parallel.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    ... Now you've got me thinking about making all this parallel.

    I thought you had selected ripple mode to save logic ?
    Parallel (same edge) pin updates exist already using usual out opcodes. right ?
    This allows a pin-pointer, should someone want relocatable/relative pin coding ?
  • cgraceycgracey Posts: 14,131
    jmg wrote: »
    cgracey wrote: »
    ... Now you've got me thinking about making all this parallel.

    I thought you had selected ripple mode to save logic ?
    Parallel (same edge) pin updates exist already using usual out opcodes. right ?
    This allows a pin-pointer, should someone want relocatable/relative pin coding ?

    I'm trying to imagine what the logic difference would be.
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-11-13 19:35
    That is why I thought having a mask like SETPAT or a new SETM/SETM2 might be better. I don't think anything needs to be saved for Interrupts. Then it could be done in parallel with no clock penalty.
    I have no idea of the silicon penalty though. It's just more like a super DIRx/OUTx/INx instruction. Could even be restricted to 32 pin A or B group.
  • cgraceycgracey Posts: 14,131
    Cluso99 wrote: »
    That is why I thought having a mask like SETPAT or a new SETM/SETM2 might be better. I don't think anything needs to be saved for Interrupts. Then it could be done in parallel with no clock penalty.
    I have no idea of the silicon penalty though. It's just more like a super DIRx/OUTx/INx instruction. Could even be restricted to 32 pin A or B group.

    We output now a 6-bit pin pointer and a 34-bit command code (2type+32data).

    Instead of the 6-bit pointer, we could output a fully decoded 64-bit pattern with extra bits like the improved bit/pin instructions use. This wouldn't take much more hardware, if any. Then, we could write the same data to any number of smart pins in a 2-clock instruction.
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-11-13 20:23
    Again, I will stress I am concerned about feature creep.

    To me, a 32 or 64 bit pin mask would be nicer. Set it once, or more often if it changes. Then just use it with all the extra instructions. The only penalty is setting the mask once. No penalty for the other instructions. The SETMASK (or use the SETPAT instruction) could set the whole 64 bits in one go by using both D and S operands.

    As I said above, happy to limit it to 32 bits and an A & B port.

    I just think a mask is cleaner. As a by-product, the pins don't have to be successive.
  • Cluso99Cluso99 Posts: 18,066
    Just realised that only the WxPIN instructions take the extra clocks.

    I had thought this applied to the DRVx etc instructions.
    For these, up to 8 successive pins can be done with an immediate pin count, else use a register, and a limitation of 32 pins in an A or B bank.
    Sounds great to me.
  • cgraceycgracey Posts: 14,131
    Cluso99 wrote: »
    Again, I will stress I am concerned about feature creep.

    To me, a 32 or 64 bit pin mask would be nicer. Set it once, or more often if it changes. Then just use it with all the extra instructions. The only penalty is setting the mask once. No penalty for the other instructions. The SETMASK (or use the SETPAT instruction) could set the whole 64 bits in one go by using both D and S operands.

    As I said above, happy to limit it to 32 bits and an A & B port.

    I just think a mask is cleaner. As a by-product, the pins don't have to be successive.

    The pins don't have to be successive with a mask, but for objects that will be passed pin numbers, they are likely to work in ranges, anyway. It's likely that things will be lumped together, in practice. Of course, a 64-bit OR gate would give us both possibilities. We'll see.

    Ah, there is one problem when dealing with pin registers. To operate on both A and B ports at once leaves some problems with data-forwarding in the pipeline. Some accommodation would have to be made to span both ports.
  • Cluso99Cluso99 Posts: 18,066
    Quite happy to limit to either A or B.
    Definitely don't want to risk upsetting the data forwarding circuit!
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-11-13 21:25
    Chip,
    OT. Could the CNT be extended to 64 bits?
    Then just need a new instruction to copy the 64-bit CNT to the GETX and GETY internal result registers.
    Everything would work as-is for 32-bit CNT, but to get a 64-bit CNT, you do a COPYCNT instruction followed by GETX and/or GETY (or whatever these instructions are called).
    WAITCTx etc do not work on the 64-bit CNT.
    This just allows a bigger timer to be implemented in software, should someone want longer timers.
    What do you think? Presume little risk, little silicon?

    And, do we need it ???
  • cgraceycgracey Posts: 14,131
    Cluso99 wrote: »
    Chip,
    OT. Could the CNT be extended to 64 bits?
    Then just need a new instruction to copy the 64-bit CNT to the GETX and GETY internal result registers.
    Everything would work as-is for 32-bit CNT, but to get a 64-bit CNT, you do a COPYCNT instruction followed by GETX and/or GETY (or whatever these instructions are called).
    WAITCTx etc do not work on the 64-bit CNT.
    This just allows a bigger timer to be implemented in software, should someone want longer timers.
    What do you think? Presume little risk, little silicon?

    Let me think about it. It's not hard to do, just HOW to present it.
  • Cluso99Cluso99 Posts: 18,066
    cgracey wrote: »
    Cluso99 wrote: »
    Chip,
    OT. Could the CNT be extended to 64 bits?
    Then just need a new instruction to copy the 64-bit CNT to the GETX and GETY internal result registers.
    Everything would work as-is for 32-bit CNT, but to get a 64-bit CNT, you do a COPYCNT instruction followed by GETX and/or GETY (or whatever these instructions are called).
    WAITCTx etc do not work on the 64-bit CNT.
    This just allows a bigger timer to be implemented in software, should someone want longer timers.
    What do you think? Presume little risk, little silicon?

    Let me think about it. It's not hard to do, just HOW to present it.
    What if a new instruction read the upper 32 bits, and WC set C according to CNT[31] ?
    Software can then check if the upper has been increments. More work, but at least it can be used.
  • Could GETCT set Z if CT has passed through zero since the last GETCT? This rollover bit cleared after GETCT. Could also set C if CT[31]=1 for completeness. The 64-bit count code go be:
    	MOV	CTHI,#0
    	...
    	GETCT	CTLO		WZ
      IF_Z	ADD	CTHI,#1
    

    If Z if difficult, then use C.
  • jmgjmg Posts: 15,140
    TonyB_ wrote: »
    Could GETCT set Z if CT has passed through zero since the last GETCT? This rollover bit cleared after GETCT. Could also set C if CT[31]=1 for completeness. The 64-bit count code go be:
    	MOV	CTHI,#0
    	...
    	GETCT	CTLO		WZ
      IF_Z	ADD	CTHI,#1
    

    If Z if difficult, then use C.

    Yes, that's a low cost way to get more capture headroom, if 64b it too complex.
    It can have 2 D-FF and write to C & Z if asked.
    C can toggle on overflow and Z is sticky, set if 2nd overflow (C set and next overflow)
    That gives
    ZC
    00 = within 2^32 range
    01 = 32b range extension, safe (34s at 250MHz)
    10 = has overflowed, user care needed to decide if this is 2..3 *2^32, or is 4..5*2^32 or >
    11 = has overflowed, user care needed to decide if this is 3..4 *2^32
  • Cluso99Cluso99 Posts: 18,066
    I will start a new thread for CNT 64 bit.
  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    Chip,
    OT. Could the CNT be extended to 64 bits?
    Then just need a new instruction to copy the 64-bit CNT to the GETX and GETY internal result registers.
    Everything would work as-is for 32-bit CNT, but to get a 64-bit CNT, you do a COPYCNT instruction followed by GETX and/or GETY (or whatever these instructions are called).
    WAITCTx etc do not work on the 64-bit CNT.
    This just allows a bigger timer to be implemented in software, should someone want longer timers.
    What do you think? Presume little risk, little silicon?

    And, do we need it ???

    This type of queued capture, gets complicated by interrupts - ie if an INT happens after the capture, but before the read, and INT also reads CNT, the first queued value is invisibly replaced.
  • cgraceycgracey Posts: 14,131
    I've got the spanned WRPIN/WXPIN/WYPIN instructions working on any number of contiguous pins in 2 clocks. So, now you'll be able to update lots of pins at once with the same data.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    I've got the spanned WRPIN/WXPIN/WYPIN instructions working on any number of contiguous pins in 2 clocks. So, now you'll be able to update lots of pins at once with the same data.

    ... hmm.. I worry how much extra logic did that flash-span-encoder cost ?
  • jmg wrote: »
    cgracey wrote: »
    I've got the spanned WRPIN/WXPIN/WYPIN instructions working on any number of contiguous pins in 2 clocks. So, now you'll be able to update lots of pins at once with the same data.

    ... hmm.. I worry how much extra logic did that flash-span-encoder cost ?

    But data rippling through each pin a clock at a time is not good.
  • cgraceycgracey Posts: 14,131
    jmg wrote: »
    cgracey wrote: »
    I've got the spanned WRPIN/WXPIN/WYPIN instructions working on any number of contiguous pins in 2 clocks. So, now you'll be able to update lots of pins at once with the same data.

    ... hmm.. I worry how much extra logic did that flash-span-encoder cost ?

    For a 2-cog compile, the LE-count shot up to 27,926 from a prior 27,906. That's 20 more LE's!
  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2018-11-14 08:41
    if you are going to leave CNT as is, then you should NOT change this.
    Seriously, this is seriously absurd to argue to change when CNT is 32bit and requires PASM code (more than this does) to deal with and impacts more people and is in my opinion MORE annoying.

    The WHOLE argument for this change was convenience to use a feature and save a long or two when using it. A feature that a LOT of projects will never use.

    CNT will likely be used in like 99% of projects, and if you don't deal with wrap (no matter how long your timing need is) you will have issues, and it will happen a lot more often.
  • cgraceycgracey Posts: 14,131
    Roy Eltham wrote: »
    if you are going to leave CNT as is, then you should NOT change this.
    Seriously, this is seriously absurd to argue to change when CNT is 32bit and requires PASM code (more than this does) to deal with and impacts more people and is in my opinion MORE annoying.

    The WHOLE argument for this change was convenience to use a feature and save a long or two when using it. A feature that a LOT of projects will never use.

    CNT will likely be used in like 99% of projects, and if you don't deal with wrap (no matter how long your timing need is) you will have issues, and it will happen a lot more often.

    I'll get to it. I can only do one thing at a time.
  • Sorry, I am a bit frustrated with what is deemed important vs what is not.

    I feel like this change is not needed at all, and the LUT PTRx change is only being done for software HDMI that won't be used in the actual chip since you are doing hardware assisted HDMI. Both seem like things that should be very low priority compared to anything else.

    Obviously, fixes for the bugs found are top priority, after that everything should be considered "only do it if it's really important". Even the CNT change I that I am advocating should be carefully considered first. I feel like that change is probably the most important of the "nice to have" additions being talked about.

    It's amazing to me how people are supporting one change that could be done with just a little software, but against another change that requires MORE software to handle it.
  • cgraceycgracey Posts: 14,131
    edited 2018-11-14 20:15
    I understand what you are saying, Roy. I'm thinking about the CT right now.

    These spanning pin and bit instructions are going to go a long ways in cleaning up people's code.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    I understand what you are saying, Roy. I'm thinking about the CT right now.

    FYI, this is info on the RaspPi counter
    https://jsandler18.github.io/extra/sys-time.html

    It runs 64b Systick counter, and 32 bit lower compares. Mentions 1us increment, which I guess means /250 prescaler from the 250MHz peripheral clock ?

Sign In or Register to comment.