cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
12,362 Views
Registered: ‎10-10-2009

Warning Synth 8-4446 all outputs are unconnected....

Jump to solution

On synthesizing nothing other than a Zynq processer with DDR2 memory enabled in Vivaldo 2014.4, I get 155 warnings such as the following:

 

[Synth 8-4446] all outputs are unconnected for this instance and logic may be removed ["d:/Users/Larry/Documents/SwiftControlSystems/Xilinx/SmartMount/SmartMount.srcs/sources_1/bd/MainBoard/ip/MainBoard_processing_system7_0_0/hdl/verilog/processing_system7_v5_5_processing_system7.v":2286]

 

The links are mostly to Verilog "generate" statements for DDR ports in the above referenced verilog file. I don't remember seeing these warnings in previous versions of Vivaldo, but maybe didn't look as hard then.

 

If I go ahead and program my board with the bitstream, the memory test application in SDK runs fine and indicates the DDR memory passes all the tests. So I'm not sure why the warnings.

 

I also get other warnings for the DDR memory:

[Synth 8-689] width (2) of port connection 'DDRDM' does not match port width (4) of module 'PS7' ["d:/Users/Larry/Documents/SwiftControlSystems/Xilinx/SmartMount/SmartMount.srcs/sources_1/bd/MainBoard/ip/MainBoard_processing_system7_0_0/hdl/verilog/processing_system7_v5_5_processing_system7.v":2907]

 

Even though ENET, PJTAG, and FTMD are not used in my desgin, I also get (rational?) warnings for them not being instantiated, similar to the following:

[Synth 8-3848] Net ENET0_GMII_TXD in module/entity processing_system7_v5_5_processing_system7 does not have driver. ["d:/Users/Larry/Documents/SwiftControlSystems/Xilinx/SmartMount/SmartMount.srcs/sources_1/bd/MainBoard/ip/MainBoard_processing_system7_0_0/hdl/verilog/processing_system7_v5_5_processing_system7.v":232]

 

Should I just ignore all these warnings? I'm mostly worried about the DDR connection related warnings. Those don't make sense.

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
19,348 Views
Registered: ‎07-01-2010

Hi,

 

Looking at the warnings, i think these can be ignored as long as your design is functional.

 

I have seen these warning in couple of scenarios and the design is functional and the warning doesn't effect the functionality.

 

Below is the example:

Even though ENET, PJTAG, and FTMD are not used in my desgin, I also get (rational?) warnings for them not being instantiated, similar to the following:

[Synth 8-3848] Net ENET0_GMII_TXD in module/entity processing_system7_v5_5_processing_system7 does not have driver. ["d:/Users/Larry/Documents/SwiftControlSystems/Xilinx/SmartMount/SmartMount.srcs/sources_1/bd/MainBoard/ip/MainBoard_processing_system7_0_0/hdl/verilog/processing_system7_v5_5_processing_system7.v":232]

 

The reason for this is down to HDL coding in the IP. If "some condition" == true we generate some logic but there is no else condition to tie off the signals. This results in synthesis generating a message that the signal is undriven if a user generates the core in that mode.

 

A CR is already in place to fix and reduce the warning.

 

Hope this helps.

 

 

Regards,

Achutha

 

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------

View solution in original post

9 Replies
Highlighted
Community Manager
Community Manager
12,351 Views
Registered: ‎07-23-2012
Definitely these warnings can't be ignored. Can you please share your design to investigate on this issue?

-----------------------------------------------------------------------------------------------
Please mark the post as "Accept as solution" if the information provided answers your query/resolves your issue.

Give Kudos to a post which you think is helpful.
0 Kudos
Highlighted
Moderator
Moderator
12,344 Views
Registered: ‎07-21-2014

Hi,

 

Did you try regenerating the cores?

 

Thanks,
Anusheel
-----------------------------------------------------------------------------------------------
Search for documents/answer records related to your device and tool before posting query on forums.
Search related forums and make sure your query is not repeated.

 

Please mark the post as an answer "Accept as solution" in case it helps to resolve your query.
Helpful answer -> Give Kudos
-----------------------------------------------------------------------------------------------

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
19,349 Views
Registered: ‎07-01-2010

Hi,

 

Looking at the warnings, i think these can be ignored as long as your design is functional.

 

I have seen these warning in couple of scenarios and the design is functional and the warning doesn't effect the functionality.

 

Below is the example:

Even though ENET, PJTAG, and FTMD are not used in my desgin, I also get (rational?) warnings for them not being instantiated, similar to the following:

[Synth 8-3848] Net ENET0_GMII_TXD in module/entity processing_system7_v5_5_processing_system7 does not have driver. ["d:/Users/Larry/Documents/SwiftControlSystems/Xilinx/SmartMount/SmartMount.srcs/sources_1/bd/MainBoard/ip/MainBoard_processing_system7_0_0/hdl/verilog/processing_system7_v5_5_processing_system7.v":232]

 

The reason for this is down to HDL coding in the IP. If "some condition" == true we generate some logic but there is no else condition to tie off the signals. This results in synthesis generating a message that the signal is undriven if a user generates the core in that mode.

 

A CR is already in place to fix and reduce the warning.

 

Hope this helps.

 

 

Regards,

Achutha

 

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------

View solution in original post

Highlighted
Xilinx Employee
Xilinx Employee
12,323 Views
Registered: ‎08-01-2012


This kind of warning genrally occurs if all outputs of an instantiated module (either a synthesizable sub-module or a black box) are loadless, either directly or after logic trimming. 


To avoid this warning, check your design to make sure that all signals are connected properly.
________________________________________________

Please mark this post as an "Accept as solution" in case if it helped to resolve your query. So that it will help to other forum users to directly refer to the answer.

Give kudos to this post in case if you think the information is useful and reply oriented.

0 Kudos
Highlighted
Observer
Observer
12,305 Views
Registered: ‎10-10-2009

Anusheel:

 

   I had updated the IP cores from older Vivado editions before running. But to make completely sure I didn't have anything corrupted, I started fresh, creating a new project with the newly downloaded Vivado 2014.4. I still get the same warnings.

 

These warnings occur with the simplest block diagram, having nothing but a Zynq processor and DDR memory attached.

 

 

0 Kudos
Highlighted
Observer
Observer
12,301 Views
Registered: ‎10-10-2009

@smarell wrote:
Definitely these warnings can't be ignored. Can you please share your design to investigate on this issue?


Note sure how to share the design. What files should I upload?

 

However, the warning occurs with the simplest Zynq block diagram possible, as follows:

 

Using Vivado 2014.4 and create a new project for a Zynq part zc7z10clg225-1.

 

I only place a single IP core: processing_system7_0, version 5.5 in the Block Diagram.

 

I configure the above processor to enable a DDR2 for a MT47H64M16HR-25 memory chip, using the defaults.

I also enable a few other MIO interfaces: Quad SPI flash (for boot, including MIO8 for feedback), UART1, USB0, and SD1 (including MIO9 for CD)

I also enable SPI1 for EMIO but don't add any PL IP cores for this in the block diagram.

The remaining 4 MIO ports (0,7,48,49) are set to GPIO.

I enable the FCLK_CLK0

 

Back in the block diagram, I click the automatic completion option which looks to correctly make the DDR and Fixed_IO ports.

 

On synthesiing, I get the errors indicated.

 

 

 

 

0 Kudos
Highlighted
Observer
Observer
12,298 Views
Registered: ‎10-10-2009

@umamahe wrote:


This kind of warning genrally occurs if all outputs of an instantiated module (either a synthesizable sub-module or a black box) are loadless, either directly or after logic trimming. 


To avoid this warning, check your design to make sure that all signals are connected properly.

I am using the simplest design with only one IP core for processing_system7_0 as mentioned in my previous post.

 

I'm not sure where else to look for a proper connection. The simple block diagram with just this IP core and the ports for DDR and Fixed_IO come up fine when I validate. The expansion of the ports looks correct.

 

I also right click on the block diagram file (*.bd) in the Sources window, and Create the wrapper after all the IP adjustements and port creation, before doing Synthesis and Implementation.

 

0 Kudos
Highlighted
Observer
Observer
12,295 Views
Registered: ‎10-10-2009

@achutha wrote:

Looking at the warnings, i think these can be ignored as long as your design is functional.


   If I export to SDK, run the memory test in the standard application template, and everything passes, does that mean the DDR memory is running fine?

 

   I also adjusted the memory test to check more than just the default 1024 words, up to 30 million in DDR (excluding the BRAM), and it still passes, but takes a bit longer to run - 14 seconds in thiscase.

 

The warning:

[Synth 8-4446] all outputs are unconnected for this instance and logic may be removed ["processing_system7_v5_5_processing_system7.v":2233]

 

links to the second line below in the verilog file referenced above.

 

/// Adding BIBUF for fixed IO Ports and IBUF for fixed Input Ports

BIBUF DDR_CAS_n_BIBUF (.PAD(DDR_CAS_n), .IO(buffered_DDR_CAS_n));
BIBUF DDR_CKE_BIBUF (.PAD(DDR_CKE), .IO(buffered_DDR_CKE));

and also many generate lines such as

genvar i;
generate
    for (i=0; i < C_MIO_PRIMITIVE; i=i+1) begin
        BIBUF MIO_BIBUF (.PAD(MIO[i]), .IO(buffered_MIO[i]));
    end

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
12,285 Views
Registered: ‎07-01-2010

Hi Larry,

 

########################################################################

  If I export to SDK, run the memory test in the standard application template, and everything passes, does that mean the DDR memory is running fine?

########################################################################

 

Yes, the tests indicate that the DDR is fine and as stated in my earlier posts the warnings can be ignored.

 

Currently i see the fix is set to 2015.1 release.

 

Regards,
Achutha

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------
0 Kudos