Prof. Taylor's Top 10:
Why Your Processor Ain't Workin' in Timin' Simulatin'

Number 10: You used initial statements in your synthesizable verilog
code, instead of using the reset signal.

Number 0F: You wrote code that initializes your register file and
writes 20 times to the same register in one cycle. Probably you used a
for loop too. Urp! Use either extra states in your state machine, or
just initialize registers with some "startup" code in your test
program.

Number 0E: You didn't go through every warning carefully. These things
are lifesavers! 

Number 0D: You didn't wire up all of the inputs to the module, and the
program happily optimized it all away.

Number 0C: You used statements that look like    "reg foo = x;"
Use reset logic to set initial values instead.

Number 0B: You have two always_comb or always_ff @(posedge clk) blocks
that assign to the same variable.

Number 0A: In your always_comb blocks, you don't assign a variable on
every case and/or if/then/else condition.  Every path through the block
should set every variable at least once! (You can put a default set of
assignments at the top of the block -- but unique case statements need defaults 
inside the case.) 

Number 9: You used casex instead of casez, or x's instead of ?.

Number 8: You used = with always @(posedge clk) statements instead of <=.   Say hello
to race conditions in your code! 

Number 7: You copied code from the internet without checking that it's
in the reference 141L slides!  Interesting fact: 80% of computer
science professors have never synthesized the Verilog that they teach
their students and post on the internet! 

Number 6: Because your code doesn't work in behavioral simulation either!

Number 5: You are still trying to convince your teammate that  your
design will work because Java and Verilog are Turing equivalent.

Number 4: You are using exotic clocking techniques such as always_ff
@(negedge clk) or @(negedge clk or foo); last used by Seymour Cray on
a subcontract for Darth Vader in the first Death Star. 

Number 3: Quartus says your design runs at > 200 MHz.  (That's because
it optimized it away due to unconnected module inputs/outputs and all
that's left is two flip flops and a wire.)

Number 2:  You used === and ==!.  More equals must be better, right?

Number 1: Your testbench is supplying a higher clock frequency than the Quartus 
tool said your design runs at. (Try running at one-quarter or lower the reported 
frequency of quartus for debugging. Then when it works, crank up the frequency!)

Or, you are asserting inputs to your design on the negedge, and they are not registered, 
and you didn't specify timing assertions, so the signal is arriving a lot later than the 
CAD tool planned for (assert inputs just after the posedge of the clock, maybe after 
1/20 of a clock period). 

Number 0: Your datapath was actually just a neat graffiti design you
copied off the stall in the second floor bathroom.


Warm regards, and happy hacking!

MBT