Re: [casper] Problem running tutorial 2

[Jack Hickish]

Hi Tom,

This is done. If you pull from
https://github.com/casper-astro/mlib_devel.git you should be good to
go with the tutorials (this is the branch we used at the workshop).

Note that if you're doing a fresh clone you'll have to add back in the
deprecated pcores (see
https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.x_and_Matlab_2012b#Tweaks_to_be_able_to_compile)

The startup proceedure has also changed slightly. After cloning the
repository, rather than editing startsg (which is tracked in git), you
should create a separate file named startsg.local, which contains your
location-specific matlab/xilinx install paths. A sample is given on
the wiki page I linked, but basically you just need a file with three
lines (eg):

export MATLAB_PATH=/opt/MATLAB/R2012b
export XILINX_PATH=/opt/Xilinx/14.7/ISE_DS
export XILINX_PLATFORM=lin64

appropriately set for your install.

Let me know if you have any problems,

Jack




On 11 August 2014 11:20, Geelen, T.F.G. t.f.g.gee...@student.tue.nl wrote:
 Hi Jack,

 Thank you, I'll be waiting for the new push on the repository. Thanks already!

 Groetjes,

 Tom Geelen

 Jack Hickish jackhick...@gmail.com wrote:


 Hi Tom,

 This is a library version issue. I've been useless and haven't yet
 pushed the up-to-date library to the casper-astro repository. I shall
 do this now (though it might take a few minutes for me to download and
 push the correct stuff to github).

 Jack

 On 11 August 2014 10:57, Geelen, T.F.G. t.f.g.gee...@student.tue.nl wrote:
 Hello,

 I am trying to work out how the GBe connection works. I have downloaded 
 tutorial 2 from the casper website and replaced all the erroneous software 
 blocks.
 I am running Matlab R2012b and Xilinx 14.5.

 As soon as I start to compile and he revves the design up to version 14.5 I 
 get a couple of errors immediatly after. Can someone give me a tip as to how 
 to solve this error?

 Kind regards,

 Tom

 Moving all revup related files to 'revup' folder...

 Format revision of project to EDK 14.5 completed
 ERROR:EDK - IPNAME: kat_ten_gb_eth, INSTANCE: tut2_gbe0 - PARAMETER TTL not
found in the MPD -
/home/s070562/Desktop/DOMT/GBE_connection/tut2/XPS_ROACH_base/system.mhs 
 line
417
 ERROR:EDK - IPNAME: kat_ten_gb_eth, INSTANCE: tut2_gbe3 - PARAMETER TTL not
found in the MPD -
/home/s070562/Desktop/DOMT/GBE_connection/tut2/XPS_ROACH_base/system.mhs 
 line
485
 WARNING:EDK - IPNAME: opb_bram_if_cntlr, INSTANCE: 
 tut2_snap_gbe0_tx_bram_lsb -
Superseded core for architecture 'virtex5sx' -
/home/s070562/Desktop/DOMT/GBE_connection/tut2/XPS_ROACH_base/system.mhs 
 line
751
 WARNING:EDK - IPNAME: opb_bram_if_cntlr, INSTANCE: 
 tut2_snap_gbe0_tx_bram_msb -
Superseded core for architecture 'virtex5sx' -
/home/s070562/Desktop/DOMT/GBE_connection/tut2/XPS_ROACH_base/system.mhs 
 line
781
 WARNING:EDK - IPNAME: opb_bram_if_cntlr, INSTANCE: 
 tut2_snap_gbe0_tx_bram_oob -
Superseded core for architecture 'virtex5sx' -
/home/s070562/Desktop/DOMT/GBE_connection/tut2/XPS_ROACH_base/system.mhs 
 line
811
 ERROR:EDK - while loading XMP file

 XPS% Evaluating file run_xps.tcl
 ERROR:EDK - Load a MHS or XMP file first
 Error using gen_xps_files (line 638)
 XPS failed.

Re: [casper] Network Switches

[Jack Hickish]

Hi John,

As Dan said I've tested (to some extent) the SX1012. I just used one
ROACH2 and corner
turned data through 8 x 10GbE ports. It worked well basically up to
line rate, with no CRC errors after a few hours of operation, but only
after

- Jason put me in touch with some Mellanox guys who provided updated firmware
- using branded Mellanox 3m QSFP - 4xSFP cables

Before the upgrade transmissions from the switch to the ROACH2 would
frequently fail.

Of course this may or may not be remotely relevant for the SX1024 :)

Good luck!

J

On 2 September 2014 16:46, Dan Werthimer d...@ssl.berkeley.edu wrote:

 hi john,

 jack hickish tested a mellanox SX1012
 (12x40Gbe, or 48x10Gbe, or mixture),
 when he was visiting berkeley.

 the SX1012 worked beautifully on roach2, after jack upgraded
 the switch firmware.   and it's a great price.  ($6K)

 i think jason has also tested this switch.

 best wishes,

 dan




 On Tue, Sep 2, 2014 at 8:36 AM, John Ford jf...@nrao.edu wrote:

 Hi all.  Has anyone tested the Mellanox SX-1024 series of switches with
 ROACH-2 and 10 and/or 40 gb NICs?

 These switches have 48 10 Gbe ports and 12 40 Gbe ports on them.

 Thanks!

 John

Re: [casper] Network Switches

[Jack Hickish]

Not to steer this conversation too far off track, but does a patch
exist to enable the ethernet CRC check within the 10Gb yellow block?
When I tested the switch I used Dave MacMahon's CRC generator block,
but it would be nice if there was the option to have the 10 gig core
use the UDP crc -- or get rid of the port that pretends that it's
doing this :)

Cheers,
J

On 2 September 2014 17:33, Jason Manley jman...@ska.ac.za wrote:
 The SX1012 and SX1036 definitely use the same ASIC series and both suffer 
 from the PHY link problem. I've got seven of them here, and tested them with 
 20 different ROACH-2 boards. As Jack points out, some links are worse than 
 others and swapping cables and ROACH2 mezzanine cards often sorts the problem 
 out. To be honest, the issue is probably on the ROACH-2 side, as we haven't 
 tuned the PHY's RX parameters. Mellanox claim to have tested and complied to 
 IEEE standards.

 To get around this, Mellanox have a patch for CASPER users, which adjusts 
 the TX drive on the switch so that a bigger signal hits the ROACH2. This 
 fixes all the problems, and the links are then very very reliable. They 
 actually borrowed a ROACH-2 for the purpose of testing and tuning their PHYs. 
 Very kind of them! This tuning was done using their own 3m cables, so you 
 should expect the best performance using those copper links. Another option 
 is to use AOC cables, which are cost-effective and loss-less.

 Lincoln, not to alarm you, but are you actually checking for bit errors on 
 your SX1024 links? I suspect you're just not noticing any faults. Packets 
 don't always get dropped... oftentimes a few bits in the data is just 
 corrupted, and if you're looking at correlator noise, you might not even 
 notice it! ...the RX error line from the 10G core is hard-coded to zero, so 
 if this is what you're watching, you'd never know. Likewise the 
 ROACH2-switch links work fine, it's only the switch-ROACH2 direction that's 
 problematic, so you'd never see the error counters on the switch climbing. We 
 (SKA-SA) add checksums to our packets to be sure. Mostly, we were seeing BER 
 numbers like 10e-10 on most of the Mellanox kit out-the-box, but a few links 
 had bad links with BER ~10E-6. After patching, it's better than 10e-13.

 Jason Manley
 CBF Manager
 SKA-SA

 Cell: +27 82 662 7726
 Work: +27 21 506 7300

 On 02 Sep 2014, at 18:01, Lincoln Greenhill lgreenh...@cfa.harvard.edu 
 wrote:

 Hi Jack (and John),

 Interesting report.  Difficult to puzzle out
 differences in our mutual experience unless the
 1012 is unlike the 1024 in subtle ways.

 We (LEDA) did not require an upgrade or Mellanox cables
 for the 10/40GbE links.  Again - I would look
 forward to discussion people may have with Jonathon
 (Cc me if not conducted via the Casper list).

 Best,
 Lincoln

 On 9/2/14, 11:54 AM, Jack Hickish wrote:
 Hi John,

 As Dan said I've tested (to some extent) the SX1012. I just used one
 ROACH2 and corner
 turned data through 8 x 10GbE ports. It worked well basically up to
 line rate, with no CRC errors after a few hours of operation, but only
 after

 - Jason put me in touch with some Mellanox guys who provided updated 
 firmware
 - using branded Mellanox 3m QSFP - 4xSFP cables

 Before the upgrade transmissions from the switch to the ROACH2 would
 frequently fail.

 Of course this may or may not be remotely relevant for the SX1024 :)

 Good luck!

 J

 On 2 September 2014 16:46, Dan Werthimer d...@ssl.berkeley.edu wrote:

 hi john,

 jack hickish tested a mellanox SX1012
 (12x40Gbe, or 48x10Gbe, or mixture),
 when he was visiting berkeley.

 the SX1012 worked beautifully on roach2, after jack upgraded
 the switch firmware.   and it's a great price.  ($6K)

 i think jason has also tested this switch.

 best wishes,

 dan




 On Tue, Sep 2, 2014 at 8:36 AM, John Ford jf...@nrao.edu wrote:

 Hi all.  Has anyone tested the Mellanox SX-1024 series of switches with
 ROACH-2 and 10 and/or 40 gb NICs?

 These switches have 48 10 Gbe ports and 12 40 Gbe ports on them.

 Thanks!

 John






 --
 Lincoln J. Greenhill   Harvard-Smithsonian CfA
 Office: 1 617-495-7194 60 Garden St, Mail Stop 42
 Cell:   1 650 722-7798 Cambridge, MA 02138
 FAX:1 617-495-7345 greenh...@cfa.harvard.edu
 Skype:  ljgreenhillwww.cfa.harvard.edu/~lincoln

Re: [casper] Spectrometer ASIAA ADC

[Jack Hickish]

Hi Katty,

We've already spoken about this, but I thought I'd reply to the maillist in
case others with the same problem land here -- I've had this problem once
before, after checking the potential things Dave mentioned, I tried
restarting Matlab and the problem disappeared. Not really a solution, but I
haven't had the issue since.

Jack
On 12 Sep 2014 18:19, David MacMahon dav...@astro.berkeley.edu wrote:

 Hi, Katty,

 It looks like something is going wrong accessing the filesystem.  Maybe
 it's because of the ñ (n with a tilde over it) character in the path?
 Maybe the path is just too long?  Is the filesystem full?  Is there a
 permissions problem?

 Hope this helps,
 Dave

 On Sep 10, 2014, at 12:54 PM, katherine viviana cortes urbina wrote:

  com.xilinx.sysgen.netlist.NetlistInternal:
 java.io.FileNotFoundException:
 /home/ROACH/Desktop/compilaciones/Diseño-Espectrometro/ross/ccat_spectro_lowbitsk/sysgen/synopsis
 (No such file or directory)

Re: [casper] errors of casper_xps on tut3

[Jack Hickish]

Hi,

If you look in the opb_v20 mpd file --
https://github.com/jack-h/mlib_devel/blob/master/xps_base/XPS_ROACH2_base/pcores/opb_v20_v1_10_c/data/opb_v20_v2_1_0.mpd
-- you should see an option OPTION ARCH_SUPPORT_MAP which defines
the FPGA types supported by the core.
If you add virtex6sx=available to this option you should be able to
progress with the compile. Where did you get your pcores from? (I
thought I had fixed this in the file linked from the casper wiki).

Cheers,
Jack

On 23 October 2014 13:15, Wang Jinqing jqw...@shao.ac.cn wrote:
 Hi

 I have download the old pcore version,the previous problem seems resolved.
 But another problem appear as below.
 Because the FPGA on my roach board is virtex6sx,but EDK says ERROR:EDK -
 IPNAME: opb_v20, INSTANCE: opb0 - not supported for architecture
 virtex6sx.How can I do?


 Format revision of project to EDK 14.3 completed
 ERROR:EDK - IPNAME: opb_v20, INSTANCE: opb0 - not supported for architecture
'virtex6sx' -
/opt/mlib_devel-master-backup1020/tut3/XPS_ROACH2_base/system.mhs line
 119
 WARNING:EDK - IPNAME: opb_bram_if_cntlr, INSTANCE: tut3_even - Superseded
 core
for architecture 'virtex6sx' -
/opt/mlib_devel-master-backup1020/tut3/XPS_ROACH2_base/system.mhs line
 281
 WARNING:EDK - IPNAME: opb_bram_if_cntlr, INSTANCE: tut3_odd - Superseded
 core
for architecture 'virtex6sx' -
/opt/mlib_devel-master-backup1020/tut3/XPS_ROACH2_base/system.mhs line
 472
 ERROR:EDK - while loading XMP file

 -原始邮件-
 发件人: Wang Jinqing jqw...@shao.ac.cn
 发送时间: 2014年10月23日 星期四
 收件人: casper@lists.berkeley.edu
 抄送:
 主题: errors of casper_xps on tut3

 Hi:

 I have run the casper_xps to synthesize tut3.mdl. At begining it seems well.
 But at last the system generator pop out such error informations as below,
 the main problem is cannot find MPD for  the pcore.  Does anyone run into
 such problems?How can I fix this problem?

  The model I used see the appendix.

 Best Regards.
 Oliver Wang


 Moving all revup related files to 'revup' folder...

 Format revision of project to EDK 14.3 completed
 ERROR:EDK - IPNAME: opb_bram_if_cntlr, INSTANCE: tut3_even - cannot find MPD
 for
the pcore 'opb_bram_if_cntlr_v1_00_a' in any of the repositories -
/opt/mlib_devel-master-backup1020/tut3/XPS_ROACH2_base/system.mhs line
 281
 ERROR:EDK - IPNAME: opb_v20, INSTANCE: opb0 - cannot find MPD for the pcore
'opb_v20_v1_10_c' in any of the repositories -
/opt/mlib_devel-master-backup1020/tut3/XPS_ROACH2_base/system.mhs line
 119
 ERROR:EDK - IPNAME: opb_bram_if_cntlr, INSTANCE: tut3_even - cannot find MPD
 for
the pcore 'opb_bram_if_cntlr_v1_00_a' in any of the repositories -
/opt/mlib_devel-master-backup1020/tut3/XPS_ROACH2_base/system.mhs line
 281
 ERROR:EDK - IPNAME: opb_bram_if_cntlr, INSTANCE: tut3_odd - cannot find MPD
 for
the pcore 'opb_bram_if_cntlr_v1_00_a' in any of the repositories -
/opt/mlib_devel-master-backup1020/tut3/XPS_ROACH2_base/system.mhs line
 472
 ERROR:EDK - IPNAME: opb_v20, INSTANCE: opb0 - cannot find MPD for the pcore
 -
/opt/mlib_devel-master-backup1020/tut3/XPS_ROACH2_base/system.mhs line
 119
 ERROR:EDK - IPNAME: opb_bram_if_cntlr, INSTANCE: tut3_even - cannot find MPD
 for
the pcore -
 /opt/mlib_devel-master-backup1020/tut3/XPS_ROACH2_base/system.mhs
line 281
 ERROR:EDK - IPNAME: opb_bram_if_cntlr, INSTANCE: tut3_odd - cannot find MPD
 for
the pcore -
 /opt/mlib_devel-master-backup1020/tut3/XPS_ROACH2_base/system.mhs
line 472
 ERROR:EDK - while loading XMP file

 XPS% Evaluating file run_xps.tcl
 ERROR:EDK - Load a MHS or XMP file first
 Error using gen_xps_files (line 685)
 XPS failed.

Re: [casper] QDR error

[Jack Hickish]

Hi Raul,

Few questions --

Which mlib_devel repository are you using?
Which board are you compiling for?
What are you clocking your design from (what have you set the MSSGE
block clock source to, and do you have the corresponding blocks in
your model if you've selected an ADC?)

Cheers,
Jack

On 23 October 2014 13:47, Raul Sapunar Opazo rasapu...@gmail.com wrote:
 Hello everyone,

 I'm trying to compile a corner turner spectrometer using a QDR.. but I get
 the following error in the compilation that I've not been able to fix:

 ERROR:EDK:4072 - INSTANCE: qdr0_controller, PORT: clk180 - port is driven by
 a
sourceless connector -

 /home/roach/Desktop/Raul/workspace/tut5_megachannel_spec/rmspec_roach1_b/XPS_
ROACH_base/system.mhs line 393
 ERROR:EDK:4072 - INSTANCE: qdr0_controller, PORT: clk270 - port is driven by
 a
sourceless connector -

 /home/roach/Desktop/Raul/workspace/tut5_megachannel_spec/rmspec_roach1_b/XPS_
ROACH_base/system.mhs line 393


 Any ideas of how to fix it?

 Best regards,

 Raul

Re: [casper] QDR error

[Jack Hickish]

Hi Raul,

It looks to me (you could confirm this by grepping your way through
XPS_ROACH_base/system.mhs) like that adc interface doesn't bother to
provide 180 and 270 degree clocks to the rest of the design, which the
QDR relies upon. The .m file which instantiates the interface suggests
that a newer (ip_version = 1.01.a) version of the interface exists
somewhere which does output these signals, but I don't have that
version in my repository (maybe someone, somewhere does?).

To get the QDR working with the existing ADC interface you'd need to
modify the adc's hdl code (and matlab wrappers of it) to add these
signals. In theory, that shouldn't be too difficult.

If you want a hand trying to get this working let me know and I'll see
if I can help do it sometime tomorrow.

Cheers,
Jack

On 23 October 2014 15:48, Raul Sapunar Opazo rasapu...@gmail.com wrote:
 Hi Jack,

 Which mlib_devel repository are you using?

 I'm using mlib_devel a8c43a8 , from git://github.com/ska-sa/mlib_devel.git .


 Which board are you compiling for?

 I'm compiling for ROACH 1.


 What are you clocking your design from (what have you set the MSSGE block
 clock source to, and do you have the corresponding blocks in
 your model if you've selected an ADC?)

 I'm using the ADC 'adc08300' un ZDOK0. I'm actually trying to recompile the
 design of the old tutorial million channel spectrometer (

 https://casper.berkeley.edu/wiki/Old_Tutorials#High_resolution_spectrometer)


 Best Regards,

 Raul

 2014-10-23 10:27 GMT-03:00 Jack Hickish jackhick...@gmail.com:

 Hi Raul,

 Few questions --

 Which mlib_devel repository are you using?
 Which board are you compiling for?
 What are you clocking your design from (what have you set the MSSGE
 block clock source to, and do you have the corresponding blocks in
 your model if you've selected an ADC?)

 Cheers,
 Jack

 On 23 October 2014 13:47, Raul Sapunar Opazo rasapu...@gmail.com wrote:
  Hello everyone,
 
  I'm trying to compile a corner turner spectrometer using a QDR.. but I
  get
  the following error in the compilation that I've not been able to fix:
 
  ERROR:EDK:4072 - INSTANCE: qdr0_controller, PORT: clk180 - port is
  driven by
  a
 sourceless connector -
 
 
  /home/roach/Desktop/Raul/workspace/tut5_megachannel_spec/rmspec_roach1_b/XPS_
 ROACH_base/system.mhs line 393
  ERROR:EDK:4072 - INSTANCE: qdr0_controller, PORT: clk270 - port is
  driven by
  a
 sourceless connector -
 
 
  /home/roach/Desktop/Raul/workspace/tut5_megachannel_spec/rmspec_roach1_b/XPS_
 ROACH_base/system.mhs line 393
 
 
  Any ideas of how to fix it?
 
  Best regards,
 
  Raul

Re: [casper] OS for development: Ubuntu 14.04?

[Jack Hickish]

Hi Adam,

I'm using Ubuntu 14.04 and things seem to work as they should, as long
as you follow the instructions on that wiki page. Though not used by
the toolflow, Vivado 2014.3 officially supports ubuntu 14.04, if
that's a concern to you.

Having said that, I think if I were to go through the setup process
again, on a machine that wasn't my everyday desktop, I'd probably go
for one of the free RedHat like distros like CentOS, just to try and
minimize unforseen headaches (I've occasionally had ubuntu updates
break things, but no more seriously than going back and redoing some
of the steps in the wiki).

Good luck!
Jack


On 27 October 2014 14:17, Schoenwald, Adam (GSFC-5640)[GSFC -  HIGHER
EDUCATION] adam.schoenw...@nasa.gov wrote:
 Hi everyone,

 I’m just getting started with a roach2 board and am about to
 set up a development station. So far I have been using windows 7 and
 encountering issues. A new computer will be coming in soon, but has Ubuntu
 14.04 LTS on it. Has anyone had any issues with this? Should I be planning
 to wipe it and install 12.04, or are the compatibility issues minimal and
 easily resolved?



 My plan was to just follow the instructions at
 https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.x_and_Matlab_2012b
 but then I saw there were some problems with 13.03
 (http://www.mail-archive.com/casper%40lists.berkeley.edu/msg04260.html).



 Any input here would be helpful,



 Thanks,

 Adam Schoenwald

Re: [casper] Problem about the adc frequency in PAPER model.

[Jack Hickish]

Hi Richard,

I've just had a very brief look at the design / software, so take this
email with a pinch of salt, but on the off-chance you haven't checked
this

It looks like the PAPER F-engine setup on running the start script for
software / firmware out of the box is --

1. Disable all ethernet interfaces
2. Arm sync generator, wait 1 second for PPS
3. Reset ethernet interfaces
4. Enable interfaces.

These four steps seem like they should be safe, yet the behaviour
you're describing sounds like the design is midway sending a packet,
then gets a sync, gives up sending an end-of-frame and starts sending
a new packet, at which point the old packet + the new packet =
overflow.

Knowing that the design works for paper, my wondering is whether after
arming the sync generator syncs are flowing through the design before
the ethernet interface is enabled. Do you have a PPS-like input? the
fengine initialisation script seems to wait for a second after arming,
but if your sync input is something significantly slower, you could
have problems.

I'm sceptical about this theory (I think the symptoms would be lots of
OK packets when you brought up the interface, and then it dying when
the sync arrives, rather than a single good packet like you're
seeing), but if the firmware + software really is the same as that
working with paper, and the wiki hasn't just got out of sync with the
paper devs, perhaps the problem is in your hardware setup

Cheers,
Jack

On 27 October 2014 16:38, Richard Black aeldstes...@gmail.com wrote:
 By enable port, I assume you mean the valid port. I've been looking at
 the PAPER model carefully for some time now, and that is how it operates. It
 has a gated valid signal with a software register on each 10-GbE core.

 Once again, this is not our model. This is one made available on the CASPER
 wiki and run without modifications.

 Richard Black

 On Mon, Oct 27, 2014 at 10:34 AM, Jason Manley jman...@ska.ac.za wrote:

 I suspect the 10GbE core's input FIFO is overflowing on startup. One key
 thing with this core is to the ensure that your design keeps the enable port
 held low until the core's been configured. The core becomes unusable once
 the TX FIFO overflows. This has been a long-standing bug (my emails trace
 back to 2009) but it's so easy to work around that I don't think anyone's
 bothered looking into fixing it.

 Jason Manley
 CBF Manager
 SKA-SA

 Cell: +27 82 662 7726
 Work: +27 21 506 7300

 On 27 Oct 2014, at 18:25, Richard Black aeldstes...@gmail.com wrote:

  Jason,
 
  Thanks for your comments. While I agree that changing the ADC frequency
  mid-operation is non-kosher and could result in uncertain behavior, the
  issue at hand for us is to figure out what is going on with the PAPER model
  that has been published on the CASPER wiki. This naturally won't be (and
  shouldn't be) the end-all solution to this problem.
 
  This is a reportedly fully-functional model that shouldn't require any
  major changes in order to operate. However, this has clearly not been the
  case in at least two independent situations (us and Peter). This begs the
  question: what's so different about our use of PAPER?
 
  We, at BYU, have made painstakingly sure that our IP addressing schemes,
  switch ports, and scripts are all configured correctly (thanks to David
  MacMahon for that, btw), but we still have hit the proverbial brick wall of
  10-GbE overflow.  When I last corresponded with David, he explained that he
  remembers having a similar issue before, but can't recall exactly what the
  problem was.
 
  In any case, the fact that by turning down the ADC clock prior to
  start-up prevents the 10-GbE core from overflowing is a major lead for us 
  at
  BYU (we've been spinning our wheels on this issue for several months now).
  By no means are we proposing mid-run ADC clock modifications, but this
  appears to be a very subtle (and quite sinister, in my opinion) bug.
 
  Any thoughts as to what might be going on?
 
  Richard Black
 
  On Mon, Oct 27, 2014 at 2:41 AM, Jason Manley jman...@ska.ac.za wrote:
  Just a note that I don't recommend you adjust FPGA clock frequencies
  while it's operating. In theory, you should do a global reset in case the
  PLL/DLLs lose lock during clock transitions, in which case the logic could
  be in a uncertain state. But the Sysgen flow just does a single POR.
 
  A better solution might be to keep the 10GbE cores turned off (enable
  line pulled low) on initialisation, until things are configured (tgtap
  started etc), and only then enable the transmission using a SW register.
 
  Jason Manley
  CBF Manager
  SKA-SA
 
  Cell: +27 82 662 7726
  Work: +27 21 506 7300
 
  On 25 Oct 2014, at 10:34, peter peterniu...@163.com wrote:
 
   Hi Richard,Joe, all,
   Thanks for your help,It finally can receive packets now!
   As you point,After enabled the ADC card and run bof file(./adc_init.rb
   roach1 bof file)in 200 Mhz (or higher than it), We need run init 

Re: [casper] Problem about the adc frequency in PAPER model.

[Jack Hickish]

Hi Richard,

That's my theory, though I doubt it's right. But as you say, an easy
test is just to delay after issuing a sync for a couple more seconds
and see if that helps. But if your PPS is a real PPS (rather than just
a square wave at some vague 1s period) then I can't see what
difference this would make.
When that doesn't help, my inclination would be to start prodding the
10gbe control signals from software to make sure the reset / sw
enables are working / see if a tge reset without a new sync behaves
differently. But I can't imagine how that would be broken unless the
stuff on github is out of date (which I doubt).

Jack

On 27 October 2014 17:28, Richard Black aeldstes...@gmail.com wrote:
 Jack,

 I appreciate your help. I tend to agree that the issue is likely a hardware
 configuration problem, but we have been trying to match it as closely as
 possible.

 We do feed a 1-PPS signal into the board, but I'm hazy on the details of the
 other pulse parameters. I'll look into that as well.

 So, if I understand you correctly, you believe that the sync pulse is
 reaching the ethernet interfaces after the cores are enabled? If that is the
 case, couldn't we delay enabling the 10-GbE cores for another second to fix
 it? This might be a quick way to test that theory, but please correct me if
 I've misunderstood.

 Richard Black

 On Mon, Oct 27, 2014 at 11:05 AM, Jack Hickish jackhick...@gmail.com
 wrote:

 Hi Richard,

 I've just had a very brief look at the design / software, so take this
 email with a pinch of salt, but on the off-chance you haven't checked
 this

 It looks like the PAPER F-engine setup on running the start script for
 software / firmware out of the box is --

 1. Disable all ethernet interfaces
 2. Arm sync generator, wait 1 second for PPS
 3. Reset ethernet interfaces
 4. Enable interfaces.

 These four steps seem like they should be safe, yet the behaviour
 you're describing sounds like the design is midway sending a packet,
 then gets a sync, gives up sending an end-of-frame and starts sending
 a new packet, at which point the old packet + the new packet =
 overflow.

 Knowing that the design works for paper, my wondering is whether after
 arming the sync generator syncs are flowing through the design before
 the ethernet interface is enabled. Do you have a PPS-like input? the
 fengine initialisation script seems to wait for a second after arming,
 but if your sync input is something significantly slower, you could
 have problems.

 I'm sceptical about this theory (I think the symptoms would be lots of
 OK packets when you brought up the interface, and then it dying when
 the sync arrives, rather than a single good packet like you're
 seeing), but if the firmware + software really is the same as that
 working with paper, and the wiki hasn't just got out of sync with the
 paper devs, perhaps the problem is in your hardware setup

 Cheers,
 Jack

 On 27 October 2014 16:38, Richard Black aeldstes...@gmail.com wrote:
  By enable port, I assume you mean the valid port. I've been looking
  at
  the PAPER model carefully for some time now, and that is how it
  operates. It
  has a gated valid signal with a software register on each 10-GbE core.
 
  Once again, this is not our model. This is one made available on the
  CASPER
  wiki and run without modifications.
 
  Richard Black
 
  On Mon, Oct 27, 2014 at 10:34 AM, Jason Manley jman...@ska.ac.za
  wrote:
 
  I suspect the 10GbE core's input FIFO is overflowing on startup. One
  key
  thing with this core is to the ensure that your design keeps the enable
  port
  held low until the core's been configured. The core becomes unusable
  once
  the TX FIFO overflows. This has been a long-standing bug (my emails
  trace
  back to 2009) but it's so easy to work around that I don't think
  anyone's
  bothered looking into fixing it.
 
  Jason Manley
  CBF Manager
  SKA-SA
 
  Cell: +27 82 662 7726
  Work: +27 21 506 7300
 
  On 27 Oct 2014, at 18:25, Richard Black aeldstes...@gmail.com wrote:
 
   Jason,
  
   Thanks for your comments. While I agree that changing the ADC
   frequency
   mid-operation is non-kosher and could result in uncertain behavior,
   the
   issue at hand for us is to figure out what is going on with the PAPER
   model
   that has been published on the CASPER wiki. This naturally won't be
   (and
   shouldn't be) the end-all solution to this problem.
  
   This is a reportedly fully-functional model that shouldn't require
   any
   major changes in order to operate. However, this has clearly not been
   the
   case in at least two independent situations (us and Peter). This begs
   the
   question: what's so different about our use of PAPER?
  
   We, at BYU, have made painstakingly sure that our IP addressing
   schemes,
   switch ports, and scripts are all configured correctly (thanks to
   David
   MacMahon for that, btw), but we still have hit the proverbial brick
   wall of
   10-GbE overflow.  When I last

Re: [casper] spectrometer implementation using LX110T instead of SX95T

[Jack Hickish]

Hi louis,

I've just checked the spec sheet - 64 multipliers!! I'm guessing you ran
out of slices when you (or maybe the compiler) pushed lots of multipliers
into logic? (the lx has more slices than the sx)
Maybe send around your utilisation summary tomorrow - it sounds like you
might need to find some pretty substantial savings from somewhere.

A few things which might help save logic:
- hard code the fft shift schedule
- lower the number of fft bits, or use bit growth
- if the fft uses pipelined convert cores for rounding, using a cheap
rounding strategy with low latency should help.
- combine fir filters in a single block which shares logic (if you haven't
already), same with the fft.

But you might be better off finding a different roach :)

Jack
 On 28 Oct 2014 00:37, Louis Dartez louisdar...@gmail.com wrote:

 Hi Dan,
 Slices is what seems to be problem from the error report (which I can send
 around tomorrow morning when I’m back in the lab). I seem to remember that
 that the compiler raised an error stating that I was trying to ~80k slices
 when only ~60k are available. I knew this would be a slippery slope when I
 started. But it would be great if we could salvage our LX110T.

 Any chance someone out there has a ROACHI SX95T that’s just collecting
 dust?
 L

 Louis P. Dartez

 Graduate Research Assistant

 STARGATE

 Center for Advanced Radio Astronomy

 University of Texas Rio Grande Valley

 (956) 372-5812


 On Oct 27, 2014, at 7:31 PM, Dan Werthimer d...@ssl.berkeley.edu wrote:

 hi louis,

 are you running out of memory?   dsp48's?  slices?

 if memory, the easiest thing to do is cut back on
 number of frequency channels.

 best,

 dan


 On Mon, Oct 27, 2014 at 4:59 PM, Louis Dartez louisdar...@gmail.com
 wrote:

 Hi all,

 I have implemented a 4 channel 200MHz correlating spectrometer on a ROACH 1
 using the Virtex5 SX95T. Currently, I am trying to get this same design to
 compile and run on a LX110T chip instead. I know that the SX95T is much
 more
 DSP intensive and more suitable for this sort of thing. During compilation
 for the LX110T I ran into the expected issues with resources and trying to
 use more than were available on the LX110T. I was wondering if anyone had
 any tips/advice on how to go about this? Has anyone out there run into
 similar situations? What knobs should I be able to tweak to get the design
 to compile for a LX110T? Is it even possible?

 I’d be more than happy to share my mdl (slx) files if needed. :)

 Thanks in advance!
 L

 Louis P. Dartez

 Graduate Research Assistant

 STARGATE

 Center for Advanced Radio Astronomy

 University of Texas at Brownsville

 (956) 372-5812

Re: [casper] spectrometer implementation using LX110T instead of SX95T

[Jack Hickish]

Hi Louis,

You can grab the report from the terminal, but it's also at the top of
the map report file, at
compile-directory/XPS_ROACH_base/implementation/system_map.mrp

Cheers,
Jack

On 29 October 2014 03:31, Louis Dartez louisdar...@gmail.com wrote:
 Hi Dan,
 I cut the number of frequency channels from 2k to 512 this afternoon. When I
 left the lab the design was still compiling so I won’t know how it fared
 until morning. I forgot to grab the resource utilization to post here.
 What’s the best way to get the utilization report anyway? Should I just cut
 it from the xps output in the terminal?

 I haven’t tried changing the number of PFB taps yet. It’s currently set to 4
 in my design.

 The model I use now utilizes a single PFB block and a single FFT block, both
 configured for four simultaneous inputs.

 L

 Louis P. Dartez

 Graduate Research Assistant

 STARGATE

 Center for Advanced Radio Astronomy

 University of Texas Rio Grande Valley

 (956) 372-5812


 On Oct 28, 2014, at 10:26 PM, Dan Werthimer d...@ssl.berkeley.edu wrote:

 can you cut back the number of frequency channels?
 or the number of PFB FIR taps?
 or do away with the PFB FIR entirely?

 best wishes,

 dan


 On Mon, Oct 27, 2014 at 5:36 PM, Louis Dartez louisdar...@gmail.com wrote:

 Hi Dan,
 Slices is what seems to be problem from the error report (which I can send
 around tomorrow morning when I’m back in the lab). I seem to remember that
 that the compiler raised an error stating that I was trying to ~80k slices
 when only ~60k are available. I knew this would be a slippery slope when I
 started. But it would be great if we could salvage our LX110T.

 Any chance someone out there has a ROACHI SX95T that’s just collecting dust?
 L

 Louis P. Dartez

 Graduate Research Assistant

 STARGATE

 Center for Advanced Radio Astronomy

 University of Texas Rio Grande Valley

 (956) 372-5812


 On Oct 27, 2014, at 7:31 PM, Dan Werthimer d...@ssl.berkeley.edu wrote:

 hi louis,

 are you running out of memory?   dsp48's?  slices?

 if memory, the easiest thing to do is cut back on
 number of frequency channels.

 best,

 dan


 On Mon, Oct 27, 2014 at 4:59 PM, Louis Dartez louisdar...@gmail.com wrote:

 Hi all,

 I have implemented a 4 channel 200MHz correlating spectrometer on a ROACH 1
 using the Virtex5 SX95T. Currently, I am trying to get this same design to
 compile and run on a LX110T chip instead. I know that the SX95T is much more
 DSP intensive and more suitable for this sort of thing. During compilation
 for the LX110T I ran into the expected issues with resources and trying to
 use more than were available on the LX110T. I was wondering if anyone had
 any tips/advice on how to go about this? Has anyone out there run into
 similar situations? What knobs should I be able to tweak to get the design
 to compile for a LX110T? Is it even possible?

 I’d be more than happy to share my mdl (slx) files if needed. :)

 Thanks in advance!
 L

 Louis P. Dartez

 Graduate Research Assistant

 STARGATE

 Center for Advanced Radio Astronomy

 University of Texas at Brownsville

 (956) 372-5812

Re: [casper] Starburst, an open-source 10gsps low-N correlator for ROACH2

[Jack Hickish]

Hey Ryan,

This sounds great. I've just got a 312mhz design for a project in Cambridge
to meet timing (broadly similar to what you're describing, but 10 single
pol antennas and only 4k channels over 5ghz bw).
Whilst I don't have any particular requests, I would be very interested in
hearing about how you end up reaching 375mhz. (What granularity you place
pblocks/cunning code optimisations/etc). I found my experience to be
educational, if a bit frustrating, and I'd be interested to know the gritty
details used by others (equally, if anyone cares, I'm very happy to talk
about my tactics). I certainly found that a vague high-level placement of
pblocks with the standard mlibdevel libraries didn't work as well as I was
hoping.

Cheers,
Jack

On 29 Oct 2014 22:26, Ryan Monroe ryan.m.mon...@gmail.com wrote:

 Hey guys,

 The CASPER community has been a great help to me in the past few years.
 People have asked for my libraries and due to JPL policy, I've always had
 to turn them away.  Thanks to help from Bob Jarnot, Jonathon Kocz and
 others, I'm now free to open-source some of my designs/libraries.

 For my PhD, I'm designing a 10gsps correlator.  I'd really like for this
 to be an extremely versatile design, useful for radioastronomy and
 earth-observing-science, good for all broadband, low-N applications.  *If
 there are any special features you'd like to see in this design, beyond
 what is listed below, tell me now!*  I'm willing to add it, but I have to
 know before everything is finished up.

 Stats are:

 (note: N bits complex means N bits for each of real and imag)

 Mode A:
 Dual-polarization full-stokes,
 2.5 GHz per pol
 8192-channel (per pol)
 8-tap hamming PFB

 Mode B:
 I/Q separating spectrometer
 5 GHz total bandwidth
 16384 channels across entire band
 8-tap hamming PFB

 Features common to both:
 Time-domain delay tracking (sample resolution; 48k-sample range)
 Frequency domain delay tracking (linear interpolation, set two registers
 to update)
 Bandpass calibration (applied before I/Q separation): unique 16 bit
 complex gain applied to each signal= sideband rejection much greater than
 ADC SNR
 10GBE full-duty cycle dump rate (4bits complex per sample)
 1GBE accumulation dumps.  accumulations supported [10ms - 100s for
 spectrometer only]; [10ms - 1s for correlator]
 Everything is synchronized off 1pps and the end of an FFT.
 Triggered accumulations via GPIO, software register or 1pps (accumulations
 can be one-off or continuous)

 In addition, the design will include a X-engine correlator (2 antennas,
 each 2-pol).  The corner turn is performed simply by wiring 10gbe cables.
 The design can be used as a spectrometer though.  The design requires an
 FPGA clock rate of 312.5 MHz, but I'm going to try for 375 MHz so that we
 can overclock if we want to (or if we get better ADCs later)

 I really want to make this a versatile, general purpose, broadband,
 spectrometer/low-N correlator.

 Features I could add if people want:

 DDR circular buffer (4bits of each adc sample, 1.6s of buffer@16 GB of
 ram) [requested by tom kuiper/majin walid]
 Larger x-engine (4 dual-pol antennas for charity, I could do 8 but it
 would be lots of work so we'll have to talk in that case)
 ADC core matching (if my old firmware for this still works!)
 *your feature request here*


 I look forward to your input!  As a friendly reminder, my track record for
 designing FPGA firmware is extremely good, but this might not all pan out
 as expected.  I'm making no promises quite yet.

 Timeline is currently to have simulated firmware which meets timing at
 312.5 MHz (equals 5 GHz total bandwidth) by dec1.  Fingers crossed!


 --Ryan

Re: [casper] wide_band_real fft simulation problem of tut3

[Jack Hickish]

Can I add to this - do you simulate a sync pulse input, and wait an
adequate time to see it show up on the block output?

Jack
On 2 Nov 2014 12:50, G Jones glenn.calt...@gmail.com wrote:

 When you are simulating, do you have the fftshift set appropriately? A
 pure sine wave will be the worst case for bit growth and overflow, so
 you'll want an fftshift of 0x I think.
 On Nov 2, 2014 2:11 AM, Wang Jinqing jqw...@shao.ac.cn wrote:

 Hi,

 I can run the tut3.mdl,but I found the simulation result of  wide_band
 fft is not correct. For example I have generate a sine (freq= 1/4pi)wave
 input the KaADC ,I found the polyphase output sine wave is still ok on the
 scope,  but after the wide_band_real fft ( after real and image parts
 seperation) and power I even can't find the corresponding spectrum line.
 There're many messy signals on the spectrum. It seems that the fft core not
 works well in simulation. Does someone run into this problem?

 Best Regards.

 Oliver Wang.

[casper] ROACH2 power on boot

[Jack Hickish]

Howdy Casperites,

Maybe my searching ability has failed me, but surprisingly I couldn't find
this in the mail archive --

What does one have to do to get a ROACH2 to boot immediately when power is
applied?

Thanks, and happy Thanksgiving to those celebrating such a thing,

Jack

Re: [casper] ROACH2 power on boot

[Jack Hickish]

Sigh.

Thanks!

On Fri Nov 28 2014 at 16:34:11 John Ford jf...@nrao.edu wrote:

 I think this is the thread you seek.   Your searching powers are clearly
 compromised by Thanksgiving dinner.

 https://www.mail-archive.com/casper%40lists.berkeley.edu/msg03727.html

 :)

  Howdy Casperites,
 
  Maybe my searching ability has failed me, but surprisingly I couldn't
 find
  this in the mail archive --
 
  What does one have to do to get a ROACH2 to boot immediately when power
 is
  applied?
 
  Thanks, and happy Thanksgiving to those celebrating such a thing,
 
  Jack
 

Re: [casper] NFS setup: TFTP permissions problem

[Jack Hickish]

Hi Michael,

Do you have SELinux running? I've just checked and I get a similar
permissions error if I reactivate SELinux on my Centos 6 server.

On Tue Dec 02 2014 at 14:07:45 Michael D'Cruze 
michael.dcr...@postgrad.manchester.ac.uk wrote:

  Hi everyone


  I'm following the NFS setup guide, and have come across a problem with
 the /srv/roach_boot/boot directory permissions. I restart the dnsmasq
 service and receive the following error:


  Starting dnsmasq:
 dnsmasq: TFTP directory /srv/roach_boot/boot inaccessible: Permission
 denied
[FAILED]


  The output of ls -l from /srv/roach_boot is


  [root@roach-workstation roach_boot]# ls -l
 total 8
 drwxrwxrwx.  2 root root 4096 Dec  1 16:31 boot
 drwxrwxrwx. 23 root root 4096 Feb  2  2009 etch


  and from within /boot is


  [root@roach-workstation boot]# ls -l
 total 1360
 -rwxrwxrwx. 1 michael michael 1390149 Dec  1 15:35
 uImage-20110812-mmcomitfix


  The output of ls --context from within /boot is


  [root@roach-workstation boot]# ls --context
 -rwxrwxrwx. michael michael unconfined_u:object_r:tftpdir_t:s0
 uImage-20110812-mmcomitfix


  All of these permissions and contexts look correct according to the
 guideso I'm at a bit of a loss. Has anyone seen this problem before,
 given all of the above conditions?


  Does the /boot directory have to have the same context as the uImage
 file within it?


  Suggestions or guidance greatly appreciated.


  Michael

[casper] Compiler merging SRLs -- Timing performance

[Jack Hickish]

Hi all,

This is something I've been fighting with for a while now, and I wonder if
anyone on this maillist has any insight (because I'm pretty sure I may just
be doing something wrong with the tools).

The problem:
I'm playing with a ROACH2 design that (sometimes) compiles at 312 MHz.
However, every now and then I'll make a small change to the design and the
compile will fail timing catastrophically, with paths failing sometimes
with -2 ns (or worse) slack.
When I look at the failing path(s), the delays are usually ~80% routing.
I'll see a signal take a huge detour to use a shift register in some
arbitrary location on the chip. Upon closer inspection of the relevant SRL,
it appears that the LUT concerned is being used for two signal paths, one
on the O5 output, one on the O6. The result seems to be that it is poorly
placed for both it's roles.

I'm only using ~50% of the slices and about 30% of the registers / luts on
the FPGA, and there are plenty of sensibly located SLICEMs the placer could
use if it so desired. I've switched lut combining off (with the -lt flag),
in planahead which doesn't seem to have made any difference.

Can anyone offer me any words of advice / wisdom which might reduce my
confusion at what's going on (or, even better, help me solve the problem)?

Despairingly yours,
Jack

Re: [casper] Compiler merging SRLs -- Timing performance

[Jack Hickish]

Hey Mark,

Yeah, I guess I could manually force the locations of the two offending
shift-regs to stop the combination, but the problem SRLs seem to be a
fairly arbitrary selection of those in the design. I don't really want to
have to start constraining at the LUT level if I can help it. But maybe
I'll try and see if the problem goes away, or just emerges somewhere else.

Hi Dave,

I have been through all the planAhead options, as well as the
fast_runtime.opt settings in the base package (I've been using both flows)
and (tried to) set everything to optimize for speed. The -lt option to me
seems like it should control the behaviour I'm seeing, but it doesn't seem
to. I'm using pblocks, but have been almost exclusively been constraining
only rams/dsps. As above, I'm about to try forcing the placements. I
haven't run resynth netlist on my simulink design, but equivalent register
removal is turned off in planAhead and some of the signals it appears to be
LUT-combining belong to different pcores, so I thought that planahead
settings should be enough. (obviously I could be wrong).
In any case, I didn't think this was an equivalent register removal
problem. It's not like multiple copies of the same register are being
merged at the expense of fanout, just a 2-clock data delay inside an
X-engine might be merged with a 2-clock delay of some data signal in an
FFT. But again, maybe I'm understanding the options wrong, so I'll try
resynthing the netlist and see if that helps.

Thanks for your help, both.

Jack



On Thu Dec 04 2014 at 19:18:35 David MacMahon dav...@astro.berkeley.edu
wrote:

 Hi, Jack,

 Are the tools are optimizing for area instead of speed?  Are you using
 Pblocks?

 I don't know if this is relevant to your situation, but I've run into
 annoyances when the tools use equivalent register removal to save a few
 flip-flops but end up causing fan-out/routing issues.  That can be turned
 off, but it's a synthesis option so if you want to apply it to a System
 Generator netlist, you have to use the resynth_netlist Matlab function
 from the casper library to re-synthesize the entire netlist.

 Dave

 On Dec 4, 2014, at 10:48 AM, Jack Hickish wrote:

  Hi all,
 
  This is something I've been fighting with for a while now, and I wonder
 if anyone on this maillist has any insight (because I'm pretty sure I may
 just be doing something wrong with the tools).
 
  The problem:
  I'm playing with a ROACH2 design that (sometimes) compiles at 312 MHz.
 However, every now and then I'll make a small change to the design and the
 compile will fail timing catastrophically, with paths failing sometimes
 with -2 ns (or worse) slack.
  When I look at the failing path(s), the delays are usually ~80% routing.
 I'll see a signal take a huge detour to use a shift register in some
 arbitrary location on the chip. Upon closer inspection of the relevant SRL,
 it appears that the LUT concerned is being used for two signal paths, one
 on the O5 output, one on the O6. The result seems to be that it is poorly
 placed for both it's roles.
 
  I'm only using ~50% of the slices and about 30% of the registers / luts
 on the FPGA, and there are plenty of sensibly located SLICEMs the placer
 could use if it so desired. I've switched lut combining off (with the -lt
 flag), in planahead which doesn't seem to have made any difference.
 
  Can anyone offer me any words of advice / wisdom which might reduce my
 confusion at what's going on (or, even better, help me solve the problem)?
 
  Despairingly yours,
  Jack
 
 

Re: [casper] Compiler merging SRLs -- Timing performance

[Jack Hickish]

Hi Everyone,

Thanks all for the advice. Based on a few experiments so far (skip to
4 for what I think is a disappointinly simple solution, that I was too
stupid to see in the XST manual) --

1. My fabric utilisation isn't that high, although digging around
planAhead there are some areas with high routing congestion. I wonder
how much this throws off the compiler.

2. Making the shift registers that are causing problems implement as
cores, rather than behavioural HDL doesn't seem to solve the problem,
the tools will quite happily combine two such cores into one LUT.

3. Explicitly disabling SRLs (by either putting lots of single delays
as cores / adding resets / (*shreg_extract = NO*)-ing HDL code makes
the problem go away for the individual delay (since now there aren't
any LUTs to combine). But mostly the symptom will just appear
somewhere else. (I haven't tried the nuclear SRL global disable, but
I'd be amazed if that didn't just cause my design to explode).

4. Resynthesizing the netlists with -lc off seems to have made all
the issues I was having disappear. At least in the timing report I've
read the headline spectacular fails have gone. Map reports that there
are still some SRLs using both O5 and O6 outputs, but I've got a bunch
of pcores, and I haven't resynth'd them all yet.
I'm a bit surprised that this option is needed in XST to avoid
combining luts that exist in different pcores, I would have thought
turning it off in map would be sufficient, but I guess I was wrong.
Maybe I would have figured this out sooner if I'd properly read an
up-to-date XST manual -- it appears that the default behaviour of lut
combining in XST has gone from 'off' in Virtex 5, to 'auto' in Virtex
6.

So bottom line, maybe -lc is an option worth playing with in future if
designs are failing timing with bizarre signal paths.

Thanks again for the help (and big shoutout for resynth_netlist, which
I certainly didn't realise was added by Dave 4 YEARS AGO!).

Jack

On 5 December 2014 at 07:01, Jason Manley jman...@ska.ac.za wrote:
 I often re-run XST with:

 register_balancing yes
 optimize_primitives yes
 read_cores yes
 shreg_extract no

 shreg_extract prevents adjacent registers from being combined into SRL16s.

 Jason Manley
 CBF Manager
 SKA-SA

 Cell: +27 82 662 7726
 Work: +27 21 506 7300

 On 05 Dec 2014, at 6:27, Henno Kriel he...@ska.ac.za wrote:

 Hi Jack,

 In Simulink if have seen similar issues when trying to add more register 
 pipelining, to decrease routing delay's and thus increase Fmax.
 However, ISE just collapses all the pipelining into a single SRL, which 
 yields the frustrations you mentioned.
 You can prevent this from happening, by adding a synchronise reset (one of 
 the tick boxes on delay block) to your pipelining registers.
 You will have to connect up a reset signal from a register (but you don't 
 actually need to use it),
 to ensure that it does not get optimized away.
 In my case this normally resolves the routing issue and achieves timing 
 closure.

 Hope this helps.
 HK



 On Thu, Dec 4, 2014 at 9:37 PM, Jack Hickish jackhick...@gmail.com wrote:
 Hey Mark,

 Yeah, I guess I could manually force the locations of the two offending 
 shift-regs to stop the combination, but the problem SRLs seem to be a fairly 
 arbitrary selection of those in the design. I don't really want to have to 
 start constraining at the LUT level if I can help it. But maybe I'll try and 
 see if the problem goes away, or just emerges somewhere else.

 Hi Dave,

 I have been through all the planAhead options, as well as the 
 fast_runtime.opt settings in the base package (I've been using both flows) 
 and (tried to) set everything to optimize for speed. The -lt option to me 
 seems like it should control the behaviour I'm seeing, but it doesn't seem 
 to. I'm using pblocks, but have been almost exclusively been constraining 
 only rams/dsps. As above, I'm about to try forcing the placements. I haven't 
 run resynth netlist on my simulink design, but equivalent register removal 
 is turned off in planAhead and some of the signals it appears to be 
 LUT-combining belong to different pcores, so I thought that planahead 
 settings should be enough. (obviously I could be wrong).
 In any case, I didn't think this was an equivalent register removal problem. 
 It's not like multiple copies of the same register are being merged at the 
 expense of fanout, just a 2-clock data delay inside an X-engine might be 
 merged with a 2-clock delay of some data signal in an FFT. But again, maybe 
 I'm understanding the options wrong, so I'll try resynthing the netlist and 
 see if that helps.

 Thanks for your help, both.

 Jack



 On Thu Dec 04 2014 at 19:18:35 David MacMahon dav...@astro.berkeley.edu 
 wrote:
 Hi, Jack,

 Are the tools are optimizing for area instead of speed?  Are you using 
 Pblocks?

 I don't know if this is relevant to your situation, but I've run into 
 annoyances when the tools use equivalent register removal

Re: [casper] inverse PFB

[Jack Hickish]

Hey Laura,

Have you tried the vanilla complex 'fft' block? If you generate the full
spectra including negative frequencies before inputting (I think there's a
mirror_spectrum block that might do this(?)), I would have thought you
could add two input streams together, as streamA + j*streamB. Since the FFT
of either stream should give you a real output, you'll get the two
independent FFTs in the real and imag outputs of the FFT block.
I'm relatively confident that the complex fft block works -- all the fft's
are pretty much the same under the hood, aside from some data
scrambulation, and I trust Andrew :)
(Caveat: I haven't thought about this for very long, and I'm a little
distracted by the Frozen soundtrack right now, so what I said might be
nonsense).

Jack




On Thu Dec 11 2014 at 14:59:46 Vertatschitsch, Laura E. 
lvertatschit...@cfa.harvard.edu wrote:

 Hi Ryan,

 I have used a method of similar simplicity that involves swapping the real
 and imaginary parts of samples before and after the fft, so a mathematical
 equivalent of multiplying by j after taking the conjugate of the samples.
 For that design I used the fft_direct block and operated only on 32
 incoming parallel samples.

 The issue is more that we aren't sure which fft block to place in that
 algorithm for the case Jonathan describes, or if there is a clever
 algorithm to use another block.  We use the fft_wideband_real to generate
 half of the full fft, so 16k points coming out over many clock cycles.
 This block expects input data that is real and produces output data that is
 complex.  It strikes me that this block will not natively slide into the
 real/imag-swap algorithm.

 We could obviously try and produce the full fft output from the data by
 flipping and concatenation (and find the value at pi?), but we are still
 left with complex data in need of an fft block that will accept it and
 perform a 32k point transform.

 Do others use such a block with success?  It was suggested to me that the
 wideband real block was much more widely used than the other blocks, thus
 it is up to date, tested, and working.

 It would be really neat if there was a dsp trick out there that used the
 wideband_real as an inverse, but we'd like to go with simplest solution
 regardless.

 -Laura



 On Thursday, December 11, 2014, Ryan Monroe ryan.m.mon...@gmail.com
 wrote:

 IIRC, an inverse FFT can be implemented as
 1. Complex conjugate
 2. Fft
 3. Complex conjugate

 Which is mathematically identical iirc to an ifft, if slightly less
 efficient computationally.

 In general, the output will not be real valued of course

 On Tue, Dec 9, 2014, 2:45 PM Jonathan Weintroub 
 jweintr...@cfa.harvard.edu wrote:

 Thanks to Richard and everyone who responded earlier for the comments,
 which in some cases are very detailed. It is good to know we are not the
 only ones worrying about this.  Our DSP group is digesting the material and
 looking at options, and other followup will likely follow.  I  did not want
 to delay thanks and acknowledgment.

 One basic question which did come up is it appears that even an inverse
 FFT would present some challenges.  We stuff the 32k forward FFT with real
 time series data and extract 16k complex frequency domain points.   Might I
 ask if any CASPER folks have experience implementing an inverse FFT
 relevant to this case, as a real time FPGA bit code?

 Thanks again.

 Jonathan Weintroub
 SAO


  On Dec 8, 2014, at 9:50 PM, Richard Shaw jr...@cita.utoronto.ca
 wrote:
 
  Hi,
 
  I thought I'd comment as this is a problem we've been having to deal
  with recently for some VLBI observations. Fortunately we've had some
  success with an offline least-squares inversion of the PFB. This is
  probably not the scheme that you want, as it essentially operates on
  the whole PFB'd timestream at once, so realistically you need a
  cluster to do it. However, there is prototype code available here [1]
  if it's useful.
 
  The rationale for doing this is is that when you look at the whole PFB
  timestream very little information is actually lost (essentially only
  a few samples at the ends), though it may be spread across frequency
  and time samples. For N PFB samples of length M, there are roughly
  2*N*M total numbers measured, which depend on 2*(N+P-1)*M numbers in
  the underlying timestream (where P is the number of taps). As
  typically P  N, there are very few unmeasured linear combinations,
  and so a statistical inversion can be pretty accurate. Fortunately it
  turns out this inversion can also be done pretty efficiently.
 
  The general scheme is this:
 
  1. inverse FFT to generate a pseudo-timestream
  2. the coupling matrix between elements in this pseudo-timestream and
  the real timestream is sparse diagonal, and is trivially calculable
  from the window function
  3. Perform a shuffle on the timstream to turn this into a series of
  band diagonal matrices (bandwidth ~ 2*P)
  4. Use a band diagonal least-squares solve 

Re: [casper] Mkid DAC error

[Jack Hickish]

Hi Matt,

I'll push these into the main casper-astro github.

Cheers
Jack

PS. Anyone else with rogue yellow blocks / cool new features / other stuff
which folk might benefit from, feel free to email me patches or files, or
raise github pull requests. Some of the major mlibdevel forks (like ska-sa)
get pulled in semi-regularly, but I'm sure there's lots of other good stuff
floating around.

On Wed, 17 Dec 2014 01:59 Matt Strader mstra...@physics.ucsb.edu wrote:


 Hi Ross,

The dac_mkid files in the repo aren't the most up to date.  The attached
files should work.  We should have someone with push power update the repo
at some point.

Matt Strader
Mazin Lab
UCSB Physics Dept.

On Tue, Dec 16, 2014 at 5:50 PM, Ross Williamson 
rwilliam...@astro.caltech.edu wrote:

Hi all,

I'm using the dac_mkid from the ska branch of mlib_devel. I get the
following error and I'm stumped.

Error in 'low_freq/dac_mkid1/Subsystem/parallel_to_serial_converter':
Initialization commands cannot be evaluated.

Caused by:
The LinkStatus can be set only for a linked block

The input to sdend is boolean (0) and config10data is 4p0.  Also is
there any documentation for this block?

Ross
--
Ross Williamson
Research Scientist - Sub-mm Group
California Institute of Technology
626-395-2647 (office)
312-504-3051 (Cell)

Re: [casper] Roach2 QDR

[Jack Hickish]

:
  [0,1,2,3,4,5, ... , 1048574, 1048575]
 
  I read it via the CPU:
  nBytesPerSample=8
  struct.unpack('{}Q'.format(nSamples),
  roach.read('qdr0_memory',nSamples*nBytesPerSample))
  and get:
  [132, 232, 332, 432, 532, ..., 104857532, 032]
 
  So reading and writing only by the CPU is consistent, and reading and
  writing only in fabric is consistent, but when I do one by the CPU
 and the
  other in fabric, the two 32 bit words get swapped, and the sequence is
  offset by one value.  I actually see the same offset in a Roach1
 version of
  the design as well.  It all seems consistent, not intermittent.
 
  Thanks,
  Matt
 
 
 
  On Mon, Mar 9, 2015 at 10:42 AM, Jack Hickish jackhick...@gmail.com
 wrote:
 
  Hi Matt,
 
  The qdr_cal routine calibrates the relationship of clock and data
 signals
  in the link between the FPGA and QDR signals. Basically it writes
 test
  patterns and reads them back looking for glitches. It then changes
 the delay
  of IODELAY blocks so that data read from the QDR is captured
 reliably.
  If this calibration script runs successfully, I'm surprised you
 still see
  glitches with 32 bits of data swapped between read and write (both
 from
  PPC). This would (surely?) count as a glitch and cause the
 calibration
  routine to fail(?). Do you only see strange behaviour when you read
 from the
  FPGA fabric, or do straight write/reads from the CPU also misbehave?
 Is the
  behaviour the same on every read / write (i.e., not intermittent)?
 
  My experience with the QDR is that at high clock speeds (not sure how
  high, but I see this at 312 MHz) the read latency of the QDR
 interface isn't
  10 clock cycles as it should be even with the minimum IODELAY
 configuration,
  and there are no reliable qdr_cal solutions. I solved this problem
 for my
  design by removing half a clock cycle latency from the interface, at
 which
  point the QDR would calibrate ok. What speed are you running your
 design at?
  To me, misordered 32-bit chunks of data sounds indicative of a
 latency
  problem in the qdr_cal solution, since the interface is 32 bit DDR,
 so half
  a clock cycle mangles 32-bit chunks of data.
 
  Good luck!
 
  Jack
 
 
 
  On Fri, 6 Mar 2015 at 23:54 Matt Strader mstra...@physics.ucsb.edu
  wrote:
 
  Hi all,
 
  I'm trying to use QDR on Roach2.  I have a test design where I
 write to
  QDR either in firmware or with katcp, then read it out in the
 firmware and
  check the results with snapshot blocks.  It mostly works, but with
 some
  interesting quirks.
 
  I know that katcp can only write 64 bits of the 72 bit QDR word, so
 I
  changed the bitbasher blocks in qdr_mask.m to move the inaccessible
 bits out
  of the way to the most significant bits.  Now everything seems to
 work well,
  except that in some builds (seems to depend on clock rate?), the
 first 32
  bits (of the 64 bits I'm writing in a cycle) get swapped with the
 last 32
  bits sometime between writing the word and reading it back.  And
 there is a
  sometimes a difference in whether I am writing in firmware or by
 katcp to
  whether this swap happens.
 
  Also, when I write with katcp starting at address zero, I find that
 when
  reading out, the write started at what seems to be address 1.  Is
 the
  latency of QDR set to 10 cycles?
 
  I can live with all this, as long as it is repeatable for a given
 design,
  but I thought I'd ask if anyone knows what is causing these quirks.
 
  Also, I understand that we should run a software calibration for
 qdr,
  which seems to be qdr_cal() in qdr.py in the ska-sa:casperfpga
 repo.  So, I
  run this first, which seems to work for my latest compiles, but I
 haven't
  noticed a difference in the results.  What exactly does this
 calibration do?
 
  Thanks,
  Matt Strader
  UC Santa Barbara
 
 

Re: [casper] Roach2 QDR

[Jack Hickish]

Hi Matt,

The qdr_cal routine calibrates the relationship of clock and data signals
in the link between the FPGA and QDR signals. Basically it writes test
patterns and reads them back looking for glitches. It then changes the
delay of IODELAY blocks so that data read from the QDR is captured reliably.
If this calibration script runs successfully, I'm surprised you still see
glitches with 32 bits of data swapped between read and write (both from
PPC). This would (surely?) count as a glitch and cause the calibration
routine to fail(?). Do you only see strange behaviour when you read from
the FPGA fabric, or do straight write/reads from the CPU also misbehave? Is
the behaviour the same on every read / write (i.e., not intermittent)?

My experience with the QDR is that at high clock speeds (not sure how high,
but I see this at 312 MHz) the read latency of the QDR interface isn't 10
clock cycles as it should be even with the minimum IODELAY configuration,
and there are no reliable qdr_cal solutions. I solved this problem for my
design by removing half a clock cycle latency from the interface, at which
point the QDR would calibrate ok. What speed are you running your design
at? To me, misordered 32-bit chunks of data sounds indicative of a latency
problem in the qdr_cal solution, since the interface is 32 bit DDR, so half
a clock cycle mangles 32-bit chunks of data.

Good luck!

Jack



On Fri, 6 Mar 2015 at 23:54 Matt Strader mstra...@physics.ucsb.edu wrote:

 Hi all,

 I'm trying to use QDR on Roach2.  I have a test design where I write to
 QDR either in firmware or with katcp, then read it out in the firmware and
 check the results with snapshot blocks.  It mostly works, but with some
 interesting quirks.

 I know that katcp can only write 64 bits of the 72 bit QDR word, so I
 changed the bitbasher blocks in qdr_mask.m to move the inaccessible bits
 out of the way to the most significant bits.  Now everything seems to work
 well, except that in some builds (seems to depend on clock rate?), the
 first 32 bits (of the 64 bits I'm writing in a cycle) get swapped with the
 last 32 bits sometime between writing the word and reading it back.  And
 there is a sometimes a difference in whether I am writing in firmware or by
 katcp to whether this swap happens.

 Also, when I write with katcp starting at address zero, I find that when
 reading out, the write started at what seems to be address 1.  Is the
 latency of QDR set to 10 cycles?

 I can live with all this, as long as it is repeatable for a given design,
 but I thought I'd ask if anyone knows what is causing these quirks.

 Also, I understand that we should run a software calibration for qdr,
 which seems to be qdr_cal() in qdr.py in the ska-sa:casperfpga repo.  So, I
 run this first, which seems to work for my latest compiles, but I haven't
 noticed a difference in the results.  What exactly does this calibration
 do?

 Thanks,
 Matt Strader
 UC Santa Barbara

Re: [casper] How to use the qdr_transpose and qdr_ct blocks?

[Jack Hickish]

Hi Chenwei,

I'm not sure about the qdr corner turn block, but the qdr transpose is
fairly simple.
It has two parameters, input block size, and output block size. The
first is the number of channels in the fft input stream, the second is the
number of spectra you want to buffer and transpose. I.e. the number of
consecutive samples of each channel you want the block to output.
For the million channel spectrometer, I expect you'd want something like:

2**11 point (real) fft (2**10 channels output) -
Qdr transpose, input size = output size = 10. -
2**10 point complex fft.

On roach 2, the inputs and outputs of the qdr transpose data streams are 72
bits wide. As with the other Casper blocks, there's also the usual boolean
sync pulse which should be input the clock before the first sample in a
transpose is input, and will be output the clock before this sample arrives
on the data output port.

Hope that helps,

Jack

On Thu, 26 Mar 2015 7:38 pm Chenwei Cai caichenwei1...@gmail.com wrote:

 Dear CASPER,

 My name is Chenwei Cai, and I am constructing the Mega-Channel
 Spectrometer with ROACH II. To achieve that, two corner turners are
 required before we implement FFTs, which means I may use qdr_transpose or
 qdr_ct blocks. Since I cannot find any explanations on these blocks
 anywhere, could you provide me some details about the functions of these
 two blocks and what kind of data do those ports receive/export?

 Look forward to hearing from you!

 --
 Best Regards
 Chenwei CAI

 Mobile: +86-152-0147-9411
 Email: caichenwei1...@pku.edu.cn

[casper] Netfpga

[Jack Hickish]

Hi all,

Today I had a fun meeting with Andrew Moore at Cambridge university, who
does some great stuff as part of netfpga (netfpga.org). By the end of it, I
wanted some new toys, namely their latest virtex 7 board -
https://www.digilentinc.com/Products/Detail.cfm?NavPath=2,719,1327Prod=NETFPGA-10G-SUME

It's got a wild academic price of 1700 USD, loads of 13gb transceivers and
dsps and whilst it's not in a particularly caspery form factor, I wonder if
anyone has any compelling use case for the board. Netfpga have their own
design flow,but it would be very possible to support the board in casper
flow too.
Is anyone interested in this board? Perhaps for use with the Hittite 26gs
ADC -
https://www.cfa.harvard.edu/twpub/
https://www.cfa.harvard.edu/twpub/SMAwideband/TwentyGspsADC/ADC1X26G_Test_Report_20141030.pdf
SMAwideband
https://www.cfa.harvard.edu/twpub/SMAwideband/TwentyGspsADC/ADC1X26G_Test_Report_20141030.pdf
/
https://www.cfa.harvard.edu/twpub/SMAwideband/TwentyGspsADC/ADC1X26G_Test_Report_20141030.pdf
TwentyGspsADC
https://www.cfa.harvard.edu/twpub/SMAwideband/TwentyGspsADC/ADC1X26G_Test_Report_20141030.pdf
/ADC1X26G_Test_Report_20141030.
https://www.cfa.harvard.edu/twpub/SMAwideband/TwentyGspsADC/ADC1X26G_Test_Report_20141030.pdf
pdf
https://www.cfa.harvard.edu/twpub/SMAwideband/TwentyGspsADC/ADC1X26G_Test_Report_20141030.pdf
or as a correlator/beamformer back end?

Basically, I'm looking for an excuse to buy one. Please, help me out :)

Jack

PS: read a bit about the what the board's being developed for here -
http://www.cl.cam.ac.uk/~nz247/publications/zilberman2014sume.pdf

Re: [casper] sync ADCs in ROACH2

[Jack Hickish]

Hi Franco,

The sync inputs are usually used to synchronise multiple boards. If you
feed an lvttl signal into the sync input of the adc5g, it will emerge from
the sync output of the yellow block. Usually people drive this signal with
a pulse per second signal from a GPS, and use the resulting simulink signal
to synchronise their logic.

Trying to sync 2 ADCs perfectly is a bit tricky though. Unless the adc5g
interface has changed since I last used it (which is possible), every time
you reprogram your board, the latency of the ADC samples arriving to
simulink is liable to change and might not be the same for both ADC cards.
I *think* that the sync signal follows the ADC data through the interface's
FIFOs, which means you can compensate for some of this variable latency
using this sync. However, I don't think you'll be able to get the alignment
of ADC streams better than 16 ADC clocks (one FPGA clock).

Usually this isn't a problem - a correlator can usually fix these small
offsets in software after taking data, and they don't change once you start
running your system.
Personally, if you need perfect real-time alignment, I would consider
injecting some test signal into both adcs and correlating their digital
streams to measure their relative phase differences.

Perhaps someone else has a better / different answer. I know people have
worried about precision ADC synchronisation for other ADCs before, but I
don't know what solutions have been proposed or implemented in the past.

Cheers,
Jack

On Thu, 29 Jan 2015 10:19 pm Franco francocuro...@gmail.com wrote:

 Hi CASPER community,
 I'm working with ROACH 2 and I need to synchronize the two ADC so that
 both take samples at the same instant of time. Does anybody know how can I
 achieve this synchronization?

 I've noticed that that the Simulink block model for these ADCs (adc5g),
 doesn't have the option of using them in interleave mode in the block
 parameters, contrary to ROACH1 ADC blocks (adc_083000x2).

 I've also noticed that the ADC boards have a SYNC input, but I don't know
 how to use it.

 Thanks,
 Franco

 --
 Franco Curotto
 Estudiante de Ingeniería Civil Eléctrica
 Facultad de Ciencias Físicas y Matemáticas
 Universidad de Chile

Re: [casper] Regarding dram: Moving from ROACH1 to ROACH2

[Jack Hickish]

I would suggest writing a casper memo, and linking it prominently from
the dram block documentation page. But if you write it, you can choose
where it goes!

On 20 April 2015 at 08:09, Madden, Timothy J. tmad...@aps.anl.gov wrote:
 I send a link when I post. I am still fixing a few bugs. Mostly works but I
 don't want to post a buggy design.
 Also, how does one update the wiki on this? Perhaps add an app note?


 Tim

 
 From: Brad Dober [do...@sas.upenn.edu]
 Sent: Monday, April 20, 2015 10:07 AM
 To: Madden, Timothy J.
 Cc: Jack Hickish; casper@lists.berkeley.edu

 Subject: Re: [casper] Regarding dram: Moving from ROACH1 to ROACH2

 Hi Tim,

 Could you send out a link to the github page when you do post it?

 Thanks,


 Brad Dober
 Ph.D. Candidate
 Department of Physics and Astronomy
 University of Pennsylvania
 Cell: 262-949-4668

 On Thu, Apr 16, 2015 at 11:11 AM, Madden, Timothy J. tmad...@aps.anl.gov
 wrote:

 I will get on github soon. Argonne and Nist are sharing stuff already.

 T

 
 From: Jack Hickish [jackhick...@gmail.com]
 Sent: Thursday, April 16, 2015 10:08 AM
 To: Madden, Timothy J.; casper@lists.berkeley.edu
 Subject: Re: [casper] Regarding dram: Moving from ROACH1 to ROACH2

 Hi Tim,

 If you don't mind sharing your design, I'll put it up on the Casper wiki,
 where i think it would be useful for others trying to use the dram.

 Cheers,
 Jack


 On Thu, 16 Apr 2015 7:19 am Madden, Timothy J. tmad...@aps.anl.gov
 wrote:

 Folks

 After reverse engineering the dram on ROACH2 here is what one should
 know.

 1. The dram on roach2 is different from roach1.
On roach1, the user can read and write 144 size words to the dram with
 the buss set not to 288 bits.
   On roach2, the data buss is always 288 bits, regardless of the use
 wide buss setting.
 2. Of one wants to stream dram data to a DAC on a roach 1, for MKID
 applications we do this:
  Read every other clock cycle by toggling cmd ack on each clock.
  144 bit words will steam out every clock that can drive the DAC.

 On roach2, we read 288 bit words every other clock cycle by toggling
 cmd ack on every clock.
 Then we use a mux to convert the  288 bit words down to a series of
 144 bit words on every clock.

 The dram should be set to 200MHz, not 240MHz or something else. The CORE
 generator has all its constraints
 set up for 200MHz. Note that this 200MHz has nothing to do with your
 fabric clock, as it comes
 from a different PLL on the FPGA. The yellow block does not interface to
 the dram itself, but simply FIFOs.
 When you write to the dram yellow block, you write to FIFOs that cross
 the clock domains. For streaming
 144 bit data to DACs, you are reading 288 bit data from the dram at 1/2
 your fabric clock rate. This gives
 lots of time for the FIFOs to read from the dram in little 8 word bursts
 and still deal with the dram refresh.

 I post this because we got confused by the documentation on the casper
 website. Also, we are moving from
 ROACH to ROACH2, and did not know the little differences in the dram.
 Also, it is natural to assume that the
 yellow block talks directly to the xilinx ddr3 controller and the ports
 correspond to the UI interface
 documented in the xilinx memory generator docs. This is not the case. The
 yellow block reads and writes
 fifos, and the ddr stuff is all hidden.

 The dram is a nice design by the way. I am just pointing out some details
 to save other folks some time.

 Tim Madden
 Argonne Lab

Re: [casper] cross_multiplier block can't find cram_init function

[Jack Hickish]

Hi James,

I think this commit --
https://github.com/jack-h/mlib_devel/commit/c34d3e539552b2f75a5e0452a72b0669b66a187b
-- should solve your problem.

Cheers,
Jack

On Tue, 28 Apr 2015 at 04:59 G Jones glenn.calt...@gmail.com wrote:

 Cram was my old version of the new bus creation utilities. The bus library
 in the CASPER block set supersedes the cram/uncram block, so the cross
 multiplier block should be updated. For reference, the cram block is in the
 old gavrt library.

 Glenn
 On Apr 28, 2015 7:44 AM, James Gowans james.gow...@uct.ac.za wrote:

  Hi,

 I'm on the latest commit of ska-sa/mlib-devel and am trying to use the
 CASPER DSP - Correlator - cross_multiplier green block.

 When I compile the design I get the following error:


 *Error in 'jgowans_fft_4chan/cross_multiplier/pack0_0': Initialization
 commands cannot be evaluated. Caused by: Undefined function 'cram_init' for
 input arguments of type 'char'.*

 Grepping through the repo I would agree that *cram_init* does not exist.
 Does anyone know where it's gone to or what can be done to get this block
 compiling?

 The mask parameters are:
 Input steams: 4
 Aggregation: 2
 In: 18_17
 Out: 32_31
 (others default)

 Regards,
 James Gowans
 M.Sc Student, University of Cape Town
  --
 UNIVERSITY OF CAPE TOWN

 This e-mail is subject to the UCT ICT policies and e-mail disclaimer
 published on our website at
 http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27
 21 650 9111. This e-mail is intended only for the person(s) to whom it
 is addressed. If the e-mail has reached you in error, please notify the
 author. If you are not the intended recipient of the e-mail you may not
 use, disclose, copy, redirect or print the content. If this e-mail is not
 related to the business of UCT it is sent by the sender in the sender's
 individual capacity.

Re: [casper] cross_multiplier block can't find cram_init function

[Jack Hickish]

Hi James

On Thu, 30 Apr 2015 at 01:21 James Gowans james.gow...@uct.ac.za wrote:

  Hi Jack and Glen,

 Thanks very much - that commit does exactly what I needed. :-)

 Two follow-on questions:

 The change you made only modifies the init script, not the mdl files which
 contains that cross_multiplier block. Why didn't you rather replace the
 cram/uncram blocks (as well as do some of your other alterations) in the
 mdl file? This seems to me the logical place to make changes, but perhaps I
 misunderstand how green blocks work?...


The init script needed changing either way, since it [attempts to] place
cram blocks, it doesn't just modify the parameters of blocks which are
already there. This has to be the case, because the block needs to
dynamically add/remove crams depending on the number of inputs. If it was
changed in the mdl file to the new bus block, the init script would break
the block when it attempted to redraw.
Having changed the init script, I guess I could have also changed the block
saved in the library too to remove the crams, but I generally try to avoid
modifying library mdl files wherever possible because it becomes a bit of a
version control nightmare. You'll notice that a lot of the newer blocks in
the library are saved as empty shells, for this reason. On initialisation,
the init script will overwrite the innards with the correct stuff.
If, on the other hand, the init file doesn't work with the block in the mdl
file as saved, then that's a screwup on my part.




 In my application I use the full resolution of the cross multiplier, so
 the cvrt blocks do nothing, but still consume logic. Would it be worth it
 do add some functionality to the init script to detect this case and remove
 the cvrt blocks, or is it uncommon to use the full resolution?


If their latency is zero, and the precision is full, the convert blocks
shouldn't use any hardware resources. You could add this to the init script
to save having superfluous blocks floating around, but I don't think this
should impact your compiles.

Cheers,
Jack



 Thanks again,
 James Gowans
  --
 *From:* Jack Hickish [jackhick...@gmail.com]
 *Sent:* Tuesday, April 28, 2015 10:27 PM
 *To:* G Jones; James Gowans
 *Cc:* casper@lists.berkeley.edu
 *Subject:* Re: [casper] cross_multiplier block can't find cram_init
 function

   Hi James,

 I think this commit --
 https://github.com/jack-h/mlib_devel/commit/c34d3e539552b2f75a5e0452a72b0669b66a187b
 -- should solve your problem.

  Cheers,
 Jack

 On Tue, 28 Apr 2015 at 04:59 G Jones glenn.calt...@gmail.com wrote:

 Cram was my old version of the new bus creation utilities. The bus
 library in the CASPER block set supersedes the cram/uncram block, so the
 cross multiplier block should be updated. For reference, the cram block is
 in the old gavrt library.

 Glenn
 On Apr 28, 2015 7:44 AM, James Gowans james.gow...@uct.ac.za wrote:

  Hi,

 I'm on the latest commit of ska-sa/mlib-devel and am trying to use the
 CASPER DSP - Correlator - cross_multiplier green block.

 When I compile the design I get the following error:


 *Error in 'jgowans_fft_4chan/cross_multiplier/pack0_0': Initialization
 commands cannot be evaluated. Caused by: Undefined function 'cram_init' for
 input arguments of type 'char'.*

 Grepping through the repo I would agree that *cram_init* does not
 exist. Does anyone know where it's gone to or what can be done to get this
 block compiling?

 The mask parameters are:
 Input steams: 4
 Aggregation: 2
 In: 18_17
 Out: 32_31
 (others default)

 Regards,
 James Gowans
 M.Sc Student, University of Cape Town
  --
 UNIVERSITY OF CAPE TOWN

 This e-mail is subject to the UCT ICT policies and e-mail disclaimer
 published on our website at
 http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27
 21 650 9111. This e-mail is intended only for the person(s) to whom it
 is addressed. If the e-mail has reached you in error, please notify the
 author. If you are not the intended recipient of the e-mail you may not
 use, disclose, copy, redirect or print the content. If this e-mail is not
 related to the business of UCT it is sent by the sender in the sender's
 individual capacity.

Re: [casper] cross_multiplier block can't find cram_init function

[Jack Hickish]

You're right that it would be better to change in both places. In fact it
would be best it the library version of the block was completely empty. If
you wanted to do this, and make any necessary changes to the init script
(there might not be any), I'll gladly merge it into the main casper-astro
repo.

Thanks
Jack

On Fri, 1 May 2015 4:10 am James Gowans james.gow...@uct.ac.za wrote:

  Thanks Jack, that makes sense!
 I still find it somewhat disconcerting that the mdl file contains a block
 so different to what the init script generates, but I suppose it doesn't
 really matter.

 I'm running a compile now but I don't foresee any problems.
 I've made a pull request against ska-sa for your change.

 James
  --
 *From:* Jack Hickish [jackhick...@gmail.com]
 *Sent:* Thursday, April 30, 2015 8:33 PM
 *To:* James Gowans; G Jones

 *Cc:* casper@lists.berkeley.edu
 *Subject:* Re: [casper] cross_multiplier block can't find cram_init
 function
   Hi James

 On Thu, 30 Apr 2015 at 01:21 James Gowans james.gow...@uct.ac.za wrote:

  Hi Jack and Glen,

 Thanks very much - that commit does exactly what I needed. :-)

 Two follow-on questions:

 The change you made only modifies the init script, not the mdl files
 which contains that cross_multiplier block. Why didn't you rather replace
 the cram/uncram blocks (as well as do some of your other alterations) in
 the mdl file? This seems to me the logical place to make changes, but
 perhaps I misunderstand how green blocks work?...


  The init script needed changing either way, since it [attempts to] place
 cram blocks, it doesn't just modify the parameters of blocks which are
 already there. This has to be the case, because the block needs to
 dynamically add/remove crams depending on the number of inputs. If it was
 changed in the mdl file to the new bus block, the init script would break
 the block when it attempted to redraw.
 Having changed the init script, I guess I could have also changed the
 block saved in the library too to remove the crams, but I generally try to
 avoid modifying library mdl files wherever possible because it becomes a
 bit of a version control nightmare. You'll notice that a lot of the newer
 blocks in the library are saved as empty shells, for this reason. On
 initialisation, the init script will overwrite the innards with the correct
 stuff.
 If, on the other hand, the init file doesn't work with the block in the
 mdl file as saved, then that's a screwup on my part.




 In my application I use the full resolution of the cross multiplier, so
 the cvrt blocks do nothing, but still consume logic. Would it be worth it
 do add some functionality to the init script to detect this case and remove
 the cvrt blocks, or is it uncommon to use the full resolution?


  If their latency is zero, and the precision is full, the convert blocks
 shouldn't use any hardware resources. You could add this to the init script
 to save having superfluous blocks floating around, but I don't think this
 should impact your compiles.

  Cheers,
 Jack



  Thanks again,
 James Gowans
  --
 *From:* Jack Hickish [jackhick...@gmail.com]
 *Sent:* Tuesday, April 28, 2015 10:27 PM
 *To:* G Jones; James Gowans
 *Cc:* casper@lists.berkeley.edu
 *Subject:* Re: [casper] cross_multiplier block can't find cram_init
 function

  Hi James,

 I think this commit --
 https://github.com/jack-h/mlib_devel/commit/c34d3e539552b2f75a5e0452a72b0669b66a187b
 -- should solve your problem.

  Cheers,
 Jack

 On Tue, 28 Apr 2015 at 04:59 G Jones glenn.calt...@gmail.com wrote:

 Cram was my old version of the new bus creation utilities. The bus
 library in the CASPER block set supersedes the cram/uncram block, so the
 cross multiplier block should be updated. For reference, the cram block is
 in the old gavrt library.

 Glenn
 On Apr 28, 2015 7:44 AM, James Gowans james.gow...@uct.ac.za wrote:

  Hi,

 I'm on the latest commit of ska-sa/mlib-devel and am trying to use the
 CASPER DSP - Correlator - cross_multiplier green block.

 When I compile the design I get the following error:


 *Error in 'jgowans_fft_4chan/cross_multiplier/pack0_0': Initialization
 commands cannot be evaluated. Caused by: Undefined function 'cram_init' for
 input arguments of type 'char'.*

 Grepping through the repo I would agree that *cram_init* does not
 exist. Does anyone know where it's gone to or what can be done to get this
 block compiling?

 The mask parameters are:
 Input steams: 4
 Aggregation: 2
 In: 18_17
 Out: 32_31
 (others default)

 Regards,
 James Gowans
 M.Sc Student, University of Cape Town
  --
 UNIVERSITY OF CAPE TOWN

 This e-mail is subject to the UCT ICT policies and e-mail disclaimer
 published on our website at
 http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable
 from +27 21 650 9111. This e-mail is intended only for the person(s)
 to whom it is addressed. If the e-mail has reached you in error

Re: [casper] Timing distribution over fiber

[Jack Hickish]

Hi John,

Thanks for the info. I'll add Litelink to my list of suppliers to
investigate.
We have no particular urge to multiplex the signals on to the fiber unless
there's a particularly neat/cheap solution to do that. There's no great
appetite to go custom. We've got about ~30 nodes, and my first stab at
getting an off-the-shelf solution turned up at a few k$ / node, not
including any cleanup electronics.

Thanks again,

Jack

On Mon, 4 May 2015 at 19:25 John Ford jf...@nrao.edu wrote:

  Hi CASPERites,
 
  For HERA, we're looking at distributing timing signals (PPS  10Mhz ref
 or
  500 MHz clock) over O(100m) fibers to various digitization nodes.
  I figure some folks in CASPERland have experience with this kind of
  system?
  Did you use custom RF-over-fiber kit, or off-the-shelf PPS/10MHz
  solutions?
  Any words of wisdom/caution to share?
 
  Any responses much appreciated!

 We have several different schemes for the different signals.  Are you
 planning for one fiber per signal per node?  or one fiber with the signals
 multiplexed on them?

 If the signals are one per signal, you can use some off-the-shelf
 solutions, but they are kind of pricey, and if you have a lot of nodes to
 supply, it might be worth working on something custom.  We have used Math
 Associates stuff for this kind of work.  Math Associates is now litelink,
 and they tout the affordability of their stuff, so maybe it's
 reasonable...


 On the 10 MHz, we send the 10 MHz reference over fiber, and at the far end
 use a crystal oscillator locked to the reference to clean up the noise
 from the fiber electronics.  This is essential for interferometry, but
 maybe not for single-dish use.

 John

 
  Jack
 

Re: [casper] casper Digest, Vol 90, Issue 10

[Jack Hickish]

Thanks for the link, Andrew!

On Thu, 7 May 2015 at 05:09 Andrew Vdb avd...@gmail.com wrote:

 Hi all,

 For those interested in White Rabbit, Xilinx have an article in their
 Xcell journal (91). The link is here
 http://issuu.com/xcelljournal/docs/xcell_journal_issue_91/18?e.

 regards,
 Andrew

 On Thu, May 7, 2015 at 1:45 AM, casper-requ...@lists.berkeley.edu wrote:

 Send casper mailing list submissions to
 casper@lists.berkeley.edu

 To subscribe or unsubscribe via the World Wide Web, visit

 https://calmail.berkeley.edu/manage/list/listinfo/casper@lists.berkeley.edu

 or, via email, send a message with subject or body 'help' to
 casper-requ...@lists.berkeley.edu

 You can reach the person managing the list at
 casper-ow...@lists.berkeley.edu

 When replying, please edit your Subject line so it is more specific
 than Re: Contents of casper digest...


 Today's Topics:

1. Re: Timing distribution over fiber (Jack Hickish)


 --

 Message: 1
 Date: Wed, 06 May 2015 23:45:53 +
 From: Jack Hickish jackhick...@gmail.com
 Subject: Re: [casper] Timing distribution over fiber
 To: Johan Burger jbur...@ska.ac.za, Michael Inggs
 miki...@gmail.com,Bob Stricklin bstr...@n5brg.com, Sias
 Malan
 s...@ska.ac.za,   Renier Siebrits ren...@ska.ac.za,
 Francois Kapp
 franc...@ska.ac.za,   Etienne Bauermeister etie...@ska.ac.za
 Cc: Simon Lewis simonacle...@hotmail.com, Casper Lists
 casper@lists.berkeley.edu,Thomas Abbott tabb...@ska.ac.za
 ,
 Stephan Sandenberg ssandenbe...@gmail.com
 Message-ID:
 CAG1GKS=5fWeJ+quOj=
 gj_rd7qgtngc2z_07abtx7nwjhojw...@mail.gmail.com
 Content-Type: text/plain; charset=utf-8

 On Wed, 6 May 2015 at 07:35 Johan Burger jbur...@ska.ac.za wrote:

 
  Hi there,
 
  Do you maybe have any idea of requirement specifications for the HERA's
 RF
  phase stability and time (?) - this might determine what technology
 could
  be appropriate.
 

 Hi Johan,

 Thanks for your response. We're sampling at 500 MHz, so we'd like to have
 a
 stability of few degrees, preferably over timescales of many hours but
 perhaps more reasonably on a calibration cadence of O(10 minutes)

 PPS is not such a big deal, and synchronization to a couple of ADC clock
 cycles is probably fine. We're investigating simple-ish ways to calibrate
 these out with signal injection.



 
  We at SKA Africa have after some iteration come up, with a precision RF
  distribution system for many antennas.  The type of laser and integrated
  modulator have been proven in the field on large arrays (not just
  MeerKAT).  The RF can be directly transmitted (in our case up to 2-3 GHz
  limited by our synthesizer - the precise frequency is 1.712GHz).
 500MHz RF
  over fibre can be done by this as well.  There is conditioning of the RF
  taking place on MeerKAT at the receiving end. As Jason said, not any or
 all
  modules really do the job properly - we converged on a solution after
  testing, that implicitly included modules evaluated from KAT-7 days, and
  more recent modules from other manufacturers.
 
  Low precision timing ~100ns can indeed be done using PTP.  If PPS is
  required instead of an Ethernet package a special conversion board
 (PCIe)
  is necessary.  This is really enough for fringe finding - used in
 MeerKAT
  S-band for example. That digitiser is mounted in an RFI shielded
 pedestal
  of the antenna though.  We supply the high precision PPS using our
 custom
  system as described below.
 
  For our L-band digitisers mounted on the outside we had to come up with
  special low power, low cost, high accuracy solution - this is being
  implemented by Renier and Etienne and others here at SKA Africa (so a
 joint
  effort by our time and frequency and digitiser team).  The reason is
 that
  White Rabbit is not compatible with 10Gbe links used on this system.
  Furthermore Ethernet is actually quite noisy as per MeerKAT
 measurements,
  and White Rabbit and PTP uses that (and with highish power consumption
 and
  largish board size), and is not preferable in a high purity clock signal
  and PPS module.  We found that measurement based PPS system will meet
 our
  requirements though, for stabilized links and provides us with accurate
  absolute time references at antennas, using analog methodologies.  This
 for
  example being important in pulsar science.
 
  I am not sure what level of RFI shielding you would be able to mount
  around modules, but as said RFI from Ethernet has certainly been found
 to
  be an RFI culprit, and cannot be therefore be used in MeerKAT close to
  sensitive modules - and needs to separately shielded.  This therefore
 means
  that if PPS is generated from White Rabbit/PTP there is still some
  uncertain propagation paths left (important at least for MeerKAT) up to
 the
  point of digitization where a timing edge is inserted.  We are using

Re: [casper] Timing distribution over fiber

[Jack Hickish]

 between channels. The analog devices chip is $50 so a custom
 solution should be $500/reference but with considerable development time.
  
   Bob Stricklin
  
  
   On May 4, 2015, at 10:02 PM, Jack Hickish jackhick...@gmail.com
 wrote:
  
   Hi John,
  
   Thanks for the info. I'll add Litelink to my list of suppliers to
 investigate.
   We have no particular urge to multiplex the signals on to the fiber
 unless there's a particularly neat/cheap solution to do that. There's no
 great appetite to go custom. We've got about ~30 nodes, and my first stab
 at getting an off-the-shelf solution turned up at a few k$ / node, not
 including any cleanup electronics.
  
   Thanks again,
  
   Jack
  
   On Mon, 4 May 2015 at 19:25 John Ford jf...@nrao.edu wrote:
   Hi CASPERites,
  
   For HERA, we're looking at distributing timing signals (PPS 
 10Mhz ref or
   500 MHz clock) over O(100m) fibers to various digitization nodes.
   I figure some folks in CASPERland have experience with this kind of
   system?
   Did you use custom RF-over-fiber kit, or off-the-shelf PPS/10MHz
   solutions?
   Any words of wisdom/caution to share?
  
   Any responses much appreciated!
  
   We have several different schemes for the different signals.  Are
 you
   planning for one fiber per signal per node?  or one fiber with the
 signals
   multiplexed on them?
  
   If the signals are one per signal, you can use some off-the-shelf
   solutions, but they are kind of pricey, and if you have a lot of
 nodes to
   supply, it might be worth working on something custom.  We have
 used Math
   Associates stuff for this kind of work.  Math Associates is now
 litelink,
   and they tout the affordability of their stuff, so maybe it's
   reasonable...
  
  
   On the 10 MHz, we send the 10 MHz reference over fiber, and at the
 far end
   use a crystal oscillator locked to the reference to clean up the
 noise
   from the fiber electronics.  This is essential for interferometry,
 but
   maybe not for single-dish use.
  
   John
  
  
   Jack
  
  
  
  
  
  
 
 
 





 --
 Michael Inggs
 Department of Electrical Engineering, University of Cape Town, Private
 Bag, Rondebosch 7701, South Africa. Tel: +27 21 650 2799 Fax: +27 21 650
 3465  Skype: mikings
 Ex Africa semper aliquid novi

Re: [casper] Timing distribution over fiber

[Jack Hickish]

Hi Bob,

Sounds interesting -- for what it's worth, I've just learnt some fellow
astronomers in Italy (Andrea Maccaferri at INAF's Medicina observatory)
have built some PPS/refclk distribution systems based on the Avago fiber
parts -- perhaps you might be interested in getting in touch with him...

Thanks (to everyone on this thread)
Jack

On Mon, 4 May 2015 at 20:19 Bob Stricklin bstr...@n5brg.com wrote:

  Hi Jack and John,

  I wanted to add an input here…..

  I am working on a 10 MHz GPS slaved reference for my personal use. I am
 working with a Analog Devices AD9548 Evaluation board (~$250) , GPS with 1
 PPS, and a ovenized 10 MHz osc. I also plan to distribute this clock and
 have considered the Avago fiber product line. One of the older generation
 Avago fiber parts should work fine for $25 per channel. With careful
 control of lengths and delays it should be possible to maintain good
 phasing between channels. The analog devices chip is $50 so a custom
 solution should be $500/reference but with considerable development time.

  Bob Stricklin


  On May 4, 2015, at 10:02 PM, Jack Hickish jackhick...@gmail.com wrote:

  Hi John,

 Thanks for the info. I'll add Litelink to my list of suppliers to
 investigate.
 We have no particular urge to multiplex the signals on to the fiber unless
 there's a particularly neat/cheap solution to do that. There's no great
 appetite to go custom. We've got about ~30 nodes, and my first stab at
 getting an off-the-shelf solution turned up at a few k$ / node, not
 including any cleanup electronics.

  Thanks again,

  Jack

 On Mon, 4 May 2015 at 19:25 John Ford jf...@nrao.edu wrote:

  Hi CASPERites,
 
  For HERA, we're looking at distributing timing signals (PPS  10Mhz ref
 or
  500 MHz clock) over O(100m) fibers to various digitization nodes.
  I figure some folks in CASPERland have experience with this kind of
  system?
  Did you use custom RF-over-fiber kit, or off-the-shelf PPS/10MHz
  solutions?
  Any words of wisdom/caution to share?
 
  Any responses much appreciated!

 We have several different schemes for the different signals.  Are you
 planning for one fiber per signal per node?  or one fiber with the signals
 multiplexed on them?

 If the signals are one per signal, you can use some off-the-shelf
 solutions, but they are kind of pricey, and if you have a lot of nodes to
 supply, it might be worth working on something custom.  We have used Math
 Associates stuff for this kind of work.  Math Associates is now litelink,
 and they tout the affordability of their stuff, so maybe it's
 reasonable...


 On the 10 MHz, we send the 10 MHz reference over fiber, and at the far end
 use a crystal oscillator locked to the reference to clean up the noise
 from the fiber electronics.  This is essential for interferometry, but
 maybe not for single-dish use.

 John

 
  Jack
 

Re: [casper] Timing distribution over fiber

[Jack Hickish]

 in a normal FPGA using the standard Xilinx 10G IP core. There are
 FPGA cores available for the IEEE1588 part, so you don't have to implement
 it yourself. We considered this for MeerKAT at one stage, but in the end we
 couldn't achieve the required performance. It might be quite workable for
 HERA, though. Anyway, just a thought. It'd save you buying special HW and
 running additional fibres, if it meets your performance targets.

 Jason Manley
 CBF Manager
 SKA-SA

 Cell: +27 82 662 7726
 Work: +27 21 506 7300

 On 05 May 2015, at 18:49, Dan Werthimer d...@ssl.berkeley.edu wrote:

 
 
  hi dave,
 
  i also think distributing clock and 1 PPS is simpler than IEEE1588.
 
  some of the IEEE1588 and white rabbit experts are here at berkeley.
  see for example:
  http://chess.eecs.berkeley.edu/pubs/881/dreams.pdf
 
  my limited understanding is that 1588 phase locks the bit clocks of
  routers and switches together.   1588 routers and switches have SMA
  connectors on them so you can use external maser/rubidium/GPS
 references.
 
  you can achieve spectacular accuracy and stabilitity with white rabbit
  if you employ really good oscillators at each node,
  i think white rabbit can acheive 70 picosecond RMS time transfer.
 
  best,
 
  dan
 
 
 
 
 
  On Tue, May 5, 2015 at 8:52 AM, David MacMahon 
 dav...@astro.berkeley.edu wrote:
  Hi, Jason,
 
  I have a great deal of curiosity about IEEE-1588, but I've always
 wondered about the precision/stability that's attainable.  Compared with
 multiple sample clocks, correlating signals sampled with one common clock
 seems far more forgiving vis a vis clock frequency/phase stability.  If you
 or John could point me to any information about this, please do!
 
  Thanks,
  Dave
 
  On May 4, 2015, at 11:44 PM, Jason Manley wrote:
 
   On the far end of the concept spectrum, have you considered
 distributing time over your existing ethernet network with IEEE-1588, and
 using this to discipline local ovenised 10MHz oscs at each antenna?
  
   I'm cc'ing Johan Burger, who heads up our Timing and Frequency
 Reference subsystem, who might be able to offer some additional insight. I
 know they've tried a few different lasers and detectors, with varying
 levels of success.
  
   Jason Manley
   CBF Manager
   SKA-SA
  
   Cell: +27 82 662 7726
   Work: +27 21 506 7300
  
   On 05 May 2015, at 5:18, Bob Stricklin bstr...@n5brg.com wrote:
  
   Hi Jack and John,
  
   I wanted to add an input here…..
  
   I am working on a 10 MHz GPS slaved reference for my personal use.
 I am working with a Analog Devices AD9548 Evaluation board (~$250) , GPS
 with 1 PPS, and a ovenized 10 MHz osc. I also plan to distribute this clock
 and have considered the Avago fiber product line. One of the older
 generation Avago fiber parts should work fine for $25 per channel. With
 careful control of lengths and delays it should be possible to maintain
 good phasing between channels. The analog devices chip is $50 so a custom
 solution should be $500/reference but with considerable development time.
  
   Bob Stricklin
  
  
   On May 4, 2015, at 10:02 PM, Jack Hickish jackhick...@gmail.com
 wrote:
  
   Hi John,
  
   Thanks for the info. I'll add Litelink to my list of suppliers to
 investigate.
   We have no particular urge to multiplex the signals on to the
 fiber unless there's a particularly neat/cheap solution to do that. There's
 no great appetite to go custom. We've got about ~30 nodes, and my first
 stab at getting an off-the-shelf solution turned up at a few k$ / node, not
 including any cleanup electronics.
  
   Thanks again,
  
   Jack
  
   On Mon, 4 May 2015 at 19:25 John Ford jf...@nrao.edu wrote:
   Hi CASPERites,
  
   For HERA, we're looking at distributing timing signals (PPS 
 10Mhz ref or
   500 MHz clock) over O(100m) fibers to various digitization nodes.
   I figure some folks in CASPERland have experience with this kind
 of
   system?
   Did you use custom RF-over-fiber kit, or off-the-shelf PPS/10MHz
   solutions?
   Any words of wisdom/caution to share?
  
   Any responses much appreciated!
  
   We have several different schemes for the different signals.  Are
 you
   planning for one fiber per signal per node?  or one fiber with the
 signals
   multiplexed on them?
  
   If the signals are one per signal, you can use some off-the-shelf
   solutions, but they are kind of pricey, and if you have a lot of
 nodes to
   supply, it might be worth working on something custom.  We have
 used Math
   Associates stuff for this kind of work.  Math Associates is now
 litelink,
   and they tout the affordability of their stuff, so maybe it's
   reasonable...
  
  
   On the 10 MHz, we send the 10 MHz reference over fiber, and at the
 far end
   use a crystal oscillator locked to the reference to clean up the
 noise
   from the fiber electronics.  This is essential for interferometry,
 but
   maybe not for single-dish use.
  
   John
  
  
   Jack
  
  
  
  
  
  
 
 
 





 --
 Michael Inggs

Re: [casper] Regarding dram: Moving from ROACH1 to ROACH2

[Jack Hickish]

Hi Tim,

If you don't mind sharing your design, I'll put it up on the Casper wiki,
where i think it would be useful for others trying to use the dram.

Cheers,
Jack

On Thu, 16 Apr 2015 7:19 am Madden, Timothy J. tmad...@aps.anl.gov wrote:

  Folks

 After reverse engineering the dram on ROACH2 here is what one should know.

 1. The dram on roach2 is different from roach1.
On roach1, the user can read and write 144 size words to the dram with
 the buss set not to 288 bits.
   On roach2, the data buss is always 288 bits, regardless of the use wide
 buss setting.
 2. Of one wants to stream dram data to a DAC on a roach 1, for MKID
 applications we do this:
  Read every other clock cycle by toggling cmd ack on each clock.
  144 bit words will steam out every clock that can drive the DAC.

 On roach2, we read 288 bit words every other clock cycle by toggling
 cmd ack on every clock.
 Then we use a mux to convert the  288 bit words down to a series of
 144 bit words on every clock.

 The dram should be set to 200MHz, not 240MHz or something else. The CORE
 generator has all its constraints
 set up for 200MHz. Note that this 200MHz has nothing to do with your
 fabric clock, as it comes
 from a different PLL on the FPGA. The yellow block does not interface to
 the dram itself, but simply FIFOs.
 When you write to the dram yellow block, you write to FIFOs that cross the
 clock domains. For streaming
 144 bit data to DACs, you are reading 288 bit data from the dram at 1/2
 your fabric clock rate. This gives
 lots of time for the FIFOs to read from the dram in little 8 word bursts
 and still deal with the dram refresh.

 I post this because we got confused by the documentation on the casper
 website. Also, we are moving from
 ROACH to ROACH2, and did not know the little differences in the dram.
 Also, it is natural to assume that the
 yellow block talks directly to the xilinx ddr3 controller and the ports
 correspond to the UI interface
 documented in the xilinx memory generator docs. This is not the case. The
 yellow block reads and writes
 fifos, and the ddr stuff is all hidden.

 The dram is a nice design by the way. I am just pointing out some details
 to save other folks some time.

 Tim Madden
 Argonne Lab

Re: [casper] How to use the qdr_transpose and qdr_ct blocks?

[Jack Hickish]

Hi Chenwei,

I had a look at your model - the error will go away if you select the
enable CPU interface option in your qdr yellow blocks. Regardless of your
error, enabling the cpu interface is necessary because it is used for
calibrating the qdr on roach2 (this was not the case on roach1) using the
script in the mlib_devel repo.
Note that currently calibrating the qdr requires software writes to occur
in the top half of the memory without being interfered with by the fabric
(aka simulink) qdr interface. QDR calibration will fail if you attempt to
calibrate whilst the fabric is writing to the top half of the qdr memory
space, so when using more than 20 bits of the address line, you'll need a
way to halt the simulink interface during calibration.
Tomorrow I'll try and modify the qdr controller so that it can override the
simulink interface during calibration, since currently this is an
unnecessary user hassle.

Cheers,
Jack

On 8 June 2015 at 10:38, Chenwei Cai caichenwei1...@gmail.com wrote:

 Hi Jack,

 I have encountered the same problem with Xilinx 14.7. See the log,

 ERROR:PhysDesignRules:1763 - Issue with pin connections and/or
 configuration on

  block:qdr1_controller/qdr1_controller/qdrc_infrastructure_inst/IODELAY_sa20
:IODELAYE1_IODELAYE1.  For DELAY_SRC IO or O programming the ODATAIN
input pins of IODELAYE1 must be connected.
 ERROR:Bitgen:25 - DRC detected 1 errors and 63 warnings.  Please see the
previously displayed individual error or warning messages for more
 details.
 ===
 Flow run time summary: (01:08:07 seconds total)
 System update00:00:00
 Design Rules Check...00:00:00
 Xilinx System Generator..00:52:02
 Base system copy.00:00:00
 IP creation..00:00:00
 EDK files creation...00:00:05
 IP elaboration...00:00:00
 Software creation00:00:00
 EDK/ISE backend..00:15:58
 ===

 Maybe I truly need your help on this. And here is my model,
 https://www.dropbox.com/s/oiawxtux7syt0jv/fft_corner_turner_v4_nuevo.slx?dl=0
 . There is one self-defined block, filt_sample, within the model, which can
 be obtained an added through this url,
 https://www.dropbox.com/sh/qckqor5hw8if0rv/AAB_SGyCoBsgDHk-8YfpPKlma?dl=0
 .

 Thanks for your help!

 On Sat, Jun 6, 2015 at 3:43 AM, Jack Hickish jackhick...@gmail.com
 wrote:

 no rush - let me know how the compile goes!

 cheers
 jack

 On 5 June 2015 at 23:24, Chenwei Cai caichenwei1...@gmail.com wrote:

 Sure Jack, but I have to send that to you on Monday, because that is not
 in my personal computer. I have installed Xilinx 14.7 on that computer and
 the model is being compiled now.


 El sábado, 6 de junio de 2015, Jack Hickish jackhick...@gmail.com
 escribió:

 in fact, can you send me your design and i'll check it works on 14.7.
 Some of the warnings you have are a bit concerning but i think they might
 just be related to some bit slicing you're doing in your model.

 Thanks,
 Jack

 On 5 June 2015 at 13:06, Jack Hickish jackhick...@gmail.com wrote:

 Hi Chenwei,

 I'll fix the verilog anyway to get rid of that erro, but I think
 you'll find that if you use 14.7 the error will go away. In any case, 14.7
 is the last version of ISE that Xilinx will release, so it's the one we're
 going to target in our libraries - it might be a good idea to upgrade your
 toolflow for this reason alone.

 Cheers,
 Jack

 On Fri, 5 Jun 2015 at 12:57 Chenwei Cai caichenwei1...@gmail.com
 wrote:

 Hi Jack,

 I am using Xilinx 14.5.

 On Fri, Jun 5, 2015 at 4:55 PM, Jack Hickish jackhick...@gmail.com
 wrote:

 Hi Chenwei,

 What version of the Xilinx tools are you using?
 I think this is easy to fix, but I'm surprised I didn't see this
 error when I compiled my test models.

 Cheers,
 Jack

 On Fri, 5 Jun 2015 at 12:02 Chenwei Cai caichenwei1...@gmail.com
 wrote:

 Thanks Jack,

 The qdr_transpose seems to work appropriately now. And I am now
 using the qdr_transpose block to construct my model which will be 
 executed
 with ROACH II, as you can check out in the following url:
 https://www.dropbox.com/s/1wcz0lhmjgcuwua/Screenshot%20from%202015-06-05%2015%3A35%3A44.png?dl=0.
 The library I am using is the one Jack merged last week (
 http://www.mail-archive.com/casper@lists.berkeley.edu/msg05947.html
 ).

 The compile goes smoothly, only to find an error at the last of
 compile. See the log below, which records the last part of compile.

 Running DRC.
 WARNING:PhysDesignRules:367 - The signal

  
 fft_corner_turner_v4_nuevo_asiaa_adc5g/fft_corner_turner_v4_nuevo_asiaa_adc5
g/fifo_din_buf181 is incomplete. The signal does not drive
 any load pins
in the design.
 WARNING:PhysDesignRules:367 - The signal

  
 fft_corner_turner_v4_nuevo_asiaa_adc5g/fft_corner_turner_v4_nuevo_asiaa_adc5
g/fifo_din_buf183 is incomplete. The signal does

Re: [casper] How to use the qdr_transpose and qdr_ct blocks?

[Jack Hickish]

 and the Q2 output pin of IFF is
 not
used.
 WARNING:PhysDesignRules:1441 - Issue with pin connections and/or
 configuration
on

  block:qdr0_controller/qdr0_controller/qdrc_infrastructure_inst/IDDR_qdr_q4
:ILOGICE1_IFF.  The IFFTYPE is DDR and the Q2 output pin of IFF is
 not
used.
 WARNING:PhysDesignRules:1441 - Issue with pin connections and/or
 configuration
on

  block:qdr0_controller/qdr0_controller/qdrc_infrastructure_inst/IDDR_qdr_q5
:ILOGICE1_IFF.  The IFFTYPE is DDR and the Q2 output pin of IFF is
 not
used.
 WARNING:PhysDesignRules:1441 - Issue with pin connections and/or
 configuration
on

  block:qdr0_controller/qdr0_controller/qdrc_infrastructure_inst/IDDR_qdr_q6
:ILOGICE1_IFF.  The IFFTYPE is DDR and the Q2 output pin of IFF is
 not
used.
 WARNING:PhysDesignRules:1441 - Issue with pin connections and/or
 configuration
on

  block:qdr0_controller/qdr0_controller/qdrc_infrastructure_inst/IDDR_qdr_q7
:ILOGICE1_IFF.  The IFFTYPE is DDR and the Q2 output pin of IFF is
 not
used.
 WARNING:PhysDesignRules:1441 - Issue with pin connections and/or
 configuration
on

  block:qdr0_controller/qdr0_controller/qdrc_infrastructure_inst/IDDR_qdr_q8
:ILOGICE1_IFF.  The IFFTYPE is DDR and the Q2 output pin of IFF is
 not
used.
 WARNING:PhysDesignRules:1441 - Issue with pin connections and/or
 configuration
on

  block:qdr0_controller/qdr0_controller/qdrc_infrastructure_inst/IDDR_qdr_q9
:ILOGICE1_IFF.  The IFFTYPE is DDR and the Q2 output pin of IFF is
 not
used.
 ERROR:PhysDesignRules:1763 - Issue with pin connections and/or
 configuration on

  block:qdr1_controller/qdr1_controller/qdrc_infrastructure_inst/IODELAY_sa20
:IODELAYE1_IODELAYE1.  For DELAY_SRC IO or O programming the ODATAIN
input pins of IODELAYE1 must be connected.
 ERROR:Bitgen:25 - DRC detected 1 errors and 63 warnings.  Please see the
previously displayed individual error or warning messages for more
 details.
 ===
 Flow run time summary: (00:27:41 seconds total)
 System update00:00:00
 Design Rules Check...00:00:00
 Xilinx System Generator..00:10:08
 Base system copy.00:00:00
 IP creation..00:00:00
 EDK files creation...00:00:06
 IP elaboration...00:00:00
 Software creation00:00:00
 EDK/ISE backend..00:17:26
 ===


 After the compile, the .bof.gz, .fpg, and .info files appear in the
 bit_file folder, but I fail to find the .bof file in that folder! Somebody
 encountered such a problem before or has some ideas about that?

 Thanks!



 On Mon, Apr 27, 2015 at 4:06 PM, Jack Hickish jackhick...@gmail.com
 wrote:

 Hi Chenwei,

 A couple of general comments --
 1. strictly speaking you should have xilinx gateway out blocks between
 the slice blocks and the scope, since the scope needs simulink (not xilinx)
 data types as input. Having said that, it'll probably work the way you have
 the design set up, it might issue warnings though.
 2. Block sizes of 2^2 probably work, but I'd recommend testing with
 something a little bigger in case there are some special cases which stop
 the small block size from behaving as expected.

 Now to explain (hopefully!) your results --

 The qdr transpose is really a reorder, that is, no rearrangement of the
 bits within the 36- bit words you're writing will ever take place. Thus, if
 the bottom 18 bits going in are always 2, the bottom bits of the output
 will also always be 2.

 It is a transpose in the sense that as each word comes in, it is written
 row by row in to a matrix with in_block_size columns, and out_block_size
 rows. It is then reordered such that it is read out column by column.

 Some hastily written python code showing how the output is related to the
 input (which may or may not be helpful):

 import pylab

 in_block_size = 2**3
 out_block_size = 2**4
 n_cycles = 4 #cycles to plot
 in_vec = range(in_block_size) * out_block_size * n_cycles
 out_vec = [0 for i in range(len(in_vec))]
 print 'in', in_vec
 for i in range(n_cycles):
   offset = i*in_block_size*out_block_size
   for col in range(in_block_size):
 for row in range(out_block_size):
   out_vec[offset + row + col*out_block_size] = in_vec[offset + col +
 row*in_block_size]

 print 'out:', out_vec
 pylab.subplot(2,1,1)
 pylab.title('in')
 pylab.plot(in_vec)
 pylab.subplot(2,1,2)
 pylab.title('out')
 pylab.plot(out_vec)
 pylab.show()

 I'm not sure I can entirely explain the output you get. (Ignoring the '2'
 in your LSBs, the block input is [0, 1, 2, 3, 4, 5, 6, 7, 0, 1, 2, ...]
 For an input and output block size of 4, [i think] the output should be:
 [0, 4, 0, 4, 1, 5, 1, 5, 2, 6, 2, 6, 3, 7, 3, 7, repeat].
 It doesn't seem to be quite that so I would suggest that either blocks
 that small don't work or (perhaps more

Re: [casper] How to use the qdr_transpose and qdr_ct blocks?

[Jack Hickish]

Hi Chenwei,

I'll fix the verilog anyway to get rid of that erro, but I think you'll
find that if you use 14.7 the error will go away. In any case, 14.7 is the
last version of ISE that Xilinx will release, so it's the one we're going
to target in our libraries - it might be a good idea to upgrade your
toolflow for this reason alone.

Cheers,
Jack

On Fri, 5 Jun 2015 at 12:57 Chenwei Cai caichenwei1...@gmail.com wrote:

 Hi Jack,

 I am using Xilinx 14.5.

 On Fri, Jun 5, 2015 at 4:55 PM, Jack Hickish jackhick...@gmail.com
 wrote:

 Hi Chenwei,

 What version of the Xilinx tools are you using?
 I think this is easy to fix, but I'm surprised I didn't see this error
 when I compiled my test models.

 Cheers,
 Jack

 On Fri, 5 Jun 2015 at 12:02 Chenwei Cai caichenwei1...@gmail.com wrote:

 Thanks Jack,

 The qdr_transpose seems to work appropriately now. And I am now using
 the qdr_transpose block to construct my model which will be executed with
 ROACH II, as you can check out in the following url:
 https://www.dropbox.com/s/1wcz0lhmjgcuwua/Screenshot%20from%202015-06-05%2015%3A35%3A44.png?dl=0.
 The library I am using is the one Jack merged last week (
 http://www.mail-archive.com/casper@lists.berkeley.edu/msg05947.html).

 The compile goes smoothly, only to find an error at the last of compile.
 See the log below, which records the last part of compile.

 Running DRC.
 WARNING:PhysDesignRules:367 - The signal

  
 fft_corner_turner_v4_nuevo_asiaa_adc5g/fft_corner_turner_v4_nuevo_asiaa_adc5
g/fifo_din_buf181 is incomplete. The signal does not drive any
 load pins
in the design.
 WARNING:PhysDesignRules:367 - The signal

  
 fft_corner_turner_v4_nuevo_asiaa_adc5g/fft_corner_turner_v4_nuevo_asiaa_adc5
g/fifo_din_buf183 is incomplete. The signal does not drive any
 load pins
in the design.
 WARNING:PhysDesignRules:367 - The signal

  
 fft_corner_turner_v4_nuevo_asiaa_adc5g/fft_corner_turner_v4_nuevo_asiaa_adc5
g/fifo_din_buf1113 is incomplete. The signal does not drive any
 load pins
in the design.
 WARNING:PhysDesignRules:367 - The signal

  
 fft_corner_turner_v4_nuevo_asiaa_adc5g/fft_corner_turner_v4_nuevo_asiaa_adc5
g/fifo_din_buf161 is incomplete. The signal does not drive any
 load pins
in the design.
 WARNING:PhysDesignRules:367 - The signal

  
 fft_corner_turner_v4_nuevo_asiaa_adc5g/fft_corner_turner_v4_nuevo_asiaa_adc5
g/fifo_din_buf163 is incomplete. The signal does not drive any
 load pins
in the design.
 WARNING:PhysDesignRules:367 - The signal

  
 fft_corner_turner_v4_nuevo_asiaa_adc5g/fft_corner_turner_v4_nuevo_asiaa_adc5
g/fifo_din_buf117 is incomplete. The signal does not drive any
 load pins
in the design.
 WARNING:PhysDesignRules:367 - The signal

  
 fft_corner_turner_v4_nuevo_asiaa_adc5g/fft_corner_turner_v4_nuevo_asiaa_adc5
g/fifo_din_buf131 is incomplete. The signal does not drive any
 load pins
in the design.
 WARNING:PhysDesignRules:367 - The signal

  
 fft_corner_turner_v4_nuevo_asiaa_adc5g/fft_corner_turner_v4_nuevo_asiaa_adc5
g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM11_RAMA_D1_DPO is
 incomplete. The
signal does not drive any load pins in the design.
 WARNING:PhysDesignRules:367 - The signal

  
 fft_corner_turner_v4_nuevo_asiaa_adc5g/fft_corner_turner_v4_nuevo_asiaa_adc5
g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM11_RAMB_D1_DPO is
 incomplete. The
signal does not drive any load pins in the design.
 WARNING:PhysDesignRules:367 - The signal

  
 fft_corner_turner_v4_nuevo_asiaa_adc5g/fft_corner_turner_v4_nuevo_asiaa_adc5
g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM11_RAMD_D1_O is incomplete.
 The
signal does not drive any load pins in the design.
 WARNING:PhysDesignRules:367 - The signal

  
 fft_corner_turner_v4_nuevo_asiaa_adc5g/fft_corner_turner_v4_nuevo_asiaa_adc5
g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM3_RAMC_D1_DPO is
 incomplete. The
signal does not drive any load pins in the design.
 WARNING:PhysDesignRules:367 - The signal

  
 fft_corner_turner_v4_nuevo_asiaa_adc5g/fft_corner_turner_v4_nuevo_asiaa_adc5
g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM3_RAMD_D1_O is incomplete.
 The
signal does not drive any load pins in the design.
 WARNING:PhysDesignRules:367 - The signal

  
 fft_corner_turner_v4_nuevo_asiaa_adc5g/fft_corner_turner_v4_nuevo_asiaa_adc5
g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM14_RAMB_D1_DPO is
 incomplete. The
signal does not drive any load pins in the design.
 WARNING:PhysDesignRules:367 - The signal

  
 fft_corner_turner_v4_nuevo_asiaa_adc5g/fft_corner_turner_v4_nuevo_asiaa_adc5
g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM14_RAMC_D1_DPO is
 incomplete. The
signal does not drive any load pins in the design.
 WARNING:PhysDesignRules:367 - The signal

  
 fft_corner_turner_v4_nuevo_asiaa_adc5g/fft_corner_turner_v4_nuevo_asiaa_adc5
g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM14_RAMD_D1_O is incomplete.
 The
signal does not drive any load pins in the design

Re: [casper] How to use the qdr_transpose and qdr_ct blocks?

[Jack Hickish]

Hi Chenwei et al.

Commit 082b13caee in the casper-astro-soak-test branch now allows
calibration of QDRs even when the fabric is writing to the whole QDR memory
space. It does this my allowing the software interface to disable simulink
writes whilst calibration is taking place.
To use this functionality, you'll need to use both the updated pcore and
calibration software in this commit.

Cheers,
Jack

On Tue, 9 Jun 2015 at 10:00 Chenwei Cai caichenwei1...@gmail.com wrote:

 Hi Jack,

 Yes, it works now! I have obtained the .bof file from the new compilation.
 Thanks so much for your suggestions and help. I will try to calibrate qdr
 with the script you provided in my next step.

 Best Regards
 Chenwei CAI

 Email: caichenwei1...@pku.edu.cn


 On Tue, Jun 9, 2015 at 4:24 AM, Jack Hickish jackhick...@gmail.com
 wrote:

 Hi Chenwei,

 I had a look at your model - the error will go away if you select the
 enable CPU interface option in your qdr yellow blocks. Regardless of your
 error, enabling the cpu interface is necessary because it is used for
 calibrating the qdr on roach2 (this was not the case on roach1) using the
 script in the mlib_devel repo.
 Note that currently calibrating the qdr requires software writes to occur
 in the top half of the memory without being interfered with by the fabric
 (aka simulink) qdr interface. QDR calibration will fail if you attempt to
 calibrate whilst the fabric is writing to the top half of the qdr memory
 space, so when using more than 20 bits of the address line, you'll need a
 way to halt the simulink interface during calibration.
 Tomorrow I'll try and modify the qdr controller so that it can override
 the simulink interface during calibration, since currently this is an
 unnecessary user hassle.

 Cheers,
 Jack

 On 8 June 2015 at 10:38, Chenwei Cai caichenwei1...@gmail.com wrote:

 Hi Jack,

 I have encountered the same problem with Xilinx 14.7. See the log,

 ERROR:PhysDesignRules:1763 - Issue with pin connections and/or
 configuration on

  
 block:qdr1_controller/qdr1_controller/qdrc_infrastructure_inst/IODELAY_sa20
:IODELAYE1_IODELAYE1.  For DELAY_SRC IO or O programming the
 ODATAIN
input pins of IODELAYE1 must be connected.
 ERROR:Bitgen:25 - DRC detected 1 errors and 63 warnings.  Please see the
previously displayed individual error or warning messages for more
 details.
 ===
 Flow run time summary: (01:08:07 seconds total)
 System update00:00:00
 Design Rules Check...00:00:00
 Xilinx System Generator..00:52:02
 Base system copy.00:00:00
 IP creation..00:00:00
 EDK files creation...00:00:05
 IP elaboration...00:00:00
 Software creation00:00:00
 EDK/ISE backend..00:15:58
 ===

 Maybe I truly need your help on this. And here is my model,
 https://www.dropbox.com/s/oiawxtux7syt0jv/fft_corner_turner_v4_nuevo.slx?dl=0
 . There is one self-defined block, filt_sample, within the model, which can
 be obtained an added through this url,
 https://www.dropbox.com/sh/qckqor5hw8if0rv/AAB_SGyCoBsgDHk-8YfpPKlma?dl=0
 .

 Thanks for your help!

 On Sat, Jun 6, 2015 at 3:43 AM, Jack Hickish jackhick...@gmail.com
 wrote:

 no rush - let me know how the compile goes!

 cheers
 jack

 On 5 June 2015 at 23:24, Chenwei Cai caichenwei1...@gmail.com wrote:

 Sure Jack, but I have to send that to you on Monday, because that is
 not in my personal computer. I have installed Xilinx 14.7 on that computer
 and the model is being compiled now.


 El sábado, 6 de junio de 2015, Jack Hickish jackhick...@gmail.com
 escribió:

 in fact, can you send me your design and i'll check it works on 14.7.
 Some of the warnings you have are a bit concerning but i think they might
 just be related to some bit slicing you're doing in your model.

 Thanks,
 Jack

 On 5 June 2015 at 13:06, Jack Hickish jackhick...@gmail.com wrote:

 Hi Chenwei,

 I'll fix the verilog anyway to get rid of that erro, but I think
 you'll find that if you use 14.7 the error will go away. In any case, 
 14.7
 is the last version of ISE that Xilinx will release, so it's the one 
 we're
 going to target in our libraries - it might be a good idea to upgrade 
 your
 toolflow for this reason alone.

 Cheers,
 Jack

 On Fri, 5 Jun 2015 at 12:57 Chenwei Cai caichenwei1...@gmail.com
 wrote:

 Hi Jack,

 I am using Xilinx 14.5.

 On Fri, Jun 5, 2015 at 4:55 PM, Jack Hickish jackhick...@gmail.com
  wrote:

 Hi Chenwei,

 What version of the Xilinx tools are you using?
 I think this is easy to fix, but I'm surprised I didn't see this
 error when I compiled my test models.

 Cheers,
 Jack

 On Fri, 5 Jun 2015 at 12:02 Chenwei Cai caichenwei1...@gmail.com
 wrote:

 Thanks Jack,

 The qdr_transpose seems to work appropriately now. And I am now
 using the qdr_transpose block to construct my model which

Re: [casper] System Compatibility

[Jack Hickish]

Hi Victor,

I strongly recommend using Xilinx's 14.7 release. Some people use Ubuntu
12.04 -- see
https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.x_and_Matlab_2012b
-- but as Dan says, life might be easier with a supported operating
system...

Cheers,
Jack

On Tue, 23 Jun 2015 at 13:01 Dan Werthimer d...@ssl.berkeley.edu wrote:



 hi victor,

 i urge people to only use operating systems supported by xilinx:
 i think right now, that means
 windows7 pro, redhat enterprise linux 5 or 6, or suse enterprise linux.

 several casperites have tried to use non-supported linux operating systems
 for casper work.
 sometimes this can work fine for particular appliciations, sometimes it
 doesn't work.

 xilinx will not provide any support or answer any questions if you use a
 non-supported operating system. and we've seen be subtle bugs
 without any reported error messages with a non-supported operating system.
 one time we found the casper FFT didn't work for sizes over 2^13 points -
 there was no
 error message - it just computed the FFT incorrectly on the FPGA - the
 simulation
 worked fine...  when we switched to redhat, the problem went away...

 best wishes,

 dan




 On Tue, Jun 23, 2015 at 12:48 PM, Victor Cardoso 
 victorcardoso...@hotmail.com wrote:

 Greetings,

 I am working with the ROACH 2 in order to implement the MUSIC project. I
 am having a lot of troubles to compile the Tutorial 1 (Introduction to
 Simulink) due to mismatch between Xilinx ISE 14.5 and my Operating System,
 Ubuntu 10.04.
 I would like to know if it's possible to run this example using Ubuntu.
 Otherwise, I can install Redhat Enterprise Linux 6.3, Matlab 12b and Xilinx
 14.5 to run the codes.

 I look forward hearing from you.

 Best Regards,
 Victor Cardoso.

Re: [casper] Call for awesome commits

[Jack Hickish]

Howdy,

I've just merged a bunch of stuff into the casper-astro repository. I
haven't yet merged it into master, but it's the casper-astro-soak-test --
https://github.com/casper-astro/mlib_devel/tree/casper-astro-soak-test

I'm going to run a few compiles against it next week to check all is well.

Highlights, and major changes:

- Merged sma-wideband
- Merged github
- Added/updated x64 adc and mkid adc/dac for ROACH2
- Added UCF yellow block
- Updated QDR interface
- Added software in mlib_devel/xps_support_sw for QDR calibration
- Removed spaces from yellow block names (This will almost certainly cause
your MSSGE block to become unlinked. update_casper_blocks(bdroot) should
fix this. And is probably a good idea if you're updating your libraries
anyway)

I've tried the QDR calibration between 120MHz and 325 MHz with good
results. Any feedback bug reports welcome.

Cheers,
Jack


On Wed, 27 May 2015 at 21:35 Jack Hickish jackhick...@gmail.com wrote:

 Hi All,

 I believe I have a version of the QDR block / software that works at
 every conceivable clock frequency anyone could want. Tomorrow
 (Berkeley time), I'm going to merge this into the main casper-astro
 github repository. This seems like as good a time as any to ask: does
 anyone have any bugfixes/features/new blocks they would like to add to
 the main repository? So far I've got the following

 -- everything in ska-sa as of now. (I based my fix off ska-sa:master)
 -- tweaked qdr interface
 -- remove spaces from xps blocks (because that now throws errors)
 -- add a ucf yellow block to add custom constraints to models

 If you have suggestions/requests, feel free to raise github pull
 requests or email me repo addresses / commit hashes / patches / other
 useful info. If you want to contribute something but aren't sure
 exactly how best to do this, just drop me an email and we'll figure
 something out!

 Cheers,
 Jack

[casper] Call for awesome commits

[Jack Hickish]

Hi All,

I believe I have a version of the QDR block / software that works at
every conceivable clock frequency anyone could want. Tomorrow
(Berkeley time), I'm going to merge this into the main casper-astro
github repository. This seems like as good a time as any to ask: does
anyone have any bugfixes/features/new blocks they would like to add to
the main repository? So far I've got the following

-- everything in ska-sa as of now. (I based my fix off ska-sa:master)
-- tweaked qdr interface
-- remove spaces from xps blocks (because that now throws errors)
-- add a ucf yellow block to add custom constraints to models

If you have suggestions/requests, feel free to raise github pull
requests or email me repo addresses / commit hashes / patches / other
useful info. If you want to contribute something but aren't sure
exactly how best to do this, just drop me an email and we'll figure
something out!

Cheers,
Jack

Re: [casper] System Compatibility

[Jack Hickish]

Hi Vishwa,

To add to what Danny said, while there will never be a Vivado flow for
ROACH1/ROACH2, I've been using a vivado-based flow for the SNAP board,
which is a kintex-7 platform. Some very limited information about how to
obtain and run the flow, aimed at our local (in berkeley) SNAP users is
available at https://casper.berkeley.edu/wiki/SNAP_Bringup

Cheers,
Jack

On Wed, 1 Jul 2015 at 08:41 Danny Price dpr...@cfa.harvard.edu wrote:

  Hi Vishwa

 As far as I’m aware, Vivado does not support Virtex 5 or 6, so can’t be
 used for ROACH1 or ROACH2 designs.

 The Xilinx + Matlab stack is hard enough to get working on officially
 sanctioned distribution, so using RHEL7 will probably just give you
 stability issues and installation woes. For a compilation machine,
 stability is *by far* more important than having a newer OS.

 That said, I’m guessing that RHEL7 would probably work fine, and that the
 install process would essentially be the same. Only one way to find out…

 Regards
 Danny



  On Jul 1, 2015, at 11:17 AM, Vishwa Seneviratne mp...@zips.uakron.edu
 wrote:

 Hi,

 Has anyone tried installing Xilinx ISE 14.7 in RHEL 7? Is there a way to
 do so?

 Also, I wonder if Casper roach developers have plans to come up with a
 MSSGE toolflow set that support Vivado Design suite in near future since,
 Xilinx has discontinued developing Xilinx ISE.

 Very respectfully,

 Regards,
 Vishwa

 On Tue, Jun 30, 2015 at 2:54 PM, Mark Wagner m...@anown.netwrote:

 Hi Victor,

 It looks like you don't have your matlab path setup correctly.  Have you
 checked out this page:
 https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.x_and_Matlab_2012b

 Mark


 On Tue, Jun 30, 2015 at 11:28 AM, Victor Cardoso 
 victorcardoso...@hotmail.comwrote:

 Thank you all for your support.

 After hearing from you, I decided to change my OS to Red Hat Workstation
 6. Unfortunately, the bugs persisted.
 When I try to launch the System Generator on Simulink I receive this
 message:
 -- Error Evaluating 'OpenFcn' callback of Xilinx System Generator Block
 block (mask) 'untitled/ System Generator'. --Undefined variable com or
 class com.xilinx.sysgen.util.StrategyUtil.loadAllStrategyNames.

 Additionally, when I type sysgen at the terminal, I get this message:
 [   INFO   ] XILINX_DSP environment variable does NOT coincide with
 $XILINX. Resetting...
 /opt/Xilinx/14.7/ISE_DS/ISE/sysgen/util/sysgen: line 1176: matlab:
 command not found

 How should I proceed at this point?

 I appreciate your attention,
 Victor Cardoso.

 PS: I'm running matlab 2012b, Xilinx ISE 14.7 and Red Hat Workstation
 6.6.
  --
 From: jsm...@ska.ac.za
 Date: Wed, 24 Jun 2015 07:11:47 +0200
 Subject: Re: [casper] System Compatibility
 To: mwag...@ssl.berkeley.edu
 CC: victorcardoso...@hotmail.com; casper@lists.berkeley.edu


 Hi Victor,

 We used to use Ubuntu 14.04, and it kind of worked, but it wasn't
 stable. Switched to the most recent version of CentOS about a month ago and
 haven't had problems since.

 Xilinx v14.7, Matlab 2012b.

 Regards,
 James


 On Wed, Jun 24, 2015 at 1:10 AM, Mark Wagner mwag...@ssl.berkeley.edu
 wrote:

  Hi Victor,

 A list of supported operating systems is here on page 7:

 http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_5/irn.pdf

 If you need free, a much safer alternative to Ubuntu (but still
 unsupported) is CentOS 6.5, which is built from RHEL6 source packages.

 Mark



 On Tue, Jun 23, 2015 at 12:48 PM, Victor Cardoso 
 victorcardoso...@hotmail.comwrote:

 Greetings,

 I am working with the ROACH 2 in order to implement the MUSIC project. I
 am having a lot of troubles to compile the Tutorial 1 (Introduction to
 Simulink) due to mismatch between Xilinx ISE 14.5 and my Operating System,
 Ubuntu 10.04.
 I would like to know if it's possible to run this example using Ubuntu.
 Otherwise, I can install Redhat Enterprise Linux 6.3, Matlab 12b and Xilinx
 14.5 to run the codes.

 I look forward hearing from you.

 Best Regards,
 Victor Cardoso.

Re: [casper] QDR ROACH2: clocking at 145 MHz

[Jack Hickish]

Hi JP,

What mlib_devel are you using? Did you actually build against commit
72d879c? I noticed you emailed a link to my repository which I specifically
tweaked for my higher (312MHz) work, which I'm sure breaks *everything* at
145.

Cheers,
Jack

On Fri, 22 May 2015 at 06:41 Juan-Pierre Jansen van Rensburg 
jvrensburg...@gmail.com wrote:

 Hi all,

 I'm trying to get the QDR on the ROACH-2 to work reliably at a clock speed
 of a 145 MHz. I'm assuming this is possible, since it has been pointed out
 in an earlier message
 http://www.mail-archive.com/casper%40lists.berkeley.edu/msg05736.html
 that the QDR should work above 120 MHz?

 I'm running the software calibration for the QDR (qdr_cal() in the qdr.py
 script) and the calibration seems to be successful, however after the
 calibration I write test patterns to the QDR but the data I read back is
 incorrect. What is  strange is that it doesn't do it for all the test
 patterns, mainly for the walking 0's and pseudo random numbers, and QDR0
 and QDR1 seem to be the main culprits for failure. I also don't have any
 QDR glitches at higher clock speeds (for instance at 200 MHz).

 I have been digging around and found this
 https://github.com/jack-h/mlib_devel/commits/ami-devel?page=8 possible
 solution (see commit 72d879c). The REFCLK for the IDELATCTRL is set to a
 100 MHz instead of the recommended 200 MHz. I have tried this, but I still
 get errors. I'm not sure if this is relevant but with this suggestion I
 have only found errors so far on QDR1?

 Does anyone have any suggestions?

 Thanks,
 JP van Rensburg

Re: [casper] 5GS/s ADC compile errors

[Jack Hickish]

Hi Michael,
Glad you got that working.
I created the soak-test branch a couple of months ago when I merged various
repositories into casper-astro and attempted to make some new fixes to the
qdr. Since its creation, I and a few others have been using the branch. At
this point I think it's ready to be merged into master.
I'll probably do that next week sometime, unless there are objections...
Thanks,
Jack

On Sat, 15 Aug 2015 2:09 pm Michael D'Cruze 
michael.dcr...@postgrad.manchester.ac.uk wrote:

 Hi Jack, Primiani,



 That seems to have worked – thanks.



 Is this particular branch a beta-test version for fixes before they become
 mainstream?



 Cheers

 Michael



 *From:* Jack Hickish [mailto:jackhick...@gmail.com]
 *Sent:* 13 August 2015 19:06
 *To:* Michael D'Cruze; casper@lists.berkeley.edu
 *Subject:* Re: [casper] 5GS/s ADC compile errors



 Hi Michael,


 This is fixed by commit 404989f. It's in the casper-astro-soak-test branch
 of https://github.com/casper-astro/mlib_devel
 There's a bunch of other fixes in this branch, so I would suggest using
 it. At some point in the hopefully near future it will become the standard
 casper-astro master branch.



 Cheers,
 Jack

 On Thu, 13 Aug 2015 at 10:50 Michael D'Cruze 
 michael.dcr...@postgrad.manchester.ac.uk wrote:





 Hello,



 I’m getting an error on compiling a spectrometer design which I’m having
 trouble understanding. The following appears in the command line interface:



 ERROR:PhysDesignRules:2506 - Incorrect placement for a BUFR component.
 BUFR

 mdl_bbox_quant_asiaa_adc5g/mdl_bbox_quant_asiaa_adc5g/DIVBUF in clock
 region CLOCKREGION_X0Y7 is driven by a CCIO

 adc0clk_p in clock region CLOCKREGION_X0Y5. The BUFR should be placed in
 the same clock region as the CCIO or the

 CLOCK_DEDICATED_ROUTE constraint should be used on the net

 mdl_bbox_quant_asiaa_adc5g/mdl_bbox_quant_asiaa_adc5g/adc_clk.

 ERROR:Pack:1642 - Errors in physical DRC.



 It reads to me as if there’s something wrong with the ADC block
 internally, but as I’ve got a very recent commit I can’t see how that could
 be, especially given the number of people using this block…



 For completeness, I’m using a 2048 MHz ADC clock in single channel mode
 (for 2048 MHz input bandwidth) and have set the fabric clock to 4096/16=256
 MHz running off the ADC clock. The actual ADC is in ZDOK0.



 Any help would be greatly appreciated; I can only see one error similar to
 this on the mail archive and it seemed to have been fixed in a subsequent
 mlib_devel commit.



 Thanks


 Michael

Re: [casper] Roach-2 crashing fix

[Jack Hickish]

Hi all,

To close out this thread, a fix is to add a mem= option to uboot's
bootargs variable ---

1. Connect a PC to the ROACH2's FTDI USB port using a usb A-B cable.
2. Open a serial console on the roach 2 using
minicom/picocom/your-favourite-serial-console. The interface settings
are 115200,N,8.
If you're using a linux PC and don't have other things connected, the
device will be ttyUSB2.
3. Reboot your roach. You should see the reboot in your serial console.
When prompted, hit any key to halt the boot sequence.
4. Manually add a mem option to your bootargs with:
setenv bootargs $bootargs mem=$mem
(This assumes you have a mem variable already set with the correct value.
Otherwise you could use mem=512M)
5. Save the new variable with:
saveenv
6. Reboot your roach. If you log in to the PowerPC and run top or look in
/proc/meminfo you should now see the correct quantity of ram.

Cheers,
Jack

On Wed, 24 Jun 2015 at 16:50 John Ford jf...@nrao.edu wrote:

 Hi all.

 We were having problems with multiple sequentail progdev calls failing on
 our ROACH-2 systems.  We were testing multiple bof files in a loop, and
 the roach would fall over and crash completely, and after the kernel
 panic, it would reboot itself.

 After a great deal of concentrated debugging effort this afternoon by
 Jack, David, Justin, Ryan, Arindam, Randy, and me, the cause of the
 crashing upon multiple progdev calls was found.  It turned out to have
 nothing to do with programming the chip, rather it was a problem with
 memory allocation by the operating system.  Jack found that problem could
 also be caused by allocating a huge array in Python, using lots of memory.

 The problem was caused by the kernel thinking that the ROACH has 768 MB of
 memory on board, when in fact it has only 512 MB.  The fix is to pass the
 real amount of memory to the kernel in the bootargs.  the systems have
 been mostly working for a long time (Years!), so you may want to check
 that your systems know in fact how much memory they have.  If you start up
 top you can see what it thinks, or look in /proc/meminfo.

 John

Re: [casper] 10Gbe transmission on roach 1

[Jack Hickish]

Hi Kaustubh,

Have you set the option in the tgev2 yellow block to enable large tx frames?
Do the receive the packets with the size you're expecting (I.e. is the EOF
synchronisation logic working properly)
Cheers,
Jack

On Tue, 11 Aug 2015 6:18 am Kaustubh Rajwade rkaustub...@gmail.com wrote:

 Hi Jason,

 Thanks for that insight. The design is working fine for packet length of
 800. Anything beyond that and the core locks up. The tx_over is high
 suggesting that the tx_buffers overflow for packet length greater than 800.
 For my application, a size of 800 is sufficient but was just curious as to
 why the core would lock up for higher packet lengths when the clock speed
 of the board is less than the clock of the 10 GBe core.

 Thanks a lot for the help!

 Cheers,
 Kaustubh

 On Thu, Aug 6, 2015 at 8:47 PM, indrajit indra...@iiap.res.in wrote:

 Dear Kaustubh,

 Sorry for the  delay.

 The data rate goes like this as per your input ..


 5.7142 us is the time taken for 800 clock cycles @ 140 MHz.

 So the data rate calculation goes by the 8/10 coding technique .

 where assuming  42 bytes  is the UDP header size.


  (((100/5.71428) *(800*8) ) + 42 )*10 bits   = ~11.20 Gbit.

 You were exceeding the through put limitations.


 Cheers

 Indrajit.


 On Tuesday 04 August 2015 06:37 PM, Kaustubh Rajwade wrote:

 Hi Indrajit,

 So I am using the iadc which I am clocking at 560 MHz (hence the board
 runs at 140 MHz). The data comes in to a 10 GBe block. After 800 clock
 cycles, I send an eof to the block. Thats pretty much it. The idea is to
 just free stream the data continuously without any break. For a packet
 length of 800 or less, this works fine. For a longer packet length the core
 locks up.

 Kaustubh

 On Tue, Aug 4, 2015 at 7:33 AM, indrajit indra...@iiap.res.in wrote:

 Dear Kaustubh,


 Can you describe your system block diagram,

 What ADC, what exactly you want to do ..

 --Indrajit



 On Tuesday 04 August 2015 12:57 PM, Kaustubh Rajwade wrote:

 Yes, but I think that in their case they are running the board at 200
 MHz which is greater than 156 MHz. In this case, it is less than 156 so the
 design should work fine. Am I missing something? Does it have something to
 do with the 8/10 encoding such that the effective clock rate of the 10 Gbe
 is less than 156 MHz?

 Let me know.

 Thanks,
 Kaustubh

 On Tue, Aug 4, 2015 at 12:13 AM, indrajit indra...@iiap.res.in wrote:


 Dear Kaustubh,

 please go through this page

 https://casper.berkeley.edu/wiki/Tutorial_10GbE


 search for Add a counter to limit the data rate 

 In that they mentioned about the limitations.

 1) You want to stream the data continuously at 140 MHz using 10GBe. ?




 Hi All,

 I have a simple design on Roach 1 where I stream packets over the 10Gbe
 network. Currently, I am running the board at 140 MHz. When I try to
 send
 packets of length 800, the core locks up. I believe that the 10 Gbe
 core
 is synchronized with 156 MHz crystal on the board so this design should
 work fine on a lower clock rate.

 Can someone shed some light on this?

 Thanks,

 Cheers,
 Kaustubh









 --
 Thanks and regards
 __
 Indrajit Vittal Barve

 Engineer,
 Radio Astronomy Group,
 Indian Institute of Astrophysics,
 Gauribidanur.
 Pin : 561208
 Mobile : +91-9845432754.
 Office : +91-8155291655.




 --
 Thanks and regards
 __
 Indrajit Vittal Barve

 Engineer,
 Radio Astronomy Group,
 Indian Institute of Astrophysics,
 Gauribidanur.
 Pin : 561208
 Mobile : +91-9845432754.
 Office : +91-8155291655.

Re: [casper] 5GS/s ADC compile errors

[Jack Hickish]

Hi Michael,


This is fixed by commit 404989f. It's in the casper-astro-soak-test branch
of https://github.com/casper-astro/mlib_devel
There's a bunch of other fixes in this branch, so I would suggest using it.
At some point in the hopefully near future it will become the standard
casper-astro master branch.



Cheers,
Jack

On Thu, 13 Aug 2015 at 10:50 Michael D'Cruze 
michael.dcr...@postgrad.manchester.ac.uk wrote:





Hello,



I’m getting an error on compiling a spectrometer design which I’m having
trouble understanding. The following appears in the command line interface:



ERROR:PhysDesignRules:2506 - Incorrect placement for a BUFR component. BUFR

mdl_bbox_quant_asiaa_adc5g/mdl_bbox_quant_asiaa_adc5g/DIVBUF in clock
region CLOCKREGION_X0Y7 is driven by a CCIO

adc0clk_p in clock region CLOCKREGION_X0Y5. The BUFR should be placed in
the same clock region as the CCIO or the

CLOCK_DEDICATED_ROUTE constraint should be used on the net

mdl_bbox_quant_asiaa_adc5g/mdl_bbox_quant_asiaa_adc5g/adc_clk.

ERROR:Pack:1642 - Errors in physical DRC.



It reads to me as if there’s something wrong with the ADC block internally,
but as I’ve got a very recent commit I can’t see how that could be,
especially given the number of people using this block…



For completeness, I’m using a 2048 MHz ADC clock in single channel mode
(for 2048 MHz input bandwidth) and have set the fabric clock to 4096/16=256
MHz running off the ADC clock. The actual ADC is in ZDOK0.



Any help would be greatly appreciated; I can only see one error similar to
this on the mail archive and it seemed to have been fixed in a subsequent
mlib_devel commit.



Thanks


Michael

Re: [casper] Roach2 aux clocking and Bram's

[Jack Hickish]

Hi Vereese,

Adding an iadc block will (I think, having just checked the adc yellow
block code) change the number or software devices on the OPB bus, so could
affect the problem if Dave's first hypothesis is correct. Having said that,
your test using sys_clk, as long as you left all the yellow blocks in your
design the same, won't change the number of OPB devices so I think that
exonerates the OPB bus. It seems to me that it's very unlikely that there's
a problem that hasn't been noticed before that affects only certain OPB
devices, and would show up at 155 MHz but not 100.
Probably you already know this, but you should be able to clock off
something close to your desired frequency by using sys_clk and setting the
rate to 155. The toolflow will try to generate a clock of this frequency by
multiplying/dividing the 100MHz onboard oscillator. I think the matlab
prompt will print a line at the start of the compile telling you what clock
speed it's managing to generate.

My inclination is to blame the yellow block - are all the clock constraints
set up right? are there any MMCMs whose locked signals you can tie to
software registers? If you run roach.est_board_clk() does it suggest your
board is actually running at the speed you think?

Cookie kebabs when you solve the problem,

Jack

On Wed, 5 Aug 2015 at 10:49 Vereese Van Tonder vton...@nrao.edu wrote:

 Hi Andrew, Dave and Wes,

 Thanks for all the advice, I have a lot of things that I can test again
 now.

 I'm currently using the casper_astro_soak_test mlib_devel repository, I'll
 see the SKA-SA mlib_devel for the fix on the aux_clk. When I ran the
 aux_clk design at 143MHz the XSG_core_config configured the MULTIPLY and
 DIVIDE to be 8. It said the FVCO = 500MHz and it gave the formula as:
 FVCO = (1000*CLKFBOUT_MULT_F)/(CLKIN1_PERIOD*DIVCLK_DIVIDE)
 However the hard coded values for  CLKFBOUT_MULT_F = 6, DIVCLK_DIVIDE = 1
 and using a CLK_FREQ = 143 then CLKIN1_PERIOD = 1000/143 ~ 6.99 then FVCO =
 858MHz and not 500MHz.

 I've only tested the design on one ROACH2 board, I'll test it with another
 board as well. If I lower the input clock frequency to 145 MHz and then
 turn it back up to 155.52 MHz then the output is as expected.

 I saw that the different brams are accessed via different opb's, however I
 couldn't see any correlation between specific opb's and correct data from
 the brams. I'll continue to compare these though.

 Thanks so much for everyone's help  - I really appreciate it.
 Vereese

 On 08/05/2015 04:21 AM, Wesley New wrote:

 The problem here is that the FVCO is not within the range of 600MHz to
 1600MHz. This is an MMCM configuration issue as Dave has already mentioned.

 I have recently fixed a similar bug in the SKA-SA mlib_devel repository.
 Is this the repository that you are using?

 I have tested the aux clock on this repository between 100MHz and 200MHz.

 Thanks

 Wes


 Wesley New
 South African SKA Project
 +2721 506 7300
 www.ska.ac.za



 On Tue, Aug 4, 2015 at 11:41 PM, David MacMahon dav...@astro.berkeley.edu
  wrote:

 Hi, Vereese,

 That's a very curious failure mode!  It's very interesting that
 everything worked fine when clocking via iADC, but not when clocking via
 your mezzanine board (or aux_clk) even though the fabric clock rate was the
 same.  I can think of two possible theories for what's going on (both
 alluded to in your email).

 The first theory is that the problem is somehow related to the address
 mapping.  Maybe under certain circumstances the memory map works out such
 that bram7 is accessed via an extra opb_to_opb bridge (or some other slight
 variation) compared to the other brams?  It would be interesting to compare
 the system.mhs and core_info.tab files for your various test builds so
 what's different between working builds and non-working builds.  What if
 you add additional unrelated BRAMs such that they appear earlier in the
 address map (maybe give them a lexicographically early name like
 aaa_bram0) or maybe enlarge the existing BRAMs?  That might push bram6
 (and others?) into the hypothetically troublesome address range.  Maybe
 clocking from the iADC changed the address map such that this hypothesized
 problem was avoided.

 The other theory is that some sort of MMCM (mis-)configuration is causing
 the MMCM to behave in a weird way.  I don't know what kind of problem that
 would be.  I've only seen issues when trying to use the ISERDES resources
 at fairly high bit rates, but the ~155 MHz clock should be fine.  I think
 the MMCM config options are shown in the system_map.mrp file, so maybe
 comparing working vs non-working versions of those files would be
 illuminating.

 When you tried to run aux_clk at faster than 143 MHz, what values did you
 use for MULTIPLY and DIVIDE?  It looks like the defaults would result in
 the same settings as the hardcoded values (with the exception of CLKOUT5)
 .  I think the MULTIPLY and DIVIDE parameters are intended to be used for
 sys_clk, so I'm not 

[casper] GNU Radio

[Jack Hickish]

Hi all,

At the end of August there is a GNU Radio conference in Washington DC (
http://www.trondeau.com/gnu-radio-conference-2015/) which myself and a few
folk from Green Bank (I believe Richard Prestage, Mark Whitehead and Joe
Brandt) were going to attend.

Are any CASPERites thinking of going? Is anyone in the CASPER community
currently using GNU Radio in a scientific capacity either on its own or
within a larger CASPER set up? If so I/we'd be very interesting in chatting
with you!

Cheers,
Jack

Re: [casper] Migrating to Roach 2 from Roach 1

[Jack Hickish]

Hi Paul,

The toolflow remains the same, you just get more FPGA / QDR / IO -- in
principle you just change the platform from ROACH to ROACH2, recompile, and
you're good to go. In practice, there's usually a few tweaks you'd need to
make depending what on-board resources you have used. Eg.

Gpio / QDR / 10GbE blocks will need their parameters changing to match the
roach2, note that ROACH2 has a different width QDR interface, and needs a
software calibration script to run on programming to make the QDR link work.
If you're using a rare-ish ADC, you might find that the yellow block
doesn't exist for ROACH2 -- it's usually easy to port these, and most have
been done already.

You can always compile your design for ROACH2 before you get the hardware
and discover any potential pitfalls.

Personally, I would say, if you're expanding an existing ROACH1-based
instrument, just buy some more R1s (maybe someone on the maillist can get
you some second hand ones on the cheap). If you're just increasing your
stock of lab equipment and might have more demanding tasks on the horizon
(the ability to use SFP+ 10GbE links is a big win), perhaps you should go
for ROACH2, but it's not going to be *too* long before ROACH3's are around,
and SNAP is coming up to being production-ready.

Cheers,
Jack

On Fri, 23 Oct 2015 at 23:52 Paul Davis  wrote:

> We currently have a few Roach1's but we need to get more.  Is there any
> reason to change to the Roach 2?  The Roach1 already does everything we
> need so we don't need the increased capabilities.  Does the toolflow change
> at all?  From what I can see I just need to recompile with a new device. Is
> this true?
>

Re: [casper] startsg issue (Xilinx?)

[Jack Hickish]

Seconded -- http://www.xilinx.com/support/answers/17966.html suggests
MATLAB 2013a and anything before ISE 14.7 (although 14.6 works on windows
-- yay!) isn't a supported combination.

On Sun, 15 Nov 2015 at 19:22 John Ford  wrote:

> > Hi all,
> >
> > As part of my attempts to narrow down the cause of the FFT problems I'm
> > having (well-documented), I'm trying different versions of ISE. I want to
> > try most of the 14.x versions plus some rather older versions.
> >
> > I've installed the versions I want to try but when I change the
> > startsg.local file for any version other than 14.7 I get the error
> > displayed at the bottom of this email. A similar issue appears on the
> mail
> > archive but this was apparently solved by reinstalling Xilinx ISE. This
> > hasn't worked for me. I have also tried deleting the entire /opt/Xilinx
> > folder and reinstalling *only* the older version. This also did not work.
> > MATLAB still successfully starts when startsg.local is looking for ISE
> > 14.7.
> >
> > This seems a rather silly error and would seem to be something to do with
> > the startup scripts, though I can't immediately see any problems. I'd be
> > grateful for any suggestions...
>
> The system is sensitive to matlab-xilinx version matching.  Some play
> nicely together, and some don't.
>
> I'd try using an earlier version of matlab.  See the casper web page for
> suggested combinations.
>
> John
> >
> > Cheers
> > Michael
> >
> > Error:
> >
> >
> >
> > 
> >
> >Segmentation violation detected at Sun Nov 15 18:51:19 2015
> >
> > 
> >
> >
> >
> > Configuration:
> >
> >   Crash Decoding : Disabled
> >
> >   Current Visual : 0x21 (class 4, depth 24)
> >
> >   Default Encoding   : UTF-8
> >
> >   GNU C Library  : 2.12 stable
> >
> >   MATLAB Architecture: glnxa64
> >
> >   MATLAB Root: /opt/MATLAB/2013a
> >
> >   MATLAB Version : 8.1.0.604 (R2013a)
> >
> >   Operating System   : Linux 2.6.32-573.8.1.el6.x86_64 #1 SMP Fri Sep 25
> > 19:24:22 EDT 2015 x86_64
> >
> >   Processor ID   : x86 Family 6 Model 45 Stepping 7, GenuineIntel
> >
> >   Virtual Machine: Java 1.6.0_17-b04 with Sun Microsystems Inc. Java
> > HotSpot(TM) 64-Bit Server VM mixed mode
> >
> >   Window System  : The X.Org Foundation (1150), display :1.0
> >
> >
> >
> > Fault Count: 1
> >
> >
> >
> >
> >
> > Abnormal termination:
> >
> > Segmentation violation
> >
> >
> >
> > Register State (from fault):
> >
> >   RAX = 7f404af6a8f0  RBX = 0020
> >
> >   RCX = 7f3bbc744618  RDX = 7f404af6a8e0
> >
> >   RSP = 7f4036736430  RBP = 7f3bbc8c5408
> >
> >   RSI = 7f3bbc744642  RDI = 0020
> >
> >
> >
> >R8 =    R9 = d501
> >
> >   R10 = 0045  R11 = 
> >
> >   R12 = 7f4036736ec0  R13 = 
> >
> >   R14 =   R15 = 7f3bbc744642
> >
> >
> >
> >   RIP = 7f404bd6f904  EFL = 00010206
> >
> >
> >
> >CS = 0033   FS =    GS = 
> >
> >
> >
> > Stack Trace (from fault):
> >
> > [  0] 0x7f404bd6f904
> >
> /opt/MATLAB/2013a/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6+00669956
> > _ZNSsD1Ev+0004
> >
> > [  1] 0x7f404acecc68
> > /opt/MATLAB/2013a/bin/glnxa64/libboost_log_setup.so.1.49.0+01846376
> >
> _ZN5boost9xpressive13match_resultsIN9__gnu_cxx17__normal_iteratorIPKcSsEEED1Ev+0040
> >
> > [  2] 0x7f3bb4e992a2
> >
> /opt/Xilinx/14.4/ISE_DS/ISE/sysgen/bin/lin64/../../lib/lin64/libsysgen.so+05595810
> > _ZN6Sysgen7Utility25getToolVersionFromFilesetERKSs+1698
> >
> > [  3] 0x7f3bb4e99d92
> >
> /opt/Xilinx/14.4/ISE_DS/ISE/sysgen/bin/lin64/../../lib/lin64/libsysgen.so+05598610
> > _ZN6Sysgen7Utility22getVivadoHLSInstallDirEv+0226
> >
> > [  4] 0x7f3bb58b5957
> > /opt/Xilinx/14.4/ISE_DS/ISE/sysgen/bin/lin64/xlmeta.mexa64+00022871
> >
> > [  5] 0x7f3bb58b7248
> > /opt/Xilinx/14.4/ISE_DS/ISE/sysgen/bin/lin64/xlmeta.mexa64+00029256
> > mexFunction+0248
> >
> > [  6] 0x7f4044a58f8a
> > /opt/MATLAB/2013a/bin/glnxa64/libmex.so+00110474 mexRunMexFile+0090
> >
> > [  7] 0x7f4044a550f9
> > /opt/MATLAB/2013a/bin/glnxa64/libmex.so+00094457
> >
> > [  8] 0x7f4044a55f1c
> > /opt/MATLAB/2013a/bin/glnxa64/libmex.so+00098076
> >
> > [  9] 0x7f404d1a06b2
> > /opt/MATLAB/2013a/bin/glnxa64/libmwm_dispatcher.so+00562866
> > _ZN8Mfh_file11dispatch_fhEiPP11mxArray_tagiS2_+0594
> >
> > [ 10] 0x7f404cc2abf6
> > /opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+04262902
> >
> > [ 11] 0x7f404cc2b37a
> > /opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+04264826
> >
> > [ 12] 0x7f404cc2beea
> > /opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+04267754
> >
> > [ 13] 0x7f404ca8ebbd
> > 

Re: [casper] Multicast on 10 gbe on ROACH-2?

[Jack Hickish]

Hi John,

It works great! Transmit only is happily also the simplest use case.
If you're doing stuff from the powerPC which you want multicasting, I
believe you have to
invoke corr.katcp_wrapper.FpgaClient.tap_multicast_add_send(). If you only
want to multicast traffic from the FPGA (which is how I've used
multicasting) all you need to do is set the destination IP to have a
multicast address (eg. I use 224.0.2.xxx). The yellow block will then
generate the appropriate destination MAC address for multicasting -- the
rest is up to the switch.*

An aside, in case it's useful: in the design where I'm using multicast I
have disabled the CPU tx/rx capabilities, so I can't use the multicast
subscribe methods provided by the corr package. Unfortunately, I also
wanted to be able to subscribe ROACHs to the multicast streams (standard FX
architecture, with F and X engines present on each board) so I set up
static multicast routes on the Mellanox SX1012 I'm using, and manually
wrote the relevant bits of the 10GbE core so that it accepts packets with
the addresses I need. It was pleasantly simple, and seems to work nicely.
I've set all my traffic to be multicast, even though most of it only has a
single destination -- I can subscribe a linux box to a few channels for
debugging or to do things like FFT zoom mode -- but for what it's worth
with 40 x ~9GbE connections going through the SX1012, it seems just as
reliable as with unicast.

If you want I can probably throw together an example design, but I'm pretty
sure for tx only it really is as simple as setting the appropriate address.
The more involved bit is turning on the relevant switch features and
writing some software to subscribe a client at the other end. I can dig out
the incantations I used with my mellanox switch, but since I did everything
with static routes I can't be much help with dynamically subscribing
software. (But it's ONLY software -- how hard can it be?!).


Cheers,
Jack

*Just read Dave's email -- I don't think you even need to set up the ARP
table with the latest yellow block, but this is probably a route to crowbar
multicast support into an old compile.

On Wed, 4 Nov 2015 at 16:58 John Ford  wrote:

> Hi all.
>
> Does the current ROACH-2 10 gbe yellow block work for multicast transmit?
>
> Does anyone have an example of use of it, if so?
>
> Thanks!
>
> John
>
>
>
>

Re: [casper] Weird FFT Output

[Jack Hickish]

Hi Amit,

I've hastily fixed that error regarding bram latency -- it's pushed to the
master casper branch at https://github.com/casper-astro/mlib_devel.git

You should be able to cherry pick that commit into your repository, but I
recommend just using the casper-astro master branch rather than the SMA
branch you're currently working with. The SMA code was merged into
casper-astro more recently than the commit you are currently at anyway.

As for your spectra, I'd suggest seeing if the problem persists with the
latest casper-astro master branch and then investigating further from there.

Cheers,
Jack


On Fri, 6 Nov 2015 at 11:14 Amit Bansod  wrote:

> Dear All,
>
> I am trying to extract 1 channel/band using PFB/FFT (pfb_fir_generic &
> fft_wideband_real blocks from casper library) and I am getting
> inconsistent result from a 64 channel PFB/FFT.
>
> I also found that the for 64 channel FFT, the fft_wideband_real block
> breaks at fft_wideband_real/fft_biplex_real_4x/bi_real_unscr_4x/delay0
> (or ../bi_real_unscr_4x/delay1) for BRAM latency > 2. Can this be also a
> cause for concern ?
>
> I have enclosed the plots of the same band for the 64 & 128 channel
> FFTs. The BW of 1 band is 12.5 MHz for 128 channels and 25 MHz for 64
> channels FFT.
>
> The design has ASIAA 5g ADCs with fpga running at 200 MHz and same noise
> source is feeding both ADCs.
>
> I am using the sma-wideband repository with commit : ecab6f5
>
>
> Regards,
> Amit Bansod
>

Re: [casper] xps Segmentation fault

[Jack Hickish]

Hi Roberto,

That's an interesting one. I don't think I've ever seen xps segfault.

First, are you using the latest (14.7) versions of the Xilinx tools?
Second, can you compile the original yellow block OK?

Other than go through the changes you've made step by step until you
identify the what's broken, I'm not really sure what to suggest. If your
code is checked into a branch of mlib_devel somewhere I'd be happy to try
and run it on my setup here if you think that'd help.

Cheers,
Jack




On Mon, 19 Oct 2015 at 19:58 Roberto F.  wrote:

> i'm trying to do a yellow block similar to the 83000x2. Instead of using
> the 83000 adc i want to do it with the adc5g adc (for roach2).
>
> I've used the tutorial 7 of casper for reference and some other documents
> to build the yellow block (i also looked how the adc5g was done).
>
> I'm stuck becuase when the toolflow runs xps -nw -scr run_xps.tcl
> system.xmp i get a Segmentation fault. I tried to open xps manualy and the
> load system.xmp but it closes. Could someone guide towards the origin of
> the bug? It's on the VHDl code or in the port definition or something.
>
> Atte.
>
>Roberto Fuentes P.
> _
>
>
> Roberto M. Fuentes P.
>

Re: [casper] Weird FFT block problem

[Jack Hickish]

Ah,

I would guess what happens is that you have delay stages being implemented
in bram where the stage delay is fewer clock cycles than the bram latency,
causing an initialization implosion. I suspect if you changed the "minimum
delay implemented in bram" (or whatever it's called) parameter to be a bit
higher you might not get this error. But as you say, >10 is very excessive,
and I'd be surprised if it makes any difference to your timing. I think if
you open your mapped design in planahead/fpga editor you'll find that
almost all that latency is being wrapped up in a single slice as a shift
register. But hey, if it works it works :)

Jack

On Tue, 6 Oct 2015 at 16:42 Michael D'Cruze <
michael.dcr...@postgrad.manchester.ac.uk> wrote:

> Hi Jack,
>
>
>
> After cycling through the settings I think I’ve isolated the issue. I was
> a bit quick to declare a solution….i was able to repeat the problem. The
> problem occurs when the BRAM latency is set to >10. I appreciate this may
> seem excessive in any case however as you know I’m messing with settings to
> get a 2^17 point FFT block to compile at 256 MHz…
>
>
>
> When the problem first arose I grabbed the latest casper-astro-soak-test
> commit, which didn’t solve the immediate issue.
>
>
>
> Perhaps someone could confirm that bram latencies >10 causes this issue?
> It’s a 2^17 point FFT with fanout 1.
>
>
>
> BW
> Michael
>
>
>
> *From:* Jack Hickish [mailto:jackhick...@gmail.com]
> *Sent:* 06 October 2015 15:50
> *To:* Michael D'Cruze; casper@lists.berkeley.edu
> *Subject:* Re: [casper] Weird FFT block problem
>
>
>
> Hi Michael,
>
>
>
> If the initialisation script fails half way through drawing then often
> you'll be left with a bunch of blocks half connected, so I think that's
> (probably) a symptom rather than a cause of the issue. Are you using the
> latest casper-astro branch? Do you remember what FFT parameters you were
> using? Was it a block fresh from the library of one you had previously
> configured? If the latter, do you remember how it was configured?
>
> Gonna be tricky to track this down if it can't be recreated...
>
>
>
> Cheers,
>
> Jack
>
>
>
> On Tue, 6 Oct 2015 at 15:25 Michael D'Cruze <
> michael.dcr...@postgrad.manchester.ac.uk> wrote:
>
> Hi all,
>
>
>
> I had an odd problem while messing about with the FFT block today – on
> setting a new combination of parameters and attempting a new compile, an
> error came up which I’ve never seen before. Something along the lines of an
> initialisation error in the FFT. On inspection, the component blocks within
> the FFT were in pieces and not linked up correctly. In the biplex core
> itself there was nothing except the in/out ports. This is very strange and
> I can’t find anything similar on the mailing list. I’ve solved it by
> erasing and re-cloning the CASPER libraries, however wondered if anyone had
> a clue why this would happen? FYI update_blocks didn’t help.
>
>
>
> Thanks
>
> Michael
>
>

Re: [casper] Weird FFT block problem

[Jack Hickish]

Hi Michael,

If the initialisation script fails half way through drawing then often
you'll be left with a bunch of blocks half connected, so I think that's
(probably) a symptom rather than a cause of the issue. Are you using the
latest casper-astro branch? Do you remember what FFT parameters you were
using? Was it a block fresh from the library of one you had previously
configured? If the latter, do you remember how it was configured?
Gonna be tricky to track this down if it can't be recreated...

Cheers,
Jack

On Tue, 6 Oct 2015 at 15:25 Michael D'Cruze <
michael.dcr...@postgrad.manchester.ac.uk> wrote:

> Hi all,
>
>
>
> I had an odd problem while messing about with the FFT block today – on
> setting a new combination of parameters and attempting a new compile, an
> error came up which I’ve never seen before. Something along the lines of an
> initialisation error in the FFT. On inspection, the component blocks within
> the FFT were in pieces and not linked up correctly. In the biplex core
> itself there was nothing except the in/out ports. This is very strange and
> I can’t find anything similar on the mailing list. I’ve solved it by
> erasing and re-cloning the CASPER libraries, however wondered if anyone had
> a clue why this would happen? FYI update_blocks didn’t help.
>
>
>
> Thanks
>
> Michael
>

Re: [casper] Mystery timing errors

[Jack Hickish]

Hi Michael,

As one of the Xilinx timing closure documents helpfully articulates, it's
very difficult to give specific recipes for solving timing problems, other
than reading the timing report, looking at things in PlanAhead/FPGA Editor,
iterating compiles and developing some intuition.

That said, there are a few things you could try, of varying levels of
complexity --
Since you have quite a lot of channels in your design, I suspect your vacc
problems are related to the size of the bram buffer (especially if your
samples are wide). Keep in mind that a bram in a Virtex6 is a 36 bit wide x
1k deep memory block, so building a vacc to accommodate many thousands of
channels means banking together lots of brams -- this is liable to cause
fanout issues on your address/control signals. The same is probably true of
the large delays in the PFB blocks, though I'm not sure how these are
implemented in the various block versions which exist in mlib_devel.
Setting brams to optimize for speed and giving them at least 3 cycles
latency may help. You could also try manually controlling bram control
signals -- I believe the casper_library_bus/bus_single_port_ram block will
do some of this for you if you set to optimize for speed and include some
fanout latency. If you replace the bram delay in the vacc with one of these
(and associated address counter logic to make the block act as a delay)
then perhaps this will help. Be careful to get your latencies right so the
block still functions properly.
You might also find that implementing the adder in a DSP slice (if you
haven't already) might help.

A more involved option is to go about manually constraining the placement
of components. You might find setting up pblocks in PlanAhead to place
major parts of your design might free up the compiler to do a little better
with the remainder of the logic. Adding pblocks for the pfb, and the
various FFT stages can be very helpful in this regard. Or perhaps just
constraining the vacc that's causing you problems might be enough.
Once you have some constraints from planahead which work, you can
auto-include them in your simulink compiles using various methods, my
favourite being the 'UCF' yellow block, which is in the current
casper-astro mlib_devel.

In general, I suspect that you would be well served by trying to reduce
your bram use in your model - the resource utilisation report can probably
either confirm or contest that this is the case. You could do this by
trying to use alternatives to brams where blocks allow it (for example the
FFT will allow coefficients to be generated using DSPs in some cases), or
by reducing the number of FIR taps, or implementing something using QDR
rather than bram if appropriate.

The unfortunate truth is that some, none or all of these suggestions may
help, or might make things worse. I would say that in my experience
over-judicious use of pipeline/register stages throughout a design can
often do more harm than good, and a sensibly placed PFB can result in
incredible timing improvements.

Hope that helps, please email back with any more info and/or updates -- I
suspect if you solve this problem documenting your method may prove very
useful for others encountering similar problems.

Cheers, and good luck!
Jack

On 30 August 2015 at 10:42, Michael D'Cruze 
michael.dcr...@postgrad.manchester.ac.uk wrote:

 Hi everyone,



 I’m having quite a lot of problems getting a particular design to
compile, XPS consistently reporting timing errors. The design is a wideband
spectrometer, somewhat similar to the tutorial 3 design. I’m running an
iADC at 1024 MHz, and the FPGA at 256 MHz. It is a two-polarisation design,
with a 64k-point PFB and FFT (for 32k channels) in each polarisation. I am
running the PFB and FFT blocks in “two-polarisation” mode, so there are
just one of each block. I am using the Vacc block from the xBlocks
repository.



 I should add at this point that the same design with 16k channels
compiles successfully at this speed, and that the 32k channel design
compiles at slower speeds (e.g. 200 MHz FPGA).



 The timing reports suggest negative slack in the PFB and Vacc blocks.
I’ve tried adding various combinations of latency in each, however no
permutations have resulted in substantial improvements. The overwhelming
majority of the errors are reported by the Vacc block. I have also tried
replacing the xBlocks Vacc block with the wide_bram_vacc block in 64-bit
mode, however this results in even more timing errors (and without the
option to adjust latencies).



 I’ve tried various combinations of latencies suggested previously on the
mail archive, but again nothing has really given any improvement.



 Am I simply pushing such a large design too hard? Is the only option to
slow it down or is there some strategic method I can adopt to get closer to
timing closure? Suggestions much appreciated!



 Thanks

 Michael

Re: [casper] Problems with ADC captured data.

[Jack Hickish]

Hi Sharat,

Are you running the adc mmcm calibration routine after programming your
roach?

Cheers,
Jack

On 31 August 2015 at 22:41, sharat varma  wrote:

>
> Hi Casper,
>
> I am working as a post-doc working under guidance of Dr. Hayden So at The
> University of Hong Kong.
>
> We are using ROACH2 to capture data from optical cytometry. We are using
> ASIAA ADC5G ADC to capture data at 4 to 5 Gsps.
>
> We basically use the following parameters.
>
> Block parameter: two-channel, ZDOK0, demux 1:1 .
> System: roach2, clock source:adc0_clk, clock rate: 300 MHz.
>
> We are connecting the output of a photo-detector 1544-B from Newport Corp
> (the spec is attached) to the ADC input using SMA.
> We find that noisy spikes are introduced when we capture the data through
> the ADC (see attached fig). We double checked if the source had problems
> using a oscilloscope, but on the oscilloscope we do not see any of these
> spikes.
>
> We would be grateful if you could let us know if we are doing anything
> wrong.
>
>  Rgards,
> Sharat
>
>
>

Re: [casper] Mystery timing errors

[Jack Hickish]

On 2 September 2015 at 02:58, Michael D'Cruze <
michael.dcr...@postgrad.manchester.ac.uk> wrote:

> Hi Jack,
>
>
>
> Thanks for your suggestions! It’s taken me a little while to work through
> it all.
>
>
>
> I did manage to get a 2-pol, 32k channel design to compile eventually. I
> think it was a combination of a) sufficient latency in the Vacc and PFB
> blocks (as you suggest) and b) splitting the two pols into two separate
> chains, rather than using one block for the PFB and FFT in biplex mode. It
> was found by just iterating through latency combinations until the timing
> started to converge, but there were still several hundred errors until I
> split up the design into two chains. Now, I don’t really understand why
> using two separate PFB/FFT blocks should make a difference (surely sysgen
> sorts such detail?), but the latency settings were:
>

Two separate blocks has two main implications. The first is that
coefficients are duplicated for each block, rather than being stored in one
place and fanned out. This is good for ram savings, but in general bad for
timing. The blocks have fanout latency and max fanout settings to try and
solve the timing problems.
The second implication is that bram delays your signals go through are
separated for your two streams. I.e., the delay buffers are half the size
but you have twice as many of them. Where your delays are short (e.g. in
FIRs with fewer than ~2k channels (depending on how many simultaneous
samples per FPGA clock you get, and the specific implementation)) a single
large buffer is better than two buffers of half the size, since any buffer
will always use at least 1 bram. If you're making loads of channels, all
the buffers are many brams in size. In this case whether or not you split
them up doesn't make any difference, bram-usage-wise, since a large buffer
just uses twice as many brams as a buffer of half the size. *However*
separate buffers of smaller sizes should be easier to run fast, which may
be a contributing factor to your design working better with separate
blocks...



>
>
> PFB: Add Latency 1; Mult latency 2; BRAM latency 3; Fanout latency 1;
> Convert latency 1 (4 taps).
>
> Vacc: Add latency 2; BRAM latency 6 (overkill?); Mux latency 0,
>
>
>

BRAM latency up to 3 certainly helps, I would have thought anything above 4
just turns into a bram with latency 3, plus a shift register, but you'd
have to dig into the mapped design to see. In any case, if it works, it
works!


> where DSP48 has been used wherever possible in the design.
>
>
>
> Now I need to see if it still works if I use more FIR taps ;-)
>

I admire your boldness.

Jack

PS.
If your design is on github, it might be a nice reference for people trying
to build models with relatively large numbers of channels


>
>
> Best wishes
>
> Michael
>
>
>
> *From:* Jack Hickish [mailto:jackhick...@gmail.com]
> *Sent:* 30 August 2015 21:57
> *To:* Michael D'Cruze
> *Cc:* casper@lists.berkeley.edu
> *Subject:* Re: [casper] Mystery timing errors
>
>
>
> Hi Michael,
>
> As one of the Xilinx timing closure documents helpfully articulates, it's
> very difficult to give specific recipes for solving timing problems, other
> than reading the timing report, looking at things in PlanAhead/FPGA Editor,
> iterating compiles and developing some intuition.
>
> That said, there are a few things you could try, of varying levels of
> complexity --
> Since you have quite a lot of channels in your design, I suspect your vacc
> problems are related to the size of the bram buffer (especially if your
> samples are wide). Keep in mind that a bram in a Virtex6 is a 36 bit wide x
> 1k deep memory block, so building a vacc to accommodate many thousands of
> channels means banking together lots of brams -- this is liable to cause
> fanout issues on your address/control signals. The same is probably true of
> the large delays in the PFB blocks, though I'm not sure how these are
> implemented in the various block versions which exist in mlib_devel.
>
> Setting brams to optimize for speed and giving them at least 3 cycles
> latency may help. You could also try manually controlling bram control
> signals -- I believe the casper_library_bus/bus_single_port_ram block will
> do some of this for you if you set to optimize for speed and include some
> fanout latency. If you replace the bram delay in the vacc with one of these
> (and associated address counter logic to make the block act as a delay)
> then perhaps this will help. Be careful to get your latencies right so the
> block still functions properly.
> You might also find that implementing the adder in a DSP slice (if you
> haven't already) might help.
>
> A more involved option is to go about manually constraining the placem

Re: [casper] Problems with ADC captured data.

[Jack Hickish]

  adc5g.tools - DEBUG -   found eye start
> at 9
> 2015-09-07 13:00:15,597 -  adc5g.tools - DEBUG - glitches
> before eye: 107
> 2015-09-07 13:00:15,597 -  adc5g.tools - DEBUG -   found eye end
> at 16
> 2015-09-07 13:00:15,598 -  adc5g.tools - DEBUG - glitches
> after eye: 362
> 2015-09-07 13:00:15,598 -  adc5g.tools - DEBUG -   EYE CENTRE at
> 12.5
> 2015-09-07 13:00:15,598 -  adc5g.tools - DEBUG - TIEBREAK: EYE
> CENTRE at 12
> 2015-09-07 13:00:15,598 -  adc5g.tools - DEBUG -   NEW START
> SEARCH REFERENCE POINT IS 2
> 2015-09-07 13:00:15,598 -  adc5g.tools - DEBUG - Starting search
> for bit 1 eye at tap 2
> 2015-09-07 13:00:15,598 -  adc5g.tools - DEBUG - found first
> glitch at 2
> 2015-09-07 13:00:15,599 -  adc5g.tools - CRITICAL - Couldn't find
> start of eye!
> Traceback (most recent call last):
>   File "test_cal.py", line 25, in 
> adc5g.calibrate_all_delays(r, 0, snaps=[SNAPNAME], verbosity=5)
>   File
> "/home/nfs/roach2/debian_stable_devel/boffiles/varma/adc_tests-disentangle/adc5g/tools.py",
> line 352, in calibrate_all_delays
> best_delay[core] =
> find_best_delay(glitches[core],verbose=(verbosity>2),reference=best_delay[0,0])
>   File
> "/home/nfs/roach2/debian_stable_devel/boffiles/varma/adc_tests-disentangle/adc5g/tools.py",
> line 253, in find_best_delay
>     raise Exception("Couldn't find start of eye")
> Exception: Couldn't find start of eye
>
> 
> When I run
> test_adc ZDOCK 0
>
> breaking at ps:0 with 9651 glitches
> test if calibration finds optimal MMCM phase ... FAIL
>
> ==
> FAIL: test if calibration finds optimal MMCM phase
> --
> Traceback (most recent call last):
>   File "test_adc5g.py", line 105, in test_optimal_solution_found
> self.assertIsNotNone(self._optimal_phase)
> AssertionError: unexpectedly None
>
> --
> Ran 8 tests in 7.293s
>
> FAILED (failures=1)
> 
> When I run test _adc ZDOCK 1
> breaking at ps:0 with 238 glitches
> test if calibration finds optimal MMCM phase ... FAIL
>
> ==
> FAIL: test if calibration finds optimal MMCM phase
> --
> Traceback (most recent call last):
>   File "test_adc5g.py", line 105, in test_optimal_solution_found
> self.assertIsNotNone(self._optimal_phase)
> AssertionError: unexpectedly None
>
> --
> Ran 8 tests in 7.033s
>
>
> On 6 September 2015 at 08:40, Jack Hickish <jackhick...@gmail.com> wrote:
>
>> Hi Sharat,
>>
>> The disentangle(!) branch at
>> https://github.com/jack-h/adc_tests/tree/disentangle has my calibration
>> code. If you check out that branch and install it (cd adc5g; python
>> setup.py install) then the test_cal.py script is a simple template for
>> calibrating. If it doesn't work it should also print/plot various helpful
>> things that will help figure out what's wrong.
>> Turns out I don't actually have a working adc5g here, except in demux 1:2
>> configuration, so I haven't been able to test the code with your boffile.
>> Having said that, with the 2:1 demux card, it seems to behave sanely for
>> the bits that one would expect to work.
>>
>> Cheers,
>> Jack
>>
>> On Fri, 4 Sep 2015 at 04:48 sharat varma <va...@hku.hk> wrote:
>>
>>> Hi Rurik,
>>>
>>> Yes. I used the boffile ver2. I also generated bof using model file and
>>> tried using it. I checked both the ADCs using -z option. I get the same
>>> error.
>>>
>>> Thanks and regards,
>>> Sharat
>>> On 4 Sep 2015 18:37, "Primiani, Rurik" <rprimi...@cfa.harvard.edu>
>>> wrote:
>>>
>>>> Hi Sharat,
>>>>
>>>> Are you using the revision 1 or revision 2 version of the test suite
>>>> bitcode and does this match the version of the board that you have? By
>>>> default it uses revision 2 which is probably what you have but just to make
>>>> sure. To use the other bitcode you would need to use the -b flag with
>>>> test_adc5g.py.
>>>>
>>>> The adc_test provided bitcode and test script *should* work out o

Re: [casper] Problems with ADC captured data.

[Jack Hickish]

Hi Sharat,

The disentangle(!) branch at
https://github.com/jack-h/adc_tests/tree/disentangle has my calibration
code. If you check out that branch and install it (cd adc5g; python
setup.py install) then the test_cal.py script is a simple template for
calibrating. If it doesn't work it should also print/plot various helpful
things that will help figure out what's wrong.
Turns out I don't actually have a working adc5g here, except in demux 1:2
configuration, so I haven't been able to test the code with your boffile.
Having said that, with the 2:1 demux card, it seems to behave sanely for
the bits that one would expect to work.

Cheers,
Jack

On Fri, 4 Sep 2015 at 04:48 sharat varma <va...@hku.hk> wrote:

> Hi Rurik,
>
> Yes. I used the boffile ver2. I also generated bof using model file and
> tried using it. I checked both the ADCs using -z option. I get the same
> error.
>
> Thanks and regards,
> Sharat
> On 4 Sep 2015 18:37, "Primiani, Rurik" <rprimi...@cfa.harvard.edu> wrote:
>
>> Hi Sharat,
>>
>> Are you using the revision 1 or revision 2 version of the test suite
>> bitcode and does this match the version of the board that you have? By
>> default it uses revision 2 which is probably what you have but just to make
>> sure. To use the other bitcode you would need to use the -b flag with
>> test_adc5g.py.
>>
>> The adc_test provided bitcode and test script *should* work out of the
>> box. Have you tried running the test on ZDOK 1, you can use -z 1 for that.
>>
>> Best,
>> Rurik
>>
>>
>> On Fri, Sep 4, 2015 at 12:01 AM, sharat varma <va...@hku.hk> wrote:
>>
>>> Hi,
>>>
>>> Thanks for the reply and sorry for the delayed response.
>>> Yes, the x-axis represent the time and y-axis represents the signed 8
>>> bit output. The negative bias is due to the nature of the input.
>>>
>>> I was trying to use the files in the link you mentioned, but I keep
>>> getting the error shown below. I am using the bof file provided for roach2.
>>>
>>> test roach connectivity ... ok
>>> check if requested bof is available ... ok
>>> test roach pingability ... ok
>>> program the requested bof ... ok
>>> estimate clock rate, should be within 1 MHz of expected ... ok
>>> confirm the design has the ADC SPI controller ... ok
>>> confirm the design has the needed scope ... ok
>>> test if calibration finds optimal MMCM phase ... FAIL
>>>
>>> ==
>>> FAIL: test if calibration finds optimal MMCM phase
>>> --
>>> Traceback (most recent call last):
>>>   File "test_adc5g.py", line 107, in test_optimal_solution_found
>>> self.assertIsNotNone(self._optimal_phase)
>>> AssertionError: unexpectedly None
>>>
>>> --
>>> Ran 8 tests in 7.230s
>>>
>>> FAILED (failures=1)
>>>
>>> Please let me know if I am doing anything wrong or where could be the
>>> problem.
>>>
>>> For your information:
>>>
>>> System: roach2
>>>
>>> ADC :  ASIAA ADC5G ADC
>>>
>>> Clock : 2500MHz.
>>>
>>> Thanks and regards,
>>>
>>> Sharat
>>>
>>>
>>> On 1 September 2015 at 23:01, Primiani, Rurik <rprimi...@cfa.harvard.edu
>>> > wrote:
>>>
>>>> Hi Sharat,
>>>>
>>>> The plot you provided has no labels or units so I will assume the
>>>> x-axis represents time in samples and the y-axis represents signed 8-bit
>>>> sample values. I'm not sure why there is such a negative bias but perhaps
>>>> that's particular to your instrument.
>>>>
>>>> Please, at the very least, run the MMCM calibration described at
>>>> https://github.com/sma-wideband/adc_tests to reduce glitches on the
>>>> interface. I believe Jack also has a more sophisticated approach which
>>>> adjusts the IODELAY for each individual data line; sadly I don't have a
>>>> link handy for that.
>>>>
>>>> Although you may not see these glitches with a sine wave, a noise-like
>>>> signal will cause more transitions on each bit and thus more glitches with
>>>> an uncalibrated interface.
>>>>
>>>> Thanks,
>>>> Rurik
>>>>
>>>>
>>>>

Re: [casper] Problems with ADC captured data.

[Jack Hickish]

Hi Sharat,

Tomorrow (in California) I'll send you a link and instructions to use the
calibration script I have, which should work ok at 2500mhz clock.

In the meantime, it might not matter, but what version of mlib-devel are
you using?

Cheers,
Jack

On Thu, 3 Sep 2015 9:02 pm sharat varma <va...@hku.hk> wrote:

> Hi,
>
> Thanks for the reply and sorry for the delayed response.
> Yes, the x-axis represent the time and y-axis represents the signed 8 bit
> output. The negative bias is due to the nature of the input.
>
> I was trying to use the files in the link you mentioned, but I keep
> getting the error shown below. I am using the bof file provided for roach2.
>
> test roach connectivity ... ok
> check if requested bof is available ... ok
> test roach pingability ... ok
> program the requested bof ... ok
> estimate clock rate, should be within 1 MHz of expected ... ok
> confirm the design has the ADC SPI controller ... ok
> confirm the design has the needed scope ... ok
> test if calibration finds optimal MMCM phase ... FAIL
>
> ==
> FAIL: test if calibration finds optimal MMCM phase
> --
> Traceback (most recent call last):
>   File "test_adc5g.py", line 107, in test_optimal_solution_found
> self.assertIsNotNone(self._optimal_phase)
> AssertionError: unexpectedly None
>
> --
> Ran 8 tests in 7.230s
>
> FAILED (failures=1)
>
> Please let me know if I am doing anything wrong or where could be the
> problem.
>
> For your information:
>
> System: roach2
>
> ADC :  ASIAA ADC5G ADC
>
> Clock : 2500MHz.
>
> Thanks and regards,
>
> Sharat
>
>
> On 1 September 2015 at 23:01, Primiani, Rurik <rprimi...@cfa.harvard.edu>
> wrote:
>
>> Hi Sharat,
>>
>> The plot you provided has no labels or units so I will assume the x-axis
>> represents time in samples and the y-axis represents signed 8-bit sample
>> values. I'm not sure why there is such a negative bias but perhaps that's
>> particular to your instrument.
>>
>> Please, at the very least, run the MMCM calibration described at
>> https://github.com/sma-wideband/adc_tests to reduce glitches on the
>> interface. I believe Jack also has a more sophisticated approach which
>> adjusts the IODELAY for each individual data line; sadly I don't have a
>> link handy for that.
>>
>> Although you may not see these glitches with a sine wave, a noise-like
>> signal will cause more transitions on each bit and thus more glitches with
>> an uncalibrated interface.
>>
>> Thanks,
>> Rurik
>>
>>
>>
>> On Tue, Sep 1, 2015 at 2:54 AM, sharat varma <va...@hku.hk> wrote:
>>
>>> Hi Jack,
>>>
>>> Thanks for the reply.
>>>
>>> I did not run mmcm calibration. Actually, we checked the ADC by feeding
>>> it a low frequency sine wave from a function generator and it works fine.
>>>
>>> The problem with spikes occurs when we feed the ADC with the
>>> photo-detector output.
>>>
>>> Regards,
>>> Sharat
>>>
>>>
>>> On 1 September 2015 at 13:52, Jack Hickish <jackhick...@gmail.com>
>>> wrote:
>>>
>>>> Hi Sharat,
>>>>
>>>> Are you running the adc mmcm calibration routine after programming your
>>>> roach?
>>>>
>>>> Cheers,
>>>> Jack
>>>>
>>>> On 31 August 2015 at 22:41, sharat varma <va...@hku.hk> wrote:
>>>>
>>>>>
>>>>> Hi Casper,
>>>>>
>>>>> I am working as a post-doc working under guidance of Dr. Hayden So at
>>>>> The University of Hong Kong.
>>>>>
>>>>> We are using ROACH2 to capture data from optical cytometry. We are
>>>>> using  ASIAA ADC5G ADC to capture data at 4 to 5 Gsps.
>>>>>
>>>>> We basically use the following parameters.
>>>>>
>>>>> Block parameter: two-channel, ZDOK0, demux 1:1 .
>>>>> System: roach2, clock source:adc0_clk, clock rate: 300 MHz.
>>>>>
>>>>> We are connecting the output of a photo-detector 1544-B from Newport
>>>>> Corp (the spec is attached) to the ADC input using SMA.
>>>>> We find that noisy spikes are introduced when we capture the data
>>>>> through the ADC (see attached fig). We double checked if the source had
>>>>> problems using a oscilloscope, but on the oscilloscope we do not see any 
>>>>> of
>>>>> these spikes.
>>>>>
>>>>> We would be grateful if you could let us know if we are doing anything
>>>>> wrong.
>>>>>
>>>>>  Rgards,
>>>>> Sharat
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [casper] Problems with ADC captured data.

[Jack Hickish]

Hi Sharat,

How recent is your checkout of that library? What does git tell you is the
most recent commit?
Can you also send me a copy of your model and boffile -- i'll test that the
calibration script works.

Cheers,
Jack


On 3 September 2015 at 22:46, sharat varma <va...@hku.hk> wrote:

> Hi Jack,
>
> Thank you Jack.
> I am using the mlib-devel from https://github.com/sma-wideband/mlib_devel
> Also, I am using ISE 14.7.
>
> Regards,
> Sharat
>
> On 4 September 2015 at 12:34, Jack Hickish <jackhick...@gmail.com> wrote:
>
>> Hi Sharat,
>>
>> Tomorrow (in California) I'll send you a link and instructions to use the
>> calibration script I have, which should work ok at 2500mhz clock.
>>
>> In the meantime, it might not matter, but what version of mlib-devel are
>> you using?
>>
>> Cheers,
>> Jack
>>
>> On Thu, 3 Sep 2015 9:02 pm sharat varma <va...@hku.hk> wrote:
>>
>>> Hi,
>>>
>>> Thanks for the reply and sorry for the delayed response.
>>> Yes, the x-axis represent the time and y-axis represents the signed 8
>>> bit output. The negative bias is due to the nature of the input.
>>>
>>> I was trying to use the files in the link you mentioned, but I keep
>>> getting the error shown below. I am using the bof file provided for roach2.
>>>
>>> test roach connectivity ... ok
>>> check if requested bof is available ... ok
>>> test roach pingability ... ok
>>> program the requested bof ... ok
>>> estimate clock rate, should be within 1 MHz of expected ... ok
>>> confirm the design has the ADC SPI controller ... ok
>>> confirm the design has the needed scope ... ok
>>> test if calibration finds optimal MMCM phase ... FAIL
>>>
>>> ==
>>> FAIL: test if calibration finds optimal MMCM phase
>>> --
>>> Traceback (most recent call last):
>>>   File "test_adc5g.py", line 107, in test_optimal_solution_found
>>> self.assertIsNotNone(self._optimal_phase)
>>> AssertionError: unexpectedly None
>>>
>>> --
>>> Ran 8 tests in 7.230s
>>>
>>> FAILED (failures=1)
>>>
>>> Please let me know if I am doing anything wrong or where could be the
>>> problem.
>>>
>>> For your information:
>>>
>>> System: roach2
>>>
>>> ADC :  ASIAA ADC5G ADC
>>>
>>> Clock : 2500MHz.
>>>
>>> Thanks and regards,
>>>
>>> Sharat
>>>
>>>
>>> On 1 September 2015 at 23:01, Primiani, Rurik <rprimi...@cfa.harvard.edu
>>> > wrote:
>>>
>>>> Hi Sharat,
>>>>
>>>> The plot you provided has no labels or units so I will assume the
>>>> x-axis represents time in samples and the y-axis represents signed 8-bit
>>>> sample values. I'm not sure why there is such a negative bias but perhaps
>>>> that's particular to your instrument.
>>>>
>>>> Please, at the very least, run the MMCM calibration described at
>>>> https://github.com/sma-wideband/adc_tests to reduce glitches on the
>>>> interface. I believe Jack also has a more sophisticated approach which
>>>> adjusts the IODELAY for each individual data line; sadly I don't have a
>>>> link handy for that.
>>>>
>>>> Although you may not see these glitches with a sine wave, a noise-like
>>>> signal will cause more transitions on each bit and thus more glitches with
>>>> an uncalibrated interface.
>>>>
>>>> Thanks,
>>>> Rurik
>>>>
>>>>
>>>>
>>>> On Tue, Sep 1, 2015 at 2:54 AM, sharat varma <va...@hku.hk> wrote:
>>>>
>>>>> Hi Jack,
>>>>>
>>>>> Thanks for the reply.
>>>>>
>>>>> I did not run mmcm calibration. Actually, we checked the ADC by
>>>>> feeding it a low frequency sine wave from a function generator and it 
>>>>> works
>>>>> fine.
>>>>>
>>>>> The problem with spikes occurs when we feed the ADC with the
>>>>> photo-detector output.
>>>>>
>>>>> Regards,
>>>>> Sharat
>>>>>
>>>>>
>>>>> On 1 S

Re: [casper] Spectrum issues

[Jack Hickish]

Hi Michael,

Are you certain that
1. The snapshot bram address counters have been changed to accommodate the
new deeper rams. If not they will wrap and never write to the lower part of
the ram.
2. Whatever controls the valid signal to the shared brams has been modified
so that valid goes high for 8k clocks?

I think you'll track down the problem pretty quickly if you simulate the
vacc and vacc control logic.

As for the blackboxed and non-blackboxed designs behaving differently, I
can only suppose that they're not really the same for some reason, or
there's something fishy going on with the port connection of fft to
gateways in the black boxes model file.

Cheers,
Jack

On Sat, 12 Sep 2015 6:35 am Michael D'Cruze <
michael.dcr...@postgrad.manchester.ac.uk> wrote:

> Hi everyone,
>
>
>
> I’m having quite a lot of trouble getting large-ish designs (16k channels)
> to produce spectra. The spectra that are being produced are quite strange.
> I’ve provided links below to a few examples. The first link is the spectrum
> produced by the unmodified tut3 model (except for the ADC and FPGA clocks
> increased to 1024 MHz and 256 MHz, respectively). It’s pretty much as you’d
> expect – a bog-standard L-band spectrum full of RFI. The second link is
> what happens when I try to increase the number of channels to 16k. As you
> can see, I can pull 16k channels from the board, but there are no actual
> data in there, beyond the original 2k channels. All the usual blocks were
> modified to get the model to work at 16k channels: the #PFB and #FFT points
> increased to 32768, the vector length in the VACC increased to 8192, the
> sync_gen block (using for now before changing to a PPS-based system)
> adjusted, and the shared_brams adjusted for longer address length. The
> third link is a zoomed-in image of the same spectrum, just to show that
> there is a partial spectrum in there. The fourth link is what comes out
> when I replace the FFT and PFB blocks with black-boxes… where the
> pre-compiled PFB and FFT blocks have the same settings as in the previous
> spectra….! The inconsistency between compiling with “raw” blocks and
> pre-compiled blocks is another source of concern.
>
>
>
> https://dl.dropboxusercontent.com/u/38103354/tut3_spectrum.png
>
> https://dl.dropboxusercontent.com/u/38103354/tut3_mod3_correct.png
>
> https://dl.dropboxusercontent.com/u/38103354/tut3_mod3.png
>
> https://dl.dropboxusercontent.com/u/38103354/tut3_mod2.png
>
>
>
> I can also make my models available if anyone would like. If I were to
> list every setting I’d changed to try and get this to work, this email
> would take about an hour to write…. but I’ve kept a log of everything I’ve
> tested. So, I’d be very grateful for suggestions for what to do next… I
> really have run out of ideas. I’ve compared the settings I’m using to the
> VEGAS models available on the git repo, and have even looked back to the
> deprecated “million channel spectrometer” model to look at the block
> settings used there. Nothing seems very different to what I’m doing.
>
>
>
> I’m going for 16k channels at the moment just because I was having trouble
> getting timing closure on 32k channels in 2-pols, with all the backend
> logic. Eventually I need to get a 64k channel model in 1-pol working, with
> the 5 GS/s ASIAA ADC, so this pre-requisite is essential.
>
>
>
> Many thanks in advance
>
> Michael
>
>
>
> P.S. I should add that the 1024 MHz ADC clock has to stay fixed because
> the downconverted 500 MHz L-band signal comes into the ADC at 0.5—1 GHz….
>
>
>
>
>

Re: [casper] Problems with ADC captured data.

[Jack Hickish]

Hi Sharat,

Did you do any of the other tests Dave suggested? Compiling/running at a
lower clock speed? Checking for roach revision compatibility? Checking
whether the failures after swapping zdoks / adc cards were always the same?

I would suggest the debug messages like --

2015-09-07 13:00:15,564 -  adc5g.tools - DEBUG - # GLITCHES FOR
CORE 0 BY IODELAY #
2015-09-07 13:00:15,564 -  adc5g.tools - DEBUG -  0:   0   0   0
0  41   0   0   0TOTAL 41
2015-09-07 13:00:15,564 -  adc5g.tools - DEBUG -  1:   0   0   0
0   0   0   0   0TOTAL 0
2015-09-07 13:00:15,564 -  adc5g.tools - DEBUG -  2:   0   0   0
0   0   0   0   0TOTAL 0
2015-09-07 13:00:15,564 -  adc5g.tools - DEBUG -  3:   0   0   0
0   0   0   0   0TOTAL 0
2015-09-07 13:00:15,565 -  adc5g.tools - DEBUG -  4:   0   0   0
0   0   0   0   0TOTAL 0
2015-09-07 13:00:15,565 -  adc5g.tools - DEBUG -  5:   0   0   0
0   0   0   0   0TOTAL 0
2015-09-07 13:00:15,565 -  adc5g.tools - DEBUG -  6:   0 108   4
0   0   0   0 100TOTAL 212
2015-09-07 13:00:15,565 -  adc5g.tools - DEBUG -  7:  54 593 584
304   0 174  12 368TOTAL 2089
2015-09-07 13:00:15,565 -  adc5g.tools - DEBUG -  8: 599   6   0
577 227 383 580 371TOTAL 2743
2015-09-07 13:00:15,565 -  adc5g.tools - DEBUG -  9:  27   0   0
0 371   2 222 291TOTAL 913
2015-09-07 13:00:15,566 -  adc5g.tools - DEBUG - 10:   0   0   0
0   2   0   0   0TOTAL 2
2015-09-07 13:00:15,566 -  adc5g.tools - DEBUG - 11:   0   0   0
0   0   0   0   0TOTAL 0

-- are your best source of information, since they isolate errors to
individual bits of individual cores.

For what it's worth, I'd also recommend compiling against
github.com/casper-astro/mlib_devel.git, which is the main CASPER repository
(and it should support the adc5g). Other repositories have custom features
which may or may not be suitable for general consumption.

Cheers,
Jack

On Tue, 8 Sep 2015 at 22:17 sharat varma <va...@hku.hk> wrote:

> HI,
>
> Thank you all very much for your patience and inputs.
>
> I ran Jacks scripts to know where the problem lies, but could not figure
> out the reason for the glitches as they vary very widely when I reprogram
> the same boff file.
> The plots that I captured using the scripts for calibrating IO delays are
> 1.png,2.png and 3.png. The plots using calibrating MMCM are in mmcm1.png
> ,mmcm2.png, mmcm3.png.
> Some points that I observed during troubleshooting was
>
> The glitches on ZDOCK0 using adc5g_test_rev2.bof files is around 7500 and
> on ZDOCK1 is around 250 even though they keeps varying each time I program
> the roach. I swapped the ADCs and this seems to be consistent. I also used
> the same ADCs and plugged them into different ROACH2 system. This was
> consistent.
>
> I checked the clock and it seems to be fine. Since I was able to capture
> data from ADC on 4 different systems through 10gbe interface, I presume
> clock should be fine.
>
> I have used already compiled files from SMA test_adc repository. I have
> also generated the boffiles using the modelfiles. I have tried different
> frequencies for my design yet the results are the same.
> I still could not figure out where is the problem.
>
> Regards,
> Sharat
>
> On 7 September 2015 at 23:47, David MacMahon <dav...@astro.berkeley.edu>
> wrote:
>
>> Hi, Sharat,
>>
>> On Sep 6, 2015, at 11:02 PM, Jack Hickish wrote:
>>
>> > As the code suggests, the error comes because bit 1 of core 3 appears
>> to never be glitch free, no matter what the delay setting. It's not obvious
>> to me what could cause this.
>>
>> Just to expand on what Jack said, here are a few possible ideas (some of
>> which are sheer speculation):
>>
>> 1. Verify the pinout of the ADC data pins in system_pad.txt.  Revision 1
>> of the ROACH2 connected one of the ZDOK differential pairs to FPGA pins
>> that were in a different bank than the others.  This sub-optimal situation
>> was "discovered" after a small number of the "rev 1" boards had been made.
>> The design was quickly re-done for "rev 2".  Virtually all ROACH2s now are
>> "rev 2", but in the interest of advancing ROACH2 development (and their own
>> development) SMA took delivery of the "rev 1" boards.  It could be possible
>> that you are using an mlib_devel that is targeting a "rev 1" board, but
>> using the resultant BOF file on a "rev 2" board.
>>
>> 2. Try to compile your design for a slower clock setting.  For example,
>> maybe 2 or 3 Gsps instead of 5 Gsps.  While this may not meet your
>> application's needs, it could be a useful diagnostic.  Different sample
>> clock rates would result i

Re: [casper] Unconnected output block warnings when compiling with dac_mkid

[Jack Hickish]

Hi Richard,

I've just modified the dac yellow blocks so that they don't try to call the
initialisation script for the now non-existent parallel_to_serial block.
The interface should still work -- essentially it's now frozen with the
parameters originally set by the dac yellow block, which I assume are right
-- but I don't have hardware to test on.

I also added terminators to the gateways in the yellow block which should
suppress "unconnected output" warnings.

Pushed to github.com/casper-astro/mlib_devel.git master branch

Let me know if you have any problems.

Cheers,

Jack

PS: There doesn't appear to be any pcore for the mkid_dac_4x in the
repository, does anyone have this in their mlib_devel? If so can you raise
a pull request against casper / point me at your repository. Failing that,
I'll copy/paste the code from here --
https://github.com/argonnexraydetector/RoachFirmPy/tree/master/ANLYellowBlocks/mkid_dacadc_4x

On Mon, 28 Sep 2015 at 00:20 G Jones  wrote:

> Regarding the parallel to serial converter, so far I haven't experienced a
> need to set the configuration registers on the DAC, so I just deleted that
> block inside the yellow block and tied the output ports to constants.
> Obviously not a good solution if you do need the configuration registers.
> Not sure about the warning.
>
> Glenn
> On Sep 27, 2015 7:02 PM, "Tubbesing, Richard G" 
> wrote:
>
>> Hello,
>>
>>
>> I am a graduate student at ERAU using ROACHs for my research project.
>>
>>
>> I have been trying to use the toolflow for some time now and I have run
>> in to many issues.
>>
>>
>> Currently, I have the latest mlib_devel from the casper-astro git.
>>
>>
>> When I compile a design that includes the dac_mkid yellow block, I am
>> having two issues:
>>
>>
>> 1) If the yellow block is placed fresh from the library into the model
>> and then the model is compiled, I get an error related to initializing mask
>> parameters on the "parallel_to_serial" block that is in a subsystem of the
>> dac_mkid block.
>>
>>
>> I can fix this if I replace the "parallel_to_serial" with one from the
>> library or simply copying it and pasting itself back in to the model.
>>
>>
>> Is there anyway to fix this? I have a work around but it is rather
>> annoying to go in and replace those to blocks whenever I use the dac_mkid
>> yellow block.
>>
>>
>>
>> 2) I am getting many warnings when I compile. They look like the
>> following two:
>>
>>
>> Warning: Output port 1 of
>> 'adc_to_dac_test/dac_mkid1/adc_to_dac_test_dac_mkid1_dac_data_i1' is not
>> connected.
>> > In
>> /opt/Xilinx/14.6/ISE_DS/ISE/sysgen/bin/lin64/xlCompileGenerateMdl.p>xlCompileGenerateMdl
>> at 203
>>   In
>> /opt/Xilinx/14.6/ISE_DS/ISE/sysgen/bin/lin64/xlGenerateButton.p>xlGenerateButton
>> at 302
>>   In gen_xps_files at 323
>>   In casper_xps>run_Callback at 158
>>   In casper_xps at 88
>>   In
>> @(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject))
>>
>> Warning: Output port 1 of
>> 'adc_to_dac_test/dac_mkid1/adc_to_dac_test_dac_mkid1_dac_data_q0' is not
>> connected.
>> > In
>> /opt/Xilinx/14.6/ISE_DS/ISE/sysgen/bin/lin64/xlCompileGenerateMdl.p>xlCompileGenerateMdl
>> at 203
>>   In
>> /opt/Xilinx/14.6/ISE_DS/ISE/sysgen/bin/lin64/xlGenerateButton.p>xlGenerateButton
>> at 302
>>   In gen_xps_files at 323
>>   In casper_xps>run_Callback at 158
>>   In casper_xps at 88
>>   In
>> @(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject))
>>
>>
>> Can anyone shed some light on this? The model will compile successfully
>> but I think these warnings are preventing the actual design from working on
>> the ROACH.
>>
>>
>> Thank you,
>>
>>
>> -Richard T.
>>
>>
>>
>>

Re: [casper] Error with snapshot block

[Jack Hickish]

Hi Roberto,

I think if you tie the external sync to 1 (so it has no edges), you have to
issue a software sync. You can do this with the man_trig optional argument
of snapshot_get():

roach.snapshot_get('snap_name', man_trig=True)

Hope that helps,
Jack

On Thu, 17 Dec 2015 at 18:58 Roberto F.  wrote:

> Hi there,
>  I'm working on the ROACH II and came across a problem with the snapshot
> block. I put the snapshots to capture the signal from the ADC (adc5g) usign
> the following configuration:
>   -number of samples: 2^16
>   -Data width: 64
>   - check Start delay support and Use DsP48s to implement counters.
>
> The din comes from a bus of length 64, this are all the samples of one of
> the channels of the ADC appended.
> we and trig ports with a constant set to one.
> This configuration has work but recent it started to througth the
> following error:
> Traceback (most recent call last): File "snap_shot_plot.py", line 254, in
>  exit_fail() File "snap_shot_plot.py", line 247, in 
> continuePloting = continuous_plot(fpga) File "snap_shot_plot.py", line 163,
> in continuous_plot adc00, adc01, adc10, adc11, adc20, adc21 = get_data()
> File "snap_shot_plot.py", line 65, in get_data hola =
> numpy.array(adc5g.get_snapshot(fpga, "snapshot0")) File
> "/home/roach/Desktop/Roberto/git/ROACH2_ADC5g_Calibration/python/adc5g/tools.py",
> line 31, in get_snapshot grab = roach.snapshot_get(snap_name,
> man_trig=man_trig, wait_period=wait_period) File
> "/usr/local/lib/python2.7/dist-packages/corr/katcp_wrapper.py", line 946,
> in snapshot_get raise RuntimeError("A snap block logic error occurred or it
> didn't finish capturing in the allotted %2.2f seconds. Reported %i bytes
> captured."%(wait_period,bram_size)) RuntimeError: A snap block logic error
> occurred or it didn't finish capturing in the allotted 2.00 seconds.
> Reported 0 bytes captured.
>
> I tried to seek the error out, but the only thing that i came across is
> that the status register in the snapshot block has value 0.
>
> Could someone give me some advice on this matter?
>
> Greatings,
>   Roberto Fuentes
>

Re: [casper] building 300-receiver channel cross-correlator

[Jack Hickish]

On Tue, 22 Dec 2015 at 16:19 Neil Salmon <n.sal...@mmu.ac.uk> wrote:

> Jack,
>
>
>
> I’m thinking the data rate and the computational load is just too large
> for Roach2, so it might be easier to design the whole think from scratch
> around latest most powerful FPGA, and designing single bit sampling
> receiver circuits. The IF centre frequency is likely to be ~3 GHz with the
> 300 MHz bandwidth, so I’ll need to design receiver analogue circuits that
> operate at these frequencies, with either analogue or digital downshift,
> which then interface to the FPGA board.
>
If rolling out custom hardware is an option, then that will certainly leave
you with a smaller system.


>
>
> Would you happen to know which software packages I might use and have
> access to from ac.uk  if I wanted to design the digital receiver boards
> and FPGA boards at these frequencies?
>

I don't have any direct experience attempting to obtain board design tools
in the UK, but I know there is the europractice software service which can
get you licenses to various design packages supposedly at reasonable cost (
http://www.europractice.stfc.ac.uk/). I have to say I'm not entirely sure
what's available in the board design realm.

Jack


> Many thanks,
>
> Neil
>
>
>
> *From:* Jack Hickish [mailto:jackhick...@gmail.com]
> *Sent:* 18 December 2015 17:26
> *To:* Neil Salmon; James Smith
>
>
> *Cc:* casper@lists.berkeley.edu
> *Subject:* Re: [casper] building 300-receiver channel cross-correlator
>
>
>
> I believe that each ZDOK is good for about 50 Gb/s. A ROACH2 has two ZDOK
> ports. Presumably you'll give up a pin or two for clocks so maybe 40Gb/s is
> a more realistic rate. We use an ADC that achieves 40Gb/s over 32 of the 40
> ZDOK pin pairs. . But you'll also have to physically interface the
> digitizers, so whether you can have multiple digitizers time multiplexed on
> the same FPGA pins or whether you need one pin (pair?) per digitizer might
> also be limiting.
>
>
>
> Jack
>
>
>
> On Fri, 18 Dec 2015 at 16:46 Neil Salmon <n.sal...@mmu.ac.uk> wrote:
>
> Jack,
>
> Thanks for help. Do you have any idea of the I/O capacity of a single
> Roach2 board – just trying to figure out how many I may need?
>
> Thank you,
>
> Neil
>
>
>
> *From:* Jack Hickish [mailto:jackhick...@gmail.com]
> *Sent:* 18 December 2015 15:08
> *To:* James Smith; Neil Salmon
>
>
> *Cc:* casper@lists.berkeley.edu
> *Subject:* Re: [casper] building 300-receiver channel cross-correlator
>
>
>
> Hi Neil,
>
>
>
> A bit more information would be useful, but it sounds like if you could
> construct a ZDOK card that interfaced some (40, one per differential pair?)
> of your digitizers to a ROACH board you could use a handful of ROACH boards
> to perform all of the cross multiplication and accumulation and interface
> with CPU data recorders / post-processors.
>
>
>
> Jack
>
>
>
> On Fri, 18 Dec 2015 at 14:26 James Smith <jsm...@ska.ac.za> wrote:
>
> Hello Neil,
>
>
>
> CASPER tools could probably do what you're looking for, but I found your
> description a bit confusing. You're going to need to clarify somewhat.
>
>
>
> Regards,
>
> James
>
>
>
>
>
> On Fri, Dec 18, 2015 at 4:15 PM, Neil Salmon <n.sal...@mmu.ac.uk> wrote:
>
> Anyone help?
>
>
>
> I’m working in academia and need to build a 300-receiver channel
> single-bit digitiser / cross-correlator with a single frequency channel
> having a bandwidth of 300 MHz, centre frequency ~3 GHz. The single bit
> digitisers sample I giving a total data rate of 180 Gbps and using XOR
> gates to do the cross-correlations, the total computation rate is 54 T XOR
> operations per second. I need to accumulate cross-correlations typically
> for times ranging from 10 ms to a few seconds. The system would comprise an
> array of single bit digitisers linked via a high speed data bus to FPGA
> boards for the cross-correlation/accumulation. I’ve no skills in board
> design but could probably learn VHDL. I don’t have funding to commission a
> design and build but wondered if anyone in this community could advise how
> I should go about building this system at our university.
>
>
>
> Thank you for any help you can provide.
>
>
>
> Neil
>
> "Before acting on this email or opening any attachments you should read
> the Manchester Metropolitan University email disclaimer available on its
> website http://www.mmu.ac.uk/emaildisclaimer "
>
>
>
> "Before acting on this email or opening any attachments you should read
> the Manchester Metropolitan University email disclaimer available on its
> website http://www.mmu.ac.uk/emaildisclaimer "
>
> "Before acting on this email or opening any attachments you should read
> the Manchester Metropolitan University email disclaimer available on its
> website http://www.mmu.ac.uk/emaildisclaimer "
>

Re: [casper] building 300-receiver channel cross-correlator

[Jack Hickish]

Hi Neil,

A bit more information would be useful, but it sounds like if you could
construct a ZDOK card that interfaced some (40, one per differential pair?)
of your digitizers to a ROACH board you could use a handful of ROACH boards
to perform all of the cross multiplication and accumulation and interface
with CPU data recorders / post-processors.

Jack

On Fri, 18 Dec 2015 at 14:26 James Smith  wrote:

> Hello Neil,
>
> CASPER tools could probably do what you're looking for, but I found your
> description a bit confusing. You're going to need to clarify somewhat.
>
> Regards,
> James
>
>
> On Fri, Dec 18, 2015 at 4:15 PM, Neil Salmon  wrote:
>
>> Anyone help?
>>
>>
>>
>> I’m working in academia and need to build a 300-receiver channel
>> single-bit digitiser / cross-correlator with a single frequency channel
>> having a bandwidth of 300 MHz, centre frequency ~3 GHz. The single bit
>> digitisers sample I giving a total data rate of 180 Gbps and using XOR
>> gates to do the cross-correlations, the total computation rate is 54 T XOR
>> operations per second. I need to accumulate cross-correlations typically
>> for times ranging from 10 ms to a few seconds. The system would comprise an
>> array of single bit digitisers linked via a high speed data bus to FPGA
>> boards for the cross-correlation/accumulation. I’ve no skills in board
>> design but could probably learn VHDL. I don’t have funding to commission a
>> design and build but wondered if anyone in this community could advise how
>> I should go about building this system at our university.
>>
>>
>>
>> Thank you for any help you can provide.
>>
>>
>>
>> Neil
>> "Before acting on this email or opening any attachments you should read
>> the Manchester Metropolitan University email disclaimer available on its
>> website http://www.mmu.ac.uk/emaildisclaimer "
>>
>
>

Re: [casper] Interfacing 64-channel ADC with ROACH-2

[Jack Hickish]

Hi Kaushal, cc. CASPER,

All good here (Berkeley), thanks. Hope you are well too.

It's been a long time since I've used that ADC, but from what I remember...

- Yes, you need to appropriately drive the ADC's reset through the jumper.
If things aren't working and you're debugging with a probe, note that this
reset is active low.
- the yellow block uses GPIO[0] for the ADC's reset. On ROACH, you had the
choice between gpio banks A and B. On ROACH2, this option on the yellow
block doesn't do anything.
- If you're using the SPI interface, the yellow block uses GPIOs 1,2,3 for
data, clk, and cs_n, respectively.
- The ADC reset is controlled by the active high reset input on the yellow
block, which is inverted and drives GPIO[0]. I suggest tying this to a
software register.

There are more details at https://casper.berkeley.edu/wiki/X64_adc

Don't forget there's some link calibration stuff you need to do -- details
are on that wiki page.

Let me know if you have other questions,

Cheers

Jack


On Wed, 8 Jun 2016 at 06:07 Kaushal Buch  wrote:

> Dear Jack,
>
> Hope you are doing good.
>
> We have recently purchased 64-channel ADC boards and are planning to use
> them with ROACH-2. We have a basic design developed for packetizing the
> data and sending it on 10GbE port.
>
> I have gone through the available literature for this on the internet.
> However, I need some additional confirmation with reference to the
> 64-channel ADC board:
>
> 1. Is it mandatory to reset the ADC through jumper  ? If yes, which pin
> should it be connected to on the ROACH-2 board ?
>
> 2. Can we reset the ADC via software register or GPIO ? In this case, how
> to configure the GPIO ?
>
>
>
> Thanks & Regards,
>
> Kaushal
>

Re: [casper] Error in Simulating Roach 2 Tutorial 1 .mdl file

[Jack Hickish]

Hi Christopher,

Which scope outputs are you not able to reproduce from the wiki? What
outputs did you see?

Cheers
Jack

On Tue, 14 Jun 2016 at 10:21 Christopher Barnes  wrote:

> Hello,
>
> My name is Christopher Barnes, and I'm a graduate student at the
> University of Michigan.  I'm working through the first four tutorials on
> the Casper website (located at https://casper.berkeley.edu/wiki/Tutorials)
> to program a ROACH2 as a wideband pocket correlator.  I've finished
> building the .mdl file from the first tutorial, and my output from the
> scopes did not match what is displayed on the webpage, so I'm requesting
> some help with this.  I'm a beginner, so I'm not sure what the problem
> could be aside from the cookbook instructions on the website.
>
> If you're willing to help me, then please email me back and I can show you
> my file.  My suspicion is that the discrepancy between my output and the
> output on the webpage is caused by an outdated release of the tools in
> Simulink.
>
>
>

Re: [casper] Error in Simulating Roach 2 Tutorial 1 .mdl file

[Jack Hickish]

Hi Christopher,

Cool, 50% of problems solved! If you throw a scope on the enable and reset
inputs of the counter you hopefully will see something amiss.

J

On Tue, 14 Jun 2016 at 11:17 Christopher Barnes <barnc...@umich.edu> wrote:

> The axes were not auto-scaled for the adder; you were correct.
>
> For the counter, the settings are correct; I just checked them again.  Do
> you have any more ideas on this?
>
> On Tue, Jun 14, 2016 at 2:04 PM, Jack Hickish <jackhick...@gmail.com>
> wrote:
>
>> For the adder, have you clicked the icon at the top marked with a pair of
>> binoculars to auto-scale the axes?
>>
>> For the counter, are your control signal and slicing definitely correct
>> -- i.e., is the reset of the counter 0, and the enable of the counter 1?
>>
>> Cheers
>> Jack
>>
>> On Tue, 14 Jun 2016 at 11:00 Christopher Barnes <barnc...@umich.edu>
>> wrote:
>>
>>> Jack,
>>>
>>> I'm not able to reproduce the counter output (
>>> https://casper.berkeley.edu/wiki/File:Counter_sim.png) or the Adder
>>> Output (https://casper.berkeley.edu/wiki/File:Adder_sim.png).  Instead
>>> of those two, I get a line at 0 for the counter output and then just an
>>> empty set of axes for the adder output.
>>>
>>> On Tue, Jun 14, 2016 at 1:56 PM, Jack Hickish <jackhick...@gmail.com>
>>> wrote:
>>>
>>>> Hi Christopher,
>>>>
>>>> Which scope outputs are you not able to reproduce from the wiki? What
>>>> outputs did you see?
>>>>
>>>> Cheers
>>>> Jack
>>>>
>>>> On Tue, 14 Jun 2016 at 10:21 Christopher Barnes <barnc...@umich.edu>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> My name is Christopher Barnes, and I'm a graduate student at the
>>>>> University of Michigan.  I'm working through the first four tutorials on
>>>>> the Casper website (located at
>>>>> https://casper.berkeley.edu/wiki/Tutorials) to program a ROACH2 as a
>>>>> wideband pocket correlator.  I've finished building the .mdl file from the
>>>>> first tutorial, and my output from the scopes did not match what is
>>>>> displayed on the webpage, so I'm requesting some help with this.  I'm a
>>>>> beginner, so I'm not sure what the problem could be aside from the 
>>>>> cookbook
>>>>> instructions on the website.
>>>>>
>>>>> If you're willing to help me, then please email me back and I can show
>>>>> you my file.  My suspicion is that the discrepancy between my output and
>>>>> the output on the webpage is caused by an outdated release of the tools in
>>>>> Simulink.
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Physics Graduate Student Symposium
>>> University of Michigan
>>> sympphysg...@umich.edu
>>> Website <http://logan.physics.lsa.umich.edu/gss/>
>>>
>>>
>
>
> --
> Physics Graduate Student Symposium
> University of Michigan
> sympphysg...@umich.edu
> Website <http://logan.physics.lsa.umich.edu/gss/>
>
>

Re: [casper] Error in Simulating Roach 2 Tutorial 1 .mdl file

[Jack Hickish]

For the adder, have you clicked the icon at the top marked with a pair of
binoculars to auto-scale the axes?

For the counter, are your control signal and slicing definitely correct --
i.e., is the reset of the counter 0, and the enable of the counter 1?

Cheers
Jack

On Tue, 14 Jun 2016 at 11:00 Christopher Barnes <barnc...@umich.edu> wrote:

> Jack,
>
> I'm not able to reproduce the counter output (
> https://casper.berkeley.edu/wiki/File:Counter_sim.png) or the Adder
> Output (https://casper.berkeley.edu/wiki/File:Adder_sim.png).  Instead of
> those two, I get a line at 0 for the counter output and then just an empty
> set of axes for the adder output.
>
> On Tue, Jun 14, 2016 at 1:56 PM, Jack Hickish <jackhick...@gmail.com>
> wrote:
>
>> Hi Christopher,
>>
>> Which scope outputs are you not able to reproduce from the wiki? What
>> outputs did you see?
>>
>> Cheers
>> Jack
>>
>> On Tue, 14 Jun 2016 at 10:21 Christopher Barnes <barnc...@umich.edu>
>> wrote:
>>
>>> Hello,
>>>
>>> My name is Christopher Barnes, and I'm a graduate student at the
>>> University of Michigan.  I'm working through the first four tutorials on
>>> the Casper website (located at
>>> https://casper.berkeley.edu/wiki/Tutorials) to program a ROACH2 as a
>>> wideband pocket correlator.  I've finished building the .mdl file from the
>>> first tutorial, and my output from the scopes did not match what is
>>> displayed on the webpage, so I'm requesting some help with this.  I'm a
>>> beginner, so I'm not sure what the problem could be aside from the cookbook
>>> instructions on the website.
>>>
>>> If you're willing to help me, then please email me back and I can show
>>> you my file.  My suspicion is that the discrepancy between my output and
>>> the output on the webpage is caused by an outdated release of the tools in
>>> Simulink.
>>>
>>>
>>>
>
>
> --
> Physics Graduate Student Symposium
> University of Michigan
> sympphysg...@umich.edu
> Website <http://logan.physics.lsa.umich.edu/gss/>
>
>

Re: [casper] ASIAA adc5g downsampling

[Jack Hickish]

Hi Amit,

That's correct, assuming you are operating the adc in single input mode. It
also has a dual-input mode, where the first 8 outputs are one input, and
the second 8 are the other.
Don't forget that the input clock in single input (aka interleaved) mode
should be half the total sample rate. Eg., for 5gsps you input a 2.5ghz
clock. Though I suppose if you're going to downsample anyway then you may
as well use the adc in dual input mode.

Cheers,
Jack

On Tue, 31 May 2016, 04:23 Amit Bansod,  wrote:

> Hello,
>
> We are trying to sample a signal 100 MHz to 270 MHz with fpga running at
> 250MHz.
>
> To downsample by 4, I simply take every 4th output of the 16 outputs
> available from the yellow block of asiaa adc5g. We do have an
> anti-aliasing filter for the desired 500MHz bw.
>
> Is this correct or am I missing something obvious ?
>
>
> Cheers,
> Amit
>
>

Re: [casper] VHDL for ROACH2

[Jack Hickish]

On Wed, 22 Jun 2016, 03:53 Adam Isaacson, <aisaac...@ska.ac.za> wrote:

> Hi Jack and Andrea,
>
> I have tested the JASPER tool flow (matlab/python hybrid) on SNAP (no
> hardware, just compiling) and we are in the process of testing on skarab.
> We still have a lot more testing to do, so there may be bugs - you have
> been warned. There is currently no support for ROACH2 or rather, this still
> needs to be added at some point, as far as I am aware. The current CASPER
> toolflow (matlab only and no python) supports ROACH2.
>

H'interesting - thanks for the setting me straight, Adam. There was a
point, quite a long time ago, when jasper could at least compile tutorial 2
(ten gig Ethernet) for roach2. I thought this had been developed further -
guess not! Mea culpa.

J



> @Andrea: Just so you know. We have are working with Optinum Solutions here
> in South Africa and one of the tasks is to target the ROACH2 using
> MathWorks HDL-Coder i.e. the HDL code will get generated from the MathWorks
> environment. The problem with the MathWorks tools are that they are very
> expensive and it is not always a viable option. If you are from an academic
> institution then they offer really good deals. It may be worthwhile looking
> at this. We hope to have ROACH2 targeted by the end of the year. The idea
> is to compare HDL-Coder's code generation efficiency with our current
> toolflow.
>
> @Andrea: A lot of effort has been spent on developing the CASPER and
> JASPER toolflow. It really is a one-click toolflow, which when complete
> generates the project files and programming files. These project files can
> then be opened using the Vivado or ISE GUI just the same way as if you had
> created the VHDL or verilog source yourself.
>
> Good luck!
>
>
> Kind Regards,
>
> Adam
>
> On Tue, Jun 21, 2016 at 11:47 PM, Jack Hickish <jackhick...@gmail.com>
> wrote:
>
>> Hi Andrea, cc-ing maillist, since I don't think you're the only one to do
>> (or want to do) this,
>>
>> What you are suggesting is absolutely technically possible, though (as
>> much as I dislike simulink), I'd think really hard before going through
>> with it. Note also, if you don't use the toolflow, you become completely
>> responsible for managing the FPGA's memory-mapped devices, and will have to
>> manually build a boffile if you want to use the katcp/borphserver
>> programming environment. That said, others may already have done all the
>> legwork for you.
>>
>> Anyway, with that cautionary note
>>
>> The VHDL (or verilog) for the various CASPER blocks is available as part
>> of the various pcores of the roach2 base package --
>> https://github.com/casper-astro/mlib_devel/tree/master/xps_base/XPS_ROACH2_base/pcores
>> .
>>
>> The instantiation of these interface blocks is performed by the toolflow
>> at compile time, which generates a Xilinx EDK spec system.mhs top level
>> file. If you want to find out how to instantiate these blocks yourself,
>> using the toolflow as a guide, here is where you climb into the CASPER
>> rabbit hole.
>>
>> There is an EDK template for a compile in the base package: for ROACH2 --
>> https://github.com/casper-astro/mlib_devel/blob/master/xps_base/XPS_ROACH2_base/system.mhs
>>  .
>> In theory, if you strip out the #IF#s in this file, you'll have a top-level
>> model description you can add stuff to -- but it still won't be in VHDL,
>> even if the instantiated modules are. Constraints are in
>> https://github.com/casper-astro/mlib_devel/blob/master/xps_base/XPS_ROACH2_base/data/system.ucf
>>
>> The toolflow adds to this template in a variety of ways --
>> * individual yellow blocks can add code via the MATLAB object-oriented
>> infrastructure via the gen_mhs_ip and gen_ucf methods of the xps class --
>> eg.
>> https://github.com/casper-astro/mlib_devel/tree/master/xps_library/%40xps_adc5g
>> * or via an overridden gen_mhs_ip or gen_ucf -- eg.
>> https://github.com/casper-astro/mlib_devel/blob/master/xps_library/%40xps_bram/gen_mhs_ip.m
>> * or via all the #IF# statements in the base package system.mhs/system.ucf
>>
>> If (#IF#?) you want to dig through the matlab block classes, and
>> system.mhs looking for what a particular yellow block *does* when it is
>> instantiated, you probably could. But it will still be an EDK file, not
>> vhdl.
>> You could also fire up simulink, compile a design with appropriate yellow
>> blocks in and then grab the system.mhs it generates and use that as a
>> template.
>> You could also look in an old ROACH2 testing repository where firmware
>> was tested prior to being casperized --
&g

Re: [casper] SNAP orders

[Jack Hickish]

Just to clarify a few things -

This is the SNAP 1 board (kintex 7) in its second revision. The kintex
ultrascale SNAP2 will be announced as and when we have info on it.
Cost of the SNAP 1 is still TBC, but in the small batches were have built
so far has come in at about 2000 USD, including fpga (at $280), not
including enclosure or 12v power supply.
Cheers
Jack

On Sat, 18 Jun 2016, 15:15 Jack Hickish, <jackhick...@gmail.com> wrote:

> Hi all,
>
> SNAP revision 2 is (finally) about to finish being tested. Various folk
> expressed interest in purchasing them once they were verified.
>
> Could those who are still interested please reply to me off-list with
>   - the approximate number of boards they want
>   - the FPGA model they need*
>   - any constraints on turnaround time.
>
> I'll then try and co-ordinate with Digicom and the rest of Berkeley to
> gather the right parts.
>
> Thanks,
>
> Jack
>
>
> * Available models are XC7K160T, XC7K325T, XC7K410T -- see
> http://www.xilinx.com/support/documentation/data_sheets/ds180_7Series_Overview.pdf
>
>

Re: [casper] ADC 5g testing

[Jack Hickish]

Hi Amit,

For what it's worth, you can always just run the ADC faster, but only use a
subset of the yellow block outputs. Eg., clock the ADC at 1280MHz, and use
every 8th yellow block output. This can be handy because
1. You get to avoid whatever edge cases exist which cause various blocks to
break at super-low clock speeds.
2. You avoid interleaving ADC cores.
3. Your FPGA design will use far less logic and DSP since it will be
running at a higher clock rate.

I guess the downside is that if you already have a design built which
expects 16 parallel inputs from the ADC block you'll have to do some
redesigning

Just my $0.02

Jack



On Fri, 17 Jun 2016 at 00:18 Amit Bansod  wrote:

> Hi Rurik,
>
> Sorry for opening an old thread.
>
> I am trying to run fpga on ROACH2 board (we have 2 ADC5g with 1:1 DEMUX
> mode) at 160 MHz. I see the zdok1 snapshot data shows no data whatsoever
> while snapshot from zdok0 is fine. The MMCM also fails for zdok1.
>
> Have you successfully ran fpga at lower frequencies ?
>
> Cheers,
> Amit
>
> On 17-Jun-15 1:32 PM, Primiani, Rurik wrote:
>
> Hi Amit,
>
> The range of frequencies you are trying, is this a test tone going into
> the IF? The MMCM calibration should be done using the ADC's test ramp
> output mode not an external IF input. Are you setting both ADC's into test
> ramp output mode before attempting the calibration? The procedure for
> calibrating the ADC's should go like this in Python:
>
> from adc5g import *
> set_test_mode(roach, 0)
> set_test_mode(roach, 1)
> sync_adc(roach)
> opt0, glitches0 = calibrate_mmcm_phase(roach, 0, ['scope_raw_0_snap',])
> opt1, glitches1 = calibrate_mmcm_phase(roach, 1, ['scope_raw_1_snap',])
> unset_test_mode(roach, 0)
> unset_test_mode(roach, 1)
>
> Best,
> Rurik
>
>
> On Wed, Jun 17, 2015 at 5:09 AM, Amit Bansod 
> wrote:
>
>> Hi Rurik,
>>
>> Thanks a lot for useful inputs on the adc calibration.
>>
>> We tried MMCM calibration for zdock=0,1 for a few range of frequencies
>> (100 MHz, 150 Mhz, 187.5 MHz,200 MHz) and we observed that the MMCM
>> fails for zdock=1 for frequencies: 100 & 150 MHz.
>>
>> I looked at the glitch profile for these two frequencies and there was
>> no region with zero glitches. What would be a good strategy to debug
>> this issue ? I can send you the glitch profiles and bit code if that is
>> useful.
>>
>> Best Regards,
>> Amit
>>
>>
>>
>> On 12-Jan-15 5:13 PM, Primiani, Rurik wrote:
>> > Hi Amit,
>> >
>> > That sadly looks nothing like a sine wave.
>> >
>> > The adc5g package is some Python code I developed to operate the ADC5g.
>> > Please see the Github link below:
>> >
>> > https://github.com/sma-wideband/adc_tests/
>> >
>> > It is important to calibrate the MMCM clk-to-out phase using the
>> > procedure outlined below. I think this may be why your output looks so
>> > strange.
>> >
>> > Are familiar with Python and the corr package?
>> >
>> > Thanks,
>> > Rurik
>> >
>> >
>> > On Mon, Jan 12, 2015 at 10:51 AM, Amit Bansod <
>> aban...@mpifr-bonn.mpg.de
>> > > wrote:
>> >
>> > Hi Rurik,
>> >
>> > I am not using the ADC5g package. The fpga is running at 150 MHz.
>> >
>> > Earlier, I did not take care of offset binary output but it did not
>> > solve the problem.
>> >
>> > By "not consistent with expected results", I mean some data points
>> > were offset by large amount. I have attached the plot (first 128
>> > data-points) for reference.
>> >
>> > I have not done any core-to-core mismatch corrections. Do you think
>> > that could be an issue ?
>> >
>> > Thanks & Regards,
>> > Amit
>>
>
>> >
>> >
>> >
>> > On 12-Jan-15 4:05 PM, Primiani, Rurik wrote:
>> >
>> > Hi Amit,
>> >
>> > Could you please provide an example plot of what you mean by
>> "not
>> > consistent with expect results"?
>> >
>> > Questions:
>> >
>> > 1. What is your clock rate?
>> >
>> > 2. Have you calibrated the MMCM?
>> >
>> > 3. The ADC output is offset binary, are you correctly
>> > interpreting it as
>> > such?
>> >
>> > 4. If you are using the adc5g python package the BRAM output
>> > needs to be
>> > converted to signed binary before capture (by subtracting 128).
>> > Have you
>> > done so?
>> >
>> > 5. Have you done any core-to-core mismatch corrections?
>> >
>> > 6. Less importantly, is your clock generator reference locked to
>> > your
>> > test tone synthesizer?
>> >
>> > Thanks,
>> >
>> > Rurik
>> >
>> >
>> > On Mon, Jan 12, 2015 at 9:58 AM, Amit Bansod
>>
> > 
>> > 
>
>> > >> wrote:
>> >
>> > Dear All,
>> >
>> > I am trying to test the ADC output for 

Re: [casper] 32 parallel inputs to fft_wideband_real

[Jack Hickish]

Hi Homin,

What total size of FFT are you trying to do? How does the FFT fail?

Cheers,
Jack

On Mon, 11 Jan 2016 at 00:35 Homin Jiang  wrote:

> Hello:
>
> Does anyone have the experience of the 32 simultaneous inputs to the
> fft_wideband_real ?  I have tried that for couple of days without any luck.
>
> Best regards
> homin jiang
>
>
>

Re: [casper] 32 parallel inputs to fft_wideband_real

[Jack Hickish]

Hi Homin,

For what it's worth, I can successfully run "update diagram" on a 32 input
2^10 point fft_wideband_real block (with mlib_devel b6e70b660) using all
default block parameters. Xilinx 14.7, Matlab 2012b.

Cheers,
Jack

On Mon, 11 Jan 2016 at 17:28 Homin Jiang <ho...@asiaa.sinica.edu.tw> wrote:

> Hi Jack:
>
> I tried 128, 512, 1024, 2048 channels.
> When the input is 32, the fft block generates 4 stages of butterfly, it
> fails in generation of coeff_gen which is inside the 4th stage of
> butterfly. There is no line connections inside the coeff_gen blocks.
>
>
> regards
> homin
>
> On Tue, Jan 12, 2016 at 12:38 AM, Jack Hickish <jackhick...@gmail.com>
> wrote:
>
>> Hi Homin,
>>
>> What total size of FFT are you trying to do? How does the FFT fail?
>>
>> Cheers,
>> Jack
>>
>> On Mon, 11 Jan 2016 at 00:35 Homin Jiang <ho...@asiaa.sinica.edu.tw>
>> wrote:
>>
>>> Hello:
>>>
>>> Does anyone have the experience of the 32 simultaneous inputs to the
>>> fft_wideband_real ?  I have tried that for couple of days without any luck.
>>>
>>> Best regards
>>> homin jiang
>>>
>>>
>>>
>>
>

Re: [casper] ROACH2 spectrum zeroes: request to verify my results

[Jack Hickish]

You get the same problem even when using the boffile and python script that
worked on my ROACH2 in Berkeley?

What's your clocking arrangement?

Cheers,
Jack

On Fri, 29 Jan 2016 at 07:20 Michael D'Cruze <
michael.dcr...@postgrad.manchester.ac.uk> wrote:

> Hi Jack,
>
>
>
> Cc: Casper list
>
>
>
> Sorry it’s taken me so long to come back – I got sucked into a few side
> projects. Unfortunately I have to report that the problem still exists: I
> am unable to use the tut3_noquant designs to produce a spectrum – they all
> contain zeroes. For the record (and for the sake of anyone else reading
> this in future), below is a link to an archive containing snips of the back
> end of my designs (vacc onwards), print statements of the first 20
> channels, and a plot for one of the scenarios. In short, the problem
> appears to be in the propagation of data between the vacc and the brams.
> I’ve eliminated the brams and vaccs individually. The only scenario in
> which I can produce a proper spectrum is where a 32-bit slice is
> implemented straight after the vacc. Why this would help is beyond me,
> however it does and is the design I am going to have to continue with
> unless a proper solution can be found.
>
>
>
> I should add that this problem appears to be independent of the design
> speed (tested down to 100 MHz FPGA clock), and the problem was seen on a
> ROACH2 with the ADC in either port, and also on a ROACH1.
>
>
>
> https://dl.dropboxusercontent.com/u/38103354/r2_spectra.zip
>
>
>
> BW
> Michael
>
>
>
> *From:* Jack Hickish [mailto:jackhick...@gmail.com]
>
> *Sent:* 12 January 2016 21:28
>
> *To:* Michael D'Cruze
> *Subject:* Re: [casper] ROACH2 spectrum zeroes: request to verify my
> results
>
>
>
> Hi Michael,
>
>
>
> That's weird. The adc should be fine in either port. As long as the adc
> yellow block zdok port and the adcX_clk match in the mssge block.
>
>
>
> Jack
>
> On Tue, 12 Jan 2016 1:09 pm Michael D'Cruze <
> michael.dcr...@postgrad.manchester.ac.uk> wrote:
>
> Hi Jack,
>
>
>
> Thanks for that. I can’t see any differences between your model file and
> mine, EXCEPT that my iADC is in ZDOK1. I recall seeing some advice to use
> ZDOK0 instead however I was under the impression any of the issues were
> sorted. This also doesn’t explain why the spectrum forms correctly when
> requantisation and 32-bit accumulators are used.
>
>
>
> Because of BBC Stargazing, I won’t be able to get at the ROACH to move the
> iADC to ZDOK0 and test your boffile, so I’ll drop you a line when I’ve got
> the results. I did, however, try my model file which was compiled to run at
> 800 MHz (now that I’ve had a chance to get at the sig gen which clocks the
> ADC) and the result was essentially the same. There were still zeroes.
>
>
>
> I’ll update you Thursday afternoon.
>
>
>
> Cheers
>
> Mike
>
>
>
> *From:* Jack Hickish [mailto:jackhick...@gmail.com]
> *Sent:* 12 January 2016 19:38
> *To:* Michael D'Cruze
>
>
> *Subject:* Re: [casper] ROACH2 spectrum zeroes: request to verify my
> results
>
>
>
>
>
> On Mon, 11 Jan 2016 at 16:03 Michael D'Cruze <
> michael.dcr...@postgrad.manchester.ac.uk> wrote:
>
> Jack,
>
>
>
> Please send me your model and boffiles. I need to try these here.
>
>
>
> Attached. I've also attached the python script, for good measure.
>
>
>
> I’ve just done exactly what you specified here, and this is how the first
> 20 channels appear:
>
>
>
> [image: image001.png]
>
>
>
> Now, I compiled the design to run at 256 MHz as is required by the
> sampling speed we need to use, and as such there were some timing errors
> initially. I deleted the three LED readouts as they weren’t needed, but I
> also needed to add a clock cycle of latency to the adder in each of the
> VACCs. There was negative slack between the readout of the delay_bram’s RAM
> block and the adder. I can’t see how this could cause such zeroes but
> nevertheless please add your thoughts.
>
>
>
> I don't see how this would cause zeros (I'm not sure changing the adder
> delay doesn't subtly mess up the timing in the vacc, but I'd need to take a
> second to think about it). For what it's worth, I'm running mine adc0_clk @
> 200MHz (adc in ZDOK one with sample rate 800MHz).
>
>
>
>
>
> Jack
>
>
>
>
>
> I will not be able to try the design at 800 MHz until I get to Jodrell in
> the morning, but I’ll eat my hair if it outputs a proper spectrum….
>
>
>
> BW
> Michael
>
>
>
> *From:* Jack Hickish [mailto:jackhick...@gmail.com]
> *Sent:* 11 Jan

Re: [casper] PlanAhead to a working bof

[Jack Hickish]

There's also a UCF yellow block that lets you add ucf files to your design
(much like the PCORE yellow block). I think there's also a method to inject
ucf constraints via an environment variable (I think you could find this in
the git log somewhere).

Cheers,
Jack

On Wed, 3 Feb 2016 at 10:31 David MacMahon 
wrote:

> Hi, Johnathon,
>
> On Feb 3, 2016, at 2:26 AM, Gard, Johnathon D. 
> wrote:
>
> There are options in the PlanAhead bitfile generation and I could have
> those wrong. This could be very likely.
>
>
> The bitgen options that the CASPER flow uses are in
> mlib_devel/xps_base/XPS_ROACH2_base/etc/bitgen.ut.
>
> I  could alternatively use the system.ucf file updated by PlanAhead
> through the casper_xps process in matlab. However this would drop my
> control of the PAR which seems to have a strong influence on how well it
> meets timing. Ironically, timing driven placement gets the far worse timing
> results.
>
>
> Newer versions of mlib_devel support the inclusion of user-specified UCF
> snippets into the overall UCF file.  To do this, you create a
> “/ucf” directory and then place files with a “.ucf” extension
> into that directory.  All .ucf files in that directory will be included in
> the overall system.ucf file that the casper flow generates.
>
> For example, if your model is "/path/to/my_model.slx", then all *.ucf
> files in “/path/to/my_model/ucf/” will be automatically included in the
> system.ucf constraints file.
>
> HTH,
> Dave
>
>

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

[Jack Hickish]

Hi Vishwa,

Is the syntax definitely -demux=1 andnot either --demux=1 or -d 1 ?


Jack

On Wed, 3 Feb 2016, 12:39 a.m. Vishwa Seneviratne 
wrote:

> Hi,
>
> I am working on how to work with different operating of the 'ADC16x250-8
> coax rev 2' for a very simple design to test how the ADC works. The design
> is compiled at an IP clock rate setting of 200MHz. My objective is to
> sample my input signal at higher sampling rate (preferably 400, 800 MHz).
>
> According to the user guide ''
> https://casper.berkeley.edu/wiki/images/4/4c/ADC16_user_guide.txt; by
> setting the demux parameter I should be able to switch between different
> sampling rates. I get the following error.
>
> $ adc16_init.rb -v -demux=1 192.168.10.5 poly_design.bof
>
> /var/lib/gems/1.9.1/gems/adc16-0.3.6/bin/adc16_init.rb:40:in ` (required)>': invalid option: -demux=2 (OptionParser::InvalidOption)
>
> from /usr/local/bin/adc16_init.rb:19:in `load'
>
> from /usr/local/bin/adc16_init.rb:19:in `'
>
> When I don't pass the 'demux' parameter the ADC board get initialized to 8
> analog inputs by default.
>
> How do I resolve this issue? or how can I set the ADC's to operate at
> different sampling rates?
>
> Thank you in advance
>
> Sincerely,
>
>
> *Vishwa Seneviratne*
>
> *Graduate Student*
>
> *Dept. of Electrical and Computer Engineering*
> *University of Akron*
>

Re: [casper] Compiler merging SRLs

[Jack Hickish]

Ha, I just read my email in the thread you linked. I guess turning off
behavioural hdl isn't (ever? always?) the solution.

On Mon, 25 Jan 2016 5:14 pm Jack Hickish <jackhick...@gmail.com> wrote:

> Hi Matt,
>
> You can resynthesize the "main" simulink netlist, but off the top of my
> head I don't know the exact way to go about this. I think you can dig out
> the netlist from the sysgen build directory and use the resynth script on
> that. Perhaps Dave MacMahon (who I believe wrote that script) could comment
> further.
> My experience was that adding the lc_off flag helped sometimes, but I
> still found luts combined on some occasions - I never got satisfactorily to
> the bottom of this.
> You can explicitly prevent combining of some blocks (eg. delays) by
> turning off any behavioural hdl options they have, but this isn't viable if
> it needs doing to so many blocks that resource utilisation ends up being
> too horrifically impacted.
>
> Having just seen the skarab/roach3 presentation in South Africa, I fondly
> await the demise of virtex 6 and ISE.
>
> Jack
>
> On Sat, 23 Jan 2016 10:48 pm Matt Strader <mstra...@physics.ucsb.edu>
> wrote:
>
>> Hello Casperites (especially Jack),
>>
>> I've run into the problem that Jack describes in this thread:
>> http://www.mail-archive.com/casper%40lists.berkeley.edu/msg05581.html
>> The compiler keeps wanting to combine unrelated LUTs on opposite sides of
>> the Virtex 6, resulting in timing errors that are 90% routing.
>>
>> At the end of the thread Jack says the solution is to use the "-lc off"
>> option in resynth_netlist and in map.
>> I'm using only one black box containing my pfb and fft.  The rest of my
>> design is not black boxed.  I used resynth_netlist on the black box's ngc
>> file, but it looks like I can't use it on the netlists generated by
>> casper_xps.  Is that right?
>> I also added "-lc off" to the map options in
>> XPS_ROACH2_base/etc/fast_runtime.opt
>>
>> After doing this, I'm still getting timing errors from LUT combining.  Is
>> there somewhere else I need to turn this off?  Any suggestions?
>>
>> Thanks,
>> Matt Strader
>>
>>
>>
>>
>>

Re: [casper] Compiler merging SRLs

[Jack Hickish]

Hi Matt,

You can resynthesize the "main" simulink netlist, but off the top of my
head I don't know the exact way to go about this. I think you can dig out
the netlist from the sysgen build directory and use the resynth script on
that. Perhaps Dave MacMahon (who I believe wrote that script) could comment
further.
My experience was that adding the lc_off flag helped sometimes, but I still
found luts combined on some occasions - I never got satisfactorily to the
bottom of this.
You can explicitly prevent combining of some blocks (eg. delays) by turning
off any behavioural hdl options they have, but this isn't viable if it
needs doing to so many blocks that resource utilisation ends up being too
horrifically impacted.

Having just seen the skarab/roach3 presentation in South Africa, I fondly
await the demise of virtex 6 and ISE.

Jack

On Sat, 23 Jan 2016 10:48 pm Matt Strader  wrote:

> Hello Casperites (especially Jack),
>
> I've run into the problem that Jack describes in this thread:
> http://www.mail-archive.com/casper%40lists.berkeley.edu/msg05581.html
> The compiler keeps wanting to combine unrelated LUTs on opposite sides of
> the Virtex 6, resulting in timing errors that are 90% routing.
>
> At the end of the thread Jack says the solution is to use the "-lc off"
> option in resynth_netlist and in map.
> I'm using only one black box containing my pfb and fft.  The rest of my
> design is not black boxed.  I used resynth_netlist on the black box's ngc
> file, but it looks like I can't use it on the netlists generated by
> casper_xps.  Is that right?
> I also added "-lc off" to the map options in
> XPS_ROACH2_base/etc/fast_runtime.opt
>
> After doing this, I'm still getting timing errors from LUT combining.  Is
> there somewhere else I need to turn this off?  Any suggestions?
>
> Thanks,
> Matt Strader
>
>
>
>
>

Re: [casper] Leuschner Spectrometer

[Jack Hickish]

Hi Rolando,

This is wrong -- the User IP clock source should be adc0_clk, at 24 MHz.
If you see a design with an ADC, but the clock source is set to to sys_clk,
this is *almost always* a mistake.

Jack

On Sat, 20 Feb 2016 at 19:04 Rolando Paz  wrote:

> Hi
>
> I have a question about the "User IP clock source" value on the model file
> Leuschner Spectrometer, because this value is programmed as "sys_clk" and
> the ADC has a value "ADC clock rate" of 96MHz.
>
> As I see in Leuschner circuit an external clock is used, then why appears
> sys_clk?
>
> https://casper.berkeley.edu/wiki/Leuschner_Spectrometer
>
> Regards
>
> Rolando Paz
>
>
>

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

[Jack Hickish]

Also, I don't think the problem is the software register, I think the
problem is present in both your designs, but in the "working" model the
compiler is optimizing away all the failing logic paths, which presumably
aren't actually doing anything given the way the blocks in the model are
connected together.

>From the passing timing report:


Timing constraint:
TS_ears_sbp22_adc16x250_8_ears_sbp22_adc16x250_8_bufg_i_2_ =
PERIOD TIMEGRP
"ears_sbp22_adc16x250_8_ears_sbp22_adc16x250_8_bufg_i_2_"
TS_adc16_line_clk / 0.5 HIGH 50%;
For more information, see Period Analysis in the Timing Closure User Guide
(UG612).

* 1863 paths analyzed, 1143 endpoints analyzed, 0 failing endpoints*
 0 timing errors detected. (0 setup errors, 0 hold errors, 0 component
switching limit errors)
 Minimum period is   3.235ns.


>From the failing timing report:

Timing constraint:
TS_ears_sbp22_adc16x250_8_ears_sbp22_adc16x250_8_bufg_i_2_ =
PERIOD TIMEGRP
"ears_sbp22_adc16x250_8_ears_sbp22_adc16x250_8_bufg_i_2_"
TS_adc16_line_clk / 0.5 HIGH 50%;
For more information, see Period Analysis in the Timing Closure User Guide
(UG612).

* 79231860653 paths analyzed, 61736 endpoints analyzed, 12780 failing
endpoints*
 12780 timing errors detected. (12746 setup errors, 34 hold errors, 0
component switching limit errors)
 Minimum period is  20.890ns.


The lack of paths analysed in the passing report suggests to me that most
of your design has been removed during optimization...

Jack

On Fri, 11 Mar 2016 at 00:18 Jack Hickish <jackhick...@gmail.com> wrote:

> Hi Nilan,
>
> It looks like there's a block called (something like) ppcm12/block_t_z2
> with a huge logic delay -- from line 135 of the failing twr file --
>
>   Data Path Delay:  20.585ns (Levels of Logic = 12)(Component delays
> alone exceeds constraint)
>
> What is this block? It looks like it has some multipliers and adders and
> stuff...
>
> There's also a timing error in the adc yellow block, but my guess is this
> is just because the place and route tool gave up when it hit impossible
> constraints elsewhere.
>
> Cheers,
> Jack
>
> On Thu, 10 Mar 2016 at 23:49 Nilan Udayanga <g...@zips.uakron.edu> wrote:
>
>> Hi all,
>>
>> We are having a little weird problem during the compilation of a roach 2
>> design with the adc16 block. I have a design for a specific application. It
>> is well pipelined and we are using ADC interfaces clocked at 200 MHz. When
>> I just terminate the output without using any software registers at the
>> output, there is no timing error (all timing costrains have been met). And
>> when I compile the design using the software register at the output (just a
>> one software register), it has a timing error, and says the maximum
>> frequency that can be achieved is around 50 MHz. I am wondering whether it
>> is a problem with the software register or not. Please find the following
>> attachments for the .twr and .twx files for each cases.
>>
>> I have tried using snapshots blocks too. Thats giving the same timing
>> error.
>>
>> Your help will be greatly appreciated.
>>
>> Regards,
>> Nilan Udayanga.
>>
>> On Wed, Mar 9, 2016 at 4:03 PM, Nilan Udayanga <g...@zips.uakron.edu>
>> wrote:
>>
>>> Hi All,
>>>
>>> Thank you very much for all your suggestions.
>>>
>>> I have two more questions,
>>>
>>> Since, ADCs need to be clocked at 480 MHz for the demux=2 mode, how does
>>> the FPGA clock at 240 MHz? does it use a clock divider internally?
>>>
>>> Is there any maximum operating frequency for the FPGA, when we use the
>>> adc16 block?
>>>
>>> Regards,
>>> Nilan Udayanga.
>>>
>>> On Wed, Mar 9, 2016 at 3:22 PM, Jack Hickish <jackhick...@gmail.com>
>>> wrote:
>>>
>>>> With regards to the demux option, for the system you describe you want
>>>> -d 2 (I.e. demux by = run the FPGA at half the sample rate, and process two
>>>> samples in parallel on every FPGA clock cycle). Basically, provided you
>>>> have the up to date ruby package, all you need to do is run adc16_init.rb
>>>> with appropriate options, and that will program your roach and set
>>>> everything up for you.
>>>>
>>>> I think the default mode of the adc16 ruby script assumes tha

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

[Jack Hickish]

Hi Nilan,

It looks like there's a block called (something like) ppcm12/block_t_z2
with a huge logic delay -- from line 135 of the failing twr file --

  Data Path Delay:  20.585ns (Levels of Logic = 12)(Component delays
alone exceeds constraint)

What is this block? It looks like it has some multipliers and adders and
stuff...

There's also a timing error in the adc yellow block, but my guess is this
is just because the place and route tool gave up when it hit impossible
constraints elsewhere.

Cheers,
Jack

On Thu, 10 Mar 2016 at 23:49 Nilan Udayanga <g...@zips.uakron.edu> wrote:

> Hi all,
>
> We are having a little weird problem during the compilation of a roach 2
> design with the adc16 block. I have a design for a specific application. It
> is well pipelined and we are using ADC interfaces clocked at 200 MHz. When
> I just terminate the output without using any software registers at the
> output, there is no timing error (all timing costrains have been met). And
> when I compile the design using the software register at the output (just a
> one software register), it has a timing error, and says the maximum
> frequency that can be achieved is around 50 MHz. I am wondering whether it
> is a problem with the software register or not. Please find the following
> attachments for the .twr and .twx files for each cases.
>
> I have tried using snapshots blocks too. Thats giving the same timing
> error.
>
> Your help will be greatly appreciated.
>
> Regards,
> Nilan Udayanga.
>
> On Wed, Mar 9, 2016 at 4:03 PM, Nilan Udayanga <g...@zips.uakron.edu>
> wrote:
>
>> Hi All,
>>
>> Thank you very much for all your suggestions.
>>
>> I have two more questions,
>>
>> Since, ADCs need to be clocked at 480 MHz for the demux=2 mode, how does
>> the FPGA clock at 240 MHz? does it use a clock divider internally?
>>
>> Is there any maximum operating frequency for the FPGA, when we use the
>> adc16 block?
>>
>> Regards,
>> Nilan Udayanga.
>>
>> On Wed, Mar 9, 2016 at 3:22 PM, Jack Hickish <jackhick...@gmail.com>
>> wrote:
>>
>>> With regards to the demux option, for the system you describe you want
>>> -d 2 (I.e. demux by = run the FPGA at half the sample rate, and process two
>>> samples in parallel on every FPGA clock cycle). Basically, provided you
>>> have the up to date ruby package, all you need to do is run adc16_init.rb
>>> with appropriate options, and that will program your roach and set
>>> everything up for you.
>>>
>>> I think the default mode of the adc16 ruby script assumes that, whatever
>>> mode you're using the ADC in, the external clock provided is at the sample
>>> rate. Though, as Matt added, the ADC supports other dividing options if
>>> they're useful to you and you're willing to read the ADC data sheet to work
>>> out how to set the divider properties.
>>>
>>> Cheers
>>> Jack
>>>
>>>
>>> On Wed, 9 Mar 2016, 09:49 David MacMahon, <dav...@astro.berkeley.edu>
>>> wrote:
>>>
>>>> Hi Vishwa,
>>>>
>>>> I am not at my computer right now, so this is from memory, but I think
>>>> you want to specify an IP clock rate of 240 MHz and supply a 480 MHz clock
>>>> to the ADC card(s). The IP clock rate is sometimes called the fabric clock
>>>> rate. It is the rate at which the FPGA logic elements (aka fabric) operate.
>>>> The ADC chips need a sample clock that is commensurate with the sampling
>>>> frequency. When you initialize the ADCs using adc16_init.rb, be sure to
>>>> pass the "-d" option. If your version of adc16_init.rb does not support the
>>>> "-d" option, then you will need to update it.
>>>>
>>>> Hope this helps,
>>>> Dave
>>>>
>>>> On Mar 9, 2016, at 08:33, Vishwa Seneviratne <mp...@zips.uakron.edu>
>>>> wrote:
>>>>
>>>> Hi David/Jack,
>>>>
>>>> We are working on a beam former and we use the 'ADC16x250-8 coax rev 2'
>>>> to sample RF signals using ROACH2-Rev 2. The operating BW is 240MHz. Thus,
>>>> we need to sample the signals at 480 MSamples/s. We have few queries
>>>> regarding the adc16 yellow block and how to setup the input clock.
>>>>
>>>> 1. Can we compile a design by setting the IP clock rate to 480MHz?
>>>> 2. Should we supply a IP clock frequency of 480MHz to the ADC board to
>>>> achieve a sampling rate of 480MSamples/s.  If not, at what clock rate
>>&g

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

[Jack Hickish]

You could always just try just throwing delays in there just to check it
fixes the compile, then at least you know that's the issue. Worrying  about
making a filter implementation that is both valid and meets timing can then
come later.

Good Luck!

Jack

On Fri, 11 Mar 2016 at 01:52 Nilan Udayanga <g...@zips.uakron.edu> wrote:

> Hi Jack,
>
> Yes, We tried lookahead pipelining as well. Even in that case, it compiled
> without the software register. However, when we add the software register,
> it failed for timing (similar to the previous design).
>
> Regards,
> Nilan Udayanga.
>
> On Thu, Mar 10, 2016 at 8:38 PM, Jack Hickish <jackhick...@gmail.com>
> wrote:
>
>> Hi Nilan,
>>
>> Yeah, I figured that would be a problem... :)
>> Does something like this (which i confess I haven't read, but Fig 14
>> looks potentially relevent) help? --
>> http://www.xilinx.com/support/documentation/white_papers/wp330.pdf
>>
>> Jack
>>
>> On Fri, 11 Mar 2016 at 01:21 Nilan Udayanga <g...@zips.uakron.edu> wrote:
>>
>>> Hi Jack,
>>>
>>> We can not add any more delays to the feedback loop multipliers and
>>> adders, since it changes the filter transfer function. However, we can try
>>> on distributing corresponding delays over adders and multipliers, without
>>> adding separate delays. But, I don't know whether it may change the
>>> critical path delay.
>>>
>>> Regards,
>>> Nilan Udayanga.
>>>
>>> On Thu, Mar 10, 2016 at 8:02 PM, Jack Hickish <jackhick...@gmail.com>
>>> wrote:
>>>
>>>> I think if you can add latency in those multipliers / adders you'll
>>>> probably find your problem will go away. It's the blow path that's
>>>> breaking, so I don;t think you can get around ijnserting some registers to
>>>> split up thje logic stages --
>>>>
>>>>
>>>> 
>>>> Slack:  -15.890ns (requirement - (data path - clock
>>>> path skew + uncertainty))
>>>>   Source:
>>>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42/srl_delay.synth_reg_srl_inst/partial_one.last_srl17e/reg_array[27].fde_used.u2
>>>> (FF)
>>>>   Destination:
>>>>  
>>>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm13_dda55e6716/block_z_1_0d8d8d72ce/mult1/comp1.core_instance1/blk0001/blk0006
>>>> (FF)
>>>>   Requirement:  5.000ns
>>>>   Data Path Delay:  20.585ns (Levels of Logic = 12)(Component
>>>> delays alone exceeds constraint)
>>>>   Clock Path Skew:  -0.245ns (1.869 - 2.114)
>>>>   Source Clock: adc0_clk rising at 0.000ns
>>>>   Destination Clock:adc0_clk rising at 5.000ns
>>>>   Clock Uncertainty:0.060ns
>>>>
>>>>   Clock Uncertainty:  0.060ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
>>>> Total System Jitter (TSJ):  0.070ns
>>>> Discrete Jitter (DJ):   0.097ns
>>>> Phase Error (PE):   0.000ns
>>>>
>>>>   Maximum Data Path at Slow Process Corner:
>>>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42/srl_delay.synth_reg_srl_inst/partial_one.last_srl17e/reg_array[27].fde_used.u2
>>>> to
>>>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm13_dda55e6716/block_z_1_0d8d8d72ce/mult1/comp1.core_instance1/blk0001/blk0006
>>>> Location Delay type Delay(ns)  Physical Resource
>>>>Logical
>>>> Resource(s)
>>>> -
>>>>  ---
>>>> SLICE_X64Y79.CQ  Tcko  0.381
>>>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(27)
>>>>
>>>>  
>>>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42/srl_delay.synth_reg_srl_inst/partial_one.last_srl17e/reg_array[27].fde_used.u2
>>>> SLICE_X65Y79.C1  net (fanout=2)0.584
>>>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(27)
>>>> SLICE_X65Y79.C   Tilo  0.068
>>>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(19)
>>>>
>>>>  

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

[Jack Hickish]

/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/addsub1/comp0.core_instance0/blk0001/blk0036

 
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/addsub1/comp0.core_instance0/blk0001/blk0030
SLICE_X63Y105.CINnet (fanout=1)0.000
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/addsub1/comp0.core_instance0/blk0001/sig007a
SLICE_X63Y105.COUT   Tbyp  0.078
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm6_9c5bc76fb5/block_t_z2_f45dc8cbb6/delay7_q_net(3)

 
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/addsub1/comp0.core_instance0/blk0001/blk002c
SLICE_X63Y106.CINnet (fanout=1)0.000
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/addsub1/comp0.core_instance0/blk0001/sig0076
SLICE_X63Y106.AMUX   Tcina 0.213
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/addsub1/comp0.core_instance0/blk0001/sig0072

 
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/addsub1/comp0.core_instance0/blk0001/blk0028
SLICE_X65Y107.A1 net (fanout=1)0.593
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/addsub1_s_net(8)
SLICE_X65Y107.COUT   Topcya0.409
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/delay7_q_net(11)

 
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/addsub2/comp1.core_instance1/blk0001/blk003c

 
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/addsub2/comp1.core_instance1/blk0001/blk0028
SLICE_X65Y108.CINnet (fanout=1)0.000
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/addsub2/comp1.core_instance1/blk0001/sig0072
SLICE_X65Y108.COUT   Tbyp  0.078
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/delay7_q_net(15)

 
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/addsub2/comp1.core_instance1/blk0001/blk0024
SLICE_X65Y109.CINnet (fanout=1)0.000
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/addsub2/comp1.core_instance1/blk0001/sig006e
SLICE_X65Y109.DMUX   Tcind 0.328
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/delay7_q_net(19)

 
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm12_2626363f3e/block_t_z2_f45dc8cbb6/addsub2/comp1.core_instance1/blk0001/blk0020
DSP48_X4Y53.A19  net (fanout=3)1.904
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/gateway_out2_x2(19)
DSP48_X4Y53.P16  Tdspdo_A_P_MULT   3.826
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm13_dda55e6716/block_z_1_0d8d8d72ce/mult1/comp1.core_instance1/blk0001/blk0005

 
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm13_dda55e6716/block_z_1_0d8d8d72ce/mult1/comp1.core_instance1/blk0001/blk0005
SLICE_X59Y109.DX net (fanout=1)1.526
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm13_dda55e6716/block_z_1_0d8d8d72ce/mult1/comp1.core_instance1/blk0001/sig00d7
SLICE_X59Y109.CLKTdick 0.034
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm13_dda55e6716/block_z_1_0d8d8d72ce/mult1_p_net(0)

 
ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm13_dda55e6716/block_z_1_0d8d8d72ce/mult1/comp1.core_instance1/blk0001/blk0006
-
 ---
Total 20.585ns (11.171ns logic,
9.414ns route)
   (54.3% logic, 45.7%
route)


On Fri, 11 Mar 2016 at 00:49 Nilan Udayanga <g...@zips.uakron.edu> wrote:

> Hi Jack,
>
> Thank you very much for your suggestions. The block t_z2 is a 2nd order
> feedback loop (figure is attached, Even though it shows 3 delays in
> multipliers, it does not have any delays).
> But I don't think this feedback loop may cause that much of delay.
>
> Regards,
> Nilan Udayanga.
>
> On Thu, Mar 10, 2016 at 7:18 PM, Jack Hickish <jac

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

[Jack Hickish]

Hi Nilan,

Yeah, I figured that would be a problem... :)
Does something like this (which i confess I haven't read, but Fig 14 looks
potentially relevent) help? --
http://www.xilinx.com/support/documentation/white_papers/wp330.pdf

Jack

On Fri, 11 Mar 2016 at 01:21 Nilan Udayanga <g...@zips.uakron.edu> wrote:

> Hi Jack,
>
> We can not add any more delays to the feedback loop multipliers and
> adders, since it changes the filter transfer function. However, we can try
> on distributing corresponding delays over adders and multipliers, without
> adding separate delays. But, I don't know whether it may change the
> critical path delay.
>
> Regards,
> Nilan Udayanga.
>
> On Thu, Mar 10, 2016 at 8:02 PM, Jack Hickish <jackhick...@gmail.com>
> wrote:
>
>> I think if you can add latency in those multipliers / adders you'll
>> probably find your problem will go away. It's the blow path that's
>> breaking, so I don;t think you can get around ijnserting some registers to
>> split up thje logic stages --
>>
>>
>> 
>> Slack:  -15.890ns (requirement - (data path - clock path
>> skew + uncertainty))
>>   Source:
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42/srl_delay.synth_reg_srl_inst/partial_one.last_srl17e/reg_array[27].fde_used.u2
>> (FF)
>>   Destination:
>>  
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm13_dda55e6716/block_z_1_0d8d8d72ce/mult1/comp1.core_instance1/blk0001/blk0006
>> (FF)
>>   Requirement:  5.000ns
>>   Data Path Delay:  20.585ns (Levels of Logic = 12)(Component delays
>> alone exceeds constraint)
>>   Clock Path Skew:  -0.245ns (1.869 - 2.114)
>>   Source Clock: adc0_clk rising at 0.000ns
>>   Destination Clock:adc0_clk rising at 5.000ns
>>   Clock Uncertainty:0.060ns
>>
>>   Clock Uncertainty:  0.060ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
>> Total System Jitter (TSJ):  0.070ns
>> Discrete Jitter (DJ):   0.097ns
>> Phase Error (PE):   0.000ns
>>
>>   Maximum Data Path at Slow Process Corner:
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42/srl_delay.synth_reg_srl_inst/partial_one.last_srl17e/reg_array[27].fde_used.u2
>> to
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/ppcm13_dda55e6716/block_z_1_0d8d8d72ce/mult1/comp1.core_instance1/blk0001/blk0006
>> Location Delay type Delay(ns)  Physical Resource
>>Logical Resource(s)
>> -  ---
>> SLICE_X64Y79.CQ  Tcko  0.381
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(27)
>>
>>  
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42/srl_delay.synth_reg_srl_inst/partial_one.last_srl17e/reg_array[27].fde_used.u2
>> SLICE_X65Y79.C1  net (fanout=2)0.584
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(27)
>> SLICE_X65Y79.C   Tilo  0.068
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(19)
>>
>>  
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8/std_conversion_generate.convert/Mmux_din[24]_GND_129_o_MUX_41_o11
>> SLICE_X62Y79.D6  net (fanout=1)0.248
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8/std_conversion_generate.convert/Mmux_din[24]_GND_129_o_MUX_41_o1
>> SLICE_X62Y79.D   Tilo  0.068
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/delay42_q_net(23)
>>
>>  
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8/std_conversion_generate.convert/Mmux_din[24]_GND_129_o_MUX_41_o13
>> SLICE_X61Y81.A6  net (fanout=26)   0.521
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8/std_conversion_generate.convert/din[24]_GND_129_o_MUX_41_o
>> SLICE_X61Y81.A   Tilo  0.068
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8_dout_net_x31(23)
>>
>>  
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_core_config/ears_sbp22_x0/convert8/std_conversion_generate.convert/Mmux_result221
>> DSP48_X3Y30.B7   net (fanout=16)   1.178
>> ears_sbp22_XSG_core_config/ears_sbp22_XSG_

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

[Jack Hickish]

t;>
>>>
>>> *Vishwa Seneviratne*
>>>
>>> *Graduate Student*
>>>
>>> *Dept. of Electrical and Computer Engineering*
>>> *University of Akron*
>>>
>>> On Wed, Feb 3, 2016 at 11:02 AM, Vishwa Seneviratne <
>>> mp...@zips.uakron.edu> wrote:
>>>
>>>> Hi Jack,
>>>>
>>>> I did try all the combinations. The error remains the same.
>>>>
>>>> $ adc16_init.rb -v --demux=1 192.168.10.5 poly_design.bof
>>>> /var/lib/gems/1.9.1/gems/adc16-0.3.6/bin/adc16_init.rb:40:in `>>> (required)>': invalid option: --demux=2 (OptionParser::InvalidOption)
>>>> from /usr/local/bin/adc16_init.rb:19:in `load'
>>>> from /usr/local/bin/adc16_init.rb:19:in `'
>>>>
>>>>
>>>> Sincerely,
>>>>
>>>>
>>>> *Vishwa Seneviratne*
>>>>
>>>> *Graduate Student*
>>>>
>>>> *Dept. of Electrical and Computer Engineering*
>>>> *University of Akron*
>>>>
>>>> On Wed, Feb 3, 2016 at 2:25 AM, Jack Hickish <jackhick...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Vishwa,
>>>>>
>>>>> Is the syntax definitely -demux=1 andnot either --demux=1 or -d 1 ?
>>>>>
>>>>>
>>>>> Jack
>>>>>
>>>>> On Wed, 3 Feb 2016, 12:39 a.m. Vishwa Seneviratne <
>>>>> mp...@zips.uakron.edu> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am working on how to work with different operating of
>>>>>> the 'ADC16x250-8 coax rev 2' for a very simple design to test how the ADC
>>>>>> works. The design is compiled at an IP clock rate setting of 200MHz. My
>>>>>> objective is to sample my input signal at higher sampling rate 
>>>>>> (preferably
>>>>>> 400, 800 MHz).
>>>>>>
>>>>>> According to the user guide ''
>>>>>> https://casper.berkeley.edu/wiki/images/4/4c/ADC16_user_guide.txt;
>>>>>> by setting the demux parameter I should be able to switch between 
>>>>>> different
>>>>>> sampling rates. I get the following error.
>>>>>>
>>>>>> $ adc16_init.rb -v -demux=1 192.168.10.5 poly_design.bof
>>>>>> /var/lib/gems/1.9.1/gems/adc16-0.3.6/bin/adc16_init.rb:40:in `>>>>> (required)>': invalid option: -demux=2 (OptionParser::InvalidOption)
>>>>>> from /usr/local/bin/adc16_init.rb:19:in `load'
>>>>>> from /usr/local/bin/adc16_init.rb:19:in `'
>>>>>>
>>>>>> When I don't pass the 'demux' parameter the ADC board get initialized
>>>>>> to 8 analog inputs by default.
>>>>>>
>>>>>> How do I resolve this issue? or how can I set the ADC's to operate at
>>>>>> different sampling rates?
>>>>>>
>>>>>> Thank you in advance
>>>>>>
>>>>>> Sincerely,
>>>>>>
>>>>>>
>>>>>> *Vishwa Seneviratne*
>>>>>>
>>>>>> *Graduate Student*
>>>>>>
>>>>>> *Dept. of Electrical and Computer Engineering*
>>>>>> *University of Akron*
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>

Re: [casper] Working with demux modes of 'ADC16x250-8 coax rev 2'

[Jack Hickish]

Hi Nilan,

You'd need to look at the interface firmware to see exactly how the clock
is generated on the FPGA, but essentially, yes, the 240 mhz clock is
derived by dividing down the clock the ADC chip passes to the FPGA (which
may or may not be equal to the sampling rate, depending on the exact setup).

On roach 2, there's all kinds of irritating constraints on the way that
clocks can be multiplied up and divided down, which lead to the limitations
described here -
https://casper.berkeley.edu/wiki/ADC16x250-8#ADC16_Sample_Rate_vs_Virtex-6_MMCM_Limitations
So you won't hit a "maximum" frequency issue as such, but there are only
certain windows of sample rates which work.

Hope that helps
J

On Wed, 9 Mar 2016, 13:03 Nilan Udayanga, <g...@zips.uakron.edu> wrote:

> Hi All,
>
> Thank you very much for all your suggestions.
>
> I have two more questions,
>
> Since, ADCs need to be clocked at 480 MHz for the demux=2 mode, how does
> the FPGA clock at 240 MHz? does it use a clock divider internally?
>
> Is there any maximum operating frequency for the FPGA, when we use the
> adc16 block?
>
> Regards,
> Nilan Udayanga.
>
> On Wed, Mar 9, 2016 at 3:22 PM, Jack Hickish <jackhick...@gmail.com>
> wrote:
>
>> With regards to the demux option, for the system you describe you want -d
>> 2 (I.e. demux by = run the FPGA at half the sample rate, and process two
>> samples in parallel on every FPGA clock cycle). Basically, provided you
>> have the up to date ruby package, all you need to do is run adc16_init.rb
>> with appropriate options, and that will program your roach and set
>> everything up for you.
>>
>> I think the default mode of the adc16 ruby script assumes that, whatever
>> mode you're using the ADC in, the external clock provided is at the sample
>> rate. Though, as Matt added, the ADC supports other dividing options if
>> they're useful to you and you're willing to read the ADC data sheet to work
>> out how to set the divider properties.
>>
>> Cheers
>> Jack
>>
>>
>> On Wed, 9 Mar 2016, 09:49 David MacMahon, <dav...@astro.berkeley.edu>
>> wrote:
>>
>>> Hi Vishwa,
>>>
>>> I am not at my computer right now, so this is from memory, but I think
>>> you want to specify an IP clock rate of 240 MHz and supply a 480 MHz clock
>>> to the ADC card(s). The IP clock rate is sometimes called the fabric clock
>>> rate. It is the rate at which the FPGA logic elements (aka fabric) operate.
>>> The ADC chips need a sample clock that is commensurate with the sampling
>>> frequency. When you initialize the ADCs using adc16_init.rb, be sure to
>>> pass the "-d" option. If your version of adc16_init.rb does not support the
>>> "-d" option, then you will need to update it.
>>>
>>> Hope this helps,
>>> Dave
>>>
>>> On Mar 9, 2016, at 08:33, Vishwa Seneviratne <mp...@zips.uakron.edu>
>>> wrote:
>>>
>>> Hi David/Jack,
>>>
>>> We are working on a beam former and we use the 'ADC16x250-8 coax rev 2'
>>> to sample RF signals using ROACH2-Rev 2. The operating BW is 240MHz. Thus,
>>> we need to sample the signals at 480 MSamples/s. We have few queries
>>> regarding the adc16 yellow block and how to setup the input clock.
>>>
>>> 1. Can we compile a design by setting the IP clock rate to 480MHz?
>>> 2. Should we supply a IP clock frequency of 480MHz to the ADC board to
>>> achieve a sampling rate of 480MSamples/s.  If not, at what clock rate
>>> should we supply? And what other parameters needed to setup when running
>>> the bof file.
>>>
>>> Thank you
>>>
>>>
>>> Sincerely,
>>>
>>>
>>> *Vishwa Seneviratne*
>>>
>>> *Graduate Student*
>>>
>>> *Dept. of Electrical and Computer Engineering*
>>> *University of Akron*
>>>
>>> On Wed, Feb 3, 2016 at 12:38 PM, David MacMahon <
>>> dav...@astro.berkeley.edu> wrote:
>>>
>>>> Hi, Vishwa,
>>>>
>>>> The software installed by following the ADC16 user guide had not been
>>>> updated with the newer version of the adc16 code that supports demux mode.
>>>> I have updated the software that the user guide points to, so if you
>>>> reinstall the adc16 gem as per the user guide you should get version 0.4.0
>>>> which supports demux mode.
>>>>
>>>> Thanks for bringing this issue to my attention.
>>>>
>>>> Dave
>>>>
>>

Re: [casper] Roach1!

[Jack Hickish]

Hi Rolando, CASPER,

The ROACH should still be supported by all the CASPER tutorials which are
on the wiki -- https://casper.berkeley.edu/wiki/Tutorials

Cheers,
Jack

On Wed, 6 Apr 2016 at 16:48 Rolando Paz  wrote:

> Hi Jack
>
> The next Friday I will travel to Mexico to pick up one ROACH1!
> I was given the opportunity to program it!
> How you advise me to start learning to program a ROACH?
>
> Best Regards
>
> Rolando Paz
>

Re: [casper] Roach1!

[Jack Hickish]

Hi Rolando,

That guide should still be up to date and working.

Jack

On Wed, 6 Apr 2016 at 22:35 Rolando Paz <flx...@gmail.com> wrote:

> Thanks Jack.
>
> So, Can I follow this guide?
>
> https://casper.berkeley.edu/wiki/ROACH_NFS_guide
>
> Regards
>
> Rolando
>
>
> 2016-04-06 23:07 GMT-06:00 Jack Hickish <jackhick...@gmail.com>:
>
>> Hi Rolando, CASPER,
>>
>> The ROACH should still be supported by all the CASPER tutorials which are
>> on the wiki -- https://casper.berkeley.edu/wiki/Tutorials
>>
>> Cheers,
>> Jack
>>
>>
>> On Wed, 6 Apr 2016 at 16:48 Rolando Paz <flx...@gmail.com> wrote:
>>
>>> Hi Jack
>>>
>>> The next Friday I will travel to Mexico to pick up one ROACH1!
>>> I was given the opportunity to program it!
>>> How you advise me to start learning to program a ROACH?
>>>
>>> Best Regards
>>>
>>> Rolando Paz
>>>
>>
>

Re: [casper] Roach1!

[Jack Hickish]

On Sat, 9 Apr 2016 at 20:01 Rolando Paz <flx...@gmail.com> wrote:

> Hi Jack
>
> Today I had the opportunity to starting 3 ROACHs1, thanks to Dr. Stan from
> IRYA.
>
> Some doubts:
>
> a) When we starting two of the three Roachs1, we used minicom to
> communicate with them. Two of the roachs goes directly to "roach_login"
> where we put "root" and then we enter into an operating system.
>
> Does this means that the most recent versions of the Roach1, is no longer
> necessary to make this guide
> https://casper.berkeley.edu/wiki/ROACH_NFS_guide?
>

I think the ROACH used to ship with SD card file systems, so you're
probably booting off one of those. It was never necessary to set up NFS
unless you wanted them to boot from a remote file system. The main
advantage of this is it makes it much easier to manage systems with many
ROACH board.



>
> b) The third roach has password, and could not find it is. How we can
> change the user and password?
>
>
The most straightforward way is probably to just copy the SD card image
from one of your working ROACH boards, or from the svn links you found.



> Best Regards
>
> Rolando Paz
>
> 2016-04-09 19:30 GMT-06:00 Jack Hickish <jackhick...@gmail.com>:
>
>> Hi Rolando,
>>
>>
>> I don't actually know what the right answer is, but if it were me I'd go
>> for one of --
>>
>> filesystem_etch_2010-03-24_sd_shipping.tar.gz
>> <https://casper.berkeley.edu/svn/trunk/roach/sw/binaries/filesystem/filesystem_etch_2010-03-24_sd_shipping.tar.gz>
>> filesystem_etch_nfs.tar.gz
>> <https://casper.berkeley.edu/svn/trunk/roach/sw/binaries/filesystem/filesystem_etch_nfs.tar.gz>
>>
>> and whichever kernel looks newest --
>> uImage-20110812-mmcomitfix
>> <https://casper.berkeley.edu/svn/trunk/roach/sw/binaries/linux/uImage-20110812-mmcomitfix>
>> ?
>>
>> Good luck,
>>
>> Jack
>>
>> On Wed, 6 Apr 2016 at 22:43 Rolando Paz <flx...@gmail.com> wrote:
>>
>>> Regarding the kernel and filesystem, which you advise me to use?
>>>
>>> The kernel
>>> https://casper.berkeley.edu/svn/trunk/roach/sw/binaries/linux/
>>>
>>> The filesystem
>>> https://casper.berkeley.edu/svn/trunk/roach/sw/binaries/filesystem/
>>>
>>> Regards
>>>
>>> Rolando
>>>
>>> 2016-04-06 23:37 GMT-06:00 Jack Hickish <jackhick...@gmail.com>:
>>>
>>>> Hi Rolando,
>>>>
>>>> That guide should still be up to date and working.
>>>>
>>>> Jack
>>>>
>>>> On Wed, 6 Apr 2016 at 22:35 Rolando Paz <flx...@gmail.com> wrote:
>>>>
>>>>> Thanks Jack.
>>>>>
>>>>> So, Can I follow this guide?
>>>>>
>>>>> https://casper.berkeley.edu/wiki/ROACH_NFS_guide
>>>>>
>>>>> Regards
>>>>>
>>>>> Rolando
>>>>>
>>>>>
>>>>> 2016-04-06 23:07 GMT-06:00 Jack Hickish <jackhick...@gmail.com>:
>>>>>
>>>>>> Hi Rolando, CASPER,
>>>>>>
>>>>>> The ROACH should still be supported by all the CASPER tutorials which
>>>>>> are on the wiki -- https://casper.berkeley.edu/wiki/Tutorials
>>>>>>
>>>>>> Cheers,
>>>>>> Jack
>>>>>>
>>>>>>
>>>>>> On Wed, 6 Apr 2016 at 16:48 Rolando Paz <flx...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Jack
>>>>>>>
>>>>>>> The next Friday I will travel to Mexico to pick up one ROACH1!
>>>>>>> I was given the opportunity to program it!
>>>>>>> How you advise me to start learning to program a ROACH?
>>>>>>>
>>>>>>> Best Regards
>>>>>>>
>>>>>>> Rolando Paz
>>>>>>>
>>>>>>
>>>>>
>>>
>

Re: [casper] yellow block for 2Gsps adc/dac

[Jack Hickish]

Hi Matt,

The usual way to deal with this is IODELAY blocks as you suggest. The adc5g
core has an example of the correct instantiation of the IODELAY primitive
and some controller code to talk to them. IIRC, the delay goes straight
after the input buffer, prior to the SERDES (or presumably immediately
before the output buffers for the DAC).

Cheers
Jack


On Tue, 26 Apr 2016 at 16:02 Matt Strader  wrote:

> Hello again,
>
> Now that my clocks are working, I've run into the next problem in my
> yellow block.  I have the adc/dac board sending a ramp, which I see on the
> roach2 side, but there are periodic glitches (see attached).  ​
>  zdok_ctr_ramp2.tiff
> 
>
> The data is coming over four 14-bit buses aligned to a 500 MHz clock from
> the adc/dac board, at DDR.  The glitches happen when the value coming
> through is a round number in binary, i.e. whenever several bits flip at
> once.  It seems that at each glitch, one or more bits fail to flip when
> they should, though they usually arrive at the right value one cycle later.
>
> I saw in the mailing list archive that people have had problems
> 
> with glitches when using MMCMs in LOW bandwidth mode.  I've tried both LOW
> and HIGH modes and see the same thing.  (For the HIGH mode I slowed my
> clock from 500 MHz to 350 MHz.  To use exactly 500 MHz as I want, I'm stuck
> with LOW mode.)
>
> I'm guessing that IODELAYs are the solution to this?  Do I put the delays
> at the inputs of my OSERDESs?  Any recommendations?
>
> Thanks,
> Matt​
>
> On Wed, Apr 20, 2016 at 6:47 PM, Matt Strader 
> wrote:
>
>> I found my mistake.  I did not have feedback input and output ports of
>> the mmcm (CLKFBOUT,CLKFBIN) connected correctly.
>>
>> Matt
>>
>> On Tue, Apr 19, 2016 at 12:10 PM, Matt Strader > > wrote:
>>
>>> Hello Casperites,
>>>
>>> I am working on a roach2 yellow block for a new 12bit,  2.0 Gsps ADC/DAC
>>> board designed at Fermilab.  I am having trouble with clocks.  The ADC/DAC
>>> board is providing me with a 500 MHz clock over a particular zdok pair.  My
>>> yellow block takes this into an mmcm and divides it down to 250 MHz to be
>>> used as the fabric clock.
>>>
>>> When testing it, I set the adc/dac clock running, then program the
>>> roach2.  When I call KatcpFpga.estimate_fpga_clock() it returns 167 MHz
>>> instead of the expected 250 MHz.
>>>
>>> I have attached what I think are the relevant snippets from my yellow
>>> block.  The rest of it can be found at
>>> https://github.com/mstrader/mlib_devel
>>> Any ideas what could be the problem?
>>>
>>> Thanks,
>>> Matt Strader
>>>
>>
>>
>

[casper] Valon Synth python interface

[Jack Hickish]

Howdy all,

I'm trying to program a Valon 5008 synth with the ValonSynth nrao python
API -- https://github.com/nrao/ValonSynth (master branch) -- running on a
raspberry pi 3.

Does anyone know if this code actually works with a 5008 -- it's advertised
for a 5007 and I get some fun results when I attempt to use it --

In [62]: import valon_synth
In [63]: v = valon_synth.Synthesizer('/dev/ttyUSB0')
In [64]: v.get_phase_lock(valon_synth.SYNTH_A)
Out[64]: True
In [65]: v.set_frequency(valon_synth.SYNTH_A, 1000.0)
Out[65]: True
In [66]: v.get_frequency(valon_synth.SYNTH_A)
Out[66]: 0.057605