Hi Tom, Thinking about this a moment longer -- I don't think an incorrect clock phase will be related to reported board clock problems. You can completely mangle the clock phase wrt to data lines, and the FPGA should still correctly lock onto the clock and derive an appropriate rate. The only symptom will be corrupted ADC data transfer.
You can get funky things happening where the initialization process (which might mess with the ADC output clock phase or rate) screws the clock the FPGA is using, and the FPGA never correctly re-locks. Usually these can be fixed with an appropriate reset of the ADC controller to reset its internal PLLs. Not being aware of your setup I can only speculate wildly, but if your code accidentally messes with a board and then doesn't reset it that could potentially cause issues. Cheers Jack On Thu, 19 Apr 2018 at 11:44 Tom Kuiper <[email protected]> wrote: > On 04/19/2018 11:20 AM, Jack Hickish wrote: > > The clock should trigger capture of the values on the data lines when > > they are stable, so putting the clock edges out of phase with the data > > transitions makes sense. Having said that, the controller HDL may or > > may not mess with the relative phases of clock and data in the FPGA, > > so the correct thing for the ADC chip to do isn't well defined unless > > you dig into the interface code. If I remember correctly, the values > > Dale sent were empirically determined -- we saw data capture glitches > > at high clock rates, indicative of the clock sampling the data lines > > as they changed, so we changed the clock phase and the glitches went > > away. The "correct" thing to do is probably to have the interface > > carry out link-training on power up -- put the ADC in a test mode > > where it outputs a known pattern, and mess with the clock vs data > > phases in the FPGA until data capture is reliable. Some of the other > > ADCs do this in firmware or software. > > Thank you, Jack. This is timely because I just concluded that the > simple fix Dale recommended does not work. Before I start down the path > you advise I'm going to take a walk and reflect on the one consistent > clue which does seem to point to something other that a > hardware/firmware problem. When I initialize the first ROACH with the > server, the system clock checks out fine. The second ROACH initialized > by the server reports a problem. At the end of the initialization of > the two, both report incorrect system clocks. > > The second part of this is if I initialize both ROACHs with the firmware > from the command line, not the server, their system clocks are good. > > I think it has to be something in the software. The ROACHs are not > aware of each other. I'm going to let the subconscious work on it a bit. > > Best regards, > > Tom > > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected].
