On 04/19/2018 03:18 PM, Jack Hickish wrote:
If this is the case I would imagine that you see est_brd_clk taking
varying amounts of time to return -- just so this doesn't keep me
awake at night, is that the case?
Sleep well tonight. I see all kinds of numbers between and 300 and 480
but
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
I'm not sure I understood that sentence(!) But let me say this --
There is an automatically instantiated register in all CASPER builds called
sys_clkcounter. It is a simple counter which increments every FPGA clock
tick.
est_brd_clk() is essentially a wrapper for:
t0 = read("sys_clkcounter")
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
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
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
Hi Tom,
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
This is probably aimed at Jack now but someone else may have an answer
to the question below.
On 04/18/2018 11:33 AM, Gary, Dale E. wrote:
This sounds like the problem we had until Matt Dexter and Dave
MacMahon determined that some KatADC registers need to be set for
correct ADC operation.
Hi Tom,
I am resending my reply of about a month ago to another, similar question.
Regards,
Dale
On Wed, Mar 7, 2018 at 8:14 AM, Gary, Dale E. wrote:
> Hi Yan,
>
> This sounds like the problem we had until Matt Dexter and Dave MacMahon
> determined that some KatADC
waveform is not quite good, as in zdok0/pol0 in attached
> picture.
>
> Any more suggestions?
>
>
> Thanks again.
> Yan
>
>
> -- Original Message ------
> From: "Gary, Dale E." <dale.e.g...@njit.edu>
> To: "casper list" <casper@lists.berk
Original Message --
> From: "Zhu, Yan" <zhu...@nao.cas.cn>
> To: casper@lists.berkeley.edu; dale.e.g...@njit.edu
> Sent: 2018-03-08 15:25:55
> Subject: Re[2]: [casper] KAT-7 KatADC on ROACH2
>
>> Hi Dale,
>>
>> Thanks a lot for helping.
hon.
Yan
-- Original Message --
From: "Zhu, Yan" <zhu...@nao.cas.cn>
To: casper@lists.berkeley.edu; dale.e.g...@njit.edu
Sent: 2018-03-08 15:25:55
Subject: Re[2]: [casper] KAT-7 KatADC on ROACH2
Hi Dale,
Thanks a lot for helping.
I applied the code, now the fpga clock spe
--
From: "Gary, Dale E." <dale.e.g...@njit.edu>
To: "casper list" <casper@lists.berkeley.edu>
Sent: 2018-03-07 21:14:59
Subject: Re: [casper] KAT-7 KatADC on ROACH2
Hi Yan,
This sounds like the problem we had until Matt Dexter and Dave MacMahon
determined that some
hi dale,
thanks for helping out zhu yan and FAST.
dan
On Wed, Mar 7, 2018 at 5:14 AM, Gary, Dale E. wrote:
> Hi Yan,
>
> This sounds like the problem we had until Matt Dexter and Dave MacMahon
> determined that some KatADC registers need to be set for correct ADC
>
Hi Yan,
This sounds like the problem we had until Matt Dexter and Dave MacMahon
determined that some KatADC registers need to be set for correct ADC
operation. Below is the python code we use to set them:
addr = [0x, 0x0001, 0x0002, 0x0003, 0x0009, 0x000A, 0x000B,
0x000E,
15 matches
Mail list logo