"No output dependent on input pin" error

[Altera_Forum]

Several warnings were generated during compilation, but they all are secondary to the following: 

 Warning: Design contains 1 input pin(s) that do not drive logic  Warning (15610): No output dependent on input pin "CLKOUT"  It looks to me that the syntax for CLKOUT in process "display" is correct, but the compiler doesn't agree. What am I missing?   Thanks for looking at this.

[Altera_Forum]

I don't know vhdl (only verilog). But here is a stab at it. 

 1. It looks like your display process is the only part dependent on CLK_OUT. 2. Its functionality is to ultiimately set a new value in sVID_DWORD. 3. VID_OUT is assigned to sVID_DWORD. 4. VID_OUT is in your entity port list as an output.   Therefore, if you have not assigned VID_OUT to output pins in the higher level module which instantiates this one, the code will be optimized away.   Therefore, this would make sense: Warning: Design contains 1 input pin(s) that do not drive logic   and so would: Warning (15610): No output dependent on input pin "CLKOUT"   I'd check that you have correctly assigned the VID_OUT signal to actual hardware pins on the FPGA.

[Altera_Forum]

Thanks for taking the time to review the file. 

 The du_forum.vhd file you reviewed is the top level entity. I checked the pinout assignments and confirmed that VID_OUT, VCLK, HSYNC, and VSYNC are assigned to pins on the FPGA. All of these should be changed by the process.  It looks like nothing in the process after ELSIF (CLKOUT'EVENT AND CLKOUT='1') is being recognized because these warning messages are generated:  Warning: Output pins are stuck at VCC or GND  Warning (13410): Pin "VCLK" is stuck at GND  Warning (13410): Pin "HSYNC" is stuck at GND  Warning (13410): Pin "VSYNC" is stuck at GND  Warning (13410): Pin "VID_OUT[0]" is stuck at GND  Warning (13410): Pin "VID_OUT[1]" is stuck at GND  Warning (13410): Pin "VID_OUT[2]" is stuck at GND  Warning (13410): Pin "VID_OUT[3]" is stuck at GND  Also, there are warnings that all the RAM nodes, q[], are synthesized away, which is consistent because if the CLKOUT part of the process isn't executed, nothing ever reads the RAM.

[Altera_Forum]

Don't use BUFFER as a top level (or any level for that matter) signal type. 

 VCLK : BUFFER STD_LOGIC; --Video clock  Almost everything in the process is dependent on the VCLK signal. I don't know if this is for sure the issue but you should avoid it.

[Altera_Forum]

I changed VCLK to OUT STD_LOGIC and created a signal to be used instead of VCLK within the process. The signal was assigned to VCLK outside of the process. Unfortunately, it didn't change any of the warning messages that are generated.

[Altera_Forum]

you wrote: 

"It looks like nothing in the process after ELSIF (CLKOUT'EVENT AND CLKOUT='1') is being recognized..."   Is CLKOUT assinged to an input pin (for an external clock), or the output of a PLL in your design?   The obvious way to debug this would be writing a testbench in modelsim. If you do not know how to do this, I would advise learning how to do so.

[Altera_Forum]

CLKOUT is defined as an input pin for an external clock. The name is misleading, but the pin is named after the MPC860 pin to which it is connected.

[Altera_Forum]

I found the problem. The variable v_vid_ctr was defined as an INTEGER RANGE 0 TO 15, but there is the expression (v_vid_ctr>=24) in the process. When I changed the range to 0 TO 31, the warning messages disappeared. 

 Thanks to all who offered suggestions. I appreciate your trying to help.