[time-nuts] schematics of frequency counter

Bob Camp kb8tq at n1k.org
Mon Jan 5 20:04:34 EST 2015


Hi

> On Jan 5, 2015, at 6:33 PM, Li Ang <lllaaa at gmail.com> wrote:
> 
> Hi Bob,
>  There are 2 oscillator on board, one 8MHz for MCU one 125MHz for FPGA.
> I've took it down from the board, and changed MCU to use internal RC
> oscillator for MCU and PLL to mutilply refclk to 200MHz for FPGA.
>  I will try do the same test tonight thanks.
> 

Most counters use 10 MHz as a reference. A sneaky trick is to use that exact same signal as the MCU clock and as the ref clock input to the FPGA’s PLL. It keeps the spurs all “in step” with each other and helps to line up the timing between the MCU and FPGA data. Because of delays, it’s not a perfect solution to the lineup stuff, unless you play with the timing file. It certainly can help with spurs. 

Bob

> 
> 2014-12-29 4:35 GMT+08:00 Bob Camp <kb8tq at n1k.org>:
> 
>> Hi
>> 
>> 
>>> On Dec 28, 2014, at 9:19 AM, Li Ang <lllaaa at gmail.com> wrote:
>>> 
>>> Hi Bob,
>>>  I did some test according to your suggestions. DUT is a symmetricom x72
>>> rb oscillator. Also, I've tried signal generator as the DUT. R&S SMY01 is
>>> not as good as HP8662A but that the best I've got. The signal geneator is
>>> also using FE5650 as ref clock.
>>> 
>>>  According to my test with the TDC today, this unit is not producing
>> very
>>> stable data.
>>>  I don't have accurate pulse generator, so this is how I test the TDC:
>>> 0) power the board with battery.
>>> 1) use FPGA to generate time pulse:
>>> reg [15:0] shift;
>>> always @(posedge refclk10M) begin
>>> shift <= {shift[14:0], sw_gate};
>>> end
>>> assign tdc_start = shift[3];
>>> assign tdc_stop1 = shift[5];
>>> 
>>> 2) use MCU to pull down sw_gate, the FPGA sync it to refclk10M domain and
>>> generate input signal for TDC.
>>> 
>>> 3) use TDC to test the time betwen tdc_start and tdc_stop1
>>> 
>>> The result is in tdc_test.zip. number * 100ns = time between tdc_start
>> and
>>> tdc_stop1. (TDC highspeed clock is refclk10M/2).
>>> 
>>> There 2 issues from the test:
>>> 1) As we can see from the data, the number is around 1.98x not 2.00x. So
>>> there is about 2ns delay between tdc_start and tdc_stop1 for this simple
>>> test code. If it is from the PCB trace and something inside FPGA, this
>> part
>>> should be a constant value at certain temperature.
>> 
>> So far all correct. If you are using Quartus, you can fire up the timing
>> analyzer and take a look at what it guesses for timing / delay on the
>> pulse. It is not a perfect number, but I’d bet it will confirm that the 2
>> ns does come from the FPGA.
>> 
>>> I can calculate it by
>>> measuring 2 cycles and 3 cylces. My current code has not implement this
>>> part, it should provide some improvement. 2ns time error for 1s gate,
>> that
>>> is something.
>> 
>> The delay probably is from the input / output fabric on the FPGA ( =
>> output driver). The test you propose should demonstrate this.
>> 
>>> 2) For a 90ps TDC, I think the result should be something like +-0.001
>>> cycle. But I get something like +-0.003 cycle. I do not know the reason
>> for
>>> now.
>> 
>> Two reasonable *guesses* would be crosstalk and noise.
>> 
>> 1)  If there are any other clocks running around during this test, I’d see
>> if they can be shut down. Things like an free running OCXO are good for
>> this - they are easy to isolate.
>> 
>> 2) Noise could be internal to the TDC. If it’s 90 ns at one sigma, then
>> you will indeed see +’/- 3 X that (or more) depending on how long you watch
>> it. At least by my math the one sigma on the data is 149 ps. That’s a bit
>> over 90 ps, but not terribly far.
>> 
>> Delaying the signals relative to each other (clock and output) as Magnus
>> suggests in another post is probably a real good idea for sorting some of
>> this out.
>> 
>> Bob
>> 
>>> 
>>> 
>>> 
>>> 
>>> 2014-12-27 22:58 GMT+08:00 Bob Camp <kb8tq at n1k.org>:
>>> 
>>>> Hi
>>>> 
>>>> (In reply to several posts. It’s easier for me this way)
>>>> 
>>>> Ok, that’s good news !!! (and useful data)
>>>> 
>>>> Your counter performance degraded a bit when you put in 5 db and not
>> much
>>>> when you put in 8 db.
>>>> 
>>>> It’s also maybe *too* good news. I suspect that cross talk between the
>>>> channels may be impacting your results.
>>>> 
>>>> Next step is to try it with two independent sources and a bit more
>>>> attenuation. When you try it with two sources, you need to attenuate
>> first
>>>> one source and then switch the attenuators to the other source. That
>> will
>>>> help you see if crosstalk from one channel is more of a problem than
>> from
>>>> the other channel.
>>>> 
>>>> One parts hint:
>>>> 
>>>> Cable TV attenuators are much cheaper than their fancy 50 ohm
>> MIniCircuits
>>>> cousins. They are also something you can pick up down at the corner
>>>> electronics store. For this sort of testing they are perfectly fine to
>> use.
>>>> At this point in the testing the mismatch between 75 ohms and 50 ohms is
>>>> not a big deal. You will need to adapt connectors, but you probably
>> still
>>>> will save money.
>>>> 
>>>> =======
>>>> 
>>>> Op-amps that have enough bandwidth and performance for a high input
>>>> impedance counter input are rare items. They also are not cheap. Often
>> they
>>>> come as some sort of current feedback part with low(er) input
>> impedance. If
>>>> you want your counter to work to 300 MHz, it should accept a 300 MHz
>> square
>>>> wave. That might mean passing the third or even the fifth harmonic of
>> the
>>>> square wave. An input channel with 900 or 1500 MHz bandwidth is quite a
>>>> challenge.
>>>> 
>>>> One very simple solution is to just grab a high speed comparator like
>> the
>>>> one used by Fluke / Pendulum (ADCMP565). Drive it directly with your
>> input
>>>> or clock. Make it your front end device. That’s not an ideal solution,
>> but
>>>> it will give you the bandwidth and a reasonable input impedance. It
>>>> requires messy things like a negative supply  or a “fake” ground (so
>> would
>>>> the op amp). It also has an ECL output that needs to be converted to
>> match
>>>> your FPGA ( hint: use the clock inputs, they are LVPECL compatible).
>>>> Driving into the FPGA with a differential signal is probably needed to
>>>> reduce crosstalk.
>>>> 
>>>> No matter how you do it, input channels are *not* an easy thing to do
>>>> properly. Even on commercial counters, they often are easy to fool.
>>>> Designing one is only the start. Fully testing it is equally complex.
>>>> 
>>>> =========
>>>> 
>>>> Do not underrate your skills in any way. You are doing far more on this
>>>> project than any of the rest of the list members have done. We have
>> talked
>>>> and talked forever about these chips. We talk a lot about these ideas.
>> We
>>>> suggest lots of complex solutions to various possible problems (like the
>>>> expensive comparator I suggested above). What we almost never do is
>>>> actually build a counter. If we build something we don’t fully test it.
>> I
>>>> have never seen any list member share their results the way you have. I
>>>> suspect that most of us (yes this includes me) are a bit to scared of
>> the
>>>> response.
>>>> 
>>>> Please do not stop your work. Keep letting us know how it is going. This
>>>> is very exciting !!!
>>>> 
>>>> Bob
>>>> 
>>>>> On Dec 27, 2014, at 8:22 AM, Li Ang <lllaaa at gmail.com> wrote:
>>>>> 
>>>>> Hi Bob,
>>>>> Here is the data and test scheme.
>>>>> It does not show much difference.
>>>>> 
>>>>> 2014-12-26 22:12 GMT+08:00 Bob Camp <kb8tq at n1k.org>:
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-nuts at febo.com
>>>> To unsubscribe, go to
>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>> and follow the instructions there.
>>>> 
>>> 
>> <1228.gif><1228.zip><tdc_test.zip>_______________________________________________
>>> time-nuts mailing list -- time-nuts at febo.com
>>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>> 
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.



More information about the time-nuts mailing list