I am not getting output I want in ModelSim - Altera (perhaps something related to timing requirements not being met?)
The output of your simulation doesn't make much sense because it is a gate level netlist (post fitter stage).

What you are seeing in your simulation is a gate level simulation on the optimised netlist. This is where all of the strange named signals have appeared from. The counter value added in ModelSim is dead because it is pre-synthesis signal which doesn't exist in your gate-level netlist.

I assume you are intending to run an RTL simulation rather than a Gate-Level simulation.



Lets have a look at what signals you have.

Because you are only using up to bit 20 of the counter, bits 21 through 32 (its a 33-bit counter) have absolutely no bearing on the design. It doesn't matter what value these bits take, so the tools optimise them away (notice how there are no strange named signals for these bits?).

The remaining bits are converted to fitter generated gate-level signals (*~50_comb, etc.), which do appear to have values, however I can't tell if these are counting because you haven't shown the LSBs of these signals, and the values of these may not make any sense without seeing the post-fitting netlist.

EDIT: I've just run your code through gate level simulation, and the various post fitting signals do count as expected:





If you were to run an RTL simulation, the resulting output would be a whole lot of unknown (x) values, because the design has no starting point.

Synchronous logic should almost always have a reset signal, this reset drives all registers in the design section into a known state. Any stateful logic requires some known initial state in order to know what state to go to next.
If this were an RTL simulation (which I guess is what you intended to run), you would simply see the counter value stuck at xxxxxx because it has no initial value, so adding 1 to an unknown value results in another unknown value.

In this case you would add to your counter as signal called reset (or whatever), which when high sets the value of the counter and state variables to zero using an if-else statement in your always block.



As to why your design is failing timing, Quartus is telling you why:


  Critical Warning (332012): Synopsys Design Constraints File file not found: 'FPGA_Testing.sdc'. A Synopsys Design Constraints File is required by the TimeQuest Timing Analyzer to get proper timing constraints. Without it, the Compiler will not properly optimize the design.


You do not have a Synopsys Design Constraints file. This is a file which tells TimeQuest how fast the various clocks are functioning in your system. Without such a file, TQ simply assumes all clocks run at some default frequency (1GHz if memory serves), and as such the design will undoubtedly fail timing requirements - because you haven't specified any.

Create a file called FPGA_Testing.sdc and add it to your Quartus project. Then add at the very least the lines below. This will get you valid information from TimeQuest.

##############################################################################
# Set resolution and units for timing file:
set_time_format -unit ns -decimal_places 3

##############################################################################
# Create a clock called "yourClockNameHere" (can be whatever you want)
# set its period in nanoseconds, set the waveform as { rise fall },
# and set which port in the design it is.
# The example below describes a 50MHz clock with 50% duty cycle 
# (rise at 0ns, then fall at 10ns) driving the 'clk' top level port
create_clock -name yourClockNameHere -period 20.000 -waveform { 0.000  10.000 } [get_ports { clk }]

# You can make more than one clock if needed.

##############################################################################
# Now that we have created the custom clocks which will be base clocks,
# derive_pll_clock is used to calculate all remaining clocks for PLLs (if any)
# and clock uncertainties.
derive_pll_clocks -create_base_clocks
derive_clock_uncertainty