XMOS XC-1 kits are shipping

>> There was nothing innovative about the design of the Transputer. The
>> device as it was supposed to be (i.e. separate comms and execution
>> planes), rather than the crippled one they shipped, was similar to
>> designs several people in the UK (and presumably elsewhere) were
>> toying with at that time. The others did not proceed because the
>> economics looked so wrong.
>
>It was used very widely ar the time, because there wasn't anything
>comparable for sale. I even sold several of my modules to hobbyists
>and university students - at =A3500 each!
>
>Some of the customers for my 16 module system were prestigious outfits
>such as BAe, Plessey Roke Manor, GCHQ and Oxford University PRG. It
>delivered 320 MIPS with very good floating-point performance at a
>comparatively low price (about =A313,000 with T800 chips).
>
>I even had inquiries from Russia, indirectly, but it was embargoed
>because of the performance. I did once apply for an export license for
>Russia, to see what happened, and actually got it! I contacted the DTI
>about it; they got very excited, admitted thay had made a mistake and
>insisted that I returned the document. I'm quite sure that Russia did
>get the technology, though. I heard on the grapevine that there were
>companies in Finland that acted as intermediaries.

Selling development boards does not equate to widely used. I saw a number
of experimental machines full of Transputers, engaged in various activities
from finger print analysis to deblurring number plates on getaway cars.
When I say "full" I mean generally no more than 16. Comms overhead killed
performance for serious array. The only real commercial product use I ever
saw was in the FPS Terreract, and it didn't do a lot for them. To make it a
practical element in their machines they needed an ASIC to expand the 4
ports, so a hypercube could be constructed. Then the comms overheads still
killed its ability to do any serious processing. The real processing was
handled by a bunch of Weitek floating point chips, and early video DRAMs.
The DRAMs allowed vectors to be streamed through the floating point units,
using the serial port originally intended for streaming pixels to a
display. By the time they'd finished burying the Transputer amongst that
lot I wonder how much value they thought it brought to the final product? I
the FPS guys I talked to at that time indicated they probably would not
have used the Transputer if they were starting again.

Regards,
Steve

On Oct 10, 2:01 pm, Leon <leon...@btinternet.com> wrote:
> I've just ordered my 1600 MIPS XMOS XC-1 design kit.
>
> The XMOS chips will replace DSPs and FPGAs in a lot of applications.
>
> I haven't been so excited about a new chip since the transputer came
> out. David May designed them both, of course.
>
> Leon
> leon...@btinternet.com

I briefly saw XMOS at a trade show in London.
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.

The quarter VGA touchscreen on the dev kit has novelty value.

I'm not sure the performance justifies the effort of using somthing
so unusual in most cases.

I'd want to make a single lifetime buy of processors if I used
these in a product. Far too likely to dissapear without trace.

Bob

On 13 Oct, 11:14, Bob <b...@mailinator.com> wrote:
> On Oct 10, 2:01 pm, Leon <leon...@btinternet.com> wrote:
>
> > I've just ordered my 1600 MIPS XMOS XC-1 design kit.
>
> > The XMOS chips will replace DSPs and FPGAs in a lot of applications.
>
> > I haven't been so excited about a new chip since the transputer came
> > out. David May designed them both, of course.
>
> > Leon
> > leon...@btinternet.com
>
> I briefly saw XMOS at a trade show in London.
> 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.
>
> The quarter VGA touchscreen on the dev kit has novelty value.
>
> I'm not sure the performance justifies the effort of using somthing
> so unusual in most cases.
>
> I'd want to make a single lifetime buy of processors if I used
> these in a product. Far too likely to dissapear without trace.
>
> Bob

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.

Leon

steveu@coppice.org wrote:
> On Oct 11, 1:43 am, Leon <leon...@btinternet.com> wrote:
>> On 10 Oct, 17:42, ste...@coppice.org wrote:
>>
>>
>>
>>> On Oct 10, 9:01 pm, Leon <leon...@btinternet.com> wrote:
>>>> I've just ordered my 1600 MIPS XMOS XC-1 design kit.
>>>> The XMOS chips will replace DSPs and FPGAs in a lot of applications.
>>>> I haven't been so excited about a new chip since the transputer came
>>>> out. David May designed them both, of course.
>>>> Leon
>>>> leon...@btinternet.com
>>> Is the comparison with the Transputer supposed to imply this is a half
>>> thought out design with brain dead execution? :-\
>>> Steve
>> The transputer was ahead of its time, and really pushed the technology
>> that was available. I sold a lot of systems using it, mostly to
>> universities and research establishments, because there was nothing
>> else around with that sort of performance then. Inmos even had their
>> own fab!
>>
>> Leon
> 
> The Transputer wasn't ahead of its time. It was brain dead. A chip
> only effective in substantial arrays selling for hundreds of pounds
> per device was a dead duck from the start. The only people who could
> seriously look at it for substantial arrays were military
> applications. However, when approached about military parts Transputer
> gave evasive answers.
> 
> There was nothing innovative about the design of the Transputer. The
> device as it was supposed to be (i.e. separate comms and execution
> planes), rather than the crippled one they shipped, was similar to
> designs several people in the UK (and presumably elsewhere) were
> toying with at that time. The others did not proceed because the
> economics looked so wrong.


Toying means nothing in our industry, it's all about rolling out actual 
product. That is what Inmos did. But:

The economics didn't have to look wrong. They were wrong because IMHO a 
cardinal mistake had been made: Entering the market with very high price 
tags. That was bound to fail and cause me to turn away. Same thing 
happened with S/C filter chips.

Next, they should have lined up an early licensing deal with a major 
semiconductor manufacturer, one that engineers trust. This is extremely 
important. Nobody in their right mind would design in a single-source 
part from a tiny manufacturer without a serious business track record. 
My guess is that a few more business-thinkers could have potentially 
saved the bacon at Inmos.

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

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.  That was the path Scenix/Ubicom went
down, calling it "virtual peripherals", and it was not very
successful.  Ubicom has since added hardware for Ethernet, USB,
etc. to their most recent parts.  The reality is that a hardware
Ethernet MAC costs less than the total system cost impact of the
software alternative.

Eric

On Oct 14, 1:31&#4294967295;am, Joerg <notthisjoerg...@removethispacbell.net>
wrote:
> > There was nothing innovative about the design of the Transputer. The
> > device as it was supposed to be (i.e. separate comms and execution
> > planes), rather than the crippled one they shipped, was similar to
> > designs several people in the UK (and presumably elsewhere) were
> > toying with at that time. The others did not proceed because the
> > economics looked so wrong.
>
> Toying means nothing in our industry, it's all about rolling out actual
> product. That is what Inmos did. But:
>
> The economics didn't have to look wrong. They were wrong because IMHO a
> cardinal mistake had been made: Entering the market with very high price
> tags. That was bound to fail and cause me to turn away. Same thing
> happened with S/C filter chips.
>
> Next, they should have lined up an early licensing deal with a major
> semiconductor manufacturer, one that engineers trust. This is extremely
> important. Nobody in their right mind would design in a single-source
> part from a tiny manufacturer without a serious business track record.
> My guess is that a few more business-thinkers could have potentially
> saved the bacon at Inmos.

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.

Regards,
Steve

steveu@coppice.org wrote:
> On Oct 14, 1:31 am, Joerg <notthisjoerg...@removethispacbell.net>
> wrote:
>>> There was nothing innovative about the design of the Transputer. The
>>> device as it was supposed to be (i.e. separate comms and execution
>>> planes), rather than the crippled one they shipped, was similar to
>>> designs several people in the UK (and presumably elsewhere) were
>>> toying with at that time. The others did not proceed because the
>>> economics looked so wrong.
>> Toying means nothing in our industry, it's all about rolling out actual
>> product. That is what Inmos did. But:
>>
>> The economics didn't have to look wrong. They were wrong because IMHO a
>> cardinal mistake had been made: Entering the market with very high price
>> tags. That was bound to fail and cause me to turn away. Same thing
>> happened with S/C filter chips.
>>
>> Next, they should have lined up an early licensing deal with a major
>> semiconductor manufacturer, one that engineers trust. This is extremely
>> important. Nobody in their right mind would design in a single-source
>> part from a tiny manufacturer without a serious business track record.
>> My guess is that a few more business-thinkers could have potentially
>> saved the bacon at Inmos.
> 
> 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.
> 

That's exactly the cardinal mistake I mentioned above. Coming into the 
market with a totally unrealistic price is bound to fail. And it did.

Usually that happens after spending big bucks in NRE, it's all way 
behind schedule and the investors demand a rather quick and unrealistic 
ROI. Seen it many times, failed every single time. You should have seen 
some of the faces here when high-faluting chips were presented and then 
I told them that my discrete solution costs a buck fifty.

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

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.

Leon

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.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

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.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate