Re: [casper] ROACH1 est_brd_clk()

2018-04-18 Thread Tom Kuiper

On 04/18/2018 10:53 AM, Gary, Dale E. wrote:
What digitizer are these using?  We have had issues with the KATADC on 
ROACH2, which turns out to need some register initializations in order 
to function properly, and the symptom is a bad est_brd_clk() result.


Hey, wow, Dale! That was fast.  Yes, they are KATADCs.  I'm interested 
in knowing about the registers. The order of the initialization might 
then be due to something in my code.


Thanks

Tom

--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.


Re: [casper] ROACH1 est_brd_clk()

2018-04-18 Thread Gary, Dale E.
Hi Tom,

What digitizer are these using?  We have had issues with the KATADC on
ROACH2, which turns out to need some register initializations in order to
function properly, and the symptom is a bad est_brd_clk() result.

Regards,
Dale

On Wed, Apr 18, 2018 at 1:48 PM, Tom Kuiper  wrote:

> What situations could cause est_brd_clk() to give the wrong answer?
>
> I have two ROACH1s and a Valon 5007.  Every time we check the Valon it
> puts out the required clock frequency, 1020 MHz, at about +7 dBm.
>
> When I initialize the ROACHs (roach1, roach2) from an ipython command
> line, est_brd_clk() in the __init__() routine finds the expected system
> clock of 255 MHz.  When the two ROACHs are initialized as part of a server
> initialization, the first ROACH initialized passes the system clock test
> and the second fails. I've reversed the order of initialization so it's not
> a specific ROACH that passes or fails.  Then at the end of the server
> initialization, I check both system clocks and they are then both wrong.
> Then, if I shut down the server and re-initialize the ROACHs, they both
> have the right system clock.
>
> If no one has an explanation, perhaps there might be some suggestions for
> what I should try next.
>
> Thanks and warm regards,
>
> Tom
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.


[casper] ROACH1 est_brd_clk()

2018-04-18 Thread Tom Kuiper

What situations could cause est_brd_clk() to give the wrong answer?

I have two ROACH1s and a Valon 5007.  Every time we check the Valon it 
puts out the required clock frequency, 1020 MHz, at about +7 dBm.


When I initialize the ROACHs (roach1, roach2) from an ipython command 
line, est_brd_clk() in the __init__() routine finds the expected system 
clock of 255 MHz.  When the two ROACHs are initialized as part of a 
server initialization, the first ROACH initialized passes the system 
clock test and the second fails. I've reversed the order of 
initialization so it's not a specific ROACH that passes or fails.  Then 
at the end of the server initialization, I check both system clocks and 
they are then both wrong. Then, if I shut down the server and 
re-initialize the ROACHs, they both have the right system clock.


If no one has an explanation, perhaps there might be some suggestions 
for what I should try next.


Thanks and warm regards,

Tom

--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.