WARNING:Xst:2677 and explicitly unconnected ports in Verilog (alternative to VHDL OPEN)?

sdaau · ‎07-13-2011

Hi all,

I'm trying to use a Verilog module - however, I do not need one of its outputs at the moment, so I wanted to explicitly declare it unconnected - like using the OPEN keyword in a port map in VHDL. So I read in Verilog HDL Syntax And Semantics Part-II that the syntax for explicitly unconnected port is ".pad()" - so I have something like:

versatile_sd_counter wptr1_cnt
(
    // synthesis attribute keep of .q is true;
    .q(),			// explicitly unconnected port
    .q_bin(wq_bin), 
    .cke(wcke),
    .clk(wclk), 
    .rst(wrst)
);

When I try to synthesize this, XST barfs with:

...
WARNING:Xst:2677 - Node <wptr1_cnt/q_4> of sequential type is unconnected in block <my_module>.
WARNING:Xst:2677 - Node <wptr1_cnt/q_3> of sequential type is unconnected in block <my_module>.
WARNING:Xst:2677 - Node <wptr1_cnt/q_2> of sequential type is unconnected in block <my_module>.
WARNING:Xst:2677 - Node <wptr1_cnt/q_1> of sequential type is unconnected in block <my_module>.

... and I'm like: "yeah, I know - I specifically wanted to leave it unconnected" :)

The thing is, I'd like XST to instantiate everything in hardware "as if" something was connected (say, output OBUFs, I guess) - however, I'd just like to keep those output elements "open" for the moment. Would that be possible somehow? As you can see, I tried using "attribute keep", however, that doesn't help much... If that is not possible - is there at least a way to suppress these warnings (without completely removing .q - also from the source of the underlying module?)

Many thanks in advance for any answers,

Cheers!

EDIT: Just found Unconnected Ports | Comp.Arch.FPGA | FPGARelated.com, and judging by the sentiment there, it is likely not possible to suppress these warnings :( Can anyone confirm that?

EDIT2: Just found unused wires and VHDL architectures (comp.lang.vhdl), and thought I should try adding a dummy signal, so I did:

// synthesis attribute keep of unconnected1 is true;
wire [8:0] 	 unconnected1; // dummy - unused/unconnected hack
...
(
  .q(unconnected1),		// 
...

... and without the attribute keep, I get "WARNING:Xst:646 - Signal <unconnected1> is assigned but never used. This unconnected signal will be trimmed during the optimization process." in addition to the usual warnings - and with the attribute keep, I get:

WARNING:Xst:1580 - Signal  with a "KEEP" property is assigned but never used. Related logic will not be removed.

AAAAHH!!! I know, I put it there myself ! :/ Is there any way to keep the sythesizer happy about this kind of situation? (on the good side, at least now I get only one warning to wade through, instead of multiple ones). Maybe there exists "attribute ignore WARNING:Xst:XYZ" :) ?

gszakacs · ‎08-14-2007

I see you've pretty much answered your own questions.

Some notes:

XST does not "barf" with the unconnected port, it's only a warning. XST gives the same

warning about unconnected ports in VHDL even when you use the "open" keyword.

You can filter warnings in the GUI, either individual instances of warnings, like

WARNING:Xst:2677 - Node <wptr1_cnt/q_4> of sequential type is unconnected in block <my_module>.

Or classes of warnings, like XST:2677.

Using KEEP attributes will help you see how much logic you've defined so far in an

unfinished project, but can cause DRC errors in bitgen if you don't get rid of them

in the final version you will load into the hardware.

-- Gabor

sdaau · ‎07-13-2011

Thanks for the answer, @gszakacs !

Sorry about the use of "barf" - I intended it to mean just "outputs a message not to my liking" :) (didn't intend that to mean error)

By the way, I just found this thread: WARNING:Xst:647 again - Xilinx User Community Forums, where the issue of filtering warning messages is discussed in more detail... Just like there, I'd also wish for a pragma or an attribute to instruct the command line tools to filter warnings from source code (as it would be better documented) - but I'll have to live with the GUI filtering...

gszakacs wrote:

Using KEEP attributes will help you see how much logic you've defined so far in an

unfinished project, but can cause DRC errors in bitgen if you don't get rid of them

in the final version you will load into the hardware.

Many thanks for this note - I would have definitely missed this at a later stage....

Cheers!

rcingham · ‎09-09-2010

A feature that is available in the corresponding tool from a competing vendor is the ability to selectively change, for instance, certain classes of Warning to Info...

------------------------------------------
"If it don't work in simulation, it won't work on the board."

gszakacs · ‎08-14-2007

gszakacs wrote:

Using KEEP attributes will help you see how much logic you've defined so far in an

unfinished project, but can cause DRC errors in bitgen if you don't get rid of them

in the final version you will load into the hardware.

Many thanks for this note - I would have definitely missed this at a later stage....

I should also mention that it is still possible to build a bitstream file even when there are

DRC errors. You can turn off DRC in the bitgen options. Generally the extra logic with no

loads on its outputs should not hurt the operation of the device.

-- Gabor

bassman59 · ‎02-25-2008

rcingham wrote:
A feature that is available in the corresponding tool from a competing vendor is the ability to selectively change, for instance, certain classes of Warning to Info...

At least for VHDL, it shouldn't even be a warning. If the user is competent enough to use the open keyword on a port map, the tools should honor it and not bother with spurious warnings.

----------------------------------------------------------------
Yes, I do this for a living.

sdaau · ‎07-13-2011

Hi all,

bassman59 wrote:

rcingham wrote:
A feature that is available in the corresponding tool from a competing vendor is the ability to selectively change, for instance, certain classes of Warning to Info...

At least for VHDL, it shouldn't even be a warning. If the user is competent enough to use the open keyword on a port map, the tools should honor it and not bother with spurious warnings.

I just wanted to note that what is a good workaround for me, turned out to be the use of the filtering messages XML file filter.filter as an argument to, say, xst - in that case, warning messages seem to be filtered also from the stdout and the *.syr text report... (more in WARNING:Xst:647 again - Xilinx User Community Forums)

gszakacs wrote:

I should also mention that it is still possible to build a bitstream file even when there are

DRC errors. You can turn off DRC in the bitgen options. Generally the extra logic with no

loads on its outputs should not hurt the operation of the device.

Thanks for this note - intuitively, that is exactly what I would expect from an OPEN keyword: the associated logic is instantiated, so it counts toward resource usage; however, given its unconnected, it simply wouldn't (shouldn't) influence the operation of the device... Nice to see this confirmed.

Cheers!

Sign In

Don't have a Xilinx account yet?

Synthesis

WARNING:Xst:2677 and explicitly unconnected ports in Verilog (alternative to VHDL OPEN)?

Re: WARNING:Xst:2677 and explicitly unconnected ports in Verilog (alternative to VHDL OPEN)?

Re: WARNING:Xst:2677 and explicitly unconnected ports in Verilog (alternative to VHDL OPEN)?

Re: WARNING:Xst:2677 and explicitly unconnected ports in Verilog (alternative to VHDL OPEN)?

Re: WARNING:Xst:2677 and explicitly unconnected ports in Verilog (alternative to VHDL OPEN)?

Re: WARNING:Xst:2677 and explicitly unconnected ports in Verilog (alternative to VHDL OPEN)?

Re: WARNING:Xst:2677 and explicitly unconnected ports in Verilog (alternative to VHDL OPEN)?