Buttons refuse to behave as (I would) expect

[bytter]

So, my BlackIce MX arrived today on the mailbox And after my previous experience of having ISE running in a virtualised Windows environment, being able to do everything from within VSCode and MacOS is a bliss! Thanks @Folknology for this wonderful board

Anyway, I was doing some sanity checking on the board (which of course includes the mandatory blink example), when I've found @lawrie open ebook. There, he explains that two of the included buttons are hardwired to the blue (49) and green (52) led. Looking at the schematics, the buttons connect to GND, so they are active low. The example @lawrie gives thus make sense; my top module is:

module chip (
  output yellow_led,
  input  button1
);

  assign yellow_led = button1;

endmodule

... with this .PCF:

set_io clk 60

set_io yellow_led 55
set_io -pullup yes button1 52

When the button is not pressed, the internal pull-up resistor keeps button1 high. Once it's pressed, both PIN52 and the green led now have a path to GND, thus registering LOW and making PIN55 (the yellow led) LOW too. Right?

The pickle is, that's not what happens: both button 1 and 2 make the yellow led turn on, and it is kept on.

However, handling (literally putting my hands on the board), tends to turn it off. This is probably because my fingers touch a specific contact on the pin header, and thus turn the signal off; which is confusing for me, because a potential GND connection from my hands would actually turn it on, not off. Further handling do not turn it on.

So my question is: what is wrong? my (@lawrie) code or my board?

Thx!

P.S. Debouncing problems?

[bytter]

Actually, even after going through the section about debouncing, and implementing the counting example in @lawrie's ebook, the three leds refuse to count after any amount of button pressing

[lawrie]

Are you using nextpnr rather than arcache-pnr? @Folknology found that you needed both the -pullup yes and nextpnr for the buttons to work correctly, and I confirmed that. Note that -pullup yes is needed even though there is already a hardware pullup resistor.

[bytter]

Yep, right on spot... I was still using arachne-pnr. Changed to nextpnr and everything now works smoothly

[Aclassifier]

Note that -pullup yes is needed even though there is already a hardware pullup resistor.

Is this because the external pullup is a LED (and a 1k serial resistor) and then it won't be able to pull very well "up"? (A LED would typically have 3V forward drop, and the leakage current through it is not anything one should count on.)

In the case where there is an external 10k pullup then the -pullup would not bee needed I assume?

Update: I see in @lawrie's text (here) that we agree on the rationale for -pullup on the IceCore board with the LED without a real pullup. But my question still stands: a real external pullup is enough to not need -pullup?

Another matter: I see in Monk's book that they use constructs like:

NET "switch_up" LOC = "P137" | PULLDOWN;

for their "user constraints file" (UCF - for Xilinx). Any idea why arachne-pnr would have a different format than this? Kind of not very portable.. And, does next-pnr have the same pcf syntax as arachne-pnr? (I have a feeling it does)

[rpflaum2000]

Constraint file formats are not portable between FPGA vendors such as Xilinx, Intel(Altera) and Lattice.

[Folknology]

Is this because the external pullup is a LED (and a 1k serial resistor) and then it won't be able to pull very well "up"? (A LED would typically have 3V forward drop, and the leakage current through it is not anything one should count on.)

Yes it's like a 1v swing which is not enough.

In the case where there is an external 10k pullup then the -pullup would not bee needed I assume?

If you have a physical pullup resistor then '-pullup' is not required.

[Aclassifier]

Thanks, @Folknology fill-20