Input/output delay and implementation of sha256 on board

[Iani97]

Hello,

I have been trying to implement a SHA256 alghorithm on my board without success so far. Right now, nothing is failing, but when i enter a letter in TeraTerm to hash, i receive random characters. The UART module works on its own and the simulations give the right results and now i am stuck. I will attach my verilog code and 2 pictures with some timing analysis in the synthesis and implementation part. My question are as follows:

1. No paths are failing, but some of them have some high logic levels and Fanout. Even though the paths are failing, do i need to worry about that? Maybe add some pipeline levels?

2.The only warning i receive is the no_input/output_delay. When i run the UART module on its own, it works without constraining these 2. So my question is as follows: Do i need them? If so, where can i read about them in more detail. I have been looking for that datasheet(i think there should be something about this topic on the datasheet ), but for some reason i cannot find it. I would be very thankful if you can give me some advice.

Thank you in advance!

 

PS: I am relatively new to FPGAs and Verilog, so if you find some mistakes in different parts of the code please tell me!

 

Edited June 26, 2021 by Iani97

[zygot]

It's really unlikely that timing constraints for your UART interface IO pins are causing problems with the results.

A general rule for clock logic is that the delay for combinatorial logic and routing have to be less than the clock period. With no timing guidance, even simple designs can break this rule. Default timing reporting in recent versions of Vivado are almost useless, even with good IO timing constraints. Still, if you learn how to set up the reports properly they can help track down issues. It just isn't as easy a task as the older tools made it.

If your hardware isn't matching your simulations then you need to add some instrumentation to the design to try and figure out why.  Of course, FPGA instrumentation is true to the Heisenburg principal, in that adding logic to see what's going on in a design will alter the synthesis and place and route results, and hence timing.

You could try adding an ILA to your SHA256  core and try to see what might be wrong.  Often a better approach is to have a good user UI that works with serial device terminal programs and allows you to look at internal register states.

Edited May 18, 2021 by zygot

[Iani97]

11 minutes ago, zygot said:

It's really unlikely that timing constraints for your UART interface IO pins are causing problems with the results.

A general rule for clock logic is that the delay for combinatorial logic and routing have to be less than the clock period. With no timing guidance, even simple designs can break this rule. Default timing reporting in recent versions of Vivado are almost useless, even with good IO timing constraints. Still, if you learn how to set up the reports properly they can help track down issues. It just isn't as easy a task as the older tools made it.

If your hardware isn't matching your simulations then you need to add some instrumentation to the design to try and figure out why.  Of course, FPGA instrumentation is true to the Heisenburg principal, in that adding logic to see what's going on in a design will alter the synthesis and place and route results, and hence timing.

You could try adding an ILA to your SHA256  core and try to see what might be wrong.  Often a better approach is to have a good user UI that works with serial device terminal programs and allows you to look at internal register states.

Thank you for your response. I will try adding ILA to SHA256 core and see what happens next