Embedded Development Tools

[primoz_beltram]

From this forum topic Critical Warning in PlanAhead and AR50430I know that critical warnings related to PS_PORB, PS_CLK and PS_SRSTB can be ignored.

There is also mentioned that this warnings will be probably removed in next tool version.

I am using Vivado 2013.3 and what I see is:

If my top level design is HDL wrapper created by “Create HDL Wrapper” command, then there are no critical warning related to PS_PORB, PS_CLK and PS_SRSTB.

This is for example for design shown in attached Picture1 that was created following UG940 Lab1.

Also the IOReport did not show any connections to PS_PORB, PS_CLK and PS_SRSTB.

This is OK.

But:

If HDL wrapper is not my top level design (our use case is such) then I get critical warnings related to this signals:

[Netlist 29-69] Cannot set property 'iostandard', because the property does not exist for objects of type 'pin'. [/home/primozb/src/svnrepos/myXilinxProgs/verilog_14.7/XY/XY.srcs/sources_1/bd/XY_ps/ip/XY_ps_processing_system7_0_0/XY_ps_processing_system7_0_0.xdc:687]

Resolution: Modify .xdc or RTL to not set this property or move it to a cell that can accept this property

[Netlist 29-69] Cannot set property 'PACKAGE_PIN', because the property does not exist for objects of type 'pin'. [/home/primozb/src/svnrepos/myXilinxProgs/verilog_14.7/XY/XY.srcs/sources_1/bd/XY_ps/ip/XY_ps_processing_system7_0_0/XY_ps_processing_system7_0_0.xdc:688]

Resolution: Modify .xdc or RTL to not set this property or move it to a cell that can accept this property

.....

I copied only couple of lines from this warnings her, to shorten this description. They are all related to PS_PORB, PS_CLK and PS_SRSTB.

In our case we have additional module(s) that is at the same level as PS HDL wrapper, which connects its AXI4 slave to PS exported M00_AXI signals. There are also others signals handled and exported to top level module by our module (but not important for this topic).

Attached Picture2 shows how our XY PS HDL wrapper module looks like.

What is important here is that PS HDL wrapper is not our top module. The DDR, FIXED_IO (VRN, VRP, MIO) and SPI_0 are assigned to our top module exports, the same way as they are in PS HDL wrapper.

Lesson I learned else where is: “Never ignore warnings”, so I always try to analyze warnings and solve them.

Workaround to get rid of this critical warnings (that I have found so far) is to comment out PS_PORB, PS_CLK and PS_SRSTB signals in .../sources_1/bd/XY_ps/ip/XY_ps_processing_system7_0_0/XY_ps_processing_system7_0_0.xdc file and not connect them in our top module.

But I would prefer solution where I don't need to change files that are generated by tools. E.g. I would need to change XY_ps_processing_system7_0_0.xdc every time I re-”Generate Output Products”.

Is there a way to remove references to this PS_PORB, PS_CLK and PS_SRSTB signals, e.g. put some TCL commands in my top level xdc file to disable (remove) references to this signals?

[ezhen · Accepted solution]

In my case this problem was involved by incorrect declaration of IO ports (PS_CLK etc). I declared it as "input" (seems to be quite logical to declare PS_CLK like input :) ) but in the wrapper the IO type is "inout" (suddenly!). Carefully compare IO types of all ports in the wrapper and in your top module. Most probably you have made the same mistake. "inout" looks very similar to "input" :)

[vemulad Xilinx Employee]

moved to embedded board

[gward]

Moved to where exactly? I have a very similar problem with the same 3 PS pins on a Zynq design. Where has this thread been moved to?

[otod3r]

hi，I have the same problem。

write_bitstream ERROR in vivado 2013.4,zedboard.

[Drc 23-20] Rule violation (RTSTAT-1) Unrouted net - 3 net(s) are unrouted. The problem net(s) are arm_system_wrapper_inst/arm_system_i/processing_system7_0/inst/PS_CLK, arm_system_wrapper_inst/arm_system_i/processing_system7_0/inst/PS_PORB, arm_system_wrapper_inst/arm_system_i/processing_system7_0/inst/PS_SRSTB.

what should i do?

[ezhen · Accepted solution]

In my case this problem was involved by incorrect declaration of IO ports (PS_CLK etc). I declared it as "input" (seems to be quite logical to declare PS_CLK like input :) ) but in the wrapper the IO type is "inout" (suddenly!). Carefully compare IO types of all ports in the wrapper and in your top module. Most probably you have made the same mistake. "inout" looks very similar to "input" :)

[primoz_beltram]

It is a problem I had a long time ago, but it is right to close it.

My problem was indeed with incorect declaration of problematic PS pins in my top moudule. When I declare them as:

...

    inout                   FIXED_IO_ps_clk   ,
    inout                   FIXED_IO_ps_porb  ,
    inout                   FIXED_IO_ps_srstb ,
...

the critical warning problem is gone.