[USRP-users] Expected FPGA Compatibility number 36, but got 38
Hello All, So I have been working on transitioning to using UHD 4.0 from 3.15, and I am running into a problem. I was able to get the software updated without issue, then I downloaded the new FPGA images using the uhd_image_downloader and updated the two USRP X310's I am working with. After that I tried running one of my flowgraphs in GRC and I get the following: RuntimeError: Expected FPGA Compatibility number 36, but got 38. So do I need to update UHD again to a newer version, or is there a way I can install the older versions of the FPGA Image? Best Regards, Jerrid ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Underruns causing USRP to stop transmitting and receiving
Marcus, The problem seems to be related to running the system with the USRP though. Someone who is working on this project with me is able to run the same embedded python block, without the USRP hardware, and gets no Underruns when doing so. We have also been unsuccessful in finding any useful information regarding potential causes and solutions from GNU Radio and USRP documentation. Best Regards, Jerrid From: Marcus D Leech Sent: Tuesday, October 20, 2020 12:35 PM To: Jerrid Plymale Cc: usrp-users@lists.ettus.com Subject: Re: [USRP-users] Underruns causing USRP to stop transmitting and receiving Probably better served by the discuss-gnuradio list and the chat.gnuradio.org online chat community. Sent from my iPhone On Oct 20, 2020, at 3:30 PM, Jerrid Plymale via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: Hello All, So I am working on writing an embedded python block in GNU Radio Companion to preform some analysis of RF signals that is received by a USRP x310 and transmitted back out of the USRP after analysis has been done. I have been running into some underruns lately that I have not been able to find a solution for. If I execute some of my analysis functions in the work function of the block, the application underruns and it causes the USRP to stop transmitting or receiving. However, if I execute the functions in separate polling functions that are being used to display values in the GUI, I do not get underruns. I think this might has to do with how often the analysis function is being executed, as the poll functions are only called at a rate of 10 Hz which is controlled by a function probe. Can anyone give me suggestions on what to try to fix the underrun problem, and any resources you can point me to that might help would be appreciated. Best Regards, Jerrid ___ USRP-users mailing list USRP-users@lists.ettus.com<mailto: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
[USRP-users] Underruns causing USRP to stop transmitting and receiving
Hello All, So I am working on writing an embedded python block in GNU Radio Companion to preform some analysis of RF signals that is received by a USRP x310 and transmitted back out of the USRP after analysis has been done. I have been running into some underruns lately that I have not been able to find a solution for. If I execute some of my analysis functions in the work function of the block, the application underruns and it causes the USRP to stop transmitting or receiving. However, if I execute the functions in separate polling functions that are being used to display values in the GUI, I do not get underruns. I think this might has to do with how often the analysis function is being executed, as the poll functions are only called at a rate of 10 Hz which is controlled by a function probe. Can anyone give me suggestions on what to try to fix the underrun problem, and any resources you can point me to that might help would be appreciated. Best Regards, Jerrid ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Running multiple USRP x310's on same PC causes network unreachable
Hi All, So I am having an issue with one of the USRP's I am using where it, after running for less than a couple minutes, will lose its network connection to the PC. To be specific, I am running two USRP x310's on the same PC, each is connected to its own 10 Gig Ethernet port on the PC, and both are using different IP addresses. I am running a different GNU Radio Flowgraph on each, one of the USRP's is just transmitting, while the other is both transmitting and receiving. I get two specific errors that pop up when the USRP that is transmitting and receiving loses its network connection to the PC. The following are the errors that are given: [ERROR][UHD] An unexpected exception was caught in a task loop. The task loop will now exit, things may not work. EnvironmentalError: IOError: "IP Address": x300 fw communication failure #1 (will show three of these errors, each one followed by the next error) EnvironmentalError: IOError: x300 fw poke32- reply timed out And sometimes the following is given at the end: EnvironmentalError: IOError: Send error on socket: Network unreachable Anyone know how to fix this issue? Any assistance would be greatly appreciated. Best Regards, Jerrid ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Signal transmission on a USRP X310
Thanks for all the info, I think I am starting to wrap my head around all of this. So I did some more digging and have found some discussions on Transmitter LO leakage (LOL) that suggest creating a cancellation signal by applying dc offsets to the transmitters inputs. By doing this, would this mean that I would need to set up I and Q signal sources in GNU Radio companion that are always on and have to correct dc offset to cancel the LOL signal, or can I apply dc offsets to my signals that I want to be transmitted and whenever I turn them on the LOL signal will be cancelled out? Best Regards, Jerrid Plymale From: Marcus D. Leech Sent: Thursday, August 6, 2020 1:08 PM To: Jerrid Plymale ; Brian Padalino Cc: usrp-users@lists.ettus.com Subject: Re: [USRP-users] Signal transmission on a USRP X310 On 08/06/2020 02:28 PM, Jerrid Plymale wrote: I am seeing a signal strength between -65 and -70 dBm, approximately, even when transmitting all 0’s. Best Regards, Jerrid Plymale Just to get some perspective, those levels are about 6dB *below* the limits of CFR 47 Part 15 for *radiated* power at *3M* from the box. Granted, inconvenient and a pain. From: Brian Padalino <mailto:bpadal...@gmail.com> Sent: Thursday, August 6, 2020 11:08 AM To: Jerrid Plymale <mailto:jerrid.plym...@canyon-us.com> Cc: Marcus D Leech <mailto:patchvonbr...@gmail.com>; usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> Subject: Re: [USRP-users] Signal transmission on a USRP X310 On Thu, Aug 6, 2020 at 2:02 PM Jerrid Plymale via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: It does, and actually it has a strength closer to -70 dBm, I had my markers in the wrong place when I thought the signal was at -100 dBm. If you transmit all 0's with the gain turned all the way down, what strength do you see coming from the radio on the carrier? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Signal transmission on a USRP X310
I am seeing a signal strength between -65 and -70 dBm, approximately, even when transmitting all 0’s. Best Regards, Jerrid Plymale From: Brian Padalino Sent: Thursday, August 6, 2020 11:08 AM To: Jerrid Plymale Cc: Marcus D Leech ; usrp-users@lists.ettus.com Subject: Re: [USRP-users] Signal transmission on a USRP X310 On Thu, Aug 6, 2020 at 2:02 PM Jerrid Plymale via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: It does, and actually it has a strength closer to -70 dBm, I had my markers in the wrong place when I thought the signal was at -100 dBm. If you transmit all 0's with the gain turned all the way down, what strength do you see coming from the radio on the carrier? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Signal transmission on a USRP X310
It does, and actually it has a strength closer to -70 dBm, I had my markers in the wrong place when I thought the signal was at -100 dBm. Best Regards, Jerrid Plymale From: Marcus D Leech Sent: Thursday, August 6, 2020 10:34 AM To: Jerrid Plymale Cc: usrp-users@lists.ettus.com Subject: Re: [USRP-users] Signal transmission on a USRP X310 Does the spur follow the tuned frequency? Sent from my iPhone On Aug 6, 2020, at 1:12 PM, Jerrid Plymale via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: Marcus, Ok that makes sense, I thought it might be something to do with the mixers and leakage, but I wasn’t sure. So I have tried lowering the gain to 0 dB, and there is no change in the signal. The signal does cause problems as I am working on a GPS related application, so even though -100 dBm is a week signal, its still stronger than GPS. Are there any options other than pre-filtering the received signal to mitigate the undesired signal around baseband? Is there a way using hardware I can reduce leakage at the terminal? Best regards, Jerrid Plymale ___ USRP-users mailing list USRP-users@lists.ettus.com<mailto: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
Re: [USRP-users] Signal transmission on a USRP X310
Marcus, Ok that makes sense, I thought it might be something to do with the mixers and leakage, but I wasn't sure. So I have tried lowering the gain to 0 dB, and there is no change in the signal. The signal does cause problems as I am working on a GPS related application, so even though -100 dBm is a week signal, its still stronger than GPS. Are there any options other than pre-filtering the received signal to mitigate the undesired signal around baseband? Is there a way using hardware I can reduce leakage at the terminal? Best regards, Jerrid Plymale ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Signal transmission on a USRP X310
Hello Marcus, I apologize for the delay in response, but I was able to solve the problem I was having with sending a signal at frequencies above 1.3 GHz. Turns out, in one of the two USRP's I am using for my project, I managed to get the cables for TX/RX and the RX2 flipped around when I set everything up (so I had the cable that was connected to the TX/RX hole on the front of the USRP connected to the RX2 terminal on the UBX 40 daughterboard, woops). Now I am able to get a clean signal transmitted without issue. Upon fixing this problem I stumbled on another issue I have been scratching my head over this week without any success. When I turn on the USRP to transmit a signal, and I have muted my signal source blocks in GNU Radio Companion, I am still getting a signal. I have tried using both USRP's and the same thing happens, a signal appears when no signal source is supplying data to the USRP from the PC, and I do not understand why. The signal is about 2.125 KHz off from the center frequency set in the USRP sink block, with a power of roughly -100 dBm measured by the Spectrum Analyzer I have access to. The signal appears even when I have a null source block connected to the USRP sink block. Is this something that can be fixed or worked around? Is this suppose to happen when transmitting using a USRP x310 and a UBX 40 daughterboard? Any suggestions or insight you can provide would be greatly appreciated. Best Regards, Jerrid Plymale ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Signal transmission on a USRP X310
Hello Marcus, The tool I have been using for initial signal quality checking has been the QT Waterfall sink in GNU Radio Companion to see if the signals are looking correct. Upon seeing that it looked like I was loosing data when I set the USRP sink's center frequency above 1.3 GHz, I connected the output of the USRP to a spectrum analyzer to get some more accurate measurements of the signal. After running some tests, I found that at a center frequency less than 1.3 GHz, the strength of the signal was somewhere around -70 dBm. When I would increase the frequency to a value above 1.3 GHz, and no changes to anything else (e.g., channel gain, sample rate), the strength dropped to somewhere around -90 dBm. This was measured by tracking the peak power from an FFT of the signal input to the spectrum analyzer. Would it help to see the flowgraph? Best Regards, Jerrid Plymale ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Signal transmission on a USRP X310
Hello All, So I have been running into some interesting issues lately with using a USRP X310 as a signal generator. I have a UBX 40 Duaghterboard installed in the USRP, and I have been testing sending signals at varying frequencies. I have noticed that I can set the center frequency of the USRP sink block up to about 1.3 GHz, and I can see the sine wave being transmitted and received just fine (1 MHz frequency and 4 MHz sampling rate sine wave), but setting the center frequency any higher causes a loss in data (the spectrogram of the signal looks pixelated and some of the pixels in the signal are much lower that others). I know that the X310 supports up to 6 GHz signals, and I know the PC I am running GNU Radio can handle generating the signal IQ data, so I am at a loss for ideas as to what could be causing the loss of signal data at frequencies greater than 1.3 GHz. Any suggestions or ideas on what I am doing wrong and what I need to change would be greatly appreciated. Best Regards, Jerrid Plymale ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Setting up an X310 as a signal generator
Brian, I realized I forgot to mention, I am using the multi_usrp API and not the RFNoC API, so I am actually unable to use the DRAM FIFO. Do you have any suggestions, or should I work on transitioning the signal generator to an RFNoC installation of UHD? Best Regards, Jerrid From: Brian Padalino Sent: Friday, May 1, 2020 10:28 AM To: Jerrid Plymale Cc: usrp-users@lists.ettus.com Subject: Re: [USRP-users] Setting up an X310 as a signal generator On Fri, May 1, 2020 at 1:23 PM Jerrid Plymale via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: Hello All, So I have been trying to set up a USRP X310 as a signal generator for about a week now, and I’m having some issues. Currently I am using gnuradio-companion to develop the functionality. I have three sets of signal sources that are of float type, creating the I and Q values that get passed to a float to complex block. The output of the three float to complex blocks go to an add block, which then outputs to a USRP sink. Currently, the first problem is with underruns, I’m not getting a lot of them however I am getting breaks in the signal when I pass it to a second USRP X310. What would be the best approach to make sure my signal is coming in strong to the second USRP? I am also having issues with increasing the power of the signal when it is received, is this mainly controlled by the gain value on the USRP source in gnuradio? What can I do to get my incoming signal to have more power? You can try placing a DRAM FIFO in your transmit flow graph as the first thing. That should ensure some tens of milliseconds worth of buffering for your signals and allow for some host jitter without underruns. Do you have an external spectrum analyzer or something that can tell you the power output of the first radio? The receivers should be able to be saturated by your transmitter, so there's definitely a gain issue somewhere. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Setting up an X310 as a signal generator
Brian, Thank you for the quick response! I will try the DRAM FIFO and see if that works. As I am working from home at the moment I do not have access to a spectrum analyzer, Is there anyway I can use any of the QT GUI blocks in gnuradio to determine a rough estimate? I know that the values you set are just values and that you have to determine how they correspond to actual values, but is there a way to do that mathematically? Determining metrics for this project have definitely been a struggle me so far. Best Regards, Jerrid From: Brian Padalino Sent: Friday, May 1, 2020 10:28 AM To: Jerrid Plymale Cc: usrp-users@lists.ettus.com Subject: Re: [USRP-users] Setting up an X310 as a signal generator On Fri, May 1, 2020 at 1:23 PM Jerrid Plymale via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: Hello All, So I have been trying to set up a USRP X310 as a signal generator for about a week now, and I’m having some issues. Currently I am using gnuradio-companion to develop the functionality. I have three sets of signal sources that are of float type, creating the I and Q values that get passed to a float to complex block. The output of the three float to complex blocks go to an add block, which then outputs to a USRP sink. Currently, the first problem is with underruns, I’m not getting a lot of them however I am getting breaks in the signal when I pass it to a second USRP X310. What would be the best approach to make sure my signal is coming in strong to the second USRP? I am also having issues with increasing the power of the signal when it is received, is this mainly controlled by the gain value on the USRP source in gnuradio? What can I do to get my incoming signal to have more power? You can try placing a DRAM FIFO in your transmit flow graph as the first thing. That should ensure some tens of milliseconds worth of buffering for your signals and allow for some host jitter without underruns. Do you have an external spectrum analyzer or something that can tell you the power output of the first radio? The receivers should be able to be saturated by your transmitter, so there's definitely a gain issue somewhere. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Setting up an X310 as a signal generator
Hello All, So I have been trying to set up a USRP X310 as a signal generator for about a week now, and I'm having some issues. Currently I am using gnuradio-companion to develop the functionality. I have three sets of signal sources that are of float type, creating the I and Q values that get passed to a float to complex block. The output of the three float to complex blocks go to an add block, which then outputs to a USRP sink. Currently, the first problem is with underruns, I'm not getting a lot of them however I am getting breaks in the signal when I pass it to a second USRP X310. What would be the best approach to make sure my signal is coming in strong to the second USRP? I am also having issues with increasing the power of the signal when it is received, is this mainly controlled by the gain value on the USRP source in gnuradio? What can I do to get my incoming signal to have more power? Best Regards, Jerrid ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Building and Installing UHD with RFNoC and GNURadio 3.8 from source with Tensorflow 2.0 integration
Hey all, So I need some direction for what I am trying to do as I am not sure that it is even possible. We are using machine learning in the project I am working on, and would like to incorporate that into GNURadio if possible. So I am currently using an anaconda environment set up with python3.7 and Tensorflow GPU 2.0 for the machine learning development. I would like to set up an installation for UHD with RFNoC and GNURadio 3.8 using this conda environment such that it uses python3.7 and has all of the python libraries that the conda environment does (like Tensorflow GPU 2.0). Can anyone point me in the right direction for guides that can help me achieve this or instruct me directly? Is this even possible? Would I have to just set up UHD with the Python API to integrate Tensorflow GPU 2.0 into the script? Any and all insight/information on this topic would be greatly appreciated. Best Regards, Jerrid ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Daughterboard configuration options
Hey All, So I was wondering if anyone could tell me if the UBX Daughterboards are configurable at all, and if so how? For example, looking at the block diagram for the UBX 40 Daughterboard, it seems like some of the clock parameters and filter parameters are that should be controllable but I have not found any documentation on this. If someone can point me in the right direction for this information it would be greatly appreciated. Best Regards, Jerrid ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Building RFNoC image with default blocks fails, [DRC MDRV-1] Multiple Driver Nets: Net has multiple drivers
Hello Cherif and Brian, I did find the clock signal re-definitions you were talking about in *rfnoc_ce_auto_inst_x310.v*, and I did notice that the file is generated by the *uhd_image_builder.py file*, so I looked in the *uhd_image_builder.py* file to find the code that generates *rfnoc_ce_auto_inst_x310.v*. I was able to find the signal re-definitions in the image builder file, lines 43 and 44 I believe, and I changed them there. So far that seems to have fixed the issue and I have successfully been able to build a custom FPGA image. The one thing I have yet to try is building one with a custom RFNoC block. Anyways, thank you for the help and I will post again if I run into any other issues. Best Regards, Jerrid ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] IOError: [Errno 2] No such file or directory - uhd_image_builder_gui crashes when trying to run
Hey Marcus, Thanks for your reply, it reminded me what I needed to do. In the version I am running, the e300 folder has been replaced with the e31x folder, so I just changed the e300 target to e31x in the uhd_image_builder_gui python file and it is working again now. Not sure how to check the version of uhd-fpga repo to tell you the truth. Best Regards, Jerrid ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] IOError: [Errno 2] No such file or directory - uhd_image_builder_gui crashes when trying to run
Hey All,
So I recently started having issues with the uhd_image_builder_gui after doing
a fresh install of UHD and GNU Radio with RFNoC. Below is the output of the
terminal when I try to run the gui. Anyone run into this issue and know how to
fix it?
Traceback (most recent call last):
File "./uhd_image_builder_gui.py", line 656, in
main()
File "./uhd_image_builder_gui.py", line 652, in main
_window = MainWindow()
File "./uhd_image_builder_gui.py", line 71, in __init__
self.init_gui()
File "./uhd_image_builder_gui.py", line 149, in init_gui
self.populate_target('e300')
File "./uhd_image_builder_gui.py", line 608, in populate_target
with open(build_targets) as fil:
IOError: [Errno 2] No such file or directory:
'/home/ck/rfnoc/src/uhd-fpga/usrp3/tools/scripts/../../top/e300/Makefile'
Best Regards,
Jerrid
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Building RFNoC image with default blocks fails, [DRC MDRV-1] Multiple Driver Nets: Net has multiple drivers
Yes, I have just been following the guide on the getting started with RFNoC page. Best Regards, Jerrid From: Brian Padalino Sent: Thursday, January 2, 2020 8:52 AM To: Jerrid Plymale 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 Thu, Jan 2, 2020 at 11:48 AM Jerrid Plymale mailto:jerrid.plym...@canyon-us.com>> wrote: I am trying to generate a custom RFNoC FPGA Image using this version of UHD. OK. So you've checked out fde2a94eb7231af859653db8caaf777ae2b66199 and you're trying to build a regular image with Vivado 2018.3. Correct? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Building RFNoC image with default blocks fails, [DRC MDRV-1] Multiple Driver Nets: Net has multiple drivers
I am trying to generate a custom RFNoC FPGA Image using this version of UHD. Best Regards, Jerrid From: Brian Padalino Sent: Thursday, January 2, 2020 8:44 AM To: Jerrid Plymale 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 Thu, Jan 2, 2020 at 11:42 AM Jerrid Plymale mailto:jerrid.plym...@canyon-us.com>> wrote: Hello Brian, I have installed UHD 3.15.0.0-124-geb448043 And this is what you're trying to build? Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Building RFNoC image with default blocks fails, [DRC MDRV-1] Multiple Driver Nets: Net has multiple drivers
Hello Brian, I have installed UHD 3.15.0.0-124-geb448043 Best Regards, Jerrid ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Building RFNoC image with default blocks fails, [DRC MDRV-1] Multiple Driver Nets: Net has multiple drivers
Hello all,
So I have been attempting to build an X310 HG FPGA image following the steps in
the getting started guide for RFNoC for a while now, and I have been getting
the following error:
Starting DRC Task
INFO: [DRC 23-27] Running DRC with 8 threads
ERROR: [DRC MDRV-1] Multiple Driver Nets: Net bus_clk_gen/inst/CLK_OUT4 has
multiple drivers: bus_clk_gen/inst/clkout4_buf/O, and
radio_clk_gen/inst/clkout1_buf/O.
ERROR: [DRC MDRV-1] Multiple Driver Nets: Net
radio_reset_sync/reset_double_sync/synchronizer_false_path/value[9]_9 has
multiple drivers:
radio_reset_sync/reset_double_sync/synchronizer_false_path/stages[9].value_reg[9][0]/Q,
and
ce_reset_sync/reset_double_sync/synchronizer_false_path/stages[9].value_reg[9][0]/Q.
INFO: [Project 1-461] DRC finished with 2 Errors
INFO: [Project 1-462] Please refer to the DRC report (report_drc) for more
information.
ERROR: [Vivado_Tcl 4-78] Error(s) found during DRC. Opt_design not run.
Time (s): cpu = 00:00:05 ; elapsed = 00:00:02 . Memory (MB): peak = 13791.785 ;
gain = 1.887 ; free physical = 109997 ; free virtual = 117079
INFO: [Common 17-83] Releasing license: Implementation
7 Infos, 0 Warnings, 0 Critical Warnings and 3 Errors encountered.
opt_design failed
ERROR: [Common 17-39] 'opt_design' failed due to earlier errors.
I have attached the build log for those who may want to look at it for more
info. Can someone direct me in what I need to do to resolve this issue so I can
build an FPGA image successfully? any help would be greatly appreciated.
Best Regards,
Jerrid
#---
# Vivado v2018.3 (64-bit)
# SW Build 2405991 on Thu Dec 6 23:36:41 MST 2018
# IP Build 2404404 on Fri Dec 7 01:43:56 MST 2018
# Start of session at: Fri Dec 27 15:38:56 2019
# Process ID: 29400
# Current directory: /home/ck/pybombs-rfnoc/rfnoc/src/uhd-fpga/usrp3/top/x300/build-X310_RFNOC_HG
# Command line: vivado -mode gui -source /home/ck/pybombs-rfnoc/rfnoc/src/uhd-fpga/usrp3/top/x300/build_x300.tcl -log build.log -journal x300.jou
# Log file: /home/ck/pybombs-rfnoc/rfnoc/src/uhd-fpga/usrp3/top/x300/build-X310_RFNOC_HG/build.log
# Journal file: /home/ck/pybombs-rfnoc/rfnoc/src/uhd-fpga/usrp3/top/x300/build-X310_RFNOC_HG/x300.jou
#---
start_gui
source /home/ck/pybombs-rfnoc/rfnoc/src/uhd-fpga/usrp3/top/x300/build_x300.tcl
# source $::env(VIV_TOOLS_DIR)/scripts/viv_utils.tcl
## namespace eval ::vivado_utils {
## # Export commands
## namespace export \
## initialize_project \
## synthesize_design \
## check_design \
## generate_post_synth_reports \
## generate_post_place_reports \
## generate_post_route_reports \
## write_implementation_outputs \
## get_top_module \
## get_part_name \
## get_vivado_mode
##
## # Required environment variables
## variable g_tools_dir$::env(VIV_TOOLS_DIR)
## variable g_top_module $::env(VIV_TOP_MODULE)
## variable g_part_name$::env(VIV_PART_NAME)
## variable g_output_dir $::env(VIV_OUTPUT_DIR)
## variable g_source_files $::env(VIV_DESIGN_SRCS)
## variable g_vivado_mode $::env(VIV_MODE)
##
## # Optional environment variables
## variable g_verilog_defs ""
## if { [info exists ::env(VIV_VERILOG_DEFS) ] } {
## set g_verilog_defs $::env(VIV_VERILOG_DEFS)
## }
## variable g_include_dirs ""
## if { [info exists ::env(VIV_INCLUDE_DIRS) ] } {
## set g_include_dirs $::env(VIV_INCLUDE_DIRS)
## }
## }
## proc ::vivado_utils::initialize_project { {save_to_disk 0} } {
## variable g_top_module
## variable g_part_name
## variable g_output_dir
## variable g_source_files
##
## variable bd_files ""
##
## file delete -force $g_output_dir/build.rpt
##
## if {$save_to_disk == 1} {
## puts "BUILDER: Creating Vivado project ${g_top_module}_project.xpr for part $g_part_name"
## create_project -part $g_part_name ${g_top_module}_project
## } else {
## puts "BUILDER: Creating Vivado project in memory for part $g_part_name"
## create_project -in_memory -part $g_part_name
## }
##
## foreach src_file $g_source_files {
## set src_ext [file extension $src_file ]
## if [expr [lsearch {.vhd .vhdl} $src_ext] >= 0] {
## puts "BUILDER: Adding VHDL: $src_file"
## read_vhdl -library work $src_file
## } elseif [expr [lsearch {.v .vh .sv .svh} $src_ext] >= 0] {
## puts "BUILDER: Adding Verilog : $src_file"
## read_verilog $src_file
## } elseif [expr [lsearch {.xdc} $src_ext] >= 0] {
## puts "BUILDER: Adding XDC : $src_file"
## read_xdc $src_file
## } elseif [expr [lsearch {.xci} $src_ext] >= 0] {
## puts "BUILDER: Adding IP : $src_file"
## read_ip $src_file
## set_prop
