On 16 Oct, 16:04, Benjamin Couillard <benjamin.couill...@[EMAIL PROTECTED]
>
wrote:
> 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,
thi=
ngs like
> > > >> > > ethernet where there is no point shoveling bytes in software
i=
f
> > > >> > > 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
t=
han
> > > >> > > 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/Ubic=
om 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
hardwa=
re
> > > >> > 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
thin=
g
> > > 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
i=
f
> > > 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?
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 fla****ng 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
|
