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