Re: [casper] Spectrum woes

[Andrew Vdb]

Hi all,

We (SKA-SA) saw similar behaviour with our PFB and found it was a
combination of things - one being to *not* select BRAM optimisations, and
another was a bug in the coefficient use in the PFB. Give the
ska-sa/mlib_deve l repo a spin - we
pushed our fixes a few months back.

Andrew

On Mon, Sep 19, 2016 at 1:00 AM, Jack Hickish  wrote:

> Hi Michael,
>
> Hmmm. Can you link the repo you're using and a reference design?
>
> Thanks
> Jack
>
> On Sun, 18 Sep 2016 at 15:05 Michael D'Cruze  manchester.ac.uk> wrote:
>
>> Hi Jack,
>>
>>
>>
>> To implement the change in optimisation I altered the delay_bram init
>> script. Line 84 which configures the Xilinx ram block, I changed the
>> parameter ‘optimize’ from ‘Area’ to ‘Speed’. No other changes were made,
>> so, I think this is the former case?
>>
>> BW
>> Michael
>>
>>
>>
>> *From:* Jack Hickish [mailto:jackhick...@gmail.com]
>> *Sent:* 18 September 2016 22:27
>> *To:* Michael D'Cruze; casper@lists.berkeley.edu
>> *Subject:* Re: [casper] Spectrum woes
>>
>>
>>
>> Hi Michael,
>>
>>
>>
>> Is this actually the optimisation parameter of the xilinx bram block, or
>> an optimisation of a casper block which completely changes some underlying
>> circuit (eg by doing a bunch of fanout control and instantiating multiple
>> small brams instead of one big one)?
>>
>> If the latter, are you sure it's not a bug in the casper implementation?
>> Perhaps a mismatch of latency on various things being fanned out?
>>
>>
>>
>> Trust nothing.
>>
>>
>>
>> Jack
>>
>>
>>
>> On Sun, 18 Sep 2016 at 14:21 Michael D'Cruze > manchester.ac.uk> wrote:
>>
>> Dear all,
>>
>>
>>
>> I’ve been chasing the cause of some nasty artefacts in my spectra
>> recently. The first turned out to be a known bug in the Xilinx compiler,
>> activated when the BRAM_sharing optimisation in the FFT is checked, however
>> the artefacts I’m seeing since seem to be activated by the RAM blocks in
>> the delay_bram block being configured for “Speed”, and not the default
>> “Area”.
>>
>>
>>
>> Below are links to two spectra. They were both recorded from the Lovell
>> telescope’s L-band receiver while the telescope was pointing at the zenith.
>> The logic used in both cases is identical, with the exception that the
>> delay_brams in the first spectra are configured for Speed, and in the
>> second they are configured for Area (default). All operating parameters
>> were the same in both cases.
>>
>>
>>
>> https://dl.dropboxusercontent.com/u/38103354/figure_1.png
>>
>> https://dl.dropboxusercontent.com/u/38103354/r13a_libs_18-09_2207.PNG
>>
>>
>>
>> Aside from how ugly the first spectrum looks (there are signals in there
>> which simply don’t exist), even the accumulated power is different. The
>> vertical scale is logarithmic so this is a factor 100 or so higher with the
>> brams configured for Speed. I don’t understand how they could be so
>> different, nor why configuring the brams for Speed should make any
>> difference at all, not least a difference of this magnitude.
>>
>>
>>
>> The most worrying thing for me now is that configuring the brams for
>> Speed was key to getting my larger designs (16k and 32k channels) to meet
>> timing. If I need to reconfig for Area, I’m going to have to brawl with Par
>> and PlanAhead all over again… It actually took a few goes to get just that
>> 4k channel design to compile.
>>
>>
>>
>> I’d appreciate ideas/suggestions!
>>
>> Thanks
>>
>> Michael
>>
>>
>>
>>
>>
>>


-- 
Dr Andrew van der Byl

Mobile: +27 83 312 7392
Email: a vd...@gmail.com

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

[Andrew Vdb]

Hi all,

For those interested in White Rabbit, Xilinx have an article in their Xcell
journal (91). The link is here
.

regards,
Andrew

On Thu, May 7, 2015 at 1:45 AM,  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 
> Subject: Re: [casper] Timing distribution over fiber
> To: Johan Burger , Michael Inggs
> ,Bob Stricklin , Sias
> Malan
> ,   Renier Siebrits ,
> Francois Kapp
> ,   Etienne Bauermeister 
> Cc: Simon Lewis , Casper Lists
> ,Thomas Abbott ,
> Stephan Sandenberg 
> Message-ID:
>  gj_rd7qgtngc2z_07abtx7nwjhojw...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, 6 May 2015 at 07:35 Johan Burger  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
> > seperate fibres for PPS and RF, to further limit self-RFI and as it was
> > found that requirements could only be met in this way.
> >
>
> This is a good point, and something we'll make sure to keep in mind...
>
> Thanks again,
> Jack
>
>
>
> >

[casper] Announcement of the workshop 'High-performance Signal and Data Processing 2014'

[Andrew Vdb]

Dear Colleagues



We are very happy to announce the workshop High-performance Signal and Data
Processing 2014. The workshop aims to bring together key people to discuss
grand challenges facing the signal processing community in Radio Astronomy,
Gamma Ray Astronomy and Particle Physics, and to provide knowledge
sharing to delegates in both a lecture format, as well as a classroom
environment for hands-on hardware and software training. General overviews
and in-depth presentations will be given.



The event will take place at the Wits Professional Development HUB at the
University of the Witwatersrand, the week of January 27th to January 31st 2014.
We are honored to have the following keynote speakers at the event:



Dr. Daniel Adams, Chief Director: Emerging Research Areas and
Infrastructure at the DST

Prof. Jean Cleymans, Chairman of SA-CERN

Dr. Bernard Fanaroff, SKA Project Director

Dr. Peter Jenni, former Spokesperson of the ATLAS experiment at CERN

Prof. Justin Jonas, MeerKAT Associate Director of Science and Engineering

Prof. Naba Mondal, Spokesperson of the India-based Neutrino Observatory



Keynote addresses will be followed by plenary sessions for in-depth
presentations by experts in areas of physics and engineering. Students and
young researches are also welcome to deliver presentations. Several
hands-on sessions with FPGA-based boards, RHINO and ROACH, will be
provided. A session on GRID software is also envisioned.



The registration and abstract submission are now open till December 31st 2013.
It is envisioned to publish a book of proceedings. There are funding
opportunities for students outside Johannesburg. Visit the workshop’s
website for more information:



http://www.hpspsa.com



Looking forward to your participation



Best regards,



The organising committee



Dr. Oana Boeriu

Dr. Andrew van der Byl

Prof. Sergio Colafrancesco

Prof. David Davidson

Dr. Andreas Faltenbacher

Dr. Siegie Fortsch

Prof. Michael Inggs (Co-Chair)

Mr. Francois Kapp

Dr. Jonathan Keartland

Prof. Bruce Mellado (Co-Chair)

Prof. Elias Sideras-Haddad

Dr. Trevor Vickey

Dr. Simon Windberg

[casper] Signal Processing Workshop: Live Streaming

[Andrew Vdb]

Hi All,

Just an update - we are experiencing some technical issues with the live
stream. It should come back online shortly.


Regards
Andrew

[casper] Signal Processing Workshop

[Andrew Vdb]

Hi everyone,

This is just to inform that the signal processing workshop taking place in
Cape Town at the University of Cape Town (28th to 31st January) will be
streamed online each day. Please visit  (
https://sites.google.com/site/hpdspworkshopcpt2012/) and use the link
provided to log in and view. A programme is also available online so you
can see what talks will be given and the associated time slot. All times
shown are relative to South Africa (GMT+2).

Regards,
Andrew

[casper] Signal Processing Workshop

[Andrew Vdb]

Hello All,

Thanks Jason for advertising the workshop. I see the attachment was removed
(well for myself at least). For those interested, here is the online link (
https://sites.google.com/site/hpdspworkshopcpt2012/)

Andrew