Shop OBEX P1 Docs P2 Docs Learn Events
The New 16-Cog, 512KB, 64 analog I/O Propeller Chip - Page 121 — Parallax Forums

The New 16-Cog, 512KB, 64 analog I/O Propeller Chip

1118119121123124144

Comments

  • What are the trade-offs?

    If we are moving to 8 bits, what would drive that? What do we get in return for the change?
  • Hi Chip.

    Normally that programing like Binary --- nd, Or -- and other functions --
    And mostly on 2-4 In signaler
  • cgraceycgracey Posts: 14,133
    edited 2015-08-06 10:20
    I just converted the WAITPAE/WAITPAN/WAITPBE/WAITPBN instructions to SETPAE/SETPAN/SETPBE/SETPBN to establish the event (port A or B, equal or not equal to target after masking).

    The event/interrupt occurs when the pattern match/mismatch goes from false to true.

    So, it will be 32 bits. This takes 66 flops per cog: 1 for equal/not-equal, 1 for INA/INB, 32 for mask, and 32 for target. Now, the pin-pattern matching happens in the background and can be polled, waited for with timeout, and used as an interrupt source.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    I just converted the WAITPAE/WAITPAN/WAITPBE/WAITPBN instructions to SETPAE/SETPAN/SETPBE/SETPBN to establish the event (port A or B, equal or not equal to target after masking).

    The event/interrupt occurs when the pattern match/mismatch goes from false to true.

    So, it will be 32 bits. This takes 66 flops per cog: 1 for equal/not-equal, 1 for INA/INB, 32 for mask, and 32 for target. Now, the pin-pattern matching happens in the background and can be polled, waited for with timeout, and used as an interrupt source.

    Sounds good.
    Checking Details :

    The WAIT is 1 SysCLK granular, and saves power, ie equiv to P1 ?

    In the poll case, does this have a sticky option, so Sw can detect an event that restores between polling times. perhaps the interrupt FF can be a sticky flag ?

    Is there edge support, or just =, <> ?

    Can 64b be armed for interrupt, and vector to the same destination ? ie all 64 pins are checked at the same time ?

  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    I just converted the WAITPAE/WAITPAN/WAITPBE/WAITPBN instructions to SETPAE/SETPAN/SETPBE/SETPBN to establish the event (port A or B, equal or not equal to target after masking).

    The event/interrupt occurs when the pattern match/mismatch goes from false to true.

    So, it will be 32 bits. This takes 66 flops per cog: 1 for equal/not-equal, 1 for INA/INB, 32 for mask, and 32 for target. Now, the pin-pattern matching happens in the background and can be polled, waited for with timeout, and used as an interrupt source.

    Sounds good.
    Checking Details :

    The WAIT is 1 SysCLK granular, and saves power, ie equiv to P1 ?

    In the poll case, does this have a sticky option, so Sw can detect an event that restores between polling times. perhaps the interrupt FF can be a sticky flag ?

    Is there edge support, or just =, <> ?

    Can 64b be armed for interrupt, and vector to the same destination ? ie all 64 pins are checked at the same time ?

    True, the wait is one-clock granular and saves power.

    There are sticky bits for all events so that they can be polled or waited on. Interrupts fire on the actual events.

    It is edge-sensitive in the sense that the event is when it goes from mismatch to match, or vice-versa, depending on whether you've selected equal or not-equal.

    To do all 64 pins would require another 64 flops for mask and target, minus one flop for no longer needing INA/INB selection.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    It is edge-sensitive in the sense that the event is when it goes from mismatch to match, or vice-versa, depending on whether you've selected equal or not-equal.
    There are some places where you want to edge-align an action, and polling can miss the true edge time.
    A True-Edge wait would defer to next Edge, no matter what state the polling arrived at, and allows wide dynamic duty cycle support.
    cgracey wrote: »
    To do all 64 pins would require another 64 flops for mask and target, minus one flop for no longer needing INA/INB selection.
    Now I'm a little confused. I thought the A and B opcodes means all pins can be seen by all COGs ?
    Are some COGs mapped to different lots of 32 bits, or are some pins missed out entirely ?
  • cgraceycgracey Posts: 14,133
    Thanks for your input, Guys.

    The single-stepping seems to work fine, but we need a mechanism for breaking asynchronously, so that we can stop the cog and poll the execution point. Any ideas on how that should work? I think it needs to be another cog or a pin event.
  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    It is edge-sensitive in the sense that the event is when it goes from mismatch to match, or vice-versa, depending on whether you've selected equal or not-equal.
    There are some places where you want to edge-align an action, and polling can miss the true edge time.
    A True-Edge wait would defer to next Edge, no matter what state the polling arrived at, and allows wide dynamic duty cycle support.
    cgracey wrote: »
    To do all 64 pins would require another 64 flops for mask and target, minus one flop for no longer needing INA/INB selection.
    Now I'm a little confused. I thought the A and B opcodes means all pins can be seen by all COGs ?
    Are some COGs mapped to different lots of 32 bits, or are some pins missed out entirely ?

    All pins are seen by all cogs, but each cog must select which pins to do a masked compare on for its pin-pattern-matching event (replaces the old WAITPxx instructions).
  • Yes, and that's 32 bits wide, which makes perfect sense.

    I prefer another COG so that it's not required that we handle single stepping externally. What do you mean by "poll?"

    To me, that means step, then display status, which means some quick way of understanding the COG state. Some of the state data is currently hidden.
  • cgracey wrote: »
    I just converted the WAITPAE/WAITPAN/WAITPBE/WAITPBN instructions to SETPAE/SETPAN/SETPBE/SETPBN to establish the event (port A or B, equal or not equal to target after masking).

    The event/interrupt occurs when the pattern match/mismatch goes from false to true.

    So, it will be 32 bits. This takes 66 flops per cog: 1 for equal/not-equal, 1 for INA/INB, 32 for mask, and 32 for target. Now, the pin-pattern matching happens in the background and can be polled, waited for with timeout, and used as an interrupt source.

    Is this an additional interrupt, or does it use an existing interrupt vector?
  • cgracey wrote: »
    I guess here's my question: Does anybody ever need to wait for a pattern to appear on a set of pins, or is waiting for a transition on a single pin enough? Every time I've used WAITPxx, it's been to trap an event on a single pin. We already have this with GETEDG/WAITEDG. Do we need this function for multiple pins? If not, we could get rid of the WAITPxx instructions.

    Instructions to track 2 pins will be useful to track differential signals, and fake-differential signals (like USB, because it has a special SE0 signal that sets both pins to zero). USB .... IS CLUSO HERE ??

    Something like WAITPP0, WAITPP1, WAITPP01 (positive edge), WAITPP10 (negative edge) . WAITPP means WAIT_Pin_Pair.

    How can be used the instruction that track 8 pins? Fast 8b/10b decoding? Fast FIFO? state machines?
  • twm47099twm47099 Posts: 867
    edited 2015-08-06 13:16
    cgracey wrote: »
    msrobots wrote: »
    My understanding is that the waitxx instructions also put a cog in low power mode. Not sure if this still applies to the P2.

    Not being able to waitxx on a single pin is a big mistake. Just having 8 pin groups to wait on would render all other 7 pins useless.

    We have hopefully 16 COGs now and a simple serial receiver could just wait for his pin as on the P1 now, with his cog sleeping.

    Maybe the smart pins could help there, but not much info known to me about them, yet.

    For Logic Analyzer and friends a 64 bit read would be nice but in reality? Not really needed. You need to capture into hub anyways, maybe with 2 cogs to get every clock cycle. Or four COGs to have 64 bit. But then you have no buttons, display, EEPROM or serial. Just 64 pins there as far as I understand.

    Please @Chip, keep that Interrupt stuff simple. We do not need a whole event-system. That is what other MC are missing. They have HUGE Datasheets. Please stay away from that and do it the KISS way of Prop1.

    Since the P2 can do ADC/DAC and not just digital any capture program will use this feature. So any LA will capture over the smart pin interface. And who needs 64 triggers?

    Please keep it simple. Block read write is good. Some helper INS for USB maybe.

    Then make the smart pins really smart. I really think this is a very good decision you made to move stuff to them independent pin systems. Keeps the COG clearer and allows for way more parallel execution.

    just my two cent.

    Mike




    If you do a wait-event instruction like WAITEDG, you are in a low-power mode. We already can wait for a single-pin edge event. I'm talking about making those multi-pin WAITPAE, etc. instructions into events that you configure. Then, you can poll or wait for the event. It's actually very simple and it lets you see if the event occurred, without you having to wait for it. Of course, you can wait for it, too, if you want.

    I guess here's my question: Does anybody ever need to wait for a pattern to appear on a set of pins, or is waiting for a transition on a single pin enough? Every time I've used WAITPxx, it's been to trap an event on a single pin. We already have this with GETEDG/WAITEDG. Do we need this function for multiple pins? If not, we could get rid of the WAITPxx instructions.

    I'm not sure if this counts, but I use "waitpne" to test a group of switches that are active low by masking all those pins and waiting until any go low, then setting a flag. After that I use the specific pin(s) that went low to take action depending on the pin or pins.

    Tom
  • And why 8 pins only ? D# and S# are 9 bits.

    Actually, I need 9 pins to receive fast synchronous data: 8 data + 1 clock?
  • Are 10 bits needed to decode 8b/10b? or is just enough with 5b/6b & 3b/4b groups?

    I am thinking of one cog programmed just to decode 10b into 8b. The WAITxxx instructions together with different jumps/calls (or service routines) can be used as a parallel CASE / SWITCH instruction to decode 8b/10b at clock speed (100-150 MHz).

    Gigabit ethernet, PCI Express, Serial ATA ... will be possible?
  • cgracey wrote: »
    The single-stepping seems to work fine, but we need a mechanism for breaking asynchronously, so that we can stop the cog and poll the execution point. Any ideas on how that should work? I think it needs to be another cog or a pin event.

    I've lost track of what we currently have available. Is this correct?
    • Set an address to break at. When this occurs, an interrupt LINK is inserted prior to the instruction at the specified address.
    • Single step mode. Automatically insert an interrupt LINK prior to every instruction.

    (question: does this mean that a return from interrupt will always execute at least one non-interrupt instruction prior to another pending interrupt LINK being inserted?)

    And you are saying we also need an ability to externally trigger the breakpoint interrupt? This is bound to use an existing resource that one may already want to use for the application itself. I suggest leaving this out and seeing what people come up with for the current debug capabilities. If anything, maybe consider increasing the number of address breakpoints. The interrupt handler could figure out which address the interrupt occurred at by examining the return address register ($1Fx).
  • MJBMJB Posts: 1,235
    cgracey wrote: »
    I'm thinking that the WAITPxx instructions could be redone as an event/interrupt, with 8-pin sensitivity. 32-pin sensitivity is overkill for most practical applications.
    I would be more concerned breaking the 'all pins are equal paradigm'
    by assigning the 8 interrupt pins to dedicated pins.
    But I assume you would configure which 8 pins to use at any given time.

  • Can the pin match event also capture what changed?
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    jmg wrote: »
    cgracey wrote: »
    It is edge-sensitive in the sense that the event is when it goes from mismatch to match, or vice-versa, depending on whether you've selected equal or not-equal.
    There are some places where you want to edge-align an action, and polling can miss the true edge time.
    A True-Edge wait would defer to next Edge, no matter what state the polling arrived at, and allows wide dynamic duty cycle support.
    cgracey wrote: »
    To do all 64 pins would require another 64 flops for mask and target, minus one flop for no longer needing INA/INB selection.
    Now I'm a little confused. I thought the A and B opcodes means all pins can be seen by all COGs ?
    Are some COGs mapped to different lots of 32 bits, or are some pins missed out entirely ?

    All pins are seen by all cogs, but each cog must select which pins to do a masked compare on for its pin-pattern-matching event (replaces the old WAITPxx instructions).

    I'm still lost - the new instructions to SETPAE/SETPAN/SETPBE/SETPBN do not sound mutually exclusive, but you seem to be saying you choose Port A or Port B, and one will trump the other.
    In the older WAITxx syntax, it is clear you 'pick a port' but in any (new) interrupt mapping context, users expect both opcodes to work.
  • jmgjmg Posts: 15,140
    Can the pin match event also capture what changed?
    That would be nice, ( as would true edge) but capture needs more flops....

    Once you do capture you may also need a overflow rule - store and keep first would allow mono-flop type captures, and SW polling would allow present-states and maybe that is enough coverage ?

  • jmgjmg Posts: 15,140
    cgracey wrote: »
    Thanks for your input, Guys.

    The single-stepping seems to work fine, but we need a mechanism for breaking asynchronously, so that we can stop the cog and poll the execution point. Any ideas on how that should work? I think it needs to be another cog or a pin event.

    I think you mean here a hardware break, as opposed to SW break.
    As you say, HW break needs to be another cog or a pin event, but that probably should be disabled by default, otherwise it provides an attack/failure mechanism for working COGs.

    Some parts map this level of external debug access to Fuses.

  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    Thanks for your input, Guys.

    The single-stepping seems to work fine, but we need a mechanism for breaking asynchronously, so that we can stop the cog and poll the execution point. Any ideas on how that should work? I think it needs to be another cog or a pin event.

    I think you mean here a hardware break, as opposed to SW break.
    As you say, HW break needs to be another cog or a pin event, but that probably should be disabled by default, otherwise it provides an attack/failure mechanism for working COGs.

    Some parts map this level of external debug access to Fuses.

    Yes, there needs to be some way to force a breakpoint interrupt. It would have to be via an I/O pin or some other cog. Of course, it would have to be enabled to happen.

    Guys, I need to get some documentation written soon and all this event/poll/wait/interrupt stuff will be easily understood. It's really dirt simple, but because I don't have anything detailed for you to read, you're imagining it's more complex than it actually is. It seems to me a nice way to be able to capture events without "being there". Anyway, it's nothing to get worried about. I think you will all approve of it.

    Thanks for all of your input into all this.
  • rjo__rjo__ Posts: 2,114
    Does anybody ever need to wait for a pattern to appear on a set of pins, or is waiting for a transition on a single pin enough?

    yes... I was doing it with the prop to make a memory selection on the FPGA side. I got rid of it because it slowed things down, but my solution globbed output together and used up my bus.. sped things up though:)

  • Cluso99Cluso99 Posts: 18,066
    Chip,
    The SETPxx sounds fantastic and makes all the interrupts cohesive and yet still simple.

    I will wait to test the debug section. Whatever you have done will be fine and way better than the P1.

    Looking forward to some docs and FPGA release.
  • For the pin matching what about adding a second mask for pins to check. That way you could pick any of the 32 pins on a port to look at and ignore the others allowing them to be used by other cogs/functions.

    Mask1 = Pins to compare
    Mask2 = Value of pins to compare





  • cgraceycgracey Posts: 14,133
    edited 2015-08-07 20:58
    Kerry S wrote: »
    For the pin matching what about adding a second mask for pins to check. That way you could pick any of the 32 pins on a port to look at and ignore the others allowing them to be used by other cogs/functions.<br />
    <br />
    Mask1 = Pins to compare<br />
    Mask2 = Value of pins to compare

    No problem! That is how it works, already.

    D provides the 32-bit mask and S is the value to check INA/INB & D against.
  • RamonRamon Posts: 484
    edited 2015-08-08 06:24
    Please, may we have an status update? It seems that it is almost 95% done. Just only smartpins left, right? Did treehouse said something about verilog? Thanks!
  • With this new bit mask and sorta-interrupt will there be a way to have a smart input pin return a timed pulse when active?

    Think repeating key when a button is held pressed that would then fire the interrupt at a defined interval. This would greatly simplify code that needs buttons with that capability. If the pulse time is programmable you could even use it for feeding a step/dir pulse gen for jog feed rates.

    Set 6 pins (or more) as jog buttons in your mask, set pulse time on active to the desired continuous jog rate, write one section of code that fires on the common interrupt that passes the next jog move (step) to your pulse gen cog/object.

    Would work great too with manual controls in other motion applications.

  • jmgjmg Posts: 15,140
    Kerry S wrote: »
    With this new bit mask and sorta-interrupt will there be a way to have a smart input pin return a timed pulse when active?

    That would depend on the Smart pins, which have yet to be defined, but I would expect Loadable gated timers and overflow flags there.

  • jmgjmg Posts: 15,140
    cgracey wrote: »
    I just converted the WAITPAE/WAITPAN/WAITPBE/WAITPBN instructions to SETPAE/SETPAN/SETPBE/SETPBN to establish the event (port A or B, equal or not equal to target after masking).

    The event/interrupt occurs when the pattern match/mismatch goes from false to true.

    So, it will be 32 bits. This takes 66 flops per cog: 1 for equal/not-equal, 1 for INA/INB, 32 for mask, and 32 for target. Now, the pin-pattern matching happens in the background and can be polled, waited for with timeout, and used as an interrupt source.

    What is the conditioning for the trigger event - ie glitch filtering ?
    It has occured to me that this match interrupt could give a USB SE0 trigger, with a small noise filter. eg 2 or 3 successive yes, trigger the INT.
    The option of Solitary match gives the fastest response time, but that has no noise filtering and can trigger on pulses << ClkWidth.

  • Cluso99Cluso99 Posts: 18,066
    jmg wrote: »
    cgracey wrote: »
    I just converted the WAITPAE/WAITPAN/WAITPBE/WAITPBN instructions to SETPAE/SETPAN/SETPBE/SETPBN to establish the event (port A or B, equal or not equal to target after masking).

    The event/interrupt occurs when the pattern match/mismatch goes from false to true.

    So, it will be 32 bits. This takes 66 flops per cog: 1 for equal/not-equal, 1 for INA/INB, 32 for mask, and 32 for target. Now, the pin-pattern matching happens in the background and can be polled, waited for with timeout, and used as an interrupt source.

    What is the conditioning for the trigger event - ie glitch filtering ?
    It has occured to me that this match interrupt could give a USB SE0 trigger, with a small noise filter. eg 2 or 3 successive yes, trigger the INT.
    The option of Solitary match gives the fastest response time, but that has no noise filtering and can trigger on pulses << ClkWidth.
    We cannot expect the P2 to do everything. Some things just need to be done in software. If there are glitches then either the design is wrong or the software must work around it. This is what we did on the P1, and it is what is done on every other micro.

    We need the P2 !
Sign In or Register to comment.