Basys: Buttons btn{RLUD} not valid in sensitivity list

[ButtonUp]

Dear community,

I am trying to trigger an event with the "gamepad" buttons on a Basys3 board using verilog.

always @(posedge btnL, posedge btnR)
begin
   if(btnR) counter = counter + 1;           
   else           
      if(btnL) counter = counter - 1;
end

assign HW_led = counter;  // display counter on 16 board LEDs
    

It seems that the btn Buttons can not be used in the always statement. The error is

[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 btnR_IBUF] >

    btnR_IBUF_inst (IBUF.O) is locked to IOB_X0Y16
     and btnR_IBUF_BUFG_inst (BUFG.I) is provisionally placed by clockplacer on BUFGCTRL_X0Y0

If I replace the always-statement with always @(posedge clk)

then the design works with the side effect that the buttons get triggered many times. However, I want to trigger by a rising edge of the buttons. From my perspective, this makes particular sense in the case of a button.

I tried the suggested set_property.... It works for one button only. The other triggers many time while true. So the warning not to do it seems justified.

Can anyone help.

Thanks in advance,

       Thomas

[zygot]

Mechanical buttons and switches are notorious for "contact bounce". It really doesn't matter how you use the logic state of such an input if you don't account for this.

Neither of your attempts are ideal, but the second one is on the right path. Nonetheless, it would be worth your while to understand what the tools are telling you about how it understands your Verilog code.... and how you understand Verilog sensitivity lists.

There are two approaches to solving your problem.
- You can create a 'de-bounced" version of the button input signal that is guaranteed to have only one leading or trailing edge.
- You can use a state machine to work off of the first logic transition and wait until enough time has passed before being sensitive to the next edge.

How long it takes for a button input signal to be conditioned into a usable form obviously depends on how the user presses and then releases the button. The problem isn't too hard if you use common sense about how you want it to work. For a user interface you might want to ensure 500 ms between button presses, but of course this limits how you can use a button. Regardless, you are constrained by the behavior of the mechanical device. So, the best idea might be to use buttons and switches as initiators of logic sequences rather than as an enable for counting.

One way to de-bounce a button is to use a global clock to detect the first transition from the quiescent state to one that indicates a button press. You can create a single clock-wide pulse as your initiator signal. You'll also want to kick off a counter that ignores further input transitions until it's unlikely that contact bounce is a possibility. Assume that this is 10's or 100's of milliseconds.

Consider that a button press isn't just one event. The user has to initiate opening or closing of a contact switch, and then at some later time release the button and initiate the same thing but in reverse order. So every button press has two sets of contact bounce periods. User's can always cause design issues if your design doesn't restrict potential user behavior with signal conditioning. Edited August 30, 2022 by zygot

[ButtonUp]

The example is supposed to be for an introductory class on FPGA programming. The solution could either be to provide a button module that serves the purpose or simply to explain the problem. In any case, thanks for your clarification about the debounce strategies.

[zygot]

Sometimes it's really hard to differentiate between questions that are classwork and questions from people just wanting to learn modern programmable logic development. Your question was hard to judge, so I tried to provide clear guidance without presenting specific instructions. I really have no idea what you prof might be looking for as an answer for an introductory class, but hopefully I threaded the needle appropriately.

BTW, it's also possible to de-bounce mechanical button states using resistors and capacitors in lieu of digital counters as a time delay. It's still logic... just not binary logic. Before programmable logic, before CMOS and TTL LSI and MSI gate level logic devices there was RTL which used discrete transistors, resistors, capacitors, and inductors to do digital design. The end result might have been a 1 or 0, off or on, but what was between the input and output was analog design. In some ways, nothing has changed except that the complicated stuff has been abstracted away from the designer.

Even simple things turn out to be more complex than one might assume if you don't have experience using them. Edited August 30, 2022 by zygot