Reply by Albert van der Horst●October 24, 20082008-10-24
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
Reply by Leon●October 16, 20082008-10-16
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
> > > > �<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. �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
>
> > > >> 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- 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
Reply by Benjamin Couillard●October 16, 20082008-10-16
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
> > > �<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. �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
>
> > >> 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- 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
Reply by Leon●October 16, 20082008-10-16
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
> > �<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. �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
>
> >> 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- 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
Reply by Leon●October 16, 20082008-10-16
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. �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
>
> > 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.- 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
Reply by Anton Erasmus●October 15, 20082008-10-15
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. �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
>>
>> 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
Reply by ●October 15, 20082008-10-15
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. �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
>
> 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.
Reply by Leon●October 15, 20082008-10-15
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
Reply by Eric Smith●October 14, 20082008-10-14
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. :-)
Reply by Rich Grise●October 14, 20082008-10-14
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