Numerous things to point out here, but I don't want to start picking apart issues in your code because the bigger issue is methodology, first and foremost.
You should do verification and debug of your code in a test bench in the simulator before you go to the hardware. Always. The simulator is where you have full white box visibility into exactly what in your code is or isn't working the way you expect.
And then after that, as for integration and testing on hardware, it would also be wise to divide and conquer before going for the whole chain end to end. For example, start by just putting out a fixed test pattern from the FPGA to the 7-segment displays, from a constant value set in the FPGA instead of taking input from the MCU. When that's all verified and working, walk backwards to integrate another step in the chain, say like driving a constant value from the MCU to the FPGA, still without taking data from your temp sensor. Etc.
There are also issues with your design approach. Potentially sub-optimal partitioning between the FPGA and MCU.
Doing the decimal modulo and division operations in the FPGA is sub-optimal. These are not trivial operations to implement in logic, they would be fairly resource intensive, and there's no need in your application for them to be particularly fast. And if you did need these operations in the FPGA for some reason, these are not something you would ordinarily code using a simple arithmetic operator, but more likely using pipelined IP. I'm actually not even sure if the synthesis tool will implement those operators for you without complaint. Anyhow, if you have available a couple more bits of I/O between the MCU and the FPGA, it would probably make better sense to handle those operations in the MCU firmware and then send over four BCD digits to the FPGA instead of straight binary. And if you are I/O constrained, then you could serialize the data transfer instead of using a full-width parallel bus, since again, there's no need in this application to be very fast.
Could go down a deep rabbit hole here... don't want to make too many assumptions about what you're trying to do.
So anyway, to reiterate my most important point to your question, taken at its simplest: Start by debugging your code in the simulator, and only then go to hardware and integrate one step at a time!
Occasional Contributor
