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!
Since this is your first FPGA project with this board, there are several things that could be going wrong. (I go through this kind of thing myself with every new development system)
Maybe the board isn't powered -- the Amazon link doesn't say whether this board includes the required 5V DC power supply. If this is anything like the ones on ebay, the board should come already loaded with some code that lights up the LEDs. Normally an FPGA board vendor loads a test program onto the board to prove there are no assembly errors, before they ship the board. So when it is first powered up, I'd expect to see an LED light up.
Maybe the JTAG programmer was connected to the wrong header -- this board has two different 2x5 shrouded headers, one for JTAG loading and the other for SPI platform flash loading.
Maybe the design is actually working? How are you testing it? I know that EP2C5T144 board doesn't have much on/board switches and LEDs. The input and output pins are on dual-row headers. It's easy to mis-count or get the inner row / outer row connection swapped. I looked through your project report files and don't see anything wrong. To test this code, you'd have to connect some wires to your in_1, in_2, in_3 and connect each to either 3.3V or GND. Then go through the "truth table" combinations, and observe the output.
Your example HDL code was correctly translated, based on this part of the log file:
Info (21057): Implemented 7 device resources after synthesis - the final resource count might be different
Info (21058): Implemented 3 input pins
Info (21059): Implemented 2 output pins
Info (21061): Implemented 2 logic cells
This is exactly the resource usage I'd expect for a pair of three-input gates. I also checked through the other reports to see if any of the logic got removed by later stages, but it looks to me like it got through place/route/map and should have ended up in the final configuration bitstream.
On a side note: it's good practice to use net names like "in_1", "out_1" like you used in logic.v, instead of just "1" - "5". Makes it easier to understand what's intended. The pinout report (BasicLogic.pin) would be easier to read if the toplevel net names matched up with your HDL code.
Pin Name/Usage : Location : Dir. : I/O Standard : Voltage : I/O Bank : User Assignment
-------------------------------------------------------------------------------------------------------------
1 : 40 : input : 3.3-V LVTTL : : 4 : Y
2 : 41 : input : 3.3-V LVTTL : : 4 : Y
3 : 42 : input : 3.3-V LVTTL : : 4 : Y
4 : 71 : output : 3.3-V LVTTL : : 4 : Y
5 : 72 : output : 3.3-V LVTTL : : 4 : Y
Suggestion: try an LED blinker project next. Just use a 24-bit counter (clocked by the on-board 50MHz system clock) and the MSB of that counter should blink slow enough you can see it blink, but fast enough you know it's doing something. I've learned the hard way to always include an LED blinker diagnostic on my projects, so I can confirm that the FPGA actually got programmed with valid code.
Best Answer
That ID is from the FPGA itself, and hardcoded, it is used to verify that the FPGA model is exactly as configured because a bitstream for a different model might damage the FPGA (e.g. by trying to drive a pin both high and low at the same time).
Autodetection of ICs on JTAG is unreliable at best. IIRC it is implemented somewhat correctly on the CycloneII, but normally you'd configure the scan chain by hand once and never touch that button afterwards. The default configuration assumes that the chain only goes through the FPGA, which is probably correct for the evaluation board, so programming works for you.
Also, check that you are using the correct programming header. Altera has two different port mappings, one for programming the FPGA's SRAM, one for programming the configuration flash. For development, you want to use the SRAM configuration.