The problem is that your "transmission_test" code is written such that it assumes that "is_transmitting" from the UART goes true before the clock edge that follows the assertion of "begin_transmit". It doesn't -- it takes a clock cycle before the UART transmitter moves out of its "idle" state, after which "is_transmitting" is true.
As a result, your "transmission_test" state machine is advancing two states for each byte transmitted, and you see only every other byte at the output of the UART.
There are many minor problems with your code samples, but the main thing you need to fix is to verify that "is_transmitting" has gone true before you advance to the next byte in the message.
This would have been pretty obvious if you had taken the time to simulate this project. I can't overemphasize the importance of simulation in verifying FPGA code. Take the time to get familiar with your simulator and learn how to write good module testbenches.
This is a good example of mismatch in results between simulation and synthesis.
If you will synthesize this code and run a test on FPGA - it will work (at least you'll not see constant hash value). However, in simulation it behaves differently:
always @(*) construct means "evaluate the following block of code any time any of the signals used on the right hand side of the assignment change". In your code these signals are: data_in, poly and hashValue.- If none of the above signals change (which is the case you're describing, right?) - the block will not be evaluated by simulator and the assignments won't be made.
Once again - synthesis tool will produce the correct logic for this code, therefore these kind of bugs are very dangerous.
There correct way to handle this is to define a clock signal and use a sequential always @(posedge clk) construct.
Furthermore, it seems that you have at least two combinatorial loops in your code. Even if they are intended - this is very bad practice. You want to avoid using any synthesizable comb loop.
However, by inspection of your code, it seems that circular reference here is just for convenience - maybe it will not synthesize into comb loop. In this case you have two options:
- Find an equivalent form which does not use circular reference
- Use Verilog
function construct.
The first approach is the correct one - Verilog is not a programming language, and the statements you are using to describe logic must be maximally similar to the inferred logic. However, this approach may be tricky, since many algorithms are written in software forms. Therefore you might use the second approach, in which case the code will look like this (not tested):
always @(posedge clk)
begin
hashValue[15:0] <= calcNewHashValue(hashValue[15:0], poly[15:0], data_in[3:0]);
end
Where calcNewHashValue is the function encapsulating the for loop from your code.
Once again: if synthesis tool warns you about comb loops you mustn't use this design. In this case either think of other algorithmic implementation, or spread the calculation on several clock cycles.
You may also want to read this paper in order to get a deeper understanding of Verilog simulators behavior.
Except for that, your coding style is very bug-prone. As a guideline, I suggest you will define a separate always block for each signal. In other words - just one signal is assigned over in always block. Make exceptions only where you can't handle it other way, and think carefully before each such decision.
Best Answer
There are a few ways to do this. In essence, what you need to do is 'unroll' the shifting part of computing the CRC so that it gets evaluated combinatorially within one clock cycle. One way to do this is with a for loop inside of a combinatorial block. If the polynomial is coming from a register (i.e. it can change at run time), then this is really the only way to do this. However, if the polynomial is coming from a parameter (i.e. determined and fixed at synthesis time) then you can compute what amounts to a matrix transformation that converts the previous CRC state and input data to a new CRC state and shifted output data.
Here is an example of some verilog code that implements the 2nd style, taking an arbitrary polynomial via a parameter: https://github.com/alexforencich/verilog-lfsr/blob/master/rtl/lfsr.v . That code forms the combinatorial core of a CRC module: https://github.com/alexforencich/verilog-lfsr/blob/master/rtl/lfsr_crc.v .