06-04-2016 03:13 AM
Hello, I'm building a large project and I'm using Vivado HLS 2016.1 and my target device Zynq ZC706. When I'm trying to simulate my design with C/RTL Co-Simulation the console keeps showing the following warning:
Warning: OPMODE Input Warning : The OPMODE 0110X0X with CARRYINSEL 000 to DSP48E1 instance is invalid.
Time: 6295685 ns Iteration: 11 Process: /apatb_dev_nonbonded_slow_energy_top/AESL_inst_dev_nonbonded_slow_energy/dev_nonbonded_slow_energy_faddfsub_32ns_32ns_32_4_full_dsp_U65/dev_nonbonded_slow_energy_ap_faddfsub_2_full_dsp_32_u/U0/i_synth/addsub_op/ADDSUB/speed_op/dsp/OP/dsp48e1_body/ALIGN_ADD/DSP2/DSP/prcs_opmode_drc File: C:\Xilinx\Vivado\2016.1\data/vhdl/src/unisims/primitive/DSP48E1.vhd
The C/RTL Co-simulation is very slow and I think that the output of this warning in console makes it even slower.
Can anyone help me understand this warning and how will I make it disappear?
I've attached a printscreen.
Thank you in advance.
P.S. I'm simulating my design about 20 hours and the console keeps spamming this warning.
06-04-2016 11:49 PM
06-05-2016 10:04 AM
06-12-2016 02:29 AM
I've found a thread in a forum about this warning but I don't know how to fix it.
In the reply he suggests the following:
"Origin of this message is uninitialized value of input (control) signal of DSP component. Such warnings can be ignored at simulation time = 0 ns or few clock cycles later. If this message appear through and through then it's error which must be fixed.
To remove this warning set initial value for reported signal."
Does anyone know how to set this initial value?
The thread is the following:
02-07-2017 09:41 PM
Are you using VHDL for cosimulation? If so can you please give it a try with Verilog?
02-08-2017 03:50 AM
Same warning with VHDL cosim with only difference the iteration is now 13 (was 11-12 in Verilog cosim).
Warning: OPMODE Input Warning : The OPMODE 0110X0X with CARRYINSEL 000 to DSP48E1 instance is invalid. Time: 2280755 ns Iteration: 13 Process: /apatb_triangulate2D_top/AESL_inst_triangulate2D/g
rp_insertSite_fu_72/grp_inTriangle_fu_364/grp_ccw_ fu_69/grp_triArea_fu_56/triangulate2D_fsubkb_U2/tr iangulate2D_ap_fsub_2_full_dsp_32_u/U0/i_synth/add sub_op/ADDSUB/speed_op/dsp/OP/dsp48e1_body/ALIGN_A DD/DSP2/DSP/prcs_opmode_drc File: /wrk/2016.4/nightly/2017_01_23_1756540/data/vhdl/s rc/unisims/primitive/DSP48E1.vhd
I am really stuck here! Any ideas?
03-20-2017 12:29 AM
Is this post solved? I am facing this issue with Vivado 2016.4.
I read the suggestion some where that all the variables should be initialized. It allows the co-simulation to pass. However, when I export the IP to Vivado I get faulty results i.e. the IP core does not work as expected. I use chipscope to analyse the results. I suspect the problem is still due to this warning.
03-28-2017 01:10 PM
@aayushntu, I currently have the same warning in my 2016.2 design with the simulation remaining in iterations 11 and 12. I learned that it is not a critical warning, and the co-simulation is still able to complete if you give it enough time.
My design in particular has pointer inputs with large depth values. It takes multiple days for co-simulation to complete, but I don't know yet if it is the design's fault or the warning's. I have not exported the IP to Vivado yet.
04-11-2017 09:31 PM
I am facing same issue and I ended up following this link. Those who had same issue and came up with solution, mention the way you fixed it. I used Verilog for co-simulation in Vivado2016.2 and the VHDL code of DSP481 in Vivado/2016.2/SDSoC is being called, from where this Warning is coming up.
Any suggestions are highly welcomed.
04-12-2017 10:16 AM
I receive this warning in 2016.2, but my simulation is still able to complete. I have not performed a hardware test yet.
04-12-2017 10:21 AM
The co-simulation is being on run for 24 hours now. (After looking at your previous post I gave it a try to run longer). Still the same warning is coming up. Any fix you made when your encountered the problem..
04-12-2017 10:37 AM
No, I did not make any change to my design regarding this warning because I don't know what causes it. I also don't know if my long simulation time is related to this warning or not.
In my top level interface, I have a few AXI master inputs and outputs with depth=5000 each (width of 24-32). Are you also using deep AXI master ports?
10-27-2017 11:50 AM
Same issue here with 2017.2 on Linux
"OPMODE Input Warning : The OPMODE 0110X0X with CARRYINSEL 000 to DSP48E1 instance is invalid."
03-10-2018 03:02 AM
Same error in SDx 2017.2 in Linux. Cosimulating in VHDL and Verilog.
More strange the Latency reported is not the same...
Report: 2917; VHDL: 5399 and Verilo 5428.
The simple algorithm implemented uses Floating Point
05-02-2018 03:01 AM
Same issue here with Vivado HLS version 2017.2 on Windows
Warning: OPMODE Input Warning : The OPMODE 001XXXX with CARRYINSEL 000 to DSP48E1 instance is invalid.
If it's a non-vital warning, is there any method to eliminate the warning message to speed up the co-simulation process??
10-30-2018 02:52 AM
I'm using SDSoC 2017.2 and I'm trying to co-simulate a floating-point design using as board the zc706.
I get the OPMODE Input Warning and I have the feeling that the simulation does not progress.. it's been 22 hours up to now. The same fixed-point version design simulates at about 20 minutes.
Is there any hope, or the only way to check my design is to actually have a zc706 board?
Without proper software tools the hardware is unusable no matter how good and well designed it is.
10-30-2018 05:25 AM
After 1469m52.274s c/rtl co-simulation failed!
I have to wait ONE DAY AND ONE HOUR for the cosim to complete.
Still, I have no idea what went wrong.. my fixed-point design works fine (same code) and csim says my design gives correct results.
So, any suggestions?
11-08-2018 11:02 AM
I had the same problem. This error showed up and RTL cosimulation was taking a very long time.
When configuring RTL cosimulation, select "Setup Only". That worked for me. This option makes RTL cosimulation just generate the files.
11-13-2018 01:33 AM
11-13-2018 05:58 AM
@nansonThe "Setup Only" option does seem to allow co-sim to run. I have the test bench print the results to the screen at runtime, and I do see these results printed to the screen even when "Setup Only" is selected.