Sorry, just getting back to this post-thanksgiving.
I tried setting the default nettype back to wire on each of these files, but I have the same error. The good news is that I did make a mistake when modifying gray2bin earlier. So, if I set the default nettype to wire at the top of gray2bin, it works. That serves as a workaround, but I’m still not sure the source of this problem. (And since it only fails on my current block, but not the previous one I did, I’m not sure why this issue has suddenly arisen.) Michael H. Rich Electronic Systems Laboratory Georgia Tech Research Institute® Phone: (404) 407-8358 E-mail: [email protected] <mailto:[email protected]> From: Wade Fife <[email protected]> Sent: Saturday, November 20, 2021 3:03 PM To: Rich, Michael <[email protected]> Cc: Rob Kossler <[email protected]>; [email protected] Subject: Re: [USRP-users] Re: Testbench Compile Error I agree, modifying gray2bin is not a great solution. The root of the problem is really in some other file. I did a grep and found these files set the default_nettype without changing it back. Some are testbenches, others are from the fosphor block IP. axis_pyld_ctxt_converter_tb.sv <http://axis_pyld_ctxt_converter_tb.sv> ctrlport_endpoint_tb.sv <http://ctrlport_endpoint_tb.sv> rfnoc_block_null_src_sink_tb.sv <http://rfnoc_block_null_src_sink_tb.sv> f15_avg.v f15_packetizer.v f15_histo_mem.v delay.v f15_maxhold.v f15_wf_agg.v f15_logpwr.vrng.v f15_rise_decay.v f15_binmap.v axi_logpwr.vfifo_srl.v f15_core.v f15_line_mem.v f15_eoseq.v Are you compiling any of those? I'll see if we can update those files so they don't cause problems in the future. If you figure out which file it is, let me know. I don't have any problems when I compile those files, but I might have just lucked out with my compile order. Modifying gray2bin should be a quick way to work around the issue. Any chance you didn't enter it correctly? Make sure you use the backtick ` before default_nettype and that it's before the module declaration in gray2bin.v. Like this: `default_nettype wire Another option is to modify the gray input of gray2bin.v to make the type explicit, by changing "input [WIDTH-1:0] gray," to "input wire [WIDTH-1:0] gray". But this might just move the problem to the next file. https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/control/gray2bin.v#L13 Thanks, Wade On Fri, Nov 19, 2021 at 5:03 PM Rich, Michael <[email protected] <mailto:[email protected]> > wrote: Thanks for the info on how the default-nettype is used. I usually work in VHDL and am not very familiar with Verilog. The testbench SystemVerilog files seem to be set up by default exactly as you’ve said, with “default_nettype none” at the top and “default_nettype wire” at the end. This is the case for both of my testbenches, but only one of them is exhibiting this issue. That said, I tried changing the default-nettype at the top of the offending testbench to wire, but I get the same error. I even tried setting the default-nettype to wire directly in the gray2bin.v file (even though modifying the UHD code didn’t seem like the best approach) and that had no effect either. Any other suggestions? Thank you, Michael H. Rich Electronic Systems Laboratory Georgia Tech Research Institute® Phone: (404) 407-8358 E-mail: [email protected] <mailto:[email protected]> From: Wade Fife <[email protected] <mailto:[email protected]> > Sent: Friday, November 19, 2021 4:34 PM To: Rob Kossler <[email protected] <mailto:[email protected]> > Cc: Rich, Michael <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> Subject: Re: [USRP-users] Re: Testbench Compile Error This means there's a file that set default_nettype to none somewhere. That setting will affect the files that get compiled after it, and in your case gray2bin.v doesn't like it. Like Rob said, you can add "`default_nettype wire" to the top of the file that's having issues and it should compile after that. Check any files you've added to make sure they don't leave the default_nettype as none. The general convention is to put "`default_nettype none" at the top of a file but have "`default_nettype wire"at the end of a file to avoid messing up any other files in the compile. Wade On Fri, Nov 19, 2021 at 1:04 PM Rob Kossler <[email protected] <mailto:[email protected]> > wrote: Are you able to run the testbench for the provided "rfnoc-example" folder? I notice that the gain testbench that is part of this example has the following as the last statement. Perhaps this is needed? `default_nettype wire On Fri, Nov 19, 2021 at 11:53 AM Rich, Michael via USRP-users <[email protected] <mailto:[email protected]> > wrote: I’m trying to run the testbench for a new module I created (UHD4) and I’m getting the following error: INFO: [VRFC 10-2263] Analyzing Verilog file "/home/nvd/uhd/fpga/usrp3/lib/control/gray2bin.v" into library xil_defaultlib INFO: [VRFC 10-311] analyzing module gray2bin ERROR: [VRFC 10-1103] net type must be explicitly specified for 'gray' when default_nettype is none [/home/nvd/uhd/fpga/usrp3/lib/control/gray2bin.v:13] ERROR: [VRFC 10-3594] non-net port 'gray' cannot be of mode input [/home/nvd/uhd/fpga/usrp3/lib/control/gray2bin.v:13] ERROR: [VRFC 10-845] illegal operand for operator ^ [/home/nvd/uhd/fpga/usrp3/lib/control/gray2bin.v:21] ERROR: [VRFC 10-2865] module 'gray2bin' ignored due to previous errors [/home/nvd/uhd/fpga/usrp3/lib/control/gray2bin.v:10] This file seems to compile without issue on my previous testbench, so I’m not sure what the difference would be here. If anyone has any insights into what could be going on I’d greatly appreciate it. Thank you, Michael H. Rich Electronic Systems Laboratory Georgia Tech Research Institute® Phone: (404) 407-8358 E-mail: [email protected] <mailto:[email protected]> _______________________________________________ USRP-users mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ USRP-users mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
