Closed ghost closed 6 years ago
Hello @alionmgriffin , I just tried the gaussianFilter function with the exact settings and version that you have specified, except that my system has Windows-7. I couldn't recreate the issue. Can you check whether you made any modifications in the code? Can you also try for any smaller image size? Are you facing this SIGSEGV for other functions too?
Thanks @bgouthamb , I have not found any other examples that are failing on simulation. Some examples are failing on compilation, synthesis, or co-simulation. I am trying the examples on another Windows 10 machine as well as a Windows 7 and Linux machine. All the tests will be in 2017.4 HLS, due to the OpenCV linking issue in 2018.2, with a clone of the Master branch. Do you have a recommendation on which environment is best for HLS development?
@alionmgriffin Linux is recommended since Windows Vivado HLS is known to have issues during Synthesis, with -std=c++0x flag. Also, OpenCV linking issue doesn't exist in Linux for 2018.1/2018.2.
@bgouthamb Tested in Linux, Windows 7, and another Windows 10. All were successful so, it is an issue with my machine. Have a good day.
System: OS: Windows 10.0.16299 CPU: i7-7820HQ RAM: 16.0 GB HLS Version: 2017.4 XFOpenCV Version: Master branch cloned Sept. 10, 2018, 1629 UTC
Project: Part: ZCU102 (xczu9eg-ffvb1156-2-i) Period: 10 Uncertainty: (blank) Top Level Function: gaussian_filter_accel Test Bench CFlags: -DXFCV_HLS_MODE -I../../../sw/xfopencv/include -std=c++0x Source CFlags: -DXFCV_HLS_MODE -IE:/sw/xfopencv/include -std=c++0x Input arguments: E:/t/xfopencv/gaussianfilter/data/im0.jpg
Issue: The 'guassianFilter' example fails simulation when run in Vivado HLS. Using the default configuration, FILTER_SIZE_3 and NO, the simulation reaches SIGSEGV in the following calls if not commented out:
xf_gaussian_filter.hpp: Line 362: buf[bottom][col] = _src_mat.data[read_index++] Line 413: _out_mat.data[write_index++] = (P0); Line 471: buf[row_ind][col] = _src_mat.data[read_index++]; Line 530: _out_mat.data[write_index++] = (P0);
According to the data and array sizing, there should not be an issue with reading from and writing to the arrays. This leads me to believe that there is another location being effected by the indexing. If so, these calls may not be causing the segfault.