Saturday, January 27, 2018

Clocks

set_clock_uncertainty -setup 0.2 [get_clocks  SYSCLK]
set_clock_uncertainty -hold 0.05 [get_clocks  SYSCLK]

For setup, uncertainty means the effective clock period is reduced by that amount.
For Hold, uncertainty is the extra timing margin that need to be satisfied

What are the components of clock uncertainty:
-        Clock jitter, any pessimism, PLL uncertainty
-        Generally, we take 10-15% of clock period
-        Will make it zero/reduce while sign-off

Inter clock uncertainty:
set_clock_uncertainity  -from  VIRTUAL_CLK   -to   SYS_CLK  -setup  0.2

set_clock_uncertainity  -from  VIRTUAL_CLK   -to   SYS_CLK  -hold   0.05

Clock Latency:
Total clock latency = Insertion delay + network delay

Source delay (insertion delay):
-        Delay from clock source (PLL) to the clock definition point.

Network delay:
-        Delay from Clock definition point to the CK pin (clock pin of the FF)

set_clock_latency 1.8 -rise [get_clocks MAIN_CLK]
set_clock_latency 1.8 -fall [get_clocks MAIN_CLK]

set_clock_latency   0.8 [get_clocks MAIN_CLK]                          # Specifying only network latency
set_clock_latency   0.8 [get_clocks MAIN_CLK]  -source            #specifying only source latency

Important difference b/w source and n/w latency:
-        Once CTS is built (Post CTS), n/w delay can be ignored
o   Assuming set_propogated_clocks for this clock is defined. So, PT calculates the network delay. Use switch full_clock_expanded to report_timing command to see this delay.
o   But, source latency is there always even CTS is built and needs to be considered
-        So, Before CTS is built (PRE-CTS), network delay is an estimate of the delay of clock tree prior to CTS


List of STA Topics

List of STA Topics:

Constraints
ECO Fix
Timing signoff


How to setup STA environment
Constraints generation
- Clocks
- IO timing characteristics
- Timing exceptions
      False path, multi cycle paths
Constraints Validation




Constraints - brief commands from start to end

Clock commands:

Creating clock:
Setting clock attributes:
Defining relationship b/w clocks: 

create_clock
clock_input_transition
clock_uncertainity
clock_inter_clock_uncertainity
create_generated_clock
set_clock_groups  -from CLK1 -to CLK2  asynchronous


1. What is the difference b/w commands? Are they exactly same?
    a) set_clock_groups  -from CLK1 -to CLK2  asynchronous
   b) set_false_path  -from  CLK1  -to  CLK2
       set_false_path  -from  CLK2  -to  CLK1

Intel interview

1. What are different types of constraints and tell me with basic commands?

2. ECO - what the basic flow? Which order do you fix?

3. Scenario:
          In the data path, there is max cap violation and setup violation trade-off i.e., once you fix max cap violation, setup violation is happening. How do you handle this scenario?
Ans:  Fix max cap violation at that particular cell. Try to optimize data path (Upsizing/Changing vt/buffering) after that particular cell which implies optimization doesn't affect max cap violation at that particular cell.

4. In the given start point and end point; does fixing setup violation lead to hold violation?
Ans: YES.

5. For a given start and end point pairs, does setup and hold violations happen?
Ans: YES. There may be different paths from one start point to the same end point.

6. Noise

7.  If there are violations from one block to another block. What is the best method do you guide PNR engineer to fix setup and hold violations for routing?

8. Do you have hands on experience with DC?

9. What is difference b/w OCV, AOCV, POCV and explain each?

10. Commands:
a) difference b/w set_input_delay and set_max_delay?
If i specify set_max_delay -to PIN; does it include/exclude/doesn't consider insertion delay?

b) What is the difference b/w below 2 commands and which is preferable
set_driving_cell, set_transition_time

11. What is multi cycle path and why do we define them
How do we specify them for setup and hold
If hold mcp is not mentioned, what happens?
Why should i check hold at zero cycle, if i check at prev edge, what happens?

12. What is MMMC?
why do we check at multi corners?
How do you handle multiple modes at constraints level?

13. setup corners

14. Hold corners:
       - why do we check hold at low voltages?

15.  What is the dependency of temperature on setup and hold times?

16. How setup time changes from SS_0.675_cw_m40, SS_0.675_cw_0c,  SS_0.675_cw_125c?

17. How the setup and hold margins are defined for specific project?

18. CPPR and calculation with example? 

19. Let us assume you don't have chance to optimise data path cells. Then what is your approach to fix setup violations?

20. What is signal integrity?
Agressor and victim nets
how to fix

21. How do you sign-off design? What do you check? Do you use any specific tools?

Monday, January 8, 2018

AMD interview

Source synchronous Interface
1. Why there is trade-off b/w setup and hold violations?
2. What is the best way to fix CG setup and hold violations?
3. How skew affects setup and hold?
4. Why hold is checked at the low voltages also at FF?
5. What is ECO flow that you have worked on?
6. At SOC level,
7. Constraints development
8. Multi frequency clocks are valid?
        - Yes. those are valid. Otherwise we need to put constraint as asynchronous in the constraints.
9. How PT takes care of multi freq violations?
        - Finds common base period
10. Which domain have you worked in SoC level?
11. AMD is working on 7nm, GF?

Saturday, January 6, 2018

Temperature vs delay in lower technologies

Generally, delay is inversely proportional to temperature.

But below 28nm,

If temperature increases, both mobility and threshold voltages are decreasing. So, delay reduces. This is called Temperature Inversion.

Worst delay corner: -40c
Best delay corner: 125c

CPPR


Cross talk effects


Constraints validation

check_timing:
     shows possible timing violations for design

   Checks the assertions and structure of the design for potential timing violations.This   command is used to identify possible problems before generating timing or constraint reports.



    This command also prints which checks it performs. If a check reveals a violation,   the   command   also prints a message about the violation. By default, the message contains a summary of the violation. To   get   more information about violations, use the -verbose option.




No clock:

Warns if no clocked signal reaches a data check register clock pin
In this case, no setup or hold checks are performed on the constrained pin.


How to check:

get_attribute [get_pins  clock_pin_path] clocks



Possible reasons:

Not defining properly generated clocks
Netlist issues



Generated clocks:

Checks generated clock network
The master must be driven by a clock source.
There can't be loops of generated clocks. i.e., If CLK2 is generated from CLK1 then CLK1's source should not be CLK2.



     multiple_clock
                    Warns   if   multiple   clocks   reach a register clock pin. If more
                    than one clock signal reaches a register   clock   pin,   and   tim-
                    ing_enable_multiple_clocks_per_reg   is   set to FALSE, then it is
                    undefined which one is used for analysis.    In   this   case,   use
                    set_case_analysis   so   only   one   clock   can   propagate from its
                    sources to the register clock pin.   Using   this   check   and   the
                    no_clock   check   run   significantly   faster   than   other checks.
                    Hence, to save time, user may want to issue these   checks   sepa-
                    rately from other checks.




no_driving_cell

                    Warns   if a port does not have any driving cell. This warning is
                    issued only when the net connected to the port   has   parasitics.
                    In   such   case,   the   accuracy   of   delay   calculation   could be
                    impacted, as a default strong driver is assumed   in   absence   of
                    driving cell definition. Especially, in presence of crosstalk, a
                    port with no driving cell could act as a strong aggressor   which
                    could   lead   to significant amount of pessimism in the analysis.
                    Also, a port with no driving cell could act as a string   victim,
                    which could underestimate the crosstalk effect.



no_input_delay

                    Warns   if   no   clock   related   delay specified on an input port,
                    where it propagates to a clocked   latch   or   output   port.   With
                    -verbose,   the   port   name   will   be listed. Note that with tim-
                    ing_input_port_default_clock set to 'true', a default clock will
                    be assumed for the input port. Otherwise it will not be clocked,
                    and the paths are unconstrained. In this case, if   there   is   no
                    input   delay specified, check_timing will not generate warnings.



         partial_input_delay
                    Warns if any port has partially defined input delay.   This   hap-
                    pens   when   set_input_delay -min is applied on a port to set the
                    min   input   delay   with   respect   to    a    clock,    however    no
                    set_input_delay   -max is applied to that port to specify the max
                    delay, or vice versa. As a result, some paths starting from   the
                    port with partially defined input delay may become unconstrained
                    and some potential violations could be missed.




  unconstrained_endpoints

                    Warns about unconstrained timing endpoints. This warning identi-
                    fies timing endpoints (output ports and register data pins) that
                    are   not   constrained   for   maximum delay (setup) checks. If the
                    endpoint is a register data pin, it can be constrained by   using
                    create_clock for the appropriate clock source. You can constrain
                    output ports using the set_output_delay   or   set_max_delay   com-
                    mands.

         unexpandable_clocks
                    Warns   if   there   are   sets   of clocks for which periods are not
                    expandable with respect to each other. The checking is only done
                    for   the   related   clock domains, such as ones where there is at
                    least one path from one clock domain to the other. This could be
                    because   of   an incorrectly defined clock period for one or more
                    of the clocks. Another possibility is when   asynchronous   clocks
                    with unexpandable periods are interacting where they should have
                    been defined in different clock domains.



    unconnected_pg_pins
                    Checks that each power and ground pin is connected to a UPF sup-
                    ply net.   The connection can be implicit (e.g., power domain) or
                    explicit (for example, connect_supply_net).




generic cells:

Warns about generic (unmapped) cells in the design.
Timing of paths through generic cells is inaccurate because these generic cells have zero delay.



ideal clocks:

Shows the clocks that are not defined as propogated clocks.
Generally, all clocks should be defined as propogated so that clock network timing is accurately calculated.



 latency_override
                    Warns of clock latency specification conflicts. If clock   source
                    latency   is   defined for both a clock and its port (source pin),
                    the source latency for clock object is ignored.   If   input_delay
                    is   set   on clock port, which also has source latency specified,
                    the input_delay is ignored as a source latency.   Also   warns   if
                    more than one clock latency fan out to any latch clock pin.


   loops   Warns   of   combinational   feedback loops. Combinational feedback
                    loops are not analyzed. If the feedback loop is   not   broken   by
                    set_disable_timing,   it is automatically broken by disabling one
                    or more timing arcs.


http://tech.tdzire.com/what-is-a-timing-loop/


EXAMPLES
         The following example checks timing of the   current   design   and   shows
         summary   information   of   potential   problems. The checks performed are
         those defined by timing_check_defaults.

            pt_shell> check_timing

            Information: Checking 'no_clock'.
            Warning: There are 4 register clock pins with no clock.

            Information: Checking 'no_input_delay'.

            Information: Checking 'unconstrained_endpoints'.
            Warning: There are 10 endpoints which are not constrained for maximum delay.

            Information: Checking 'generic'.

            Information: Checking 'latch_fanout'.
            Warning: There are 2 level-sensitive latches which fanout to themselves.
            Information: There are 2 level-sensitive latches which fanout to latches
              of the same clock.

            Information: Checking 'loops'.
            Warning: There are 6 timing loops in the design.

            Information: Checking 'generated_clocks'.

         The following example adds the clock_crossing   check   to   the   list   of
         checks in timing_check_defaults.

            pt_shell> check_timing -include {clock_crossing}

            Information: Checking 'no_clock'.
            Warning: There are 4 register clock pins with no clock.

            Information: Checking 'no_input_delay'.

            Information: Checking 'unconstrained_endpoints'.
            Warning: There are 10 endpoints which are not constrained for maximum delay.

            Information: Checking 'generic'.

            Information: Checking 'latch_fanout'.
            Warning: There are 2 level-sensitive latches which fanout to themselves.
            Information: There are 2 level-sensitive latches which fanout to latches
              of the same clock.

            Information: Checking 'loops'.
            Warning: There are 6 timing loops in the design.

            Information: Checking 'generated_clocks'.

            Information: Checking 'clock_crossing'.

            Information: Checking 'pll_configuration'.

         The   following   example   adds   the   clock_crossing check to the list of
         checks in timing_check_defaults and removes the loops   check   from   the
         same list.

            pt_shell> check_timing -include {clock_crossing} -exclude {loops}

            Information: Checking 'no_clock'.
            Warning: There are 4 register clock pins with no clock.

            Information: Checking 'no_input_delay'.

            Information: Checking 'unconstrained_endpoints'.
            Warning: There are 10 endpoints which are not constrained for maximum delay.

            Information: Checking 'generic'.

            Information: Checking 'latch_fanout'.
            Warning: There are 2 level-sensitive latches which fanout to themselves.
            Information: There are 2 level-sensitive latches which fanout to latches
              of the same clock.

            Information: Checking 'generated_clocks'.

            Information: Checking 'clock_crossing'.

         The following example removes the retain option from the list of checks
         in timing_check_defaults. Assuming that this check is not   included   in
         timing_check_defaults,   there   is nothing to remove. The output in this
         example is the same as running the command without the -exclude option.

            pt_shell> check_timing -exclude {retain}

            Information: Checking 'no_clock'.
            Warning: There are 4 register clock pins with no clock.

            Information: Checking 'no_input_delay'.

            Information: Checking 'unconstrained_endpoints'.
            Warning: There are 10 endpoints which are not constrained for maximum delay.

            Information: Checking 'generic'.

            Information: Checking 'latch_fanout'.
            Warning: There are 2 level-sensitive latches which fanout to themselves.
            Information: There are 2 level-sensitive latches which fanout to latches
              of the same clock.

            Information: Checking 'loops'.
            Warning: There are 6 timing loops in the design.

            Information: Checking 'generated_clocks'.

         The   following   example   checks   only   latch   fanout and shows detailed
         information.

            pt_shell> check_timing -verbose -override_defaults {latch_fanout}
            Warning: There are 2 level-sensitive latches which fanout to themselves.

            Latch data pin
            ------------------------------------------------------------
            l3/D
            l4/D

            Information: There are 2 level-sensitive latches which fanout to latches
              of the same clock.

            From Pin                  To Pin                     Clock             Level
            --------------------------------------------------------------------------------
            l1/G                        l2/D                        C1                  positive
            l1/G                        l3/D                        C1                  positive

What are the sing-off checks for STA during TapeOut?


ETM (Extracted TIming Model):

http://www.vlsi-expert.com/2011/02/etm-extracted-timing-models-basics.html

How to read spef:

Below link provides the detailed explanation of contents of one sample spef file.
http://www.vlsi-expert.com/2010/08/how-to-read-spef.html

RC corners

In below 90nm or in deep submircron nodes:
        The contribution of interconnect delay in a timing path become significant and Coupling Cap component (Cc) in net delay can significantly alter slack values at an endpoint of a timing path.

So,  RC corners have to be split up as per the contribution of each component Ground Capacitance (Cg) and Coupling capacitance (Cc).

So on top of the 2 conventional RC corners Cmax and Cmin, foundry came up with 2 more RC corners.

RC worst (also known as Delay corner) - Cc is min,  Cg * R is max
RC best (also known as XTALK corner) - Cc is max.  Cg * R is min


5 types of RC corners:
Cbest
Cworst
RCworst
RCbest
Typical

Cworst (Cmax corners):
Refers to corners which results max cap.
Corner has largest path delay for paths with short interconnect nets and can be  used for max-path analysis.

RCworst (RC max corners):
Refers to corners which maximizes interconnect RC product.
Corner has largest path delay for paths with long interconnects and can be  used for max-path analysis.

Cbest (Cmin corner):

Refers to corners with min cap
Interconnect Resistance is larget than the Typical corner.
Results in smallest delay for paths with short nets and can be used for min-path analysis.

RCbest (min interconnect RC product):
Refers to corners with min interconnect RC product.
Corresponds to min Resistance and larger than typical capacitance.
Results in smallest delay for paths with long interconnects and can be used for min-path analysis.



So there are 2 types of parasitics
1) C based
2) RC based

C-based means worst and best caps
RC-based means worst and best R in adjustment with C (RC product)

Based on experience,  it was found that C-based extraction provides worst and best case over RC for internal timing paths because Capacitance dominates short wire. However, for large design, inter-block timing paths were often worst with RC worst parasitic since R dominates for long wires.








Min pulse width violation and fixing

http://tech.tdzire.com/what-is-minimum-pulse-width-check-and-pulse-absorption/

It is important for clock signal to ensure proper performance/functionality of sequential cells.

Definition:  
         This check ensures the width of clock should be more than min specified value.

Ensures that width of the clock signal is wide enough for the cell's internal operations to complete. i.e,.
It is min pulse width of the clock it has to maintain to get a stable output you need.

Impact:
       It can't capture at the edge of clock signal. So data may miss at that point.

Why does it shrink:
     Due to unequal rise and fall delays of combinational cells.

Detailed explanation:
Let us assume a clock entering a buffer. If the rise delay of that buffer is more than fall delay, the output clock will have less width than the input.

See the following figure which illustrates the same. So think of. what will happen to the same clock signal, when it passes through a series of same type of buffers. The width of the clock signal keeps decreasing, and at a point when the buffer delay is more than the clock pulse width, the clock pulse gets absorbed. This is known as Pulse absorption. So it is important to perform MPW check.


How to fix:
Keep symmetry rise and fall delays clock tree cells.

How to constrain in PT:

set  timing_enable_clock_constraints  true

#define min/max  pulse widths
set_pulse_clock_min_width
set_pulse_clock_max_width

#Remove/ignore MPW checks at particular sequential cells
remove_min_pulse_width

Query:
If asymmetric rise and fall delay cells present in the data path, what checks will be violated?
    - Data path delay means it is arrival time. If arrival time increases, setup violation comes otherwise hold violation comes.


From other website:
In ETS(or TEMPUS as the newest Cadence tool for STA is called), you will see a report like this:
In this example, the clock period is 6ns with a duty cycle of 50%.i.e. Here, the clock signal at clk_ctrl_reg/CP should be high at least for 0.3202ns (please note that the default time unit is ps in TEMPUS). The actual signal is high for 2.9731ns. Hence there is no minimum pulse width violation at the CP pin for src_clk.
Constraining the design
Now, let us see how you can specify this constraint for your design.
  1. Using .lib file
  2. Minimum pulse width depends on the technology node and the standard cell library design. You will have these modeled in your .lib file. Look for timing_type : min_pulse_width; in your liberty file. These will be defined for clock, reset and preset pins of a flop, or the enable pin of a latch.
    The index_1 is the transition at pin CP, and the last value in the table is the max_transition of the pin. The values denote the minimum pulse width values for the pin transition specified.
  3. SDC command ‘set_min_pulse_width’
  4. To specifically set the minimum pulse width constraint, you can use the command set_min_pulse_width
    If neither high now low is specified the constraint applies to both high and low signal levels.
Reporting the violations
You can use in majority of STA tool, report_timing or a similar command.
You can also use the command report_min_pulse_widthin TEMPUS to report the pulse width values.