If there is going to be that many flip-flops included then please make sure some of them, along with the adder, can be re-purposed to perform second-order filtering on the ADC.
I really hope that like CNT being 64 bits to avoid the 56 seconds gap the counters will also support 64 bit. No really need here, just stomach feeling.
As @jmg said the capture part is what is somehow missing on the P1 and I hope some support for that can go to the smart pins. One long asked whish was to be able to clock in stuff with the video circuit instead of just clocking out.
The same applies IMHO to I2C and SPI also. Currently a SPI slave (external clock) is sort of cumbersome to program and quite slow compared to - say - SPI out with the video circuit..
So support for serialization (sync or async) for input and output is quite important. Some features will require pin pairs so this needs to be addressed. I am not asking for SPI in hardware or full blown UARTS, Just some shift register inputting from a pin with optional clock on another pin.
yeah. just dreaming here. We will see what @Chip comes up with. But running independent Subsystems on pin(pairs) parallel to 16 cogs sounds very nice to me.
Hello!
I have been reading through the forum, and I am interested in the "smart pin".
What apps are being planned for the these smart pins? The other threads
give me a indication of the function of the pin; That it could be used as
some kind of Neural interface? In reference to all the functions that surround it.(?)
Just a thought....
Like @Timothy D. Swieter I am waiting calmly for the Parallax FPGA Board (and the not yet announced seminar in Rocklin...)
Mike
Prior discussion with Chip was that we'd announce the seminar date when we had our own, functional Propeller 1-2-3 FPGA board. I'll check with him to see what his latest thoughts are on this detail.
He's getting better at estimating his development time now that he's been through this particular design more than twice.
What apps are being planned for the these smart pins? The other threads
give me a indication of the function of the pin; That it could be used as
some kind of Neural interface?
Not quite Neural smart - more smart enough to be configured a number of different ways, with attached Counter/Shifter/mode config Logic resource.
Hello!
I have been reading through the forum, and I am interested in the "smart pin".
What apps are being planned for the these smart pins? The other threads
give me a indication of the function of the pin; That it could be used as
some kind of Neural interface? In reference to all the functions that surround it.(?)
Just a thought....
It's basically a counter/ADC/DAC/SPI/video generator/etc. per pin that replaces the per-cog counters and video generator.
I'm afraid to ask, but is there a target date for the first FPGA update? Could you provide an FPGA image without hubexec, cordic engine and smart pins?
It's been 3 weeks since I last asked, and almost 5 weeks since Christmas. I'm curious how the P2 development is going. Any guess on when the FPGA update will be coming?
I've been using the P-1 chip in a very successful commercial application for several years
and now would like to upgrade to more speed and features.... It seems the P-2 has been
“on the stove”, “in the works”... for a long time. Soooo?? Six months? / a year?
You must have some Idea .
I really don't want to design my new project around a PIC (but they are fast, cheap, and
have lots of features.)
Just hedge your efforts. If that means using a PIC in the interim then do it.
The design attempts have been going on for six years plus now with no end in sight.
Over the decades I learned one thing about tech companies. They say a lot of things but until they deliver on what they say with a real product, it's vaporware. You don't bet the farm on something that doesn't yet exist..
... The design attempts have been going on for six years plus now with no end in sight.
To be fair though, the target date was only ever set and missed once. And that wasn't six years ago.
To speculate, my fingers are still crossed for end of this year. I don't see Chip making dramatic changes to the FPGA releases from user testing input. It'll mostly be a bug checking exercise and for the users it offers the obvious early release development opportunity.
I guess there is still room for feature creep around the SmartPins but that'll be pretty rigidly fenced by available real-estate. When every additional gate is multiplied by 64 you definitely want to be sure it's going to be useful.
And finally, the question of ROM size and boot features. He's already had a successful outing with first Prop2 attempt so may not add much here, just massage it for this Prop2 design, dunno.
When every additional gate is multiplied by 64 you definitely want to be sure it's going to be useful..
I'm not sure you can expect a x64 effect.
The Smart Pin Cell will cover Serial and Counters & PWM, and in most practical uses, those at least pair pins.
(SPI needs 3-4)
Candidates are likely to be 32x or 16x or maybe 24x , or even some other die-determined number.
16x seems light*, 64x or even 32x may not fit, opening up some other number.
* 16x may be more tolerable, if CellN.Serial use on some pins, also allows CellN.Counter use on others.
However that implies more Multiplex complexity.
A Pin Cell that has Tiny Fifo and Config for a choice of ONE-OF peripheral would have a simpler register interface, and less Multiplex demand.
While they are likely to be in pairs, any pairing arrangements will be in addition to the 64x effect. The bulky things like configuration and buffers and shifters and adders will be on a per pin basis. Otherwise, something like the counters would have to stay in the Cogs.
Either that or the spec has to change to, say, 32 ADC channels across 64 pins.
It's quite the dilemma really. Shifting the counters out to the SmartPins means that they can't be directed to any old pin the way the Prop1 can do it. This, in turn, means that if you are not using a particular counter then it can't be used anywhere else either. The more this arrangement is bulked up the more wasteful it can become.
It has some advantages though:
1: As Chip has said, the decoupling makes his design work easier.
2: It also means that the counter resources are not Cog bound. If you are wanting to manage, say, 8 channels from one Cog then the Prop2 design makes that a piece of cake.
One detail that, Phil in particular, might be concerned about is that Cogs will no longer be able to directly sample the counters at full instruction speed. They certainly won't be CogRAM mapped. I'm not too sure what Chip has in mind here using the PINx/DIRx signalling. Will the instructions stall on a read?
While they are likely to be in pairs, any pairing arrangements will be in addition to the 64x effect. The bulky things like configuration and buffers and shifters and adders will be on a per pin basis. Otherwise, something like the counters would have to stay in the Cogs.
.
I'm not following.
The Multiplier is not locked to the pin count, but to the number of Pin-Peripheral-Blocks that are implemented.
Buffers and shifters will be in the Pin-Peripheral-Block, they do not have to be duplicated in every single pin.
Buffers and shifters will be in the Pin-Peripheral-Block, they do not have to be duplicated in every single pin.
But they will be on every pin if the spec of 64 ADCs is maintained. Either that or there has to be more routing added to link the pins to the counters for example.
Buffers are buffers, more engines demand more buffering. Tx/Rx shifters tend to want to be independent but it's true they don't have to be.
ADC's I understood to be part of the full-custom pin design, not in Verilog.
ADC's are not complete without the counters. The earlier Prop2 design was to have the Cog based counters time multiplex however many ADC pins into a single counter as desired.
EDIT: With the original design only being a first order design, same as Prop1 circuits, having the counters in the Cogs was okay. However, I think, the frequency performance of a multi-order ADC design can only be achieved when not multiplexed. I'd forgotten this detail just before. This is another potential advantage of having the counters in the SmartPins.
Note that the COG counter is a pair of counters, so that cell can support two pins, assuming it is the counter used for ADC.
ADCs/DACs may have their own logic, so they do not have to link into another block.
The DAC's have a higher bandwidth pathway, and there were requests to have that pathway work on Read as well
(for things like camera grabs & fast Logic-in)
I'm somewhat curious about the cog<->pin serial links. From my understanding, maximum clock rates in an IC aren't simply determined just by the process node, but also by the complexity of the circuit. In that case, can't some sub-circuits be decoupled and operate at different clocks from others (assuming it's not going beyond the theoretical max for that process)? I'm making an assumption here, but aren't serial transceivers simpler than a CPU's core logic and thus be able to operate at a higher frequency? So why should, say, a 32-bit long require 32 CPU clocks when sent over the serial link, instead of some fraction of that? It might come in handy to send or receive a message between the pins and cogs at some rate greater than clk/32 (or whatever the message length is).
... The DAC's have a higher bandwidth pathway, and there were requests to have that pathway work on Read as well (for things like camera grabs & fast Logic-in)
Hmm, it is possible to have preferential fast access to SmartPins registers of the nearby 4 pins I guess. Not too sure if it could justify the extra real-estate though.
EDIT: I can see the programming appeal of this one. It gives an alternative way where MSG may not have worked. The flipside is it also "gives an alternative way" to be confused about SmartPins ...
Good question. It would be doable to maybe double the clockrate. But that does require another set of clock resources and this clock will be geographically spread all the way around the silicon to reach all the SmartPins and all the Cogs as well.
Probably more importantly, it doesn't prevent instruction stalls.
So an additional PLL which feeds its signal to every pin and cog. I don't know if that would actually be a routing nightmare, as I imagine one wire running around the periphery with an interconnect to every pin. Maybe it doesn't work that way.
Still, looking at chips manufactured on the 180nm process, some of them went above 1GHz, so I'd have to imagine there's a nice margin there to increase the clock at some sub-circuits, considering the P2 is likely going to be clocked at less than 200MHz.
I don't see why it would cause instruction stalls, or at least any more than the intended design will. You mov the value to the tx register and it sends it off. Not sure how current requests will work.. Stall until the data comes in?
A number of small MCUs currently shipping, allow some peripherals to clock faster than the CORE.
Typically 4x~8x to get better PWM resolution.
Usually you use one PLL and different dividers.
The Prop PLL likely already runs > 2x fSys - 300MHz to 1GHz is common for MCU PLLs, and they divide that down to give 50% duty cycle (on the highest used CLK ) which allows better specs.
Interesting. If accurate, then it definitely sounds like something worth looking into as it substantially increases message throughput.
Comments
It is probably worthwhile to list significant market areas :
3 Phase PWM needs dead-band settings and 6 pins driven, with a fault in pin for current trip.
Some I think can read hall sensors.
External Clock, and capture needs 2 pins
Std D-FF ADC needs 2 pins, with option of 2nd output, for 3 pins
Reciprocal counting needs 2 counters (one on Time, one on Cycles), Atomic control, & triggered capture, but needs just 1 pin.
It may make sense to Pair pins,
As @jmg said the capture part is what is somehow missing on the P1 and I hope some support for that can go to the smart pins. One long asked whish was to be able to clock in stuff with the video circuit instead of just clocking out.
The same applies IMHO to I2C and SPI also. Currently a SPI slave (external clock) is sort of cumbersome to program and quite slow compared to - say - SPI out with the video circuit..
So support for serialization (sync or async) for input and output is quite important. Some features will require pin pairs so this needs to be addressed. I am not asking for SPI in hardware or full blown UARTS, Just some shift register inputting from a pin with optional clock on another pin.
yeah. just dreaming here. We will see what @Chip comes up with. But running independent Subsystems on pin(pairs) parallel to 16 cogs sounds very nice to me.
Enjoy!
Mike
I have been reading through the forum, and I am interested in the "smart pin".
What apps are being planned for the these smart pins? The other threads
give me a indication of the function of the pin; That it could be used as
some kind of Neural interface? In reference to all the functions that surround it.(?)
Just a thought....
Prior discussion with Chip was that we'd announce the seminar date when we had our own, functional Propeller 1-2-3 FPGA board. I'll check with him to see what his latest thoughts are on this detail.
He's getting better at estimating his development time now that he's been through this particular design more than twice.
Ken Gracey
It's basically a counter/ADC/DAC/SPI/video generator/etc. per pin that replaces the per-cog counters and video generator.
and now would like to upgrade to more speed and features.... It seems the P-2 has been
“on the stove”, “in the works”... for a long time. Soooo?? Six months? / a year?
You must have some Idea .
I really don't want to design my new project around a PIC (but they are fast, cheap, and
have lots of features.)
Bill
Good quote. Have to remember it.
The design attempts have been going on for six years plus now with no end in sight.
Over the decades I learned one thing about tech companies. They say a lot of things but until they deliver on what they say with a real product, it's vaporware. You don't bet the farm on something that doesn't yet exist..
We are all pulling our last grey hairs out in anticipation.
If you know the play "Waiting for Godot", that is what we are up against.
To be fair though, the target date was only ever set and missed once. And that wasn't six years ago.
To speculate, my fingers are still crossed for end of this year. I don't see Chip making dramatic changes to the FPGA releases from user testing input. It'll mostly be a bug checking exercise and for the users it offers the obvious early release development opportunity.
And finally, the question of ROM size and boot features. He's already had a successful outing with first Prop2 attempt so may not add much here, just massage it for this Prop2 design, dunno.
I'm not sure you can expect a x64 effect.
The Smart Pin Cell will cover Serial and Counters & PWM, and in most practical uses, those at least pair pins.
(SPI needs 3-4)
Candidates are likely to be 32x or 16x or maybe 24x , or even some other die-determined number.
16x seems light*, 64x or even 32x may not fit, opening up some other number.
* 16x may be more tolerable, if CellN.Serial use on some pins, also allows CellN.Counter use on others.
However that implies more Multiplex complexity.
A Pin Cell that has Tiny Fifo and Config for a choice of ONE-OF peripheral would have a simpler register interface, and less Multiplex demand.
Either that or the spec has to change to, say, 32 ADC channels across 64 pins.
It has some advantages though:
1: As Chip has said, the decoupling makes his design work easier.
2: It also means that the counter resources are not Cog bound. If you are wanting to manage, say, 8 channels from one Cog then the Prop2 design makes that a piece of cake.
One detail that, Phil in particular, might be concerned about is that Cogs will no longer be able to directly sample the counters at full instruction speed. They certainly won't be CogRAM mapped. I'm not too sure what Chip has in mind here using the PINx/DIRx signalling. Will the instructions stall on a read?
The Multiplier is not locked to the pin count, but to the number of Pin-Peripheral-Blocks that are implemented.
Buffers and shifters will be in the Pin-Peripheral-Block, they do not have to be duplicated in every single pin.
ADC's I understood to be part of the full-custom pin design, not in Verilog.
That makes them outside any Pin-Peripheral-Block mapping decisions.
Buffers are buffers, more engines demand more buffering. Tx/Rx shifters tend to want to be independent but it's true they don't have to be.
ADC's are not complete without the counters. The earlier Prop2 design was to have the Cog based counters time multiplex however many ADC pins into a single counter as desired.
EDIT: With the original design only being a first order design, same as Prop1 circuits, having the counters in the Cogs was okay. However, I think, the frequency performance of a multi-order ADC design can only be achieved when not multiplexed. I'd forgotten this detail just before. This is another potential advantage of having the counters in the SmartPins.
Note that the COG counter is a pair of counters, so that cell can support two pins, assuming it is the counter used for ADC.
ADCs/DACs may have their own logic, so they do not have to link into another block.
The DAC's have a higher bandwidth pathway, and there were requests to have that pathway work on Read as well
(for things like camera grabs & fast Logic-in)
Hmm, it is possible to have preferential fast access to SmartPins registers of the nearby 4 pins I guess. Not too sure if it could justify the extra real-estate though.
EDIT: I can see the programming appeal of this one. It gives an alternative way where MSG may not have worked. The flipside is it also "gives an alternative way" to be confused about SmartPins ...
So an additional PLL which feeds its signal to every pin and cog. I don't know if that would actually be a routing nightmare, as I imagine one wire running around the periphery with an interconnect to every pin. Maybe it doesn't work that way.
Still, looking at chips manufactured on the 180nm process, some of them went above 1GHz, so I'd have to imagine there's a nice margin there to increase the clock at some sub-circuits, considering the P2 is likely going to be clocked at less than 200MHz.
I don't see why it would cause instruction stalls, or at least any more than the intended design will. You mov the value to the tx register and it sends it off. Not sure how current requests will work.. Stall until the data comes in?
Interesting. If accurate, then it definitely sounds like something worth looking into as it substantially increases message throughput.