CPU load

I think what you'll find is alot of the cpu considerations depend on
how quick you need a response.  For example you can run a USB2.0 stack
on a 8bit PIC processor, but just don't hammer it with data at the full
USB2.0 rate.

I'm using a pentium-class 300mhz processor in a embedded pc/104 board.
We do not use the usb funtionality of the board, but it does have 2
usb2.0 connectors, we are using the tcp/ip stack very extensively,
along with a busy serial port...we have had no problems at all.

I don't know if you would need a 300Mhz pentium-class processor to do
what you want to, but unless power consumption is a big issue, I would
rather have more power than less.

Good Luck...
Mark Brodis

Mark,

yes, at the moment, I need good luck, thanks...
I know, that crucial for the CPU will be, what applications we will set
untop of the stacks.
Problem is, this is even also not clear at the moment.
We are going to build a SoC for CE in the US, a hybrid analog digital TV
system ready for the cable market.Completely new market for us.
At leas we will have a 400Mhz system master CPU, where we do not know,
whether required applications will execute in a users satisfying manner.
We guess, the 400Mhz won't be enough, but to we do not know.  We are
thinking about a multi-core system, but have to convince the HW guys.
Here the problems start. I have to investigate in all planned modules, to
find an estimation about needed MIPS.
I hoped, there might by some infomation out, about minimum MIPS requirements
for the mentioned stacks.
In addition, this is my first major project to plan and I'm not sure how to
start...and so much questions:

Performance needed for :

USB
TCP/IP
1394
LinuxOS
Web browsing appl.
Digital video recorder
MHP/OCAP applications
Electronic programming guide
JPEG viewer
MPEG-2 decoder
MP-3 player
WMA and so on

Any idea how to come to reasonable numbers?

Joe

Sometimes it isn't just a case of simply adding the MIPS required for each
component. If more than one item has a time-critical component then you
have to check that the system can cope if one is using the CPU when the
other needs servicing. This can break a system even if your CPU is doing
almost nothing for the next 10ms or so once it's processed the events.

Yes, your are certainly correct.
But starting from scratch with planning the SoC, some estimations have to be
done to at least know in what direction we have to go.
Is a 8-bit µC enough or do we expect a multi processor architecture to
fulfil the requirements ?
I think I have to decide to use the 2nd one, but then I need some numbers to
convince the HW guys.

Having double the CPU that a bottom up estimate suggests plus choosing a
CPU family where you can easily change to a more powerful CPU every 9-18
months would be a good business plan.

If you are successful, then you will have to add more features to stay
in the market.

I would be very carefully to allow for RAM expansion, as well.

These are both business decisions that your marketing organization
should be involved in.  They can make it easy for your hardware team to
give you extra bandwidth and memory by rationalizing cost options
against time to market and feature issues.

Having to hand optimize code is time consuming, and first to market gets
80% of the total business.  That extra market share  pays for several
higher capability CPU and I/O chips.

The conundrum of having competing functions with latency and throughput
requirements is made worse by having a time sharing scheduler like the
one provided by Linux.  You may find it hard to enforce design decisions
about allocating computing resources under the standard Linux scheduler.

The two approaches to dealing with this are to go to a multi-cpu design,
or to go to a scheduler that lets you enforce policy.

If you want to stick with Linux then a real time Linux implementation
will allow you to set policy decisions by dividing your work into time
critical and non-critical elements, then further prioritizing among the
time critical elements.

RTLinux, which I am familiar with, runs Linux as its low priority task,
and allows for either priority preemptive schedulers or fixed time slot
scheduling for the time critical tasks while still running standard
Linux applications and services.

Firewire is well supported as real time task, and has an efficient
controller and design to support this.

USB2.0 controllers resemble the Firewire controllers and could also be
efficiently implemented although Firewire is more sophisticated in
hardware bandwidth allocation.

TCP/IP is not likely to be a CPU hog unless you are having to deal with
a badly behaving network. Having to handle packet fragmentation is the
worst CPU load, followed by handling lost packets and adjusting data
rate to minimize data loss , etc.

If you control the network, I would consider using a different IP
protocol like UDP that does not spend a lot of time dealing with bad
network behavior, but if you are on the internet you don't get to decide.

In that case, get a smarter ethernet chip or board and let it offload
some of the work from the CPU.

The comment earlier in this thread about competition for resources was
dead on target.

You are probably not CPU bound unless you are running a lot of software
calculations like decompression / compression of video, as the
interfaces you discuss can be set up to do intelligent data transfers
without generating a lot of interrupts per byte.

You could instead be I/O bound, particularly if all the interfaces you
mention could be active at once.  Memory interface speed is the killer
here in a single CPU, single memory architecture with multiple I/O
channels simultaneously running.  Going to a second CPU with a separate
memory bus or increasing memory bus speed both address this issue.


The tasks you describe so far are probably not well suited for an 8 bit
controller nor for a 64 bit one.  I would think mainstream processors
well supported by Linux such as X86 or Power architecture ( maybe ARM
architecture  if power is a constraint).

Highly integrated System on a Chip solutions are risky until you know
your I/O and throughput requirements, as those designs all make a number
of compromises to fit everything on a single chip.

They often share hardware resources such as their memory interface and
may even share a single interrupt request line. Chips like the Geode and
the ZF86 come to mind here.

Before compromising, you should find out what is critical to your
application area.

My advice would be to pick a well supported, off the shelf embedded CPU
board to prototype software on while your hardware team works on their
design and buy or borrow at least two of the target boards, then to
attempt some performance measurements using Linux / RTLinux.

Get an evaluation copy of an embedded (probably real time embedded)  OS
already validated for that board, and run some of the standard
benchmarks.  Then try to adapt them or extend them to reflect your end
environment. By using off the shelf hardware and software, you will
learn a lot before your hardware team is very far along.

<Commercial blurb starts here here>

The company I work for (FSMLabs)   distributes an evaluation kit that
includes a bootable kernel that is real time aware, a real time
scheduler, libraries, an on line book with examples, benchmarks, and a
regression test suite.  One of our users ran the tests on 14 different
off the shelf CPU boards in 2-3 weeks' time, which gave them a very
extensive baseline.

We can also arrange for X86 based target boards, ARM or XSCALE based
target boards, and Power PC based target boards to be shipped on 30 day
evaluation.

<End Commercial blurb>

You can do paper analysis, and probably should for Raw Order of
Magnitude estimates, but nothing beats performing an actual measurement.

The above is free advice that I once wished I have been given, and is
worth every cent you paid for it.

Let me know if you need help getting some eval software and / or
hardware.  Don't let the Sparkies (EE types) beat you down.

Regards,

Mike Cravens

Opinions are my own, and were not written for direct hire but were
influenced by my experience base.  Neither my employer, wife , minister,
or Golden retriever are responsible or necessarily take seriously
anything I say.

Mike Cravens
snipped-for-privacy@fsmlabs.com
(972) 693-7799