Temperature tracking scheme for programmable phase-shifter in pulsed Radar SoC

A Programmable Phase Shifter is commonly used in a pulsed Radar SoC for controlling the timing of the transceiver. It creates a Phase-Shift Amount (PSA) proportional to a tuning code. In the heart of this design, a Generic Delay-Locked Loop (Generic DLL) is responsible for creating an arbitrarily specified delay. Even though process variation and VDD variation has been properly considered, the temperature variation is often harder to cope with. In this paper, we present a temperature tracking scheme for this purpose. Simulation results show that, the maximum phase error can be thereby reduced from 96ps at its peak down to only 12ps.

SECTION I. Introduction

In recent years, CMOS-based pulsed Radar system has emerged as a cost-effective scheme for indoor wireless sensing applications [1] [2] [3] [4] [5]. Such a Radar transmits a sequence of short-duration pulses periodically. Once a pulse is transmitted, it listens to any echo (or returned signal) to decide if an object is detected within its target range (e.g., in an $10\text{m}\times 10\text{m}$ indoor environment). The distance of a detected object can be approximated by a timing parameter called Time-of-Arrival (ToA), referring to the timing interval between a pulse is launched and the time when the incoming signal arrives. By tuning the ToA parameter increasingly, a pulsed Radar can scan an area from the Radar site towards the outer region step-by-step.

In general, a pulsed Radar relies on a timing control unit called Programmable Phase Shifter to control its transceiver's operations precisely. This function of the programmable phase shifter depends on two major parameters, as illustrated in Fig. 1:

(1) Operation Period To

This denotes the timing interval between two pulses. For example, in our working example, we use 10MHz as the operation frequency, or 100ns as the operation period, meaning that the RF front-end transmits a short-duration pulse signal in every 100ns period. It is notable that this operation period is also the maximum tunable range of a programmable phase shifter. So, our example has a wide range of tunable range [0ns, 100ns].

(2) Tuning Resolution $\boldsymbol{\delta}_{\mathbf{0}}$

This denotes the minimum tuning unit of time. In our example, we set 10ps as the tuning resolution. Overall, the tunable range is divided into $(100\text{ns})/ 10\text{ps}=10,000$ notches. If we use $\boldsymbol{k}$ to denote the tuning code in [0], [10], [000], then we have the following expression: $$\begin{equation*} \mathbf{Phase}\ \mathbf{Shift}\ \mathbf{Amount} (\mathbf{PSA}) =\boldsymbol{k}^{\ast}10\mathbf{ps} \end{equation*}$$

Where the phase-shift amount (PSA) is equivalent to the Time-of-Arrival (ToA).

Fig. 1:

Our programmable phase shifter produces two clock signals $\{\Phi 1$ and $\Phi 2\}$ with the phases shifted by an amount controllable by a tuning code. The tuning range is [0ns, 100ns] and the tuning resolution is 10ps.

A cell-based “programmable phase-shifter” design has been revealed in [6]. It produced the desired phase-shift amount by a so-called two-stage coarse-fine tuning process [7]. More specifically, it incorporates a Generic DLL to create a desired “fine delay” within [1ns 2ns], when added to a “coarse delay” in [0ns, 99ns] will become a desired phase-shift amount within a wide-range of [Ons, 100ns]. while having a high tuning resolution of 10ps.

It is worth mentioning that a Generic DLL is more complicated than a typical DLL, as a Generic DLL needs to be able to lock to an arbitrary delay, instead of just locking to a clock cycle time of the input clock signal. This creates a major difference in their operation: A typical DLL can operate in a closed loop after locking, by making the phase of the output clock signal in line with the input clock signal constantly, while a Generic DLL may operate in an open loop after locking, because there is no reference it can use to calibrate the output clock signal anymore. This poses a challenge for tracking the process, VDD, and temperature variation in a Generic DLL. Even though it has been demonstrated in [6] that the process and VDD condition can be calibrated on the chip by some calibration circuit before the operation of a General DLL, no scheme has been proposed to address the effect of temperature variation. Study shows that a Generic DLL in [6] could experience a phase error as large as 96ps when the temperature elevates from 25°C to 125°C. In light of this observation, we therefore aim to propose a temperature tracking scheme in this work for a Generic DLL, so that it can be used in our programmable phase-shifter to enhance its robustness under temperature variation.

The rest of this paper is organized as follows. Section II reviews the basic architecture of a programmable phase-shifter. Section III discusses the proposed temperature tracking scheme. Section IV presents experimental results, and Section V concludes.

SECTION II. Preliminaries

A. Overview

A basic programmable phase shifter is composed of three parts, (1) coarse-tuning block, (2) fine-tuning block, and (3) a central controller. The coarse-tuning block is responsible for coarse-delay generation with a tuning resolution of 1ns. On the other hand, fine-tuning block is responsible for fine-delay generation of a tuning resolution of 10ps and a tunable range of [1ns, 2ns] under a “fine-code”. The central controller transmits control signals, regulating the locking and operational flow of entire circuit. Fig. 2 shows the major IOs and internal signals:

• $\Phi_{\text{ref}}$: A 100MHz input reference clock signal.

• $\text{coarse}{\_}{\text{code}}[6:0]$: A 7-bit coarse-tuning code, for controlling the coarse-delay.

• $\Phi_{\text{coarse}}$: The clock signal produced by the coarse-tuning block. This signal has a desired coarse-delay in reference to the input reference clock.

• $\text{fine}{\_}\text{code}[7:0]$: A 8-bit fine-tuning code.

• $\Phi_{\text{new}{\_}{ref}}$ and $\Phi_{\text{shifted}}$: Two 10MHz clock signals produced by our programmable phase shifter. The phase difference between $\Phi_{\text{new}{\_}{\text{ref}}}$ and $\Phi_{\text{shifted}}$ is the phase-shift amount defined by $\text{coarse}{\_}{\text{code}}[6:0]$ and $\text{fine}{\_}{\text{code}}[7:0]$

Fig. 2:

The major signals in our programmable phase shifter.

The two-step phase-shift amount (PSA) can be expressed as: $$\begin{equation*} \mathbf{PSA} =\mathbf{coarse}{\_}{\mathbf{code}}[6:0]^{\ast}1\mathbf{ns}+\text{fine}{\_}{\text{code}}[7:0]^{\ast}10\mathbf{ps} \end{equation*}$$

In other words, the $\text{coarse}{\_}{\text{code}}$ has a weight of 100 times larger than that of the $\text{fine}{\_}{\text{code}}$.

Fig. 3:

Illustration of the timing relationship between $\{\Phi_{\text{new}{\_}{ref}}, \Phi_{\text{coarse}}, \Phi$ shifted $\}$.

As illustrated by the waveforms in Fig. 3, the rising edge of $\Phi_{\text{shifted}}$ now arrives later that of $\Phi_{\text{new}{\_}\text{ref}}$ by an amount of $(\text{coarse}{\_}{\text{delay}}+\text{fine}{\_}{\text{delay}})$.

B. Architecture, Circuit, and Operation

The operation of the coarse-tuning block is relatively PVT-invariant, and thus omitted. Next, we will focus more on how to make the fine-tuning block PVT-invariant.

Fig. 4:

Micro-architecture of our programmable phase shifter.

The micro-architecture of the fine-tuning block is shown in Fig. 4. It can be divided into the following four components - (1) a Generic Delay-Locked Loop (DLL), which will lock to a desired fine-delay after a delay calibration process during a delay locking process, (2) a cell-based All-Digital Phase Locked Loop (ADPLL) (named ADPLL-2) [8], which will be used to create the calibration clock signals, $\Phi_{\text{calibrate}}$, to assist the locking process of the above Generic DLL, (3) a supplementary frequency divider (called $\mathbf{Div}{\_}{\mathbf{N}}$) for assisting the ADPLL-2 to generate the above calibration clock signals $\Phi_{\text{calibrate}}$, and (4) two tri-state buffers forming a multiplexer at the input of the DLL. With this tri-state buffer based MUX, DLL is driven by the calibration clock signals, i.e., $\Phi_{\text{calibrate}}$, in the calibration mode, and by the output signal of the coarse-tuning block, i.e., $\Phi_{\text{coarse}}$, in the normal operational mode.

Conceptually, these components jointly take $\Phi_{\text{coarse}}$ as the input and delay it by an amount of “fine_delay” to produce another 10MHz clock signal, called $\Phi_{\text{shifted}}$ in the normal operation mode.

SECTION III. Temperature Tracking Scheme

A. Delay Calibration of the Generic DLL

To make a generic DLL locking to an arbitrarily specified delay value, e.g., 1.32ns we use ADPLL-2 to produce a clock signal with a period of 1.32ns to drive the DLL in our design in a so-called calibration stage. Then the DLL goes through a typical locking process. After the DLL is locked, its Tunable Delay Element (TDE) in the DLL will have exactly 1.32ns as desired, and then we can continue to switch the input signal of the DLL to the normal 10MHz input clock signal, i.e., $\Phi_{\text{coarse}}$, and the operation for our pulsed Radar SoC can be started. However, the calibrated delay across the TDE in the DLL, even though accurate in the beginning, could fluctuate with the temperature variation. Since the DLL is now operated in an open loop, there is no knowing about that unless some other scheme is introduced as discussed below.

B. Temperature Tracking

We modify the Generic DLL as shown in Fig. 5 to assist the temperature tracking process. The goal is to keep the delay across the TDE in the DLL invariant regardless of the temperature.

Fig. 5:

A generic DLL with temperature-tracking ability.

Major IO signals in this block diagram include:

• $\text{DLL}{\_}\text{in}$: A 10MHz clock coming out of the coarse-tuning block as the input to this Generic DLL.

• $\Phi_{\text{shifted}}$: Final output of the Generic DLL.

• $\Phi_{\text{fast}}$: A high-speed 1GHz clock signal previously generated elsewhere. It is mainly used for “training pulse generation” as will be detailed later.

This modified Generic DLL can be divided into the following portions:

1. A basic DLL: which includes a TDE implemented by the architecture proposed in [9], a Phase-Detector (PD), and a controlling for DLL locking operation.

2. A TDE-delay quantifying circuit: which includes only an inverter and an AND gate. It converts the TDE-delay into a pulse-width in a signal called ‘PW’. We will frequently mention this signal later.

3. A Time-to-Digital Converter (TDC): which is implemented by only standard cells following the guidelines proposed in [10]. This TDC converts the pulse-width in its incoming signal into a 9-bit digital code, denoted as TDC_code[8:0].

4. A training clock signals generator: which consists of two counter-based frequency dividers, namely ‘Divider-1’ and ‘Divider-2’. Two training signals are thereby generated, including ‘Clock_PW_1ns' and ‘Clock_PW_1ns'. As their names suggest, the pulse-width of ‘Clock_PW_1ns' is 1ns, and the pulse-width ‘ ’_2ns' is 2ns.

5. A temperature-tracking controller: which regulates the “control-code” ${}^{\prime\prime}$ of the TDE during the normal operation. In the above figure, the control code of the TDE is denoted as $\gamma[10:0]$.

Next, we describe the temperature-tracking operation. We have established one auxiliary feedback path in the new architecture: $$\begin{gather*} \mathbf{TDE}-\mathbf{delay}\ \mathbf{quantifying}\ \mathbf{signal} ({}^{\prime}PW{}^{\prime})\rightarrow \mathbf{TDC}\rightarrow\\ \mathbf{Controller}\rightarrow {}^{\prime}\mathbf{fine}-\mathbf{code}^{\prime}\ \mathbf{of}\ \mathbf{the}\ \mathbf{TDE} \end{gather*}$$

Whenever the General DLL starts its normal operation, we can intermittently perform a so-called “delay re-calibration” procedure, non-intrusively in the background. For every re-calibration interval (e.g., 1μs), this procedure fine-tune the “fine-code” of the TDE through the above auxiliary feedback path so that the TDE-delay stays close to its desired value regardless of the temperature. It is notable that since the delay re-calibration performs only very slight adjustments in the “fine-code” of the TDE, so it will not disrupt the General DLL's normal operation.

However, the above principle may have a pitfall: We have assumed that a Time-Digital Converter itself is PVT-invariant. But in reality, it is not. So, how can we make a TDC immune to the PVT variation is another sub-topic we need to revolve first before we can legitimize the above temperature tracking scheme. The above discussions can be now consolidated as a temperature-tracking flow depicted in Fig. 6.

Fig. 6:

Temperature-tracking flow.

After the DLL is locked, we record the pulse-width at signal ${}^{\prime}PW{}^{\prime}$ as ${}^{\prime}PW_{\text{target}}{}^{\prime}$. Note that we wish to main this property throughout the entire DLL operation cycle until it was re-locked to another delay value. Then, the DLL is in its normal operation. At the end of every delay re-calibration interval, we perform two steps: (1) We re-calibrate the TDC, and producing its latest “transfer curve” at the current temperature, and (2) We re-adjust TDE in the DLL by incrementing or decrementing the value of $\gamma[10:0]$, until the resulting pulse-width at signal ‘PW’ is within an tolerable error range of ${}^{\prime}PW_{\text{target}}{}^{\prime}$.

It is worth mentioning that in the above delay re-calibration, the value of $\gamma[10:0]$ needs to be either incremented or decremented, based on an interpolation process as illustrated in the following example.

Fig. 7:

An interpolation process that maps a TDC output code, e.g., $y$, to its corresponding pulse-width at the input, e.g., pw_y.

Example 1

As mentioned previously, we use two training clock signals, i.e., 'Clock_PW_Ins' and 'Clock_PW_2ns' to characterize the transfer curve of the TDC at a particular moment. Since the transfer curve of TDC is quite linear, we can perform linear interpolation to map a derived 9-bit TDC code back to its corresponding pulse-width at its input, as illustrated below in Fig. 7. In this example, a TDC output code, e.g.,y, has been mapped to its corresponding pulse-width, e.g., pw_y

SECTION IV. Experimental Results

We have implemented a programmable phase shifter with the proposed temperature tracking scheme using a 90nm CMOS process. Fig. 8 shows the layout. The core area is 570 $(\mu \text{m})\times 560(\mu \text{m})=0.3192\mu \text{m}^{2}$. The power consumption with a supply voltage of 1V is 23.3 mV.

Fig. 8:

The layout of the entire programmable phase shifter.

Fig. 9:

Simulated phase-shift amount versus control code.

Fig. 10:

The phase error.

Fig. 8 shows the simulated Phase-Shift Amounts under various control codes for 400 selected sample points. Fig. 9 shows the phase errors with and without temperature tracking. Since it is not easy to change the temperature settings in our simulation environment dynamically, we convert the temperature effect (e.g., 25°C to 125°C in 300µs) into its equivalent VDD drop effect (e.g., IV to 0.94V in 300µs). The phase error range without the temperature tracking scheme is originally [1ps, 96ps], while reduced to [-7ps, 22ps] when the delay re-calibration interval is $5\mu \text{s}$, and further down to [-7ps, 12ps] when the delay re-calibration interval is $1\mu \text{s}$.

SECTION V. Conclusion

In this work, we have presented a temperature-tracking scheme for a programmable phase shifter (required in a pulsed Radar SoC). It is composed of only standard cells. The key contribution is to make a Generic DLL immune to PVT variation. We have demonstrated that this can be done by an auxiliary feedback path which can provide intermittent non-intrusive delay re-recalibration to ensure that the delay across the DLL conforms to its designated value even when the temperature varies largely. Simulation has demonstrated that the maximum phase error can be reduced from 96ps down to only 12ps.