New Role: Back to C

I have moved from the High Speed Serial Interconnect group to the embedded systems group in my company. This change has been pretty exciting and I am learning a lot. For those who just know me as a semiconductor professional, my job is still the same. I am just working on chips that drive IPODs, Digital Cameras, Keyboards, Mice, Fitness Equipment instead of chips that drive CISCO routers, video servers, etc, which is what I was doing earlier.

I have spent almost 6 weeks on hands on training. So back to C coding, microcontroller design and also some analog design.

On different note, you guys should check out this cool game that I found. It has been pretty addictive.

Measuring crosstalk on High Speed Serial Interfaces

We had a product that had a multiple channels of serial interfaces in the same chip. When we got multiple requests from customers to give them confidence that there is no interference between adjacent channels, specifically when they are simultaneously operating at different frequencies. We had to invent the measurement methodology since there were no specific techiniques to estimate the crosstalk and its impact on serial interfaces. The measurement methodology we came up with is the featured article in Planet Analog today. Thanks to Jeff Hushley for making the measurements and writing the article.  The article can be found at

http://www.planetanalog.com/article/printableArticle.jhtml?articleID=201000007

Back to Blog world

I am back. I have been swamped lately and been unable write blogs. There are a couple of topics I would like to complete first and then get back on track. Stay tuned. 

HDMI: Do we really need a multi-gigabit connection between our TVs and Set-top box?

I work on chips that are used as interconnect chips for broadcast video equipment. The video is transported within the studio environment (example: camera to production truck) in an uncompressed format for obvious reasons, quality & to not spend resources on compression and decompression since it impacts latency, power and consumes time. The interface used by equipment in a studio to handle digital video is called Serial Digital Interface (SDI). The article that Vikas and I wrote on SDI gives a pretty in depth background on fundamentals of studio quality video and goes in-depth on how to build an SDI interface. It also goes into current market dynamics in the studio broadcast world.

Getting back to the point, digital video signals need to maintain a high quality inside a studio. But unfortunately they cannot be transmitted to TV viewers like us at the same bit rate at which they were captured in the studio. Before they get shipped out of the door for broadcast they need to be compressed since the transmission medium connecting to the consumer premises is usually bandwidth limited (can only handle bit rates in the tens of Mbps) . The transmission to consumer premises is usually over-the-air using RF modulation or digital wireline transmission using cable and/or optics. The bandwidth for all these media is extremely limited. With IPTV taking off, broadcast video signals will be delivered to your home through a DSL line or Cable network at a BW of less than 10 Mbps per link.  The signal captured at extremely good quality in the studio (at approxiamtely 1.5Gbps rates for high definition and 270Mbps for standard definition) is compressed to a signal of very low bit-rate (any where from 1 Mbps to 20 Mbps) using either MPEG2 orMPEG4 and delivered to your home. All MPEG schemes are lossy compression schemes, ie, the compression gets rid of redundant information and also reduces amount of information transmitted (bits used) for visually unnoticeable characteristics of the video image. For a given compression scheme, more the amount of compression, poorer the quality of the reconstructed video at the destination. The video getting into your set-top box is usually in the range of ones to tens of Mbps per channel.

HDMI is a high BW connection between a TV peripheral (set-top box, DVD player or XBox) with a fairly expensive cable (cable can cost upto $100 for the seemingly higher quality ones) . HDMI transmits uncompressed/decompressed video from TV media peripherals to the TV. One of the main functions of the set-top box is to decompress (MPEG2 decode) the incoming compressed video and display it on your TV. In new set-top boxes (especially the HDTV ones), the decompressed data from the set-top box is delivered to TV through an optional HDMI connection. Given that lot of new TVs already have MPEG2 decoders built-in (for ATSC decoding) why can’t the set-top box transmit the video to the display in compressed format and let the TV decode the MPEG2 data before display. From a solution standpoint, you would then replace an expensive cable with a cheap cable followed by a piece of silicon device (MPEG2 decoder) which when manufactured in volume would cost way lower than the cost incurred to buy the HDMI cables. This might also remove the need for a stand-alone set-top box, it could just be integrated into the TV by adding a few more chips to the TV board. If the data is delivered compressed through out the video distribution network why is it not carried all the way into the TV set at the reduced bit-rate. If you compare two methods of interconnect, set-top box delivering decoded data at high datarates to the TV and TV decoding the MPEG2 data directly, there would be no difference in the quality of the display. Then why has HDMI been so succesful and created so much buzz? 

I will try to answer this in my next blog. I will also try to provide a few other alternative interconnections that TV and set-top box industry should consider in a subsequent blog (which are not standardized or popular yet but makes logical sense from a cost standpoint).

Use google.com/reader or bloglines.com to manage blog viewing. 

What’s hot today is not tomorrow!

I was reading Gokul’s post on how things that were hot once could get “boring” eventually. This happens very commonly to tech professionals in any industry.

I guess any application, once it hits mainstream market and starts seeing cycles of cost reductions will eventually get commoditized. With so much R&D money invested by big corporations things become standardized and will be perceived as commonplace or perhaps “boring”. This is what happened to PC hardware industryin late 90s, networking gear in 2000s. It happens a lot in semiconductor industry as well. When I entered the semiconductor industry I got the chance to work on High Speed Serial I/O which was considered state of the art during that time. Now Serial I/O IP is available for sale by multiple vendors and it is headed towards the direction of becoming a commodity.

When things get “boring”, I guess you can take two routes: 1. Get into a different field that requires most of your skillset but still is not commoditized and has lot of open challenges; or 2. Move up the value chain in your field/domain so that you are working on where the challenges and fortune lie in your industry. (Examples:  Adding more services on the top of your infrastructure, adding more software features to your existing hardware, adding applications to your solution that are complementary so that you provide a broader portfolio of products, or just sheer improve the horsepower/performance of your current app if there is a market need for it) 

Use google.com/reader or bloglines.com to manage blog viewing.

Should my Tech Blog be separate?

There is my personal side and the way I view things that are happening in the world, which I love writing about and there is also the tech world which I am passionate about from a professional stand-point. I am debatting if I should keep all my tech material confined to a separate blog mainly geared towards my profession. The number of tech blog entries is going to be lesser and the content is going to be much more in-depth just focussing on narrow field. Comments welcome!

My first Tech Blog – Measuring BER for serial links

One of our customers once asked me, how to measure BER for a serial NRZ data communication link with clock and data recovery. It turns out that bit errors are caused due to multiple reasons, mostly random. Moreover, even though one has a way to detect and count the number of errors over a given period of time how can one predict the future BER given the random nature of errors. Given such a scenario how can one reliably measure the BER of a link. The result of the research I did to answer this question was a technical article:

http://www.analogzone.com/nett1003.pdf