# hold time violation during FPGA post place and route simulation in modelsim

I am designing a simple encryption circuit on Xilinx Virtex-5 FPGA. I have given the timing constraint in the UCF as below:

NET "clk" TNM_NET = clk;
TIMESPEC TS_clk = PERIOD "clk" 25 ns HIGH 50%;


My design does not have any errors in static timing analysis report after place and route. Part of the report is shown below:

Timing errors: 0  Score: 0

Constraints cover 191219 paths, 0 nets, and 38438 connections

Design statistics:
Minimum period:   9.954ns{1}   (Maximum frequency: 100.462MHz)


However, when I run a post place and route timing simulation in modelsim. It gives me this error and the design does not generate the proper result in the simulation.

# ** Error: /home/rex/opt/Xilinx/10.1/ISE/verilog/mti_se/simprims_ver/simprims_ver_source.v(121020): $hold( posedge CLK:650974 ps, negedge I &&& (in_clk_enable1 != 0):651125 ps, 153 ps ); # Time: 651125 ps Iteration: 0 Instance: /tb/aes_wrapper_0/\aes_fwd_0/aes_fwd_core_inst/CIPHER_RND_1_ARK_ROW_1_4_ARK_COL_1_3_xor_itm_1_sg1 # ** Error: /home/rex/opt/Xilinx/10.1/ISE/verilog/mti_se/simprims_ver/simprims_ver_source.v(121020):$hold( posedge CLK:650974 ps, negedge I &&& (in_clk_enable1 != 0):651125 ps, 153 ps );
#    Time: 651125 ps  Iteration: 0  Instance: /tb/aes_wrapper_0/\aes_fwd_0/aes_fwd_core_inst/CIPHER_RND_1_ARK_ROW_1_4_ARK_COL_1_2_xor_itm_1_sg3_0
# ** Error: /home/rex/opt/Xilinx/10.1/ISE/verilog/mti_se/simprims_ver/simprims_ver_source.v(121020): $hold( posedge CLK:650974 ps, negedge I &&& (in_clk_enable1 != 0):651125 ps, 153 ps ); # Time: 651125 ps Iteration: 0 Instance: /tb/aes_wrapper_0/\aes_fwd_0/aes_fwd_core_inst/CIPHER_RND_1_ARK_ROW_1_4_ARK_COL_1_3_xor_itm_1_sg3_0 # ** Error: /home/rex/opt/Xilinx/10.1/ISE/verilog/mti_se/simprims_ver/simprims_ver_source.v(121019):$hold( posedge CLK:650974 ps, posedge I &&& (in_clk_enable1 != 0):651125 ps, 153 ps );
#    Time: 651125 ps  Iteration: 0  Instance: /tb/aes_wrapper_0/\aes_fwd_0/aes_fwd_core_inst/CIPHER_RND_1_ARK_ROW_1_4_ARK_COL_1_2_xor_itm_1_sg3_2
# ** Error: /home/rex/opt/Xilinx/10.1/ISE/verilog/mti_se/simprims_ver/simprims_ver_source.v(121020): \$hold( posedge CLK:650974 ps, negedge I &&& (in_clk_enable1 != 0):651125 ps, 153 ps );
#    Time: 651125 ps  Iteration: 0  Instance: /tb/aes_wrapper_0/\aes_fwd_0/aes_fwd_core_inst/CIPHER_RND_1_ARK_ROW_1_4_ARK_COL_1_3_xor_itm_3


I only know this is a hold time violation. How do I interpret this error information more precisely? How to solve this problem?

Updates: I tracked the signals that cause the hold time violation. The input pad is connected to some combinational logic before it goes to the DFF which has hold time violation. I assume adding OFFSET IN constraint will solve this problem. How do I determine the right value (??ns) in the OFFSET IN constraint?

OFFSET = IN ??ns BEFORE "clk";

• I'd start by upgrading your tools. 10.1 is a good number of versions behind the current 14.4. Since the hold violation was not reported during synthesis, but modelsim picks it up, there might be an issue with the tools that has been fixed since 10.1 – stanri Apr 3 '13 at 4:26
• Do you recognize the register in the error message? Could you put up some code showing any relevant connectivity? Reading this app note, it says that "At a minimum, every design should have PERIOD, OFFSET IN, and OFFSET OUT constraints.". I don't know if this applies to you, but might want to read this: xilinx.com/support/documentation/white_papers/wp237.pdf – Tim Apr 3 '13 at 4:28
• yeah but ISE 10.1 was one of their better efforts. For Virtex 5 it's fine. @Rex : trace both source and destination points on a failing signal - it is likely that one or the other is not a regular FF (possibly BRAM, mult or I/O pin). Often you need to add timing constraints to cover I/O signals and special function blocks (BRAM used to need its own constraints) – Brian Drummond Apr 3 '13 at 8:58
• Trace where the inputs to this signal come from - if any are external and asynchronous, you will see violations. – Martin Thompson Apr 3 '13 at 15:56
• @StaceyAnne, I agree with Brian, 10.1 is a major software launch along with Virtex-5 series. The lastest version I tried before is 13.1. I do not find anything particularly more useful. – drdot Apr 3 '13 at 20:41