Has anyone done anything truly advanced with the Prop?
MarkS
Posts: 342
I was thinking about doing something kind of advanced, like a neural net, or just a network of Props, if that's the wrong term. These things (Props) are dirt cheap and easy to interface. So far, I've only seen one multi-Prop set up, which used 16 Props to control a large display.
I was thinking about using a 16-bit shift register (SR) to connect 16 Props together. With a shift register, all you would need is two pins per Prop. One pin connects to one of the 16 SR outputs and is always an input. The second pin is either an input or output, depending on the state of the other pin. When the SR outputs a low to the first pin, the selected Prop outputs data to the other Props on the second pin, if needed. If the SR output is high, then the second pin is set as an input and the Prop listens. Whether the data is needed by the Prop is determined by each individual Prop. One cog from each Prop would be set aside for inter-Prop communication. With this set up, it should be possible to link multiple 16-Prop clusters together with very little difficulty. At least in theory.
Would this work? What are the downsides to this method? Are there better methods? What could be done with a cluster like this?
Post Edited (MarkS) : 9/9/2007 2:01:36 AM GMT
I was thinking about using a 16-bit shift register (SR) to connect 16 Props together. With a shift register, all you would need is two pins per Prop. One pin connects to one of the 16 SR outputs and is always an input. The second pin is either an input or output, depending on the state of the other pin. When the SR outputs a low to the first pin, the selected Prop outputs data to the other Props on the second pin, if needed. If the SR output is high, then the second pin is set as an input and the Prop listens. Whether the data is needed by the Prop is determined by each individual Prop. One cog from each Prop would be set aside for inter-Prop communication. With this set up, it should be possible to link multiple 16-Prop clusters together with very little difficulty. At least in theory.
Would this work? What are the downsides to this method? Are there better methods? What could be done with a cluster like this?
Post Edited (MarkS) : 9/9/2007 2:01:36 AM GMT
Comments
I'm one of those guys that would love the Prop if it only had one pin. It's pretty RISCy... which I like. I don't know why we need a SUB instruction... and I hate the idea of putting a multiply operator into the PropII. Your design is perfect... as it is... for some rather sophisticated number theory applications...and as a pure computing environment.
? have you seen this by Chip: http://forums.parallax.com/forums/default.aspx?f=25&m=130452
Your design looks like a super-hub. So not only is your design elegant, but it will be conceptually understandable since it is analogous to the Prop design.
I have been waiting for someone to implement (since it is beyond my scope!) a parallelized graphics and signal platform. Maybe you will be the one!!!
It would be usefull if you could group at least some of the pins... for instance take all of the normal video pins and bring them out together toward an interface. It would be nice to have a little DMA area, with another grouping of same numbered pins interfaced to it. A few other shared resources would be nice!
If you don't have a common clock... you are going to regret not having a common clock.
Get a loan... buy a building... do it!
Rich
By the way... why not stack 16 proto boards?... 4 long bolts, a couple of wires, and a HUGE battery and you are in business[noparse]:)[/noparse]
You could use one Prop with a crystal and use a Frequency Synthesizer OBJ and one pin
on the master and pipe that to the other Props.
This the the scheme I'm using with a 2-Prop board; works great. 5 MHz crystal provides
80 MHz in master, Freq Synth outputs 5 MHz to second Prop which also runs at 80 MHz.
This eliminated capacitance of several inches of trace between Props from clobbering the
waveform.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
asking whether it would work.. Yes it would! It is a "time slicing" algorithm (as used in the HUB-COG system, as Rich rightly remarked) Such algorithms are considered highly inefficient, but are easy to implement and stable. They are useful for equalized bandwidth and low response time applications.
The main drawback - needing a dedicated master - has been addressd by "token passing" mechanisms.
Practical engineers work for around 30 years to find the best solution, and what we have is ethernet, a basically highly unreliable CSMA/CD protocol...
For highend applications variant of cross bar switches are used.
So you can imagine there is a lot to read about this matter...
I think everyone has played with two or even more Props at a time (I think I also posted an image of six Props on a cheap bus motherboard two monthes ago - very elegant!).
The main problem is the higher levels of the comunication protocol. The Propeller is - despite its internal architecture - not better equipped for this as the next best $1 processor!
What we need AT LEAST is an implementation of
XCOGNEW(...) Starting a COG on a remote chip (with local code? with remote code?)
XRD/WRLONG Reading writing a word from/to a remote HUB
XLOCK central locking
It is of little concern how the physical layer looks like - of course just my personal opinion!
Edit Just BTW: I had a long discussion with BTX monthes ago about this: Do not forget the fan-out constraints! Having 16 "listeners" will reduce the transmission speed due to their input capacity. Let's take 10pF as worst case times 16 = 160 pF driven through 100 Ohms is about 32 ns = 30 MHz.
Post Edited (deSilva) : 9/9/2007 7:12:10 AM GMT
I can see where there could easily be some modifications that would take up a lot less band-width·, for instance,· 100 processors, instead of· 6400··bits, might have a·100 bit·"window" ·where each processor could set a "I got something to say" bit indicating their data had changed since the last frame. out of 100 processors, maybe only 5-6 might actually have something to say.
Each processor would have·to be programmed with it's own address or have·some sort of·start-up addressing·function, but the ability to have a lot of processors talking to each other (·no matter whether they are on the same board or not ! ) makes·distributed processing reasonably easy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
" Anything worth doing... is worth overdoing. "
··············································· ( R.A.H. )
····································
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec
My our page
Bus1 Bus2 Bus3 Bus A 1A <----> 2A <----> 3A ^ ^ ^ | | | v v v Bus B 1B <----> 2B <----> 3B ^ ^ ^ | | | v v v Bus C 1C <----> 2C <----> 3C ^ ^ ^ | | | v v v Bus D 1D <----> 2D <----> 3DThe tricky part is the software. One (hopefully) cog will need to be dedicated to processing and routing signals along their way from one cog to another. There is a fairly simple routing protocol that would need to be implemented to send messages between nodes. The protocol is completely dynamic; routing decisions are made on-the-fly as I2C messages move between the different propellors. There is probably less than a byte timing of latency for each hop of a message and no intermediate buffers are needed to hold messages being forwarded. It depends in large part on the ability of I2C for both the host and slave to control the timing of the link.
Clearly if you wanted to send to a propellor that was directly attached to one of your buses (that is, it had the same X or Y address) you'd just pick that bus and blast out your message. The other props on the bus would listen and one of them would recognize itself as the destination of the message.
However, if you wanted to send a message from 1A to 2B, you'd need to route through an intermediate propellor. To do this, you just pick any available bus (either the least busy or LRU) and send the message out on that bus. Every propellor on the bus will examine the message. One of them will share part of an address with the destination and it will know that it needs to route the message, since it can bring it one step closer. While routing a message, an entry is set up the the routing part drives the I2C buses in parallel. The route monitors the I2C state transitions in order to switch the communication direction between the lines in the involved buses but otherwise just copies the input side of each line to the output side. When a stop state is detected the route is freed.
In 3 or more dimensions you need to take a little more care in your choice of bus to send on. Whenever you receive a message to forward you always want to pick a bus that's closer to the destination address. You don't want to send the message off along a bus where you are already on the correct coordinate. In 3D you can be routing along 2 buses and the third may ask you to route for it (by presenting a packet with your Z bus address). The router can hold off the communication using I2C handshaking until a route is available.
A broadcast address might be useful.
Caveats: I haven't analyzed this for fairness, there could be significant contention issues. Areas for tuning involve the choice of bus (other than I2C) and the method of picking the best bus to forward on. This would probably work for SPI as well. This might be hard to fit into one cog. Top speed may be low. A 3D mesh would require some wizardry because things do get more complicated. More cogs could be used to speed up overall performance. Other buses might use the timers for faster operation.
Good stuff: Scales incredibly well. A 4x4x4 64-propeller mesh would have 48 seperate buses (and 288 wires). If each bus could run at 1Mb/s (I don't know if this is feasible) there would be 48Mb/s aggregate bandwidth and would run at 9GMips. Although the system could provide I2C services, it will also operate transparently if you use a spin or other multi-master compatible I2C component to drive the bus (if routing is going on a well-behaved I2C component will see the busy bus and wait to send).
Post Edited (acy.stapp) : 9/13/2007 4:43:47 AM GMT
I see also that my following arguments stil hold:
(1) Problems and solutions addressed have nothing to do with Propeller specifics, but are common knowledge for all processor communicatin for around 30 years now. Re-inventing wheels should always go hand- in-hand with throurough readings
(2) It has proved extremely useful to consider protocol layers of whatever kind to not get confused with what you are talking about. ISO/OSI is porfect, but it should be always considered:
-- physical
-- data link
-- routing
-- application
On each (of the first three) layer there are well known pros and cons for many realisations
(3) Network topology and geometry as brought-up by acy.step is an extremely interesting topic. However mesh routing is not the simplest task...
If we only had transputers...