XMOS XC-1 kits are shipping

"Leon" <leon355@btinternet.com> wrote in message 
news:3d4b6f41-b742-405d-87bd-47e2fb75ac1d@8g2000hse.googlegroups.com...
"Not if you have four 400 MIPS cores on the chip, each with 64 bits of
I/O, 64k of RAM, with 3.2 Gbit/s comms links between cores and 32
threads per core, with switching between threads in one clock. If the
software is free, it is a very cost-effective solution, especially as
the chips will be very cheap."

Well, if you're already bought the MIPS, then you're correct, Leon, you might 
as well get some free peripherals out of it.  This is certainly the case with 
PCs, where even a cheap box has a several GHz CPU and -- for 90+% of users --  
has tons of free cycles sitting around that can be used for soft modems, sound 
card DSP, etc.

On the other hand, for embedded systems the best solution isn't always so 
clear-cut.  Look at everyone using FTDI (or similar) USB to RS-232 chips with 
some dirt cheap low-end microcontroller -- often this approach is cheaper 
overall than using a "USB microcontroller," especially if the product volumes 
are low so development cost is significant.  Or look at John Larkin's boxes --  
he uses an Xport to turn Ethernet back into serial, since (presumably) overall 
it's cheaper/more effective than having one of his guys sit down and figure 
out how to add an Ethernet stack to his 68k-family CPUs.  Even though the 
stack itself is surely freely available somewhere, the integration time is 
still significant.

---Joel

Leon wrote:
> Not if you have four 400 MIPS cores on the chip, each with 64 bits of
> I/O, 64k of RAM, with 3.2 Gbit/s comms links between cores and 32
> threads per core, with switching between threads in one clock.

That's somewhat more on-chip resources and higher performance than we
had at Ubicom, but it's also trying to do commensurately more
sophisticated and higher performance functions in the software, so I
don't expect it to actually work out any better than things did for
Ubicom.

> If the
> software is free, it is a very cost-effective solution, especially as
> the chips will be very cheap.

Software is NEVER free, even when someone is giving it away.  You'll
pay for it one way or another.

Eric

On Tue, 14 Oct 2008 14:28:50 -0700, Eric Smith wrote:
> 
> Software is NEVER free, even when someone is giving it away.  You'll
> pay for it one way or another.

Dude, you gotta learn where to shop. ;-)

Cheers!
Rich

Rich Grise <rich@example.net> writes:
> Dude, you gotta learn where to shop. ;-)

I'm also going to have to get myself one of those prestigious
example.net email addresses like you have.  I hear that they
provide really good spam filtering.  :-)

I've just received my XC-1 kit and have started playing with it. It
comes with a nice demo that does interesting things with the LEDS,
buttons and speaker, uses a UART, and includes a simple game.

The tools are open source, and work OK from the command line. The IDE
uses Eclipse, and I can't seem to get an XC program to build properly,
although a C program is OK.

Support on the Xlinkers forum is very good; I've asked a few questions
there and an XMOS engineer has answered them in a few minutes.

Leon

On 14 Okt., 15:57, Leon <leon...@btinternet.com> wrote:
> On 13 Oct, 20:42, Eric Smith <e...@brouhaha.com> wrote:
>
>
>
>
>
> > Bob wrote about XMOS:
>
> > > They seem far too fixated on doing everything in software, things like
> > > ethernet where there is no point shoveling bytes in software if
> > > hardware can take care of it.
> > Leon wrote:
> > > They are supplying free libraries for all the usual peripheral
> > > functions. Doing stuff like that in software is much cheaper than
> > > using hardware, and easier in many ways.
>
> > Been there, done that, and it's not cheaper or easier when you
> > consider the overall system cost impact, not just the "benefit" of
> > leaving out the hardware block. &#4294967295;That was the path Scenix/Ubicom went
> > down, calling it "virtual peripherals", and it was not very
> > successful. &#4294967295;Ubicom has since added hardware for Ethernet, USB,
> > etc. to their most recent parts. &#4294967295;The reality is that a hardware
> > Ethernet MAC costs less than the total system cost impact of the
> > software alternative.
>
> > Eric
>
> Not if you have four 400 MIPS cores on the chip, each with 64 bits of
> I/O, 64k of RAM, with 3.2 Gbit/s comms links between cores and 32
> threads per core, with switching between threads in one clock. If the
> software is free, it is a very cost-effective solution, especially as
> the chips will be very cheap.

XMOS found a way to make their chips so cheap, that they can do
everything cheaper in software than all others in hardware?
Why don't they sell this revolutionary technology to semiconductor /
FPGA companies then?
They just wouldn't tell anyone about it and the same big Market would
use it without knowing,  but at lower prices.

On Tue, 14 Oct 2008 15:32:45 +0100, Paul Carpenter
<paul@pcserviceselectronics.co.uk> wrote:

>In article 
>  <3d4b6f41-b742-405d-87bd-47e2fb75ac1d@8g2000hse.googlegroups.com>, 
>leon355@btinternet.com says...
>> On 13 Oct, 20:42, Eric Smith <e...@brouhaha.com> wrote:
>> > Bob wrote about XMOS:
>> >
>> > > They seem far too fixated on doing everything in software, things like
>> > > ethernet where there is no point shoveling bytes in software if
>> > > hardware can take care of it.
>> > Leon wrote:
>> > > They are supplying free libraries for all the usual peripheral
>> > > functions. Doing stuff like that in software is much cheaper than
>> > > using hardware, and easier in many ways.
>> >
>> > Been there, done that, and it's not cheaper or easier when you
>> > consider the overall system cost impact, not just the "benefit" of
>> > leaving out the hardware block. &#4294967295;That was the path Scenix/Ubicom went
>> > down, calling it "virtual peripherals", and it was not very
>> > successful. &#4294967295;Ubicom has since added hardware for Ethernet, USB,
>> > etc. to their most recent parts. &#4294967295;The reality is that a hardware
>> > Ethernet MAC costs less than the total system cost impact of the
>> > software alternative.
>> >
>> > Eric
>> 
>> Not if you have four 400 MIPS cores on the chip, each with 64 bits of
>> I/O, 64k of RAM, with 3.2 Gbit/s comms links between cores and 32
>> threads per core, with switching between threads in one clock. If the
>> software is free, it is a very cost-effective solution, especially as
>> the chips will be very cheap.
>
>The PC market solution to determinisity -
>
>	"If in doubt put bigger processor(s) and 
>	 lots more memory to solve the 'problem'"
>
>Having seen how easily screwed even software UARTs can get, and
>when something goes wrong all other activity is screwed.
>
>The PC example is dodgy CD inserted, nothing else can work until
>the upto 30 seconds of lockout. Lots of other examples exist.
>
>This sort of software emulation of hardware ONLY is useful for
>cheap and nasty commodity products that assume that unusability
>is always solved by a reset (for some products that means host PC
>AS WELL!).
>
>This means for the VAST majority of *my* applications it is useless.

I fully agree with this. Software is flexible and easier to correct
than hardware. Unfortunantely this has lead to the current thinking
that we can ship the product with known issues, since "We can always
fix it later". In most cases these fixes never happen. I would prefer
more peripherals in hardware, not less. TCP/IP stack in hardware, USB
stack in hardware etc. Something like IEEE-1394 is much more reliable
than USB, since all the enumeration etc is handled by the hardware. 
With the right hardware support, which can be a few gates, software
can often be made much simpler, more robust and faster. A simple thing
like an atomic increment or decrement can be quite complex to
implement in software. In hardware it is trivial. In my experience
from porting code written for old hardware, to new hardware.
Calculation tasks are much faster on modern hardware. Moving data
around between buffers, and peripherals is only a little bit faster if
at all. Simple things like hardware that provides the amount of space
available in a FIFO in a register in stead of just a FIFO has space
flag, can easily make the moving of data easily 5x faster. 

Regards
  Anton Erasmus

On 15 Oct, 15:33, in...@rayed.de wrote:
> On 14 Okt., 15:57, Leon <leon...@btinternet.com> wrote:
>
>
>
>
>
> > On 13 Oct, 20:42, Eric Smith <e...@brouhaha.com> wrote:
>
> > > Bob wrote about XMOS:
>
> > > > They seem far too fixated on doing everything in software, things like
> > > > ethernet where there is no point shoveling bytes in software if
> > > > hardware can take care of it.
> > > Leon wrote:
> > > > They are supplying free libraries for all the usual peripheral
> > > > functions. Doing stuff like that in software is much cheaper than
> > > > using hardware, and easier in many ways.
>
> > > Been there, done that, and it's not cheaper or easier when you
> > > consider the overall system cost impact, not just the "benefit" of
> > > leaving out the hardware block. &#4294967295;That was the path Scenix/Ubicom went
> > > down, calling it "virtual peripherals", and it was not very
> > > successful. &#4294967295;Ubicom has since added hardware for Ethernet, USB,
> > > etc. to their most recent parts. &#4294967295;The reality is that a hardware
> > > Ethernet MAC costs less than the total system cost impact of the
> > > software alternative.
>
> > > Eric
>
> > Not if you have four 400 MIPS cores on the chip, each with 64 bits of
> > I/O, 64k of RAM, with 3.2 Gbit/s comms links between cores and 32
> > threads per core, with switching between threads in one clock. If the
> > software is free, it is a very cost-effective solution, especially as
> > the chips will be very cheap.
>
> XMOS found a way to make their chips so cheap, that they can do
> everything cheaper in software than all others in hardware?
> Why don't they sell this revolutionary technology to semiconductor /
> FPGA companies then?
> They just wouldn't tell anyone about it and the same big Market would
> use it without knowing, &#4294967295;but at lower prices.- Hide quoted text -
>
> - Show quoted text -

With chips anticipated to sell for as little as $1 each, and replacing
FPGAs and DSPs in a lot of applications, I expect that the much larger
established companies will be getting worried. XMOS already has
several design wins, although the chips are not yet in full
production.

I've just heard that free samples of the BGA512 chip and the newer
BGA144 chip will soon be available via the XMOS web site. The latter
is in an 11x11 mm package, and is identical to the larger device,
apart from only having the I/O from two cores brought out. It should
be possible to put it on a low-cost 4-layer board, which is something
I'll be doing.

Leon

On 15 Oct, 20:28, Anton Erasmus <nob...@spam.prevent.net> wrote:
> On Tue, 14 Oct 2008 15:32:45 +0100, Paul Carpenter
>
>
>
>
>
> <p...@pcserviceselectronics.co.uk> wrote:
> >In article
> > &#4294967295;<3d4b6f41-b742-405d-87bd-47e2fb75a...@8g2000hse.googlegroups.com>,
> >leon...@btinternet.com says...
> >> On 13 Oct, 20:42, Eric Smith <e...@brouhaha.com> wrote:
> >> > Bob wrote about XMOS:
>
> >> > > They seem far too fixated on doing everything in software, things like
> >> > > ethernet where there is no point shoveling bytes in software if
> >> > > hardware can take care of it.
> >> > Leon wrote:
> >> > > They are supplying free libraries for all the usual peripheral
> >> > > functions. Doing stuff like that in software is much cheaper than
> >> > > using hardware, and easier in many ways.
>
> >> > Been there, done that, and it's not cheaper or easier when you
> >> > consider the overall system cost impact, not just the "benefit" of
> >> > leaving out the hardware block. &#4294967295;That was the path Scenix/Ubicom went
> >> > down, calling it "virtual peripherals", and it was not very
> >> > successful. &#4294967295;Ubicom has since added hardware for Ethernet, USB,
> >> > etc. to their most recent parts. &#4294967295;The reality is that a hardware
> >> > Ethernet MAC costs less than the total system cost impact of the
> >> > software alternative.
>
> >> > Eric
>
> >> Not if you have four 400 MIPS cores on the chip, each with 64 bits of
> >> I/O, 64k of RAM, with 3.2 Gbit/s comms links between cores and 32
> >> threads per core, with switching between threads in one clock. If the
> >> software is free, it is a very cost-effective solution, especially as
> >> the chips will be very cheap.
>
> >The PC market solution to determinisity -
>
> > &#4294967295; &#4294967295;"If in doubt put bigger processor(s) and
> > &#4294967295; &#4294967295; lots more memory to solve the 'problem'"
>
> >Having seen how easily screwed even software UARTs can get, and
> >when something goes wrong all other activity is screwed.
>
> >The PC example is dodgy CD inserted, nothing else can work until
> >the upto 30 seconds of lockout. Lots of other examples exist.
>
> >This sort of software emulation of hardware ONLY is useful for
> >cheap and nasty commodity products that assume that unusability
> >is always solved by a reset (for some products that means host PC
> >AS WELL!).
>
> >This means for the VAST majority of *my* applications it is useless.
>
> I fully agree with this. Software is flexible and easier to correct
> than hardware. Unfortunantely this has lead to the current thinking
> that we can ship the product with known issues, since "We can always
> fix it later". In most cases these fixes never happen. I would prefer
> more peripherals in hardware, not less. TCP/IP stack in hardware, USB
> stack in hardware etc. Something like IEEE-1394 is much more reliable
> than USB, since all the enumeration etc is handled by the hardware.
> With the right hardware support, which can be a few gates, software
> can often be made much simpler, more robust and faster. A simple thing
> like an atomic increment or decrement can be quite complex to
> implement in software. In hardware it is trivial. In my experience
> from porting code written for old hardware, to new hardware.
> Calculation tasks are much faster on modern hardware. Moving data
> around between buffers, and peripherals is only a little bit faster if
> at all. Simple things like hardware that provides the amount of space
> available in a FIFO in a register in stead of just a FIFO has space
> flag, can easily make the moving of data easily 5x faster.
>
> Regards
> &#4294967295; Anton Erasmus- Hide quoted text -
>
> - Show quoted text -

However, XMOS will be supplying fully tested and characterised "plug-
in" software modules, which will get round the problems you mention.
The XC language makes this very straightforward.

Leon

On 16 oct, 06:40, Leon <leon...@btinternet.com> wrote:
> On 15 Oct, 20:28, Anton Erasmus <nob...@spam.prevent.net> wrote:
>
>
>
> > On Tue, 14 Oct 2008 15:32:45 +0100, Paul Carpenter
>
> > <p...@pcserviceselectronics.co.uk> wrote:
> > >In article
> > > &#4294967295;<3d4b6f41-b742-405d-87bd-47e2fb75a...@8g2000hse.googlegroups.com>,
> > >leon...@btinternet.com says...
> > >> On 13 Oct, 20:42, Eric Smith <e...@brouhaha.com> wrote:
> > >> > Bob wrote about XMOS:
>
> > >> > > They seem far too fixated on doing everything in software, things like
> > >> > > ethernet where there is no point shoveling bytes in software if
> > >> > > hardware can take care of it.
> > >> > Leon wrote:
> > >> > > They are supplying free libraries for all the usual peripheral
> > >> > > functions. Doing stuff like that in software is much cheaper than
> > >> > > using hardware, and easier in many ways.
>
> > >> > Been there, done that, and it's not cheaper or easier when you
> > >> > consider the overall system cost impact, not just the "benefit" of
> > >> > leaving out the hardware block. &#4294967295;That was the path Scenix/Ubicom went
> > >> > down, calling it "virtual peripherals", and it was not very
> > >> > successful. &#4294967295;Ubicom has since added hardware for Ethernet, USB,
> > >> > etc. to their most recent parts. &#4294967295;The reality is that a hardware
> > >> > Ethernet MAC costs less than the total system cost impact of the
> > >> > software alternative.
>
> > >> > Eric
>
> > >> Not if you have four 400 MIPS cores on the chip, each with 64 bits of
> > >> I/O, 64k of RAM, with 3.2 Gbit/s comms links between cores and 32
> > >> threads per core, with switching between threads in one clock. If the
> > >> software is free, it is a very cost-effective solution, especially as
> > >> the chips will be very cheap.
>
> > >The PC market solution to determinisity -
>
> > > &#4294967295; &#4294967295;"If in doubt put bigger processor(s) and
> > > &#4294967295; &#4294967295; lots more memory to solve the 'problem'"
>
> > >Having seen how easily screwed even software UARTs can get, and
> > >when something goes wrong all other activity is screwed.
>
> > >The PC example is dodgy CD inserted, nothing else can work until
> > >the upto 30 seconds of lockout. Lots of other examples exist.
>
> > >This sort of software emulation of hardware ONLY is useful for
> > >cheap and nasty commodity products that assume that unusability
> > >is always solved by a reset (for some products that means host PC
> > >AS WELL!).
>
> > >This means for the VAST majority of *my* applications it is useless.
>
> > I fully agree with this. Software is flexible and easier to correct
> > than hardware. Unfortunantely this has lead to the current thinking
> > that we can ship the product with known issues, since "We can always
> > fix it later". In most cases these fixes never happen. I would prefer
> > more peripherals in hardware, not less. TCP/IP stack in hardware, USB
> > stack in hardware etc. Something like IEEE-1394 is much more reliable
> > than USB, since all the enumeration etc is handled by the hardware.
> > With the right hardware support, which can be a few gates, software
> > can often be made much simpler, more robust and faster. A simple thing
> > like an atomic increment or decrement can be quite complex to
> > implement in software. In hardware it is trivial. In my experience
> > from porting code written for old hardware, to new hardware.
> > Calculation tasks are much faster on modern hardware. Moving data
> > around between buffers, and peripherals is only a little bit faster if
> > at all. Simple things like hardware that provides the amount of space
> > available in a FIFO in a register in stead of just a FIFO has space
> > flag, can easily make the moving of data easily 5x faster.
>
> > Regards
> > &#4294967295; Anton Erasmus- Hide quoted text -
>
> > - Show quoted text -
>
> However, XMOS will be supplying fully tested and characterised "plug-
> in" software modules, which will get round the problems you mention.
> The XC language makes this very straightforward.
>
> Leon

Seriously, how much are they paying you?

To be fair, the XMOS seems like a promising device, I might consider
using it someday, but it still hasn't been widely tested in real
designs.

How many MACs can it perform? Do you have benchmarks for FFTs, IIR
filtering, FIR Filtering? What if you want to interface it to a DDR-II
SDRAM module?

Best regards

Benjamin