#4749: Clock Driver Validation -------------------------------------+------------------------------ Reporter: Matt Joyce | Owner: Sebastian Huber Type: enhancement | Status: assigned Priority: normal | Milestone: Component: test | Version: 6 Severity: normal | Resolution: Keywords: clock driver, testsuite | Blocked By: Blocking: | -------------------------------------+------------------------------
Comment (by blackbird): Adding onto Chris John's suggestions. Given variety of hardware peripherals and systems affected by clock jitter, if I may make a couple of suggestions on PPS/GPS input clocking from prior experience implementing similar testing: 1. Split the test suite into external/external HIL (Hardware in the Loop) and maybe SIL (Software in the Loop) pass/fail. Consider other devices on the clock tree if interested. For example, PCIe jitter testing, IEEE 1588, etc, can further aid system verification from an external timing perspective. May help if SYSTICK derived from a shared clock distribution source that could have their own sources of configuration/firmware/logic- ware/implementation errors on a single BSP. This may be vital to avoid misdiagnosing an off by one error that could be located in say a clock distribution configuration register unrelated to the driver being validated. 2. GPS Quality Checks. Given potential geographic distribution of users, test sites limits, band configuration, and Ephemeris, general quality of fix checks should be a condition for tests passing or failing. An atomic/high end OCXO in general could avoid GPS dependence if Stratum 1 is sufficient for the test at hand, but may be out of reach from a cost and availability perspective. 3. Consider a spec on minimum GPS holdover clocking performance for the external hardware versus target frequency and clock tree configuration. In an adverse environment, etc, GPS receiver going into loss off fix can add variability through the packaged DCTCXOs and VCTCXOs freewheeling. 4. Clock Sync and Distribution Performance. Many of the clock distribution/jitter cleaner/sync ICs are often rated worse than Stratum 3 and may not provide adequate jitter free performance to test higher speed clocks as Chris alluded to. Though this issue is related to SYSTICK performance, my concern here is the variability of clocks and potential phase relationships across clock domains. This is especially applicable to FPGA metastability issues, clock domain crossing issues, soft-processor synthesis variability, and clock distribution pathways for PPS input/output, and the derivation of SYSTICK. 5. No-GPS Solution: A < 100 PPB clock can provide adequate short term timing performance, especially against the 25PPM or clocks on many PCBs. The ability to frequency tune an oscillator through (say a VCTCXO or digitally tuned) and PLL lock can also be helpful. Some testers lock both the input and output clock signal with known dividers derived from the clock tree config. This gets into spectrum analysis territory and can be a good way to validate the test suite itself. Granted, if someone is looking for 1000 Systicks versus PPS, and they are off by 1 on a fast clock, none of these considerations matter since the missing tick is clearly observable. However, this is not a deterministic solution versus a phase lock + known good hardware comparing the output with the BSP clock tree config. This is also flexible as intermediate clocks can be easily validated as well, and many BSPs internally contain the reference hardware to implement this. 6. Consider accuracy and capability of onboard thermal sensors and SoC utilization/junction temperatures. A set of constraints/monitored variables in the test setup will help for hardware in the loop. This itself can produce a false positive for off-by one testing or throw off jitter measurements. Granted, if SYSTICK frequency dividers are large, this is less of a problem as the problem is more observable. 7. Consider Allan Deviation/Variance statistics as an output for in-situ clock performance analysis given availability of a higher performance external reference clocks and adequate measurement hardware. This may help identify outliers and quantify performance of the on-board and off-board clocks for validation and outlier rejection. This data can then be used to generate a good test times from time constants where oscillator performance is optimal after thermal settling. Other concerns on test threshold parameters that may vary for BSPs are oscillator models, aging characteristics, part changes, mfg batches, etc, some of which could be datasheet values depending on pass/fail criterion. These are mostly related to jitter related issues that I can see arising from the test suite, and a free measurement of clock related performance parameters off a GPSDO doesn't seem half bad, especially for Stratum 3E or better which is natively supported by most clock distribution circuits on modern 5G, PCIe 5.0, IEEE 1588, and precision timing capable boards -- Ticket URL: <http://devel.rtems.org/ticket/4749#comment:4> RTEMS Project <http://www.rtems.org/> RTEMS Project
_______________________________________________ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs