It wouldn't be far off the mark to call Google TV as one of the unmitigated disasters of 2010 - 2011. Through the failure of the Logitech Revue, it was responsible for Logitech's below-par performance last year, and also for the stepping down of its CEO. Anand covered Intel's winding down of the Digital Home Group and it could be said that Google TV / Intel's concept of Smart TV not taking off as expected was one of the reasons.

However, Google doesn't give up on its efforts without a fight. With access to the Android market and an upgrade to Honeycomb, Google TV received some life support last October. However, pricing and device power consumption were the two other prime factors which needed to get addressed. The first generation Google TV devices were all based on the Intel's CE4100. Despite being a highly capable platform, it suffered from a number of issues such as high silicon cost (leading to higher priced Google TV units) and unreasonably high power consumption. With Intel's shuttering of the Digital Home Group, it was inevitable that Google and its partners would end up moving to an ARM based platform. Given that ARM has remained the architecture of choice for Android smartphones, this was also a move predicted by many.

We covered Marvell's foray into the DMA (Digital Media Adapter) market with their ARMADA 1000 platform. Today, Marvell is officially launching the next generation ARMADA 1500 (88DE3010) SoC. They also announced their team up with Google and indicated that all the Google TV boxes at the 2012 CES would be powered by Marvell silicon.

The ARMADA 1500 (88DE3100) is the follow up to the ARMADA 1000 (88DE3010) introduced a couple of years back. The 88DE3010 is the same chip which is being used in the Nixeus Fusion XS which started shipping recently. It is also the chip used in some high end (in terms of cost) 3D Blu-ray players like the Kaiboer K860i and the Asus O!Play BD players (BDS-500 and BDS-700).

The ARMADA 1500 (88DE3100) is a media SoC with a dual core PJ4B superscalar host processor. It is targeted towards IP/Cable/Satellite STBs, premium Blu-ray players / DMAs and Google TV applications.

The following block diagram reveals the structure of the 88DE3100 SoC:

We will take a look at the I/Os first:

• A/V Inputs: Just like the CE4100, the Marvell chip also has Transport Stream inputs and support for digital inputs (plain YUV / RGB). The TS inputs are probably not of much use in Google TV applications, but I can definitely see the digital inputs being used in cases where the device needs to have a HDMI input (from a STB output) for blending / overlay.
• A/V Outputs: The SoC has a HDMI 1.4 compliant TX PHY with 1080p60 / frame and field interleaved 3D support and 12b Deep Color capability. HD audio bitstreaming and CEC support are also available. along with various combinations of component / composite / S-Video and digital audio outputs.
• Memory Interface: 32-bit DDR3 DRAM running at 800 MHz provides for 61.2 Gbps of maximum theoretical bandwidth. Up to 1 GB of DRAM is supported.
• NAND Controller: This is a 8 bit interface running at 50 MHz compliant with ONFI 1.0 specifications. Up to 2 GB of NAND Flash is supported.
• Peripherals: SATA3, USB 2.0 Host, USB 2.0 Slave, SD3.0 controller, Two Fast Ethernet (100 Mbps) ports and other miscellaneous peripherals round up the SoC features.

Marvell's PJ4B

The PJ4B CPU core was first sampled by Marvell in October 2010. It is supposed to be compatible with Cortex-A9 and delivers similar instruction throughput per cycle. Being a custom designed architecture, it has the capability to clock at a higher rate compared to off-the-shelf Cortex-A9s. While ARM estimates that the Cortex-A9 can provide around 2.5 DMIPS/MHz/Core, Marvell claims that the PJ4B can provide up to 2.61 DMIPS/MHz/Core (take this for what it is worth).

Each PJ45B core in the 88DE3100 is supported by a 4-way 32KB I-Cache and a 8-way 32KB D-Cache. There is a common 512KB coherent L2 cache.

Unlike the previous members of the ARMADA lineup which didn't have NEON support, the 88DE3100 supports both NEON VFPU and Intel WMMX. The cores are clocked at 1.2 GHz, delivering up to 6000 DMIPS of performance. This sort of performance enables the 88DE3100 to support Flash enabled web browsers and other such key areas necessary for Google TV to shine

vMeta Engine

The vMeta video decoder supports more formats than I have ever seen on any media processing chip (Sigma and Realtek included!). The 88DE3100 provides for dual stream decode acceleration of

• H.264 High Profile @ Level 4.1, 4.2 and 5; Multiple View Coding
• VC-1 Advanced profile @ level 3, WMV9 MP@HL
• MPEG-2 MP@HL, MP@ML
• MPEG4 SP@L3, ASP@L5, DIVX-HD
• AVS 6.2
• VP6/8 SD and HD
• RV9/10 (RMVB up to 1080p)
• Low Delay Mode (progressive refresh) support for H.264 Baseline profile

The vMeta engine also supports JPEG/PNG/GIF/TIFF/BMP/Animated GIF decoding acceleration up to 50MP/s. A number of containers are also specified as being supported officially, but that is usually a matter of firmware.

Qdeo Post Processing

The Qdeo post processing engine performs per-pixel 3D noise reduction, 3D de-interlacing, scaling, natural depth expansion, intelligent color remapping and adaptive contrast enhancement. I am quite sure this would compare favorably with whatever Sigma Designs has up its sleeve in the VXP post processing engine in the SMP8910.

Vivante's GC1000

One of the complaints I had about the 88DE3010 (ARMADA 1000) was the absence of a 3D graphics engine. The 88DE3100 takes care of that by including the GC1000 GPU from Vivante. The GPU supports OpenGL-ES 1.1 / 2.0, something necessary for XBMC to run on the chip. The GPU itself clocks at 750 MHz (with a maximum theoretical DRAM bandwidth of 3.2 Gbps), providing for 375M vertex/S and 750M pixel/S vertex and texture rates. A separate 3D drawing and stretch BLT engine (400M pixel/S fill rate) is used in cases where the 3D engine is an overkill.

The Audio DSP is a 500 MHz superscalar processor capable of executing 4 instructions per cycle. and is complemented by a 800 MHz audio post processing engine. This allows for simultaneous decoding, post processing and downmixing of audio channels. A 500 MHz security processor takes care of multiple cryptography functions to keep the DRM believing folks happy.

Power Consumption

The SoC itself is specified to have a maximum power consumption of 5.3W, with a recommendation to budget for up to 6.5W TDP based on system design. With this power profile, it is indeed possible to have fanless operation with a passive cooling solution.


 

Coming back to the software platform, it is worthwhile to pause and try to see where Google TV is headed. To most reviewers, Google appeared to have bitten off more than it could chew in the first iteration of Google TV. In trying to be a jack of all trades (DVR support, HDMI passthrough, keyboard in front of the TV etc.), it ended up being a master of none of the purposes it aimed to serve.

I have two Android based media streamers running at home right now, the TViX Xroid A1 from Minevox and the Nixeus Fusion XS. I love how the Android features blend seamlessly with the media streamer experience in both the units. The reason Android works for me in both the units is that the gadget has some specific purpose, and it fulfils that purpose first (play local media) before letting the Android features take over. Unfortunately, the Google TV devices out there right now don't get local media streaming right and the online media streaming aspects are better in devices such as the WDTV Live SMP / Rokus. So, there is no incentive for the consumer out there to invest in a box which doesn't get anything right.

It is time for Google TV to start afresh. Pulling away from a PC-like model and trying to resist the temptation to make people spend time (searching) online will be a good first step. If Google keeps trying to make their device act as a bridge between the existing STB infrastructure and the display, it would just mean that the lessons have not been learnt. Google TV should just provide the users a low powered media streamer device with the perfect hybrid of OTT services and local media playback capability. Moving on to DVR capabilities and STB interfacing without getting that right is a waste of effort. In this context, the shift to an ARM based platform is a good choice.

How suitable is the Marvell platform? Going the ARM route is perfectly reasonable. I am more worried about Marvell's track record in this market. I have hesitated in going forward with the Fusion XS review because the firmware is not yet stable or ready for prime time. One may point to Nixeus being at fault for this, but the Kaiboer K860i isn't receiving any glowing reviews either.

Given the similar SoC architecture, I expect a lot of SDK features / code base to be shared between them. Hopefully, the SDK given to the Google TV device manufacturers is up to the mark and gets the necessary features right.

In summary, both Google and Marvell seem to be starting off on the wrong foot in this venture. Given the situation, we hope to be pleasantly surprised when checking out the Google TV devices in action at CES next week.