Back to those 'pipes', Does anyone know if it is a parallel interface or serial that cogs can communicate with other cogs?
And, does anyone know if these pipes can be used by all cogs at the same instant?
I wish Chip had communicated how the pipes actually get used. 8 cogs and 32-bit wide pipe implies only 4 lines/cog; or is this a wrong use? Is it just a 'register' that all cogs can read/write? Somebody please unclog my thinking on this (small) concept.
Obviously we will have to wait and see. However, had we had the internal connections for portB in the Prop 1 we could have used this extensively.
Now most programs would likely only have comms between 2 cogs, but the option is here for doing anything we want.
The pins have very complex things on them and now use a lot of silicon, so it is not possible for the pins to actually exist in the silicon. So the pipes are just pins from the cog joined - no complex ADC, etc.
As for the counters, etc. I think from later discussions, that the counter sections still reside per cog, not per pin as I has guessed. This means that what Chip has said is that high speed comms can be done between cogs would hold true. Remember, most programs consist of a main cog and the other cogs do helper functions including any I/O. I think this will continue to be the likely case into the future. Of course, we will be able to off-load a lot more code into the I/O cogs because of the additional hardware in the cogs/pins and speed.
From the register map, it seems the PortD is the pipe and has 2 registers PIN & DIR, just the same as the other 3 ports A, B & C.
Maybe the 4 unused pins of Port C are internally connected, but there will be no ADC etc for these pins.
Basically it is too late to ask for features for the Prop II. First test silicon should be wip as we speak.
So (me included) lets restrict discussion to what is in Prop II. If you want, start a Prop 3 wish list thread, but don't expect anyone to take notice for quite a while (years).
The pins I was referring to that I thought should be full featured pins are the 4 leftover pins that wouldn't fit in the package from port C. I would agree that port D should be just like Prop1 pins, but internal only
I don't know where you are getting your information, but last I heard they were waiting for their test chip to come back with only some test blocks laid out. Has the whole chip been laid out already?
I got the impression that the cogs will have two counters as it is now, while the pins themselves will also have one (or more?) - considering Chip was talking about how you can perform various automated functions on the pins with very little cog oversight.
BTW, does anybody know if there is a copy of the whole chat somewhere? I didn't see it on savage circuit's site.
EDIT: Reading through the chat again, it does seem to me now that the pins do NOT have their own counters.
hinv: Unfortunately it is only the test chip. I am unsure whether Beau has actually sent it out yet without checkin the thread.
I don't think there is space for more I/O pins on the die. If they did this it would most likely impact hub space from what Beau has said. The pin area has taken a huge amount of die space.
I would expect that they will test the cog for instruction set working.
There is definately a lot more stuff in the pins and counters. I guess we will have to wait a little longer to find out all that is in there. One thing you can be assured of, we will be amazed even if it doesn't do all of our pet requirements.
I got the impression that the cogs will have two counters as it is now, while the pins themselves will also have one (or more?) - considering Chip was talking about how you can perform various automated functions on the pins with very little cog oversight.
There has to be counters in the I/O blocks. Can't do the ADC/DAC functions without them. How accessible they'll be for using in other ways is another question.
Thanks for posting the chatlog. The Propeller 2 becomes more interesting day by day, i mean: 160MHz clock and one cycle instructions sound great on its own! A Logic Analyzer with it would be a killer application, as well as bitbanging high speed serial protocols.
As far as i think i understood the last "port" is a 4 bit bus (the rest of the last 32 bits not being connected as I/O pins) that all COGs can access like pins (i wonder if it would be possible to one cog masking it as an input and another as an output) without the hub access schedule. Thats a high speed method to trigger another COGs processing (in contrast to a hub access depending LOCKSET or Rdxxxx/Wrxxxx) or feed some data directly for extra processing. I guess the "filter it out" statement means its just a bus that requires some handshaking between COGs, but i guess mostly two COGs needing high speed synch will have to share data without the Hub RAM scheduler, which means the clock is the handshake.
Wrt the silicon real estate discussion i understand that there is this aim to have all I/O Pins have the same functionality, otoh it could be that only some pins have special functions (and save that spaces on the others). But i guess a lot of features that are preferably available on any pin goes hand in hand with a little extra functionality for special purposes. This makes the propeller such a great, versatile design.
It´s a shame that lots of people tend to use more complex architectures instead of solving a lot of problems by parallel processing. I mean, i too like the small pin count packages of e.g. AVRs, but when mixing several serial I/O it gets complicated.
Comments
And, does anyone know if these pipes can be used by all cogs at the same instant?
I wish Chip had communicated how the pipes actually get used. 8 cogs and 32-bit wide pipe implies only 4 lines/cog; or is this a wrong use? Is it just a 'register' that all cogs can read/write? Somebody please unclog my thinking on this (small) concept.
This is my assumption as well. So it should up to the programmer to decide how to implement the pipe width and comm protocol.
Obviously we will have to wait and see. However, had we had the internal connections for portB in the Prop 1 we could have used this extensively.
Now most programs would likely only have comms between 2 cogs, but the option is here for doing anything we want.
The pins have very complex things on them and now use a lot of silicon, so it is not possible for the pins to actually exist in the silicon. So the pipes are just pins from the cog joined - no complex ADC, etc.
As for the counters, etc. I think from later discussions, that the counter sections still reside per cog, not per pin as I has guessed. This means that what Chip has said is that high speed comms can be done between cogs would hold true. Remember, most programs consist of a main cog and the other cogs do helper functions including any I/O. I think this will continue to be the likely case into the future. Of course, we will be able to off-load a lot more code into the I/O cogs because of the additional hardware in the cogs/pins and speed.
From the register map, it seems the PortD is the pipe and has 2 registers PIN & DIR, just the same as the other 3 ports A, B & C.
Maybe the 4 unused pins of Port C are internally connected, but there will be no ADC etc for these pins.
Basically it is too late to ask for features for the Prop II. First test silicon should be wip as we speak.
So (me included) lets restrict discussion to what is in Prop II. If you want, start a Prop 3 wish list thread, but don't expect anyone to take notice for quite a while (years).
Have I missed this? I have kept my eye on this thread, but I have not seen anything turn up yet. Was it posted somewhere else?
Ross.
Lots of us are highly interested in seeing the new instructions.
The pins I was referring to that I thought should be full featured pins are the 4 leftover pins that wouldn't fit in the package from port C. I would agree that port D should be just like Prop1 pins, but internal only
I don't know where you are getting your information, but last I heard they were waiting for their test chip to come back with only some test blocks laid out. Has the whole chip been laid out already?
Doug
BTW, does anybody know if there is a copy of the whole chat somewhere? I didn't see it on savage circuit's site.
EDIT: Reading through the chat again, it does seem to me now that the pins do NOT have their own counters.
Chip joined in here http://www.savagecircuits.com/forums/misc.php?do=ccarc&page=31
I don't think there is space for more I/O pins on the die. If they did this it would most likely impact hub space from what Beau has said. The pin area has taken a huge amount of die space.
I would expect that they will test the cog for instruction set working.
There is definately a lot more stuff in the pins and counters. I guess we will have to wait a little longer to find out all that is in there. One thing you can be assured of, we will be amazed even if it doesn't do all of our pet requirements.
Fingers crossed for successful test silicon.
All I get from those links is the Smilie List.
You need be member to get Chat functions.
As far as i think i understood the last "port" is a 4 bit bus (the rest of the last 32 bits not being connected as I/O pins) that all COGs can access like pins (i wonder if it would be possible to one cog masking it as an input and another as an output) without the hub access schedule. Thats a high speed method to trigger another COGs processing (in contrast to a hub access depending LOCKSET or Rdxxxx/Wrxxxx) or feed some data directly for extra processing. I guess the "filter it out" statement means its just a bus that requires some handshaking between COGs, but i guess mostly two COGs needing high speed synch will have to share data without the Hub RAM scheduler, which means the clock is the handshake.
Wrt the silicon real estate discussion i understand that there is this aim to have all I/O Pins have the same functionality, otoh it could be that only some pins have special functions (and save that spaces on the others). But i guess a lot of features that are preferably available on any pin goes hand in hand with a little extra functionality for special purposes. This makes the propeller such a great, versatile design.
It´s a shame that lots of people tend to use more complex architectures instead of solving a lot of problems by parallel processing. I mean, i too like the small pin count packages of e.g. AVRs, but when mixing several serial I/O it gets complicated.
wbr,
SkyFX