[time-nuts] FPGA based TDC

Bob Camp kb8tq at n1k.org
Sun Dec 18 09:26:28 EST 2016


Hi

> On Dec 18, 2016, at 7:46 AM, Attila Kinali <attila at kinali.ch> wrote:
> 
> On Sat, 17 Dec 2016 10:48:35 -0500
> Bob Camp <kb8tq at n1k.org> wrote:
> 
>>> Sébastian told me that for the original TDC design (based on a Spartan3 IIRC)
>>> they didn't employ any method for increasing the resolution by compensating
>>> for different bin sizes, as they got pretty close to the minimal bin size
>>> anyways. But for the Cyclone4 I guess using something like Wu's Wave Union[4]
>>> approach might be a good idea. Unfortunately, we didn't have the time to 
>>> try it.
>> 
>> If you do go to the Wave Union, it does work on Cyclone 5’s and Spartan 6’s. I suspect 
>> it will work on the newer stuff as well. The big issue you run into is “decoding” the patterns
>> you get. The data is *not* a nice looking set of “all zeros before” and “all ones after” some
>> point. Figuring out which bin came first with a random calibration approach requires a 
>> bit of a leap of faith (count the zeros / count the ones) to order them. Even with that you 
>> still get bins that appear to be equivalent (same number of zeros), but have them in a 
>> different order. 
> 
> Yes, the decoding of wave union is anything but trivial. The main issue
> is that the ordering of the thermometer encoded bits is not the same as
> the ordering of the delay line. This is due to the badly controlled delays
> within the delay line and the clock tree causing unequal capture time for
> the registers. This leads to "bubbles" in the encoding. The original TDC Core
> code reordered the bits according to the timing simulation results.
> For the Cyclone4 we encountered the problem, that the ordering is not stable.
> i.e. the ordering changes over time and is dependent on the logic
> surrounding the delay line. Thus we reverted to only count the zeros/ones as
> an approximation. This of course does not work with wave union and an
> other scheme as to be devised. One way to do it would probably be to make
> the distance between the edges long enough such that the bubles can be
> matched to a single edge. Then one could count the zeros/ones in the area
> around the presumed edge position. But as I have not tried this, I do not
> know how well it would work in reality.


It does work, but it is a bit messy. The number of “indeterminate” states starts to get
a bit alarming. Without a fancy system to actually figure out what is what ( = a generator 
that steps off at 1 ps resolution with jitter < 0.1 ps) there is a lot of “faith”involved. 

You also can do the same things with multiple delay lines. The assumption is that the
odd stuff will not happen at the same places. At least with my limited skills, that turned
out to be a poor assumption. The problems occurred to often and they pretty much
*always* lined up. 

The scary part is that you can come up with issues like crosstalk that can turn the 
system into something a bit non-random. There have to be sensitivities like that
on the die. It’s just a question of if they are large enough to matter in this case …

Back to shopping the auction sites for that generator. I’ve got $20 as my max bid :)

Bob

> 
> 				Attila Kinali
> 
> -- 
> Malek's Law:
>        Any simple idea will be worded in the most complicated way.
> _______________________________________________
> 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