Methods for parallel propeller synchronization.

Clock Loop

This is a pretty big topic, and I hope people are willing to talk about their circuits, methods and programming, even tho, this is really the key to unlimited propeller power, as SOME have already taken advantage of. I.E. products that are only possible with multiple propellers running synchronized.

(scopes, gaming systems, etc...)


I had thought about it and most of my methods involve complex programming, which require a scope, and or timing diagrams written at the assembly level.

Anyone come up with an easy method?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
TERMS OF USE: MIT License

"Permission is hereby granted, free of charge, to any pers...........................
..............................OMITTED FOR FORUM...............................................
.................. OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. "

localroger

Clock_Loop, you're right, this is a big topic and a lot of it depends on your application. Most schemes will tie up a cog in each prop using some kind of protocol to keep parallel memory structures synchronized; this might be through one pin with an asynchronous serial protocol or with more pins for synchronous or parallel transfer for higher speed. More than two props might be connected to the same bus and take turns transmitting their changes.

All such schemes are going to have some synchronization latency, and it is the application that will determine how acceptable that is. In most apps offloading the user interface to something that isn't immediately updated will not cause trouble because human senses are slower than the interface latency. Robotic controls that might have timing critical responses to unpredictable real-world inputs would pose the biggest challenges.

I have been looking at the use of an external SPI RAM chip shared by multiple Props which take turns reading and writing to it; this has the advantage of not tying up a cog 100% of the time for communication. The props would still need an external way of making sure only one of them tries communicating with the RAM chip at a time.

ErNa

Don't care for latency: it is a proven experience, that good engineers can cope with any limitation. It is a necessity to have a uniform mechanism which is transparent to the location of the cogs and to the physical realization of the communication process. I do this for some time via pointer tables in global memory and synchronize spin and assembler processes with a single mechanism. Can show it, if you like, at the upew and will present it in the (now very chaotic and rudimentary) cmap (see link) after the event

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away

Leon

All that stuff was worked out many years ago by Tony Hoare with his Communicating Sequential Processes (CSP):

en.wikipedia.org/wiki/Communicating_Sequential_Processes

CSP were the basis for the Inmos transputer, and live on in the XMOS devices (both designed by David May). They have special hardware on the chip for synchronizing processes and communication channels, but something similar could be implemented in software.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 6/21/2009 5:13:33 PM GMT

ErNa

I worked with the transputer, still own some, and I still miss some features of OCCAM. But the propeller is a cheap hardware element and it should be possible to create a standardized communication protocol. But this needs some collective, concentrated and agreed upon work. After the upew I will try to reanimate an older thread and maybe, we can make some use of CSP know-how.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away

Leon

I was developing transputer-based systems 24 years ago. I don't really see the point of connecting Propellers together (there are much better devices for parallel processing), but CSP is the way to go if someone wants to do it.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

ErNa

So You just miss the application! We are awaiting PropII. Will there be 8 or 16 cogs? It doesn't matter, it will never be enough and to have a propellorized home, it need distributes hardware anyway And a standardized protocol to not alway start from adam and eve.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away

localroger

I don't think there will ever be a single standard solution for multiprop sync because application requirements differ so greatly.

There are indeed many reasons to connect multiple props, since the prop is an extremely cheap solution to a number of normally expensive problems. But if your application requires mroe than 8 cogs or 32 I/O lines you will need more than one. This isn't so unusual once you start applying the prop to industrial applications, and the other solutions are FAR more expensive.

Some applications will simply be tolerant of latency, such as user interfaces. (I will soon be designing a machine which will probably use one prop for the video, keyboard, touchscreen, and SD card interfaces, and another for a whole bunch of high speed machine timing; the interface between the two can be quite loose.) Others may have fixed windows, for example if a drive shaft rotates past a sensor you have a certain amount of time during which that can't possibly happen again, which you can use for sync comms. Others simply need to be done all on one bus, and with the prop that means one chip. I'm thinking of some high speed bagging and sorting applications where there are a lot of high speed I/O's going on and distributed decision making, such as systems with 8 scales that are constantly batching and then taking the best 3 of 8 to fill a single bag to generally get closer than one piece to the bag target weight. A lot of those things have 60 to 100 I/O's and they are making decisions on a millisecond basis as product and bags fly down conveyor belts and scales fill and are emptied. If it hiccups at the wrong time you end up with food on the floor.

Things like CSP are elegant and useful for things like avionics which must be absolutely reliable, and totally irrelevant to things like the prop where you don't have room for the implementation overhead and you're using the chip because it does $200 worth of work for $8. The prop isn't a supercomputer, it is an extremely cheap computing element that does certain previously very expensive things, like generating video, very elegantly and cheaply. It achieves this capability by making certain sacrifices, such as the 32K hub RAM limit and lack of external expandability, which require us to approach every application the way we approached them back around 1980. You need a certain amount of insight and cleverness to make it do anything useful at all; there are no one size fits all solutions. But when you do make it fit, you can get a lot done for eight bucks.

Leon

Applications like that are much simpler than true parallel processing using a MIMD architecture, which is the topic of this thread - Methods for parallel propeller synchronization. That requires something like CSP, which isn't necessarily limited to supercomputers or safety-critical systems, BTW.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 6/21/2009 8:57:20 PM GMT

heater

localroger: "Things like CSP are elegant and useful for things like avionics which must be absolutely reliable, and totally irrelevant to things like the prop where you don't have room for the implementation overhead"

I don't agree that it irrelevant to things like the Prop. Think how wonderfully useful it would be if one cog could write a LONG (say) to a special register or using a special instruction (wrchan) and that long was available to another COG (rdchan) as fast as silicon can allow via some COG-COG channel mechanism.

There are countless uses for such high speed links and that is CSP.

I've been campaigning for such on the Prop II. Not sure if anyone has noticed though.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

ErNa

heater, you are right and we will see, what Chip puts into prop two. I personally run a propeller with 8 cogs in parallel, exchanging up to 80 variables and for example, the visualization is done by mirroring selected variables to a propterminal. The housekeeping is quite simple, I start every coq only with a pointer to an array of pointers to variables somewhere in memory.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away

Leon

The transputer was a very simple device by today's standards, equivalent to a single Propeller cog, and even ran at the same speed (20 MIPS). It had high-speed (for the time) duplex links between chips implemented by 10 Mbit/s hardware link engines (four per chip), and virtual channels between processes. That was 24 years ago!

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 6/21/2009 9:35:59 PM GMT

localroger

heater -- for the prop, writing 32 bits is an atomic operation, and what you suggest is precisely what the Hub does all the time. You have a bigger potential for trouble writing tables or strings, which can be half-written by one cog when another decides to peek; that's why the LOCKs are implemented. If you need intercog comms faster than HUB RAM you can do it the way the Turbulence demo does, if you can spare the I/O pins. But unless you're trying to process real-time video or something Hub RAM timing will usually be plenty fast enough.

I've done a lot of work on platforms with limitations similar to the P1, and I'll maintain that in RL applications there will almost always be an application specific approach that is faster and leaner than any reasonably universal approach. When you have a megabyte of RAM instead of 32K and 128 pins of I/O instead of 32 you can start thinking about universal plug-in protocols that do it all for everybody in all situations. As it is I find myself hacking bits out of things like the TVTEXT object that I don't need in order to fit in things I do.

heater

localroger: No Problem, those imaginary COG-COG channels are serial. If you link COGs via channels, as per the transputer, there is no shared RAM bottle neck and no issues with multiple access to shared memory areas. That is maybe the chief CSP idea.

Perhaps the Turbulence demo is a good example of why COG-COG links might be a good idea. LUFT obviously saw the need for it.

Transputers and now XMOS chips make good use of these ideas without megabytes of RAM and using quite simple mechanisms.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Leon

It might make sense to have an inter-chip link accessed via the hub on the P2. Any cog could then have access to it, and it would be quite cheap to implement.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

ErNa

Whatever you do, it will be a compromise. The transputer was the OCCAM machine and lightyears ahead, but tungsten plugs and the never running T9000 virtual links broke his neck. Aside of what could be called "marketing" and the success of Intel. You could add 250 numbers by creating 250 processes and pipeline the execution. Nice code, but pour performance. However, I have to free one cog in my application and make him a communication controller to do interpropeller communication.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away

Clock Loop

One of my ideas to synch up a few props involved a master prop.

This master prop resets, and makes the clock for the slave props.

Instead of programming delays, communications, etc..

I thought about using a feedback clock that runs from each slave prop to the master prop.

This feedback clock is 5mhz, and is generated on the slave prop.

The master prop also generates a 5mhz clock for that same slave prop.

The master prop counts the feedback clock of all the slave chips individually, and determines which prop is the slowest, and which the fastest.

Then this master prop adjusts the clocks of all the other props to match one of the slave props.

So for a bit the master prop over or under clocks the too fast or too slow props, at the same time counting the feedback clocks of each prop to determine where each prop is in its program.

So bascially its like the master prop is controlling the throttle of all the slave props, and starts counting the feedback clock from each prop, to determine where in its program it is, and adjusts the clock to synch it up.

This is something I was thinking of doing at initial start, because we all know that the prop won't act normal when its clock is being changed.

The master prop would require all the timing code, but each slave prop would only require the bootup synch.

This method might be more complicated than its worth, I don't know, but its still something I would like to try. I am sure there are issues to this method that I can't think of right now.

(the attached image is the circuit. The two slave props on the right are not fully connected)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
TERMS OF USE: MIT License

"Permission is hereby granted, free of charge, to any pers...........................
..............................OMITTED FOR FORUM...............................................
.................. OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. "

Post Edited (Clock Loop) : 6/21/2009 11:42:10 PM GMT

Leon

That's a very messy way to do it, a classic MIMD approach would be much simpler. I just don't see why you are fixated on synchronized processors. What sort of application will it be used for? It would be a good idea to study the literature and see how other people have approached the design of parallel-processing systems.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 6/22/2009 12:01:37 AM GMT

Cluso99

Try using an external oscillator common to all props. Then they stay in clock sync.
The hub will still affect the sync by cycles but you can determine each cog within the scheme of things.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Clock Loop

Leon said...
I just don't see why you are fixated on synchronized processors. What sort of application will it be used for?
Leon

Fixated? Well for the fame, glory, and bragging rights of coarse... lol..

No app in mind, just didn't see much here about how one would go about accomplishing this.

Even my "messy" method might have some merit. Considering that the other methods discussed here involve precise assembly and spin.

To do proper synch, one would require a scope.

I am just trying to find ways to accomplish synch without having to resort to using assembly/spin programmed delays and a scope.

Plus if one WANTED to have different programs run on each prop, if the clocks were synched, and counted, the master prop would know how far into the program it is.

Even if programmed delays were put on one slave prop and not the other, the master prop would still have the feedback clock to count how "long" that particular prop was running..

Without even communicating with it.

Thats a pretty big deal, not having to communicate with a prop to figure out where it is in its program?
Messy, perhaps, but a new idea.. we need more.

Actually I see my idea as pretty interesting. I'll try it someday.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
TERMS OF USE: MIT License

"Permission is hereby granted, free of charge, to any pers...........................
..............................OMITTED FOR FORUM...............................................
.................. OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. "

Leon

Look at CSP and you will see why synchronized processors aren't required.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Clock Loop

Leon said...
Look at CSP and you will see why synchronized processors aren't required.

Leon

CSP is just a language to allow communication to do synch, if I understand it correctly.

I guess what I am getting at is keep as much as possible in hardware, to minimize the software overhead of doing the synch.

Using a single central clock would help, but then you can't adjust the clocks of the other chips to bring them into synch.

I guess I like the idea of NOT having to mess with a program to get it synched up. (communications)

Having the slave clock out a 5mhz signal is done easily by the props hardware no major programming involved, set it and forget it.

I like the idea of having a centralized prop that is the "DJ" who spins all the props into a synchronized song of many players. Players that don't even need to know about eachother, or communicate.

I mean if a central prop knows exacly where its slaves are, then that central prop can MOVE the PROGRAM to a different SYNCH spot, on the fly, by doing nothing more than adjusting the main clock of that slave.

I am sure there are limitations to changing the clock input of a prop. Like an upper and lower limit
before the program/prop/pll has an error.

This would be basically putting a PWM into the XI of the prop. But with limitations on upper and lower freq, plus duty cycle limitations.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
TERMS OF USE: MIT License

"Permission is hereby granted, free of charge, to any pers...........................
..............................OMITTED FOR FORUM...............................................
.................. OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. "

Post Edited (Clock Loop) : 6/22/2009 1:26:30 AM GMT

Cluso99

As I said above, use a crystal oscillator, common to all.
After a delay to ensure all props are running, the master pulses a line low. When a cog in each prop (waitpeq) detects this line going low they read the CNT register. This then provides the starting point for each prop. They can then be synchronised to this counter - it wraps about every 90 seconds.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Clock Loop

Cluso99 said...
As I said above, use a crystal oscillator, common to all.
After a delay to ensure all props are running, the master pulses a line low. When a cog in each prop (waitpeq) detects this line going low they read the CNT register. This then provides the starting point for each prop. They can then be synchronised to this counter - it wraps about every 90 seconds.

Hmm, ok thats pretty simple, the kind of stuff I was lookin for.

I still like the idea that I can use the master/slave prop setup as a state machine with my clocking method.

Its almost like you can control slave props without even telling them anything... except adjusting their clocks so they change their states.


I need to look into your simple suggestion and also my method.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
TERMS OF USE: MIT License

"Permission is hereby granted, free of charge, to any pers...........................
..............................OMITTED FOR FORUM...............................................
.................. OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. "

Cluso99

I used the sync method in my datalogger to sync 4 cogs (1 prop) to be 1 clock pulse apart so that each cog samples at 50nS, but staggered at 12.5nS.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

ErNa

A microcontroller is a programmable devise and therefor it can be adapted to different tasks. It will always be less effective as a specialized hardware. That is out of question. Studying old fashioned solutions often shows the way to very good new implementations. We now have more computing power this gives us the chance to start over. Often the core of a solution is covered by work arounds, resulting from available technology. Those before us were not stupid. They only missed the means. The transputer was an occam machine, and occam doesn't know about the numbers of physical processors. Configuration was separated from the software.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away

Leon

An occam program knew about the topology of the transputer system it was going to be run on at compile time. There were also occam worm programs that could determine the topology at run time. There were also C and Fortran compilers for the transputer, and I ported a LISP interpreter to it.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

ErNa

Yes. I know the story very well. Programming a transputer in C is like shoping with a formula 1 car (or vice versa). Misunderstanding is easy, so lets to this. Compile time should be after programming time At compile time (or was it linking, forgotten) you just had to tell, which channel are mapped on which port. And that didn't change the software structure. Exactly that should be a goal: make software transparent to hardware variations. But not with if's, then's, macro replacements and so on.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away