Re: [casper] Problem using the ASIAA 5Gsps chip in design

2014-05-10 Thread Gopal Narayanan
Dave,

Is there a simple fix to xps_library/detokenize.m in the SKA mlib_devel
repository? Should I just use the detokenize.m script from the SMA git
branch?

Should the calculation not be based on app_clk_rate but rather on 100 MHz?

Thanks!
Gopal



On Fri, May 9, 2014 at 4:53 PM, David MacMahon dav...@astro.berkeley.eduwrote:

 I think Gopal's problem with the ska-sa mlib_devel is due to commit
 e419ce2.  This commit changed the calculation of the clock factors in
 xps_library/detokenize.m to be based on app_clk_rate (250 MHz in Gopal's
 case) rather than 100 MHz.  These clock factors are passed to the
 roach_infrastructure HDL via parameters that get defined in system.mhs.

 Dave




-- 
Gopal Narayanan  Ph #: (413) 545 0925
Department of Astronomy  e-mail: go...@astro.umass.edu
University of Massachusetts  Amherst MA 01003


Re: [casper] Problem using the ASIAA 5Gsps chip in design

2014-05-10 Thread Gopal Narayanan
Hi Rurik

I have been mostly using the SKA mlib branch until now. When I saw the
problem of compiling ROACH2 and ASIAA ADC, I tried to switch to SMA mlib to
see if the problem was there as well (my assumption was that since you guys
are using the ASIAA ADC actively, you must not have this issue). And indeed
while it solved the MMCM clock issue, the fi dependence on Fixed-Point
toolbox is a show-stopper there. So I might spend some time cherry-picking
the fi dependency out of the SMA branch. I'll let you know the success of
this effort.

Thanks
Gopal


On Fri, May 9, 2014 at 3:47 PM, Primiani, Rurik
rprimi...@cfa.harvard.eduwrote:

 Hi Gopal,

 Your XSG core config parameters look fine to me. I do not understand
 how the adc0_clk clock frequency should affect the sys_clk-generating
 MMCM in any way. Can you send me the full output log of your compile?
 Also, can you send me the XPS_ROACH2_base/system.mhs file from your
 design directory?

 As for the fixed point toolbox, I see that commits 1b13e3d, 617ba13,
 and b3d63ce remove the fi dependence from the FFT blocks. This was
 after the most recent time I merged with ska-sa and so the
 sma-wideband FFT still depends on the fixed-point toolbox. You can try
 cherry-picking those commits to remove the dependence for now. I have
 tried this but I have not tested it.

 Unfortunately merging the two forks at this point would require quite
 a bit of careful thought since there are many conflicts that would
 need to be worked out. I will give this a shot since this needed to be
 done eventually.

 Best,
 Rurik



 On Fri, May 9, 2014 at 2:37 PM, Gopal Narayanan go...@astro.umass.edu
 wrote:
  Rurik
 
  For the MMCM error, here are my XSG core config mask parameters:
  Hardware platform: ROACH2:sx475t
  User IP Clock Source: adc0_clk
  User IP Clock Rate: 250 MHz
  Sample Period: 1
  Synthesis Tool: XST
 
  Yes, I normally use the ska-sa branch, and I have compiled the tutorial 3
  spectrometer using other boards (KatADC or iADC) successfully without
  needing the Fixed point Toolbox.
 
  Thanks!
  Gopal
 
 
 
  On Fri, May 9, 2014 at 2:24 PM, Primiani, Rurik 
 rprimi...@cfa.harvard.edu
  wrote:
 
  Hi Gopal,
 
  The MMCM error you pasted above has nothing to do with the ADC5g
  block. It is instead coming from the roach_infrastructure pcore which
  generates the sys_clk signal. What are your XSG core config mask
  parameters set to?
 
  I'm not sure how the sma_wideband repository differs from ska-sa in
  terms of the FFT and fixed point toolbox. The two forks have diverged
  quite a bit and should probably be merged. Perhaps one of the
  divergences is that the fixed point blocks have been replaced in
  ska-sa but I am unaware of such a change. Have you tried building your
  FFT module using the ska-sa fork (without the ADC5g if need be)?
 
  Thanks,
  Rurik
 
 
  On Fri, May 9, 2014 at 2:09 PM, Gopal Narayanan go...@astro.umass.edu
  wrote:
   Hi Casperites,
  
   I am trying to use the ASIAA ADC chip in a simulink design. To start
   with
   all I have in my design is the chip operating in two channel (AC
 mode),
   with 1:1 demux on ZDOK 0 with a clock rate of 2 GSps. I just
 terminated
   all
   outputs of the ADC just for this design. I am using a ROACH2 board in
 my
   design. I get the following error when compiling:
  
   ERROR:LIT:667 - Block 'MMCM_ADV symbol
  
  
  
 physical_group_infrastructure_inst/infrastructure_inst/sys_clk_fb_int/infrastructure_inst/infrastructure_inst/MMCM_BASE_sys_clk'
   has its target
  frequency, FVCO, out of range. Valid FVCO range for speed grade
 -1
   is
  600MHz - 1200MHz. The computed FCVO is a function of the input
   frequency
  CLKIN1_PERIOD, the division factor DIVCLK_DIVIDE, and the
   CLKFBOUT_MULT_F
  attribute (FVCO =
   1000*CLKFBOUT_MULT_F/(CLKIN1_PERIOD*DIVCLK_DIVIDE)).
   The
  CLKIN_PERIOD attribute may have been set by ngdbuild based on the
   user
  specified PERIOD constraint. The current calculated FVCO is
   400.00
   MHz.
  Reference the V6 architecture Users Guide or search the Xilinx
 Answer
   Records
  database for the error code.
   Errors found during logical drc.
  
   I am using Matlab R2012b and XSG 14.5.
   This is when I am using the SKA mlib-devel branch. Here are the
 details
   of
   the mlib git branch:
  
   $ git rev-parse --short HEAD
   b2d72d4
   $ git remote -v
   origin https://github.com/ska-sa/mlib_devel.git (fetch)
   origin https://github.com/ska-sa/mlib_devel.git (push)
  
  
   I tried to use the SMA mlib_devel branch instead. Here are the details
   on
   the SMA mlib branch I used:
  
   $ git rev-parse --short HEAD
   d4954fd
   $ git remote -v
   origin https://github.com/sma-wideband/mlib_devel.git (fetch)
   origin https://github.com/sma-wideband/mlib_devel.git (push)
  
   With the SMA mlib devel I am able to compile the simple ASIAA chip
   design
   mentioned above. However, for more complicated designs (I'm trying to
   put
   

Re: [casper] Problem using the ASIAA 5Gsps chip in design

2014-05-10 Thread David MacMahon
Hi, Gopal,

It doesn't look like there are any relevant changes for you since (and 
including) the suspect commit, so you could just reset your local mlib_devel 
back to the commit just prior to commit e419ce2 with this command:

$ git reset --hard e419ce2^

Note the '^' at the end, that's very important.

Dave

On May 10, 2014, at 8:43 AM, Gopal Narayanan wrote:

 Dave,
 
 Is there a simple fix to xps_library/detokenize.m in the SKA mlib_devel 
 repository? Should I just use the detokenize.m script from the SMA git branch?
 
 Should the calculation not be based on app_clk_rate but rather on 100 MHz?
 
 Thanks!
 Gopal
 
 
 
 On Fri, May 9, 2014 at 4:53 PM, David MacMahon dav...@astro.berkeley.edu 
 wrote:
 I think Gopal's problem with the ska-sa mlib_devel is due to commit e419ce2.  
 This commit changed the calculation of the clock factors in 
 xps_library/detokenize.m to be based on app_clk_rate (250 MHz in Gopal's 
 case) rather than 100 MHz.  These clock factors are passed to the 
 roach_infrastructure HDL via parameters that get defined in system.mhs.
 
 Dave
 
 
 
 
 -- 
 Gopal Narayanan  Ph #: (413) 545 0925
 Department of Astronomy  e-mail: go...@astro.umass.edu
 University of Massachusetts  Amherst MA 01003