UPDATE: See the end for WHY you disable USB.
Here’s the HOW:
For what that USB_PU line does, let’s take a look at the schematic:
We see the USB D+ line is connected via a 1.5K resistor to USB_PU. Per the USB spec (as described in the Speed Identification section here), if you pull the D+ line to 3.3V (in this case by setting USB_PU to ‘1’), you’re telling the USB host that there’s a USB device present (thus enabling all the handshaking and enumeration that follows).
If you pull D+ low by setting USB_PU to ‘0’ (or ground), you’re signaling there is no (longer) a USB device connected.
(Edit upon edits later…) And if you pore over the page linked above, you’ll see mention of how D- can be used to identify a low speed device. But since D- doesn’t have a pull-up resistor, you don’t have to worry about pulling that line low at all - only the D+ line matters here since the TinyFPGA only identifies as high-speed.
Now for WHY:
If you don’t disable USB (either by omitting the USB_PU setting code or setting it to ‘1’ instead of ‘0’) the device/computer the TinyFPGA is connected to will identify it as a high speed USB device and will try to enumerate it. This will fail unless you’ve got some logic coded in that communicates properly over USB_P and USB_N. In the blinky example, you clearly don’t, so the enumeration will fail. In Windows, if you look in the Device Manager, you’ll see a new “Unknown USB Device (Device Descriptor Request Failed)”… which isn’t the end of the world, but it’s kinda sloppy nonetheless.
Bottom line: it’s better to disable USB by pulling USB_PU low if you’re not actually going to communicate via the USB port.
But how does any of this work to load the firmware over USB? Because there’s the default TinyFPGA bootloader that loads up when you hit the reset button, which contains the USB logic to enumerate as USB. If your code contained similar logic, you too could use the USB port (e.g., as a serial device).
I hope this helps!