Kye said...
Why do you guys want external I/O pins to communicate between Cogs? So that you can add a tiny bit of speed to your application? Why not use the internal memory? The propeller 2 will be atleast 8... Wait EIGHT!!! Times faster than the original.
Not trying to argue, but according to what I've read it would also be 8 times faster to read the internal IO
pins than using HUB access. If Chip has a better solution though, I fully support that since I would greatly
appreciate freeing up die for other more useful features (more memory, NRZ or Manchester SERDES, etc...).
Beau or Chip: Do you expect the pin-out to change? Also, I would appreciate an answer on the pin-to-pin center pitch and spacing.
Kye: From what Chip has said, there will be more cog ram (somewhere between 496-508) since some of the registers will be replaced with instructions. The extra pins will not waste space. And boy, don't I wish we had them now!!
I totally disagree that it is a kludge. It is just a standard set of output pins, just without the pad I/O to the real world.
Everyone knows the Prop II is going to be so much faster and so much more powerful. But so too are the apps requiring complex things like this. If we are going to utilise the power of the Prop II, we need everything to help. As I understand it, the basic design was done with 4 x 32 bit ports (128 I/O) although only 104 were intended to be brought out. Recently the package changed restricting the I/Os to 64 pins.
There are going to be some impacts with software - this was chipped in stone over a year ago. IMHO the Prop II is not a big Prop I, but a completely new chip with much higher aspirations, that shares to roots of it's design from the Prop I. Many/most objects will run with only minor modifications. But, the Prop I is NOT being replaced.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Chip also said (in an earlier thread) that there will be an extra 128 longs per cog, for video buffer, and they will be accessible with the new indexed address mode.
Now THAT will be a very welcome new feature...
Cluso99 said...
Kye: From what Chip has said, there will be more cog ram (somewhere between 496-508) since some of the registers will be replaced with instructions. The extra pins will not waste space. And boy, don't I wish we had them now!!
I totally disagree that it is a kludge. It is just a standard set of output pins, just without the pad I/O to the real world.
Everyone knows the Prop II is going to be so much faster and so much more powerful. But so too are the apps requiring complex things like this. If we are going to utilise the power of the Prop II, we need everything to help. As I understand it, the basic design was done with 4 x 32 bit ports (128 I/O) although only 104 were intended to be brought out. Recently the package changed restricting the I/Os to 64 pins.
There are going to be some impacts with software - this was chipped in stone over a year ago. IMHO the Prop II is not a big Prop I, but a completely new chip with much higher aspirations, that shares to roots of it's design from the Prop I. Many/most objects will run with only minor modifications. But, the Prop I is NOT being replaced.
You said "Chip also said (in an earlier thread) that there will be an extra 128 longs per cog"
I my opinion Chip ned reconsider one of my ideas I send him on PM to use spare space on silicon to give os FULL COG size of that EXTRA Long's.
My idea was to have that much extra RAM beyond COG. With it we can have 8 FULL lenght physical COG's else 16 Half lenght physical COG's. That istead of 4 Longs (ONE COG) window to HUB use 2x2 Longs. With same resources that one COG have (very usable to simpler drivers that need full speed.
As I can see it that is more useble that some more KBytes extra HUB ram and with that nice inter communications posibilitys as are planed give even much more powerfull Prop II. No mather Chip said He will have even posibility of 4 Logical COG's in one Physical. He can still have them with my idea.
But as I said my idea ads upp to 8 extra Physical COG's if needed.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Interesting idea - however 8 extra half size cogs would still need hub accesses, slowing down hub access for all cogs.
When Chip was talking about the threads in cogs, I suggested that it automatically switch threads every instruction - but I have a better idea since then.
What if the threads were tied to hub access cycles? Let's say 4 hardware threads, and thread switching occurs exactly when that cog gets its hub cycle.
This would have MANY benefits:
- ALL four threads would be fully deterministic, and would be guaranteed a hub access cycle every 32 clock cycles (8*4)
- since non-threaded cogs have 8x the hub accesses compared to Prop1, this means the hardware threads would have 2x the hub bandwidth of Prop1!
- each thread would get 496/4 = 124 longs of cog memory, and 32 longs of FIFO - or the FIFO could belong to just one thread
- no need for TASK switching instructions
- each hardware thread would be 40Mips, twice as fast as a Prop1 cog
- only 8 "real" cogs, so each "real" cog gets 8 cycle access to hub
- ONE cog could handle keyboard, mouse, TV and audio - with only slight mods to current drivers
- ONE cog could do SPI, I2C and have two spare hardware threads!
Since a hardware thread would be deterministic, with twice the speed and twice the hub bandwidth of a Prop1 cog, a VGA bitmap driver would only take 1/4 of a cog!
This would allow 8 "full speed" cogs, or 32 "quarter speed" mini-cogs, or any mix in between, while keeping full determinism!
Easiest memory mapping would be:
Thread 0: $000-$07F cog ram, I/O at $1Fx
Thread 1: $080-$100 cog ram, I/O at $1Fx
Thread 2: $100-$17F cog ram, I/O at $1Fx
Thread 3: $180-$1FF cog ram, I/O at $1Fx, would only have 108 logs, due to I/O registers
Optionally, a cog could also run just two threads, at "half speed", with 256 longs for Thread 0, 240 longs for Thread 1 - again, fully deterministic.
I wish I'd thought of locking the thread switching to hub access before..
Sapieha said...
Hi Bill Henning
You said "Chip also said (in an earlier thread) that there will be an extra 128 longs per cog"
I my opinion Chip ned reconsider one of my ideas I send him on PM to use spare space on silicon to give os FULL COG size of that EXTRA Long's.
My idea was to have that much extra RAM beyond COG. With it we can have 8 FULL lenght physical COG's else 16 Half lenght physical COG's. That istead of 4 Longs (ONE COG) window to HUB use 2x2 Longs. With same resources that one COG have (very usable to simpler drivers that need full speed.
As I can see it that is more useble that some more KBytes extra HUB ram and with that nice inter communications posibilitys as are planed give even much more powerfull Prop II. No mather Chip said He will have even posibility of 4 Logical COG's in one Physical. He can still have them with my idea.
But as I said my idea ads upp to 8 extra Physical COG's if needed.
One thing I didn't think of about my earlier statement is that the complexity and chip space for each pin might be a LOT more since chip has added ADC and other functionality on every pin. 128 Full Featured pins, with only 64 of them brought out, may take up a lot more die space than I considered. Maybe Beau can answer that one.
I don't like the idea of going down to 108 longs. 496Longs is quite tight already, which is why you invented LMM. If he was going down the multi-threaded cog approach(which I hope not for TurboProp), I would hope that each thread which have it's own full register set, which on a cog means 512longs.
2nd, that sound's like a fundamental change that would take a LOT of work. Do you really want to wait that much longer. I would really like to have time to play/work with the TurboProp before TSHTF!
I invented LMM to be able to host large programs generated by compilers [noparse]:)[/noparse]
Chip has already said he is adding threads... but his model is non-deterministic, and requires a TASKSWITCH instruction.
The idea behind going down to 108/124 longs (4-way) or 240/256 (2-way) is that it is better than the non-deterministic TASKSWITCH approach for small easy drivers.
Ie - this would let a 4 thread cog easily do kb/mouse/audio out and simple TV out (ie bitmap) in just one hardware cog!
This is NOT meant for complex programs, but for simple drivers, which now "waste" most of a cog's resources.
108 longs is enough for many simple drivers, 240 longs for even more.
Basically, this gets more bang/buck out of the same silicon, by combining several small drivers into each cog.
Consider... which would be easier to program:
- a combined kb/mouse/audio/tv cog with non-deterministic threads and TASKSWITCH
- a combined kb/mouse/audio/tv cog with deterministic threads and no need for explicit task switching
THREADS 0 ' assumed to be there if omitted, ie default is non-threaded cog
org $0
' a regular, 496 long cog
THREADS 2
THREAD 1 ' automatically sets ORG to $0
' regular PASM code, no need to do TASKSWITCH, count cycles to next switch etc
THREAD 2 ' automatically sets ORG to $100
' regular PASM code, no need to do TASKSWITCH, count cycles to next switch etc
THREADS 3
THREAD 1 ' automatically sets ORG to $0, gets every second slot (of four possible slots, runs at 1/2 regular cog speed)
' regular PASM code, no need to do TASKSWITCH, count cycles to next switch etc
THREAD 2 ' automatically sets ORG to $100
' regular PASM code, no need to do TASKSWITCH, count cycles to next switch etc
THREAD 3 ' automatically sets ORG to $180
' regular PASM code, no need to do TASKSWITCH, count cycles to next switch etc
THREADS 4
THREAD 1 ' automatically sets ORG to $0
' regular PASM code, no need to do TASKSWITCH, count cycles to next switch etc
THREAD 2 ' automatically sets ORG to $80
' regular PASM code, no need to do TASKSWITCH, count cycles to next switch etc
THREAD 3 ' automatically sets ORG to $100
' regular PASM code, no need to do TASKSWITCH, count cycles to next switch etc
THREAD 4 ' automatically sets ORG to $180
' regular PASM code, no need to do TASKSWITCH, count cycles to next switch etc
hinv said...
Bill,
I don't like the idea of going down to 108 longs. 496Longs is quite tight already, which is why you invented LMM. If he was going down the multi-threaded cog approach(which I hope not for TurboProp), I would hope that each thread which have it's own full register set, which on a cog means 512longs.
2nd, that sound's like a fundamental change that would take a LOT of work. Do you really want to wait that much longer. I would really like to have time to play/work with the TurboProp before TSHTF!
Where did the idea come from that a cog would have only 128 longs??!!!!!
If that were a fixed size, then for me that would certainly kill the ability to create reasonable programs in assembler, as Spin or LMM just is not an answer for most of my speed intensive requirements. I wholly agree with Doug that 512 is tight enough already.
Bill, as far as wasting cogs on small drivers is concerned, then just implement a multithread scheduler per cog (takes only 25 longs) and you can have (almost) as many threads as you like; I have already run 128 small threads in one cog.
Most of my requirements are for bigger than 128 instructions, so trying to knit together bigger programs out of small pieces is just too bizare..... a mess of spaghetti code that will be hard to make deterministic or to debug. If that's the way it's going, my needs for Prop2 have just taken serious turn for the worse.
If however the concept is that cogs and their memory can individually be sized from zero to N threads, then I'm alright as I then have both options.
The concept is that each cog could run in one of four modes, and it would still have all the 496 locations - they would just be allocated to the deterministic threads.
(It is probably a moot point, as it is unlikely that the proposal could make it into PropII.)
NORMAL (default, not threaded)
2 THREADS (auto-switched on every hub access cycle, one cog gets $000-$0FF, other gets $100-$1EF
3 THREADS (auto switched, one cog gets 50% of time and $000-$0FF, two cogs get 25% of time and $100-$17F and $180-$1EF)
4 THREADS (auto switched, 4 threads, each get 25%, $000-$07F, $080-$FF, $100-$17F, $180-$1EF)
Note that the cog memory could be divided differently - the main idea is to be able to sub-divide a full speed cog into two, three or four
FULLY 100% deterministic hardware threads.
I do intend to play with your scheduler, it sounds great, however you have to admit the above is simpler, easier to understand, and no overhead - a good way of combining small drivers, which is all the idea is meant for.
I cringe whenever I use a whole cog for keyboard, mouse or serial - or some other uses.
Since Chip is already adding support for threading, but with an explicit task switch, making it non-deterministic (without lots of work and calculations in all threads) this should not be too big a change.
pjv said...
Whoa Just A Minute,
Where did the idea come from that a cog would have only 128 longs??!!!!!
If that were a fixed size, then for me that would certainly kill the ability to create reasonable programs in assembler, as Spin or LMM just is not an answer for most of my speed intensive requirements. I wholly agree with Doug that 512 is tight enough already.
Bill, as far as wasting cogs on small drivers is concerned, then just implement a multithread scheduler per cog (takes only 25 longs) and you can have (almost) as many threads as you like; I have already run 128 small threads in one cog.
Most of my requirements are for bigger than 128 instructions, so trying to knit together bigger programs out of small pieces is just too bizare..... a mess of spaghetti code that will be hard to make deterministic or to debug. If that's the way it's going, my needs for Prop2 have just taken serious turn for the worse.
If however the concept is that cogs and their memory can individually be sized from zero to N threads, then I'm alright as I then have both options.
Chip: I think your idea is even more restrictive than having 2 x 32 internal I/O ports.
While your method gives each cog an individual·32bit output port, the input port is only 32 bits from·EITHER one cog OR·a group of cogs or'd together, but not a mix of both. i.e. Cog 0 cannot read cog 1 bits 0-7 and cogs 4 & 4 bit 10 or'd together.
Good point. This can be overcome by having FOUR eight-bit fields in the mask register. Each byte within this register would provide the cog mask for the corresponding byte in the IN register. Then, you could get up to four different masks. I could even add another eight-bit register which would contain four two-bit fields, each 2-bit field setting the byte# for the corresponding IN byte. That way, byte numbers wouldn't even need to correspond across cog outputs.
This way, now·we also·need to know the cog number we are talking with.
The COGNEW instruction is totally "plug-and-play" and it returns a cog number. This makes it easy to hook stuff up at run time. This "internal pin" resource needs to be dynamic (reusable), not fixed at compile time (impossible to do, considering run-time possibilities).
I would rather have just 2 x 32bit internal pin ports, and total control of how they were allocated (DIRx, OUTx, INx, just like we do for external pins. Object use is just the same as we do currently... they should be passed as parameters. It is true that there is no control of this, but that is no different to what we do now.
heater said...
Now to pin organization/management. Perhaps when dealing with 8 concurrent objects few pins this is not an issue but I've always thought there should be some way to specify which pins are allocated to which objects at a single place in your project at a higher level than the individual objects. Rather like is done in the design tools for FPGA's There your VHDL/Verlog objects can use pins by name without caring which pins they actually are in the finished design. Pins are assigned to names and hence objects at one place when you fit your design to the selected device.
I agree that this is useful for pins, which are always in fixed-positions. However, everything else can be dynamic and therefore cannot be determined at compile time. Or, if it was determined at compile time, it would cease to be dynamic.
As the Prop is moving to 64 external and maybe 64 internal pins the management of this random pool of pins becomes more tedious using the current methods.
I agree, but this is a software compiler issue, not a hardware issue.
For external pins, only, I agree.
The one thing I like about the prop, with the exception of the preconfigured booting using P30/31 loader and P28/29 eeprom, all pins are almost totally identical. I say almost because of the pin grouping requirements of the VGA and TV using the VCFG register.
SPI, SD, Kbd, Mouse, FDX, and most other objects can use any pins. They do not even have to be consecutive, although some software did not allow for pins to be configured independently (e.g. older fsrw).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 2/12/2010 6:44:18 AM GMT
So, I'm just gonna put this out here. Take it or leave it.
<RANT>
It is extremely important that the ASM and hardware model for the propeller chip is not F**Cked up. The more stuff you guys seem to want to add to fix a few little problems will just make the propeller chip a worthless device.
Why do you guys want external I/O pins to communicate between Cogs? So that you can add a tiny bit of speed to your application? Why not use the internal memory? The propeller 2 will be atleast 8... Wait EIGHT!!! Times faster than the original.
Personally, Kye, I totally agree with you! I've NEVER even been tempted to use an external pin for a cog-to-cog comm/alert. I've always used RDxxxx and WRxxxx which provide nice, fat conduits for all the data you can stand. What HAS been useful is sync'ing multiple cogs using WAITCNT for video purposes. I kind of suspect that resorting to pin monkey-motion is a result of micro-managing·one's application and not getting the benefit of some healthy separation between cogs' activities. It would seem to me that so much herky-jerky instruction execution that would be commensurate with pin-watching is analogous to a sprint relay where everyone has to keep stopping to negotiate the baton transfer. Better to have one guy run the whole race.
You don't need internal pin ports. They will be underused and will just add an extra cost and overhead to all programmers of the device. Please, give me more than just one or two real world examples of where internal pins will be needed.
Yeah, can someone provide some examples? I missed the last ones.
The propeller 2 will also have way more RAM. Being able to send data through memory will be much easier anyway since you won't have to fill up the internal memory with a huge screen buffer. This again allows for cog to cog communication.
Unless there are just a bunch of applications that could not run without internal pins I don't see the point in it.
The propeller 2 needs to have atleast 496 general purpose registers in each cog to use. Adding all these fancy extra features is going to make it very difficult for some of my drivers I have written and other peoples drivers they have written to run since they will be out of program memory space.
No worries, here, Kye. There are only SIX special purpose registers, starting at $1FA: INDA (indirect A), INDB (indirect , INP, OUTP, DIRP, and ALTP (for configuring I/O pins to special modes). All things like CTR access have been made into instructions, so that things like reading CTR deltas can be accomplished in one instruction.
I would hate to see extra "kuldge" of·internal pin ports added just to provide some means of cog to cog communication WHEN THERE EXIST A GIANT POOL OF INTERNAL MEMORY!
I agree, personally. Internal pins in their simplest form would be a resource that would probably create 10x more·object-compatibility·headaches than performance improvements.
Beau or Chip: Do you expect the pin-out to change? Also, I would appreciate an answer on the pin-to-pin center pitch and spacing.
Steve, here is what is shaping up to be the final pinout (attached image). The pin pitch is 0.5mm. Here is an example of the package we will use: http://www.ricoh.co.jp/LSI/product_pcif/pkg/TQFP-100-P1-1414.pdf The crystal oscillator powers from VP3, which will need to be 3.3V (as opposed to say, 1.8V). I think most customers will run all ports at 3.3V, since 3.3V is required for the analog functions. You can run pure digital ports at 1.8V, though.
Thanks, for answering Chip. You put my mind at ease.
I'm okay with having a whole new platform with the propeller 2. I just really want to be able to just TWEAK my current drivers and not rewrite them completely on a new platform.
Chip: I think your idea is even more restrictive than having 2 x 32 internal I/O ports.
While your method gives each cog an individual·32bit output port, the input port is only 32 bits from·EITHER one cog OR·a group of cogs or'd together, but not a mix of both. i.e. Cog 0 cannot read cog 1 bits 0-7 and cogs 4 & 4 bit 10 or'd together.
Chip replied...
Good point. This can be overcome by having FOUR eight-bit fields in the mask register. Each byte within this register would provide the cog mask for the corresponding byte in the IN register. Then, you could get up to four different masks. I could even another eight-bit register which would contain four two-bit fields, each 2-bit field setting the byte#-selector for the corresponding IN byte. That way, byte numbers wouldn't even need to correspong across cog outputs.
I would rather just have a plain old set of internal pin ports where the outputting cog decided which pins it would drive using DIRx, OUTx and INx. This is simple and already easily understood. Your method seems to be overly complex to understand, and at least a different method. Anyway, that's my thoughts.
I would just rather the Prop II, no matter what it's limitations.
Internal Xtal...
Is it possible to place an internal xtal with 1% tolerance or tigher in the fab process you are using?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
You don't need internal pin ports. They will be underused and will just add an extra cost and overhead to all programmers of the device. Please, give me more than just one or two real world examples of where internal pins will be needed.
Yeah, can someone provide some examples? I missed the last ones.
If I understand correctly what you mean by "internal pin ports", wouldn't this allow a master cog to trigger a slave cog into action by having the slave normally sitting at a WAITPEQ? Currently, the only way I know to do that is for the master to wait for the hub to reach it (so it can do a LOCKCLR or WRLONG) and then wait again till the hub reaches the slave cog (so it can do a LOCKSET or RDLONG). Is there a better mechanism to do this? The problem with this mechanism is not only that it's slow (requiring up to 2 full hub cycles), and power hungry (requiring the slave to execute a tight loop) but also that the time it takes for the master to signal the slave depends on the relative ordering of the cogs around the hub, and how far apart they are.
Or have I misunderstood what you mean by "internal pin ports"?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Chip said...
The crystal oscillator powers from VP3, which will need to be 3.3V (as opposed to say, 1.8V).
Crystal oscillators need to be close to GND pins, and isolated from Digital action,
so the best idea is probably to spread the VP3-GND pair, and slot the XI XO between them.
Couple of ROM questions:
* How large is the ROM (size, and spare room )
* What speed can it access (I guess to one core ?)
* What ROM NRE and MOQ's are likely ?
I have used waitpeq and an external pin (unused pin) to synchronise 4 cogs to the same clock signal, then by reading cnt and adding a small value +0, +1, +2 & +3 then perform a waitcnt, each cog is now in slip sync (where each cog is now synchronised to the next clock from the previous cog). This method was used in my version of the datalogger to log all 32 pin states on each successive clock cycle.
Many have stated, including myself, that had the internal PortB pins been implemented in the Prop I we would have used them for cog to cog transfer and flags. There is no hub delay in accessing the port pins, so it would be much quicker to implement transfers and signalling between cogs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
There is an important point here. How to get a COG to wait for some signal/event from another COG in such away that it is basically halted and consuming minimal power until the event occurs?
At the moment this can only be done by using a wait on a pin. And hence the desire for having internal "virtual" pins.
Currently pretty much all drivers in OBEX or wherever are in a tight polling loop when waiting for commands. This is not conducive to low power operation.
I do agree with Kye and Leon that it's best to keep things simple and not introduce a raft of new special registers/modes/complicated bit fields etc.
The danger is in ending up with a 2000 page Prop II manual trying to explain features that many will not use. With the good stuff lost in the noise this will put many people off.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
There is an important point here. How to get a COG to wait for some signal/event from another COG in such away that it is basically halted and consuming minimal power until the event occurs?
At the moment this can only be done by using a wait on a pin. And hence the desire for having internal "virtual" pins.
I do this often on a couple of designs where I'm idling in the lowest power state I can manage. I've done a few bits 'n bobs where PORTB would have been quite handy. Sure, I could have done it using polling loops, but waits are so much neater, accurate (timing wise) and of course power saving.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
heater: That is an excellent case for internal pins. You are of course correct that power can only be reduced with waitxxx.
Just the same as external pins, except no I/O pad. No need for any extra instructions other that to say Port C & D are implemented but not brought out to any external pin. In fact, it makes for a later version of the Prop IIB with the internal pins brought out externally. There are no special registers/modes/complicated bit fields in this method. All completely understood because we are already using them to talk to the outside world, and on occasions internally cog to cog. IIRC doesn't the turbulence demo use this feature?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Yes, Turbulence did use a pin for sync. I used it for measuring the execution speed of ZiCog. Toggle a pin on each instruction dispatch and use the frequency counter object to measure. Saved counting instructions in a HUB variable.
I agree, Cluso, internal pins are a simple extension of what we have been doing already with no extra "warts" to worry about.
A COG should not have to know or care if the device it is communicating with is external to the Prop or internal (another COG).
To me that means using the hyper-simple internal pin idea or moving up to some sophisticated communication channel idea as is done in the, dare I say it, XMOS and Transputer architectures. Which I'm sure brings with it a whole world of problems to solve and a couple of years of development effort.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
For me discusions on NEED not NEED extra internal ports are mising point.
In many industrial aplications it is neesesary to syncronise things. If we not have that ports we need use EXTERNAL pins that are waste of resources.
I understand some people that them said them not need them, BUT them not consider that Prop II are not constructed only for them.
If Prop II will be wersalite for many aplications that need as many inbuild posibilites as are posible.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
I'm starting to think maybe just simple I/O pins that aren't brought out are the way to go, if anything. It's a simple circuit and requires one sentence of explanation. If that's how it winds up being, people had better use good sense about how to allocate them.
So far, by the way, I've only heard people say that they use single pins at a time to release other cogs from WAITPxx instructions. If that's all that needed, 64 internal I/Os is total overkill.
Also, I would have done that sync'ing mentioned above (where 4 cogs were equally offset) by launching each cog with a future CNT target cumulatively offset by +4. That way, they'd all launch, do their initial WAITCNT, and thereafter they'd be synced at equal offsets. No pin needed. Maybe less code, too.
Any other examples that are more compelling out there?
I have to agree completely with the folks who are in favor of internal ports. They would be a clean and simple way to synchronize cogs and to communicate between cogs without the delays going through the hub incurs. Best of all it is something we are already familiar with so there is no learning curve.
jazzed said...
BTW: have you ever accidently shorted VCC/GND with a scope probe?
A few times. Always gives me a start if I see a spark. I zapped a few chips inside the FIB machine and thought I ruined it, but replacing the exploded parts fixed the problem.
Someone said, "Experience is directly proportional to the amount of equipment ruined."
I've been working all night getting a new Altera Stratix III board figured out and configured so I can resume logic design on a newer platform. In the past, we've made our own FPGA boards, but it takes a good month, so I bought one of Altera's this time. This thing is uber-complicated. It took some forensics just to get the breakout·adapter signals related back to the·1152-pin $3700 FPGA chip that sits in the middle of the main board, surrounded by all kinds of debris. This is a refresher in how complex something can be. For everyone's enjoyment, below is a picture of some active control that pops up when I go to the·Pin Assigments window (imagine "Internal pins. Compile time. Making everything make sense.")
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 2/12/2010 3:06:08 PM GMT
Comments
Not trying to argue, but according to what I've read it would also be 8 times faster to read the internal IO
pins than using HUB access. If Chip has a better solution though, I fully support that since I would greatly
appreciate freeing up die for other more useful features (more memory, NRZ or Manchester SERDES, etc...).
Beau or Chip: Do you expect the pin-out to change? Also, I would appreciate an answer on the pin-to-pin center pitch and spacing.
Thanks,
--Steve
I totally disagree that it is a kludge. It is just a standard set of output pins, just without the pad I/O to the real world.
Everyone knows the Prop II is going to be so much faster and so much more powerful. But so too are the apps requiring complex things like this. If we are going to utilise the power of the Prop II, we need everything to help. As I understand it, the basic design was done with 4 x 32 bit ports (128 I/O) although only 104 were intended to be brought out. Recently the package changed restricting the I/Os to 64 pins.
There are going to be some impacts with software - this was chipped in stone over a year ago. IMHO the Prop II is not a big Prop I, but a completely new chip with much higher aspirations, that shares to roots of it's design from the Prop I. Many/most objects will run with only minor modifications. But, the Prop I is NOT being replaced.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Now THAT will be a very welcome new feature...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
You said "Chip also said (in an earlier thread) that there will be an extra 128 longs per cog"
I my opinion Chip ned reconsider one of my ideas I send him on PM to use spare space on silicon to give os FULL COG size of that EXTRA Long's.
My idea was to have that much extra RAM beyond COG. With it we can have 8 FULL lenght physical COG's else 16 Half lenght physical COG's. That istead of 4 Longs (ONE COG) window to HUB use 2x2 Longs. With same resources that one COG have (very usable to simpler drivers that need full speed.
As I can see it that is more useble that some more KBytes extra HUB ram and with that nice inter communications posibilitys as are planed give even much more powerfull Prop II. No mather Chip said He will have even posibility of 4 Logical COG's in one Physical. He can still have them with my idea.
But as I said my idea ads upp to 8 extra Physical COG's if needed.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Interesting idea - however 8 extra half size cogs would still need hub accesses, slowing down hub access for all cogs.
When Chip was talking about the threads in cogs, I suggested that it automatically switch threads every instruction - but I have a better idea since then.
What if the threads were tied to hub access cycles? Let's say 4 hardware threads, and thread switching occurs exactly when that cog gets its hub cycle.
This would have MANY benefits:
- ALL four threads would be fully deterministic, and would be guaranteed a hub access cycle every 32 clock cycles (8*4)
- since non-threaded cogs have 8x the hub accesses compared to Prop1, this means the hardware threads would have 2x the hub bandwidth of Prop1!
- each thread would get 496/4 = 124 longs of cog memory, and 32 longs of FIFO - or the FIFO could belong to just one thread
- no need for TASK switching instructions
- each hardware thread would be 40Mips, twice as fast as a Prop1 cog
- only 8 "real" cogs, so each "real" cog gets 8 cycle access to hub
- ONE cog could handle keyboard, mouse, TV and audio - with only slight mods to current drivers
- ONE cog could do SPI, I2C and have two spare hardware threads!
Since a hardware thread would be deterministic, with twice the speed and twice the hub bandwidth of a Prop1 cog, a VGA bitmap driver would only take 1/4 of a cog!
This would allow 8 "full speed" cogs, or 32 "quarter speed" mini-cogs, or any mix in between, while keeping full determinism!
Easiest memory mapping would be:
Thread 0: $000-$07F cog ram, I/O at $1Fx
Thread 1: $080-$100 cog ram, I/O at $1Fx
Thread 2: $100-$17F cog ram, I/O at $1Fx
Thread 3: $180-$1FF cog ram, I/O at $1Fx, would only have 108 logs, due to I/O registers
Optionally, a cog could also run just two threads, at "half speed", with 256 longs for Thread 0, 240 longs for Thread 1 - again, fully deterministic.
I wish I'd thought of locking the thread switching to hub access before..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Post Edited (Bill Henning) : 2/11/2010 8:50:54 PM GMT
I don't like the idea of going down to 108 longs. 496Longs is quite tight already, which is why you invented LMM. If he was going down the multi-threaded cog approach(which I hope not for TurboProp), I would hope that each thread which have it's own full register set, which on a cog means 512longs.
2nd, that sound's like a fundamental change that would take a LOT of work. Do you really want to wait that much longer. I would really like to have time to play/work with the TurboProp before TSHTF!
Doug
I invented LMM to be able to host large programs generated by compilers [noparse]:)[/noparse]
Chip has already said he is adding threads... but his model is non-deterministic, and requires a TASKSWITCH instruction.
The idea behind going down to 108/124 longs (4-way) or 240/256 (2-way) is that it is better than the non-deterministic TASKSWITCH approach for small easy drivers.
Ie - this would let a 4 thread cog easily do kb/mouse/audio out and simple TV out (ie bitmap) in just one hardware cog!
This is NOT meant for complex programs, but for simple drivers, which now "waste" most of a cog's resources.
108 longs is enough for many simple drivers, 240 longs for even more.
Basically, this gets more bang/buck out of the same silicon, by combining several small drivers into each cog.
Consider... which would be easier to program:
- a combined kb/mouse/audio/tv cog with non-deterministic threads and TASKSWITCH
- a combined kb/mouse/audio/tv cog with deterministic threads and no need for explicit task switching
THREADS 0 ' assumed to be there if omitted, ie default is non-threaded cog org $0 ' a regular, 496 long cogTHREADS 2 THREAD 1 ' automatically sets ORG to $0 ' regular PASM code, no need to do TASKSWITCH, count cycles to next switch etc THREAD 2 ' automatically sets ORG to $100 ' regular PASM code, no need to do TASKSWITCH, count cycles to next switch etcTHREADS 3 THREAD 1 ' automatically sets ORG to $0, gets every second slot (of four possible slots, runs at 1/2 regular cog speed) ' regular PASM code, no need to do TASKSWITCH, count cycles to next switch etc THREAD 2 ' automatically sets ORG to $100 ' regular PASM code, no need to do TASKSWITCH, count cycles to next switch etc THREAD 3 ' automatically sets ORG to $180 ' regular PASM code, no need to do TASKSWITCH, count cycles to next switch etcTHREADS 4 THREAD 1 ' automatically sets ORG to $0 ' regular PASM code, no need to do TASKSWITCH, count cycles to next switch etc THREAD 2 ' automatically sets ORG to $80 ' regular PASM code, no need to do TASKSWITCH, count cycles to next switch etc THREAD 3 ' automatically sets ORG to $100 ' regular PASM code, no need to do TASKSWITCH, count cycles to next switch etc THREAD 4 ' automatically sets ORG to $180 ' regular PASM code, no need to do TASKSWITCH, count cycles to next switch etc▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Where did the idea come from that a cog would have only 128 longs??!!!!!
If that were a fixed size, then for me that would certainly kill the ability to create reasonable programs in assembler, as Spin or LMM just is not an answer for most of my speed intensive requirements. I wholly agree with Doug that 512 is tight enough already.
Bill, as far as wasting cogs on small drivers is concerned, then just implement a multithread scheduler per cog (takes only 25 longs) and you can have (almost) as many threads as you like; I have already run 128 small threads in one cog.
Most of my requirements are for bigger than 128 instructions, so trying to knit together bigger programs out of small pieces is just too bizare..... a mess of spaghetti code that will be hard to make deterministic or to debug. If that's the way it's going, my needs for Prop2 have just taken serious turn for the worse.
If however the concept is that cogs and their memory can individually be sized from zero to N threads, then I'm alright as I then have both options.
Cheers,
Peter (pjv)
(It is probably a moot point, as it is unlikely that the proposal could make it into PropII.)
NORMAL (default, not threaded)
2 THREADS (auto-switched on every hub access cycle, one cog gets $000-$0FF, other gets $100-$1EF
3 THREADS (auto switched, one cog gets 50% of time and $000-$0FF, two cogs get 25% of time and $100-$17F and $180-$1EF)
4 THREADS (auto switched, 4 threads, each get 25%, $000-$07F, $080-$FF, $100-$17F, $180-$1EF)
Note that the cog memory could be divided differently - the main idea is to be able to sub-divide a full speed cog into two, three or four
FULLY 100% deterministic hardware threads.
I do intend to play with your scheduler, it sounds great, however you have to admit the above is simpler, easier to understand, and no overhead - a good way of combining small drivers, which is all the idea is meant for.
I cringe whenever I use a whole cog for keyboard, mouse or serial - or some other uses.
Since Chip is already adding support for threading, but with an explicit task switch, making it non-deterministic (without lots of work and calculations in all threads) this should not be too big a change.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 2/12/2010 6:44:18 AM GMT
Chip Gracey
Parallax, Inc.
Chip Gracey
Parallax, Inc.
cgi.ebay.com/TQFP-100-TQFP100-TQFP-100-Adapter-SMD-PCB-Double-Side_W0QQitemZ390145725419QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item5ad67f53eb
Good luck spinning out your design.
Cheers.
--Steve
Post Edited (jazzed) : 2/12/2010 2:31:54 AM GMT
I'm okay with having a whole new platform with the propeller 2. I just really want to be able to just TWEAK my current drivers and not rewrite them completely on a new platform.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Chip: I think your idea is even more restrictive than having 2 x 32 internal I/O ports.
While your method gives each cog an individual·32bit output port, the input port is only 32 bits from·EITHER one cog OR·a group of cogs or'd together, but not a mix of both. i.e. Cog 0 cannot read cog 1 bits 0-7 and cogs 4 & 4 bit 10 or'd together.
Chip replied...
Good point. This can be overcome by having FOUR eight-bit fields in the mask register. Each byte within this register would provide the cog mask for the corresponding byte in the IN register. Then, you could get up to four different masks. I could even another eight-bit register which would contain four two-bit fields, each 2-bit field setting the byte#-selector for the corresponding IN byte. That way, byte numbers wouldn't even need to correspong across cog outputs.
I would rather just have a plain old set of internal pin ports where the outputting cog decided which pins it would drive using DIRx, OUTx and INx. This is simple and already easily understood. Your method seems to be overly complex to understand, and at least a different method. Anyway, that's my thoughts.
I would just rather the Prop II, no matter what it's limitations.
Internal Xtal...
Is it possible to place an internal xtal with 1% tolerance or tigher in the fab process you are using?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
John Abshier
If I understand correctly what you mean by "internal pin ports", wouldn't this allow a master cog to trigger a slave cog into action by having the slave normally sitting at a WAITPEQ? Currently, the only way I know to do that is for the master to wait for the hub to reach it (so it can do a LOCKCLR or WRLONG) and then wait again till the hub reaches the slave cog (so it can do a LOCKSET or RDLONG). Is there a better mechanism to do this? The problem with this mechanism is not only that it's slow (requiring up to 2 full hub cycles), and power hungry (requiring the slave to execute a tight loop) but also that the time it takes for the master to signal the slave depends on the relative ordering of the cogs around the hub, and how far apart they are.
Or have I misunderstood what you mean by "internal pin ports"?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Couple of ROM questions:
* How large is the ROM (size, and spare room )
* What speed can it access (I guess to one core ?)
* What ROM NRE and MOQ's are likely ?
Post Edited (jmg) : 2/12/2010 9:15:17 AM GMT
Many have stated, including myself, that had the internal PortB pins been implemented in the Prop I we would have used them for cog to cog transfer and flags. There is no hub delay in accessing the port pins, so it would be much quicker to implement transfers and signalling between cogs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
At the moment this can only be done by using a wait on a pin. And hence the desire for having internal "virtual" pins.
Currently pretty much all drivers in OBEX or wherever are in a tight polling loop when waiting for commands. This is not conducive to low power operation.
I do agree with Kye and Leon that it's best to keep things simple and not introduce a raft of new special registers/modes/complicated bit fields etc.
The danger is in ending up with a 2000 page Prop II manual trying to explain features that many will not use. With the good stuff lost in the noise this will put many people off.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I do this often on a couple of designs where I'm idling in the lowest power state I can manage. I've done a few bits 'n bobs where PORTB would have been quite handy. Sure, I could have done it using polling loops, but waits are so much neater, accurate (timing wise) and of course power saving.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Just the same as external pins, except no I/O pad. No need for any extra instructions other that to say Port C & D are implemented but not brought out to any external pin. In fact, it makes for a later version of the Prop IIB with the internal pins brought out externally. There are no special registers/modes/complicated bit fields in this method. All completely understood because we are already using them to talk to the outside world, and on occasions internally cog to cog. IIRC doesn't the turbulence demo use this feature?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I agree, Cluso, internal pins are a simple extension of what we have been doing already with no extra "warts" to worry about.
A COG should not have to know or care if the device it is communicating with is external to the Prop or internal (another COG).
To me that means using the hyper-simple internal pin idea or moving up to some sophisticated communication channel idea as is done in the, dare I say it, XMOS and Transputer architectures. Which I'm sure brings with it a whole world of problems to solve and a couple of years of development effort.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
For me discusions on NEED not NEED extra internal ports are mising point.
In many industrial aplications it is neesesary to syncronise things. If we not have that ports we need use EXTERNAL pins that are waste of resources.
I understand some people that them said them not need them, BUT them not consider that Prop II are not constructed only for them.
If Prop II will be wersalite for many aplications that need as many inbuild posibilites as are posible.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
So far, by the way, I've only heard people say that they use single pins at a time to release other cogs from WAITPxx instructions. If that's all that needed, 64 internal I/Os is total overkill.
Also, I would have done that sync'ing mentioned above (where 4 cogs were equally offset) by launching each cog with a future CNT target cumulatively offset by +4. That way, they'd all launch, do their initial WAITCNT, and thereafter they'd be synced at equal offsets. No pin needed. Maybe less code, too.
Any other examples that are more compelling out there?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Someone said, "Experience is directly proportional to the amount of equipment ruined."
I've been working all night getting a new Altera Stratix III board figured out and configured so I can resume logic design on a newer platform. In the past, we've made our own FPGA boards, but it takes a good month, so I bought one of Altera's this time. This thing is uber-complicated. It took some forensics just to get the breakout·adapter signals related back to the·1152-pin $3700 FPGA chip that sits in the middle of the main board, surrounded by all kinds of debris. This is a refresher in how complex something can be. For everyone's enjoyment, below is a picture of some active control that pops up when I go to the·Pin Assigments window (imagine "Internal pins. Compile time. Making everything make sense.")
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 2/12/2010 3:06:08 PM GMT