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: > 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.muel...@ettus.com> > *Sent:* Wednesday, September 11, 2019 11:34 AM > *To:* Quadri,Adnan <adnan.qua...@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: > > 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.muel...@ettus.com> > > Sent: Friday, September 6, 2019 4:00 PM > > To: Quadri,Adnan <adnan.qua...@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: > > > Hello, > > > > > > We are trying to perform singular vector decomposition. The idea is > > > to work on an RFNoC block that takes in summation of samples from > > the > > > Radio source and will perform SVD. > > > > > > Is anybody working on something similar? > > > Currently, the RFNoC OFDM synchronizer block has timing constraint > > > issues and can't be used to build FPGA image. > > > > > > Just asking around to get some suggestions/advice and idea if > > working > > > on that Verilog implementation of SVD is something doable and if > > > anybody tried anything similar. > > > > > > Thank you, > > > Adnan > > > > > > > > > _______________________________________________ > > > USRP-users mailing list > > > USRP-users@lists.ettus.com > > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwIDaQ&c=OAG1LQNACBDguGvBeNj18Swhr9TMTjS-x4O_KuapPgY&r=JoNl3b2Pn0MHhs668QvjpcSGl6s3MEmtJLBypH6x02U&m=k37R0Rl_g81NH-S6ItDZuzmUBw5LoTVhKicoMs7QquI&s=wNh-TuGTVEYzPNN0GRzBjYiBuFKVQfG5vjCSdYCEnPY&e= > > > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
