Electronic – Safe amount of current going into the device

Capture the input rather than the counter to see if bounce is your problem. If you have storage scope, use edge trigger to get the capture. Otherwise try adding debounce between Reg1/Reg2 and between Reg4/5.

To implement this use an 8 or 16 element shift register fed from synchronised A. Take the AND and the ~OR from between all the shift register bits, these give you are "all set" and "all clear" signals. Use this as the set and reset of an output register, which would feed REG2. Same for B -> REG 5.

If you find this still glitches you can either try a lower clock, or extend the shift register. Above 16 stages it's probably better to remodel as a binary counter and last-state bit. On each cycle if the state is different from last, reset counter and update last-state. If the counter overflows without being cleared, that's your trigger to set/reset the output.

I think from your question you already understand this, but for clarification, this is my usual terminology:

• Programming implies altering some non-volatile device
• Configuration is what the FPGA does when it starts up - it loads its volatile internal memory from non-volatile external memory.

So, as you surmise, the system needs a non-volatile device of some sort which you program on the production line. To Clarify your comment on the USB blaster, it is not a chip... it's a "pod", so you'd have one for your programming station, not one per board:

Anyway, back to the non-volatile storage options:

• The "Almost-zero-engineering required" approach uses Altera's configuration flash devices, which are JTAG programmable using something like a USB blaster. You just wire them up like the datasheet says, and away you go. They cost more per MBit than other options, though, so are not often used in volume production.

• One more usual approach is a "normal" SPI flash chip. The Cyclone user guide configuration section will list some which are compatible with it, and I believe you can also use the Quartus software to program them via the JTAG of the FPGA they are connected to. More engineering involved, checking you have the right device etc. Also, if you are in volume production, you may not want to be using Quartus on the production line, which which case you may have to provide a separate programming header for the flash chip, and some hardware+software to drive that.

• If you have a microcontroller in your system (even on another board...) you could connect that up to the FPGA's JTAG or configuration pins and store the FPGA bitstream in the micro's flash. More engineering involved as you have to have some software to "boot" the FPGA. however, it can make in-field upgrades easier, as often the micro is set up to receive software upgrades already, whereas updating the flash when it hangs directly off the FPGA is often an "opening the box" experience!