---

[This post is taking part in our Designing Hardware for HD series. Be sure to check it out!]

One of the most burning issues involved with designing a video telephony device is where the video codec is going to reside. The reason is that this is by far the most CPU intensive task of the whole system, especially when going up to high definition. I’d like to discuss the various options that exist today on the market, with their relative advantages and challenges.

There is a wide variety of solutions that can accommodate a video codec successfully. At their very basic level, they can be split into software-based and hardware-based solutions.

Solution options for HD video-processing chips

Software-based Solutions

In software-based solutions the video codec is treated as another piece of code that gets compiled and executed on the chip. These solutions can be further divided into single core chips, multi core chips and many core chips.

Single core chips are the simplest to program, but these are hard pressed to meet the demands of HD video processing. The Intel Atom chip, for instance, falls in this category.

Multi-core chips are chips that have a relatively small number of cores )up to 8 today), which are viewed by the operating system as a single unit. The cores execute various tasks of the same program (or multiple programs). Usually, the operating system selects which core will run which of the tasks at hand at any given time. You can find here GPP (General Purpose Processor) chips, such as the Intel Core i7, or DSPs such as the Freescale MSC8144E.

Multi-core chips are considered today hard to program, due to the need to deal with multi-threaded applications. That said, splitting a video codec into multiple threads is a relatively easy task. I’d say that from a programmer’s point of view, using a GPP, or even a DSP would be the easiest solution.

Many core systems will usually run a larger number of cores, up to a hundred today and going to the tens or hundreds of cores in the near future, each running independently of the rest with its own operating system. The Tilera TILE family of processors is a good example.

Many core systems are harder to deal with, as the synchronization mechanisms that exist between cores are a lot harder to program and manage. But, what a many core system lacks in programming it returns ten fold in power usage, with a much lower watt requirement for the same processing task.

Software based video codecs provide a high level of flexibility – since the codec runs as “pure” software, changes to it are relatively easy to make. It comes at a cost – the price for the same processing power will be relatively high.

Hardware-based Solutions

In Hardware-based solutions, the codec is not a single piece of software that is executed on the chip – parts of the codec (or all of it) will run as part of the dedicated hardware circuitry itself. As with software solutions, there is a broad spectrum of options here as well.

Acceleration is a kind of a hybrid solution, where the codec’s processing is divided between software that manages the higher level of logic of the codec and a hardware acceleration unit, which will tend to take on the menial tasks of video processing, such as motion estimation and DCT calculations. The TI DM6467 belongs to this family.

Next in the spectrum are the FPGA-based solutions. In the case of FPGAs (Field-Programmable Gate Array), the solution will come from third parties. This is a good comparison of HD encoders on FPGAs that can be a good starting point for companies who wish to go down this path.

An FPGA chip will be harder to program and will be by far more complex than other solutions. This is why the relevant video codecs come from third parties, who are experienced in such development.

The last family in this category is ASIC solutions, where the chip itself has the video codec hard-wired into its chip. Notable solutions here are Cavium Networks PureVu^TM CNW22XX or Maxim MG3500.

ASIC solutions can be treated as black boxes – they do the job intended – nothing more and nothing less. This comes with a great risk of running into interoperability issues that might require changes in the codec or simply the need to improve the codec, which are quite impossible.

How to Choose?

There are a lot of parameters that you need to consider when choosing your processor:

• Price – easy. If you are price sensitive in your product, then you will need to select a solution that isn’t expensive from both a BOM point of view and a development point of view
• Flexibility – does the chip offer you a way to change the codec? To control it properly? How much time does it take to make such changes? Will you be dependent on a third party for such changes?
• Connectivity – does the chip integrate other functions that you will need? Audio coding, application, GUI, video ports, etc.
• Experience – is your team experienced with such a platform? Will you be able to recruit the team necessary to design and develop the end product easily?
• Design wins – have you seen any design wins of the processor for the target market you are going to? Do you need such guarantees before you start your project?

Decide what is important to you – there might be other aspects not listed here that make sense to you. Check the various alternatives that exist on the market and select the one that fits best.