Set_input_delay misunderstanding

vlsi9, I didn't fully follow your post, but the set_min_delay requirement is a direct override of the hold relationship. Here's the way I think of it:

1) The set_input_delay constraint describes a circuit. It says there is an external register, it says what clock drives that register, what FPGA port it drives, and what the max and min datapath delays are from that register to the FPGA.

2) TimeQuest now sees a register->register path. It sees a launch and latch clock and determines a setup and hold relationship.

3) If you add a set_min_delay assignment, it overrides the hold relationship on that register to register path. But the datapath delay you had in your set_input_delay is still used.

For example, if you have a 10ns clock in the FPGA and 10ns external clock(no shifts), and do:

set_input_delay -min -3.0 -clock virt_clk [get_ports din]

You now have a 0ns hold requirement. The external datapath delay is -3ns, which means inside the FPGA the datapath must be at least 3ns longer than the clock path in order to avoid a hold violation. If you then do:

set_min_delay 1.0 -from [get_ports din]

You've now overriden the hold requirement of 0 and made it 1ns, so the over the whole path, the data must be 1ns longer than the clock. Since externally the datapath delay is -3ns, then inside the FPGA the datapath must now be 4ns longer than the clock.

For the second part about the input port to output port being a don't care, first check if it's being analyzed by doing a report_timing between them. (I can go into details of when or why it would, but the main thing is that you don't want it). If it is being analyzed, or if you just want to make sure it's ignored, just add

set_false_path -from [get_ports RC_Data0] -to [get_ports {RCDataout{31]}]

Of course, what you're doing is just loosening the hold requirement by -6ns, which you may prefer over cutting it.