I was wrong. Even starting a thread outside of the ROACH control thread
will cause est_brd_clk() to go bad.
To summarize, for each ROACH I start a control thread. Initializing the
FPGA also starts a thread. So at this point we have the main thread,
two ROACH control threads, and two FPGA threads. est_brd_clk() works
fine for either ROACH.
Now I start another thread from the main thread to handle writing to
disk from each ROACH's queue. As soon as I start one of these threads
est_brd_clk() goes bad.
I believe that the firmware is not affected. I'll verify by looking at
known spectra. I think there is something in est_brd_clk() that makes
an assumption about timing that is not valid in this situation.
Regards
Tom
On 04/19/2018 02:59 PM, Tom Kuiper wrote:
On 04/19/2018 11:52 AM, Jack Hickish wrote:
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.
Well, I found the cause even if I don't understand it yet. Since I
have two ROACHs running side-by-side under a common parent, each is
running in its own thread. That is, my software is threaded, as well
as the fpga in its own thread under corr launched from within my
thread. This still works. But then I start up another thread from
within my thread to handle writing to disk. Then est_brd_clk() goes
bad. Perhaps some corr expert reading this will have an explanation.
I can probably fix it by making the disk writing thread separate from
the ROACH control thread. We'll see.
--
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].
