To add to markg@prosensing.com 's response, what he is suggesting is completely correct from the static timing point of view. If an output port has no set_output_delay, then it is not part of a path - a path can only end at a clocked object; in the case of an output port, the "clocked object" is the one "created" by the set_output_delay - it "creates" a clocked object clocked by the clock specified in the -clock option and with a delay specified by the value in the command. So without a set_output_delay, the cells and nets between the final flip-flop (technically the clock pin of that flip-flop) and the output port are not part of a path, and hence will not result in a timing report.
However, the tools have a specific check for unconstrained output ports - the "check_timing" command (which is done as part of the normal flow) will flag these "unconstrained output ports" (which are either a warning or a critical warning - I don't remember which). If these are asynchronous outputs like LEDs, then you can ignore the warning. But many designed are uncomfortable ignoring warnings, so they want to fix them.
To do this, you do two things:
- Put a set_output_delay on the port
- You can use any legal clock and any delay value for the command
- set_output_delay -clock <any_legal_clock> <any_value> [get_ports <name_of_output_port>]
- Set the path (and it is now a path since it is constrained) as false
- set_false_path -to [get_ports <name_of_output_port>]
This, then satisfies the check_timing command and tells the tool that there are no timing requirements on the path.
Avrum
