Re: [casper] roach2 bof file problems

[Shanly Rajan]

On Thu, Jun 13, 2013 at 4:45 AM, Suraj Gowda surajgo...@berkeley.eduwrote:

 Hi Dave,
 Thanks for the info, I'm able to program the roach2 from both telnet and
 katcp. We did manage to waste some time on the katcp python version issue (
 http://www.mail-archive.com/casper@lists.berkeley.edu/msg04067.html) as
 well.

 Does anyone know if there are there plans for a ROACH2 setup wiki page?

I will take ownership of that task and will add a ROACH2 setup wiki page in
coming days.

 Suraj


 On Wed, Jun 12, 2013 at 3:13 PM, David MacMahon dav...@astro.berkeley.edu
  wrote:

 Hi, Suraj,

 On Jun 12, 2013, at 2:59 PM, Suraj Gowda wrote:

  Does anyone know what causes the error 'cannot execute binary file'
 when trying to execute a bof file from the powerpc shell?  This error
 occurs with all bof files, including the test designs from github

 The bof files are not executable on ROACH2.  Executable bof files
 requires a BORPH enabled Linux kernel.  ROACH2 uses a memory mapped kernel
 module for talking to the FPGA rather than BORPH.  It might have been less
 confusing if we gave them an extension other than .bof even though they
 do utilize a similar file format (ELF-based) as ROACH1 bof files.

 I think you must program the FPGA via tcpborphserver3.  I am not aware of
 a command line progdev utility that runs on the ROACH2's PPC without
 using tcpborphserver3 (though it could be nice to have).  I think the
 mailing list archive will have some discussions on how to do this using
 telnet or netcat or Python or Ruby.

 Hope this helps,
 Dave





-- 
Shanly Rajan

SKA-SA
DBE Team
021 506 7362 (O)
072 783 2022 (M)

Re: [casper] roach2 bof file problems

[David MacMahon]

Hi, Shanly,

On Jun 12, 2013, at 11:38 PM, Shanly Rajan wrote:

 I would strongly encourage you to try the new approach of using a memory 
 mapped kernel module for FPGA access. 

I totally agree with you!  In fact, I think we should eliminate BORPH kernel 
builds altogether for ROACH2.  It would be great to have the memory mapped 
module backported to ROACH1, then we could eliminate BORPH builds altogether 
(except for legacy BEE2 hardware where BORPH actually adds value).

Dave

[casper] MUSIC ADC/DAC 4x interface

[G Jones]

Hi,
Is anyone using the adc_mkid_4x and dac_mkid_4x interfaces to the
MUSIC ADC/DAC board? When I use these blocks I get sporadic bit
glitches on both the ADC and DAC most of the time, even though timing
comes out fine. Reprogramming the ROACH many times and trying many
ADC/DAC clock rates sometimes reduces or eliminates the glitches, but
not particularly reliably. This smells like some sort of constraint is
not getting set properly in the UCF. There was some discussion of a
problem like this for the adc2x14_400 block, but that was the 2x
interface and seems to be unrelated to this. I am clocking my FPGA off
of the ADC (ADC1) with an FPGA clock of 120 MHz and an ADC and DAC
clocks at 480 MHz.

I just built a test design with the adc_mkid and dac_mkid (2x)
interfaces. They seem to work fine w/o glitches.

Anyone experienced this problem and have  a solution?

Thanks,
Glenn