A thought on the issue of CTR's (which I agree are needed) and the PLL's -- is there any possibility of fixing the feedback problem that causes the PLL's to jitter so that they could be made to output a spectrally clean radio signal?
From what I understand, no: it'll only get worse, since all outputs have to be synchronized to the system clock. That said, however, you could probably generate a more spectrally-pure sine wave using the DACs, since the amplitude can be computed for whatever the desired phase is at the system clock edges. I'm not sure how or if this would work at frequencies greater than a ponderable submultiple of the system clock -- and probably not at all above the system clock frequency.
I wonder the same things, too, but Phil Pilgrim is absolutely adamant that we must keep them.
There is a smidge of hypocrisy here. How many times has Phil insisted that either Chip should decide everything or else commercial users should decide everything?
It would seem so, wouldn't it? I've also said that I'm perfectly content to continue using the P1 if its successor lacked the counters. I'm not a commercial user, but I like to fantasize that some of the work I've contributed to the forum may end up in commercial designs here and there.
A thought on the issue of CTR's (which I agree are needed) and the PLL's -- is there any possibility of fixing the feedback problem that causes the PLL's to jitter so that they could be made to output a spectrally clean radio signal?
The Counter-PLLs are analog cells, so it is unclear if they are in the FPGA/Verilog at all.
If they were somehow able to be preserved and patched-into the layout, then a separate path would be needed to the pin driver,
that avoided any Sys-Clk sampling effects.
With Clock devices designed to create spectrally clean radio signals, I would expect this need to be a shrinking niche.
eg a SiLabs Si504 is not expensive , and takes a simple 32 bit real to set Fo (32KHz~100MHz) and a 16 bit integer as an offset.
It is your insistence that the rest of us should pound rocks that rankles, Phil.
Hey, I put myself in the same category as "the rest of us." I don't think it should matter to Chip what I think, since I'm neither a qualified chip designer nor a volume user. That does not, of course mean that I lack an opinion from time to time; and it's okay for me to say that I like the counters, and here's how I use them. But I'd be perfectly content to ignore this whole messed-up design process again until there's deliverable silicon. As I said, I'm generally happy with the P1 and haven't nearly exhausted its potential. It's our bird in the hand; the rest, so far, is just colored smoke.
For me NEGC, NEGNC, NEGZ, NEGNZ are instructions that are not often used and can be replaced with:
if_c NEG D,S
if_nz NEG D,S ...etc
That does the same if D and S point to the same register, otherwise it needs an additional MOV D,S before.
Another idea to reduce the instructions: It may be enough to use only PTRB as a call-stack pointer.
Then all the CALLA #, CALLA @, CALLA D, RETA, can be removed. I would keep POPA and PUSHA so that PTRA can still be used for a Datastack.
Will all the WAITxxx and MSGINA/B instruction behave like in the Prop2 in task mode (jump to itself)? Are tasks really necessary when we have 16 cogs?
Andy
What NEGC does, though, is absolutely write something. Substituting a conditional NEG instruction wouldn't be the same for some cases.
I thought, too, that we only need one stack, but it's nearly zero logic to support two stacks and we have the opcode space to do so. You wouldn't want more than one hubexec task, anyway, since the ICACHE would stutter like mad and there's only one AUGS/AUGD set of circuitry. AUGS/AUGD remember which task set them up, so they do their thing on the proper task. This means any task can be hub exec, but there'd better be only one if you want ICACHE efficiency and use of AUGS/AUGD.
There are no more multi-personality wait/loop instructions, though there probably ought to be for WAITVID, so that other tasks can continue when one is doing a WAITVID.
Tasks are necessary to allow some types of applications to run in single cogs.
Hey, I put myself in the same category as "the rest of us." I don't think it should matter to Chip what I think, since I'm neither a qualified chip designer nor a volume user. That does not, of course mean that I lack an opinion from time to time; and it's okay for me to say that I like the counters, and here's how I use them. But I'd be perfectly content to ignore this whole messed-up design process again until there's deliverable silicon. As I said, I'm generally happy with the P1 and haven't nearly exhausted its potential. It's our bird in the hand; the rest, so far, is just colored smoke.
-Phil
Phil, thanks for your input on how you use the CTRs. Would you like to offer any suggestion on what can be done to augment them in some useful ways, while keeping them simple like they are?
Phil, thanks for your input on how you use the CTRs. Would you like to offer any suggestion on what can be done to augment them in some useful ways, while keeping them simple like they are?
Do you mean here COG Counters, or Pin Counter-Cells ?
Are COG counter in, or out, or tbf ?
Phil, thanks for your input on how you use the CTRs. Would you like to offer any suggestion on what can be done to augment them in some useful ways, while keeping them simple like they are?
If I may extend my hypocrisy even further , two things do come to mind immediately:
1. The logic modes could be enhanced to provide stateful or gated clocking, e.g. count on A's rising edge, only when B is high. The ultimate extension of this would include both up and down counting for full quadrature decoding.
2. Include the internal output of one counter among the input options for the other. (I had an app for this a long while back, but I can't now remember what it was.)
Having to synchronize all outputs to the system clock does cripple clock functions somewhat since you can't output the PLL directly. I might also have suggested true divide-by-n indirect frequency synthesis, but that's rather pointless now. I guess it would still be possible to include a max-count register that forced the counter to roll over and toggle before it reached $ffff_ffff.
Would have to do two if's
if_c NEG D,S
if_nc MOV D,S
As there is only 496 longs, any opcode that single handedly can do the job of two if_xx is always welcome
That's right if D and S are different registers. Then the NEGC is a move and a negate at the same time.
But my observation is that this is a rare case, mostly you have calculated a result in a register and need to negate it according a flag.
And then
NEGC result,result
can be replaced by the single instruction:
if_c NEG result,result
I don't say the NEGx should be removed now, but they would be the first I would remove when we need the space.
What I missed often in the P1 counters is a Prescaler. Now the counters run always with the systemclock frequency. For DUTY and FB modes this is sometimes too fast. It would be nice if the FRQ->PHS accumulation could run also with 1/2, 1/4, ..1/16 of the sysclock.
>But my observation is that this is a rare case, mostly you have calculated a result in a register and need to negate it according a flag
I could see a use of setting up a value +- , based on c.
NEGC register,#128
Out of 684 Spin files in my projects directory, 110 use counters in one fashion or another. Counters are the lifeblood of the Propeller. I guess if the P1+/P2 didn't have any, I would happily continue to use the P1.
Even with something as simple as pos w/feedback counter mode, you can build a very sensitive amplifier capable of receiving radio signals directly or the raw output from an ultrasonic transducer. This has become a basic building block for several Propeller projects. With two counters programmed in logic mode (XOR), a very flexible set of I/Q mixers can be constructed. This, again, has become a basic building block for my apps.
If anything, I would like to see additional counter modes and ways to link multiple counters. The main thing is to keep things simple, not "smart." The more and simpler building blocks one has at his disposal, the more creative he can be. The counters, in their present state, with ready access to all their registers, fill that requirement to a "T".
-Phil
Phil,
I loved your programs using the counters. They were Brilliant and well documented !
So, which ones could not use the Intelligent Pins ?
Could the intelligent pins have these parts added ?
What parts need to be in the cog ?
BTW I don't see your comments as any more hippocratic than most of us. Most of us campaigned for P2 extras and then countered with wanting to go back to the P16X32B.
So, which ones could not use the Intelligent Pins ?
Could the intelligent pins have these parts added ?
What parts need to be in the cog ?
Another useful indicator would be how large are the Present COG counters, and their Pin-Alloc MUXs ?
I see a strong backward-compatible argument for keeping only P1 features in COG-CTR, and expanding other uses at the Pins.
There is a 32b Adder in a COG-CTR, that can be saved from the pins, if COG-CTR is reserved for NCO tasks.
This will make the pins faster, and smaller. (removes 32b Adder+Mux)
There is also an argument for keeping the D-Side muxes down on Counters, to keep MHz higher.
It may allow 200MHz to be reached, with a split of the NCO task.
( I moved this from smart pin) >Chip could do a 'reality check' with OnSemi, to confirm his fuses are still the smallest/cheapest/(lowest risk) way to do some config?
He sure should,
Imagine cog-one has 512 longs of Sonos that is transferred to its Cog-ram in 100ns, It will be the instant-on BIOS
Just filling in the Special Registers maybe be enough to set a instant (pull-down/up) pin state, if not the first 4 instructions will do that.
The rest is the boot loader and monitor, but if you have a 7v programmer it can all be customized over and over !
Pros with SONOS technology is its ease of integration in CMOS (only two additional masks).
This allows the NV cell to be located immediately adjacent to the 6T SRAM cell in each memory bit making the transfers between SRAM to NV all happen in parallel and at very low power levels.
Chip,
You got rid of ADDS, but kept ADDX and SUBX. I think we need ADDS more than the X variants. Signed addition (and thus subtraction because it's signed) is way more useful than ADDX/SUBX in my opinion.
I guess it would still be possible to include a max-count register that forced the counter to roll over and toggle before it reached $ffff_ffff.
-Phil
I was asking for something like this, a "PhsaMax" value on posedge counting, at which a pin will toggle high then low, resetting Phsa and starting over.
I was asking for something like this, a "PhsaMax" value on posedge counting, at which a pin will toggle high then low, resetting Phsa and starting over.
In the Pin-cells this should be possible, as Chip has mentioned Pin-PWM is like this
if X == 0 then X=frame_count and Y=on_time, else (X--, if Y<>0 then Y--) ; pin output = Y<>0
That has 2 reload values, on down counters, one of which saturates.
With all the things coming from P2, (hopefully it is the simple, low silicon and low power pieces) maybe we might get COGNEWX/COGRUNX where we can start a cog in hubexec mode - that gives virtually instant on.
> we can start a cog in hubexec mode - that gives virtually instant on.
But it will run a default cog code every time (may even have bugs in it), with Cypress SONOS that copies itself to the cog in under 100ns the options would be:
The user have changed the instant default pin state to his/her needs and if a expert the user have also modified the boot loader to specific storage used.
Set AES key for code stored encrypted on external memory device, as another cog can not read another cogs ram and it never passed through the hub improves security.
Set a serial number or a macid etc etc,
As SONOS hardly adds any horizontal die space so why not add it to all 16 cogs (or even hub)? many applications would have no need for spi-flash then.
And Chip can work on the default boot code after P1+ have been sent to the fab.
The ultimate extension of this would include both up and down counting for full quadrature decoding.
-Phil
Such a perfect real-time device without quad-decode on the counters baffles me. More and more of the serious automation machinery out there in the real world relies on servo motors with quadrature encoder feedback (okay there is also SSI BiSS, Endat, etc.) and we are talking multi MHz frequencies. The micro-controller that I have been using since the late '80's (I've shipped thousand+) can handle 16 quadrature encoder inputs, each at 15MHz.
Such a perfect real-time device without quad-decode on the counters baffles me. More and more of the serious automation machinery out there in the real world relies on servo motors with quadrature encoder feedback (okay there is also SSI BiSS, Endat, etc.) and we are talking multi MHz frequencies. The micro-controller that I have been using since the late '80's (I've shipped thousand+) can handle 16 quadrature encoder inputs, each at 15MHz.
Which micro-controller has 16 x 15MHz Quad channels ?
How does it set the Quad State engine sample rate, or is that fixed ?
Chip has mentioned Quad Counting, & it was in P2, so it will likely be in the Pin Cell.
To address the distribution and listing issue, Parallax's strategy moving forward with P2 is to focus on three distributors exclusively (Mouser, Digi-Key and RS Components).
I've been rattling the cages of Premier Farnell / Element 14 / Newark.com for the past 12 months on the subject of stocking your products. They're my preferred supplier because they're 45 minutes from my door and will do almost 24/7 will-call :-)
When I first started harassing them they sold propellers in DIP and QFP for $35 each with a $20-per-order freight charge. Not kidding. Then they made the mistake of inviting me into one of their focus groups and I beat on them mercilessly for months (which they ignored). Then, every time I placed an order for a propeller related project I copied them on the mouser invoice with the comment "If you sold the Prop you would have gotten this". After 5 or 6 of those they finally relented and now...
"Supplier Direct Ship Continental US Only Non-Cancelable / Non Returnable
Ships within 2-3 business days for in stock items" and priced at $8.49.
So, as I understand it they add $1 to the price and then pass the order direct to parallax for fulfilment.
It's progress I guess, but I really wish they would REALLY stock it so I could fulfil my 5pm on a friday "need a prop" itch.
Just to clarify though Ken - if their buyer comes to you guys you would actually sell and let them stock right? Your deal with Mouser / Digi / RS doesn't preclude other suppliers?
1 - Would it be practical to add counters to the hub that could be used by any cog?
2 - Has any P1 application ever made use of all 16 counters?
3 - If 1 is possible could a number of shared hub counters work in conjunction with the smart pins to provide as much or more functionality than the current P1 counters do?
> we can start a cog in hubexec mode - that gives virtually instant on.
But it will run a default cog code every time (may even have bugs in it), with Cypress SONOS that copies itself to the cog in under 100ns the options would be:
The user have changed the instant default pin state to his/her needs and if a expert the user have also modified the boot loader to specific storage used.
Set AES key for code stored encrypted on external memory device, as another cog can not read another cogs ram and it never passed through the hub improves security.
Set a serial number or a macid etc etc,
As SONOS hardly adds any horizontal die space so why not add it to all 16 cogs (or even hub)? many applications would have no need for spi-flash then.
And Chip can work on the default boot code after P1+ have been sent to the fab.
You can bet SONOS is patented and requires $ per chip.
ROM Boot is way more secure.
1 - Would it be practical to add counters to the hub that could be used by any cog?
2 - Has any P1 application ever made use of all 16 counters?
3 - If 1 is possible could a number of shared hub counters work in conjunction with the smart pins to provide as much or more functionality than the current P1 counters do?
The smart pins can already "provide as much or more functionality than the current P1 counters do".
A main driver for keeping a COG-Counter is for backward compatibility, moving to hub access would break that, so one may as well stick with the pin-cell counters - they can be shared.
Where looking at a hub-located Counter pool could make sense, is if
a) The RW bandwidth of the Pin cells is deemed to be too slow
b) The Pin Cells come out of sim as too costly, in either Power or Area.
Counter to pin mapping would be needed, but that is also needed in COG counters, but the new counters need 3 possible pins, std COG ctrs have 2 pin fields.
Pin Cells do not need pin-mapping, (use adjacent pins for extras) but the Software does need to specify which address to use.
Access to HUB counters would be slower than COG counters, but faster than Pin Cells.
Hub-located counters would allow almost any number, eg 24 or 32 or 48, without making pins no longer identical.
There may be a 'hybrid' solution ? - by the time you route wires from every pin to counters, and then do a Nx3 MUX, it might be less area to simply run a parallel bus around all the pins - a 32b Muxed bus would fit in 35 wires (tristated).
Access would be time shared, like the HUB is now.
That approach would give Pin cells physically located at the pins, but accessed on a memory map method like the HUB, so from a Data viewpoint, they would look to be 'in the HUB' - even tho they are at the pins.
Chip will know the relative die routing costs of COG_Ctrs, vs a Block of Counters located in the hub, vs running a parallel bus round all the pin-located Counters.
I want the ROM, and it should be worked out before we fab. That way the code protect, and the basic init process is solid, trusted and easily understood.
Comments
From what I understand, no: it'll only get worse, since all outputs have to be synchronized to the system clock. That said, however, you could probably generate a more spectrally-pure sine wave using the DACs, since the amplitude can be computed for whatever the desired phase is at the system clock edges. I'm not sure how or if this would work at frequencies greater than a ponderable submultiple of the system clock -- and probably not at all above the system clock frequency.
-Phil
It would seem so, wouldn't it? I've also said that I'm perfectly content to continue using the P1 if its successor lacked the counters. I'm not a commercial user, but I like to fantasize that some of the work I've contributed to the forum may end up in commercial designs here and there.
-Phil
The Counter-PLLs are analog cells, so it is unclear if they are in the FPGA/Verilog at all.
If they were somehow able to be preserved and patched-into the layout, then a separate path would be needed to the pin driver,
that avoided any Sys-Clk sampling effects.
With Clock devices designed to create spectrally clean radio signals, I would expect this need to be a shrinking niche.
eg a SiLabs Si504 is not expensive , and takes a simple 32 bit real to set Fo (32KHz~100MHz) and a 16 bit integer as an offset.
-Phil
What NEGC does, though, is absolutely write something. Substituting a conditional NEG instruction wouldn't be the same for some cases.
I thought, too, that we only need one stack, but it's nearly zero logic to support two stacks and we have the opcode space to do so. You wouldn't want more than one hubexec task, anyway, since the ICACHE would stutter like mad and there's only one AUGS/AUGD set of circuitry. AUGS/AUGD remember which task set them up, so they do their thing on the proper task. This means any task can be hub exec, but there'd better be only one if you want ICACHE efficiency and use of AUGS/AUGD.
There are no more multi-personality wait/loop instructions, though there probably ought to be for WAITVID, so that other tasks can continue when one is doing a WAITVID.
Tasks are necessary to allow some types of applications to run in single cogs.
Phil, thanks for your input on how you use the CTRs. Would you like to offer any suggestion on what can be done to augment them in some useful ways, while keeping them simple like they are?
if_c NEG D,S
if_nc MOV D,S
As there is only 496 longs, any opcode that single handedly can do the job of two if_xx is always welcome
Do you mean here COG Counters, or Pin Counter-Cells ?
Are COG counter in, or out, or tbf ?
2. Include the internal output of one counter among the input options for the other. (I had an app for this a long while back, but I can't now remember what it was.)
Having to synchronize all outputs to the system clock does cripple clock functions somewhat since you can't output the PLL directly. I might also have suggested true divide-by-n indirect frequency synthesis, but that's rather pointless now. I guess it would still be possible to include a max-count register that forced the counter to roll over and toggle before it reached $ffff_ffff.
-Phil
That's right if D and S are different registers. Then the NEGC is a move and a negate at the same time.
But my observation is that this is a rare case, mostly you have calculated a result in a register and need to negate it according a flag.
And then
NEGC result,result
can be replaced by the single instruction:
if_c NEG result,result
I don't say the NEGx should be removed now, but they would be the first I would remove when we need the space.
Andy
Thanks
Alex
Andy
I could see a use of setting up a value +- , based on c.
NEGC register,#128
I loved your programs using the counters. They were Brilliant and well documented !
So, which ones could not use the Intelligent Pins ?
Could the intelligent pins have these parts added ?
What parts need to be in the cog ?
BTW I don't see your comments as any more hippocratic than most of us. Most of us campaigned for P2 extras and then countered with wanting to go back to the P16X32B.
Not a comparison, but Chip did a Summary that I expanded into Cell Modes here
http://forums.parallax.com/showthread.php/155145-Putting-smarts-into-the-I-O-pins?p=1258273&viewfull=1#post1258273
Another useful indicator would be how large are the Present COG counters, and their Pin-Alloc MUXs ?
I see a strong backward-compatible argument for keeping only P1 features in COG-CTR, and expanding other uses at the Pins.
There is a 32b Adder in a COG-CTR, that can be saved from the pins, if COG-CTR is reserved for NCO tasks.
This will make the pins faster, and smaller. (removes 32b Adder+Mux)
There is also an argument for keeping the D-Side muxes down on Counters, to keep MHz higher.
It may allow 200MHz to be reached, with a split of the NCO task.
He sure should,
Imagine cog-one has 512 longs of Sonos that is transferred to its Cog-ram in 100ns, It will be the instant-on BIOS
Just filling in the Special Registers maybe be enough to set a instant (pull-down/up) pin state, if not the first 4 instructions will do that.
The rest is the boot loader and monitor, but if you have a 7v programmer it can all be customized over and over !
Pros with SONOS technology is its ease of integration in CMOS (only two additional masks).
This allows the NV cell to be located immediately adjacent to the 6T SRAM cell in each memory bit making the transfers between SRAM to NV all happen in parallel and at very low power levels.
http://www.cypress.com/?docID=45736
Agree. We need ADDS.
Ross.
I was asking for something like this, a "PhsaMax" value on posedge counting, at which a pin will toggle high then low, resetting Phsa and starting over.
In the Pin-cells this should be possible, as Chip has mentioned Pin-PWM is like this
if X == 0 then X=frame_count and Y=on_time, else (X--, if Y<>0 then Y--) ; pin output = Y<>0
That has 2 reload values, on down counters, one of which saturates.
But it will run a default cog code every time (may even have bugs in it), with Cypress SONOS that copies itself to the cog in under 100ns the options would be:
The user have changed the instant default pin state to his/her needs and if a expert the user have also modified the boot loader to specific storage used.
Set AES key for code stored encrypted on external memory device, as another cog can not read another cogs ram and it never passed through the hub improves security.
Set a serial number or a macid etc etc,
As SONOS hardly adds any horizontal die space so why not add it to all 16 cogs (or even hub)? many applications would have no need for spi-flash then.
And Chip can work on the default boot code after P1+ have been sent to the fab.
Such a perfect real-time device without quad-decode on the counters baffles me. More and more of the serious automation machinery out there in the real world relies on servo motors with quadrature encoder feedback (okay there is also SSI BiSS, Endat, etc.) and we are talking multi MHz frequencies. The micro-controller that I have been using since the late '80's (I've shipped thousand+) can handle 16 quadrature encoder inputs, each at 15MHz.
Which micro-controller has 16 x 15MHz Quad channels ?
How does it set the Quad State engine sample rate, or is that fixed ?
Chip has mentioned Quad Counting, & it was in P2, so it will likely be in the Pin Cell.
Don't you mean 80 cores? Can't leave the 16 cogs out of the count ;-)
I've been rattling the cages of Premier Farnell / Element 14 / Newark.com for the past 12 months on the subject of stocking your products. They're my preferred supplier because they're 45 minutes from my door and will do almost 24/7 will-call :-)
When I first started harassing them they sold propellers in DIP and QFP for $35 each with a $20-per-order freight charge. Not kidding. Then they made the mistake of inviting me into one of their focus groups and I beat on them mercilessly for months (which they ignored). Then, every time I placed an order for a propeller related project I copied them on the mouser invoice with the comment "If you sold the Prop you would have gotten this". After 5 or 6 of those they finally relented and now...
"Supplier Direct Ship Continental US Only Non-Cancelable / Non Returnable
Ships within 2-3 business days for in stock items" and priced at $8.49.
So, as I understand it they add $1 to the price and then pass the order direct to parallax for fulfilment.
It's progress I guess, but I really wish they would REALLY stock it so I could fulfil my 5pm on a friday "need a prop" itch.
Just to clarify though Ken - if their buyer comes to you guys you would actually sell and let them stock right? Your deal with Mouser / Digi / RS doesn't preclude other suppliers?
Red
2 - Has any P1 application ever made use of all 16 counters?
3 - If 1 is possible could a number of shared hub counters work in conjunction with the smart pins to provide as much or more functionality than the current P1 counters do?
ROM Boot is way more secure.
The smart pins can already "provide as much or more functionality than the current P1 counters do".
A main driver for keeping a COG-Counter is for backward compatibility, moving to hub access would break that, so one may as well stick with the pin-cell counters - they can be shared.
Where looking at a hub-located Counter pool could make sense, is if
a) The RW bandwidth of the Pin cells is deemed to be too slow
b) The Pin Cells come out of sim as too costly, in either Power or Area.
Counter to pin mapping would be needed, but that is also needed in COG counters, but the new counters need 3 possible pins, std COG ctrs have 2 pin fields.
Pin Cells do not need pin-mapping, (use adjacent pins for extras) but the Software does need to specify which address to use.
Access to HUB counters would be slower than COG counters, but faster than Pin Cells.
Hub-located counters would allow almost any number, eg 24 or 32 or 48, without making pins no longer identical.
There may be a 'hybrid' solution ? - by the time you route wires from every pin to counters, and then do a Nx3 MUX, it might be less area to simply run a parallel bus around all the pins - a 32b Muxed bus would fit in 35 wires (tristated).
Access would be time shared, like the HUB is now.
That approach would give Pin cells physically located at the pins, but accessed on a memory map method like the HUB, so from a Data viewpoint, they would look to be 'in the HUB' - even tho they are at the pins.
Chip will know the relative die routing costs of COG_Ctrs, vs a Block of Counters located in the hub, vs running a parallel bus round all the pin-located Counters.