Vivado Placement Failure

[MarkSe]

I am having an issue with a very simple Verilog project. I can't seem to figure out what is going on. Hoping that someone here may have some insight or experience.

Quote

 

[Place 30-574] Poor placement for routing between an IO pin and BUFG. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .xdc file to demote this message to a WARNING. However, the use of this override is highly discouraged. These examples can be used directly in the .xdc file to override this clock rule.
    < set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets btnC_IBUF] >

    btnC_IBUF_inst (IBUF.O) is locked to IOB_X0Y13
     and btnC_IBUF_BUFG_inst (BUFG.I) is provisionally placed by clockplacer on BUFGCTRL_X0Y0

 

 

Here is the Verilog.

module fsm(
    input clk,
    input rst,
    input btnC,
    output led
    );
    
    // state decls
    localparam state_off = 0; 
    localparam state_on = 1; 
    
    // state variables
    reg rState;
    reg nextState;
    
    // sequential logic to update the state register
    always @(posedge clk, posedge rst)
    begin
        if (rst) 
            rState <= 0;
        else
            rState <= nextState;
    end

    // Combinational logic to calculate the next state
    always @*
    begin
        case (rState)
            state_off:
                if (btnC)
                    nextState = state_on;
                    
            default:
                if (btnC)
                    nextState = state_off;            
        endcase
    end
    
    // output assignment
    assign led = rState;
    
endmodule

The constraints file is the latest Basys-3-Master.xdc file with the clk, sw[0], btnC and led[0] uncommented. I renamed sw[0] -> rst and led[0] -> led.

## This file is a general .xdc for the Basys3 rev B board
## To use it in a project:
## - uncomment the lines corresponding to used pins
## - rename the used ports (in each line, after get_ports) according to the top level signal names in the project

## Clock signal
set_property PACKAGE_PIN W5 [get_ports clk]
	set_property IOSTANDARD LVCMOS33 [get_ports clk]
	create_clock -add -name sys_clk_pin -period 10.00 -waveform {0 5} [get_ports clk]

## Switches
set_property PACKAGE_PIN V17 [get_ports rst]
    set_property IOSTANDARD LVCMOS33 [get_ports rst]

## LEDs
set_property PACKAGE_PIN U16 [get_ports led]
	set_property IOSTANDARD LVCMOS33 [get_ports led]

##Buttons
set_property PACKAGE_PIN U18 [get_ports btnC]
	set_property IOSTANDARD LVCMOS33 [get_ports btnC]

## Configuration options, can be used for all designs
set_property CONFIG_VOLTAGE 3.3 [current_design]
set_property CFGBVS VCCO [current_design]

 

[MarkSe]

I figured out the solution. It now works as expected. A strange parse of the compiler.

@hamster Unless you have something further to add I fail to see how the button was being used as a clock. It is an input to combinational logic.

[hamster]

Your clock signal is not connected to a pin that connects directly to the FPGAs internal cocking resources. 

If you add the constrain mentioned in the error report the tools will make it work, but due to the extra 'bits and pieces' requires to make this happen performance might be reduced (eg the clock may have extra jitter). 

Should be fine unless you are doing a high performance design. 

 

PS using the button as a clock signal is a bad idea... 

[hamster]

Of, you are using the button as a clock signal because you have inferred a latch. 

 

There are some paths through the logic in the combinatorial block that do not set nextState.

[MarkSe]

17 hours ago, hamster said:

Of, you are using the button as a clock signal because you have inferred a latch. 

 

There are some paths through the logic in the combinatorial block that do not set nextState.

I am not sure what you mean by using the button as a clock signal. The constraints file maps the hardware clock to the clk input. And it maps U18 to btnC which is the default constraint. Can you elaborate on what you mean a little bit further?

I see the issue with not all code paths setting nextState. Thank you for catching that, I've fixed that but it does not fix the placement error.