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

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.

--
Dave
mail da ve@llondel.org (without the space)
http://www.llondel.org/
So many gadgets, so little time...

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

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.

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.

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