cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
marascax
Visitor
Visitor
917 Views
Registered: ‎02-12-2020

I don't treat wire as clock but I still get a Poor placement for routing between an IO and BUFG error implementing

Jump to solution

I have a module in Verilog for a counter

module counter (
    input increment,
    input reset,
    output [5:0] count
);
    reg[5:0] current = 6'b0;
    always@(reset or increment) begin
        current <= (reset == 1'b1) ? 6'b000000 : 
            ((increment == 1'b1) ? current + 6'b1 : current);
    end
    assign count[5:0] = current[5:0];
endmodule

I know this error can come from treating the wires as clocks, but I do not use posedge or negedge for reset or increment. I get an implementation error for the increment wire despite this. The schematic shows a BUFG instance with a global clock wire being created and I don't know why that's being generated scheme.PNG

The increment and reset wires are coming from two buttons on the board, their constraints are below. What should I look into to fix this? The board this is for is a PYNQ xc7z020-1clg400c. I can provide more info if needed.

set_property -dict { PACKAGE_PIN D19   IOSTANDARD LVCMOS33 } [get_ports { BUTTONS[0] }]; #IO_L4P_T0_35 Sch=btn[0]
set_property -dict { PACKAGE_PIN D20   IOSTANDARD LVCMOS33 } [get_ports { BUTTONS[1] }]; #IO_L4N_T0_35 Sch=btn[1]
set_property -dict { PACKAGE_PIN L20   IOSTANDARD LVCMOS33 } [get_ports { BUTTONS[2] }]; #IO_L9N_T1_DQS_AD3N_35 Sch=btn[2]
set_property -dict { PACKAGE_PIN L19   IOSTANDARD LVCMOS33 } [get_ports { BUTTONS[3] }]; #IO_L9P_T1_DQS_AD3P_35 Sch=btn[3]
0 Kudos
1 Solution

Accepted Solutions
mike_james_lewis
Contributor
Contributor
888 Views
Registered: ‎09-01-2015

You have a fundamental flaw in your design approach.

Let's call the two buttons you are using in tyour design - button_rst and button_increment.

Do not use these in your always@ statement at all .. instead bring in a clk and reset ... you must have these available in your FPGA environment.

Then things look like ...

module counter (
input clk,
input rst, input button_increment, input button_rst, output [5:0] count ); reg[5:0] count; always@(posedge clk or posedge rst) begin
if (rst) current <= 0;
else begin
if (button_increment) count<= count+1;
else if (button_rst) count<= 0;
else count <= count;
end end endmodule

 

The other thing you'll have to add (and I haven't shown it) is that the two button inputs need to be debounced. Google should supply some useful info on how to do that.

 

Mike

View solution in original post

4 Replies
mike_james_lewis
Contributor
Contributor
889 Views
Registered: ‎09-01-2015

You have a fundamental flaw in your design approach.

Let's call the two buttons you are using in tyour design - button_rst and button_increment.

Do not use these in your always@ statement at all .. instead bring in a clk and reset ... you must have these available in your FPGA environment.

Then things look like ...

module counter (
input clk,
input rst, input button_increment, input button_rst, output [5:0] count ); reg[5:0] count; always@(posedge clk or posedge rst) begin
if (rst) current <= 0;
else begin
if (button_increment) count<= count+1;
else if (button_rst) count<= 0;
else count <= count;
end end endmodule

 

The other thing you'll have to add (and I haven't shown it) is that the two button inputs need to be debounced. Google should supply some useful info on how to do that.

 

Mike

View solution in original post

marascax
Visitor
Visitor
868 Views
Registered: ‎02-12-2020
That makes sense! Thank you!
0 Kudos
u4223374
Advisor
Advisor
825 Views
Registered: ‎04-26-2015

To add to the excellent post above...

 

In a combinational block (ie one that isn't triggered from a clock edge), what you put in the sensitivity list doesn't actually matter during synthesis/implementation. Any signal that's used as an input within the block will trigger it. In this case, "current" is both an input and an output to the block - so every time the block runs, it changes "current", which causes the block to run again, which changes "current" again, which causes the block to run again, and so on...

 

The clock-triggered approach is a far, far better way to do this.

 

0 Kudos
bruce_karaffa
Scholar
Scholar
767 Views
Registered: ‎06-21-2017

The button not only needs to be debounced, but edge detected, otherwise the counter will increment on every clock cycle that the button is depressed.  With only a six bit counter, at normal FPGA clock speeds, this will look like a six bit random number generator without the edge detection.

0 Kudos