On 16 oct, 06:40, Leon <leon...@[EMAIL PROTECTED]
> wrote:
> 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,
thing=
s 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
tha=
n
> > >> > > 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=
went
> > >> > 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
o=
f
> > >> 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
th=
e
> > >> software is free, it is a very cost-effective solution, especially
a=
s
> > >> 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
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
|
