To really save power, you need to stop all but one cog and then switch to RCSLOW mode while disabling the crystal oscillator and PLL. This will reduce consumption to about 8uA. Be sure no I/O pins are floating or sourcing current. Then, when the single cog wants to power back up, turn on the crystal oscillator and PLL, wait 10ms, then switch over to them. Then, turn your cogs back on.
The current Propeller is always going to be the one that easily lends itself to battery applications. It is fabricated in a low-leakage .35um process and its current can be reduced at runtime to just a few microamps.
The next Propeller might leak one whole milliamp, without even clocking. This is due to a leakier, albeit faster, .18um process.
If we were using a newer 45nm process, the leakage could run into the 100's of millamps. How would that be for progress?
The current Propeller will always be the one to use if you don't need higher performance.
Ym2413a said...
I guess this new chip also amounts more RF noise as well right?
You get more of everything! The pins will toggle slightly faster, so each pin would create more noise than a current chip's pin. It mainly comes down to how many pins are toggling and whether you provide any R, RC, or LC filtering for any long traces on your circuit board.
Are any of you interested in a low-EMI mode that would slow pin transitions way down?
Are any of you interested in a low-EMI mode that would slow pin transitions way down?
It's not that big of a deal to me personally I was just wondering, Maybe if such a mode does help save power (low power mode) then it would be something nice.
The RF issue is nothing a good old shielded enclosure couldn't fix and I think anyone who is worried about EMI would already have the idea of using a metal enclosure to keep RF out if anything.
Are any of you interested in a low-EMI mode that would slow pin transitions way down ?
This might be handy for certification of finished controllers PCB's / Machines ! It's pretty much the way 'others' do it - build their controller PCB - flash a moderate firmware version - get it certified .. once certified flash what you like .. It may sound deceptive but is common place.
The following is 'Slightly' Off topic but relevant to Certification and aforementioned Low-EMI mode.
Most industry sectors do it - Automotive industry 'detunes' engines at known Gov. test points to reduce emissions and increase fuel efficiency at these known test points 30mph,55mph and 70mph (europe anyway)
leading to a large industry dedicated to mildly 'remap' your engine - essentially negating these flat spots.
Performance Cars fitted with the likes of 'S' (Sport Mode) buttons that switch engine maps on the fly and open up flaps in the exhaust system - come with a warning 'Do not use on Public Roads' .... as if !
EDIT: Basically,in a long winded way, I am saying YES to the suggested 'low-EMI' mode ..
Regards,
John Twomey
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 'Necessity is the mother of invention'
Those who can, do.Those who can’t, teach.
Post Edited (QuattroRS4) : 9/3/2008 10:48:48 AM GMT
I have one question on START/STOP COGs and Restart.
It is posible att have it to STOP COG in midle of its program RUN and Restart on same position (Resume).
Samt one Restart that START COG with Address in it that I specify
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty.
There is the thing, huge latency on coming out of low power. Loading/Starting COGs, waiting for the clock to stabilize....
For example I have worked on battery powered devices that required to wake from a "medium power mode " on receiving a sync signal from a modem and then immediately start reading the serial data.
So the clocks needed to be running at a suitable rate even in a lowish (medium) power mode and state also needed to be preserved.
Then there was a real "low power mode" more as you describe.
So that what I was fishing for with WAITLOCK.
With what you say about leakage it may not be so much of a gain but still getting to a few milliamps is better than a few hundred.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Chip: "wait 10ms, then switch over to them"
There is the thing, huge latency on coming out of low power. Loading/Starting COGs, waiting for the clock to stabilize....
I believe there is plenty of intermediate power levels the Prop can be setup for. From running more Cogs at idle speed to running on the internal 12 MHz clock to leaving the crystal running and just sleeping all the Cogs.
My proposo is to ad to ad increment flag to You proposed TRLONGS instruction.
TRLONGS count,increment flags < Increment only cog_address, hub_address else both ············································ (Mostuseful HUB_Addres with transfer block protocols ············································ from and to I/O. With HUB flag on it is posible to fill block ············································ with specific value
RDLONGS cog_address,hub_address
LMM code. ···· TRLONGS 1,0,1 < set count to one long, no increment COG, increment HUB ···· NOP < LMM Code place holder ···· RDLONGS cog_address,hub_address ···· JMP LMM Code + 1 < Jump to read next long
Ps. With Instruction LMM AD/SUB to ( RDLONGS cog_address,hub_address ) it is even posible to have JUMP in its program flow. And ( cog_address ) can hold LMM_RET address.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty.
Why must it be that the RAM is quad-port (3 reads, 1 write)?· Aren't there alternatives to this?· You don't NEED 4-port RAM, you need 4 transactions to RAM in one pipeline stage.· Could you not clock memory transactions faster·and have multiple memory transactions·in one·pipe stage?· (Kind of break the pipe stage into four single-port-RAM-friendly stages, or two dual-port-RAM-friendly stages.)· Or use both edges of the clock cycle for a pipe stage to transfer:· two reads on the first edge, a read and a write on the second edge.· Or use a hybrid...or SOMEthing.
Since the size of the quad-port RAM seems to be prohibitive to having 16 cogs, I sure hope a lot of brainstorming went into alternatives to the brute force approach.
Chip Gracey (Parallax) said...
ONE THING TO CONSIDER, EVERYONE:
The next Propeller might leak one whole milliamp, without even clocking. This is due to a leakier, albeit faster, .18um process.
Does this mean that the next Propeller might require some additional considerations for cooling?
Any idea of the current draw? (Edited for proper meaning, shouldn't post before coffee.)
Like others I've been reading this thread with great interest in spite of the fact that a bunch
of it is sailing over my head. Would someone mind doing a revised list of features gleaned
from the information here in layman's English?
Chip Gracey (Parallax) said...
ONE THING TO CONSIDER, EVERYONE:
The current Propeller is always going to be the one that easily lends itself to battery applications. It is fabricated in a low-leakage .35um process and its current can be reduced at runtime to just a few microamps.
The next Propeller might leak one whole milliamp, without even clocking. This is due to a leakier, albeit faster, .18um process.
....
Would a 64 IO Prop have same power characteristics as the current Prop?
Being able to add a parallel bus would allow a solution to·many of the constraint issues we now face especially regarding external memory and its access speed or connecting to other Propellers or devices. Propeller II production is obviously a long time away, meanwhile you have customers that need more than the current Propeller can provide.
There were comments in this forum on this question some time ago from Parallax. There is a design for the 64 pin Prop I that's on hold because of problems with the chip design software. Parallax is waiting for the problems to be addressed and there's no way to know when this will happen.
To help clear things as far as what Mike mentioned... "There is a design for the 64 pin Prop I that's on hold because of problems with the chip design software. Parallax is waiting for the problems to be addressed and there's no way to know when this will happen." ...Yes, this is true, but so far this problem is isolated to the 350nm 64-Pin version of the Propeller still·in layout, and NOT the 180nm version of Propeller II (also still in layout.)· We have 2 layout Engineers for·each project, myself and·Frank.· Frank placed the layout for the Prop I, and is currently working on the 350nm 64-Pin version of Prop I.· I was brought on board to layout the Prop II.· As far as the Prop II status is concerned, ALL major blocks are complete.· There are a few minor·blocks left to finish, including the·CPU and details on how it will function within each·COG ... thus the initial drive for this forum thread.· ... And yes, the CPU is a relatively minor block since it's all digital, and all of the standard cells (i.e. AND,NAND,XOR,OR,NOR, FLIP-FLOP's, etc.) are designed in a·way with standard cell pitches that·allows them to be "snapped" into place·... the difficult blocks are·usually analog where the design requires more of a balancing act to make sure things are going to operate as planned.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 9/3/2008 5:40:59 PM GMT
(I've read thru the whole thread now, and I'm markign this post up now based on the posts earlier)
I haven't had a chance to read thru the whole thread (I plan to though), but I did want to say that I think having a flat 32bit memory model for the new chip is the way to go.
RAM starting at 0 and the ROM at the end of the address space instead of packed together. This will make future revisions with more RAM or ROM able to be compatible without weirdness. This seems to be the plan now.
I can't imagine it being very hard a tool that converts Prop 1 code into Prop 2 code, in fact it could just be an option in the IDE. Of course it won't be able to resolve timing issues, but it could fix up the memory addressing.
Also, what are the chances of having a version that had it's internal address and data busses exposed to allow for projects to add ram and memory mapped hardware?
Post Edited (Roy Eltham) : 9/7/2008 12:20:48 PM GMT
TRLONGS count,increment flags < Increment only cog_address, hub_address else both ············································ (Mostuseful HUB_Addres with transfer block protocols ············································ from and to I/O. With HUB flag on it is posible to fill block ············································ with specific value
Good idea! It would be nice to be able to clear a swath of hub ram in one operation.
Why must it be that the RAM is quad-port (3 reads, 1 write)?
If you want single-clock instruction execution, this is how it must be done. It's true that you could overclock the RAM, but you could only overclock it maybe 1.5 times before it would·become the critical timing path. If it were possible to overclock it just 2 times without it becoming the critical path, then we could get away with half the silicon for a 2-port RAM, instead.
Does this mean that the next Propeller might require some additional considerations for cooling?
No way! It's just going to draw more quiescent current. If the chip winds up running hot, it's not a good thing, as heat slows things down. This is where clock-gating comes in to minimize unnecessary signal transitions, which contribute to current draw, which generate heat. A hot chip is to be avoided.
Would a 64 IO Prop have same power characteristics as the current Prop?
The only extra power dissipation would come from loads connected to the extra pins. Otherwise, it will have the same power characteristics of the current Propeller.
It is one more instruction to consider.
I Name it ( BITsSET Position,xBits,Bits ).
I am not sure If it is posible that it must have dedicated Long address register Maybe in coniunction with
WRLONGS cog_address,hub_address
Useful to fill ColorBits in Video buffer and math more.
USE.
Long to modify. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ········BITsSET 10,5,10110 <Position,xBits,Bits
Long After······· xxxxxxxxxxxxxxxxxxxxxx10110xxxxx
·
Ps. Maybe Modify Long after that instruction
Ps2. Even deriviates AND, OR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty.
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again BTW: I type as I'm thinking, so please don't take any offence at my writing style
Comments
To really save power, you need to stop all but one cog and then switch to RCSLOW mode while disabling the crystal oscillator and PLL. This will reduce consumption to about 8uA. Be sure no I/O pins are floating or sourcing current. Then, when the single cog wants to power back up, turn on the crystal oscillator and PLL, wait 10ms, then switch over to them. Then, turn your cogs back on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
The current Propeller is always going to be the one that easily lends itself to battery applications. It is fabricated in a low-leakage .35um process and its current can be reduced at runtime to just a few microamps.
The next Propeller might leak one whole milliamp, without even clocking. This is due to a leakier, albeit faster, .18um process.
If we were using a newer 45nm process, the leakage could run into the 100's of millamps. How would that be for progress?
The current Propeller will always be the one to use if you don't need higher performance.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Share the knowledge: propeller.wikispaces.com
Lets make some music: www.andrewarsenault.com/hss
Are any of you interested in a low-EMI mode that would slow pin transitions way down?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
It's not that big of a deal to me personally I was just wondering, Maybe if such a mode does help save power (low power mode) then it would be something nice.
The RF issue is nothing a good old shielded enclosure couldn't fix and I think anyone who is worried about EMI would already have the idea of using a metal enclosure to keep RF out if anything.
Thanks Chip. [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Share the knowledge: propeller.wikispaces.com
Lets make some music: www.andrewarsenault.com/hss
In My opinion.
Computnig Power is more important that few more miliamps
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
This might be handy for certification of finished controllers PCB's / Machines ! It's pretty much the way 'others' do it - build their controller PCB - flash a moderate firmware version - get it certified .. once certified flash what you like .. It may sound deceptive but is common place.
The following is 'Slightly' Off topic but relevant to Certification and aforementioned Low-EMI mode.
Most industry sectors do it - Automotive industry 'detunes' engines at known Gov. test points to reduce emissions and increase fuel efficiency at these known test points 30mph,55mph and 70mph (europe anyway)
leading to a large industry dedicated to mildly 'remap' your engine - essentially negating these flat spots.
Performance Cars fitted with the likes of 'S' (Sport Mode) buttons that switch engine maps on the fly and open up flaps in the exhaust system - come with a warning 'Do not use on Public Roads' .... as if !
EDIT: Basically,in a long winded way, I am saying YES to the suggested 'low-EMI' mode ..
Regards,
John Twomey
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Those who can, do.Those who can’t, teach.
Post Edited (QuattroRS4) : 9/3/2008 10:48:48 AM GMT
I have one question on START/STOP COGs and Restart.
It is posible att have it to STOP COG in midle of its program RUN and Restart on same position (Resume).
Samt one Restart that START COG with Address in it that I specify
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Software Define Radio sounds like it might benefit from LOW EMI mode pins. If Prop I can be a radio I'm sure Prop II can be a better one.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
There is the thing, huge latency on coming out of low power. Loading/Starting COGs, waiting for the clock to stabilize....
For example I have worked on battery powered devices that required to wake from a "medium power mode " on receiving a sync signal from a modem and then immediately start reading the serial data.
So the clocks needed to be running at a suitable rate even in a lowish (medium) power mode and state also needed to be preserved.
Then there was a real "low power mode" more as you describe.
So that what I was fishing for with WAITLOCK.
With what you say about leakage it may not be so much of a gain but still getting to a few milliamps is better than a few hundred.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
One more Use of My proposo. LMM in 1+3 longs
My proposo is to ad to ad increment flag to You proposed TRLONGS instruction.
TRLONGS count,increment flags < Increment only cog_address, hub_address else both
············································ (Mostuseful HUB_Addres with transfer block protocols
············································ from and to I/O. With HUB flag on it is posible to fill block
············································ with specific value
RDLONGS cog_address,hub_address
LMM code.
···· TRLONGS 1,0,1 < set count to one long, no increment COG, increment HUB
···· NOP < LMM Code place holder
···· RDLONGS cog_address,hub_address
···· JMP LMM Code + 1 < Jump to read next long
Ps. With Instruction LMM AD/SUB to ( RDLONGS cog_address,hub_address ) it is even posible to have JUMP in its program flow. And ( cog_address ) can hold LMM_RET address.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 9/5/2008 2:58:03 AM GMT
Why must it be that the RAM is quad-port (3 reads, 1 write)?· Aren't there alternatives to this?· You don't NEED 4-port RAM, you need 4 transactions to RAM in one pipeline stage.· Could you not clock memory transactions faster·and have multiple memory transactions·in one·pipe stage?· (Kind of break the pipe stage into four single-port-RAM-friendly stages, or two dual-port-RAM-friendly stages.)· Or use both edges of the clock cycle for a pipe stage to transfer:· two reads on the first edge, a read and a write on the second edge.· Or use a hybrid...or SOMEthing.
Since the size of the quad-port RAM seems to be prohibitive to having 16 cogs, I sure hope a lot of brainstorming went into alternatives to the brute force approach.
Thanks for any clarification.
Does this mean that the next Propeller might require some additional considerations for cooling?
Any idea of the current draw? (Edited for proper meaning, shouldn't post before coffee.)
Like others I've been reading this thread with great interest in spite of the fact that a bunch
of it is sailing over my head. Would someone mind doing a revised list of features gleaned
from the information here in layman's English?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Post Edited (Oldbitcollector) : 9/3/2008 5:23:27 PM GMT
Being able to add a parallel bus would allow a solution to·many of the constraint issues we now face especially regarding external memory and its access speed or connecting to other Propellers or devices. Propeller II production is obviously a long time away, meanwhile you have customers that need more than the current Propeller can provide.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
...Yes, this is true, but so far this problem is isolated to the 350nm 64-Pin version of the Propeller still·in layout, and NOT the 180nm version of Propeller II (also still in layout.)· We have 2 layout Engineers for·each project, myself and·Frank.· Frank placed the layout for the Prop I, and is currently working on the 350nm 64-Pin version of Prop I.· I was brought on board to layout the Prop II.· As far as the Prop II status is concerned, ALL major blocks are complete.· There are a few minor·blocks left to finish, including the·CPU and details on how it will function within each·COG ... thus the initial drive for this forum thread.· ... And yes, the CPU is a relatively minor block since it's all digital, and all of the standard cells (i.e. AND,NAND,XOR,OR,NOR, FLIP-FLOP's, etc.) are designed in a·way with standard cell pitches that·allows them to be "snapped" into place·... the difficult blocks are·usually analog where the design requires more of a balancing act to make sure things are going to operate as planned.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 9/3/2008 5:40:59 PM GMT
I haven't had a chance to read thru the whole thread (I plan to though), but I did want to say that I think having a flat 32bit memory model for the new chip is the way to go.
RAM starting at 0 and the ROM at the end of the address space instead of packed together. This will make future revisions with more RAM or ROM able to be compatible without weirdness. This seems to be the plan now.
I can't imagine it being very hard a tool that converts Prop 1 code into Prop 2 code, in fact it could just be an option in the IDE. Of course it won't be able to resolve timing issues, but it could fix up the memory addressing.
Also, what are the chances of having a version that had it's internal address and data busses exposed to allow for projects to add ram and memory mapped hardware?
Post Edited (Roy Eltham) : 9/7/2008 12:20:48 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Thanks
And not forget LMM in 3 clok cykles
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
It is one more instruction to consider.
I Name it ( BITsSET Position,xBits,Bits ).
I am not sure If it is posible that it must have dedicated Long address register Maybe in coniunction with
WRLONGS cog_address,hub_address
Useful to fill ColorBits in Video buffer and math more.
USE.
Long to modify. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
······· ·BITsSET 10,5,10110 <Position,xBits,Bits
Long After······· xxxxxxxxxxxxxxxxxxxxxx10110xxxxx
·
Ps. Maybe Modify Long after that instruction
Ps2. Even deriviates AND, OR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 9/4/2008 8:32:13 AM GMT
Whilst I understand what you said, that did make me smile
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offence at my writing style
The PropII seems so close yet so far from our hands.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Share the knowledge: propeller.wikispaces.com
Lets make some music: www.andrewarsenault.com/hss
I am curious what funktions is planed in CPU/ALU block
I shortage to·me is INC/DEC COG register one step and mayby x steps for use with Address advance.
Ps. And any·type of register software counters
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 9/5/2008 3:22:40 AM GMT
Regards,
John Twomey
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Those who can, do.Those who can’t, teach.
My next question on counters is.
If·You can reconstruct them to have UPP/DOWN capablites with 2 PIN control.
4 counters (X,Y,Z,A) on COG. Very useful in all Robot control.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 9/4/2008 11:03:36 AM GMT