Re: [casper] Ultrascale+HBM DSP48's + CASPER FFT
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
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAPU71P_hO0PX
Re: [casper] Ultrascale+HBM DSP48's + CASPER FFT
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.
[casper] Ultrascale+HBM DSP48's + CASPER FFT
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.
