Discussion and technical support related to USRP, UHD, RFNoC
View all threadsHi Jerrid,
Some hints, for info, I am working with the X310 device, but you can take the big picture.
I previously met such issues, those were related to signal re-definitions.
The file rfnoc_ce_auto_inst_x310.v at lines 19/20 is re-defining the ce_clk/ce_rst signals by assigning to them radio_clk/radio_rst signals. The issue here is that ce_clk is a clock of its own and is already defined in the top block file x300.v at lines 259 and 290. My filepath is rfnoc/src/uhd-fpga/usrp3/top/x300/.
Vivado 2017.4 would just let this pass but when I moved to Vivado 2018.4 the build would each time fail, popping Net having multiple drivers errors.
Changing the ce_clk/ce_rst signals names in the rfnoc_ce_auto_inst_x310.v and modifying this instantiation file accordingly will make the build work. The solution is ok If you are using a different custom instantiation file,.
However, I am not sure that in your case it will help, because your rfnoc_ce_auto_inst_x310.v file is re-created at each build command. So likely anything you update in the file will be dumped at the next build.
Best Regards
Cherif
On Fri, Jan 3, 2020 at 1:14 PM Cherif Diouf via USRP-users <
usrp-users@lists.ettus.com> wrote:
Hi Jerrid,
Some hints, for info, I am working with the X310 device, but you can
take the big picture.
I previously met such issues, those were related to signal re-definitions.
The file rfnoc_ce_auto_inst_x310.v at lines 19/20 is re-defining the
ce_clk/ce_rst signals by assigning to them radio_clk/radio_rst signals.
The issue here is that ce_clk is a clock of its own and is already defined
in the top block file x300.v at lines 259 and 290. My filepath is
rfnoc/src/uhd-fpga/usrp3/top/x300/.
In the 3.15.0.0 code on github I don't see what you're talking about:
Looking at the history of the file, it looked like that might have been
removed way back in 2016 in commit c98bc14fe0ea2c27a5629a24d47915eb7e0b6700.
Jerrid - do you have those lines that Cherif is describing?
Brian
I have this version UHD 3.15.0.git-84-g164d76dc
but the lines are there whenever you use the ./uhd_image_builder.py scripts.
Best Regards
Cherif
From: Brian Padalino bpadalino@gmail.com
Sent: Friday, January 3, 2020 7:25:00 PM
To: Cherif Diouf
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Building RFNoC image with default blocks fails, [DRC MDRV-1] Multiple Driver Nets: Net has multiple drivers
On Fri, Jan 3, 2020 at 1:14 PM Cherif Diouf via USRP-users <usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com> wrote:
Hi Jerrid,
Some hints, for info, I am working with the X310 device, but you can take the big picture.
I previously met such issues, those were related to signal re-definitions.
The file rfnoc_ce_auto_inst_x310.v at lines 19/20 is re-defining the ce_clk/ce_rst signals by assigning to them radio_clk/radio_rst signals. The issue here is that ce_clk is a clock of its own and is already defined in the top block file x300.v at lines 259 and 290. My filepath is rfnoc/src/uhd-fpga/usrp3/top/x300/.
In the 3.15.0.0 code on github I don't see what you're talking about:
https://github.com/EttusResearch/fpga/blob/fde2a94eb7231af859653db8caaf777ae2b66199/usrp3/top/x300/rfnoc_ce_auto_inst_x300.vhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_EttusResearch_fpga_blob_fde2a94eb7231af859653db8caaf777ae2b66199_usrp3_top_x300_rfnoc-5Fce-5Fauto-5Finst-5Fx300.v&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xIsHdXnCRYoK3O7I17CLaka29UJ1VwI3mC9u8FAc7Ss&m=uyt3D3vrCo1sD1ffyQEPYhBW4X1kPu-ydtQoXIbEFIA&s=oWOA1dV-heZzHDmVnnGT9vrXUo3FwHl3BxJ3Eq3s6q0&e=
Looking at the history of the file, it looked like that might have been removed way back in 2016 in commit c98bc14fe0ea2c27a5629a24d47915eb7e0b6700.
Jerrid - do you have those lines that Cherif is describing?
Brian
On Fri, Jan 3, 2020 at 1:41 PM Cherif Diouf C.E.V.Diouf@tudelft.nl wrote:
I have this version UHD 3.15.0.git-84-g164d76dc
but the lines are there whenever you use the ./uhd_image_builder.py
scripts.
Ah, I see it now:
Someone at Ettus should probably stop assigning those clocks.
Brian