Below are the basic commands in constraint file.
1. current_instance -- Sets the current instance of design.
Example - /design/ins1/moduleA
2. set_hierarchy_separator -- Specifies the hierarchy separator used in SDC file.
Example -
set_hierarchy_separator .
set_hierarchy_separator /
all_clocks
all_inputs
all_outputs
all_registers -clock CLK1
current_design
create_clock
This will define the clock , simple syntax to define clock is
create_clock -period [get_ports <CLK>]
user can define custom clock also, like define the duty cycle if it is not 50/50. also one can define the multiple rising edge , falling edge within one clock period using -waveform {.. ,..}
create_generated_clock
A generated clock is a clock derived from a master clock. master clock is define using create_clock.
In Design , in clocking architecture, multiple clock can be derived from one master clock, and generated could be a divided version of master clock or could be a multiplier version of master clock. either one can be defined using -multiply_by or -divide_by option.
set_clock_latency
There are two types of clock latency ,
1. source latency - also called insertion delay , this is the delay from clock source to clock definition point.
2. network latency - network latency is the delay from clock definition point to the clock input of flop.
The total clock latency is the sum of both , network latency and source latency.example is given below.
# Rise clock latency on CLK_A is 1ns:
set_clock_latency 1.0 -rise [get_clocks CLK_A]
# Fall clock latency on all clocks is 1.2ns:
set_clock_latency 1.2 -fall [all_clocks]
 |
| clock latency |
set_clock_sense
set_clock_uncertainty
clock uncertainty is the time in clock period which used to model clock jitter and other pessimism factor during the timing analysis.
Example -
set_clock_uncertainty -setup 0.1 [get_clocks CLK_A]
set_clock_uncertainty -hold 0.05 [get_clocks CLK_A]
set_data_check
set_disable_timing
set_false_path
set_ideal_latency
set_ideal_network
set_ideal_transition
set_input_delay
set_max_delay
set_max_time_borrow
set_min_delay
set_multicycle_path (important one)
set_output_delay
set_case_analysis
set_driving_cell
set_fanout_load
set_load
set_max_fanout
set_max_transition
set_operating_condition (optional)
set_clock_groups
You can use either one of option depends on the functionality and clock muxing in design.
physically_exclusive means that particular clocks will never be present physically at the same time , logically_exclusive means particular clocks will be available but will never used at the same time. this helps in crosstalk analysis between the clocks , as if clocks are physically available on board then there will be noise and crosstalk associated with it.
set_false_path is having the same thing as logically_exclusive , either one of them can be used to remove false paths from timing analysis and reports.
1.) Looks like you are mixing set_false_path and set_clock_groups. Both of them are very different and typically you don't need both at the same time in a certain section of the design.
All 3 options i.e. -asyn -phys_excl and -logic_exl will cause no paths to show up. So there is no need for an explicit false path if you are able to use set_clock_groups.
2.) The differenece between -async and -log_excl is in the way, PT handles crosstalk analysis.
If 2 clocks are async, it means that they don't have any phase relationship at all. So instead of using definite timing windows based on arrival times/skew etc, the tool will use infinite timing windows when calculating aggressors and victims,
When you use -logic_excl switch, it still means that no timing paths will show up, however crosstalk analysis will be done with regular timing windows based on arrival times/skew etc.
Practical Example of Timing Constraint like on I2C/SPI/etc
----------------------
