thermometer to binary encoder truth table

[mrflibble]

It does clear things up. Now I can promote you from the "delusional" category to the "wildly optimistic" category. Progress! A 20 ps difference per flip-flop in the naive implementation you posted will give you plenty of opportunity to learn interesting things. Case in point, you won't be able to get reliable single shot resolution of 20 ps either with that approach.

Sooo, how about a pulse stretcher with a gain of 100? Then you can get away with your current approach on available fpga's and get the required single shot resolution. If you are averaging (which you didn't mention) then the picture becomes somewhat different.

 

[mohamed mahmoud]

i can get easily get 20 psec if i use 90nm technology .
delay of inverter (represent resolution without using time amplifier) equal to 20 psec in 90nm .

increasing the gain of time amplifier (as much as you want) is not easy because it affect input linear range and resolution and range Programmabilty ...
i refer you to this thesis
**broken link removed**
it,s very interesting topic and has more chance .....

--------------------------------------------------
is the priority encoder is best block to convert my thermometer to binary code ?

 

[mrflibble]

Gave that paper a quick browse. Yup, that has all the traditional ingredients in it to get to 20 ps on a modern fpga. Unlike that image you posted earlier. ;-)

Priority encoder suffers from an annoying problem when there are "bubbles" in your sampled pulse train.

Lets put it this way: the priority encoder will work. As long as you can ensure that there are no bubbles (aka out of order zeroes or ones) in your samples. And of course you can ensure that, because what could possibly go wrong? Hence the priority encoder is the best solution. Right up to the point where you discover it is not the best solution, and then a bubble tolerant solution is the best solution.