usrp-users@lists.ettus.com

Discussion and technical support related to USRP, UHD, RFNoC

View all threads

Re: [USRP-users] Building RFNoC image with default blocks fails, [DRC MDRV-1] Multiple Driver Nets: Net has multiple drivers

CD
Cherif Diouf
Fri, Jan 3, 2020 6:13 PM

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/.

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

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/. 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
BP
Brian Padalino
Fri, Jan 3, 2020 6:25 PM

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:

https://github.com/EttusResearch/fpga/blob/fde2a94eb7231af859653db8caaf777ae2b66199/usrp3/top/x300/rfnoc_ce_auto_inst_x300.v

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: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: https://github.com/EttusResearch/fpga/blob/fde2a94eb7231af859653db8caaf777ae2b66199/usrp3/top/x300/rfnoc_ce_auto_inst_x300.v 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
CD
Cherif Diouf
Fri, Jan 3, 2020 6:41 PM

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

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.com<mailto: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.v<https://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
BP
Brian Padalino
Fri, Jan 3, 2020 6:49 PM

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:

https://github.com/EttusResearch/fpga/blob/fde2a94eb7231af859653db8caaf777ae2b66199/usrp3/tools/scripts/uhd_image_builder.py#L44

Someone at Ettus should probably stop assigning those clocks.

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: https://github.com/EttusResearch/fpga/blob/fde2a94eb7231af859653db8caaf777ae2b66199/usrp3/tools/scripts/uhd_image_builder.py#L44 Someone at Ettus should probably stop assigning those clocks. Brian >