Hello Adnan,

I'm currently not aware of anyone doing that.

However, since one of the typical applications of beefier FPGAs is math
accelerators for linear algebra problems, it's more than likely someone
did in fact implement an SVD before, and you might just need to connect
it to a nocshell to make it work in RFNoC. There's a lot of interesting
papers out there on SVD implementations for fixed point math on FPGAs,
I think Drexel uni had some interesting stuff for SVD-based channel
estimation for OFDM. I've not seen any code of them, though...

So, from an algorithmic point of view, an SVD isn't too hard. IIRC,
sequential algorithms can work in-place, and thus (for a m×n matrix,
n>m) don't need more than n² space for intermediate and final result
(+2m for index and scale storage if you want to pivot elegantly).

Now, I've not ever implemented more than a C++ QR decomposition (which
is the core algorithm for most EVD problems, which you typically
householder-transform an SVD problem to), so I'm really not competent
to comment on hardware implementations, but chances are you want to
compute a lot of result values in parallel if you're doing it in the
FPGA – because otherwise, you'd abhor doing much work in hardware (that
being hard) in favor of doing it easier-to-debug and also free-to-
have in the shape of LAPACK software. (Subtext message, more for future
readers than for you: Evaluate whether something really should be done
in hardware; it's not inherently better to do things in hardware.)
But that parallelism might imply that in-place is not a feasible way of
computing things, and your memory requirements might be much larger.
Depending on the size of SVD you're planning to do, that might or might
not be an issue.

Best regards,
Marcus

On Fri, 2019-09-06 at 19:05 +0000, Quadri,Adnan via USRP-users wrote:

Hello,

Thanks for your prompt response and sorry for my delayed one.

I have thought about the first option you have discussed, which is to use already implemented SVD but modify it to fit with the nocshell.

As we go down that way, I will update this thread with questions or any significant findings.

Thank you,
Adnan

From: Marcus Müller marcus.mueller@ettus.com
Sent: Friday, September 6, 2019 4:00 PM
To: Quadri,Adnan adnan.quadri@louisville.edu; usrp-users@lists.ettus.com usrp-users@lists.ettus.com
Subject: Re: [USRP-users] RFNoC SVD Block

Hello Adnan,

I'm currently not aware of anyone doing that.

However, since one of the typical applications of beefier FPGAs is math
accelerators for linear algebra problems, it's more than likely someone
did in fact implement an SVD before, and you might just need to connect
it to a nocshell to make it work in RFNoC. There's a lot of interesting
papers out there on SVD implementations for fixed point math on FPGAs,
I think Drexel uni had some interesting stuff for SVD-based channel
estimation for OFDM. I've not seen any code of them, though...

So, from an algorithmic point of view, an SVD isn't too hard. IIRC,
sequential algorithms can work in-place, and thus (for a m×n matrix,
n>m) don't need more than n² space for intermediate and final result
(+2m for index and scale storage if you want to pivot elegantly).

Now, I've not ever implemented more than a C++ QR decomposition (which
is the core algorithm for most EVD problems, which you typically
householder-transform an SVD problem to), so I'm really not competent
to comment on hardware implementations, but chances are you want to
compute a lot of result values in parallel if you're doing it in the
FPGA – because otherwise, you'd abhor doing much work in hardware (that
being hard) in favor of doing it easier-to-debug and also free-to-
have in the shape of LAPACK software. (Subtext message, more for future
readers than for you: Evaluate whether something really should be done
in hardware; it's not inherently better to do things in hardware.)
But that parallelism might imply that in-place is not a feasible way of
computing things, and your memory requirements might be much larger.
Depending on the size of SVD you're planning to do, that might or might
not be an issue.

Best regards,
Marcus

On Fri, 2019-09-06 at 19:05 +0000, Quadri,Adnan via USRP-users wrote:

Thanks! I'm always curious about how our hard- and software
infrastructure is being used!

By the way, in case you want to test a verilog SVD implementation
within a signal processing framework: Bowen Hu did a very interesting
Google Summer of Code project this year, in which he made it possible
to just drop in a Verilog Module in a GNU Radio block and use that to
do signal processing in a pure host computer simulation. He'll be at
GRCon this year!

https://github.com/B0WEN-HU/gr-verilog
</shameless_plug>

Best regards,
Marcus
On Wed, 2019-09-11 at 15:13 +0000, Quadri,Adnan wrote:

This Verilog AXI is so amazing. I just went through the project link quickly.

We can test our verilog implementation on GRC! This will be so helpful.
Thank you so much for sharing the information.

Adnan

From: Marcus Müller marcus.mueller@ettus.com
Sent: Wednesday, September 11, 2019 11:34 AM
To: Quadri,Adnan adnan.quadri@louisville.edu; usrp-users@lists.ettus.com usrp-users@lists.ettus.com
Subject: Re: [USRP-users] RFNoC SVD Block

Thanks! I'm always curious about how our hard- and software
infrastructure is being used!

By the way, in case you want to test a verilog SVD implementation
within a signal processing framework: Bowen Hu did a very interesting
Google Summer of Code project this year, in which he made it possible
to just drop in a Verilog Module in a GNU Radio block and use that to
do signal processing in a pure host computer simulation. He'll be at
GRCon this year!

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_B0WEN-2DHU_gr-2Dverilog&d=DwIDaQ&c=OAG1LQNACBDguGvBeNj18Swhr9TMTjS-x4O_KuapPgY&r=JoNl3b2Pn0MHhs668QvjpcSGl6s3MEmtJLBypH6x02U&m=OAza1LeUx_20PABZFpa8SFpGhqGusnLgCJPv8Qn9IY4&s=RVT10qjiHFS4-MdCMHF5eFq0-VWOEryN7swfWuOKkZI&e=
</shameless_plug>

Best regards,
Marcus
On Wed, 2019-09-11 at 15:13 +0000, Quadri,Adnan wrote:

Hi Adnan,

Take a look to this document
https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_3/ug902-vivado-high-level-synthesis.pdf
.
I feel that HLS is the way to go.
However, if I remember correctly the maximum size of the matrix that is
supported by HLS linpack implementation of the SVD is 8x8.

Just due to my curiosity. Why do not you buffer samples and perform SVD in
the software? (I feel that that will be much easier).

Cheers,

Emil

On Wed, Sep 11, 2019 at 6:45 PM Quadri,Adnan via USRP-users <
usrp-users@lists.ettus.com> wrote: