Hi,

I am not strong with HW understanding, so I open this thread, because I would like to better understand, what XMOS (XENA) will be possibly used for.

First I though, that it is some really innovative concept, but now I think, that A-EON (Hyperion) just choosed one of many available CPUs, and added it into X1000.

If I am not mistaken, the work process is typical - you install IDE (Eclipse), you have some special SDK with special C compiler available. You code your app, utilising XMOS CPU capabilities. Then you compile it, and upload/program the chip. Then you reboot the chip, and it does some stuff.

The thing is, that it can work in rather autonomy kind of way, on its own, so I wonder what will be the linkage to AmigaOS itself? Such chips typically sport some microOS, so you will be able to link it to AmigaOS via some TCP sockets, UART (console), etc.

With frieds, we already use http://www.ubicom.com chips, which seem to be maybe even better integrated and capable, but are pricier and maybe not so universal.

Right now, I can't fully understand, what will be the real gain to have XENA inside, other than some fun factor, community factor, and the fact, that it is going to be present in all new Amigas. Because OTOH, on PC, you can plug special card to PCI-e or concentrate upon the future, which seems to lay in GPGPU architectures ...

Also - so far, so called "paralelism" looks more like hype. The concept still has to be proven usefull in daily life. PS3 and its uber cool Cell anyone? A fiasco, isn't it? ...

So - what's your opinion?

Quote:

-pekr- wrote: I am not strong with HW understanding, so I open this thread, because I would like to better understand, what XMOS (XENA) will be possibly used for.

It is a coprocessor (with 8 threads) which can do everything you like. As I understand it can access the main memory together with the PPC (?).

Quote:

If I am not mistaken, the work process is typical - you install IDE (Eclipse), you have some special SDK with special C compiler available.

I doubt the XMOS development environment will work under AmigaOS. But I'm sure there will be Amiga native tools in a short time.

Quote:

You code your app, utilising XMOS CPU capabilities. Then you compile it, and upload/program the chip. Then you reboot the chip, and it does some stuff.

I would guess that there will be some Amiga library or device for communicating with Xena (upload and start new threads, etc.).

@phx

The design tools are Java based. So now all we need is a java port.

_________________
Leo Nigro, CTO Commodore USA, LLC
Opinions expressed are my own and not those of C= USA.
Commodore/AMIGA "Beautiful, High-Performance, Home Computers for Creativity and Entertainment."

@-pekr-

Got this from user "JonathanMay":

I can't post on the forum yet (just signed up), but wanted to post the following. Can anyone help?

"Hi guys.

I'm from XMOS (www.xmos.com). Unsurprisingly, we noticed the activity on these forums... I thought I'd come along and have a read through.

First thing to say is that for technical questions about XMOS and the processor architecture - as well as free, open source tools downloads, many many applications examples and documentation, head over to the XMOS website (http://xmos.com) or the XMOS community website (http://xcore.com).

Couple of quick answers to the above: no there is currently no OS for the XMOS chips. You can use the parallelism for whatever you want. There are 8 threads per core, and the timing of the execution of the threads - written in high level languages such as C, C++ and XC - is deterministic allowing you to control hardware devices with real-time guarantees.

As regards to the "future" being in GPGPU architectures: that's a little tenuous in my opinion. They are hard to program, do not offer a very general form of parallelism and are somewhat limited to extremely data-parallel operations. They are also very expensive and inflexible. What is interesting about them is that their rise has demonstrated that it really isn't that hard to write parallel programs - even on unconventional, inflexible and constrained architectures with untidy languages. XC is a language developed by XMOS where parallelism is inherent and at the language's core:

par {
thread1();
thread2();
}

What will bring parallelism into the mainstream is a solid programming model and an architecture that efficiently executes this model. This is what XMOS believes it has created.

There will always be sceptics: this is why the tools are free and include a cycle-accurate simulator of the architecture: you can write some programs and try them out before you even buy an XMOS device.

Welcome on board and best of luck - I'll do my best to answer questions but as I said before, come on over to our forums/website if you want more detailed answers/discussion.

Jonathan"

_________________
Wiki for new/returning Amiga users - Projects: ACE basic compiler / FrexxEd / Git

These thigns seem a little like they blur the line between software and hardware. It's not a use it for this kind of chip, it seems programmable, and useful for various things, somewhat like how an FPGA chip is programmable and useful for various things. It's interesting to think of a "processor" being used as glue logic (digital locig to translate between bus protocols, such as to bridge PowerPC local bus to PCI slot, giving needed control translations between different things).

Doing it in software running on a processor is very different from how an FPGA works, which is nto software running on a processor, it's implementing a digital chip netlist using memory elements to define input/output gate truth tables (choose and gate, or gate, xor gate, etc), and lots of muxing to choose connections and include or not include flip-flops, etc much more like direct ASIC silicon design but with more overhead and thus less performance)

Look at the development kits on the Xmos site. The chip can be a USB chip, a sound chip, a uart, general purpose IO pins (twiddle how you like similar to microcontroller port-a/port-b things), ethernet, memory controllers, etc. and can probably give you ISA slots, Zorro (with a Z) slots, maybe PCI. The way that people that have known all along are talking, it can be just about anything you can imagine, given the pins can switch fast enough for such ideas.

I may be over-assuming when I say ISA, Zorro, PCI, etc. but until we have time to absorb specs, reference designs, etc. then there's danger of assuming wrong, but this is what things sound like to me.

But it's also a processor, and perhaps we can additionally think of it similarly to an SPE unit in the Cell. An FPGA can have a processor put into it as well, but who from the Amiga community has done anything with the FPGA on the SAM boards?

To whoever mentioned Video Toaster as a Zorro card, (not sure if it was here or another thread) it's not. It was a Video slot card. But similar potential, just create a Video slot instead of a Zorro slot. But, as the rest of the world has moved on to software-only video editing, High-Def, etc. why not consider the Xcore's potential as a replecement for the Toaster?


Seems they use Eclipse for their IDE, which I'd love to see ported to AmigaOS. Perhaps this provides some additional motivation to that end. Though Eclipse is a Java program, we need to get Java going, and then Eclipse should just run on that. So where an FPGA geek like me needs a Windows or maybe Linux PC to do FPGA design, there's some potential that Amiga fans could do comparable things using Xcore chips instead fo FPGA chips without going to a PC. All we need is Java, then we get Eclipse, and thus get the Xcore development environment.

That's pretty cool, and something that's extremely unlikely for FPGAs where the synthesis, place&route, etc. tools are controlled by the FPGA chip companies who are very protective of how their FPGAs work and won't make the good stuff open-source for us to port. Even though icarus Verilog has figured out some of that, it's got a ways to go before comparing evenly with the FPGA company tools.

The first thing that comes to mind for me, in either an FPGA or an Xcore, is to reimplement Altivec, should the mystery CPU not have that itself. I'm curious if that'd be worth it considering the slower clock speed, passing things over to an external device via PCI or Local Bus or whatever, and the software trapping involved, but I have recently aquired an FPGA on a PCI card to tinker with the idea. (as well as other ideas)

Last edited by billt on 05-Jan-2010 at 04:15 PM.
Last edited by billt on 05-Jan-2010 at 04:07 PM.

_________________
All glory to the Hypnotoad!

@billt

As well as potentially giving us a development environment we could potentially use in AmigaOS, there's also the design language aspect. You can design using something likely easier and quicker to learn for many Amiga fans, using their extensions to C language. For FPGAs, you mostly use either Verilog or VHDL, either way a new language to learn, as well as a new tool flow to learn. Xcore seems to use a software debugger, while FPGA geeks use simulators and waveform viewers, which likely nto many Amiga users are familiar with. Probably mroe of us are familiar with C compilers and debuggers than the FPGA style tools.

While Xmos offers a simulator, I can't yet say how that compares to how you simulate and interact with FPGA/ASIC designs.

I'm a chip designer, have done silicon layout of FPGA chips, and currently do IP integration and simulation for ARM-based ASIC chips, I would absolutely LOVE to be able to run a software debugger in these simulations to help debug the C code compiled and running on the ARM core. We CANNOT do that. At least not with the particular tools we have here. The best I've been abel to do is to is to step through the C source code running on the ARM core to see what line is being run, btu we cannot see current runtime values of variables in the source code. All I can see is a pointer to which line is currently executing. It's somewhat useful, but not nearly as good as having GDB.

Whether or not you can use GDB inside Xcom's simulation or not (just noticed on their web page that you can debug inside the simulator), you can apparently do it outside of the simulator such as directly to the chip on the X1000 board, which I expect will be possible on the X1000 motherboard. Compared to debugging some of my FPGA ideas, using GDB is pretty freakin cool. I really hope that it's useful in debugging what's happening on the IO pins configured as glue logic, bus protocols, etc. via GDB instead of requiring expensive scopes, probes, and logic analyzers, which I can't quite afford myself.

Last edited by billt on 05-Jan-2010 at 04:42 PM.
Last edited by billt on 05-Jan-2010 at 04:29 PM.

_________________
All glory to the Hypnotoad!

@vidarh

There is a thread on xcore.com forums in the general questions area asking, "So, who is behind the Amiga X1000?" They don't have an answer posted yet. But, it appears they have discovered us.

_________________
Amiga user since 1985.

It would seem to me that although this whole concept isn't directly integrated in the CPU ISA, we are still somewhat beating Intel and their Larrabee idea here.

For instance, I believe that this computer will be out before the first Larrabee enabled CPU, moreover the Xorro slot insures that this design is future proof.
You know intel, if you want a CPU with more Larrabee cores, just buy a new CPU, but here we could add a Xorro expansion card with a full cluster of these things!

_________________
SamFlex Complete 800Mhz System + AmigaOS 4.1 Update 4
Amiga 2000 DKB 2MB ChipRam GVP G-Force040 Picasso 2 OS3.9 BB2
AmigaCD 32

@BigBentheAussie

Only the IDE is, the rest is the usual GNU toolchain, modified.

_________________

@Thread

The XCore toolchain is based on LLVM. That means for PowerPC it will only be a matter of writing an AmigaOS 4 backend for LLVM and recompiling.

See the XMOS design tools source page for details.

@billt

Quote:

billt wrote: @billt I'm a chip designer, have done silicon layout of FPGA chips, and currently do IP integration and simulation for ARM-based ASIC chips, I would absolutely LOVE to be able to run a software debugger in these simulations to help debug the C code compiled and running on the ARM core. We CANNOT do that. At least not with the particular tools we have here. The best I've been abel to do is to is to step through the C source code running on the ARM core to see what line is being run, btu we cannot see current runtime values of variables in the source code. All I can see is a pointer to which line is currently executing. It's somewhat useful, but not nearly as good as having GDB.

As I said - I am not HW developer, but looking over the shoulder of my friend using Ubicom, it is absolutly natural that you can upload new version of SW dynamically, and device (CPU) reflashes itself. You can also debug in runtime. I would trash any environment, which does not allow that

Now that I finally started University -only ten years late!- and studying computer architecture, this XMOS stuff sounds like a sexy, sexy toy to play with my little new knoledges.

NetBean also in c/c++ to start with.

_________________
http://aros-exec.org/

http://serk118.blogspot.com/

@madmalkav

You're not alone. I just graduated 2 years ago and now I'm 35 years old! I switched from computer engineering to computer science part-way through though.

Just stick to the virtual instruction set at http://www.llvm.org/ and you'll be able to write XCore code like a champ in no time, not to mention that the same virtual instruction set runs on x86, PPC and others.

@-pekr-

The idea behind the XMOS (Xena) chip is to be many things at the same time. From my understanding it is a blend between an FPGA, microcontroller and DSP. An FPGA integrates an array of logic gates which can be wired in different ways to make different circuits, but they are difficult and time-consuming to program, and require experience in electronics, but with experience they can be made to perform many things in parallel. A microcontroller on the other hand is easier to program but usually does not have much parallelism. A DSP usually has high parallelism but is very limited in what you can do with it compared to an FPGA or microcontroller. It seems to me that the XMOS is meant to combine the advantages of those three technologies into a single device, so you can easily program it like a Microcontroller, allows high parallelism like an DSP or FPGA.

@vidarh

Welcome to both of you!

TrevorD

_________________
No, I don't need no reason, I'm just breezin'

There is an XMOS users forum. There is a thread regarding the X1000.

http://www.xmoslinkers.org/forum/viewtopic.php?t=700

_________________
AmigaOne X1000

I'm still trying to figure out what the advantages of the XCore architecture are. It sounds like a CPU with hardware support for up to 8 threads, and you can run 4 threads concurrently at full speed. Their website doesn't do the best job of explaining what the advantages are, or exactly what they mean with "event based."

I like the way that you can interconnect multiple CPUs, and have them communicating with ease, and the way that it can multi-thread without needing an OS, but exactly what makes it better for certain tasks then, say, an ARM7 micro which also has 64K of RAM, and has integrated peripherals, and its own 1-wire inter-chip comms. I'm guessing that more can be done with less effort. This is going to take some time to figure out.

I like the idea of having this chip on the motherboard, and a slot that provides access to I/O, and would allow more to be connected. It sounds like the perfect hacker's port for all sorts of hardware projects.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@billt

Quote:

billt wrote: Look at the development kits on the Xmos site. The chip can be a USB chip, a sound chip, a uart, general purpose IO pins (twiddle how you like similar to microcontroller port-a/port-b things), ethernet, memory controllers, etc. and can probably give you ISA slots, Zorro (with a Z) slots, maybe PCI. The way that people that have known all along are talking, it can be just about anything you can imagine, given the pins can switch fast enough for such ideas.

This is where things get fuzzy for me. It sounds like this USB port isn't an integrated peripheral, but I see no mention of FPGA-like functionality, anywhere. So, would this USB port be serviced via one or two of the processing core's threads? Possibly, given that it's "event based." ** If that were true, then I would eat through all eight threads in no time with many projects.

Hans

** isn't an IRQ routine also event based? What's different here?

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

By "event driven" they mean that the threads can be scheduled based on IO activity and timers. I.e. you can have a thread pause until a byte is written to a specific IO port. This is instead of the "traditional" model where an interrupt would be triggered, and the OS would have to dispatch an event to the proper thread. It allows very low latency / low overhead implementation of "simulated" hardware - their site has examples of things like UART's (it implements a simple serial port in less than a screenful of code), ethernet, a SID implementation etc.

It's not a a replacement for vector units (anything you'd consider using GPGPU for, for example), but an additional tool for things that require low latency IO interaction and/or parallelism where each thread or small group of threads do different things (one of their dev units has 64 cores, for 512 hardware threads...).

It will likely take quite a while before the true benefits of it starts to be realized (and I'll keep whining it apparently "only" has a single core instead of the quad one in the first model).

One big potential benefit: They can make it cheaper to make Xorro cards by allowing people to have less on board logic and instead rely on loading software onto the XCore to drive various logic on the expansion card. And given how cheap the XCore's are, people making expansion cards might even choose to use XCore's on the card as well if they need the added capacity, as a cheaper alternative to custom ASICs or FPGAs.

_________________
Wiki for new/returning Amiga users - Projects: ACE basic compiler / FrexxEd / Git