Hi Leo! Just a few things to add:
> * I see the rfnoc-devel branch on the Github repository hasn't been updated in the last 6 months, and grepping code I've seen you've included "RFNoC stuff" in the maint branch, which is the one I'm currently using. The thing is I don't see the Python scripts to create RFNoC OOT modules anymore. Funny enough, I believe rfnoc-devel branches of uhd and fpga repos were updated earlier this week. Vivado version is bumped to 2017.4 and there's many changes/bug fixes. I'm not totally clear on the differences between branches myself, but I understand the rfnoc-devel branches are the only ones that fully provide the "rfnoc api" that allows users to write/plug in other rfnoc blocks-- which is why you won't see the python scripts there. > is it possible to address directly a certain Crossbar port from the API and send / receive samples from that RFNoC block to the host and back without changing anything within the UHD? (even if the block is not properly "recognized") I would suggest trying to get your block recognized by UHD. The UHD software uses a factory generator to enumerate all blocks on a particular FPGA image, and it also provides a number of other helpful tasks like exposing set/get registers and associating any required C++ software with the fpga block. Another thing to keep in mind: if you want to use the gr-ettus plugins to design flowgraphs in gnuradio-companion, I believe you need *two* blocks in order to send data from Processor -> FPGA -> Processor, but this can be easily resolved by adding a FIFO before or after your block under test. Hope this helps, EJ On Thu, Apr 5, 2018, 4:41 PM Brian Padalino via USRP-users < usrp-users@lists.ettus.com> wrote: > Hey Leo, > > On Thu, Apr 5, 2018 at 3:01 PM, Leandro EchevarrÃa via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hey everybody, >> >> I've begun working on an X310 board, and I need to make modifications to >> the Verilog code to include my own code. My strength is on HDL design, but >> I lack experience on the software part. I've got some questions (in order >> from most urgent to more annecdotical) I'd very much appreciate you'd help >> me with: >> >> * I see the rfnoc-devel branch on the Github repository hasn't been >> updated in the last 6 months, and grepping code I've seen you've included >> "RFNoC stuff" in the maint branch, which is the one I'm currently using. >> The thing is I don't see the Python scripts to create RFNoC OOT modules >> anymore. I've got no worries as to how to integrate my modules inside the >> Verilog (I saw those scripts were somehow about automating instantiation >> code), but I'm a little lost as to WHAT part of the UHD API should I modify >> and recompile in order for a custom RFNoC module to be recognized by the >> host computer and be able to communicate with it. The guides and >> application notes about this also seem to be a little outdated. Any hint? >> > > This repository was the most help to me: > > https://github.com/ejk43/rfnoc-ootexample > > You run everything out of tree, and I think it helps understand the > separation of where code lives. > > The thing to note is that, for UHD, you need to have at least an XML file > in the rfnoc/blocks directory that defines the input/output ports and the > block ID. This is enough to tell UHD about your block, but not much else > like registers. You can implement your own class for controlling your > block all out of tree as well. > > >> * Is the AXI Crossbar configured in any way from the host? Or is there >> just a mapping between the crossbar ports / modules ID and the blocks the >> host understands should be inside the FPGA? Where is the "signal path" >> (i.e.: DBA-RX2 -> DDC0 --> FFT --> host) defined? Understand I've been >> studying the design "upwards", reading first a lot of Verilog code, and I'm >> beginning to explore the API itself. >> * Following the last question: is it possible to address directly a >> certain Crossbar port from the API and send / receive samples from that >> RFNoC block to the host and back without changing anything within the UHD? >> (even if the block is not properly "recognized") >> > > The CHDR has a source and destination that's programmed into the header > and that programs the block itself. This is how each block is addressed > and moves data. > > Something to also note is there is a limit to the number of RFNoC blocks > you can have in the design without making major modifications - I believe > it's 10 or 11, so don't make every small thing it's own block. You should > definitely consolidate into things that make sense. > > Good luck! > > Brian > _______________________________________________ > 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
