Replies inline. On Thu, Mar 22, 2018 at 9:48 AM TIMMEN Koen via USRP-users < usrp-users@lists.ettus.com> wrote:
> Hello, > > > > First of all I would like to mention that I am not sure if this is the > right location to ask these type of questions. However, I tried to find > answers to my questions elsewhere but couldn’t find a better suited > location, so I hope I’m not at the wrong address and causing too much > clutter in the e-mail list. > > > > My experience with USRPs is almost nonexistent. Over the last few weeks I > have looked around on the internet, learning about the concepts of FPGAs > and HDL coding and I followed the Getting Started Guide for RFNoC. I am > familiar with signal processing and the required mathematics and I would > like to apply this knowledge in the domain of FPGAs, possibly while using > RFNoC. This, I will be doing within the scope of an assignment that was > given to me: what needs to be done is to set-up a USRP X310 with a real > time signal generation module. Currently, this module is already up and > running on a USRP N210 and all HDL code and host code is available to me. > So all that needs to be done, is to use the existing HDL code and port it > to another device. At least.. that’s how I interpret the task. Like I said, > I am new to the USRP field and I have difficulties approaching it. Where do > I get started? Do I need to know in-depth HDL coding etc. > You will have to have a pretty solid understanding of HDL, yes. Do I have this right -- you inherited an existing N210 HDL design (not the stock code, but a custom build), and you're responsible for porting it to X310? > > > Here are some of the questions I have, I would like to thank anyone who is > kind enough to reply to them in advance for answering: > > · HDL code is device independent, correct? Giving that the new > FPGA has enough available hardware to synthesize the code, it shouldn’t be > a problem to reuse the HDL code on a different device. So my thinking was > that I could simply keep all the code that was created by someone skilled > on the subject and simply create a new device specific image and no changes > would be required. Is this correct or am I too naïve about this? (My > attempts at doing this using Vivado, were useless and I can’t figure out > what I am doing wrong.) > HDL code is nominally device independent, for the simplest cases. In every part which interfaces with actual hardware it will be extremely device-dependent. In the case of the N210 design you have, while the core custom signal processing code which your predecessor created may (or may not!) be easily portable, the surrounding HDL which composes the rest of the design is 100% specific to the N210. > · The existing HDL code is written in VHDL, but upon following > the RFNoC getting started guide, I noticed the rfnocmodtool produces > Verilog skeleton code. Is it also possible to make this work with the code > I currently have or will I have to translate the code into Verilog? > You can wrap VHDL modules into Verilog designs. > · Will RFNoC be a useful tool in fulfilling this task? > Yes, but -- before you go anywhere near RFNoC or any hardware at all, I suggest you spend some time on an intermediate task. That is, creating a testbench with which you can isolate the relevant DSP code, learn how it works, and wrap it into something that can be used in an RFNoC block. You will be best served if you create an AXI4 Stream interface to the DSP code -- if you are lucky, it already uses an AXI4 Stream interface, in which case your job gets easier. Once you have a good understanding of the custom code, and once you have it isolated into a testbench using AXI4 Streams to interface to it, you can wrap it into an RFNoC block fairly easily, and at that point you can use it in an X310 design. > · There are many ready to use RFNoC blocks available through the > ettus open source library. But I have trouble understanding what they are > used for… where can I find a description of these blocks? Normally I would > expect the function of a block written in the code itself. And since I do > not read HDL code that well, the meaning of the code is not directly > obvious to me. > Unfortunately documentation is not RFNoC's strong suit. The code is still the best documentation as to the function of these blocks. > · To close off, I realize that maybe I am too much a beginner to > start this project. In that case, where should I begin? Is a HDL coding > course the place to start? > I think that would be a good place to start! I wouldn't look at that (or anything) as a hard prerequisite. Better to look at it as something which will certainly speed your understanding and get you to a solution faster. Nick > > > Kind regards, > > > > Koen > > > > > _______________________________________________ > 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
