Hi > On Dec 20, 2014, at 10:28 AM, Li Ang <lll...@gmail.com> wrote: > > Hi > It's me again. I was debugging the new FPGA version board this week. > The attached file is the test result of this new board, and 2 tests of CPLD > version(2014/12/11) are also included. There are few things changed between > these 2 version: > 1) CPLD -> FPGA > 2) XC6206 -> TPS79333 for TDC power supply. Analog and digital part of TDC > use dedicated LDO.
good idea > 3) 2 layer -> 4 layer also a good idea > 4) add 74ALV2G14 since FPGA does not support schmitt input I would suggest trying it with a non-schmitt trigger part as well. It should be a simple swap out since it’s a leaded part. In some cases the trigger level hysteresis is not helpful. The better over voltage immunity of the leaded parts compared to the FPGA inputs *is* a good idea. They also are a lot easier to swap out if you blow one out accidentally. > > A little bit better than before. :) Yes indeed. Not just better in magnitude, but better in terms of the traces all being close to each other. > > > > mistakes of current version: > 1) the board is 1cm bigger than expected……. so you got some board for free :) > 2) the themral pad of FPGA should be connected to ground Often multiple via’s are run to ground from the thermal pad to improve heat spreading. If the part is not hot to the touch, you should be ok for right now. > > test instruments > 1) HP6622A as power supply > 2) FE5650 rb as reference > 3) PRS10 rb as DUT I would toss an OCXO or two into the mix eventually. ——————— It looks like the three “4 layer FPGA” plots all cluster tightly at just under 2x10^-10 at 1 second as long as linear regression is turned off. That’s pretty good performance. I *think* I’m seeing that correctly on the plots. If I’m not, let me know. The two plots with linear regression are still a bit “interesting”: The plot with ref and DUT the same ( green) still is showing data that is in the “to good to be true” range. The averaging process of the linear regression is probably still causing this. The plot with ref and DUT not the same (RED) shows some sort of spur. That could indeed be a spur from one or the other of the Rb’s. It also could be something in your lab. Turning out the light is a good thing to check. Because of the low frequency, I would suspect a spur on the Rb. Put another way, the counter is not making a mistake in this case. It’s reporting what is actually going on with the inputs. Another test source (or pair of sources) would help sort this out. ———————— The ADEV of a (working) MV89 or similar OCXO over the 1 to 100 second range should be at the < 2x10^-12 level. That’s good enough for the tests you are running. It’s also well below the (maybe) 1x10^-11 of the Rb’s at 1 second. So far the Rb’s ADEV has not been a problem for you. If you get a bit better with what you are doing, it may become an issue. You will need to use TimeLab’s built in “remove frequency error (drift)” capability when you are running OCXO’s. That’s an ok thing to do for the test. —————————— Something else to look at: Check your results vs input level. In other words, attenuate one of the input signals and see what happens. I would start with 3 or 6 db and go from there. The attenuation does not have to be precise. The frequencies involved are not high enough to require fancy parts. The idea is to check if the input noise level of the gates is a problem for you. If the data quickly get worse as you attenuate, they need some help. Enough for now. Thanks for sharing !! Bob _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
