PLL jitter and tracking filters
in [Design]
|
Prev: This is funny
Next: One mouse click, 2 PC's
From: Jim Thompson on 16 Jun 2010 11:41 On Wed, 16 Jun 2010 08:15:22 -0700, Tim Wescott <tim(a)seemywebsite.now> wrote: >On 06/15/2010 11:09 PM, crasic wrote: >> Hi all, >> >> I posted this topic over at comp.dsp and they suggested I try you >> guys. >> >> I'm working on a problem that requires a tracking bandpass filter. The >> center frequency is known a priori, but has some drift within the >> range 0.01-0.05 f. A typical frequency would be 700KHz with a >> corresponding 1-2Khz drift and fairly noisy which, after digitizing >> and edge detection, is in the form of frequency jitter, Ideally the >> center frequency should be easily set. The output of the circuit is >> essentially a square wave, with some predetermined (and preferably >> adjustable) pulse width. >> >> The signal drift is fairly small, ~+- 500Hz for the 700KHz signal. >> What we are worried about most is reducing jitter on the resultant >> square wave. We are currently successfully using a sequence of >> amplifiers, an analog (constant) bandpass, and a sine->square >> converter based on some 74XX chips. >> >> Unfortunately this analog circuitry is power hungry, expensive, >> nonconfigurable, and bulky. So we want to (if possible) move >> everything to the digital domain, ideally implemented on some >> programmable logic like an FPGA. >> >> So one idea is to use a purely digital PLL synthesized in an altera >> fpga. We are essentially using something like http://opencores.org/project,dpll_rwf >> but independently designed by me from the same references (not by >> choice, I stumbled on his open source design after the work was done). >> The DPLL design is based on some older IEEE papers (late 70's) and >> uses a binary phase detector and a sequential loop filter (a "Variable >> Reset Random Walk Filter" or "VR-RMF" in dsp jargon) which is >> essentially two up/down counters hooked up in a clever way, >> >> We measured our noise floor with the PLL running in an open loop to be >> approximately ~50uHz at 700KHz and a 160Mhz (10*16) clock (all >> measurements are taken over 1 second. 10 readings are taken and >> averaged). About ten times better than our "ideal" output jitter of >> the running loop. > >This is different from what you reported over at comp.dsp -- you >corrected a problem? > >> As it turns out, the PLL is working too much as an ideal bandpass. On >> a scope you can see a clearly mimicked signal, i.e. it is following >> the input signal with all its jitter and the output jitter of the pll >> matches the input jitter (when measured on a frequency counter). The >> input and output jitter is 3 orders of magnitude above our intrinsic >> jitter of the loop so there is room for improvement. The paper which >> this design is based on (reference 3 on that open cores page) >> experimentally predicts frequency jitter reduction of ~5-10 fold over >> input jitter on a relatively noisy signal. We are getting almost no >> reduction. >> >> Does anyone have any thoughts on this problem with the PLL? > >Its loop gain is too high, leading to a too-high bandwidth. Find the >design element that sets the loop gain and reduce it. > >> Or maybe >> more generally: How would you approach the general problem stated at >> the top? > >Without reading the papers involved, I'm suspicious of your methods. >Digital PLLs are easy things to implement these days, where in the >1970's you would have been severely constrained by the hardware >available. Are you sure you're not doing a whole bunch of work that's >necessary if you're building a circuit from resistor-transistor logic, >but which is a massive waste of gates if you're doing it in an FPGA? > >If your FPGA design isn't easily separable into a phase comparator, a >loop filter, an and NCO, then it's not a good design and working with it >is going to be an ongoing PITA. > >input signal -> phase compare --> loop filter --> counter value --> >loadable down-counter --> output signal. > >(If you need a "real" PLL at all -- think about Vladimir's response. If >you need phase lock then you do need something that's going to be a PLL >when all is said and done, though). Or use a purely analog phase detector since the frequency is well-known with small deviations. I did that in a TACAN application almost half a century ago :-) Remarkable ability to pull a signal out of noise. ...Jim Thompson -- | James E.Thompson, CTO | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona 85048 Skype: Contacts Only | | | Voice:(480)460-2350 Fax: Available upon request | Brass Rat | | E-mail Icon at http://www.analog-innovations.com | 1962 | The only thing bipartisan in this country is hypocrisy
From: Tim Wescott on 16 Jun 2010 12:56 On 06/16/2010 08:41 AM, Jim Thompson wrote: > On Wed, 16 Jun 2010 08:15:22 -0700, Tim Wescott<tim(a)seemywebsite.now> > wrote: > >> On 06/15/2010 11:09 PM, crasic wrote: >>> Hi all, >>> >>> I posted this topic over at comp.dsp and they suggested I try you >>> guys. >>> >>> I'm working on a problem that requires a tracking bandpass filter. The >>> center frequency is known a priori, but has some drift within the >>> range 0.01-0.05 f. A typical frequency would be 700KHz with a >>> corresponding 1-2Khz drift and fairly noisy which, after digitizing >>> and edge detection, is in the form of frequency jitter, Ideally the >>> center frequency should be easily set. The output of the circuit is >>> essentially a square wave, with some predetermined (and preferably >>> adjustable) pulse width. >>> >>> The signal drift is fairly small, ~+- 500Hz for the 700KHz signal. >>> What we are worried about most is reducing jitter on the resultant >>> square wave. We are currently successfully using a sequence of >>> amplifiers, an analog (constant) bandpass, and a sine->square >>> converter based on some 74XX chips. >>> >>> Unfortunately this analog circuitry is power hungry, expensive, >>> nonconfigurable, and bulky. So we want to (if possible) move >>> everything to the digital domain, ideally implemented on some >>> programmable logic like an FPGA. >>> >>> So one idea is to use a purely digital PLL synthesized in an altera >>> fpga. We are essentially using something like http://opencores.org/project,dpll_rwf >>> but independently designed by me from the same references (not by >>> choice, I stumbled on his open source design after the work was done). >>> The DPLL design is based on some older IEEE papers (late 70's) and >>> uses a binary phase detector and a sequential loop filter (a "Variable >>> Reset Random Walk Filter" or "VR-RMF" in dsp jargon) which is >>> essentially two up/down counters hooked up in a clever way, >>> >>> We measured our noise floor with the PLL running in an open loop to be >>> approximately ~50uHz at 700KHz and a 160Mhz (10*16) clock (all >>> measurements are taken over 1 second. 10 readings are taken and >>> averaged). About ten times better than our "ideal" output jitter of >>> the running loop. >> >> This is different from what you reported over at comp.dsp -- you >> corrected a problem? >> >>> As it turns out, the PLL is working too much as an ideal bandpass. On >>> a scope you can see a clearly mimicked signal, i.e. it is following >>> the input signal with all its jitter and the output jitter of the pll >>> matches the input jitter (when measured on a frequency counter). The >>> input and output jitter is 3 orders of magnitude above our intrinsic >>> jitter of the loop so there is room for improvement. The paper which >>> this design is based on (reference 3 on that open cores page) >>> experimentally predicts frequency jitter reduction of ~5-10 fold over >>> input jitter on a relatively noisy signal. We are getting almost no >>> reduction. >>> >>> Does anyone have any thoughts on this problem with the PLL? >> >> Its loop gain is too high, leading to a too-high bandwidth. Find the >> design element that sets the loop gain and reduce it. >> >>> Or maybe >>> more generally: How would you approach the general problem stated at >>> the top? >> >> Without reading the papers involved, I'm suspicious of your methods. >> Digital PLLs are easy things to implement these days, where in the >> 1970's you would have been severely constrained by the hardware >> available. Are you sure you're not doing a whole bunch of work that's >> necessary if you're building a circuit from resistor-transistor logic, >> but which is a massive waste of gates if you're doing it in an FPGA? >> >> If your FPGA design isn't easily separable into a phase comparator, a >> loop filter, an and NCO, then it's not a good design and working with it >> is going to be an ongoing PITA. >> >> input signal -> phase compare --> loop filter --> counter value --> >> loadable down-counter --> output signal. >> >> (If you need a "real" PLL at all -- think about Vladimir's response. If >> you need phase lock then you do need something that's going to be a PLL >> when all is said and done, though). > > Or use a purely analog phase detector since the frequency is > well-known with small deviations. I did that in a TACAN application > almost half a century ago :-) Remarkable ability to pull a signal out > of noise. > > ...Jim Thompson There can be good reasons for using digital in circumstances like this, the OP's cited desire to be as flexible as possible is certainly one of them. But when you're doing stuff like this, your digital circuit is ultimately just a simulation that's running in real time, pretending to be an analog circuit. Sometimes the best thing is to go for the real deal. (All my training was for analog circuit design, with computers as a hobby on the side. Then the radio modem that I built for my Master's thesis absolutely DEMANDED crystal stability in the carrier reference along with wide frequency swings; I could either use up square feet of board space to do it all analog, or I could do it on the poor little slow 8-bit processor that had just been blinking lights on the front panel to implement the modem. The first five years of my professional career were a rear-guard action against doing all these nifty analog jobs in digital. Since then I've acquiesced: analog circuit design is for really little things, really fast things, or for accurately transitioning from the real world to digital and back). -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
From: Jim Thompson on 16 Jun 2010 13:38 On Wed, 16 Jun 2010 09:56:45 -0700, Tim Wescott <tim(a)seemywebsite.now> wrote: >On 06/16/2010 08:41 AM, Jim Thompson wrote: >> On Wed, 16 Jun 2010 08:15:22 -0700, Tim Wescott<tim(a)seemywebsite.now> >> wrote: >> >>> On 06/15/2010 11:09 PM, crasic wrote: >>>> Hi all, >>>> >>>> I posted this topic over at comp.dsp and they suggested I try you >>>> guys. >>>> >>>> I'm working on a problem that requires a tracking bandpass filter. The >>>> center frequency is known a priori, but has some drift within the >>>> range 0.01-0.05 f. A typical frequency would be 700KHz with a >>>> corresponding 1-2Khz drift and fairly noisy which, after digitizing >>>> and edge detection, is in the form of frequency jitter, Ideally the >>>> center frequency should be easily set. The output of the circuit is >>>> essentially a square wave, with some predetermined (and preferably >>>> adjustable) pulse width. >>>> >>>> The signal drift is fairly small, ~+- 500Hz for the 700KHz signal. >>>> What we are worried about most is reducing jitter on the resultant >>>> square wave. We are currently successfully using a sequence of >>>> amplifiers, an analog (constant) bandpass, and a sine->square >>>> converter based on some 74XX chips. >>>> >>>> Unfortunately this analog circuitry is power hungry, expensive, >>>> nonconfigurable, and bulky. So we want to (if possible) move >>>> everything to the digital domain, ideally implemented on some >>>> programmable logic like an FPGA. >>>> >>>> So one idea is to use a purely digital PLL synthesized in an altera >>>> fpga. We are essentially using something like http://opencores.org/project,dpll_rwf >>>> but independently designed by me from the same references (not by >>>> choice, I stumbled on his open source design after the work was done). >>>> The DPLL design is based on some older IEEE papers (late 70's) and >>>> uses a binary phase detector and a sequential loop filter (a "Variable >>>> Reset Random Walk Filter" or "VR-RMF" in dsp jargon) which is >>>> essentially two up/down counters hooked up in a clever way, >>>> >>>> We measured our noise floor with the PLL running in an open loop to be >>>> approximately ~50uHz at 700KHz and a 160Mhz (10*16) clock (all >>>> measurements are taken over 1 second. 10 readings are taken and >>>> averaged). About ten times better than our "ideal" output jitter of >>>> the running loop. >>> >>> This is different from what you reported over at comp.dsp -- you >>> corrected a problem? >>> >>>> As it turns out, the PLL is working too much as an ideal bandpass. On >>>> a scope you can see a clearly mimicked signal, i.e. it is following >>>> the input signal with all its jitter and the output jitter of the pll >>>> matches the input jitter (when measured on a frequency counter). The >>>> input and output jitter is 3 orders of magnitude above our intrinsic >>>> jitter of the loop so there is room for improvement. The paper which >>>> this design is based on (reference 3 on that open cores page) >>>> experimentally predicts frequency jitter reduction of ~5-10 fold over >>>> input jitter on a relatively noisy signal. We are getting almost no >>>> reduction. >>>> >>>> Does anyone have any thoughts on this problem with the PLL? >>> >>> Its loop gain is too high, leading to a too-high bandwidth. Find the >>> design element that sets the loop gain and reduce it. >>> >>>> Or maybe >>>> more generally: How would you approach the general problem stated at >>>> the top? >>> >>> Without reading the papers involved, I'm suspicious of your methods. >>> Digital PLLs are easy things to implement these days, where in the >>> 1970's you would have been severely constrained by the hardware >>> available. Are you sure you're not doing a whole bunch of work that's >>> necessary if you're building a circuit from resistor-transistor logic, >>> but which is a massive waste of gates if you're doing it in an FPGA? >>> >>> If your FPGA design isn't easily separable into a phase comparator, a >>> loop filter, an and NCO, then it's not a good design and working with it >>> is going to be an ongoing PITA. >>> >>> input signal -> phase compare --> loop filter --> counter value --> >>> loadable down-counter --> output signal. >>> >>> (If you need a "real" PLL at all -- think about Vladimir's response. If >>> you need phase lock then you do need something that's going to be a PLL >>> when all is said and done, though). >> >> Or use a purely analog phase detector since the frequency is >> well-known with small deviations. I did that in a TACAN application >> almost half a century ago :-) Remarkable ability to pull a signal out >> of noise. >> >> ...Jim Thompson > >There can be good reasons for using digital in circumstances like this, >the OP's cited desire to be as flexible as possible is certainly one of >them. > >But when you're doing stuff like this, your digital circuit is >ultimately just a simulation that's running in real time, pretending to >be an analog circuit. Sometimes the best thing is to go for the real deal. > >(All my training was for analog circuit design, with computers as a >hobby on the side. Then the radio modem that I built for my Master's >thesis absolutely DEMANDED crystal stability in the carrier reference >along with wide frequency swings; I could either use up square feet of >board space to do it all analog, or I could do it on the poor little >slow 8-bit processor that had just been blinking lights on the front >panel to implement the modem. The first five years of my professional >career were a rear-guard action against doing all these nifty analog >jobs in digital. Since then I've acquiesced: analog circuit design is >for really little things, really fast things, or for accurately >transitioning from the real world to digital and back). Yep. Even MY recent chip designs are largely digital content, with analog peripheries :-) ...Jim Thompson -- | James E.Thompson, CTO | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona 85048 Skype: Contacts Only | | | Voice:(480)460-2350 Fax: Available upon request | Brass Rat | | E-mail Icon at http://www.analog-innovations.com | 1962 | The only thing bipartisan in this country is hypocrisy
From: Tim Wescott on 16 Jun 2010 14:08 On 06/16/2010 10:38 AM, Jim Thompson wrote: > On Wed, 16 Jun 2010 09:56:45 -0700, Tim Wescott<tim(a)seemywebsite.now> > wrote: > >> On 06/16/2010 08:41 AM, Jim Thompson wrote: >>> On Wed, 16 Jun 2010 08:15:22 -0700, Tim Wescott<tim(a)seemywebsite.now> >>> wrote: >>> >>>> On 06/15/2010 11:09 PM, crasic wrote: >>>>> Hi all, >>>>> >>>>> I posted this topic over at comp.dsp and they suggested I try you >>>>> guys. >>>>> >>>>> I'm working on a problem that requires a tracking bandpass filter. The >>>>> center frequency is known a priori, but has some drift within the >>>>> range 0.01-0.05 f. A typical frequency would be 700KHz with a >>>>> corresponding 1-2Khz drift and fairly noisy which, after digitizing >>>>> and edge detection, is in the form of frequency jitter, Ideally the >>>>> center frequency should be easily set. The output of the circuit is >>>>> essentially a square wave, with some predetermined (and preferably >>>>> adjustable) pulse width. >>>>> >>>>> The signal drift is fairly small, ~+- 500Hz for the 700KHz signal. >>>>> What we are worried about most is reducing jitter on the resultant >>>>> square wave. We are currently successfully using a sequence of >>>>> amplifiers, an analog (constant) bandpass, and a sine->square >>>>> converter based on some 74XX chips. >>>>> >>>>> Unfortunately this analog circuitry is power hungry, expensive, >>>>> nonconfigurable, and bulky. So we want to (if possible) move >>>>> everything to the digital domain, ideally implemented on some >>>>> programmable logic like an FPGA. >>>>> >>>>> So one idea is to use a purely digital PLL synthesized in an altera >>>>> fpga. We are essentially using something like http://opencores.org/project,dpll_rwf >>>>> but independently designed by me from the same references (not by >>>>> choice, I stumbled on his open source design after the work was done). >>>>> The DPLL design is based on some older IEEE papers (late 70's) and >>>>> uses a binary phase detector and a sequential loop filter (a "Variable >>>>> Reset Random Walk Filter" or "VR-RMF" in dsp jargon) which is >>>>> essentially two up/down counters hooked up in a clever way, >>>>> >>>>> We measured our noise floor with the PLL running in an open loop to be >>>>> approximately ~50uHz at 700KHz and a 160Mhz (10*16) clock (all >>>>> measurements are taken over 1 second. 10 readings are taken and >>>>> averaged). About ten times better than our "ideal" output jitter of >>>>> the running loop. >>>> >>>> This is different from what you reported over at comp.dsp -- you >>>> corrected a problem? >>>> >>>>> As it turns out, the PLL is working too much as an ideal bandpass. On >>>>> a scope you can see a clearly mimicked signal, i.e. it is following >>>>> the input signal with all its jitter and the output jitter of the pll >>>>> matches the input jitter (when measured on a frequency counter). The >>>>> input and output jitter is 3 orders of magnitude above our intrinsic >>>>> jitter of the loop so there is room for improvement. The paper which >>>>> this design is based on (reference 3 on that open cores page) >>>>> experimentally predicts frequency jitter reduction of ~5-10 fold over >>>>> input jitter on a relatively noisy signal. We are getting almost no >>>>> reduction. >>>>> >>>>> Does anyone have any thoughts on this problem with the PLL? >>>> >>>> Its loop gain is too high, leading to a too-high bandwidth. Find the >>>> design element that sets the loop gain and reduce it. >>>> >>>>> Or maybe >>>>> more generally: How would you approach the general problem stated at >>>>> the top? >>>> >>>> Without reading the papers involved, I'm suspicious of your methods. >>>> Digital PLLs are easy things to implement these days, where in the >>>> 1970's you would have been severely constrained by the hardware >>>> available. Are you sure you're not doing a whole bunch of work that's >>>> necessary if you're building a circuit from resistor-transistor logic, >>>> but which is a massive waste of gates if you're doing it in an FPGA? >>>> >>>> If your FPGA design isn't easily separable into a phase comparator, a >>>> loop filter, an and NCO, then it's not a good design and working with it >>>> is going to be an ongoing PITA. >>>> >>>> input signal -> phase compare --> loop filter --> counter value --> >>>> loadable down-counter --> output signal. >>>> >>>> (If you need a "real" PLL at all -- think about Vladimir's response. If >>>> you need phase lock then you do need something that's going to be a PLL >>>> when all is said and done, though). >>> >>> Or use a purely analog phase detector since the frequency is >>> well-known with small deviations. I did that in a TACAN application >>> almost half a century ago :-) Remarkable ability to pull a signal out >>> of noise. >>> >>> ...Jim Thompson >> >> There can be good reasons for using digital in circumstances like this, >> the OP's cited desire to be as flexible as possible is certainly one of >> them. >> >> But when you're doing stuff like this, your digital circuit is >> ultimately just a simulation that's running in real time, pretending to >> be an analog circuit. Sometimes the best thing is to go for the real deal. >> >> (All my training was for analog circuit design, with computers as a >> hobby on the side. Then the radio modem that I built for my Master's >> thesis absolutely DEMANDED crystal stability in the carrier reference >> along with wide frequency swings; I could either use up square feet of >> board space to do it all analog, or I could do it on the poor little >> slow 8-bit processor that had just been blinking lights on the front >> panel to implement the modem. The first five years of my professional >> career were a rear-guard action against doing all these nifty analog >> jobs in digital. Since then I've acquiesced: analog circuit design is >> for really little things, really fast things, or for accurately >> transitioning from the real world to digital and back). > > Yep. Even MY recent chip designs are largely digital content, with > analog peripheries :-) Where the challenge lies -- and where I see a lot of designs falling short -- is getting the care and feeding of the ADCs and DACs right, while not polluting your sensitive analog circuitry with digital noise. It's easy to forget noise and bandwidth and DC offset and all that nasty analog stuff when you've just stumbled out of 10000 lines of code that define how the signals are processed once they're in the digital world. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
From: Jim Thompson on 16 Jun 2010 14:13
On Wed, 16 Jun 2010 11:08:53 -0700, Tim Wescott <tim(a)seemywebsite.now> wrote: >On 06/16/2010 10:38 AM, Jim Thompson wrote: >> On Wed, 16 Jun 2010 09:56:45 -0700, Tim Wescott<tim(a)seemywebsite.now> >> wrote: >> >>> On 06/16/2010 08:41 AM, Jim Thompson wrote: >>>> On Wed, 16 Jun 2010 08:15:22 -0700, Tim Wescott<tim(a)seemywebsite.now> >>>> wrote: >>>> >>>>> On 06/15/2010 11:09 PM, crasic wrote: >>>>>> Hi all, >>>>>> >>>>>> I posted this topic over at comp.dsp and they suggested I try you >>>>>> guys. >>>>>> >>>>>> I'm working on a problem that requires a tracking bandpass filter. The >>>>>> center frequency is known a priori, but has some drift within the >>>>>> range 0.01-0.05 f. A typical frequency would be 700KHz with a >>>>>> corresponding 1-2Khz drift and fairly noisy which, after digitizing >>>>>> and edge detection, is in the form of frequency jitter, Ideally the >>>>>> center frequency should be easily set. The output of the circuit is >>>>>> essentially a square wave, with some predetermined (and preferably >>>>>> adjustable) pulse width. >>>>>> >>>>>> The signal drift is fairly small, ~+- 500Hz for the 700KHz signal. >>>>>> What we are worried about most is reducing jitter on the resultant >>>>>> square wave. We are currently successfully using a sequence of >>>>>> amplifiers, an analog (constant) bandpass, and a sine->square >>>>>> converter based on some 74XX chips. >>>>>> >>>>>> Unfortunately this analog circuitry is power hungry, expensive, >>>>>> nonconfigurable, and bulky. So we want to (if possible) move >>>>>> everything to the digital domain, ideally implemented on some >>>>>> programmable logic like an FPGA. >>>>>> >>>>>> So one idea is to use a purely digital PLL synthesized in an altera >>>>>> fpga. We are essentially using something like http://opencores.org/project,dpll_rwf >>>>>> but independently designed by me from the same references (not by >>>>>> choice, I stumbled on his open source design after the work was done). >>>>>> The DPLL design is based on some older IEEE papers (late 70's) and >>>>>> uses a binary phase detector and a sequential loop filter (a "Variable >>>>>> Reset Random Walk Filter" or "VR-RMF" in dsp jargon) which is >>>>>> essentially two up/down counters hooked up in a clever way, >>>>>> >>>>>> We measured our noise floor with the PLL running in an open loop to be >>>>>> approximately ~50uHz at 700KHz and a 160Mhz (10*16) clock (all >>>>>> measurements are taken over 1 second. 10 readings are taken and >>>>>> averaged). About ten times better than our "ideal" output jitter of >>>>>> the running loop. >>>>> >>>>> This is different from what you reported over at comp.dsp -- you >>>>> corrected a problem? >>>>> >>>>>> As it turns out, the PLL is working too much as an ideal bandpass. On >>>>>> a scope you can see a clearly mimicked signal, i.e. it is following >>>>>> the input signal with all its jitter and the output jitter of the pll >>>>>> matches the input jitter (when measured on a frequency counter). The >>>>>> input and output jitter is 3 orders of magnitude above our intrinsic >>>>>> jitter of the loop so there is room for improvement. The paper which >>>>>> this design is based on (reference 3 on that open cores page) >>>>>> experimentally predicts frequency jitter reduction of ~5-10 fold over >>>>>> input jitter on a relatively noisy signal. We are getting almost no >>>>>> reduction. >>>>>> >>>>>> Does anyone have any thoughts on this problem with the PLL? >>>>> >>>>> Its loop gain is too high, leading to a too-high bandwidth. Find the >>>>> design element that sets the loop gain and reduce it. >>>>> >>>>>> Or maybe >>>>>> more generally: How would you approach the general problem stated at >>>>>> the top? >>>>> >>>>> Without reading the papers involved, I'm suspicious of your methods. >>>>> Digital PLLs are easy things to implement these days, where in the >>>>> 1970's you would have been severely constrained by the hardware >>>>> available. Are you sure you're not doing a whole bunch of work that's >>>>> necessary if you're building a circuit from resistor-transistor logic, >>>>> but which is a massive waste of gates if you're doing it in an FPGA? >>>>> >>>>> If your FPGA design isn't easily separable into a phase comparator, a >>>>> loop filter, an and NCO, then it's not a good design and working with it >>>>> is going to be an ongoing PITA. >>>>> >>>>> input signal -> phase compare --> loop filter --> counter value --> >>>>> loadable down-counter --> output signal. >>>>> >>>>> (If you need a "real" PLL at all -- think about Vladimir's response. If >>>>> you need phase lock then you do need something that's going to be a PLL >>>>> when all is said and done, though). >>>> >>>> Or use a purely analog phase detector since the frequency is >>>> well-known with small deviations. I did that in a TACAN application >>>> almost half a century ago :-) Remarkable ability to pull a signal out >>>> of noise. >>>> >>>> ...Jim Thompson >>> >>> There can be good reasons for using digital in circumstances like this, >>> the OP's cited desire to be as flexible as possible is certainly one of >>> them. >>> >>> But when you're doing stuff like this, your digital circuit is >>> ultimately just a simulation that's running in real time, pretending to >>> be an analog circuit. Sometimes the best thing is to go for the real deal. >>> >>> (All my training was for analog circuit design, with computers as a >>> hobby on the side. Then the radio modem that I built for my Master's >>> thesis absolutely DEMANDED crystal stability in the carrier reference >>> along with wide frequency swings; I could either use up square feet of >>> board space to do it all analog, or I could do it on the poor little >>> slow 8-bit processor that had just been blinking lights on the front >>> panel to implement the modem. The first five years of my professional >>> career were a rear-guard action against doing all these nifty analog >>> jobs in digital. Since then I've acquiesced: analog circuit design is >>> for really little things, really fast things, or for accurately >>> transitioning from the real world to digital and back). >> >> Yep. Even MY recent chip designs are largely digital content, with >> analog peripheries :-) > >Where the challenge lies -- and where I see a lot of designs falling >short -- is getting the care and feeding of the ADCs and DACs right, >while not polluting your sensitive analog circuitry with digital noise. > >It's easy to forget noise and bandwidth and DC offset and all that nasty >analog stuff when you've just stumbled out of 10000 lines of code that >define how the signals are processed once they're in the digital world. Multiple rails. "Isolation walls" (deep diffusions). Bias distribution via current mirrors such that local references are relative to local rails, etc. ...Jim Thompson -- | James E.Thompson, CTO | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona 85048 Skype: Contacts Only | | | Voice:(480)460-2350 Fax: Available upon request | Brass Rat | | E-mail Icon at http://www.analog-innovations.com | 1962 | The only thing bipartisan in this country is hypocrisy |