hinv said...
Actually, the I/Os can run at 1.8V, 3.3V, or anything in-between, if I understand correctly. Can someone clarify this? I would, but my search capability went away.
Anybody that has done chip development want to throw out a guess as to when the TurboProp could go into production considering they layout they are doing now? Maybe I will hold off my purchase of an IGEPv2.
Thanks,
Doug
Is it safe to say this chip won't work with a 6502 chip with 5 volt logic?
Chuckz: you just use one of the methods to bring 5V signals to 3.3 V levels or the other way around: CPLDs, '8T245s, resistors or some other level shifters by Maxim, National, Analog, NXP....
I'd use resistors and a 8T245 in your case...
Chip said "That is easy to do, but it feels like kind of a kludge." in response to "Are you still implementing the extra port(s) internally so we could do 32bit cog to cog mailbox/comms or whatever?"
and later:
"Because of power and ground pin needs, not to mention die real estate, I think 64 I/Os is going to fill things up. S we're heading for 2x32-bit I/O ports with 2x32-bit internal ports."
So am I to interperate that as we are getting 128 I/Os with 64 of them available? If so, that is even better than I was hoping for
I REALLY like that "kludge", because to me, it is a feature! It's another communication method that has been used in the past, ie. "turbulence", at the cost of real I/O. We will be able to do both!
And if I understand correctly, we can use those pin features internally as well!
Ariba: I would be hoping that the serial boot pins would be P62/P63 which are next to RES.
And eeprom on P60/P61 or SD on P58-P61, anticipating we can boot from SD without an eeprom. Maybe some other boot options also. I was discussing with Chip on the old thread about using a single pin with various values of a resistor to +V or GND to determine the boot option.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Nice to know a package has been selected. Is it .5mm or .65mm pitch? The bigger the better [noparse]:)[/noparse]
Too bad you can't have just 4 more pins for Serial and EEPROM (whatever) IO.
Consider: COGs use pins to talk to "things". Only in this case the "things" are implemented in other COGs on the same chip so the pins need not come out of the chip.
potatohead: "This will diminish the ease of plugging objects together as is done right now."
Why? Right now objects use pins. When you are mixing and matching objects in your application you have to allocate you pins and adjust the objects accordingly.
If COG code is written that shares data through pins then you have to go through that same process.
That's not to say that there arn't better ways of communicating between COGs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Agreed. I think it's pretty exciting. I also think it will be another layer to manage, that's all. That is why I wrote "only downside". There are a lot of upsides!!
IMHO, it will get abused, then it will get sorted, leaving us a nice, fast inter-cog comms.
- I like the idea of having two internal ports as well, very handy for inter-cog comm [noparse]:)[/noparse]
- I will be the first to admit that I know very little about the constraints you are under on ground/vcc and ground/vio pins.
On the drawing Beau posted, there were two pairs of Vcc/GND, and Vio/GND (8 pins total) per side. If that could be held back to 4 pins per side (perhaps Vcc/GND and Vio/GND - the GND's are going to be tied internally I assume) it would fit a PLCC84 footprint. The only reason I am "harping" on this is that I strongly believe it would allow you to sell many more chips, as it would be MUCH easier for prototyping, education, and small production runs.
- regarding PORTA/PORTB
I see two potential solutions that I believe would work and accommodate higher speed external access, both involve having two groups of ports, using two port addresses in cog memory - but mapping multiple ports to each of those two locations. I think this would be the best of both worlds.
A) Changing the meaning of the bits you are putting in slightly, and a bit of extra logic:
bit 6: 0=Port A group, 1=Port B group
bit 5: 0=external port, 1= (currently internal) future external port
bits 4..0: bit within the port
This would allow the BITSET/CLEAR/TOGGLE/TEST instructions - which I *GREATLY* appreciate! and it would allow faster external access
"PULSEHL" and "PULSELH" port,bit would be most welcome as well [noparse]:)[/noparse] giving a 160MHz pulse on the pin
Adding one more bit
bit 7: Port Group (0=A, 1=B)
bit 6,5: select port in group (allows for 8x 32 bit ports total for future BGA packages)
bit 4-0: select pin
This would also allow high speed access etc, and keep the single bit action semantics.
Consider the following contrived example using 6ns external SRAM
PORTA 0..23=address bus
PORTB 0..7= data bus
'Clear external mem, assume /WR pulled low, static ram
clear
mov outa,#0
mov count,CONST_16M
loop:
mov outb,#0
add outa,#1
djnz count,#loop
' now same thing with indexed ports
clear
SELECT PORTA
mov out,#0
mov count,CONST_16M
loop:
SELECT PORTB
mov out,#0
SELECT PORTA
add out,#1
djnz count,#loop
' I realize that the 0 could be left on the port, but what if you wanted to fill the memory with a pattern changing at each address?
The second case is 66% slower than the first case.
I have some rather ambitious plans for Prop2 [noparse]:)[/noparse] and need all the speed I can get.
Chip Gracey (Parallax) said...
Bill Henning said...
A few questions...
- On 100 pin TQFP, a lot more than 64 I/O's would be possible... are you considering perhaps 2x32 pin ports, and a 1x16 bit port for SPI, I2C etc?
- If it is 2x32 and 1x16 (which makes sense on a TQFP-100) could the other 16 bits be implemented internally? It would be great for cog-cog flags
- If there will only be 64 I/O's on the silicon, could you please look into a PLCC84 package? It would make prototyping MUCH easier, and through-hole PLCC84 sockets are readily available, allowing for through-hole designs
- If there are only 64 I/O's, I'd strongly prefer going back to the existing PORTA / PORTB mapping in Cog memory, as it would not require switching a port index to update ports, speeding up external memory solutions
<FONT color=blue>I see your point, but it would, on the other hand, force you into self-modifying code for pin parameters, whereas with the current scheme, you just select a port number from bits 6,5 of a variable, while bits 4..0 can provide the bit number. This keeps things simple, though I understand your rationale for wanting discrete port addresses.
Yes, it's great to receive those updates about the state of the design of the Prop II, as well as some insigts into the design/fabrication process. Very much appreciated! Knowing the number of I/O pins makes its much easier to envision designs involving the chip (of course, making such plans may not be the most well-advised thing considering that the chip is not out yet, but you know we can't resist).
I am wondering if it's still the plan to implement an SD card boot option, or whether members see any difficulties providing such. It seems like this is still the plan, and I hope so, as that would be quite convenient for many scenarios. It wouldn't seem to involve much in terms of hardware, other than the ROM required to store the SD code. Well, some kind of agreement would be needed for the pin interface, or an external selection mechanism (perhaps using a resistor as Cluso mentioned). If I recall correctly, ROM is the smallest/simplest memory element to fabricate (being read-only), so, hopefully, die space is not a problem (though don't know about any address space limitations). I know, not to worry...
Anyway, would providing such an SD boot option basically involve gutting the code of an SD object, keeping only what's required/essential to load the HUB? Guess so. Perhaps our SD crew here would care to comment. To the untrained ear, it sounds a bit scarry, though, because it wouldn't allow for changes (being fixed in ROM), but, I guess, if it works, it works ("works" meaning "boots"). For example, we don't need to worry about SD/SDHC/SDXC, when we're using SPI access. And we don't need things like sub-directory support (something that could be useful after booting and loading another SD driver of choice). But I don't know about the possibility for compatibility problems with various cards. Hopefully, most will work (with the possible exception of some micro SD cards where SPI support is not required). Anyway, I'm really hopeful that SD booting can make it into the final design if it's not too problematic. Again, thanks for the recent updates.
Fast chips like that need plenty of supply and ground pins, they simply won't work properly otherwise. Power has to be distributed evenly across the chip. Moreover, each supply and ground pin pair will have to be decoupled, adequate decoupling with what you propose will be impossible.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
potatohead said...
Agreed. I think it's pretty exciting. I also think it will be another layer to manage, that's all. That is why I wrote "only downside". There are a lot of upsides!!
IMHO, it will get abused, then it will get sorted, leaving us a nice, fast inter-cog comms.
I think it would be a lot cleaner to have live inter-cog channels that are based on cog#, not internal pin#, since cog# is reliably unique at run-time. In fact, it would take less silicon to make such a scheme, as opposed to internal I/O pins. Maybe some hybrid scheme could be realized where internal pin# ties to cog#. That way, there is a fixed rule that is reliable, and not subject to coding conflict.
The beauty of having internal pins, as opposed to·some generic inter-cog channels·is that the CTRs, video,·and WAITPEQ/WAITPNE all breathe pin states. So, I think it will be such that there will be internal pins, but they will have some mux'able relationship to cogs. That way, the cog#, which is dynamic at run-time, could be used as a selector, getting around the problem of agreed resource management among software objects.
Ok, I realize that the design is too far along for adding something like this. But one can dream!
How about something like:
Each cog gets a fifo, 8 levels (or more) deep. Any cog can write to it, by choosing which cog to send to via bits 24-27 of new FIFOCTL register
FIFOCTL new register, something like (leaves bits for 16 cogs later)
bits 0-7 = which cog sent it
bits 8-15 = reserved [noparse]:)[/noparse]
bits 20-23: which cog current top-of-fifo came from
bits 24-27: which cog's fifo to write to
bits 28-30: number of longs in fifo (0 = empty, 1-6 = number of longs, 7 = 7 or more, in case FIFO is larger than 8 entries [noparse]:)[/noparse]
bit 31 = new msg received (set when any cog writes to the fifo)
This way, cogs could block waiting for a message from any cog (bit31) or block waiting for a message from a specific cog (bits 0-7 (later 0-15))
FIFODATA
when the cog reads it, it reads words written to the fifo by any cog
when the cog writes to it, it writes into the FIFO of the cog specified by bits 24-27 of FIFOCTL, and each FIFO long has a 4 bit "tag" showing what cog it came from (moved to FIFOCTL when that long is the next long to be read)
This would be quite interesting, and blazingly fast
If the fifo was 16 levels or deeper, it could also be used as follows:
Chip, I think that's worth consideration. And something like that will scale without the usual pain of scaling kludges, where just the flat, "here are the pins, you all go for it" model won't.
Having that resource is compelling enough, I sure didn't want to shoot it down. [noparse]:)[/noparse]
I personally like "here are the pins, you all go for it". After all isn't that what makes the prop so versatile? This pin isn't tied to an ADC and that to an SPI port, .....
I think the 64 external pins will be "abused" if what you mean by "abused" is that some will allocate them for one object, and another will allocate them for another object, and consequently, those pin assignments have to be worked out in order to use both objects. I don't see the problem.
It's like buying an empty piece of land to do with what you want. Of course, If you are talking about also implementing N S E and West ports like in the SeaForth chip, I think it would be great for Prop III.
I just do not see the problem with having another 64 I/O pins which are internal to the chip. It is not a kludge IMHO.
Think of the advantages with the Prop 1 if we had those 32 PortB pins available now.
Why is that any different to using external pins for objects ??? We have to define those external ones·now. I do not want to see the internal ones tied to any specific cog. That is the beauty of the current design, all identical. And we will find ways to use them in conjunction with the counters in ways not yet thought of.
Boot from SD (microSD)...
This would be a great advantage. I·do this now on the RamBlade using the fsrw driver·(see the RamBlade thread, MIT license). Not requiring an eeprom, etc, would be a great option. Any future Prop II design is likely to include a microSD card and it means we do not have to preprogram an eeprom.
Chip has said there is plenty of ROM for the code, and if there is a bug, then provided it is an option, we just don't get to use it.
ROM code...
BTW, if we have the SD drivers in ROM, that is another bonus. I suggest a mix of spin and pasm, so maybe we can load objects from ROM.
It would be nice to have a number of standard objects in ROM (VGA, TV, Keyboard, FullDuplex, SD and of course USB if it is ready).
Design changes...
Chip said... ·So, I think it will be such that there will be internal pins, but they will have some mux'able relationship to cogs.
I get concerned that the design is still a long way from being frozen. I know it is great for us to keep making suggestions, but if we want Prop II we all need to be aware that any additions (or even possible additions) delay it.
Prop 1B...
Dare I mention this... The Prop II is still some time off... Do we want the Prop 1B in the interim, even if it impacts the Prop II delivery ???
Do you think that·the Prop 1B have it's own market aside from Prop II when it is released ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Everything about the Prop is quite carefully organized, Cog, Objects, locks, etc except the pins. More on that below.
The way I see the pin issue is this:
Currently:
The only way for the COGs to speak to external devices is through pins.
Many objects use pins and have the pin usage buried in the object somewhere.
Considerate objects take their pin usage from parameters.
The user of an object has to ensure it uses the pins the user wants.
Future Prop:
Can extend the idea of "external device" to include other COGs internally.
So we just uses pins to talk to those devices, its just more of the same as we have now.
OK some half of the available pins don't go off chip, so what.
Hopefully we are not just "bit-banging" pins in software but also have some enhanced serializer/deserializers that can shovel data through serially at 100MHz or whatever.
This all seems quite a neat extension of the current Prop.
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.
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
hinv said...
I personally like "here are the pins, you all go for it". After all isn't that what makes the prop so versatile? This pin isn't tied to an ADC and that to an SPI port, .....
I think the 64 external pins will be "abused" if what you mean by "abused" is that some will allocate them for one object, and another will allocate them for another object, and consequently, those pin assignments have to be worked out in order to use both objects. I don't see the problem.
It's like buying an empty piece of land to do with what you want. Of course, If you are talking about also implementing N S E and West ports like in the SeaForth chip, I think it would be great for Prop III.
Because it is always anticipated by object·programmers that a custom pinout will ultimately be dictated by the end-programmer,·object programmers must bend over backwards to accommode·any pin(s) at run-time. There is no possibility of pin conflict in this circumstance. What happens, though, when there are·a bunch of·internal·"pins" and there is no physical commitment necessitated? I have a feeling that object programmers would not take so seriously those pin assigments, and·afford them the·same level of flexibility·as they currently give physical pins. I also think end-programmers would be loathe to sort out which objects·get which internal I/O pins. It would take more discipline and code to keep things straight than would seem·(initially) necessary by everyone. Remember IRQ conflicts on the IBM PC's? That was a disaster that took the industry maybe 15 years to overcome. We need something that is "plug-and-play", right out of the gate. It would simplify life for everyone.
Here's what I think we'll do:
Each cog will have a single 32-pin internal port, which can be read/controlled like any other port via IN, OUT, DIR,·CTR's, video, etc.
In actuality, there will be EIGHT separate 32-bit internal·port output buses (one from each cog).
Each cog will have a special·8-bit register which can be·written to set the mask for which cogs' output ports will be OR'd together to form its own IN port.
This way, every cog can simultaneously output 32 bits and·input one or more other cogs' outputs.
For example, cog0 and cog1 want to establish a two-way 32-bit "window"... Both cog0 and cog1·set their internal DIR's to $FFFFFFFF. Cog0 sets his mask to %00000010. Cog1 sets his mask to %00000001. Now, whatever each writes to his internal OUT port shows up on the other's internal IN port. Other cogs are free to connect however they choose, as no scarce resources have been used up, as would have happened if we just had extra pins that were internal.
Another example: Cog0 wants to·release from·a WAITPEQ instruction·when any of cog1..cog7 output a 1·on their internal port's·bit0... Cog0 writes %11111110 to his mask. All other cogs set their internal ports' DIR's to $00000001, then each·sets bit0 of their internal port's OUT when some condition occurs that cog0 is waiting to trigger from. Cog0 executes a WAITPEQ ($00000001),($00000001), with the internal port selected. When any of cog1..cog7 set bit0 in their internal OUT, cog0 is released from the WAITPEQ.
Does anyone have any opinion on whether or not DIR is even needed for the internal port? I cannot think of a case where it is necessary, but maybe there is one. It would be nice to not have to initialize the DIR to be able to output internally, but maybe that register could just reset to $FFFFFFFF, and then it could be modified, if needed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 2/11/2010 8:40:48 AM GMT
Each cog will have a single 32-pin internal port, which can be read/controlled like any other port via IN, OUT, DIR,·CTR's, video, etc.
In actuality, there will be EIGHT separate 32-bit internal·port output buses (one from each cog).
Each cog will have a special·8-bit register which can be·written to set the mask for which cogs' output ports will be OR'd together to form its own IN port.
This way, every cog can simultaneously output 32 bits and·input one or more other cogs' outputs.
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. This way, now·we also·need to know the cog number we are talking with.
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.
I see a potential in using this where we have a 32 bit (say PortC) bus and·we start a block transfer with setting 1 bit (say Port D bit 0). Both cogs synchronise on the pin and the reading cog delays 1 instruction...
One cog writes a long to Port C, increments the internal cog address, and does a djnz to loop again
Second cog reads the long from PortC, increments the internal cog address, and does a djnz to loop again
This is a 3 instruction transfer, although you mentioned·a repeat instruction which may make this a 2 instruction loop. I would see it needs to be a 2 instruction loop as the write would be on 1 clock, the read on the next, and so on.
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.
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.
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).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Indeed, managing the chaos of the "pin soup" is something that the dev tool should be taking care of.
I kind of like the idea of the internal "pin-soup" It kind of fits with the Propeller philosophy of not having a special use for anything and everything should be general purpose. Not only that it makes it dead easy to migrate code out of one Prop into another should you need more than one. Just change the pin assignments from internal to external.
Would be great combined with fast serializer/deserilalizer hardware for blatting data around.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Some time ago one of my ideas ws to have "Mail type REGISTERS in COG's that one COG send to another info to them.
That every COG had 8 REG's as "MailBox"
Cluso.
Yes that can help much to many types of intercommunication ut to that we needs some free runings counters that we can program once and then simple WAIT ON them.
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.
# of internal pins:
For quick transfers, It would be awesome to be able to do 32bit handshaked transfers. To do this, we would need 32bits for data plus 2 bits for handshakes without special hardware. I can see these being set up and torn down at will, not necessarily "owned" by a cog.
Also the more pins available, the less contention.
Also, for future chips, it makes sense to reserve the ports so that if the TurboProp really takes off in demand (pun intended;^) a TurboPropCD could be just a logical I/O upgrade to 128pins. The intercog stuff could just continue, I would guess without problem as long as the
voltages were set apropriatly.
Management of pins:
I can see this pin management getting in the way. Yes, the IRQ problem was a problem, but the main problem is that a lot of this stuff was hardwired, or jumpered. It is not the same thing for cogs obviously. Cogs are software controlled.
Continuing development:
I was hoping that the TurboProp was really close and in "layout" which would mean real hardware soon (few months), but it seems not. I don't want to add complexity at this time. I am wanting to see what pin features you have developed, the 3D stuff, etc.
I want a TurboProp, not an Osborne II.
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.
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.
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.
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!
The propeller 2 needs to be easy to use. Not a fully of a bunch of extra complicated stuff that isn't necessary.
<End of RANT>
I really do not want to see the ASM messed up. It is really important to me and to alot of other people that it will be possible to port programs form the propeller 1 to the propeller 2 with minimal effort.
If a significant portition of our register space is missing for "extra" not neeed features life will be difficult.
Sorry, for yelling here. But I would like to be heard.
Sorry, i couldn't resist. i too agree with kye, adding things that will be of use to a few people will over complicate things and end up being useless to the masses, and someone, somewhere will be saying, why did they do this and not that? i think that the prop II will end up being more than anyone expected and doubt very seriously that anyone will be disappointed!
Comments
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
I'd use resistors and a 8T245 in your case...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
pPropellerSim - A propeller simulator for ASM development sourceforge.net/projects/ppropellersim
and later:
"Because of power and ground pin needs, not to mention die real estate, I think 64 I/Os is going to fill things up. S we're heading for 2x32-bit I/O ports with 2x32-bit internal ports."
So am I to interperate that as we are getting 128 I/Os with 64 of them available? If so, that is even better than I was hoping for
I REALLY like that "kludge", because to me, it is a feature! It's another communication method that has been used in the past, ie. "turbulence", at the cost of real I/O. We will be able to do both!
And if I understand correctly, we can use those pin features internally as well!
Am I alone in excitement about this?
Doug
And eeprom on P60/P61 or SD on P58-P61, anticipating we can boot from SD without an eeprom. Maybe some other boot options also. I was discussing with Chip on the old thread about using a single pin with various values of a resistor to +V or GND to determine the boot option.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
This will diminish the ease of plugging objects together as is done right now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Too bad you can't have just 4 more pins for Serial and EEPROM (whatever) IO.
Consider: COGs use pins to talk to "things". Only in this case the "things" are implemented in other COGs on the same chip so the pins need not come out of the chip.
potatohead: "This will diminish the ease of plugging objects together as is done right now."
Why? Right now objects use pins. When you are mixing and matching objects in your application you have to allocate you pins and adjust the objects accordingly.
If COG code is written that shares data through pins then you have to go through that same process.
That's not to say that there arn't better ways of communicating between COGs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
IMHO, it will get abused, then it will get sorted, leaving us a nice, fast inter-cog comms.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
- I like the idea of having two internal ports as well, very handy for inter-cog comm [noparse]:)[/noparse]
- I will be the first to admit that I know very little about the constraints you are under on ground/vcc and ground/vio pins.
On the drawing Beau posted, there were two pairs of Vcc/GND, and Vio/GND (8 pins total) per side. If that could be held back to 4 pins per side (perhaps Vcc/GND and Vio/GND - the GND's are going to be tied internally I assume) it would fit a PLCC84 footprint. The only reason I am "harping" on this is that I strongly believe it would allow you to sell many more chips, as it would be MUCH easier for prototyping, education, and small production runs.
- regarding PORTA/PORTB
I see two potential solutions that I believe would work and accommodate higher speed external access, both involve having two groups of ports, using two port addresses in cog memory - but mapping multiple ports to each of those two locations. I think this would be the best of both worlds.
A) Changing the meaning of the bits you are putting in slightly, and a bit of extra logic:
bit 6: 0=Port A group, 1=Port B group
bit 5: 0=external port, 1= (currently internal) future external port
bits 4..0: bit within the port
This would allow the BITSET/CLEAR/TOGGLE/TEST instructions - which I *GREATLY* appreciate! and it would allow faster external access
"PULSEHL" and "PULSELH" port,bit would be most welcome as well [noparse]:)[/noparse] giving a 160MHz pulse on the pin
bit 7: Port Group (0=A, 1=B)
bit 6,5: select port in group (allows for 8x 32 bit ports total for future BGA packages)
bit 4-0: select pin
This would also allow high speed access etc, and keep the single bit action semantics.
Consider the following contrived example using 6ns external SRAM
PORTA 0..23=address bus
PORTB 0..7= data bus
The second case is 66% slower than the first case.
I have some rather ambitious plans for Prop2 [noparse]:)[/noparse] and need all the speed I can get.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/9/2010 5:43:11 PM GMT
I am wondering if it's still the plan to implement an SD card boot option, or whether members see any difficulties providing such. It seems like this is still the plan, and I hope so, as that would be quite convenient for many scenarios. It wouldn't seem to involve much in terms of hardware, other than the ROM required to store the SD code. Well, some kind of agreement would be needed for the pin interface, or an external selection mechanism (perhaps using a resistor as Cluso mentioned). If I recall correctly, ROM is the smallest/simplest memory element to fabricate (being read-only), so, hopefully, die space is not a problem (though don't know about any address space limitations). I know, not to worry...
Anyway, would providing such an SD boot option basically involve gutting the code of an SD object, keeping only what's required/essential to load the HUB? Guess so. Perhaps our SD crew here would care to comment. To the untrained ear, it sounds a bit scarry, though, because it wouldn't allow for changes (being fixed in ROM), but, I guess, if it works, it works ("works" meaning "boots"). For example, we don't need to worry about SD/SDHC/SDXC, when we're using SPI access. And we don't need things like sub-directory support (something that could be useful after booting and loading another SD driver of choice). But I don't know about the possibility for compatibility problems with various cards. Hopefully, most will work (with the possible exception of some micro SD cards where SPI support is not required). Anyway, I'm really hopeful that SD booting can make it into the final design if it's not too problematic. Again, thanks for the recent updates.
Fast chips like that need plenty of supply and ground pins, they simply won't work properly otherwise. Power has to be distributed evenly across the chip. Moreover, each supply and ground pin pair will have to be decoupled, adequate decoupling with what you propose will be impossible.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 2/10/2010 5:26:09 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
The beauty of having internal pins, as opposed to·some generic inter-cog channels·is that the CTRs, video,·and WAITPEQ/WAITPNE all breathe pin states. So, I think it will be such that there will be internal pins, but they will have some mux'able relationship to cogs. That way, the cog#, which is dynamic at run-time, could be used as a selector, getting around the problem of agreed resource management among software objects.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Ok, I realize that the design is too far along for adding something like this. But one can dream!
How about something like:
Each cog gets a fifo, 8 levels (or more) deep. Any cog can write to it, by choosing which cog to send to via bits 24-27 of new FIFOCTL register
FIFOCTL new register, something like (leaves bits for 16 cogs later)
bits 0-7 = which cog sent it
bits 8-15 = reserved [noparse]:)[/noparse]
bits 20-23: which cog current top-of-fifo came from
bits 24-27: which cog's fifo to write to
bits 28-30: number of longs in fifo (0 = empty, 1-6 = number of longs, 7 = 7 or more, in case FIFO is larger than 8 entries [noparse]:)[/noparse]
bit 31 = new msg received (set when any cog writes to the fifo)
This way, cogs could block waiting for a message from any cog (bit31) or block waiting for a message from a specific cog (bits 0-7 (later 0-15))
FIFODATA
when the cog reads it, it reads words written to the fifo by any cog
when the cog writes to it, it writes into the FIFO of the cog specified by bits 24-27 of FIFOCTL, and each FIFO long has a 4 bit "tag" showing what cog it came from (moved to FIFOCTL when that long is the next long to be read)
This would be quite interesting, and blazingly fast
If the fifo was 16 levels or deeper, it could also be used as follows:
cog A reads XMM, stuffs fifo for video cog B
presto, bypasses hub for screen refresh!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 12:14:35 AM GMT
Having that resource is compelling enough, I sure didn't want to shoot it down. [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
I think the 64 external pins will be "abused" if what you mean by "abused" is that some will allocate them for one object, and another will allocate them for another object, and consequently, those pin assignments have to be worked out in order to use both objects. I don't see the problem.
It's like buying an empty piece of land to do with what you want. Of course, If you are talking about also implementing N S E and West ports like in the SeaForth chip, I think it would be great for Prop III.
I just do not see the problem with having another 64 I/O pins which are internal to the chip. It is not a kludge IMHO.
Think of the advantages with the Prop 1 if we had those 32 PortB pins available now.
Why is that any different to using external pins for objects ??? We have to define those external ones·now. I do not want to see the internal ones tied to any specific cog. That is the beauty of the current design, all identical. And we will find ways to use them in conjunction with the counters in ways not yet thought of.
Boot from SD (microSD)...
This would be a great advantage. I·do this now on the RamBlade using the fsrw driver·(see the RamBlade thread, MIT license). Not requiring an eeprom, etc, would be a great option. Any future Prop II design is likely to include a microSD card and it means we do not have to preprogram an eeprom.
Chip has said there is plenty of ROM for the code, and if there is a bug, then provided it is an option, we just don't get to use it.
ROM code...
BTW, if we have the SD drivers in ROM, that is another bonus. I suggest a mix of spin and pasm, so maybe we can load objects from ROM.
It would be nice to have a number of standard objects in ROM (VGA, TV, Keyboard, FullDuplex, SD and of course USB if it is ready).
Design changes...
I get concerned that the design is still a long way from being frozen. I know it is great for us to keep making suggestions, but if we want Prop II we all need to be aware that any additions (or even possible additions) delay it.
Prop 1B...
Dare I mention this... The Prop II is still some time off... Do we want the Prop 1B in the interim, even if it impacts the Prop II delivery ???
Do you think that·the Prop 1B have it's own market aside from Prop II when it is released ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The way I see the pin issue is this:
Currently:
The only way for the COGs to speak to external devices is through pins.
Many objects use pins and have the pin usage buried in the object somewhere.
Considerate objects take their pin usage from parameters.
The user of an object has to ensure it uses the pins the user wants.
Future Prop:
Can extend the idea of "external device" to include other COGs internally.
So we just uses pins to talk to those devices, its just more of the same as we have now.
OK some half of the available pins don't go off chip, so what.
Hopefully we are not just "bit-banging" pins in software but also have some enhanced serializer/deserializers that can shovel data through serially at 100MHz or whatever.
This all seems quite a neat extension of the current Prop.
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.
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Here's what I think we'll do:
Each cog will have a single 32-pin internal port, which can be read/controlled like any other port via IN, OUT, DIR,·CTR's, video, etc.
In actuality, there will be EIGHT separate 32-bit internal·port output buses (one from each cog).
Each cog will have a special·8-bit register which can be·written to set the mask for which cogs' output ports will be OR'd together to form its own IN port.
This way, every cog can simultaneously output 32 bits and·input one or more other cogs' outputs.
For example, cog0 and cog1 want to establish a two-way 32-bit "window"... Both cog0 and cog1·set their internal DIR's to $FFFFFFFF. Cog0 sets his mask to %00000010. Cog1 sets his mask to %00000001. Now, whatever each writes to his internal OUT port shows up on the other's internal IN port. Other cogs are free to connect however they choose, as no scarce resources have been used up, as would have happened if we just had extra pins that were internal.
Another example: Cog0 wants to·release from·a WAITPEQ instruction·when any of cog1..cog7 output a 1·on their internal port's·bit0... Cog0 writes %11111110 to his mask. All other cogs set their internal ports' DIR's to $00000001, then each·sets bit0 of their internal port's OUT when some condition occurs that cog0 is waiting to trigger from. Cog0 executes a WAITPEQ ($00000001),($00000001), with the internal port selected. When any of cog1..cog7 set bit0 in their internal OUT, cog0 is released from the WAITPEQ.
Does anyone have any opinion on whether or not DIR is even needed for the internal port? I cannot think of a case where it is necessary, but maybe there is one. It would be nice to not have to initialize the DIR to be able to output internally, but maybe that register could just reset to $FFFFFFFF, and then it could be modified, if needed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 2/11/2010 8:40:48 AM GMT
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. This way, now·we also·need to know the cog number we are talking with.
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.
I see a potential in using this where we have a 32 bit (say PortC) bus and·we start a block transfer with setting 1 bit (say Port D bit 0). Both cogs synchronise on the pin and the reading cog delays 1 instruction...
This is a 3 instruction transfer, although you mentioned·a repeat instruction which may make this a 2 instruction loop. I would see it needs to be a 2 instruction loop as the write would be on 1 clock, the read on the next, and so on.
I agree, but this is a software compiler issue, not a hardware issue.
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).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 kind of like the idea of the internal "pin-soup" It kind of fits with the Propeller philosophy of not having a special use for anything and everything should be general purpose. Not only that it makes it dead easy to migrate code out of one Prop into another should you need more than one. Just change the pin assignments from internal to external.
Would be great combined with fast serializer/deserilalizer hardware for blatting data around.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Some time ago one of my ideas ws to have "Mail type REGISTERS in COG's that one COG send to another info to them.
That every COG had 8 REG's as "MailBox"
Cluso.
Yes that can help much to many types of intercommunication ut to that we needs some free runings counters that we can program once and then simple WAIT ON them.
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
For quick transfers, It would be awesome to be able to do 32bit handshaked transfers. To do this, we would need 32bits for data plus 2 bits for handshakes without special hardware. I can see these being set up and torn down at will, not necessarily "owned" by a cog.
Also the more pins available, the less contention.
Also, for future chips, it makes sense to reserve the ports so that if the TurboProp really takes off in demand (pun intended;^) a TurboPropCD could be just a logical I/O upgrade to 128pins. The intercog stuff could just continue, I would guess without problem as long as the
voltages were set apropriatly.
Management of pins:
I can see this pin management getting in the way. Yes, the IRQ problem was a problem, but the main problem is that a lot of this stuff was hardwired, or jumpered. It is not the same thing for cogs obviously. Cogs are software controlled.
Continuing development:
I was hoping that the TurboProp was really close and in "layout" which would mean real hardware soon (few months), but it seems not. I don't want to add complexity at this time. I am wanting to see what pin features you have developed, the 3D stuff, etc.
I want a TurboProp, not an Osborne II.
<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.
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.
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.
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!
The propeller 2 needs to be easy to use. Not a fully of a bunch of extra complicated stuff that isn't necessary.
<End of RANT>
I really do not want to see the ASM messed up. It is really important to me and to alot of other people that it will be possible to port programs form the propeller 1 to the propeller 2 with minimal effort.
If a significant portition of our register space is missing for "extra" not neeed features life will be difficult.
Sorry, for yelling here. But I would like to be heard.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Sorry, i couldn't resist. i too agree with kye, adding things that will be of use to a few people will over complicate things and end up being useless to the masses, and someone, somewhere will be saying, why did they do this and not that? i think that the prop II will end up being more than anyone expected and doubt very seriously that anyone will be disappointed!
Post Edited (kf4ixm) : 2/11/2010 4:22:02 PM GMT
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM