Trouble moving from ISE to Vivado

I am trying to port a project from XEM6001 and ISE to XEM7001 and Vivado. I had trouble with the porting, so I decided to try the pipe_test sample program that comes with FrontPanel. Synthesis, implementation, and writing bitfile all run successfully, but with over 200 warnings. Some of them are listed here. No “serious warnings”.

Have I done something wrong that has resulted in these warnings?

(My XEM7001 is on order, so I don’t know if this project works. I only know that all steps were executed successfully.)

[Synth 8-689] width (16) of port connection ‘error_count’ does not match port width (32) of module ‘pipe_in_check’ [“C:/xyz/pipe_test/pipe_test_src/PipeTest.v”:61]

[Synth 8-350] instance ‘mmcm0’ of module ‘MMCME2_BASE’ requires 18 connections, but only 6 given [“C:/xyz/pipe_test/pipe_test_src/okLibrary.v”:56]

[Synth 8-3331] design okBTPipeOut has unconnected port ok1[29] (99 more like this)

[Vivado 12-4702] SLEW is not a supported property on input port(s). Setting is ignored. [“C:/xyz/pipe_test/pipe_test_src/xem7001.xdc”:30] (7 more line this)

[Constraints 18-96] Setting input delay on a clock pin ‘hi_in[0]’ is not supported, ignoring it [“C:/xyz/pipe_test/pipe_test_src/xem7001.xdc”:65]

I should have asked a more pointed question that can be answered without the reader knowing how I set up this project.

When the pipe_test project is correctly executed for the XEM7001 board with Vivado, will the warnings that I mentioned be seen?

Many advanced FPGA designs will have some warnings. It can be fairly difficult if not impossible to work around some of the warnings (such as for unconnected ports on modules). Doing so can also make the code less readable or less adaptable to other projects. As you’ve found it’s also entirely possible for code that builds without warnings on one piece of software to generate a slew of warnings in another.

That’s not to say that warnings should be ignored, if you’re running into problems with some code they can help to narrow down where an issue might be, though even fully working code will likely generate them. With the move to Vivado Xilinx added “Critical Warnings” which generally indicate larger issues that will more likely need to be addressed.