Re: [casper] off-line data processing with ROACH2

Thanks James, I will look in to it. Thanks & Regards, Bela Bela Dixit Electronics and Telecommunication engg(digital system) On Thu, Apr 19, 2018 at 11:42 AM, James Smith wrote: > Hello Bela, > > Depending on how you're reading your binary file on the computer, the >

Re: [casper] off-line data processing with ROACH2

Hello Bela, Depending on how you're reading your binary file on the computer, the easiest thing to do would probably be to use the ROACH2's 10 GbE networking. You can then use e.g. a python socket program to send the data to the ROACH2 in chunks, receive and process it on the FPGA and then use

[casper] off-line data processing with ROACH2

Hi CASPERites, I am having digitized data which is available in binary file. This data I want to push on to the ROACH2 board as an input for further processing. Kindly suggest me what are the options that can possible in this regards. Thanks & Regards, Bela -- You received this

Re: [casper] off-line data processing with ROACH2

Have a look at Tutorial 2: https://casper.berkeley.edu/wiki/Tutorial_10GbE_ROACH2 This is a very simple example of using the networking obviously, but the main ideas will hold. Just be careful of endian-ness, make sure that you're interpreting packets correctly, because computers tend to be

[casper] roach2 fault thresholds?

Hi All, Does anyone know what the fault led and/or shutdown thresholds are for the roach2 board? I found this table for roach1: https://casper.berkeley.edu/wiki/Roach_monitor_and_management_subsystem But I can't find anything similar for roach2. Also, does anyone know if there's a log kept

Re: [casper] temporary ROACH2 faults after power dips and spikes

Dear kind CASPER Colleagues, To offer a little more feedback on this: —We reiterate that all advice is appreciated and useful. They may well be relevant to prior weird experiences, however in the current case . . . — . . . after assorted power cycles removing all inputs, confirmation that the

Re: [casper] temporary ROACH2 faults after power dips and spikes

Hi, Jonathan, The ROACH2s at GB output over all 8 SFP+ ports very often without problem. Not sure whether this matters, but they are connected via fiber optic transceivers rather than copper cables. HTH, Dave > On Apr 19, 2018, at 11:00, Jonathan Weintroub >

Re: [casper] KAT-7 KatADC on ROACH2

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

Re: [casper] KAT-7 KatADC on ROACH2

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

Re: [casper] KAT-7 KatADC on ROACH2

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

Re: [casper] KAT-7 KatADC on ROACH2

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

Re: [casper] KAT-7 KatADC on ROACH2

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")

Re: [casper] KAT-7 KatADC on ROACH2

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

Re: [casper] KAT-7 KatADC on ROACH2

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