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

2014-05-12 Thread Gopal Narayanan
Hi Dave

I tried your suggestion to reset back to the commit at hand. I tried
recompiling the simple ASIAA ADC design alone. I get further along this
time, but I get the following error:

XPS% Loading xmp file system.xmp
ERROR:EDK - This project was created with EDK version 14.6, but the
installed
   version of EDK tools is 14.5
ERROR:EDK - while running revup

So my Xilinx tool set is indeed 14.5. I even tried to create  a whole new
project from scratch with a XSG config object, a System generator and the
ASIAA ADC. But it still produces the same error. Perhaps this is a simpler
fix? Looks like the EDK version is hard-coded somewhere in the mlib-devel
area. Do you have suggestions on what to do here?

Thanks!
Gopal



On Sat, May 10, 2014 at 2:15 PM, David MacMahon
dav...@astro.berkeley.eduwrote:

 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
 




-- 
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-12 Thread David MacMahon

On May 12, 2014, at 11:34 AM, Charles Coldwell wrote:

 On Mon, May 12, 2014 at 2:19 PM, David MacMahon
 dav...@astro.berkeley.edu wrote:
 
 This version info seems to not really be used/useful at all.
 
 Agreed, and it seems to be absent from the corresponding files in the
 sma-wideband fork.  It could/should probably be dropped, which would
 be a better patch.

That would be great!  (assuming it works, of course)

Dave




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

2014-05-12 Thread Gopal Narayanan
Charles,

Thanks. This patch worked fine.

Gopal



On Mon, May 12, 2014 at 1:23 PM, Charles Coldwell coldw...@gmail.comwrote:

 On Mon, May 12, 2014 at 11:52 AM, Gopal Narayanan go...@astro.umass.edu
 wrote:
  Hi Dave
 
  I tried your suggestion to reset back to the commit at hand. I tried
  recompiling the simple ASIAA ADC design alone. I get further along this
  time, but I get the following error:
 
  XPS% Loading xmp file system.xmp
  ERROR:EDK - This project was created with EDK version 14.6, but the
  installed
 version of EDK tools is 14.5
  ERROR:EDK - while running revup

 I had to work around this problem for version 14.4 targeting ROACH2

 $ git show 39a088449a2e0261cd84740014b313f704b55ded
 commit 39a088449a2e0261cd84740014b313f704b55ded
 Author: Charles M. Coldwell coldw...@gmail.com
 Date:   Tue Apr 29 13:08:42 2014 -0400

 Change the ISE version number to the one we have.

 diff --git a/xps_base/XPS_ROACH2_base/system.xmp.sx475t
 b/xps_base/XPS_ROACH2_base/system.xmp.sx475t
 index 88706c5..0c6922e 100644
 --- a/xps_base/XPS_ROACH2_base/system.xmp.sx475t
 +++ b/xps_base/XPS_ROACH2_base/system.xmp.sx475t
 @@ -1,5 +1,5 @@
 -XmpVersion:  14.6
 -VerMgmt: 14.6
 +XmpVersion:  14.4
 +VerMgmt: 14.4
  IntStyle:default
  MHS File:system.mhs
  MSS File:system.mss

 Since this file is copied verbatim when building your XPS project (no
 variable substitution or whatnot), I couldn't think of a better way to
 do it.

 --
 Charles M. Coldwell, W1CMC
 Belmont, Massachusetts, New England
 Turn on, log in, tune out




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




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

2014-05-09 Thread Gopal Narayanan
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
together a spectrometer with the ASIAA chip) when using FFT modules, the
SMA mlib branch seems to need the Matlab Fixed-Point toolbox, which I don't
have a license for.

I came across  the following thread in the casper mailing lists about the
Fixed Point toolbox:

https://www.mail-archive.com/casper@lists.berkeley.edu/msg04488.html

Anybody have some ideas on what may be causing the MMCM_ADV error seen
above or to circumvent the need for  a FP toolbox license?

Thanks!

Gopal



-- 
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-09 Thread Primiani, Rurik
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
 together a spectrometer with the ASIAA chip) when using FFT modules, the SMA
 mlib branch seems to need the Matlab Fixed-Point toolbox, which I don't have
 a license for.

 I came across  the following thread in the casper mailing lists about the
 Fixed Point toolbox:

 https://www.mail-archive.com/casper@lists.berkeley.edu/msg04488.html

 Anybody have some ideas on what may be causing the MMCM_ADV error seen above
 or to circumvent the need for  a FP toolbox license?

 Thanks!

 Gopal



 --
 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-09 Thread Gopal Narayanan
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.eduwrote:

 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
  together a spectrometer with the ASIAA chip) when using FFT modules, the
 SMA
  mlib branch seems to need the Matlab Fixed-Point toolbox, which I don't
 have
  a license for.
 
  I came across  the following thread in the casper mailing lists about the
  Fixed Point toolbox:
 
  https://www.mail-archive.com/casper@lists.berkeley.edu/msg04488.html
 
  Anybody have some ideas on what may be causing the MMCM_ADV error seen
 above
  or to circumvent the need for  a FP toolbox license?
 
  Thanks!
 
  Gopal
 
 
 
  --
  Gopal Narayanan  Ph #: (413) 545 0925
  Department of Astronomy  e-mail: go...@astro.umass.edu
  University of Massachusetts  Amherst MA 01003
 




-- 
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-09 Thread Primiani, Rurik
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
  together a spectrometer with the ASIAA chip) when using FFT modules, the
  SMA
  mlib branch seems to need the Matlab Fixed-Point toolbox, which I don't
  have
  a license for.
 
  I came across  the following thread in the casper mailing lists about
  the
  Fixed Point toolbox:
 
  https://www.mail-archive.com/casper@lists.berkeley.edu/msg04488.html
 
  Anybody have some ideas on what may be causing the MMCM_ADV error seen
  above
  or to circumvent the need for  a FP toolbox license?
 
  Thanks!
 
  Gopal
 
 
 
  --
  Gopal Narayanan  Ph #: (413) 545 0925
  Department of Astronomy  e-mail: go...@astro.umass.edu
  University of Massachusetts  Amherst MA 01003
 




 --
 Gopal Narayanan  

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

2014-05-09 Thread David MacMahon
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




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

2014-05-09 Thread Primiani, Rurik
Yes, Dave, I think you're right.

I'm unclear why the sys_clk MMCM doesn't just have hard-coded clock
factors. Its input clock never changes and it's always outputting 100
MHz and 200 MHz.

On the other hand, the aux_clk MMCM does seem to have its factors
hard-coded even though aux_clk can be an arbitrary frequency. Am I
missing something?

Side note: why are these clock factors derived in detokenize.m? Surely
there's a more appropriate place to do this?

Best,
Rurik

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




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

2014-05-09 Thread David MacMahon

On May 9, 2014, at 2:26 PM, Primiani, Rurik wrote:

 I'm unclear why the sys_clk MMCM doesn't just have hard-coded clock
 factors. Its input clock never changes and it's always outputting 100
 MHz and 200 MHz.

I think things are a little gray here.  When the user specifies using sys_clk 
for the User IP Clock Source, then I think sys_clk is in fact used and its 
MMCM is configured to output the rate specified in User IP Clock Rate rather 
than a fixed 100 MHz.

 On the other hand, the aux_clk MMCM does seem to have its factors
 hard-coded even though aux_clk can be an arbitrary frequency. Am I
 missing something?

I agree that aux_clk's MMCM usage seems suspect.

 Side note: why are these clock factors derived in detokenize.m? Surely
 there's a more appropriate place to do this?

It does seem like an odd place to do this and I'm sure a more appropriate place 
could be found, but given that it's been there for a long time and it has 
worked there for a long time, I'm not sure I'd want to move it just for 
aesthetics sake.

Dave