On 15 Oct, 20:28, Anton Erasmus <nob...@[EMAIL PROTECTED]
> wrote:
> On Tue, 14 Oct 2008 15:32:45 +0100, Paul Carpenter
>
>
>
>
>
> <p...@[EMAIL PROTECTED]
> wrote:
> >In article
> > =A0<3d4b6f41-b742-405d-87bd-47e2fb75a...@[EMAIL PROTECTED]
>,
> >leon...@[EMAIL PROTECTED]
says...
> >> On 13 Oct, 20:42, Eric Smith <e...@[EMAIL PROTECTED]
> 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. =A0That was the path Scenix/Ubicom
w=
ent
> >> > down, calling it "virtual peripherals", and it was not very
> >> > successful. =A0Ubicom has since added hardware for Ethernet, USB,
> >> > etc. to their most recent parts. =A0The 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 -
>
> > =A0 =A0"If in doubt put bigger processor(s) and
> > =A0 =A0 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 ****p 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 sup****t, 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 ****ting 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
> =A0 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
|
