Re: [casper] Ultrascale+HBM DSP48's + CASPER FFT

[Jonathon Kocz]

Thanks Adam. Good to know it wasn't just me!

As an update: I installed Vivado 2020.1 this afternoon. Running with matlab
2019a it does seem they fixed the issue, and it compiles without error.

Caveat: I've only tested with simple counters. I haven't yet looked to see
what in the toolflow might need updating before it is fully compatible with
vivado 2020.

Cheers,
Jonathon

On Fri, 28 Aug 2020 at 03:55, Adam Isaacson  wrote:

> Hi Jonathon,
>
> We have the same issue for our 1K channeliser using the Alveo U280 boards
> - see screen capture. To fix this we changed the Simulink counters not to
> use DSP - not very practical, but at least we got the compile through. I
> have looked at the DSP architecture for the Virtex UltraScale+ with HBM and
> it definitely has the DSP architecture. We used Matlab R2018a and Vivado
> 2019.1.1 and Vivado 2019.2 - they all had this issue. I believe it to be a
> Simulink/sysgen bug. I never got around to logging a support request with
> Xilinx yet, as we were focusing on the Alveo U280 100GbE testing. We
> haven't looked into this much more yet.
>
> This is from Andrew van der Byl: "The - a snag.There seems to be an
> issue when counters are set to use DSP logic. Jasper_frontend fails (see
> attached pic) if a counter is set to use DSP (it's fine when Fabric or
> behavioural is selected). You can regenerate the issue by changing any of
> the counters in the base design to use DSP. The DSP slices used in the
> PFB are fine though. I did have to change all counters in the design that
> by default are set to use DSP slices or the build would fail. Thought I'd
> give you the heads up. I'll start to work in the rest of the logic and
> build in some test logic as well".
>
> Kind regards,
>
> Adam Isaacson
> South African Radio Astronomy Observatory (SARAO)
> Hardware Manager
> Cell: (+27) 825639602
> Tel:  (+27) 215067300
> email: aisaac...@ska.ac.za
>
>
>
> On Fri, Aug 28, 2020 at 2:31 AM Jonathon Kocz  wrote:
>
>> Hi CASPER,
>>
>> I was wondering if anyone had encountered difficulties in compiling
>> larger CASPER FFTs for Ultrascale+ HBM devices?
>>
>> I have found I can compile the CASPER FFTs fine for Ultrascale+ devices,
>> but HBM devices seem to object ("Cannot target DSP48 on this device,
>> virtexuplusHBM").
>>
>> As far as I know DSP48E2 should be backward compatible with DSP48E1 (and
>> certainly as other Ultrascale+ devices will compile, this seems to be true).
>>
>> The only thing I've been able to find specifically relating to HBM
>> devices is that the number you can cascade may be different due to the
>> difference in SLRs with the HBM interface (UG579).
>>
>> Is this just Simulink needing an update (I've tried Vivado 2019.1.1 and
>> 2019.2, both with Matlab 2019a), do we finally need to explicitly change
>> the DSP48's in the toolflow to be E2 for devices like this, or is there
>> something more fundamental I'm missing?
>>
>> Thanks,
>> Jonathon
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To view this discussion on the web visit
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAPU71P8xjbD%2BwSSWPRK-qYVOVt-umBxmLQiYWmAAncyrgobF1A%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnGLVoRD13PsFPHaUay3etcgMev8MfFs6MDijeTDgvrRfw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAPU71P_hO0PX3wdSj6AC2J3nXwP5zcdmpgfWuafhSA47_h-RGg%40mail.gmail.com.

Re: [casper] PFB (taps): Effects on time resolution

[Ross Martin]

Hi Colm,

I realized that I forgot to mention that time resolution and response
duration aren't exactly the same thing.

When you switch from an FFT to a PFB with an equivalent number of channels,
the PFB filter has a length equal to N FFTs.  So your time response length
becomes longer by a factor of N.  However, the PFB output still has a
definite and distinct peak that hasn't really changed in width from the
original FFT case.

So for many ways of measuring time resolution, switching from FFT to PFB
doesn't change time resolution much, even though it does extend the time
length of the response.

Regards,

Ross

r...@bitbybitsp.com


On Fri, Aug 28, 2020, 7:58 AM Ross Martin  wrote:

> Hi Colm,
>
> Events with narrow time resolution will have larger bandwidth, which means
> that energy from them will appear in multiple PFB output channels.
>
> If you retain only a single PFB output channel, then you have lost time
> resolution exactly as described by previous answers.
>
> However, PFBs, when done correctly, are invertible. If you retain *all*
> PFB channels, you can reconstruct the entire original time series (with
> some controllable processing noise).  Since you can reconstruct all your
> original data, you've lost nothing at all regarding time resolution (or
> anything else).  Fine time resolution can be hard to see in this form, but
> all the data is there to extract it.
>
> It's also possible to invert part of a PFB.  For example, if an event has
> energy primarily in three adjacent channels, you can keep just those three
> channels and invert just the three channels.  This effectively gives you a
> bandpass filter with three times the channel bandwidth, and three times
> finer time resolution than the time resolution of a single channel.
>
> Regarding your second question of whether amplitude of an off-center sine
> wave varies.  It essentially does not.  A PFB, when properly constructed,
> is exactly equivalent to a complex mixer, followed by a lowpass filter,
> followed by a downsampler.  (Presentation on my web site.).  For an
> off-center sine wave these steps will give as a primary output signal a
> complex sine wave whose amplitude is constant but phase varies.  There will
> also be secondary aliased output components, that do distort the amplitude
> measurement a little.  However, these components will certainly be in the
> stopband of the filter, and with even weak PFB filters be at least 60dB
> down.  If that's too much amplitude measurement variation, you can get
> stronger PFB filters -- but these will give you lower time resolution in a
> single output channel.
>
> Regards,
>
> Ross
>
> r...@bitbybitsp.com
>
>
>
>
> On Fri, Aug 28, 2020, 3:40 AM Colm Bracken  wrote:
>
>> Hi James,
>>
>> Perfect, thanks so much.
>> It is good to have clarity on these matters.
>>
>> Best wishes,
>> Colm
>>
>> On Fri, 28 Aug 2020 at 12:23, James Smith  wrote:
>>
>>> Hello Colm,
>>>
>>> Yes, you're correct. That's how some of our narrowband designs work -
>>> you use each PFB channel as a very narrow bandpass filter, and treat its
>>> output as a complex time-series. So you can pass it through another PFB to
>>> get a higher-resolution spectrum, at the expense of very much lower time
>>> resolution of course.
>>>
>>> Regards,
>>> James
>>>
>>>
>>> On Fri, Aug 28, 2020 at 11:04 AM Colm Bracken 
>>> wrote:
>>>
 Hi Cedric,

 Great, thanks for confirming that.
 One more question, if you don't mind?

 If a narrow band signal is off-centre relative to one of my frequency
 bins, will the measured amplitude change each time I run the FFT?
 For example, if my FFT frequency bins are exactly 1 MHz wide (1024 pt
 FFT applied to 1 GSPS ADC data), and I am trying to measure a sinusoid with
 a frequency of 5.1 MHz, will the measured amplitude oscillate at a
 frequency of 0.1 MHz (5.1 MHz - 5 MHz)? Basically, my sampling (in terms of
 how often I sample the full time stream for the FFT) is out of phase with
 the signal to be measured?

 I probably didn't explain that very well, apologies.

 Best wishes,
 Colm

 On Fri, 28 Aug 2020 at 11:17, 'Cedric Viou' via
 casper@lists.berkeley.edu  wrote:

> Hi Colm,
>
> You are right.
>
> PFB is a great way to reduce frequency smearing but the down-side is
> time smearing.
>
> A brief event will be convolved with at least one of your PFB 8-tap
> filters that end up feeding several FFT computations in a row.
> So, you get time smearing for that short event...
>
> Regards,
>
> Cedric
>
>
> Le 28/08/2020 à 11:56, Colm Bracken a écrit :
> > Hi All,
> >
> > I have a question, which is probably DSP 101 basics, but I just
> wasn't 100% sure.
> >
> > If I am applying a 1024 point FFT to a continuous time-stream from
> an ADC with sampling ~ 1 GSPS, I will have a time resolution ~ 1
> microsecond (and 

Re: [casper] PFB (taps): Effects on time resolution

[Ross Martin]

Hi Colm,

Events with narrow time resolution will have larger bandwidth, which means
that energy from them will appear in multiple PFB output channels.

If you retain only a single PFB output channel, then you have lost time
resolution exactly as described by previous answers.

However, PFBs, when done correctly, are invertible. If you retain *all* PFB
channels, you can reconstruct the entire original time series (with some
controllable processing noise).  Since you can reconstruct all your
original data, you've lost nothing at all regarding time resolution (or
anything else).  Fine time resolution can be hard to see in this form, but
all the data is there to extract it.

It's also possible to invert part of a PFB.  For example, if an event has
energy primarily in three adjacent channels, you can keep just those three
channels and invert just the three channels.  This effectively gives you a
bandpass filter with three times the channel bandwidth, and three times
finer time resolution than the time resolution of a single channel.

Regarding your second question of whether amplitude of an off-center sine
wave varies.  It essentially does not.  A PFB, when properly constructed,
is exactly equivalent to a complex mixer, followed by a lowpass filter,
followed by a downsampler.  (Presentation on my web site.).  For an
off-center sine wave these steps will give as a primary output signal a
complex sine wave whose amplitude is constant but phase varies.  There will
also be secondary aliased output components, that do distort the amplitude
measurement a little.  However, these components will certainly be in the
stopband of the filter, and with even weak PFB filters be at least 60dB
down.  If that's too much amplitude measurement variation, you can get
stronger PFB filters -- but these will give you lower time resolution in a
single output channel.

Regards,

Ross

r...@bitbybitsp.com




On Fri, Aug 28, 2020, 3:40 AM Colm Bracken  wrote:

> Hi James,
>
> Perfect, thanks so much.
> It is good to have clarity on these matters.
>
> Best wishes,
> Colm
>
> On Fri, 28 Aug 2020 at 12:23, James Smith  wrote:
>
>> Hello Colm,
>>
>> Yes, you're correct. That's how some of our narrowband designs work - you
>> use each PFB channel as a very narrow bandpass filter, and treat its output
>> as a complex time-series. So you can pass it through another PFB to get a
>> higher-resolution spectrum, at the expense of very much lower time
>> resolution of course.
>>
>> Regards,
>> James
>>
>>
>> On Fri, Aug 28, 2020 at 11:04 AM Colm Bracken 
>> wrote:
>>
>>> Hi Cedric,
>>>
>>> Great, thanks for confirming that.
>>> One more question, if you don't mind?
>>>
>>> If a narrow band signal is off-centre relative to one of my frequency
>>> bins, will the measured amplitude change each time I run the FFT?
>>> For example, if my FFT frequency bins are exactly 1 MHz wide (1024 pt
>>> FFT applied to 1 GSPS ADC data), and I am trying to measure a sinusoid with
>>> a frequency of 5.1 MHz, will the measured amplitude oscillate at a
>>> frequency of 0.1 MHz (5.1 MHz - 5 MHz)? Basically, my sampling (in terms of
>>> how often I sample the full time stream for the FFT) is out of phase with
>>> the signal to be measured?
>>>
>>> I probably didn't explain that very well, apologies.
>>>
>>> Best wishes,
>>> Colm
>>>
>>> On Fri, 28 Aug 2020 at 11:17, 'Cedric Viou' via
>>> casper@lists.berkeley.edu  wrote:
>>>
 Hi Colm,

 You are right.

 PFB is a great way to reduce frequency smearing but the down-side is
 time smearing.

 A brief event will be convolved with at least one of your PFB 8-tap
 filters that end up feeding several FFT computations in a row.
 So, you get time smearing for that short event...

 Regards,

 Cedric


 Le 28/08/2020 à 11:56, Colm Bracken a écrit :
 > Hi All,
 >
 > I have a question, which is probably DSP 101 basics, but I just
 wasn't 100% sure.
 >
 > If I am applying a 1024 point FFT to a continuous time-stream from an
 ADC with sampling ~ 1 GSPS, I will have a time resolution ~ 1 microsecond
 (and frequency res. of ~ 1 MHz).
 >
 > But, if I instead apply an 8 tap PFB, am I essentially smearing out
 my time resolution by a factor of 8, since I am now summing 8 rows of my
 1024 point time streams?
 > I can't see how the number of PFB taps wouldn't affect my time
 resolution. Or am I missing something?
 >
 > Thanks in advance,
 > Colm
 >
 > --
 >
 > *Dr Colm Bracken*
 > Lecturer
 > Maynooth University Experimental Physics
 >
 >
 > Maynooth University, Maynooth, Co. Kildare, Ireland.
 >
 > T: +353 1 708 3641
 > E: colm.brac...@mu.ie  W:
 www.maynoothuniversity.ie 
 >
 > Follow my work on https://nuim.academia.edu/ColmBracken
 >
 >
 >
 > And
 >
 >
 > 

Re: [casper] PFB (taps): Effects on time resolution

[Colm Bracken]

 Hi James,

Perfect, thanks so much.
It is good to have clarity on these matters.

Best wishes,
Colm

On Fri, 28 Aug 2020 at 12:23, James Smith  wrote:

> Hello Colm,
>
> Yes, you're correct. That's how some of our narrowband designs work - you
> use each PFB channel as a very narrow bandpass filter, and treat its output
> as a complex time-series. So you can pass it through another PFB to get a
> higher-resolution spectrum, at the expense of very much lower time
> resolution of course.
>
> Regards,
> James
>
>
> On Fri, Aug 28, 2020 at 11:04 AM Colm Bracken 
> wrote:
>
>> Hi Cedric,
>>
>> Great, thanks for confirming that.
>> One more question, if you don't mind?
>>
>> If a narrow band signal is off-centre relative to one of my frequency
>> bins, will the measured amplitude change each time I run the FFT?
>> For example, if my FFT frequency bins are exactly 1 MHz wide (1024 pt FFT
>> applied to 1 GSPS ADC data), and I am trying to measure a sinusoid with a
>> frequency of 5.1 MHz, will the measured amplitude oscillate at a frequency
>> of 0.1 MHz (5.1 MHz - 5 MHz)? Basically, my sampling (in terms of how often
>> I sample the full time stream for the FFT) is out of phase with the signal
>> to be measured?
>>
>> I probably didn't explain that very well, apologies.
>>
>> Best wishes,
>> Colm
>>
>> On Fri, 28 Aug 2020 at 11:17, 'Cedric Viou' via casper@lists.berkeley.edu
>>  wrote:
>>
>>> Hi Colm,
>>>
>>> You are right.
>>>
>>> PFB is a great way to reduce frequency smearing but the down-side is
>>> time smearing.
>>>
>>> A brief event will be convolved with at least one of your PFB 8-tap
>>> filters that end up feeding several FFT computations in a row.
>>> So, you get time smearing for that short event...
>>>
>>> Regards,
>>>
>>> Cedric
>>>
>>>
>>> Le 28/08/2020 à 11:56, Colm Bracken a écrit :
>>> > Hi All,
>>> >
>>> > I have a question, which is probably DSP 101 basics, but I just wasn't
>>> 100% sure.
>>> >
>>> > If I am applying a 1024 point FFT to a continuous time-stream from an
>>> ADC with sampling ~ 1 GSPS, I will have a time resolution ~ 1 microsecond
>>> (and frequency res. of ~ 1 MHz).
>>> >
>>> > But, if I instead apply an 8 tap PFB, am I essentially smearing out my
>>> time resolution by a factor of 8, since I am now summing 8 rows of my 1024
>>> point time streams?
>>> > I can't see how the number of PFB taps wouldn't affect my time
>>> resolution. Or am I missing something?
>>> >
>>> > Thanks in advance,
>>> > Colm
>>> >
>>> > --
>>> >
>>> > *Dr Colm Bracken*
>>> > Lecturer
>>> > Maynooth University Experimental Physics
>>> >
>>> >
>>> > Maynooth University, Maynooth, Co. Kildare, Ireland.
>>> >
>>> > T: +353 1 708 3641
>>> > E: colm.brac...@mu.ie  W:
>>> www.maynoothuniversity.ie 
>>> >
>>> > Follow my work on https://nuim.academia.edu/ColmBracken
>>> >
>>> >
>>> >
>>> > And
>>> >
>>> >
>>> > Research Associate
>>> >
>>> > Astronomy & Astrophysics Section
>>> > School of Cosmic Physics
>>> > Dublin Institute for Advanced Studies
>>> > 31 Fitzwilliam Place
>>> > Dublin 2, D02 XF86
>>> >
>>> >
>>> >
>>> > T: +353 1 440 6656 ext 352
>>> > E: cbrac...@cp.dias.ie  W:
>>> www.dias.ie/2017/06/22/dr-colm-bracken <
>>> https://www.dias.ie/2017/06/22/dr-colm-bracken>
>>> >
>>> > Follow my work on https://nuim.academia.edu/ColmBracken
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups "casper@lists.berkeley.edu" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> an email to casper+unsubscr...@lists.berkeley.edu >> casper+unsubscr...@lists.berkeley.edu>.
>>> > To view this discussion on the web visit
>>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAEx9wh9GmrYZ7_uLkXwSKqOp3GYm1Ei_0Bq-TPg9pt8LgQdprw%40mail.gmail.com
>>> <
>>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAEx9wh9GmrYZ7_uLkXwSKqOp3GYm1Ei_0Bq-TPg9pt8LgQdprw%40mail.gmail.com?utm_medium=email_source=footer
>>> >.
>>>
>>> --
>>> Cedric Viou 
>>>
>>> Ingénieur de recherche
>>>
>>> Station de Radioastronomie de Nançay,
>>> Observatoire de Paris, PSL Research University, CNRS, Univ. Orléans,
>>> OSUC,
>>> 18330 Nançay, France
>>> http://www.obs-nancay.fr/
>>>
>>> phone : +33 (0) 248 51 8609
>>> fax   : +33 (0) 248 51 8318
>>>
>>> www.openstreetmap.org/?mlat=47.381848=2.194415=18
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "casper@lists.berkeley.edu" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to casper+unsubscr...@lists.berkeley.edu.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/68a23cbf-5320-8b50-7a4f-52379c4a2ad7%40obs-nancay.fr
>>> .
>>>
>>
>>
>> --
>>
>> *Dr Colm Bracken*
>> Lecturer
>> Maynooth University Experimental Physics
>>
>>
>> Maynooth University, Maynooth, Co. 

Re: [casper] Red Pitaya Wide(-ish)band Spectrometer Tutorial

[Paul Akumu]

Hi  Mathews,

I am using Matlab 2018a and Vivado 2019.1.1

When I run casperfpga.__version__, I get
*0.0+unknown.202008281536 *

Thanks,
Paul.

On Fri, Aug 28, 2020 at 3:24 PM Mathews Chirindo 
wrote:

> Hi Paul
>
> I had to try the following from my side:
>
> 1. I cloned the repos from casper-astro mlib_devel
> https://github.com/casper-astro/mlib_devel/tree/devel [devel branch] and
> https://github.com/casper-astro/tutorials_devel [master branch]
> 2. I successfully compiled the first tutorial
> https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_intro
>  and
> programmed the red pitaya - tested all good.
> 3. I successfully compiled the second tutorial
> https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_adc_dac
>  and
> programmed the red pitaya - tested all good.
> 4. I ran the tut_spec.py script at
> https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_spec
>  using
> the tut_spec.fpg file. No issues.
> 5. I ran the tut_spec.py script at
> https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_spec
>  using
> the fpg file that I compiled from tut_spec.slx. No issues.
>
> I am using Matlab 2018a and Vivado 2019.1. Can you refine which ones you
> use particularly eg 2018a or 2018b and 2019.1 or 2019.2. I am not sure
> about compatibility, though.
>
> It seems there is no problem with the design files in the repos.
>
> What do you get if you run: casperfga.__version__
>
> Further investigations will follow.
>
> Thanks
> Mathews
>
>
>
>
>
>
> On Fri, Aug 28, 2020 at 8:50 AM Adam Isaacson  wrote:
>
>> Hi Paul,
>>
>> Thanks, I will investigate further and get back to you.
>>
>> Kind regards,
>>
>> Adam Isaacson
>> South African Radio Astronomy Observatory (SARAO)
>> Hardware Manager
>> Cell: (+27) 825639602
>> Tel:  (+27) 215067300
>> email: aisaac...@ska.ac.za
>>
>>
>>
>> On Thu, Aug 27, 2020 at 10:49 PM Paul Akumu  wrote:
>>
>>> Hi Adam,
>>>
>>> I have tried the recommended repos but the error still persists.
>>>
>>> Kind regards,
>>> Paul.
>>>
>>> On Thu, Aug 27, 2020 at 11:00 AM Adam Isaacson 
>>> wrote:
>>>
 Hi Paul,

 Thanks for confirming. Please can you try the latest commits and
 following repos:

 1) mlib_devel - https://github.com/ska-sa/mlib_devel
  (devel branch)
 2) casperfpga - https://github.com/ska-sa/casperfpga (devel branch)

 These repos contain the latest Red Pitaya fixes. If the problem still
 persists then I will investigate further. I just want to make sure that we
 have merged all the relevant fixes in the casper-astro repo from the ska-sa
 repo.

 Kind regards,

 Adam Isaacson
 South African Radio Astronomy Observatory (SARAO)
 Hardware Manager
 Cell: (+27) 825639602
 Tel:  (+27) 215067300
 email: aisaac...@ska.ac.za



 On Wed, Aug 26, 2020 at 8:39 PM Paul Akumu  wrote:

> Hi Adam,
>
> Yes, I built the slx files and generated the fpg files for the first
> two tutorials.
>
> For the third tutorial, I first opened the slx file in Simulink and
> compiled it but got an error when I tried to upload and program. Then I
> tried updating the model as described under "Updating an Existing Toolfow
> Installation" using update_casper_blocks(bdroot) before compiling
> again but got the same error report. Finally, I tried using the fpg file
> provided which also resulted in the same error.
>
> Thanks,
> Paul.
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_2240250882981861666_m_5257118673740282965_m_-3441388826180357240_m_-3334835703352447321_m_5458899884828230806_m_6900430746832513320_m_497581565406995344_m_7518126369254170950_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Wed, Aug 26, 2020 at 3:49 PM Adam Isaacson 
> wrote:
>
>> Hi Paul,
>>
>> Thanks for your email. It looks like your mlib_devel and casperfpga
>> version are fairly recent and contain the BRAM 32 bit fixes that we made.
>> It seems I committed this particular fpg file 9 months ago, so it might 
>> not
>> of contained all these fixes then. I am quite certain it was working for
>> me, but maybe I committed the incorrect file at the time. You say the 
>> first
>> two tutorials were successful and I know the second tutorial has a
>> snapshot, so your build environment must work. I am assuming you build 
>> the
>> slx files and generated the fpg files for the first two tuts, of course.
>> Correct me if wrong!
>>
>> Please try and rebuild the spectrometer slx file and test the fpg
>> generated file. Let me know if 

Re: [casper] Red Pitaya Wide(-ish)band Spectrometer Tutorial

[Mathews Chirindo]

Hi Paul

I had to try the following from my side:

1. I cloned the repos from casper-astro mlib_devel
https://github.com/casper-astro/mlib_devel/tree/devel [devel branch] and
https://github.com/casper-astro/tutorials_devel [master branch]
2. I successfully compiled the first tutorial
https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_intro
and
programmed the red pitaya - tested all good.
3. I successfully compiled the second tutorial
https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_adc_dac
and
programmed the red pitaya - tested all good.
4. I ran the tut_spec.py script at
https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_spec
using
the tut_spec.fpg file. No issues.
5. I ran the tut_spec.py script at
https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_spec
using
the fpg file that I compiled from tut_spec.slx. No issues.

I am using Matlab 2018a and Vivado 2019.1. Can you refine which ones you
use particularly eg 2018a or 2018b and 2019.1 or 2019.2. I am not sure
about compatibility, though.

It seems there is no problem with the design files in the repos.

What do you get if you run: casperfga.__version__

Further investigations will follow.

Thanks
Mathews






On Fri, Aug 28, 2020 at 8:50 AM Adam Isaacson  wrote:

> Hi Paul,
>
> Thanks, I will investigate further and get back to you.
>
> Kind regards,
>
> Adam Isaacson
> South African Radio Astronomy Observatory (SARAO)
> Hardware Manager
> Cell: (+27) 825639602
> Tel:  (+27) 215067300
> email: aisaac...@ska.ac.za
>
>
>
> On Thu, Aug 27, 2020 at 10:49 PM Paul Akumu  wrote:
>
>> Hi Adam,
>>
>> I have tried the recommended repos but the error still persists.
>>
>> Kind regards,
>> Paul.
>>
>> On Thu, Aug 27, 2020 at 11:00 AM Adam Isaacson 
>> wrote:
>>
>>> Hi Paul,
>>>
>>> Thanks for confirming. Please can you try the latest commits and
>>> following repos:
>>>
>>> 1) mlib_devel - https://github.com/ska-sa/mlib_devel
>>>  (devel branch)
>>> 2) casperfpga - https://github.com/ska-sa/casperfpga (devel branch)
>>>
>>> These repos contain the latest Red Pitaya fixes. If the problem still
>>> persists then I will investigate further. I just want to make sure that we
>>> have merged all the relevant fixes in the casper-astro repo from the ska-sa
>>> repo.
>>>
>>> Kind regards,
>>>
>>> Adam Isaacson
>>> South African Radio Astronomy Observatory (SARAO)
>>> Hardware Manager
>>> Cell: (+27) 825639602
>>> Tel:  (+27) 215067300
>>> email: aisaac...@ska.ac.za
>>>
>>>
>>>
>>> On Wed, Aug 26, 2020 at 8:39 PM Paul Akumu  wrote:
>>>
 Hi Adam,

 Yes, I built the slx files and generated the fpg files for the first
 two tutorials.

 For the third tutorial, I first opened the slx file in Simulink and
 compiled it but got an error when I tried to upload and program. Then I
 tried updating the model as described under "Updating an Existing Toolfow
 Installation" using update_casper_blocks(bdroot) before compiling
 again but got the same error report. Finally, I tried using the fpg file
 provided which also resulted in the same error.

 Thanks,
 Paul.




 
  Virus-free.
 www.avast.com
 
 <#m_5257118673740282965_m_-3441388826180357240_m_-3334835703352447321_m_5458899884828230806_m_6900430746832513320_m_497581565406995344_m_7518126369254170950_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

 On Wed, Aug 26, 2020 at 3:49 PM Adam Isaacson 
 wrote:

> Hi Paul,
>
> Thanks for your email. It looks like your mlib_devel and casperfpga
> version are fairly recent and contain the BRAM 32 bit fixes that we made.
> It seems I committed this particular fpg file 9 months ago, so it might 
> not
> of contained all these fixes then. I am quite certain it was working for
> me, but maybe I committed the incorrect file at the time. You say the 
> first
> two tutorials were successful and I know the second tutorial has a
> snapshot, so your build environment must work. I am assuming you build the
> slx files and generated the fpg files for the first two tuts, of course.
> Correct me if wrong!
>
> Please try and rebuild the spectrometer slx file and test the fpg
> generated file. Let me know if you get the same issue. If you don't then I
> must have checked a suspect fpg file in this repo and we can easily fix
> that, if that is the case.
>
> Kind regards,
>
> Adam Isaacson
> South African Radio Astronomy Observatory (SARAO)
> Hardware Manager
> Cell: (+27) 825639602
> Tel:  (+27) 215067300
> email: aisaac...@ska.ac.za
>
>
>
> On Mon, 

Re: [casper] PFB (taps): Effects on time resolution

[James Smith]

Hello Colm,

Yes, you're correct. That's how some of our narrowband designs work - you
use each PFB channel as a very narrow bandpass filter, and treat its output
as a complex time-series. So you can pass it through another PFB to get a
higher-resolution spectrum, at the expense of very much lower time
resolution of course.

Regards,
James


On Fri, Aug 28, 2020 at 11:04 AM Colm Bracken  wrote:

> Hi Cedric,
>
> Great, thanks for confirming that.
> One more question, if you don't mind?
>
> If a narrow band signal is off-centre relative to one of my frequency
> bins, will the measured amplitude change each time I run the FFT?
> For example, if my FFT frequency bins are exactly 1 MHz wide (1024 pt FFT
> applied to 1 GSPS ADC data), and I am trying to measure a sinusoid with a
> frequency of 5.1 MHz, will the measured amplitude oscillate at a frequency
> of 0.1 MHz (5.1 MHz - 5 MHz)? Basically, my sampling (in terms of how often
> I sample the full time stream for the FFT) is out of phase with the signal
> to be measured?
>
> I probably didn't explain that very well, apologies.
>
> Best wishes,
> Colm
>
> On Fri, 28 Aug 2020 at 11:17, 'Cedric Viou' via casper@lists.berkeley.edu
>  wrote:
>
>> Hi Colm,
>>
>> You are right.
>>
>> PFB is a great way to reduce frequency smearing but the down-side is time
>> smearing.
>>
>> A brief event will be convolved with at least one of your PFB 8-tap
>> filters that end up feeding several FFT computations in a row.
>> So, you get time smearing for that short event...
>>
>> Regards,
>>
>> Cedric
>>
>>
>> Le 28/08/2020 à 11:56, Colm Bracken a écrit :
>> > Hi All,
>> >
>> > I have a question, which is probably DSP 101 basics, but I just wasn't
>> 100% sure.
>> >
>> > If I am applying a 1024 point FFT to a continuous time-stream from an
>> ADC with sampling ~ 1 GSPS, I will have a time resolution ~ 1 microsecond
>> (and frequency res. of ~ 1 MHz).
>> >
>> > But, if I instead apply an 8 tap PFB, am I essentially smearing out my
>> time resolution by a factor of 8, since I am now summing 8 rows of my 1024
>> point time streams?
>> > I can't see how the number of PFB taps wouldn't affect my time
>> resolution. Or am I missing something?
>> >
>> > Thanks in advance,
>> > Colm
>> >
>> > --
>> >
>> > *Dr Colm Bracken*
>> > Lecturer
>> > Maynooth University Experimental Physics
>> >
>> >
>> > Maynooth University, Maynooth, Co. Kildare, Ireland.
>> >
>> > T: +353 1 708 3641
>> > E: colm.brac...@mu.ie  W:
>> www.maynoothuniversity.ie 
>> >
>> > Follow my work on https://nuim.academia.edu/ColmBracken
>> >
>> >
>> >
>> > And
>> >
>> >
>> > Research Associate
>> >
>> > Astronomy & Astrophysics Section
>> > School of Cosmic Physics
>> > Dublin Institute for Advanced Studies
>> > 31 Fitzwilliam Place
>> > Dublin 2, D02 XF86
>> >
>> >
>> >
>> > T: +353 1 440 6656 ext 352
>> > E: cbrac...@cp.dias.ie  W:
>> www.dias.ie/2017/06/22/dr-colm-bracken <
>> https://www.dias.ie/2017/06/22/dr-colm-bracken>
>> >
>> > Follow my work on https://nuim.academia.edu/ColmBracken
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "casper@lists.berkeley.edu" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to casper+unsubscr...@lists.berkeley.edu > casper+unsubscr...@lists.berkeley.edu>.
>> > To view this discussion on the web visit
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAEx9wh9GmrYZ7_uLkXwSKqOp3GYm1Ei_0Bq-TPg9pt8LgQdprw%40mail.gmail.com
>> <
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAEx9wh9GmrYZ7_uLkXwSKqOp3GYm1Ei_0Bq-TPg9pt8LgQdprw%40mail.gmail.com?utm_medium=email_source=footer
>> >.
>>
>> --
>> Cedric Viou 
>>
>> Ingénieur de recherche
>>
>> Station de Radioastronomie de Nançay,
>> Observatoire de Paris, PSL Research University, CNRS, Univ. Orléans,
>> OSUC,
>> 18330 Nançay, France
>> http://www.obs-nancay.fr/
>>
>> phone : +33 (0) 248 51 8609
>> fax   : +33 (0) 248 51 8318
>>
>> www.openstreetmap.org/?mlat=47.381848=2.194415=18
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To view this discussion on the web visit
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/68a23cbf-5320-8b50-7a4f-52379c4a2ad7%40obs-nancay.fr
>> .
>>
>
>
> --
>
> *Dr Colm Bracken*
> Lecturer
> Maynooth University Experimental Physics
>
>
> Maynooth University, Maynooth, Co. Kildare, Ireland.
>
> T: +353 1 708 3641
> E: colm.brac...@mu.ie W: www.maynoothuniversity.ie
>
> Follow my work on https://nuim.academia.edu/ColmBracken
>
>
>
> And
>
>
> Research Associate
>
> Astronomy & Astrophysics Section
> School of Cosmic Physics
> Dublin Institute for Advanced Studies
> 31 Fitzwilliam Place
> 

Re: [casper] Red Pitaya Wide(-ish)band Spectrometer Tutorial

[Paul Akumu]

Noted with thanks.


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Fri, Aug 28, 2020 at 1:39 PM Adam Isaacson  wrote:

> Hi Paul,
>
> I have spoken with my colleague Mathews Chirindo who will be investigating
> this further for you. He made the most recent changes to the toolflow and
> tested the tutorials for the Red Pitaya recently. He will give you feedback
> on this thread.
>
> Kind regards,
>
> Adam Isaacson
> South African Radio Astronomy Observatory (SARAO)
> Hardware Manager
> Cell: (+27) 825639602
> Tel:  (+27) 215067300
> email: aisaac...@ska.ac.za
>
>
>
> On Fri, Aug 28, 2020 at 8:50 AM Adam Isaacson  wrote:
>
>> Hi Paul,
>>
>> Thanks, I will investigate further and get back to you.
>>
>> Kind regards,
>>
>> Adam Isaacson
>> South African Radio Astronomy Observatory (SARAO)
>> Hardware Manager
>> Cell: (+27) 825639602
>> Tel:  (+27) 215067300
>> email: aisaac...@ska.ac.za
>>
>>
>>
>> On Thu, Aug 27, 2020 at 10:49 PM Paul Akumu  wrote:
>>
>>> Hi Adam,
>>>
>>> I have tried the recommended repos but the error still persists.
>>>
>>> Kind regards,
>>> Paul.
>>>
>>> On Thu, Aug 27, 2020 at 11:00 AM Adam Isaacson 
>>> wrote:
>>>
 Hi Paul,

 Thanks for confirming. Please can you try the latest commits and
 following repos:

 1) mlib_devel - https://github.com/ska-sa/mlib_devel
  (devel branch)
 2) casperfpga - https://github.com/ska-sa/casperfpga (devel branch)

 These repos contain the latest Red Pitaya fixes. If the problem still
 persists then I will investigate further. I just want to make sure that we
 have merged all the relevant fixes in the casper-astro repo from the ska-sa
 repo.

 Kind regards,

 Adam Isaacson
 South African Radio Astronomy Observatory (SARAO)
 Hardware Manager
 Cell: (+27) 825639602
 Tel:  (+27) 215067300
 email: aisaac...@ska.ac.za



 On Wed, Aug 26, 2020 at 8:39 PM Paul Akumu  wrote:

> Hi Adam,
>
> Yes, I built the slx files and generated the fpg files for the first
> two tutorials.
>
> For the third tutorial, I first opened the slx file in Simulink and
> compiled it but got an error when I tried to upload and program. Then I
> tried updating the model as described under "Updating an Existing Toolfow
> Installation" using update_casper_blocks(bdroot) before compiling
> again but got the same error report. Finally, I tried using the fpg file
> provided which also resulted in the same error.
>
> Thanks,
> Paul.
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-9194337642259334392_m_3990562732980485248_m_5458899884828230806_m_6900430746832513320_m_497581565406995344_m_7518126369254170950_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Wed, Aug 26, 2020 at 3:49 PM Adam Isaacson 
> wrote:
>
>> Hi Paul,
>>
>> Thanks for your email. It looks like your mlib_devel and casperfpga
>> version are fairly recent and contain the BRAM 32 bit fixes that we made.
>> It seems I committed this particular fpg file 9 months ago, so it might 
>> not
>> of contained all these fixes then. I am quite certain it was working for
>> me, but maybe I committed the incorrect file at the time. You say the 
>> first
>> two tutorials were successful and I know the second tutorial has a
>> snapshot, so your build environment must work. I am assuming you build 
>> the
>> slx files and generated the fpg files for the first two tuts, of course.
>> Correct me if wrong!
>>
>> Please try and rebuild the spectrometer slx file and test the fpg
>> generated file. Let me know if you get the same issue. If you don't then 
>> I
>> must have checked a suspect fpg file in this repo and we can easily fix
>> that, if that is the case.
>>
>> Kind regards,
>>
>> Adam Isaacson
>> South African Radio Astronomy Observatory (SARAO)
>> Hardware Manager
>> Cell: (+27) 825639602
>> Tel:  (+27) 215067300
>> email: aisaac...@ska.ac.za
>>
>>
>>
>> On Mon, Aug 24, 2020 at 10:52 PM Paul Akumu 
>> wrote:
>>
>>> Hello,
>>>
>>> I am new to the Toolfow and I have been following the Red Pitaya
>>> tutorials. I have Matlab 2018 and Vivado 2019 installed. I was able to
>>> follow the first two tutorials which compiled and uploaded via 
>>> casperfpga
>>> successfully. When following 

Re: [casper] PFB (taps): Effects on time resolution

[Colm Bracken]

Hi Cedric,

Great, thanks for confirming that.
One more question, if you don't mind?

If a narrow band signal is off-centre relative to one of my frequency bins,
will the measured amplitude change each time I run the FFT?
For example, if my FFT frequency bins are exactly 1 MHz wide (1024 pt FFT
applied to 1 GSPS ADC data), and I am trying to measure a sinusoid with a
frequency of 5.1 MHz, will the measured amplitude oscillate at a frequency
of 0.1 MHz (5.1 MHz - 5 MHz)? Basically, my sampling (in terms of how often
I sample the full time stream for the FFT) is out of phase with the signal
to be measured?

I probably didn't explain that very well, apologies.

Best wishes,
Colm

On Fri, 28 Aug 2020 at 11:17, 'Cedric Viou' via casper@lists.berkeley.edu <
casper@lists.berkeley.edu> wrote:

> Hi Colm,
>
> You are right.
>
> PFB is a great way to reduce frequency smearing but the down-side is time
> smearing.
>
> A brief event will be convolved with at least one of your PFB 8-tap
> filters that end up feeding several FFT computations in a row.
> So, you get time smearing for that short event...
>
> Regards,
>
> Cedric
>
>
> Le 28/08/2020 à 11:56, Colm Bracken a écrit :
> > Hi All,
> >
> > I have a question, which is probably DSP 101 basics, but I just wasn't
> 100% sure.
> >
> > If I am applying a 1024 point FFT to a continuous time-stream from an
> ADC with sampling ~ 1 GSPS, I will have a time resolution ~ 1 microsecond
> (and frequency res. of ~ 1 MHz).
> >
> > But, if I instead apply an 8 tap PFB, am I essentially smearing out my
> time resolution by a factor of 8, since I am now summing 8 rows of my 1024
> point time streams?
> > I can't see how the number of PFB taps wouldn't affect my time
> resolution. Or am I missing something?
> >
> > Thanks in advance,
> > Colm
> >
> > --
> >
> > *Dr Colm Bracken*
> > Lecturer
> > Maynooth University Experimental Physics
> >
> >
> > Maynooth University, Maynooth, Co. Kildare, Ireland.
> >
> > T: +353 1 708 3641
> > E: colm.brac...@mu.ie  W:
> www.maynoothuniversity.ie 
> >
> > Follow my work on https://nuim.academia.edu/ColmBracken
> >
> >
> >
> > And
> >
> >
> > Research Associate
> >
> > Astronomy & Astrophysics Section
> > School of Cosmic Physics
> > Dublin Institute for Advanced Studies
> > 31 Fitzwilliam Place
> > Dublin 2, D02 XF86
> >
> >
> >
> > T: +353 1 440 6656 ext 352
> > E: cbrac...@cp.dias.ie  W:
> www.dias.ie/2017/06/22/dr-colm-bracken <
> https://www.dias.ie/2017/06/22/dr-colm-bracken>
> >
> > Follow my work on https://nuim.academia.edu/ColmBracken
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "casper@lists.berkeley.edu" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to casper+unsubscr...@lists.berkeley.edu  casper+unsubscr...@lists.berkeley.edu>.
> > To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAEx9wh9GmrYZ7_uLkXwSKqOp3GYm1Ei_0Bq-TPg9pt8LgQdprw%40mail.gmail.com
> <
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAEx9wh9GmrYZ7_uLkXwSKqOp3GYm1Ei_0Bq-TPg9pt8LgQdprw%40mail.gmail.com?utm_medium=email_source=footer
> >.
>
> --
> Cedric Viou 
>
> Ingénieur de recherche
>
> Station de Radioastronomie de Nançay,
> Observatoire de Paris, PSL Research University, CNRS, Univ. Orléans, OSUC,
> 18330 Nançay, France
> http://www.obs-nancay.fr/
>
> phone : +33 (0) 248 51 8609
> fax   : +33 (0) 248 51 8318
>
> www.openstreetmap.org/?mlat=47.381848=2.194415=18
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/68a23cbf-5320-8b50-7a4f-52379c4a2ad7%40obs-nancay.fr
> .
>


-- 

*Dr Colm Bracken*
Lecturer
Maynooth University Experimental Physics


Maynooth University, Maynooth, Co. Kildare, Ireland.

T: +353 1 708 3641
E: colm.brac...@mu.ie W: www.maynoothuniversity.ie

Follow my work on https://nuim.academia.edu/ColmBracken



And


Research Associate

Astronomy & Astrophysics Section
School of Cosmic Physics
Dublin Institute for Advanced Studies
31 Fitzwilliam Place
Dublin 2, D02 XF86



T: +353 1 440 6656 ext 352
E: cbrac...@cp.dias.ie W: www.dias.ie/2017/06/22/dr-colm-bracken

Follow my work on https://nuim.academia.edu/ColmBracken

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 

Re: [casper] Red Pitaya Wide(-ish)band Spectrometer Tutorial

[Adam Isaacson]

Hi Paul,

I have spoken with my colleague Mathews Chirindo who will be investigating
this further for you. He made the most recent changes to the toolflow and
tested the tutorials for the Red Pitaya recently. He will give you feedback
on this thread.

Kind regards,

Adam Isaacson
South African Radio Astronomy Observatory (SARAO)
Hardware Manager
Cell: (+27) 825639602
Tel:  (+27) 215067300
email: aisaac...@ska.ac.za



On Fri, Aug 28, 2020 at 8:50 AM Adam Isaacson  wrote:

> Hi Paul,
>
> Thanks, I will investigate further and get back to you.
>
> Kind regards,
>
> Adam Isaacson
> South African Radio Astronomy Observatory (SARAO)
> Hardware Manager
> Cell: (+27) 825639602
> Tel:  (+27) 215067300
> email: aisaac...@ska.ac.za
>
>
>
> On Thu, Aug 27, 2020 at 10:49 PM Paul Akumu  wrote:
>
>> Hi Adam,
>>
>> I have tried the recommended repos but the error still persists.
>>
>> Kind regards,
>> Paul.
>>
>> On Thu, Aug 27, 2020 at 11:00 AM Adam Isaacson 
>> wrote:
>>
>>> Hi Paul,
>>>
>>> Thanks for confirming. Please can you try the latest commits and
>>> following repos:
>>>
>>> 1) mlib_devel - https://github.com/ska-sa/mlib_devel
>>>  (devel branch)
>>> 2) casperfpga - https://github.com/ska-sa/casperfpga (devel branch)
>>>
>>> These repos contain the latest Red Pitaya fixes. If the problem still
>>> persists then I will investigate further. I just want to make sure that we
>>> have merged all the relevant fixes in the casper-astro repo from the ska-sa
>>> repo.
>>>
>>> Kind regards,
>>>
>>> Adam Isaacson
>>> South African Radio Astronomy Observatory (SARAO)
>>> Hardware Manager
>>> Cell: (+27) 825639602
>>> Tel:  (+27) 215067300
>>> email: aisaac...@ska.ac.za
>>>
>>>
>>>
>>> On Wed, Aug 26, 2020 at 8:39 PM Paul Akumu  wrote:
>>>
 Hi Adam,

 Yes, I built the slx files and generated the fpg files for the first
 two tutorials.

 For the third tutorial, I first opened the slx file in Simulink and
 compiled it but got an error when I tried to upload and program. Then I
 tried updating the model as described under "Updating an Existing Toolfow
 Installation" using update_casper_blocks(bdroot) before compiling
 again but got the same error report. Finally, I tried using the fpg file
 provided which also resulted in the same error.

 Thanks,
 Paul.




 
  Virus-free.
 www.avast.com
 
 <#m_3990562732980485248_m_5458899884828230806_m_6900430746832513320_m_497581565406995344_m_7518126369254170950_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

 On Wed, Aug 26, 2020 at 3:49 PM Adam Isaacson 
 wrote:

> Hi Paul,
>
> Thanks for your email. It looks like your mlib_devel and casperfpga
> version are fairly recent and contain the BRAM 32 bit fixes that we made.
> It seems I committed this particular fpg file 9 months ago, so it might 
> not
> of contained all these fixes then. I am quite certain it was working for
> me, but maybe I committed the incorrect file at the time. You say the 
> first
> two tutorials were successful and I know the second tutorial has a
> snapshot, so your build environment must work. I am assuming you build the
> slx files and generated the fpg files for the first two tuts, of course.
> Correct me if wrong!
>
> Please try and rebuild the spectrometer slx file and test the fpg
> generated file. Let me know if you get the same issue. If you don't then I
> must have checked a suspect fpg file in this repo and we can easily fix
> that, if that is the case.
>
> Kind regards,
>
> Adam Isaacson
> South African Radio Astronomy Observatory (SARAO)
> Hardware Manager
> Cell: (+27) 825639602
> Tel:  (+27) 215067300
> email: aisaac...@ska.ac.za
>
>
>
> On Mon, Aug 24, 2020 at 10:52 PM Paul Akumu 
> wrote:
>
>> Hello,
>>
>> I am new to the Toolfow and I have been following the Red Pitaya
>> tutorials. I have Matlab 2018 and Vivado 2019 installed. I was able to
>> follow the first two tutorials which compiled and uploaded via casperfpga
>> successfully. When following the wide band spectrometer tutorial I tried 
>> to
>> program the red Pitaya with the fpg file provided for the tutorial
>> here
>> ,
>> but got the following response/error;
>>
>> Connecting to Red Pitaya: 192.168.200.151
>> Uploading: tut_spec.fpg
>> These are the devices in your design ...
>> ['acc_cnt', 'acc_len', 'accum0_snap_ss_bram', 'accum0_snap_ss_ctrl',
>> 'accum0_snap_ss_status', 'accum1_snap_ss_bram', 

Re: [casper] PFB (taps): Effects on time resolution

['Cedric Viou' via casper@lists.berkeley.edu]

Hi Colm,

You are right.

PFB is a great way to reduce frequency smearing but the down-side is time 
smearing.

A brief event will be convolved with at least one of your PFB 8-tap filters 
that end up feeding several FFT computations in a row.
So, you get time smearing for that short event...

Regards,

Cedric


Le 28/08/2020 à 11:56, Colm Bracken a écrit :
> Hi All,
> 
> I have a question, which is probably DSP 101 basics, but I just wasn't 100% 
> sure.
> 
> If I am applying a 1024 point FFT to a continuous time-stream from an ADC 
> with sampling ~ 1 GSPS, I will have a time resolution ~ 1 microsecond (and 
> frequency res. of ~ 1 MHz).
> 
> But, if I instead apply an 8 tap PFB, am I essentially smearing out my time 
> resolution by a factor of 8, since I am now summing 8 rows of my 1024 point 
> time streams?
> I can't see how the number of PFB taps wouldn't affect my time resolution. Or 
> am I missing something?
> 
> Thanks in advance,
> Colm
> 
> -- 
> 
> *Dr Colm Bracken*
> Lecturer
> Maynooth University Experimental Physics
> 
> 
> Maynooth University, Maynooth, Co. Kildare, Ireland.
> 
> T: +353 1 708 3641
> E: colm.brac...@mu.ie  W: 
> www.maynoothuniversity.ie 
> 
> Follow my work on https://nuim.academia.edu/ColmBracken
> 
>  
> 
> And
> 
> 
> Research Associate
> 
> Astronomy & Astrophysics Section
> School of Cosmic Physics
> Dublin Institute for Advanced Studies
> 31 Fitzwilliam Place
> Dublin 2, D02 XF86
> 
> 
> 
> T: +353 1 440 6656 ext 352
> E: cbrac...@cp.dias.ie  W: 
> www.dias.ie/2017/06/22/dr-colm-bracken 
> 
> 
> Follow my work on https://nuim.academia.edu/ColmBracken
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to casper+unsubscr...@lists.berkeley.edu 
> .
> To view this discussion on the web visit 
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAEx9wh9GmrYZ7_uLkXwSKqOp3GYm1Ei_0Bq-TPg9pt8LgQdprw%40mail.gmail.com
>  
> .

-- 
Cedric Viou 

Ingénieur de recherche

Station de Radioastronomie de Nançay, 
Observatoire de Paris, PSL Research University, CNRS, Univ. Orléans, OSUC, 
18330 Nançay, France
http://www.obs-nancay.fr/

phone : +33 (0) 248 51 8609
fax   : +33 (0) 248 51 8318

www.openstreetmap.org/?mlat=47.381848=2.194415=18

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/68a23cbf-5320-8b50-7a4f-52379c4a2ad7%40obs-nancay.fr.


signature.asc
Description: OpenPGP digital signature

[casper] PFB (taps): Effects on time resolution

[Colm Bracken]

Hi All,

I have a question, which is probably DSP 101 basics, but I just wasn't 100%
sure.

If I am applying a 1024 point FFT to a continuous time-stream from an ADC
with sampling ~ 1 GSPS, I will have a time resolution ~ 1 microsecond (and
frequency res. of ~ 1 MHz).

But, if I instead apply an 8 tap PFB, am I essentially smearing out my time
resolution by a factor of 8, since I am now summing 8 rows of my 1024 point
time streams?
I can't see how the number of PFB taps wouldn't affect my time resolution.
Or am I missing something?

Thanks in advance,
Colm

-- 

*Dr Colm Bracken*
Lecturer
Maynooth University Experimental Physics


Maynooth University, Maynooth, Co. Kildare, Ireland.

T: +353 1 708 3641
E: colm.brac...@mu.ie W: www.maynoothuniversity.ie

Follow my work on https://nuim.academia.edu/ColmBracken



And


Research Associate

Astronomy & Astrophysics Section
School of Cosmic Physics
Dublin Institute for Advanced Studies
31 Fitzwilliam Place
Dublin 2, D02 XF86



T: +353 1 440 6656 ext 352
E: cbrac...@cp.dias.ie W: www.dias.ie/2017/06/22/dr-colm-bracken

Follow my work on https://nuim.academia.edu/ColmBracken

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAEx9wh9GmrYZ7_uLkXwSKqOp3GYm1Ei_0Bq-TPg9pt8LgQdprw%40mail.gmail.com.

Re: [casper] Red Pitaya Wide(-ish)band Spectrometer Tutorial

[Adam Isaacson]

Hi Paul,

Thanks, I will investigate further and get back to you.

Kind regards,

Adam Isaacson
South African Radio Astronomy Observatory (SARAO)
Hardware Manager
Cell: (+27) 825639602
Tel:  (+27) 215067300
email: aisaac...@ska.ac.za



On Thu, Aug 27, 2020 at 10:49 PM Paul Akumu  wrote:

> Hi Adam,
>
> I have tried the recommended repos but the error still persists.
>
> Kind regards,
> Paul.
>
> On Thu, Aug 27, 2020 at 11:00 AM Adam Isaacson 
> wrote:
>
>> Hi Paul,
>>
>> Thanks for confirming. Please can you try the latest commits and
>> following repos:
>>
>> 1) mlib_devel - https://github.com/ska-sa/mlib_devel
>>  (devel branch)
>> 2) casperfpga - https://github.com/ska-sa/casperfpga (devel branch)
>>
>> These repos contain the latest Red Pitaya fixes. If the problem still
>> persists then I will investigate further. I just want to make sure that we
>> have merged all the relevant fixes in the casper-astro repo from the ska-sa
>> repo.
>>
>> Kind regards,
>>
>> Adam Isaacson
>> South African Radio Astronomy Observatory (SARAO)
>> Hardware Manager
>> Cell: (+27) 825639602
>> Tel:  (+27) 215067300
>> email: aisaac...@ska.ac.za
>>
>>
>>
>> On Wed, Aug 26, 2020 at 8:39 PM Paul Akumu  wrote:
>>
>>> Hi Adam,
>>>
>>> Yes, I built the slx files and generated the fpg files for the first two
>>> tutorials.
>>>
>>> For the third tutorial, I first opened the slx file in Simulink and
>>> compiled it but got an error when I tried to upload and program. Then I
>>> tried updating the model as described under "Updating an Existing Toolfow
>>> Installation" using update_casper_blocks(bdroot) before compiling again
>>> but got the same error report. Finally, I tried using the fpg file provided
>>> which also resulted in the same error.
>>>
>>> Thanks,
>>> Paul.
>>>
>>>
>>>
>>>
>>> 
>>>  Virus-free.
>>> www.avast.com
>>> 
>>> <#m_5458899884828230806_m_6900430746832513320_m_497581565406995344_m_7518126369254170950_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>> On Wed, Aug 26, 2020 at 3:49 PM Adam Isaacson 
>>> wrote:
>>>
 Hi Paul,

 Thanks for your email. It looks like your mlib_devel and casperfpga
 version are fairly recent and contain the BRAM 32 bit fixes that we made.
 It seems I committed this particular fpg file 9 months ago, so it might not
 of contained all these fixes then. I am quite certain it was working for
 me, but maybe I committed the incorrect file at the time. You say the first
 two tutorials were successful and I know the second tutorial has a
 snapshot, so your build environment must work. I am assuming you build the
 slx files and generated the fpg files for the first two tuts, of course.
 Correct me if wrong!

 Please try and rebuild the spectrometer slx file and test the fpg
 generated file. Let me know if you get the same issue. If you don't then I
 must have checked a suspect fpg file in this repo and we can easily fix
 that, if that is the case.

 Kind regards,

 Adam Isaacson
 South African Radio Astronomy Observatory (SARAO)
 Hardware Manager
 Cell: (+27) 825639602
 Tel:  (+27) 215067300
 email: aisaac...@ska.ac.za



 On Mon, Aug 24, 2020 at 10:52 PM Paul Akumu  wrote:

> Hello,
>
> I am new to the Toolfow and I have been following the Red Pitaya
> tutorials. I have Matlab 2018 and Vivado 2019 installed. I was able to
> follow the first two tutorials which compiled and uploaded via casperfpga
> successfully. When following the wide band spectrometer tutorial I tried 
> to
> program the red Pitaya with the fpg file provided for the tutorial
> here
> ,
> but got the following response/error;
>
> Connecting to Red Pitaya: 192.168.200.151
> Uploading: tut_spec.fpg
> These are the devices in your design ...
> ['acc_cnt', 'acc_len', 'accum0_snap_ss_bram', 'accum0_snap_ss_ctrl',
> 'accum0_snap_ss_status', 'accum1_snap_ss_bram', 'accum1_snap_ss_ctrl',
> 'accum1_snap_ss_status', 'accumdat_snap_ss_bram', 'accumdat_snap_ss_ctrl',
> 'accumdat_snap_ss_status', 'adc_dv', 'adc_sample_cnt',
> 'adc_voltage_snap_ss_bram', 'adc_voltage_snap_ss_ctrl',
> 'adc_voltage_snap_ss_status', 'fft_sync_inc0', 'fft_sync_inc1',
> 'reg_cntrl', 'snap_gap', 'sync_cnt', 'sync_reg', 'sys_block',
> 'sys_board_id', 'sys_clkcounter', 'sys_rev', 'sys_rev_rcs',
> 'sys_scratchpad']
> Traceback (most recent call last):
>   File "tut_spec.py", line 38, in 
> spec0=fpga.snapshots.accum0_snap_ss.read(arm=False)['data']
>   File