Parallel processing
Veronis
Posts: 1
I am a prof at GWU and plan to write a manual on parallel processing using the Propeller as the main platform. Could someone direct me to the following:
(1)Articles on this forum or elsewhere discussing the parallel processing capabilities of the Prop.
(2)Example code setting parallel processing between clogs in one chip and intercommunication between chips.
I would be very grateful for any assistance I receive.
Andrew
(1)Articles on this forum or elsewhere discussing the parallel processing capabilities of the Prop.
(2)Example code setting parallel processing between clogs in one chip and intercommunication between chips.
I would be very grateful for any assistance I receive.
Andrew
Comments
There's very little on intercommunications between multiple Propellers since only a few people have done this for high speed general purpose communications and have focused mostly on how to get the data from Propeller to Propeller using only a few I/O pins and not much in the way of other resources.
There's all sorts of examples of communications between cogs since most I/O drivers contain a mix of high level (Spin) and low level (assembly) code and the assembly code occupies a cog when running.
Have a look through the various "sticky threads" in this Propeller forum. They contain a lot of information including examples of Spin and assembly.
I am not an expert... so, please consider what I say with the grain of salt that it deserves[noparse]:)[/noparse]
I found one of your ppt presentation about PL design using VHDL, but I have not been able to find much "on-line."
http://books.google.com/books?q=andrew+veronis&source=citation&sa=X&oi=print&ct=title&cad=bottom-3results&hl=en
produces a very impressive list of your books and articles.
This forum is full of highly talented and very serious thinkers... don't be afraid to challenge them!!! What seems to work best are very specific questions, which always get answered in a highly informative manner.
You should consider Andre's book for one of your classes.
To make the best argument for the PROP, I think you will have to choose a problem, which has a grain that is coarse enough to justify the time required to read from or write to uSD but small enough to fit the algorithm into RAM. I have a short list of good problems.
I think a "PROP only" network is ideal... but to get there quickly is quite a challenge. I would love to see an intermediate (educational) networking product based on a FPGA/CPLD to generate the clock, handle the housekeeping and share the memory problem. Andre Lamothe has done some good work in this area.
You might consider using ImageCraft's C compiler in one of your courses. This will allow you to test more extensive algorithms.
Mike Green's various implementations of Femtobasic are a treasure trove of technical solutions and programming solutions.
Rich
... given all of "that" ... you might consider the possibility of inviting a NIST guru to send you a super-duper clock... which might also provide you a long term funding solution[noparse]:)[/noparse] No doubt there is a technology transfer officer waiting for your call[noparse]:)[/noparse]
Post Edited (rjo_) : 5/21/2008 2:24:41 AM GMT
I want to say: it doesn't matter, how you teach people to work with parallel processes, it is important to show them the advantages before the are caught by the promises of the virtual world of easy living.
void main()
{
extern int _textmode;
int i;
_textmode = 1;
asio_init(57600);
asm("cogid %i");
printf("My COGID is %d waiting for a key()\n", i);
getchar();
printf("starting COG%d, return value %d\n", 0, coginit(0, BlinkLED22, &stack[noparse][[/noparse]20]));
printf("starting COG%d, return value %d\n", 2, coginit(2, BlinkLED21, &stack[noparse][[/noparse]40]));
printf("starting COG%d, return value %d\n", 3, coginit(3, BlinkLED16, &stack[noparse][[/noparse]60]));
printf("starting COG%d, return value %d\n", 4, coginit(4, BlinkLED17, &stack[noparse][[/noparse]80]));
printf("starting COG%d, return value %d\n", 5, coginit(5, BlinkLED18, &stack[noparse][[/noparse]100]));
printf("starting COG%d, return value %d\n", 6, coginit(6, BlinkLED19, &stack[noparse][[/noparse]120]));
printf("starting COG%d, return value %d\n", 7, coginit(7, BlinkLED20, &stack[noparse][[/noparse]140]));
printf("entering echo loop\n");
while (1)
putchar(getchar());
}
***
A COG to blink one LED. Talk about a waste of power I will release BETA4 in the next few hours with the capability.
// richard
http://www.xmos.com/
I've thinking of designing my own board for the XS1 chip, like I did for the transputer when it first came out, and have started creating the PCB part.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 5/21/2008 12:50:22 PM GMT
······ Would you consider creating a Yahoo group or some other venue to discuss your Xmos board? I think there would be a lot of interest in it and until it dovetails with a Parallax product it probably isn't appropriate to discuss it in depth here.· A number of applications immediately come to mind (one current Propellor thread discusses using other micros as intelligent memory/port expanders and the Xmos chip would be perfect for that). I wrote a simple z-buffer renderer for transputers in the early 90's and I think there might be just enough on-chip RAM to implement a 16-bit z-buffer for Hydra users.
-phar
The Parallax reference books tell you what the keywords are and do, but the LaMothe book tells you exactly what's going on when you load 'Spin' code and then use that code to load Assembly into other Cogs, and how those Cogs can use "Main Memory" to communicate. It also uses a multi-Cog approach to implement computer games utilizing an off-the-shelf PS2 PC Mouse, off-the-shelf PS2 Keyboard, Composite Video, VGA Video, and NES controller. With excellent performance and all source code included.
The HYDRA system board also has already wired a simple RJ-11 phone jack for implementing board-to-board communication.
Now, mind you I've only been working with the Hydra for a month or so. And Parallax does sell a nice Propeller board-with-chip for $20 for multi-chip/multi-board exercises (you'll need to order a $25 Prop-Clip or Prop-Plug to program the $20 board)
http://groups.yahoo.com/group/XMOS_UG
XMOS themselves will probably form their own group before long, like Inmos did with the Occam Users Group.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
this is off topic; if that is a problem, please feel free to say so.
Leon et all,
I'm struggling to understand this. So, I'm not trying to act ignorant, I actually am ignorant[noparse]:)[/noparse]
Do you see the potential to use the XMOS FPGA for hooking up a network of Props?
Wouldn't it be better to use an industry standard for this sort of thing?
For example, I've seen imaging solutions for under $150 from Altera, and the development tools look unreal.
Where does XMOS fit?
Rich
-phar
The chip is attracting a lot of interest and they have plenty of VC funding, so it should be quite successful.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 5/25/2008 12:21:11 PM GMT
One of the most attractive features of the forum is the free flow of information and opinion... I will now try to track back to your topic[noparse]:)[/noparse]
Guys,
Thanks for the response.
IF we were to compare the MIPS equivalent of the counters on the PROPI and PROPII to the XS1, where are we in terms of overall bandwidth? (No cheating allowed...)
How do we quantify the MIPS effect of interrupt driven logic to state of the art Propeller logic?
On the software side... $1000 seems very reasonable[noparse]:)[/noparse]
Doctor Veronis,
Notice that my attempt to return to your topic didn't actually work... but I got close!!!
There will be a PropIII... I have a feeling that it will look a lot like multiple PropIIs on a single chip...
AND VC will not be required[noparse]:)[/noparse]
You are in the right place... with the right skill set... at the right time.
Rich
It's a completely different approach. For instance, a single XS1 core can have up to eight threads, with single threads devoted to SPI, PIO, I2C, UART etc. Cores can operate in parallel, with their own threads. Peripherals are implemented in software, like the Prop, and only take a few lines of code. Here is a UART transmit function written in XC:
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 5/25/2008 4:20:13 PM GMT
The Propeller has a much larger state (2K bytes) associated with each processor and the processors are not scheduled unless they attempt to use one of the hub resources (like the shared memory). In other words, they run at full speed simultaneously unless they're explicitly blocked.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
May has to find the "killer application" and he will never bring the money back if he addresses amateurs as we are.
Is software and full hardware.
·· On the other hand, in the area of microcontrollers and DSP's, software compatibility doesn't count for that much. If you just look at TI DSP's, they have conventional DSP's, transputer-like DSP's, VLIW DSP's. I think there's plenty of room for XMOS, they just have to outperform the competition in enough applications. And I don't think they should cater to amateurs either, but that doesn't mean being unacommodating. Microchip, for instance, has done pretty well giving away software. I don't imagine that decision was based on the hobbyist market, but it certainly makes it nice if you are a hobbyist.
·· From my perspective, the XMOS chip is an experiment and if people like us aren't going to experiment, who is?
-phar
I note Veronis has not replied.
Evan
(1)Articles on this forum or elsewhere discussing the parallel processing capabilities of the Prop.
(2)Example code setting parallel processing between clogs in one chip and intercommunication between chips.
I twice tried to point to the cmaptools which can be downloaded for free cmap.ihmc.us/. With help of this mapping tool it could be possible to bring better order into the object exchange, document software, describe programming patterns and so on. As a professor you can have the server software too.
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
just points to the WWW-representation of the actual cmap. The advantage is, that anyone can have access and can contribute his knowledge. The backdraw is: the result come from cooperation
I didn't go on with this work, because there was no resonance, but different other effords to bring more order into the chaos, and, as long as there is not real working together, this only blows the chaos up.
Post Edited (ErNa) : 5/26/2008 1:51:54 PM GMT
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle