Defining Operating Conditions in PD using SoC Encounter

I am using SoC encounter for project. I want to introduce operating conditions into the flow.

1. How these operating conditions are defined?
2. Is it dependent on Synthesis & RTL?
3. On what basis these operating conditions are decided?
4. What is the difference between prePD and postPD netlist?

Answers:
1. Using setOptCond command.
2. No.
3. Normally best case and worst case operating conditions is used for SoC           encounter do timing optimization for setup and hold.
4. PostPD netlist has complete clock tree structure and so more accurate               timing analysis with wire capacitance.

Using the Useful Skew Technique

The useful skew technique improves timing QoR by adjusting the clock arrival times to take advantage of positive slack in the network. Use the skew_opt cmd to automatically perform useful skew analysis and generate the sueful skew constraints.

Skew_opt Details
By default, the skew_opt cmd performs the follwoing tasks:
1) Analyzes the design to determine which paths can be used for useful skew.
ICC looks for paths with positive slack where the slack could be restributed (by adjusting the clock latencies) along the input-to-output paths to improve the overrall design timing.

By default, ICC eveluates only the setup constraints. To consider both setup and hold constraints, specify the -hold option. You can also tighten the setup and hold constraints by specifying the
-setup_margin and -hold_margin options, respectively.

ICC does not adjust the latency on the follwoing types of paths:
1. Paths that loop from a register to itself.
2. Paths that contain level-sensitive latches
3. Combinational paths from in input port to an output port.
4. Paths within interface logic models
Note:
ICC does not adjust the latency on a nonstop pin.  For paths that start or end at nonstop pins ( either implicit or explicit), ICC will only adjust the latency at the other endpoints or startpoints.

By default, there is no limit to the amount of latency adjustment that can be made. To limit the amount of latency adjustment, specify the -adjustment_limit option. To further limit the amount the latency can be decreased, specify the -decrease_factor option.

To disable this analysis and use the existing clock latencies, specify the -no_optimization option.
- Determines the interclock relationships in the design.
ICC analyzes the interclock relationships in the design and uses this analysis to define the interclock delay balancing groups.
- Generates a script file that is used to adjust the clock latencies and set the interclock delay balancing constraints.
The script contains set_clock_latency and set_clock_tree_exceptions -float cmds to adjust the clock latencies and set_inter_clock_delay_options cmds to define the interclock delay balancing groups.
By default, a script is generated if any latency adjustments are identified. If you want to generate a script only if the worst negative slack (WNS) improves by a certain amount, specify the
-improvement_threshold option.
By default, the generated script file is named skew_opt.tcl. To use another file name, specify the
-output option.

- Sources the generated script file to apply the clock latency adjustments and interclock delay balancing constraints.
You can disable sourcing of some of the cmds in the generated script, or of the entire generated script.
     1) To disable sourcing of the set_clock_latency cmds, set the skew_opt_skip_ideal_clocks variable to true before running the skew_opt.
     2)To disable sourcing of the set_clock_tree_exceptions -float cmds, set the skew_opt_skip_propagated_clocks variable to true before running skew_opt.
     3) To disable sourcing of the set_inter_clock_delay_options cmds, set the skew_opt_skip_clock_balancing variable to true before running skew_opt.
     4) To disable sourcing of the entire script, specify the -no_auto_source option when you run skew_opt.

all_connected

all_connected
[-leaf]
single_object_collection_or_object

Returns a collection of all of the objects connected to the specified net, pin, or port.

·    The following command returns a collection of all of the hierarchical ports connected to the net net_1 :
all_connected [get_nets net_1]

The software returns the following information:

TL2/l2_in TL1/l1_out

·    The following command returns a collection that contains only the flattened connection points for the net net_1 :
all_connected -leaf [get_nets net_1]

The software returns the following information:

TL2/L1/RX/D TL1/RX/Q

2 ways to buffer high fanout nets

High fanout nets can be buffered in one or two below ways. The choice depends on if the buffering need to be balanced or not.

1. Using the optDesign command:

EDI using the optDesign command to correct DRVs and timing violations.
The optDesign command does not fix fanout violations by default. To fix fanout violations during optDesign, do the following:

setOptMode -fixFanoutLoad true
optDesign -preCTS


Setting the -fixFanoutLoad option to true will force timing optimization to correct fanout load violations. This method will fix fanout load violations but will not attempt to balance the buffering.

Note: If fanout violations exist after you run the optDesign command, review the *.fanout file that is generated. The remarks column will list a letter code to indicate why a factor violations was not fixed.


2. Buffering a net using the bufferTreeSynthesis command:

The bufferTreeSynthesis command should be used to fix fanout violations if you require the buffer tree to be balanced. Use the bufferTreeSynthesis options to specify the delay and skew constraints along with other desired constraints.
The difference between the buffer tree built by optDesign and the one built by CTS is whether the tool attempts to balance the skew between the endpoints.
For optDesign, we want the tool to build a tree that produces the best timing even if the tree isn't balanced.  For example, if we had a sink in a high fanout tree that was more timing-critical than the others, we would want optDesign to build a tree that delivered the signal to the timing-critical sink earlier than the other sinks.
For CTS, we want the tool to create a tree that balances skew between all of the sinks.  This is desirable in a clock tree scenario because we typically want to minimize skew between registers as a starting point (though we may employ useful skew techniques later where we task the tool to intentionally skew certain registers to improve timing).
For reset trees,  you can allow the tool to use the built-in buffering algorithm of the optDesign command as a starting point.  If you see timing violations arise because of a timing constraint that enforces that the bits in a bus arrive within a certain window, you can seek to build a balanced tree.  If you need to go that route, you can use bufferTreeSynthesis for buffering.

Example Top_Level Implementation Flow with ILMs

1.  prepare the top level verilog file, if needed.

2.  set_analysis_views -setup {module_slowCorner} -hold {module_fastCorner}

3.  Load the config file, including the top-level netlist,  ILM directory name, ilm_blocks.lib

loadConfig fileName
specifyilm -cell block_A -dir ../block_A/block_A ILM
specifyilm -cell block_B -dir ../block_B ILM

4. load the floorplan

loadFPan top_floorplan

5. Place the design
placeDesign

6. Run pre_CTS timing optimization.
optDesign -preCTS

7. Build the clock tree
clockDesign

8. Run post-CTS timing optimization
Or
optDesign -postCTS -hold  ; #optional

9. Route the design
routeDesign

10. Run post-route optimization for setup
optDesign -postRoute

11. Run post-route optimization for setup and hold.
optDesign -postRoute -hold

12. Run post-route optimization for SI
optDesign -postRoute -si

SI and Timing Analysis

1.  Restore the Design
restoreDesign routedSession.dat designname

2.  Import the coupled SPEF file from RCX
spefIn rcx coupled_spef

3. Perform timing analysis in EDI System
timeDesign -postRoute -reportOnly

4. Analysis signal integrity by preforming SI analysis in EDI system.
timeDesign -postRoute -si

5. The following listing is a sample script for signal integrity and timing analysis in EDI system.
timeDesign -postRoute -reportOnly -si