Shop OBEX P1 Docs P2 Docs Learn Events
P2 Smart Pins - Page 3 — Parallax Forums

P2 Smart Pins

1356711

Comments

  • kwinnkwinn Posts: 8,697
    cgracey wrote: »
    Seairth wrote: »
    cgracey wrote: »
    jmg wrote: »
    cgracey wrote: »
    All combinations of A rise/fall, B hi/lo and B rise/fall, A hi/lo * would be helpful, just like a "stateful" scope trigger. This would accommodate quadrature decoding (which I know is already covered elsewhere), as well as Start/Stop detection for I2C.

    * or, equivalently, all combinations of A, A(prev), B, and B(prev) , with an additional command long telling what to do (increment, decrement, nothing, error) for each.

    -Phil

    I have something like that now, where for each counter mode, there's a fixed pattern of 16 two-bit values which are used as +0/+1/-1. There are sixteen to accommodate all cases of A, A(prev), B, B (prev). The %10 case is unused, but could be an event trigger.

    I've thought about making this 16x2-bit pattern user-settable, but it would require another 32 bits of flops (out of a current ~200) per smart pin. My thinking has been to keep such details away from the user, so he's not burdened with thinking about these patterns. It seems easier to just have modes for A-B encoders, counters, frequency measuring, etc. Otherwise, they'd have to load some cryptic long into the smart pin to get it to do something. I'm not against that, personally, but I don't want to overburden people with details. We could have labels for these values (ie 'pin_encoder' = %00_01_11_00__11_00_00_01__01_00_00_11__00_11_01_00).

    What do you guys think?

    This comes down to coverage.

    Do you have a table of the modes supported by your current code ?

    - ie what is missing, from the simpler choices ?

    FlipFlops are not of as high as cost in ASIC, as they are in FPGAs, and they replace mini-roms.

    Having pre-defines as words for modes, is not hard to document, so users rarely need to know the 10101's

    I got the smart pin pretty much done, but I've decided to combine the measurement and timer logic blocks. I am adding some modes where you can inc/dec/clear on any combination of A, A(prev), B, B(prev) and selectively report results back or just alert via the IN bit.

    The A and B inputs to smart pins can now be the local pin, any of three pins above or below, or the OUT signal to either the local or adjacent pin. This will allow a smart pin to use another smart pin's output as one of its inputs, or allow you to control it via the OUT bit. Just working out the details now.

    These things are just getting smarter and smarter! I'm afraid that they're getting too smart for me to understand! :o

    It's nothing that a little diagram won't clear up.

    I was thinking, after I worked all night, that inspiration is akin to a true random number generator, where you must wait for some phenomenon to generate the number. You can't just get it on demand. Most of the night, I just kind of sat there waiting for things to congeal in my head, not knowing when, or if, it would come. Finally, almost on its own, the mental picture emerged and it was quite clear. I had been trying to think about this for a week, to no avail.
    Sometimes just taking a break is the best thing to do. After beating my head on a problem for hours I would go for a coffee break, and quite often the solution or an idea that lead to it would come to me while I was relaxing. This was particularly true for the university cafeterias. Must have been the ambiance there.
    We've got a framework now that can do all kinds of measurements, including things like A-B encoding. I had these measurements working, already, but not as a general case where the user could set up any configuration. This is going to be very simple to code, but these darn ideas are hard to get.

    Love the way the smart pins are coming together. So much flexibility and power yet they sound like they will be so easy to use. Really looking forward to getting my hands on the final product.
  • cgracey wrote:
    I am adding some modes where you can inc/dec/clear on any combination of A, A(prev), B, B(prev) and selectively report results back or just alert via the IN bit.
    I like the fact that clear is in there! But did you mean to exclude do nothing?

    -Phil
  • cgraceycgracey Posts: 14,133
    edited 2016-01-22 22:19
    cgracey wrote:
    I am adding some modes where you can inc/dec/clear on any combination of A, A(prev), B, B(prev) and selectively report results back or just alert via the IN bit.
    I like the fact that clear is in there! But did you mean to exclude do nothing?

    -Phil

    Yes, 'do nothing' was one of the four combos.

    You are probably wondering exactly how it works and what it can do.

    First, a quick diagram of the smart pin.

    Second, some waveforms and how it came to be. The waveform was actually gapped before it became flat.


  • Chip,
    You should do stand up. :)

    These smart pins are turning out to be quite deluxe.


  • Those waveform pictures look like something my cat would play with ... or ahem ... never mind.
  • rjo__rjo__ Posts: 2,114
    I am with Seairth on this one:)

    But you are right, a little diagram does make it clearer.
    I admit to a having a high fever, but I swear that smart pin looks like a retro-virus and the output looks like an alley during Oktoberfest.




  • jmgjmg Posts: 15,140
    cgracey wrote: »
    I got the smart pin pretty much done, but I've decided to combine the measurement and timer logic blocks.
    I thought you had already done that ?
    cgracey wrote: »
    I am adding some modes where you can inc/dec/clear on any combination of A, A(prev), B, B(prev) and selectively report results back or just alert via the IN bit.

    .. and capture ?

    cgracey wrote: »
    The A and B inputs to smart pins can now be the local pin, any of three pins above or below, or the OUT signal to either the local or adjacent pin. This will allow a smart pin to use another smart pin's output as one of its inputs, or allow you to control it via the OUT bit. Just working out the details now.
    Sounds flexible.
    There are some uses cases where you might want to have a 'hold-off', on Time interval A-B, or average Time interval A-B, and there a 3rd in Cell could get into the mix.
    Others, where you may want to capture some user-defined number of cycles.
    There, one Pin cell would count the N and another adjacent cell capture time on /N TC
  • Regarding the A and B signals query one of the possible surces can be "cog output" and "output pin" so that the input (smartblock output) of the same pin can trigger for differences. In this case the delay between A nad B that someone suggested before can be used to delay the event. This (the resulted input) can became an interrupt source now.


    With all the discussions going on I have not understood if the smart pins it's only a digital matter or have to do also with analog part. In this case I would like know if the following function (picture) can be done with the foreseen features. I mean having a comparator with swappable inverting and non inverting inputs (or selectable negated output) that can be ORed with the COG's output. For example to quickly shutdown a pwm output in case the comparator preset level is exceded. If the comparator could have also an optional selectable hold memory on output still better.
    The aim is to use external components as les as possible, run the code as slow as possible for energy saving reasons and still be able to react quickly in case of excedance of limiting values.
    786 x 914 - 30K
  • jmgjmg Posts: 15,140
    dMajo wrote: »
    For example to quickly shutdown a pwm output in case the comparator preset level is exceded.
    I think Chip has mentioned Reset of PWM already, from an adjacent pin,
    My guess is that Reset signal can be either direct, or via Analog Comparator, but I've not seen Tpd of Vos numbers on Analog parts of the design yet.

  • For clearance
    1022 x 466 - 18K
  • cgraceycgracey Posts: 14,133
    edited 2016-01-31 12:12
    dMajo wrote: »
    For clearance

    There's an SMPS mode for PWM that can shorten the pulse, based on a shunt resistor being input to a comparator whose other input connects to an 8-bit DAC inside the I/O pin.
  • cgraceycgracey Posts: 14,133
    edited 2016-01-31 12:38
    Okay. I've been off the forum for a few days, working on the programmable mode, and I think I've got the whole smart pin done! I thought I was here a few times before, but I think this is it. I'll do a complete test on Monday to make sure I haven't broken anything and then I'll do the FPGA image compiles.

    Making the programmable mode has been tough. It can do a lot of things, but it's going to take some usage before we know if it does what we need it to do. You can build all kinds of things out of it, like strange pulse measurers, serializers/deserializers, event trappers, and I don't know what else. It's not that complicated, but it's a little like chess, where you have different pieces that can move differently, and you could go insane trying to figure out all possibilities. This is going to require some documentation with diagrams.

    To briefly describe the programmable mode, it works like this:

    It inputs two pins: {B-previous, B-current, A-previous, A-current} to get a 4-bit input value on each clock. The A-current bit can be selected from a few other sources, as well.

    It maintains a 32-bit variable which can be set to 0/1/-1, incremented or decremented (with or without saturation), right- or left-shifted with A-previous or 0, set to any value by a cog, or left the same, on each clock, according to input and state.

    It uses dual 16-bit fields to pick 0's and 1's, based on the inputs and state. In 2-state mode, the 16-bit fields are selectively toggled between to get the 0/1 values. In 1-state mode, the fields are ganged together to get 0/1/2/3, to make four possible actions per clock, instead of just two.

    Ultimately, a 5-bit opcode executes on each clock:

    xx000 = <same>
    xx001 = set acc = 0
    xx010 = set acc = 1
    xx011 = set acc = -1
    xx100 = increment acc
    xx101 = decrement acc
    xx110 = A-previous/0 >> acc >> OUT
    xx111 = OUT << acc << A-previous/0
    x1xxx = next, 2-bit: toggle bit 0 xor for ops xx010..xx111 starting this op
    x1xxx = next, 1-bit: toggle state, switches bitfields
    1xxxx = signal: raises IN bit and outputs the 32-bit variable for reading by cog

    You pick four 5-bit opcodes and the dual 16-bit fields, along with seven configuration bits and a 5-bit counter value which can be used to selectively delay toggling into the other state (by x1xxx occurrences).

    As mentioned, A-current can be substituted with other signals: MSB or LSB of the 32-bit variable or the state bit (useful for 1-state mode, where fields are always combined, not toggled between).

    You can pick either the MSB or LSB of the 32-bit variable to drive the OUT signal, if the cogs' OUT is not used. For each A and B input, you can pick the local pin's input, the inputs from relative pins +3/+2/+1/-1/-2/-3, the OUT signal coming from the cogs, or the adjacent pin's final OUT signal. Before A goes into the smart pin flops, you can select A^B, A|B, A&B, or just A. There are inversion selectors for all inputs, as well as output.

    Here is a list of all pin modes:
    instructions
    --------------------------------------------------------------------------------------
    PINMODE	D/#,S/#		'write D[31:0] to pin S[5:0] mode
    PINSETX	D/#,S/#		'write D[31:0] to pin S[5:0] X
    PINSETY	D/#,S/#		'write D[31:0] to pin S[5:0] Y
    
    PINREAD	D,S/#		'read data from pin s[5:0], mode dependent
    
    PINACK  S/#		'acknowledge pin to drop IN signal (alias for PINMODE #0,S/#)
    
    
    					pad	pad
    MMMMM	Description			DIR	OUT	Pattern
    --------------------------------------------------------------------------------------
    00000	OUT (default)			DIR	OUT
    
    00001 *	DAC cog channel			DIR	OUT	output-update-repeat
    00010 *	DAC 16-bit dither		DIR	OUT	output-update-repeat
    00011 *	DAC 16-bit pwm			DIR	OUT	output-update-repeat
    
    00100 *	tra pulse			DIR	mode	wait-output-repeat
    00101 *	tra edges			DIR	mode	wait-output-repeat
    00110 *	nco freq			DIR	mode	output
    00111 *	nco duty			DIR	mode	output
    
    01000 *	pwm triangle 16:16		DIR	mode	output-update-repeat
    01001 *	pwm sawtooth 16:16		DIR	mode	output-update-repeat
    01010 *	pwm SMPS, A=V			DIR	mode	output-update-repeat
    01011 *	pwm SMPS, A=V, B=I		DIR	mode	output-update-repeat
    
    01100 *	A-high inc			DIR **	OUT	measure-report-loop
    01101 *	A-rise inc			DIR **	OUT	measure-report-loop
    01110 *	A-high inc, B-high dec		DIR **	OUT	measure-report-loop
    01111 *	A-rise inc, B-rise dec		DIR **	OUT	measure-report-loop
    10000 *	A-B encoder			DIR **	OUT	measure-report-loop
    
    10001 *	time A states			DIR **	OUT	time-report-loop (MSB = state)
    10010 *	time A high			DIR **	OUT	time-report-loop
    10011 *	time A-rise to A-rise		DIR **	OUT	time-report-loop
    
    10100 *	custom 2-bit, 1-pattern		DIR **	OUT	custom
    10101 *	custom 2-bit, 1-pattern, out	DIR **	mode	custom
    10110 *	custom 1-bit, 2-pattern		DIR **	OUT	custom
    10111 *	custom 1-bit, 2-pattern, out	DIR **	mode	custom
    
    11000 *	B-clk tx byte			DIR	mode	transmit-repeat
    11001 *	B-clk tx long			DIR	mode	transmit-repeat
    11010 *	B-clk rx byte			DIR **	OUT	receive-repeat
    11011 *	B-clk rx long			DIR **	OUT	receive-repeat
    
    11100 *	async tx byte			DIR	mode	transmit-repeat
    11101 *	async tx long			DIR	mode	transmit-repeat
    11110 *	async rx byte			DIR **	OUT	receive-repeat
    11111 *	async rx long			DIR **	OUT	receive-repeat
    
      * DIR from cogs: 0=reset, 1=start; IN to cogs: 1=done; 'PINACK pin' = clear done
     ** set %HHHLLL to %111111 (float/float) if your intent is to input
    

    For the various modes, PINSETX/PINSETY are used to configure any settings after PINMODE is used to set the mode. PINREAD can be used at any time to read back the last-updated 32-bit value from the smart pin. PINACK is used to cancel the IN signal coming back from the smart pin that lets you know that it finished something. After PINACK, the smart pin with drop IN and then raise it again on the next completion. These events can drive interrupts.
  • evanhevanh Posts: 15,126
    A fixed four deep five bit instruction sequencer for every pin? Wow, impressive, how big a foot print?

    And I'm thinking the Prop1 counters can be emulated too! There'll be some cheering me thinks.
  • cgraceycgracey Posts: 14,133
    I had the smart pin down to 430 ALM's, but it's at 504 now with the addition of the programmable mode.
  • cgraceycgracey Posts: 14,133
    Oh, those four 5-bit instructions can execute in ANY order, based on input and state.
  • evanhevanh Posts: 15,126
    504 x 64 pins = 32256 ALMs for Smartpins. From what I've read I'm thinking that'll account for around 25% of total synthesised logic. That's not over the top I don't think given what is being achieved on a per pin basis. Any ideas if it all fits on the silicon?
  • evanhevanh Posts: 15,126
    cgracey wrote: »
    Oh, those four 5-bit instructions can execute in ANY order, based on input and state.

    Different from a sequencer then. Fun fun!
  • Bob Lawrence (VE1RLL)Bob Lawrence (VE1RLL) Posts: 1,720
    edited 2016-02-02 21:12
    @cgracey

    re: I've got the whole smart pin done!

    Wow! looks like smorgasboard of great options there. :) We'll be experimenting for the next 50 years with all the new instructions and options. :)



  • This is really fascinating Chip. Really opens up the possibilities.

    Don't suppose you have a diagram to help understand it? (even if hand drawn)

  • jmgjmg Posts: 15,140
    cgracey wrote: »
    Here is a list of all pin modes:

    11000 * B-clk tx byte DIR mode transmit-repeat
    11001 * B-clk tx long DIR mode transmit-repeat
    11010 * B-clk rx byte DIR ** OUT receive-repeat
    11011 * B-clk rx long DIR ** OUT receive-repeat

    11100 * async tx byte DIR mode transmit-repeat
    11101 * async tx long DIR mode transmit-repeat
    11110 * async rx byte DIR ** OUT receive-repeat
    11111 * async rx long DIR ** OUT receive-repeat

    That consumes 8 modes, and only gives a restrictive 8 or 32bit Serial length choices.

    Would it not be more flexible, and free up 4 modes, with a defined-elsewhere Tx/Rx bit-count value ?



  • rjo__rjo__ Posts: 2,114
    I think I'm going to buy myself a helmet. I'm already slapping myself on the forehead and the pins are still in storage.

    I Googled "smart pins... and it is ...
    ...

    ... a Google game!!!

    "SMART PINS is a game by Google where you answer geographic questions by dropping pins on a map."

    So... if the question is ... "where were Smart Pins developed?"... I would drop Google's smart pin on the home of Parallax's smart pins... right?

    The Smart Pin is also the home of "The classic Antique Pewter Collection"

    By the way... you can now add 13 output pins to your next Arduino project... for a mere $4.95 at MakerShed.
  • evanhevanh Posts: 15,126
    We don't have to worry about disparate duplication of naming like that but Chip has identified another trademarked use of SmartPins naming for IC functionality already. There was a discussion a few weeks back ... Pion or Pinion were a couple of names I liked.
  • Cluso99Cluso99 Posts: 18,066
    WOW, OUCH and UGH !!!

    WOW about the functionality.

    OUCH for the silicon size. 14nm here we come <tongue in cheek>

    UGH - I tried to do a block diagram of this as I read it.

    I still wonder...
    * Does every pin require this?
    * Is it an overkill use of silicon?
    * Is there another more flexible way? (micro cogs might be more flexible but use more power)
    * Does it reflect what we need or overkill?
    * Delay and risk?
  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    I still wonder...
    * Does every pin require this?
    That probably comes down to 'does it fit' ?
    ie suppose having one per pin, drops RAM from 512k to 256k, then what is the trade off position ?
    Cluso99 wrote: »
    * Is it an overkill use of silicon?
    * Is there another more flexible way? (micro cogs might be more flexible but use more power)
    Another choice is 1 cell per Pair of pins, but Chip has this now half duplex, needing two cells for a duplex UART, so the Pin-Pair saving is not as great.
    That could still be a fall-back point, as Pin Pair will have some logic saving. (at the expense of less total capability numbers)

    Present split allows nominally 1 RX and 63 Tx (etc) for example. Paired, that becomes ~32 duplex channels.

    Cluso99 wrote: »
    * Does it reflect what we need or overkill?
    * Delay and risk?
    It is actually fairly similar to Cypress latest PSoC 4200L Family, put in a blender....

    They have 16b (?!) timer 'cells' copied 8 times
    ( Who puts 16b timers into a 32b MCU ?!)
    They have USART cells for (i2c/SPI/UART), copied 4 times, with 10 registers to config/operate, plus 8 byte FIFOs.
    The i2c mode has a nifty dual-port memory mapped mode, (EZ) where external i2c pins can access 32 bytes of register memory, with no local SW needed.
  • Cluso99Cluso99 Posts: 18,066
    jmg,
    Just my comments!

    We need to start testing P2 or it will be another year :(
  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    We need to start testing P2 or it will be another year :(

    It's already a year off.

    A side effect of the larger number of pin cells Chip has chosen, is helper USB support is less likely - as the size of each cell is now very important.

    With 4 spare modes using my idea above, 2 of those could map to USB shifters, where
    * NZRI and
    * bit-stuff/destuff
    * Sampling reSync (digital PLL)
    are the sensible bit-level tasks to put into silicon.
    None of that is huge logic, but if the pin-cells are identical, it dies copy 64 times, which is rather an over-kill.


  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    Cluso99 wrote: »
    We need to start testing P2 or it will be another year :(

    It's already a year off.

    A side effect of the larger number of pin cells Chip has chosen, is helper USB support is less likely - as the size of each cell is now very important.

    With 4 spare modes using my idea above, 2 of those could map to USB shifters, where
    * NZRI and
    * bit-stuff/destuff
    * Sampling reSync (digital PLL)
    are the sensible bit-level tasks to put into silicon.
    None of that is huge logic, but if the pin-cells are identical, it dies copy 64 times, which is rather an over-kill.


    I don't know, yet, what is needed, exactly, for USB in a smart pin. I know it's not overwhelming, but I also suspect much software is required on top of that before we could be sure that the smart pin implementation is correct.

    It's true that at 180nm, complexity matters, but at something like 14nm, you couldn't design enough stuff to make a dent in what would be available, area-wise. It's frustrating that costs go so high, into the $millions, for a leading-edge process. All you could design would be 1mm square, and the rest could be RAM.

    Sending the current smart pin to Weight Watchers would result in loss of functions. We could save area by equipping different pins with different smart pin functions, but it is really luxurious to be able to use any pin for anything.

    I think we need to try out what's been developed, so far, and get a reading on it. It's kind of a new frontier in Prop land. I'll test everything in the morning and then get an update out. Documentation will be coming over the next few days.
  • cgraceycgracey Posts: 14,133
    edited 2016-02-01 06:36
    Regarding the current 8- and 32-bit limitations on serial:

    We could do ANY word length, but it adds a lot of mux's, which inflate the gate count. It would be better to pick what several word lengths are likely to be needed, and implement maybe four or eight different ones.

    The programmable modes could do 1..32-bit synchronous serial, but they could not double-buffer data like the dedicated serial modes do. So, maybe the problem is solved, already.

    I suspect a 9-bit mode might be handy in the dedicated serial circuit, to accommodate parity. Personally, I like to handle errors at a much higher level, rather than having to react from the trenches.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    Regarding the current 8- and 32-bit limitations on serial:

    We could do ANY word length, but it adds a lot of mux's, which inflate the gate count. It would be better to pick what several word lengths are likely to be needed, and implement maybe four or eight different ones.
    I don't see a lot of muxes, as they are shifters, and a counter defines when to stop shifting and load ?

    That means a 5b loadable unidirectional counter for length, which is quite compact in logic.
    There is likely already a bit counter for 8 & 32, so it is adding 4 config bits.

    I would expect 8 preset values to use more muxes/roms.

  • evanhevanh Posts: 15,126
    JMG, if I'm reading your thinking correctly, you are saying that the shift/buffer registers are managed as 32-bit in terms of parallel data then only the shifting is controlled by the length parameter?
Sign In or Register to comment.