On Tue, 14 Oct 2008 15:32:45 +0100, Paul Carpenter
<paul@[EMAIL PROTECTED]
> wrote:
>In article
> <3d4b6f41-b742-405d-87bd-47e2fb75ac1d@[EMAIL PROTECTED]
>,
>leon355@[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. 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 ****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
Anton Erasmus
|
