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.
Chip was talking about removing counters entirely, but it may be a clone of P1 counters needs to stay for backward compatibility.
The COG counters have parallel access, whilst the Pin Counters are on a shared serial bus.
That makes them a little different to control.
The Pin-cell-counter is a very good idea, but if it comes as one-for-every-pin will probably not be known until area/power numbers are in.
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)
There are really only 2 that are important, CRC16 USB/IBM & CCITT.
However, I am quite happy for this to be done in sw if we can get a simple cog-cog direct access (either adjacent, or 64bit simple PortD style).
The fairly simple instruction I came up with that calcs a single bit CRC and combines the previous bit and current bit made for a huge improvement in receiving USB FS.
Again, I am happy to dedicate more cogs to FS USB since we have at least 16 cogs.
At this time, I am quite prepared to wait and see what Chip comes up with as the base.
Chip was talking about removing counters entirely, but it may be a clone of P1 counters needs to stay for backward compatibility.
The COG counters have parallel access, whilst the Pin Counters are on a shared serial bus.
That makes them a little different to control.
The Pin-cell-counter is a very good idea, but if it comes as one-for-every-pin will probably not be known until area/power numbers are in.
I didn't get the impression that the counters were going to be removed. Of course if there's going to be the equivalent of a counter on each pin there's little need to have counters dedicated to cogs.
I didn't get the impression that the counters were going to be removed.
I was going by this (and other) decouple comments Chip has made.
["Actually, the CTRs are one of the slowest-to-develop features of any Propeller. To decouple that mess from the cog is fantastic, because it simplifies the heck out of the cog design and allows the pin functions to be developed separately."]
Of course if there's going to be the equivalent of a counter on each pin there's little need to have counters dedicated to cogs.
From a Functional basis, yes, there is a very large amount of overlap.
The main difference I can see is not in the COG / Pin counter cells themselves, but more the means to access the registers.
(I've not seen a comment on the PLL in this thread, which is in a COG counter, but Chip has said elsewhere that PLLs are a problem given the clocked nature of all the pins now. ie a PLL may remove from a COG counter (if any) anyway )
The PLL detail is very hard to test in a FPGA.
I was going by this (and other) decouple comments Chip has made.
["Actually, the CTRs are one of the slowest-to-develop features of any Propeller. To decouple that mess from the cog is fantastic, because it simplifies the heck out of the cog design and allows the pin functions to be developed separately."]
Having trouble getting the quoting working the way I want it to. From Chip in the 8th post of the thread when responding to a question from Phil about what the "counter per pin" approach will take away from the per cog functionality.
"In the case of the Prop1 CTRs, perhaps nothing. I just didn't want to get stuck in the morass of complicating those counters to meet some higher expectations, like on the Prop2. There is a lot of interplay between CTRs and cogs, and to standardize what that is is soothing to my mind."
Rereading the posts in the thread it's hard to tell exactly what the plan is. I do think having a counter on each pin is a great idea and severely reduces the usefulness of the P1 counters in the cogs. (assuming all the modes of the cog counters are available in the per pin counters.
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 don't think there is any cause for concern, yet. I would think that the configuration/mode and registers, once set, would be static static and consume next to no power.
If you have 64 pins * 32 bit counters ALL toggling away, then thats 2048 flops, a comparable tally to the number of flops in a P1E cog. And that's not factoring how many flops will get removed from the 16 cogs * 2 counters.
The architecture isn't clear yet. For some modes it would be better to have a counter in the cog, and for others the counter on the pad is better. Have both? And just use the one best suited according to mode? - wouldn't necessarily was power if one or the other is being used.
We need to keep an open mind on this for now while Chip looks at how to slice it
Rereading the posts in the thread it's hard to tell exactly what the plan is. I do think having a counter on each pin is a great idea and severely reduces the usefulness of the P1 counters in the cogs. (assuming all the modes of the cog counters are available in the per pin counters.
Chips list includes this
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
Of those, NCO needs the 32 bit adder which is in the COG Ctr, but does not have to also be in a Pin-Counter designed for true PWM and Capture. A 32 bit adder has some silicon cost.
If I map those modes, to a Cell control function, I get something like
Operation Mapping A Mapping B Software
--------------------+-------------------+---------------+--------------
PWM ReloadA : PeriodV ReloadB : PwmV
DUTY CaptureA : =\_ CaptureB : _/= (A-B')/(B-B')
time positive edges CaptureA : _/= CaptureB : _/=
time negative edges CaptureA : =\_ CaptureB : =\_
time highs CaptureA : _/= CaptureB : =\_ B-A
time lows CaptureA : =\_ CaptureB : _/= B-A
count positive edges ExtClkA : _/=
count negative edges ExtClkA : =\_
count highs ClockENA : H
count lows ClockENA : L
Quadrature A/B (A/B => ClockENA & DirnA, Uses adjacent pins.
NCO tnf, needs 32b Adder
PWM is DownCounter & Saturate, others are UpCounter, except Quadrature.
and some can combine, so for my earlier FreqCounter, it uses
ExtClkA : _/=, ClkB = fSYS, (CaptureA : _/= CaptureB : _/=) Atomic SW enabled
If you have 64 pins * 32 bit counters ALL toggling away, then thats 2048 flops, a comparable tally to the number of flops in a P1E cog. And that's not factoring how many flops will get removed from the 16 cogs * 2 counters.
They are binary counters, (except in NCO case) so they toggle progressively slower, so each Bin counter == just 2 100MHz FFs,
in Cpd terms.
There will be clock tree Cpd, but this can be a compact cell on the clocked registers layout.
They are binary counters, (except in NCO case) so they toggle progressively slower, so each Bin counter == just 2 100MHz FFs,
in Cpd terms.
There will be clock tree Cpd, but his can be a compact cell on the clocked registers layout.
Good point, though there will likely be other ways of using the count register, such as UART or perhaps lookup table.
Anyway my point is, after running some basic calculations, I don't think we should be too worried about the area or power consumed just 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)
Out of the 64 I/O's you might have 1/4 of them in some smart mode, so I don' think the power is going to be that prominent. If all 64 pin brains were busy, it might be the additional equivalent of 2 extra cogs' worth of power. The big thing to consider here is that there are NO long nets in those pin brains, unlike a cog that has RAMs and talks to the hub. Pin brains are little self-contained beasties whose only output into the core is their pin's IN signal. They run entirely off of their pin's DIR and OUT inputs. I love that these can be developed and enhanced without ever touching the cog Verilog. This is like not letting the tail wag the dog.
... Pin brains are little self-contained beasties whose only output into the core is their pin's IN signal. They run entirely off of their pin's DIR and OUT inputs. I love that these can be developed and enhanced without ever touching the cog Verilog. This is like not letting the tail wag the dog.
Do you have MHz Sims on these yet ?
Do you plan to remove the COG counters, or intend to keep those for backwards compatibility ?
Because NCO is the only mode that needs a wide adder, for fun I tried a 32 bit Pin Cell in Verilog with
Booleans of SynRST/Enable/Dirn/Saturate and words of SwWrite/Reload
That will do all of the modes listed above. No prescale needed for PWM, with 32b Cell.
Then I edited one for +1 or +32b Field
Lattice tools say the variant with wide 32b Adder is ~ 20% larger, and ~ 9% slower.
That is just the 32b Counter being measured, so the % impact of a total pin cell will be less, especially if only one counter gets NCO.
I guess if these come in as compact, low power and easily meet 200MHz then adding NCO to the Pin, is an easier decision than if they struggle to make 200MHz target, and are larger.
hehe - I just saw pin brains - great description, with some slang content
I just checked and there are a lot of things called variants of "Smart I/O". This is the kind of thing that is probably heavily trademarked and has lots of patents circling overhead like vultures. I would stay clear of any kind of naming convention like that because it could just attract the wrong kind of attention. Remember, EVERYTHING is already patented. Better to look weird than act like a player.
I think you'd have a reasonable chance if you went for "smart i/o" - which can be considered a generic description. But SmartIO may be taken/trademarked
I just checked and there are a lot of things called variants of "Smart I/O". This is the kind of thing that is probably heavily trademarked and has lots of patents circling overhead like vultures. I would stay clear of any kind of naming convention like that because it could just attract the wrong kind of attention. Remember, EVERYTHING is already patented. Better to look weird than act like a player.
You can stay descriptive with phrases like
"Counter smarts at every pin" (assuming it does get one cell every pin )
If the counter Pin Cell turns out to be compact and fast, you might want to think about a smaller version of this device.
So we need a basic thing like "COG" only for the pins. "Terminal" comes to mind, in a sense where the I/O data to move across the pin is queued, sorted, scheduled, counted, processed, etc... and the track, carries the data to and from the COG...
My best guess, using classic terms as we've done so far.
So we need a basic thing like "COG" only for the pins. "Terminal" comes to mind, in a sense where the I/O data to move across the pin is queued, sorted, scheduled, counted, processed, etc... and the track, carries the data to and from the COG...
My best guess, using classic terms as we've done so far.
Just a thought but, if the pin-based counters are going to be so powerful, do the COG core based ones need to retain all of their existing features?
According to the P1 datasheet...
Multi-function Counters
o Configurable state machines generate or sense repetitive signals per clock cycle
o Measure frequency, detect edges, count cycles, D/A or A/D conversion, and more
o Operate autonomously with optional run-time monitoring and adjusting
o Two counters per cog
...now, to my mind, most of those are pin-orientated functions not core-orientated ones.
I recently released a game called Apple Dash. Thinking if anything the word Apple would get stopped! But no! Dash was the one that got stopped! Dash of all words, thanks to the likes of Diner Dash, my game was nothing like theirs, yet they still made us change the name! This is even with owning the UK "Apple Dash" tm, the problem I found out, is just because you own a TM in your country, if you sell world wide, you need to get the TM globally! which comes at a huge expense, at least for an indie developer!
And it would be an immense PITA if Parallax were to have to stop selling the "Turbo Prop" or whatever it's release name finally becomes.
Also, if it does get named Turbo Prop, I think the part name should be TP16X32B
Do you plan to remove the COG counters, or intend to keep those for backwards compatibility ?
Because NCO is the only mode that needs a wide adder, for fun I tried a 32 bit Pin Cell in Verilog with
Booleans of SynRST/Enable/Dirn/Saturate and words of SwWrite/Reload
That will do all of the modes listed above. No prescale needed for PWM, with 32b Cell.
Then I edited one for +1 or +32b Field
Lattice tools say the variant with wide 32b Adder is ~ 20% larger, and ~ 9% slower.
That is just the 32b Counter being measured, so the % impact of a total pin cell will be less, especially if only one counter gets NCO.
I guess if these come in as compact, low power and easily meet 200MHz then adding NCO to the Pin, is an easier decision than if they struggle to make 200MHz target, and are larger.
hehe - I just saw pin brains - great description, with some slang content
I think we need to keep the CTRs.
No Verilog work has been done for these circuits yet. You are way ahead of me.
Just a thought but, if the pin-based counters are going to be so powerful, do the COG core based ones need to retain all of their existing features?
According to the P1 datasheet...
...now, to my mind, most of those are pin-orientated functions not core-orientated ones.
[E2A]
I see jmg has wondered the same as well.
I wonder the same things, too, but Phil Pilgrim is absolutely adamant that we must keep them. I wish he would elaborate on why he feels this way. Phil?
The reason I asked was I was hoping they won't get rejected due to power consumption. With 32 bit counters, w can get insanely accurate PWM, time capture and much more.
The more I read about your smart pins, the more I liked them and want to use them
Out of the 64 I/O's you might have 1/4 of them in some smart mode, so I don' think the power is going to be that prominent. If all 64 pin brains were busy, it might be the additional equivalent of 2 extra cogs' worth of power. The big thing to consider here is that there are NO long nets in those pin brains, unlike a cog that has RAMs and talks to the hub. Pin brains are little self-contained beasties whose only output into the core is their pin's IN signal. They run entirely off of their pin's DIR and OUT inputs. I love that these can be developed and enhanced without ever touching the cog Verilog. This is like not letting the tail wag the dog.
do you have a feel for what percentage of a cog's die area and a cog's logic gates is taken up by the CTRs?
If is was found that everything that needed to be done could be done in the pin counters, would that help bring overall power down or even increase the number of COGs?
For me the, Prop1 was my first experience with micro-controllers. In all of the time I have been using the Prop1, I can honestly say that I have not once even wondered where the counters were located..
I don't care, I don't see why anyone else should care either… so there!
The most common issue that I run into with cog centric counters is that I only have two… I rarely run out of code space(simple mind… simple code)… but I frequently find myself having to start up a cog simply because I need additional counter functions.
Much of the time, you can simply do in code what the counter does for you… but then you slow down your cog.
Comments
Chip was talking about removing counters entirely, but it may be a clone of P1 counters needs to stay for backward compatibility.
The COG counters have parallel access, whilst the Pin Counters are on a shared serial bus.
That makes them a little different to control.
The Pin-cell-counter is a very good idea, but if it comes as one-for-every-pin will probably not be known until area/power numbers are in.
As that area are near edge and will have some bounding wires connected it will give that smart IO extra cooling -- simplifying heat problems
"Smart IO" That's it, brilliant. What an excellent catch phrase for the P2 product brief document.
However, I am quite happy for this to be done in sw if we can get a simple cog-cog direct access (either adjacent, or 64bit simple PortD style).
The fairly simple instruction I came up with that calcs a single bit CRC and combines the previous bit and current bit made for a huge improvement in receiving USB FS.
Again, I am happy to dedicate more cogs to FS USB since we have at least 16 cogs.
At this time, I am quite prepared to wait and see what Chip comes up with as the base.
I didn't get the impression that the counters were going to be removed. Of course if there's going to be the equivalent of a counter on each pin there's little need to have counters dedicated to cogs.
I was going by this (and other) decouple comments Chip has made.
["Actually, the CTRs are one of the slowest-to-develop features of any Propeller. To decouple that mess from the cog is fantastic, because it simplifies the heck out of the cog design and allows the pin functions to be developed separately."]
From a Functional basis, yes, there is a very large amount of overlap.
The main difference I can see is not in the COG / Pin counter cells themselves, but more the means to access the registers.
(I've not seen a comment on the PLL in this thread, which is in a COG counter, but Chip has said elsewhere that PLLs are a problem given the clocked nature of all the pins now. ie a PLL may remove from a COG counter (if any) anyway )
The PLL detail is very hard to test in a FPGA.
I don't think there is any cause for concern, yet. I would think that the configuration/mode and registers, once set, would be static static and consume next to no power.
If you have 64 pins * 32 bit counters ALL toggling away, then thats 2048 flops, a comparable tally to the number of flops in a P1E cog. And that's not factoring how many flops will get removed from the 16 cogs * 2 counters.
The architecture isn't clear yet. For some modes it would be better to have a counter in the cog, and for others the counter on the pad is better. Have both? And just use the one best suited according to mode? - wouldn't necessarily was power if one or the other is being used.
We need to keep an open mind on this for now while Chip looks at how to slice it
Chips list includes this
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
Of those, NCO needs the 32 bit adder which is in the COG Ctr, but does not have to also be in a Pin-Counter designed for true PWM and Capture. A 32 bit adder has some silicon cost.
If I map those modes, to a Cell control function, I get something like
They are binary counters, (except in NCO case) so they toggle progressively slower, so each Bin counter == just 2 100MHz FFs,
in Cpd terms.
There will be clock tree Cpd, but this can be a compact cell on the clocked registers layout.
Good point, though there will likely be other ways of using the count register, such as UART or perhaps lookup table.
Anyway my point is, after running some basic calculations, I don't think we should be too worried about the area or power consumed just yet.
Out of the 64 I/O's you might have 1/4 of them in some smart mode, so I don' think the power is going to be that prominent. If all 64 pin brains were busy, it might be the additional equivalent of 2 extra cogs' worth of power. The big thing to consider here is that there are NO long nets in those pin brains, unlike a cog that has RAMs and talks to the hub. Pin brains are little self-contained beasties whose only output into the core is their pin's IN signal. They run entirely off of their pin's DIR and OUT inputs. I love that these can be developed and enhanced without ever touching the cog Verilog. This is like not letting the tail wag the dog.
Do you have MHz Sims on these yet ?
Do you plan to remove the COG counters, or intend to keep those for backwards compatibility ?
Because NCO is the only mode that needs a wide adder, for fun I tried a 32 bit Pin Cell in Verilog with
Booleans of SynRST/Enable/Dirn/Saturate and words of SwWrite/Reload
That will do all of the modes listed above. No prescale needed for PWM, with 32b Cell.
Then I edited one for +1 or +32b Field
Lattice tools say the variant with wide 32b Adder is ~ 20% larger, and ~ 9% slower.
That is just the 32b Counter being measured, so the % impact of a total pin cell will be less, especially if only one counter gets NCO.
I guess if these come in as compact, low power and easily meet 200MHz then adding NCO to the Pin, is an easier decision than if they struggle to make 200MHz target, and are larger.
hehe - I just saw pin brains - great description, with some slang content
But for marketing @Sapieha nailed it - SMART IO.
Enjoy!
Mike
Every man and their dog claim to be able to do Smart IO... might be too Generic and anonymous.
'Smart Pins' would be more descriptive
I just checked and there are a lot of things called variants of "Smart I/O". This is the kind of thing that is probably heavily trademarked and has lots of patents circling overhead like vultures. I would stay clear of any kind of naming convention like that because it could just attract the wrong kind of attention. Remember, EVERYTHING is already patented. Better to look weird than act like a player.
You can stay descriptive with phrases like
"Counter smarts at every pin" (assuming it does get one cell every pin
If the counter Pin Cell turns out to be compact and fast, you might want to think about a smaller version of this device.
So we need a basic thing like "COG" only for the pins. "Terminal" comes to mind, in a sense where the I/O data to move across the pin is queued, sorted, scheduled, counted, processed, etc... and the track, carries the data to and from the COG...
My best guess, using classic terms as we've done so far.
I like "Smart IO", too.
According to the P1 datasheet...
...now, to my mind, most of those are pin-orientated functions not core-orientated ones.
[E2A]
I see jmg has wondered the same as well.
I recently released a game called Apple Dash. Thinking if anything the word Apple would get stopped! But no! Dash was the one that got stopped! Dash of all words, thanks to the likes of Diner Dash, my game was nothing like theirs, yet they still made us change the name! This is even with owning the UK "Apple Dash" tm, the problem I found out, is just because you own a TM in your country, if you sell world wide, you need to get the TM globally! which comes at a huge expense, at least for an indie developer!
And it would be an immense PITA if Parallax were to have to stop selling the "Turbo Prop" or whatever it's release name finally becomes.
Also, if it does get named Turbo Prop, I think the part name should be TP16X32B
I think we need to keep the CTRs.
No Verilog work has been done for these circuits yet. You are way ahead of me.
I wonder the same things, too, but Phil Pilgrim is absolutely adamant that we must keep them. I wish he would elaborate on why he feels this way. Phil?
The reason I asked was I was hoping they won't get rejected due to power consumption. With 32 bit counters, w can get insanely accurate PWM, time capture and much more.
The more I read about your smart pins, the more I liked them and want to use them
do you have a feel for what percentage of a cog's die area and a cog's logic gates is taken up by the CTRs?
If is was found that everything that needed to be done could be done in the pin counters, would that help bring overall power down or even increase the number of COGs?
I don't care, I don't see why anyone else should care either… so there!
Much of the time, you can simply do in code what the counter does for you… but then you slow down your cog.