The DE2-115-board has a different layout so the peripherals on the board are connected differently to the fpga than on the DE2-board.
I would suggest that you read up on how the external peripherals are connected (in the manual for the DE2-115-board) and change that pin mapping in Quartus. You will also have to specify the correct model of the fpga as well so that Quartus will know what part to synthesize for.
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
The problem was with the fact that, in order to program the Cyclone, the Programmer needs all devices in the device list and it turns out there is a secondary Max II device that needs to be there as well. I did an Auto-Detect, removed the duplicate Cyclone, and everything worked find from then on.