"As for the huge executables. Back in the day there was a WORM program for the Transputer that would boot up a network of nodes with the same code. The size and topology of the network was discovered as it booted. Seems like the XMOS needs such a WORM for arrays like this."
Yeah, but the transputer could receive its programming through a Link. If I remember correctly you just had to reset it and then it would be listening on one of its Links. I don't think this is possible with Xcores, internally cores 1,2 and 3 get booted over channel 0, but core 0 has to be booted from SPI or JTAG. JTAG is not such a bad idea because it makes debugging easier, especially in the case of malfunctioning XLinks. Unfortunately this makes it impossible for a WORM to selectively reboot nodes and 'worm' its way through a topology.
What is more serious at this point is that it doesn't seem to be possible to reboot individual nodes when they start misbehaving. I could be wrong but I think that the topology gets defined when all interconnected XCores boot up simultaneously. There is some magic going on that requires an XLink physically be available to both XCores it is connected to at the SAME (well, few seconds actually) time when both XCores are booting. This means booting of one XCore on its own will make it impossible to establish XLink connections to already running XCores.
FPGA supercomputer
nieuwhzn:
I would have to reread the docs to be sure of the xcore boot options but if the Transputer style "listening on links" is not an option then it looks like it would be possible to achieve by programming the OTP with a boot loader that simulates it. Thus supporting WORM loader.
As for both ends of a link having to come up at the same time, there is a way around that. It is described in the docs somewhere.
Over on the xlinkers forum there is a project that creates an XLINK in software on an AVR. It enables connecting to an xcore using the xlink hardware so no thread need be wasted on some other protocol. The xcore end of that link is used in such a way that the AVR and xcore need not come up at the same time.
This could also be allowed for in the transputer style loader in OTP.
As for not being able to reset an individual xcore, I guess that's a hardware issue. You might have to design your own array board that allows it.
I would have to reread the docs to be sure of the xcore boot options but if the Transputer style "listening on links" is not an option then it looks like it would be possible to achieve by programming the OTP with a boot loader that simulates it. Thus supporting WORM loader.
As for both ends of a link having to come up at the same time, there is a way around that. It is described in the docs somewhere.
Over on the xlinkers forum there is a project that creates an XLINK in software on an AVR. It enables connecting to an xcore using the xlink hardware so no thread need be wasted on some other protocol. The xcore end of that link is used in such a way that the AVR and xcore need not come up at the same time.
This could also be allowed for in the transputer style loader in OTP.
As for not being able to reset an individual xcore, I guess that's a hardware issue. You might have to design your own array board that allows it.
"Congratulations!"nieuwhzn wrote:I just received my XMP-64 yesterday.
Dynamic reconfigurable VM worm hole routing.
Dynamically resets, individual cores?
Certainly you may set up a simulated CSP VM with necessary flush.
It looks to me, that the Xmos is capable of ASMP as well as SMP.
To really scale would require a switching crossbar like @ 4links.com.
XMP-64 is hardwired hypercube and shure would be a blast racked.
What would kick it over the top would be a CSP tightly coupled RAM
server each 64kblock representing a VM. Then you add more Swithes
and RAM Servers as you scale. Who ever designs a CSP RAM server
should win project of the month.
Nieuwhzn your right, its not a Tranputer and we are going to
have to exploit the Xmos advantages. The Xmos follows the
Transitor model more closely than the Inmos hence no notion
of an external ram and on and on. One might first presume the
Xmos is lacking said feature or what ever, but I know this chips
architectural design is elegant and unique to the hardware and
software industries. Therefore all legacy notions are put in check.
The best an FPGA can do is put an Xmos hardcore within said fabric.
Although I do like what anti-fuse may do for an array, or prepossess.
I do like the Xmos Platform On Web idea, start with bare hardware
turnkey, not unlike Googles initial base. There have been a few FPGA
Cluster Super nets, the hardware tends to eat itself when they scale.
There is no consortium for programing fpga's, "RAMP is a mess!". XC
could very well become ML, HDL languge of choice for good hackers.The
opportunity to step outside the FPGA mob, because of XMOS, represents
a great approach to form and function for both hardware and software
people to converge upon.
Where in the docs? I still have 4 XC-1's lying around, would be nice to be able to hook them up together.Heater wrote:nieuwhzn:
As for both ends of a link having to come up at the same time, there is a way around that. It is described in the docs somewhere.
Look for XS1-L System Specification or XS1-G System Specification. They are on the XMOS documentation page under "silcon". They both have similar sections describing chip to chip link connections that are reset at the same time, or one is "hot pluggable" or there is a master/slave relationship.
3.2.2 Initialising a LLink comprising a single power and reset domain
3.2.3 Initialising a LLink comprising a hot plug
3.2.4 Initialising a LLink comprising master and slave domains
Sadly it does not give any examples of code that would do this, only some hints.
Hence I point you at the xcore to AVR project over on xlinkers. The AVR end is basically "hot plug" and there is code in the xcore end to handle it.
I think a similar thing is done in a project linking an xcore to an FPGA on xlinkers.
Also those docs talk about booting from links, I have not studied it so hard yet.
3.2.2 Initialising a LLink comprising a single power and reset domain
3.2.3 Initialising a LLink comprising a hot plug
3.2.4 Initialising a LLink comprising master and slave domains
Sadly it does not give any examples of code that would do this, only some hints.
Hence I point you at the xcore to AVR project over on xlinkers. The AVR end is basically "hot plug" and there is code in the xcore end to handle it.
I think a similar thing is done in a project linking an xcore to an FPGA on xlinkers.
Also those docs talk about booting from links, I have not studied it so hard yet.
Its interesting AVR, being early supporter, Atmel is well embedded.
They have a mature, very small granular AVR embedded FPGA, called FPSLIC
descendant of the AT40KAL series descended from the AT6000 series
They also have an new expensive AEROSPACE FPGA AT288fs, LP and so so.
Atmel is backing off the fpga business, so they say. FPSLIC extendable AVR.
I believe the FPGA interconnect info is listed in under system services.
I'll be interested in investigating how the AVR does its thing.
Dynamic reconfiguration, XC should deal with accordingly.
What are the PWM features or needed features?
MAPS, MASKS, LINKS, what is software definable at run-time?
go configure!
They have a mature, very small granular AVR embedded FPGA, called FPSLIC
descendant of the AT40KAL series descended from the AT6000 series
They also have an new expensive AEROSPACE FPGA AT288fs, LP and so so.
Atmel is backing off the fpga business, so they say. FPSLIC extendable AVR.
I believe the FPGA interconnect info is listed in under system services.
I'll be interested in investigating how the AVR does its thing.
Dynamic reconfiguration, XC should deal with accordingly.
What are the PWM features or needed features?
MAPS, MASKS, LINKS, what is software definable at run-time?
go configure!
http://www.xmos.com/kbase/index.php?Vie ... EntryID=23nieuwhzn wrote:"
What is more serious at this point is that it doesn't seem to be possible to reboot individual nodes when they start misbehaving.
Hope this can help.