I looked at the Prop2 CTRs and found that we could do everything they do, right in the pin circuits, excepting the function generator and Goertzel, which we could do in software with a larger granularity. Anyway, the pin smarts can handle all of these functions from the Prop2 CTRs:
PWM
NCO
DUTY
time positive edges
time negative edges
time highs
time lows
count positive edges
count negative edges
count highs (ADC summation)
count lows
Additionally, these functions can be accomplished:
time highs AND lows, with IN serial message indicating what state happened last, along with duration value.
asynchronous UART w/16-bit baud
SYNCHRONOUS IN/OUT SHIFTER USING ADJACENT PIN AS CLOCK - this is the way to implement SERDES!
drive 9-bit DAC with 7 bits of sub-dither for 16-bit average
set I/O pin drive modes: fast, slow, resistor, current, inverter, Schmitt, feedback, etc.
I just realized that once a pin is configured, it needs to stay in its mode, regardless of DIR, because there are many pin driver configurations that use DIR and OUT together, just like under normal operation. So, the DIR serial message receiver must not affect the internal DIR state if it sees that fast message preamble. This is good for ADC modes, where you'll be able to enable calibration with DIR and calibration state with OUT.
Would bit-wise CRC calculations be possible in pin logic? tx should be extremely simple but I don't really have any ideas on how to generalize syncing an rx CRC right now...
Would bit-wise CRC calculations be possible in pin logic? tx should be extremely simple but I don't really have any ideas on how to generalize syncing an rx CRC right now...
All those little odd-ball computations could be done well in the pins.
It's unclear to me what happens to the INx, OUTx, and PHSx. It looks like DIRx, FRQx, and CTRx go away, replaced by the DIRMSG instruction. Is that correct? What about the other three?
If we can get a divider on its clock, or a counter as its clock, definitely!
Like most people, I use PWM for motor control, there 8 bits precision for the duty cycle is fine, but the update frequency can be from 50Hz to say 200Khz (I mostly use in the 100Hz-200Hz range). This could actually be bit-banged.
For servos, I normally need 500us - 2500us pulse width in a 20ms window. Digital servos can use more precision, and have much shorter periods.
Sixteen bits of precision is more than good enough here!
It's unclear to me what happens to the INx, OUTx, and PHSx. It looks like DIRx, FRQx, and CTRx go away, replaced by the DIRMSG instruction. Is that correct? What about the other three?
Never mind. I saw the new register map in the other thread. I guess I need to go back and re-read this thread again, as I obviously don't understand the distinction between interacting with the registers and using the xxxMSG instructions.
Never mind. I saw the new register map in the other thread. I guess I need to go back and re-read this thread again, as I obviously don't understand the distinction between interacting with the registers and using the xxxMSG instructions.
The pin smarts have their own lives outside of the CTRs. The CTRs are still needed.... to...... PHIL???????
I have newer asked for this because the P2 was overkill for many things (there is a big gap between P1 and P2) and also its power needs make some uses a nonsense. (Don't take it wrongly it's a super uC)
But for an enhanced P1 this is one thing I am missing and I will use many times. Perhaps it's already part of the P2 new pin design and I am not aware of it.
Basically this works so:
- an pin is declared as ADC thus it is an input
- the pin is routed to the ADC and a comparator
- since it can't be used as output at the same time, its DAC is also routed to the comparator setting a comparing setpoint/level
- the comparator output is routed to the adjacent pin's output OR circuitry through an enable
- in this way the comparator output is available to the external world through the adjacent pin if it is set as output and comparator is enabled
- in this way the comparator output is available to any cog through its input register (feedback)
The comparator function can be done in analog or digital domain depending how the ADC/DAC functions are build
Uses (many)
1) For example through adjacent output you are PWMing an IGBT to control a load. The input ADC can read eg the process current while the DAC can set over-current protection shutting down very quickly the PWM pulses through the output OR avoiding hardware damages. Perhaps the comparator can have a configurable hold (output set/reset memory) also.
2) You can have an environmental controller (? weather station, data logger, battery powered device). A cog can wait on cnt to sample the ADC once a second/minute/hour to log the data. A second cog (alarm controller) can wait on adjacent pin (ADC threshold set through the DAC) to react immediately if something is going wrong with the input signal. Extreme power saving.
X) and many others, but I will not bore with long lists
Here below how I figure that concept that perhaps I wasn't able to explain properly with my English level.
Again missing many parts of circuitry (all the in/out/dir and/or from each cog and many else). Take it as concept.
You could probably just write the polynomial coefficients (via serial link) to the pin circuitry that implements the LFSR.
That was what I was thinking you could have a user configurable ploy and 8/16/32 word length at the cost of a 32 bit LFSR, 32 bit poly register, 3:1 tap mux and setting register.
How much control would we have over period and frequency of the PWM?
If the Counter registers are 32bits (as they will be for other tasks) then the PWM resolution will naturally become up to 32 bits.
With settings for both Wrap Value and Compare value, any precision PWM at all can be set.
The 32b field allows shifts to manage any pre-scaler, which keeps the other logic simpler.
A nice detail of two-counter PWM, is that values of 0 & 100% are both supported.
I would like to have a Pos Edge CTR mode that allows you to input a value for the counter to count up to, fire a pin high, reset the counter, take the pin low. There are cases where in PASM the time for code to do this takes too long.
It is looking like 3 pin support will be there, so this could use PWM mode, set to ext-clock from an Adj pin.
Choices on the Pin high case are to reset on itself (gives a one clock pulse), or set the PWM just above this for a N-High pulse.
Both cases need the external edge to continue while high, and if you wanted a Mono-flop action, then some single-shot support would be needed, otherwise the cycle repeats until SW says stop.
SW that waits for the =\_ could issue a stop command, within the latency limits of the shared command bus.
If a cog doesn't configure a pin into some special mode that traps IN/OUT signals for modal use, any OUTMSG packets will travel over the pins, as long as the corresponding DIR bits are high to enable output. Another cog (in another chip) in a WAITMSG instruction can receive it, as if it was coming from his own pin's state machine. The messages are 32 bits and encoded as %010_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx_0, with bits advancing on every clock (100 Mbaud @ 200MHz clock). So, each cog can receive and send, but in a half-duplex fashion, as these instructions stall the cog.
If the pins get pushed into SERDES modes, this may prove quite a bottleneck ?
To still keep the silicon simple, could each COG have a second, direct serial path to pins in cyclic order ?
I think "smart pins" is the coolest feature I've heard of yet. I don't care much about color tables, displays, multipliers, hubex, caches, or ultra high bandwidth. But these smart pins sounds like a great way to make all of that obsolete: why have a fast cog when your pin is fast on it's own?
I think "smart pins" is the coolest feature I've heard of yet. I don't care much about color tables, displays, multipliers, hubex, caches, or ultra high bandwidth. But these smart pins sounds like a great way to make all of that obsolete: why have a fast cog when your pin is fast on it's own?
Certainly a great idea, but the Pin cell still needs to be fed, and the output taken, so the COGs are not redundant yet !
I am curious how much power they will draw, especially if we are looking at 64-80 32 bit counters running at 200MHz with match and preset registers. (Chip has not said anything about that, I was looking at a worst case power wise)
I am curious how much power they will draw, especially if we are looking at 64-80 32 bit counters running at 200MHz with match and preset registers. (Chip has not said anything about that, I was looking at a worst case power wise)
I wonder about that and now much area it will take. These have gone from basic smart counters to 'do everything' pins with their own MCU almost with all of these modes Chip is talking about. One minute we had no room left for more Hub RAM and the next every pin is getting their own brain.
While I am thrilled by the concept, we just killed the P2 due to over use of space and power and it looks like we are headed there for round 2.
I am curious how much power they will draw, especially if we are looking at 64-80 32 bit counters running at 200MHz with match and preset registers. (Chip has not said anything about that, I was looking at a worst case power wise)
This will be a very important question, along with 'can they hit 200MHz ?'
- I think the match is avoided by using two counters, but the counters are binary, so the bits toggle less frequently for a lower average ft. ( same Qn power as 2 100MHz FF per Bin CTR)
There is still a clock tree, feeding 2 x 32bit counters, and the state-logic. (Capture case can be clock gated)
I wonder about that and now much area it will take. These have gone from basic smart counters to 'do everything' pins with their own MCU almost with all of these modes Chip is talking about. One minute we had no room left for more Hub RAM and the next every pin is getting their own brain.
While I am thrilled by the concept, we just killed the P2 due to over use of space and power and it looks like we are headed there for round 2.
I was under the impression that this approach would also reduce some of the circuitry that's currently in each cog. If so, that will help somewhat.
I was under the impression that this approach would also reduce some of the circuitry that's currently in each cog. If so, that will help somewhat.
That was what I thought too, as Chip had mentioned that the per cog counters were complex, but now it seems we still have to keep at least some cog counter capability AND these are getting more complex trying to provide the same (and more) capability as we are taking out of the cog.
Cog counter x 16 vs Pin counter x 64 (80) ???
I don't know if there is a big difference in integrating these within the cog logic that makes up the difference or if Chip just really needed some sleep there at the end...
I was under the impression that this approach would also reduce some of the circuitry that's currently in each cog. If so, that will help somewhat.
Good point, also any design that runs a lot of Smart Pins, is likely to not use the COGs so much, so there will be some power budget trade off possible there too.
Pin Counter Cells can also be quite locally compact, as they have a serial interface and just 3(?) locally associated pins, and that has to help the Cpd side of things.
Is it one counter per pin or one counter per two pins? Also, it's currently two counters per cog so 32 counters.
True, we have 2 per cog. But while they may see some reduction in ability I think they are staying as there are other uses for them.
The per pin thing is hard to pin down. Seems like every pin has its own, plus they can be somehow connected with one (or two?) other pins for more complex functions. That was when I started wondering about the real cost in power and area. Then people started talking about using them in groups of 8 for parallel, and for serial, and P2P comm and ...
@jmg True and good points. Also the counters have to be able to route special functions to any pin when in cogs vs just their pin (and 1 ? 2 ? connected) which would be more compact. I would love to see the circuit comparison between the two setups! That would be very educational.
Comments
It will work also for parallel data? I want to attach two UM232H modules (in synchronous FT245 mode) to the new propeller.
Each FT232H is capable to transfer 40 MBytes/s from PC USB 2.0 to FPGA/Propeller (and viceversa).
It uses 8 bit data signals (D0-7), 4 control signals (RXF#, TXE#, RD#, WR#) and a fixed clock output (60 MHz).
The FT232H outputs a fixed 60 MHz clock. I am not sure how the propeller should handle those two clocks (SW or Smart Pins?).
http://www.ftdichip.com/Support/Documents/DataSheets/Modules/DS_UM232H.pdf
Chip,
All I can say to this is: HOLY COW!!!
How much control would we have over period and frequency of the PWM?
Did not reply to Chip's post as I had to go get a bib... was drooling too much.
It all comes down to how much logic we have room and power for. I think 16 bits would be fine for PWM.
All those little odd-ball computations could be done well in the pins.
Like most people, I use PWM for motor control, there 8 bits precision for the duty cycle is fine, but the update frequency can be from 50Hz to say 200Khz (I mostly use in the 100Hz-200Hz range). This could actually be bit-banged.
For servos, I normally need 500us - 2500us pulse width in a 20ms window. Digital servos can use more precision, and have much shorter periods.
Sixteen bits of precision is more than good enough here!
edit: PLEASE go get a good day's sleep
Never mind. I saw the new register map in the other thread. I guess I need to go back and re-read this thread again, as I obviously don't understand the distinction between interacting with the registers and using the xxxMSG instructions.
200M clock cycles divided by say 44KHz = 454.54
Almost 9 bit CD rate audio output per pin for the cost of a capacitor?
Or 10 bit half CD rate audio at 20KHz sampling?
NICE!
The pin smarts have their own lives outside of the CTRs. The CTRs are still needed.... to...... PHIL???????
this is how I basically imagine +/- the P2 pin (there are missing all pull-ups and perhaps also the routing is wrong, take as concept)
IN1 <--------\ +--------------\ ADC1 <--------/ | | DIR1 >----------\ | | | DAC1 >--------\ sw/en | >-------------+---() pin1 OUT1 >--------/ IN2 <--------\ +--------------\ ADC2 <--------/ | | DIR2 >----------\ | | | DAC2 >--------\ sw/en | >-------------+---() pin2 OUT2 >--------/I have newer asked for this because the P2 was overkill for many things (there is a big gap between P1 and P2) and also its power needs make some uses a nonsense. (Don't take it wrongly it's a super uC)
But for an enhanced P1 this is one thing I am missing and I will use many times. Perhaps it's already part of the P2 new pin design and I am not aware of it.
Basically this works so:
- an pin is declared as ADC thus it is an input
- the pin is routed to the ADC and a comparator
- since it can't be used as output at the same time, its DAC is also routed to the comparator setting a comparing setpoint/level
- the comparator output is routed to the adjacent pin's output OR circuitry through an enable
- in this way the comparator output is available to the external world through the adjacent pin if it is set as output and comparator is enabled
- in this way the comparator output is available to any cog through its input register (feedback)
The comparator function can be done in analog or digital domain depending how the ADC/DAC functions are build
Uses (many)
1) For example through adjacent output you are PWMing an IGBT to control a load. The input ADC can read eg the process current while the DAC can set over-current protection shutting down very quickly the PWM pulses through the output OR avoiding hardware damages. Perhaps the comparator can have a configurable hold (output set/reset memory) also.
2) You can have an environmental controller (? weather station, data logger, battery powered device). A cog can wait on cnt to sample the ADC once a second/minute/hour to log the data. A second cog (alarm controller) can wait on adjacent pin (ADC threshold set through the DAC) to react immediately if something is going wrong with the input signal. Extreme power saving.
X) and many others, but I will not bore with long lists
Here below how I figure that concept that perhaps I wasn't able to explain properly with my English level.
Again missing many parts of circuitry (all the in/out/dir and/or from each cog and many else). Take it as concept.
... cmp32 | | IN1 <--------\ sw | >-------------\ / | | ADC1 <--------+ | | | | | /-----|--------/ | DIR1 | | + | | \--|\ cmp1 | | | >---\ | | /--|/ | | DAC1 >--------+ - | | | \ | | | >-------------+---()pin1 (+)----/ sw | OUT1 >--/ | | | | | | IN2 <--------\ sw | >-------------\ / | | ADC2 <--------+ | | /-----|--------/ | | | | DIR2 | | + | | \--|\ cmp2 | | | >---\ | | /--|/ | | DAC2 >--------+ - | | | \ | | | >-------------+---()pin2 (+)----/ sw | OUT2 >--/ | | | | | | IN3 <--------\ sw | >-------------\ / | | ADC3 <--------+ | | /-----|--------/ | | | | DIR3 | | + | | \--|\ cmp3 | | | >---\ | | /--|/ | | DAC3 >--------+ - | | | \ | | | >-------------+---()pin3 (+)----/ sw | OUT3 >--/ | | | pin4 ...You could probably just write the polynomial coefficients (via serial link) to the pin circuitry that implements the LFSR.
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MC68332
I have always wondered why that concept wasn't adopted by others to take some of the load off the cpu.
Now, if one counter/timer interrupt per core could be implemented for high reliability time triggered systems...
http://www.safetty.net/publications/pttes
The free book is worth reading before turning on the flame throwers.
If the Counter registers are 32bits (as they will be for other tasks) then the PWM resolution will naturally become up to 32 bits.
With settings for both Wrap Value and Compare value, any precision PWM at all can be set.
The 32b field allows shifts to manage any pre-scaler, which keeps the other logic simpler.
A nice detail of two-counter PWM, is that values of 0 & 100% are both supported.
See above, The Prescaler can be avoided if the counters are 32b, and they will be for other uses, so I'd go for simplicity, and keep every RMW to 32b
It is looking like 3 pin support will be there, so this could use PWM mode, set to ext-clock from an Adj pin.
Choices on the Pin high case are to reset on itself (gives a one clock pulse), or set the PWM just above this for a N-High pulse.
Both cases need the external edge to continue while high, and if you wanted a Mono-flop action, then some single-shot support would be needed, otherwise the cycle repeats until SW says stop.
SW that waits for the =\_ could issue a stop command, within the latency limits of the shared command bus.
If the pins get pushed into SERDES modes, this may prove quite a bottleneck ?
To still keep the silicon simple, could each COG have a second, direct serial path to pins in cyclic order ?
Certainly a great idea, but the Pin cell still needs to be fed, and the output taken, so the COGs are not redundant yet !
I wonder about that and now much area it will take. These have gone from basic smart counters to 'do everything' pins with their own MCU almost with all of these modes Chip is talking about. One minute we had no room left for more Hub RAM and the next every pin is getting their own brain.
While I am thrilled by the concept, we just killed the P2 due to over use of space and power and it looks like we are headed there for round 2.
This will be a very important question, along with 'can they hit 200MHz ?'
- I think the match is avoided by using two counters, but the counters are binary, so the bits toggle less frequently for a lower average ft. ( same Qn power as 2 100MHz FF per Bin CTR)
There is still a clock tree, feeding 2 x 32bit counters, and the state-logic. (Capture case can be clock gated)
I was under the impression that this approach would also reduce some of the circuitry that's currently in each cog. If so, that will help somewhat.
That was what I thought too, as Chip had mentioned that the per cog counters were complex, but now it seems we still have to keep at least some cog counter capability AND these are getting more complex trying to provide the same (and more) capability as we are taking out of the cog.
Cog counter x 16 vs Pin counter x 64 (80) ???
I don't know if there is a big difference in integrating these within the cog logic that makes up the difference or if Chip just really needed some sleep there at the end...
Good point, also any design that runs a lot of Smart Pins, is likely to not use the COGs so much, so there will be some power budget trade off possible there too.
Pin Counter Cells can also be quite locally compact, as they have a serial interface and just 3(?) locally associated pins, and that has to help the Cpd side of things.
True, we have 2 per cog. But while they may see some reduction in ability I think they are staying as there are other uses for them.
The per pin thing is hard to pin down. Seems like every pin has its own, plus they can be somehow connected with one (or two?) other pins for more complex functions. That was when I started wondering about the real cost in power and area. Then people started talking about using them in groups of 8 for parallel, and for serial, and P2P comm and ...
@jmg True and good points. Also the counters have to be able to route special functions to any pin when in cogs vs just their pin (and 1 ? 2 ? connected) which would be more compact. I would love to see the circuit comparison between the two setups! That would be very educational.