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

[Mathews Chirindo]

Hi Paul

I want to try and get more information about your setup so we can see how
we can assist you further.

So, what version of Linux are you using? I am using Ubuntu 16.04 LTS. And
are you running the python script under python 3 virtual environment, see
https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html?highlight=virtual%20environment#pre-requisites
or
are you running with just standard python 2.7.

Thanks
Mathews

On Fri, Aug 28, 2020 at 1:38 PM Paul Akumu  wrote:

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

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

[Adam Isaacson]

Thanks, Jonathon. It is possible I sent in a SR to Xilinx at the time. We
should probably be using Vivado 2020.1 - contains other sysgen fixes.

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 10:30 PM Jonathon Kocz  wrote:

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