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.
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 ?
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.
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.
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 ?
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.
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.
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 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?
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?
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.
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?
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).
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.
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.
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.
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 ?
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.
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.
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:)
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
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.
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.
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.
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.
Comments
If we are moving to 8 bits, what would drive that? What do we get in return for the change?
Normally that programing like Binary --- nd, Or -- and other functions --
And mostly on 2-4 In signaler
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.
A True-Edge wait would defer to next Edge, no matter what state the polling arrived at, and allows wide dynamic duty cycle support.
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 ?
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.
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 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.
Is this an additional interrupt, or does it use an existing interrupt vector?
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?
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
Actually, I need 9 pins to receive fast synchronous data: 8 data + 1 clock?
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?
I've lost track of what we currently have available. Is this correct?
(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).
by assigning the 8 interrupt pins to dedicated pins.
But I assume you would configure which 8 pins to use at any given time.
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.
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 ?
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.
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:)
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.
Mask1 = Pins to compare
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.
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.
That would depend on the Smart pins, which have yet to be defined, but I would expect Loadable gated timers and overflow flags there.
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 need the P2 !