XMOS XC-1 kits are shipping

On 16 Oct, 16:04, Benjamin Couillard <benjamin.couill...@gmail.com>
wrote:
> 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?

Nothing! I just like the devices.

>
> 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?

I'm still at the flashing LED stage. I'll ask those questions at the
seminar next week. It can do a MAC in one cycle and it has all the
usual DSP stuff in the instruction set but I'm not sure how they are
accessed via the compilers.

I'll be adding a header to my board tomorrow, so that I can interface
my own hardware to it easily.

Leon

In article <29f6f706-9a1a-4a31-b7df-bca8733765d7@p10g2000prf.googlegroups.com>,
 <steveu@coppice.org> wrote:
 <SNIP>
>
>Going to market with an impractical product is much worse than toying
>and figuring out its impractical before you spend the big bucks. I
>remember when the Inmos people kept trying to sell their filter chip
>into a board I was doing. The board's BOM target was about 130 pounds
>(more or less met in the end), while their chip in 100k volume was
>something like 800 pounds. I guess the salesman had few other leads to
>follow if he kept wasting his time on us.

What is "impractical" about the first device to manage doing the first
quantum chromatic calculation?
What was "impractical" about the interactive graphical displays of oil
wells on the Meico's at Shell Rijswijk?
(Hint, the alternative at the time was tying up Shell's Cray. The
transputer boxes where an order of magnitude less expensive.)

I don't argue with the lack of commercial prowess though.
If they just had managed to keep up with increasing clock
speeds, instead of going to 9000, they might still be in business.

>
>Regards,
>Steve

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst