[BD 41-238] Port/Pin property POLARITY does not match between /clk_wiz/reset(ACTIVE_HIGH) and /processing_system7_0/FCLK_RESET0_N(ACTIVE_LOW)

[Xband]

My next strange issue, after "validating design" this is the only error, and seems to not have anything to do with Digilent boards or IP?  Perhaps the order ip was added was an issue.  

Is there a simple "invert" function that can be used as a band aide?  I can see putting the invert before the Zynq processing FCLK.  

AMD support suggests an issue with boot.ini or JTAG setting? 

Found this in AMD support but doesn't really provide a clear solution.  

I seem to encounter a new issue everytime I rebuild the project I'm trying to make, not near having anything work yet, just keep trying a rebuild, is this a common practice? 

Thanks for any insight. 

 

 

https://support.xilinx.com/s/question/0D52E00006lLgyWSAS/polarity-of-reset-issue?language=en_US

[BD 41-238] Port/Pin property POLARITY does not match between /clk_wiz/reset(ACTIVE_HIGH) and /processing_system7_0/FCLK_RESET0_N(ACTIVE_LOW)
 

Edited August 30, 2023 by Xband

[artvvb]

Hi @Xband

I gather from other threads that the particular connection here is from Zynq FCLK0_resetn to a clocking wizard reset input. There are a couple of options for handling the reset polarity after it enters PL:

1. The utility vector logic IP can be used to implement a one-bit not gate for the reset. Vivado will automatically use this IP to invert the polarity of an external reset if the reset polarity param in a clocking wizard preset associated with an external system clock doesn't match the reset's polarity. Vivado doesn't automatically do the same for Zynq reset pins, but it could be inserted manually.

2. The processor system reset IP, usually added by connection automation to ensure proper timing of resets for interconnects and peripherals, provides polarity settings that let it invert all of its inputs and outputs.

3. Easiest, in my opinion: The clocking wizard reset polarity can be configured.

It's also worth pointing out that many of the other IP in your design (all of the AXI stuff, for example) will require active low resets.

The issue you are looking at from AMD support is only relevant if you're trying to use the device without any software running in PS. Is this the case?

Thanks,

Arthur

[JColvin]

Hi @Xband,

I haven't seen this error recently, but usually this is the result of the presumed reset polarity of the processor (Zynq or Microblaze) not matching the polarity of the actual button on the physical device.

If you use the preset for the processor that comes with the Digilent Board Files (some additional instructions on this are available here, https://digilent.com/reference/programmable-logic/guides/installing-vivado-and-vitis#install_digilent_s_board_files, and here, https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi#add_a_processor_to_a_block_design), you'll see that either an invert block has indeed been added to the reset or that expected polarity of the reset in the processor settings has been made to match the physical polarity (it'll change to probably say something like "FCLK_RESET0_N"), which likely just does the exact same thing but is instead hidden away within the black box.

If this doesn't resolve the issue for you, which board are you using and which version of Vivado do you have so we can debug this further?

Thanks,
JColvin

Edit: just learned my answer might not be accurate for the Eclypse board which you are working with. @artvvb will likely have a more accurate answer for you.

[artvvb]

Also, a tangentially related issue I've run into before, the default "single-ended clock capable pin" input source parameter of the clock wizard can lead to critical warnings in the implementation methodology reports. Using "global buffer" ought to resolve it. More info here: https://support.xilinx.com/s/question/0D52E00006hpQy0SAE/ps-clock-as-pll-input?language=en_US

Thanks,

Arthur

 

[Xband]

@artvvb

I think the problem my have popped up because I started the project first adding the Zynq processor and other parts, running the connection automation along the way, then later I added the "clock wizard" ip.  Could have been the root of the issue.  I went back and rebuilt the project again and seem to have avoided this problem so far.  Thanks again for your help.