Sunday, April 08, 2012

A 3x9 Gb/s Shared, All-Digital CDR for High-Speed, High-Density I/O

A 3x9 Gb/s Shared, All-Digital CDR for High-Speed, High-Density I/O
This paper appears in:
Solid-State Circuits, IEEE Journal of
Date of Publication: March 2012
Author(s): Loh, M.
California Inst. of Technol. (Caltech), Pasadena, CA, USA
Emami-Neyestanak, A.
Volume: 47, Issue: 3
On Page(s): 641 - 651
Product Type: Journals & Magazines

ABSTRACT

This paper presents a novel all-digital CDR scheme in 90 nm CMOS. Two independently adjustable clock phases are generated from a delay line calibrated to 2 UI. One clock phase is placed in the middle of the eye to recover the data (“data clock”) and the other is swept across the delay line (“search clock”). As the search clock is swept, its samples are compared against the data samples to generate eye information. This information is used to determine the best phase for data recovery. After placing the search clock at this phase, search and data functions are traded between clocks and eye monitoring repeats. By trading functions, infinite delay range is realized using only a calibrated delay line, instead of a PLL or DLL. Since each clock generates its own alignment information, mismatches in clock distribution can be tolerated. The scheme's generalized sampling and retiming architecture is used in an efficient sharing technique that reduces the number of clocks required, saving power and area in high-density interconnect. The shared CDR is implemented using static CMOS logic in a 90 nm bulk process, occupying 0.15 mm2. It operates from 6 to 9 Gb/s, and consumes 2.5 mW/Gb/s of power at 6 Gb/s and 3.8 mW/Gb/s at 9 Gb/s.


Comments:
Very little to dislike in this paper. It might turn out to be as interesting as Staszewski's all-digital PLL work!
The key advantage of an all-digital system is that while it may not be the most "beautiful" (think wine-glass in comparison with an earthenware pot) implementation around, once you've got it right, you can port it to any process with minimal work and be happy and sit on a beach with a pina-colada. (or perhaps, be rendered redundant!)

The CDR described in this paper is mainly for source-synchronous links. Stuff like shipping data from one core in a chip to another core. The frequency difference of the sending clock and the recieving clock is not expected to be huge so as to require very high band-width CDRs. Its for slow stuff.... you have multiple buses from one core to the other and while they are driven by the same PLL, the routing might have decent mismatches and you need a CDR to correct for that so that the Back-end digital does not have a fit closing timings (silly sounding but difficult to do in multi-core chip and processors like the "Cell" processor school kids are going ga-ga about...)

The idea is to take the source clock, run it through a delay chain which does not need to be accurate but generates enough phases with the resolution you require. Now take two clocks. Keep one at the centre of the eye-opening (data-clock) and make the other move about trying to find the most optimum sampling point (search-clock). Once it finds that, make it the data clock and let the first one move about. This does two things
- It calibrates out the mismatch between the two clocks
- If the eye begins to drift away, you can find the optimum sampling point and then INVERT THE CLOCK (this is a half-rate system) to move behind (or ahead) one UI

Interesting....

The rest is all easily figured out. Take the multiple samples, filter them... figure out the point where the search data differs with the sampled data. Do some fancy probability stuff to figure out how many samples you need to take to get the BER you need.
- The "search" data and the "sampled" data are compared in a low-rate manner
- The clock phase updates are made by a control block in a low rate manner
- Though the exact delay of the delay chain is unimportant, we do need to have some control on the delay to control the band-width. Too high and it becomes unstable. Too low and it tracks nothing and BER shoots up.
- While the routing of CLK and CLKZ are done digitally, they need to be carefully done. There is a comment in the paper about this.

Issues:
1. The delay chain will be very susceptible to supply noise. It is not described how that is combated. Combating it would probably not hurt power too much (unless you want to put an LDO to generate the supply) but would definitely cost area. It is unclear from the paper whether sufficient de-cap was put in though the micro-graph does show unnamed areas which could be de-coupling...
2. There are no details about jitter budgets. How much was given to the loop, how much to timing error etc.

Good paper overall. While the authors have been cautious in trying to pitch it for source synchronous interconnects, it might also work for serial link applications with only embedded clock. The band-width of the CDR is very low since the same control block adjusts clocks for many channels. If we speed up the control block and keep one dedicated for each channel, then things would get interesting and a comparison with a DLL based CDR for cable applications would be worth looking at.

Also, it is interesting that an eye-opening search scheme has been used instead of the tradition BB-PD loop. The BB-PD loop, coupled with the delay chain shown here and a digital filter would be very close to an all-digital CDR for plesiochronous links. This present scheme is good for multiple links in a source synchronous clocking scheme.

I have seen a 5Gbps VCO-based CDR which took ~20-30mA. This papers says that it would take something like 12.5mA for the same application without requiring too much analog work and would give something that will be easily portable between processes. It is likely that due to the higher band-width required, the power would go up but it might end up hitting 20-30mA which is still competitive.

Don't remember the comparable area number so cannot compare...

Really...a BB-PD with a delay loop would be an interesting all-digital CDR to compare with the above numbers.

Sunday, March 25, 2012

Low power dual mode transceiver for cm-Range Wireless Interconnects -Review

A Fully Integrated, 291 pJ/bit UWB Dual-Mode Transceiver for cm-Range Wireless Interconnects
Gambini, S.; Crossley, J.; Alon, E.; Rabaey, J.H.;
Berkeley Wireless Res. Center, Berkeley, CA, USA

This paper appears in: Solid-State Circuits, IEEE Journal of
Issue Date : March 2012
Volume : 47 , Issue:3
On page(s): 586 - 598
ISSN : 0018-9200
References Cited: 22
INSPEC Accession Number: 12543295
Digital Object Identifier : 10.1109/JSSC.2011.2177690
Date of Publication : 03 January 2012
Date of Current Version : 21 February 2012
Sponsored by : IEEE Solid-State Circuits Society

ABSTRACT

We present an ultra-wideband transceiver designed for ultra-low-power communication at sub-10 cm range. The transceiver operates at a 5.6 GHz carrier frequency, chosen to minimize path loss when using a 1 cm2 antenna, and can switch its architecture between self-synchronous rectification and low-IF to adapt its power consumption to the channel characteristic in real time. A low-power digital circuit exploits redundancy in the modulation scheme to provide a real-time BER estimate used to close the mode-switching loop. Implemented in 65 nm CMOS, the transceiver consumes 25 μW when transmitting and 245 μW when receiving in low-power mode, plus 45 μW in the clock generator, and only requires an external antenna. Dual-mode operation allows range extension and mitigates interference.



A few comments:
Interesting concept to use spatially the scarce wireless spectrum. This radio is targeted for low power networks which will typically bounce around small bits of data gathered from sensors etc. The idea is to put a temperature sensor bead/tag somewhere and forget about it for 2-3 years. Intermittently, it will wake up, gather data and send a probably 10-bit message to another transceiver in close proximity and through many such "bounces" it will make its way to the central node which will collect all data and collate.

The power dissipation needs to be very low to allow for a transceiver like this to live on a 1cm X 1cm X 0.5cm volume of battery and last for 2-3 years while sending data every ms or so.... Of course, the sensor itself will have its own power-dissipation and that's not taken into account.

Also, the antenna is a paste-on type with an area of 1cm X 1cm. The targeted range is no more than 5cm. They end up getting 1-2 cm in the low-power mode and in the high-power mode they get 3cm. It might be useful to define a Figure of merit which takes into account the range reached? Without it, 290pJ/bit number doesn't really make sense...

A few criticisms:
  1. It has been argued that we can potentially choose any frequency that gives us a channel response with minimum channel loss. Given that spatial reuse is being targeted, you could argue that you don't care if you step on other radio's shoes. Not very sure about that, even though FC requirements are met.... For example if you have a 802.11n WLAN around, it would'nt be too happy with a temperature sensor around at the same frequency going off at unpredictable intervals....?
  2. Conversely, what about being blocked by the ambient WLAN signal? They have presented some results but no further system analysis has been presented.
  3. How do multiple transceivers communicate with each other? (Probably that's another paper?)
  4. What do you do with a 1-cm range radio?
  5. How do you get frequency control in place without external components? A Tx and an Rx talking at different frequencies are'nt much use...

I liked the way they have gone about discussing the system constraints. A few good items to remember:
  • They have argued that they can use whatever band-width they need. If we accept this, it is quite nice to see, how they have traded off power dissipation ofor band-width. They have used an UWB Tx with a very low duty cycle signaling of data. This allows them to get rid of the high frequency LO which would be expensive power-wise.
  • Also, due to this, they have dumped the RF-PLL and proved in another paper that frequency drift does not matter much if it is limited to below the signal band-width.
  • Now the Tx is going to be a bursty transmitter which will send a 2ns burst every Tb to signal no inversion of signal. If an inversion is to be signaled, the delay becomes either Tb/2 or 3/2.Tb. During the other times, it can be turned off to save power.
  • Due to the coding, we can only have patterns like Tb/2, Tb, ..., Tb, 3Tb/2 or 3Tb/2, Tb, ..., Tb, Tb/2. If we have something like Tb/2, Tb, ..., Tb, Tb/2 or 3Tb/2, Tb, ..., Tb, 3Tb/2, then we know a bit error has happened and this gives us a handy way to figure out the channel quality.
  • The Rx is very interesting. Given the channel and coding chosen, it will be the more power hungry circuit element
  • An I/Q heterodyne Rx is too expensive for the current use, so instead the incoming RF is mixed with an LO which leads to an IF frequency such that2(pi)f_IF.T_p > pi/2. This will ensure that due to the frequency mismatch, there will be a peak sometime in the bit period which will be detected by the base-band. (Is this applicable only to burst-mode signals of this kind???)
  • Normally they use a diode-based envelope detector for signal demodulation, but based on the channel quality, they can go to the mixer based Rx defined in (a) above.
  • The timing recovery is absolutely critical and this is the only circuit that stays on all the time. They have explained the timing recovery somewhat but it requires deeper reading/modeling to give really critical comments here.

Overall, while the idea is good and the RF system work is top-class, one does ask as to whether something like this is really useful and how it will work at the higher system level what with issues of inter-operability, hand-shaking and data generation and use not completely clear.

Key take-aways:
  1. Trade-off band-width for power
  2. Use of effective coding scheme to get an idea of channel state
  3. Use of an interesting demodulation scheme in place of an I/Q heterodyne.

Saturday, March 24, 2012

New find on Internet radio

While working at home I like to keep my internet radio turned on. I typically listen to "Radio Paradise". They have a nice mix of Pop and Rock music that both me and D like.
Discovered this song there yesterday morning. I am completely hooked.


The lyrics are can be found online of course along with the translation, but I copy the English translation here for easy reference (With a hat-tip to http://lyrics.wikia.com)

"Hypocrisy in politics,It’s not good. It’s not good. We don’t want any.
Demagogy in politics,
It’s not good. It’s not good. We don’t want any.
Dictatorship in politics,
It’s not good. It’s not good. We don’t want any.
Happiness, happiness for the people,
Love, love for the people.
It’s not good. It’s not good. We don’t want any.

Corrupt men in politics,
It’s not good. It’s not good. We don’t want any.
Schemers in politics,
It’s not good. It’s not good. We don’t want any.
Dictators in politics,
It’s not good. It’s not good. We don’t want any.
Respect, respect for the people.

Peace, peace for the people
Politics betrays its fathers
Politics betrays its friends
It’s also a machine of war
No pity for its enemies
He’s working for himself while saying that he’s working for us.
He tells us thank you while thinking that he’s the one who did it.

It’s not good. It’s not good. We don’t want any.

Hypocrisy in politics,
It’s not good. It’s not good. We don’t want any.
Demagogy in politics,
It’s not good. It’s not good. We don’t want any.
Dictatorship in politics,
It’s not good. It’s not good. We don’t want any.
Respect, respect for the people.
Peace, peace for the people.
Respect, respect for the people."

Friday, March 23, 2012

What does this mean?

Saw this at Surya's wedding's venue. What does this mean??




Could it be "It is NOT ok to snatch chains off ladies riding pillion on motorbikes. It is OK to stare at them"??



Sunday, March 18, 2012

Snatches of bachelor existence

I had a gala time this week when I traveled to Hyderabad to attend Surya's wedding.

My work is hot. My wife is unwell. I need to be at home to clean-up and help out in the cooking. Indian weddings are a painful, boring experience with your friend whose wedding you are supposedly attending too busy and stressed out to talk to you. You are basically left to your own devices for the duration of your stay. To top it, I have not been home for almost two years now, and if I have to travel, I should have been doing my filial duty and going to Delhi!

I went because Surya is a close friend and because, his wedding is a cue for all my friends in that circle to land-up. It was quite convenient: Thulla and Frusthu were in Bangalore. Skroy was in Hyderabad itself. We have not met as a gang for close to nine years. All of us are married and half of us either have kids or are expecting them.
I had a torrid time getting to Hyderabad. The flight to Chennai was delayed by six hours and the Hyderabad connection was delayed by another four. I finally arrived at Hyd at one in the morning.

It was an awesome experience! Aside from the talking of course, we had three days of total physical abuse: In the three days, I must have slept collectively some twelve hours, drunk at-least 2-3 liters of alcohol in assorted dilution media, finished off half a dozen sticks of tobacco in assorted forms (I don't smoke in my normal life..).

While we all are responsible chaps at work, husbands, parents...we are at heart the same gang which used to sit up late at nights, comment about the female crowd, yak away and then as the sun rose went to give exams which we cleared with varying levels of ease.

Unfortunately, all guys in our gang are married now, so it is difficult to get another occasion to meet again. Probably we will need to invent a wedding now to sell to our wives and kids in order to meet and lead a snatched bachelor existence again...?

Tuesday, February 14, 2012

Is it worth it?

There is something the "Bhagvad Gita" which states something to the effect of, "Work your ass off and forget about the expected rewards".

I have been working too hard for a few months now, chasing a dream. Its not been a pain. It's actually been fun as I enjoy what I do. I enjoy making sense of disparate bits of specifications and give something working first time. I enjoy (after a hard day's work of politicking and alignment meetings) to just take a piece of analog circuitry, make sense out of it and get it to work.

These days though, I have been able to get very little of analog circuit design. It's been mostly emailing, ppt'ing, MS-Word'ing and meeting reservation-ing. It is still fun. It is still nice to make a difference and have people listen to and be influenced by what you are saying. It's nice to feel in a corner of your heart that the project will be seriously hit if you were not around.

So while I have no complaints about what I do, sometimes I do wonder if it all is worth it for various reasons.

While I have been chasing one dream, another one has come to fruition. I have held it dear to me for the last eight years. Held it close to my heart. Wept over it. Tossed and turned at night lying awake, dreaming of it. Today it's mine. Do I feel happy?

Well you can say a bit but I am frankly not over the moon about it. Hell, I have'nt even updated my Linkedin and perhaps have no intention to.

So...is it all worth it?