Details

Published: Tuesday, 02 April 2019 20:03

Hits: 3999

--------------
Primetime:
---------------

PrimeTime: gate level STA tool. dynamic analysis requires input vectors and simulating those, so may not capture all possible paths. PT has most of the same timing cmd as used in DC.
--------------
It takes gate level netlist in: .db, .v, .vhdl format
It takes delay info in std delay format (SDF). Both net and cell delay are in this file. This file is optional.
It takes parasitic data (R and C) in std parasitic exchange format (SPEF). Only net delays can be caculated here by using parasitics from SPEF. when SDF not vailable, SDF is generated from SPEF, and used for net delays. It takes cell delays from .lib.
It takes timing constraints in synopsys design constraint (SDC) format

For prelayout timing analysis, cell delay come from .lib and net delay come from wire load models which estimate delays based on estimated cap and res of nets. PT supports use of timing models to represent chip submodules or std cells. Liberty model (.lib) is widely used model that it supports.

Clk/data paths are most common paths that PT analyzes. These paths start at i/p port or clk pin(of seq cell) and end at o/p port or data pin(of seq cell).
4 types of path analyzed: data path, Async paths (on async set/reset pins of flops as recovery/removal checks), clk path (thru Clk tree), clk gating paths. (clk and data paths are combined for data setup/hold checks).

PT automatically creates path groups for these paths (each of these path groups have 2 path types: setup(max) and hold(min)):
1. clk/data path (path group has the name of the clk associated with capture flop/latch, if there are multiple "create_clock" or "create_generated_clock" cmds, then separate path group created for each created/generated clock). Latch may be normal or SR latch. When considering check b/w set/reset pins (non-seq arc), the path group is assigned to the clk, which drives the end_point set/reset pin.
2. clkgating paths (clk_gating_default for paths that end on combinational element used for clk gating, EN pin wrt clk)
3. async paths (async_default for paths that end on asyn set/clr i/p of FF, checks for recovery/removal checks wrt clk). set/clr pins may be driven by o/p of flops, but they are still async wrt capturing clk.
4. default paths (default) that don't fall into any category.
5. none (unconstrained paths).

We can also have user defined path groups. In DC, these path groups affect design opt.

PT cmds:
-------
0. report_path_groups => shows all path groups above.

0. report_timing -from -to : most powerful cmd to see details of a timing path.
---
-from/to can also be -rise_from, -fall_from, -rise_to, -fall_to. -through can be -rise_through, -fall_through.
-path full | full_clock | full_clock_expanded => default is full. use full_clock_expanded to see full clk path.
-delay min|max => min=hold, max=setup (min_max reports both min and max timing)
-nets -cap(or -capacitance) -tran(or -transition_time)=> to show these values in timing reports
-nworst : number of paths to report per endpoint (default=1). We need to use this option when we do report_timing to a particular end point, and want to see all failing paths thru it.
-max_paths : number of paths to report per path group. (default=1)
-exceptions all => reports timing exception that applies to that path (to see why a certain path is unconstrained etc)
-slack_greater_than/-slack_lesser_than => used to show paths within particular slack range
-group {*gating} => shows paths only for that group. Use [get_path_groups *] to get reports for all path groups. Usually we use it when we have multiple clock groups, and we want to see path associated with particular clock, but we don't know the start or end point.
-crosstalk_delta => reports annotated delta delay and delta transition time which are computed duringcrosstalk SI analysis. Using this option does not initiate crosstalk analysis.
-input_pins => Shows input pins in the path report. By default, the report shows only output pins.
#NOTE: for report_timing, default is to show "max" (i.e setup) paths. So, if we want to see hold paths, we have to specify "-delay min" for hold paths (and "-delay max" for setup paths). Use -delay min_max to show both setup and hold arcs in same report.

ex: report_timing=> see options below

-path_type full
-delay_type max
-input_pins
-nets
-slack_lesser_than 0.000
-max_paths 100
-transition_time
-capacitance
-sort_by slack

#async path behaviour in DC vs PT: 2 kinds of async paths:
1. recovery/removal checks: PT performs this check by default, but DC neither analyzes nor opt these paths.
To analyze and opt these paths in DC, use this: set enable_recovery_removal_arcs true
To disable these paths in PT, use this: set timing_disable_recovery_removal_checks true
2. timing paths thru asynchronous pins (i.e paths flowing thru set/reset pins to Q/QZ o/p pin of the flop and then setting up to clk of next flop as D pin, these are clear/preset arcs in .lib file) : by default neither PT nor DC report these paths.
To report these paths in PT, use this: set timing_enable_preset_clear_arcs true (default is false)
To report these paths in DC, use this: -enable_preset_clear_arcs (in report_timing cmd). Even if we have this option, it only allows us to view these paths during reporting, but DC never opt these paths.

We can specify cell names for start/end_point. Then, all paths from all pins of start cell to all pins of end cell are considered. So PT warns about this, if there are any invalid points for start/end_points.
Ex: report_timing -from sync_reg -to tsd_latch => PT warns that of 5 pins in start_point of sync_reg (DTP10 has PREZ,CLK,D,Q,QZ pins), 4 are invalid start points. CLK of DTP10 is the only valid start point. PT also warns that of 4 pins in end_point of tsd_latch (LAB10 has SZ,RZ,Q,QZ pins), 2 are invalid end points. SZ/RZ of LAB10 are the only valid end points. For PT false paths, start point should always be CLK and endpoint should always be D. DC and VDIO don't warn about this, and just ignore the constraint, if it doesn't conform to this. VDIO/ETS reports may show startpoints as Q or D, but when false pathing, we should always write them as from CLK.

#NOTE for recovery/removal paths, use Q of 1st flop as startpoint and CLRZ/PREZ of next flop as end point. For some reason, using CLK of 1st flop as startpoint doesn't work.

#In latch based paths, borrowing occurs if data arrives in the transparency window. See PT doc (page 36-38). So startpoints may be from D, Q or CLK. CLK and Q startpoints are treated as starting from the clk of latch, while D is treated as starting from the D i/p of latch and going thru the latch to Q o/p pin of latch. Note, this behaviour is different when VDIO/ETS is used to report such paths. In VDIO/ETS path from startpoint D is still the same, but paths from CLK and Q startpoints are treated as worst case slack paths from D, CLK or Q.

to report timing for such paths, and see the latch borrowing, use -trace_latch_borrow (otherwise startpoint delay is shown for D, doesn't show the actual path to D)
Ex: report_timing -from ... -to ... -trace_latch_borrow

Ex: of time borrowing path
Point Incr Path
---------------------------------------------------------------
clock spi_stb_clk (rise edge) 55.00 55.00 => start point
...
data arrival time 56.55 => this is data path delay from 1st flop.
---
clock clk_latch_reg (rise edge) 1.00 1.00 => end point
...
Iregfile/tm_bank0_reg_9/C (LAH1B) 3.66 r => this is total delay to clk of latch
time borrowed from endpoint 52.89 56.55 => since data comes much later than rising edge of clk, we borrow the difference (56.55-3.66=52.89) from this latch, so that next path from latch o/p will consider that D->Q delay is 52.89ns.
data required time 56.55
---------------------------------------------------------------
data required time 56.55
data arrival time -56.55
---------------------------------------------------------------
slack (MET) 0.00

Time Borrowing Information
---------------------------------------------------
clk_latch_reg nominal pulse width 100.00 => this is width of clk pulse = clk_period/2
clock latency difference -0.36 => this is reduction of pulse width due to diffeerence in rising and falling edge
library setup time -0.26 => this is setup time of latch (wrt falling edge of clk) which needs to be subtracted, as max time available is reduced by this
---------------------------------------------------
max time borrow 99.37 => final max time available to borrow
actual time borrow 52.89 => actual time borrowed < max available. so timing met
---------------------------------------------------
-------------------

1. report timing to auto detect False paths:
---
By using the report_timing -false command, you can have PrimeTime automatically detect false paths based on the logic configuration of the design.

2. report timing exceptions:
---
report_timing -exceptions all => reports all timing exceptions that apply to all paths. exception may be because of false_path, multicycle path or min/max delay.

3. set_disable_clock_gating_check: to disable clock gating check on specified cell or pin (when pin is spec, clk gating check is disabled only if pin is clk or En). This is needed when we are outputting clock on a dmux pin, and the tool checks for clk gating on these paths, as it thinks other i/p to the OR/AND gate to be the Enable signal trying to setup or hold to clk signal.
ex: set_disable_clock_gating_check {u_DIA_DIG/u_DMUX_DIG/U293 u_DIA_DIG/u_126/A} => disabled clock gating hold/setup checks. We cannot use set_false_path for such paths, as PT will warn about "valid endpoint not found", as it's really not a data path, but a clock gating check.

4. set_disable_timing => disables timing through the specified cells, pins, ports, or timing arcs. It removes the affected objects from timing analysis, rather than removing the timing constraints from the paths (as in "set_false_path"). So, this cmd is more efficient, and can be used when all paths thru a pin are false (instead of using multiple "set_false_path").
NOTE: This cmd is also helpful when we want disable timing b/w 2 async pins of flop such as CLRZ/PREZ. In this case we can't use "set_false_path -from flop1/CLK -to flop2/PREZ", as then the path of flop2/PREZ setting up to flop2/CLK would be false pathed. We need path of flop2/PREZ setting up to flop2/CLRZ would be false pathed which wouldn't be possible using false_path.
set_disable_timing -from CLRZ -to PREZ {get_cells {u_SPT/Ret_reg} => timing arc from CLRZ to PREZ disabled for Ret_reg flop. This timing arc should exist in .lib file for that Flop. This is equiv to:
set_disable_timing [get_timing_arcs -from {u_SPT/Ret_reg/CLRZ} -to {u_SPT/Ret_reg/PREZ}] => this is equiv to one above.
NOTE: to see all timing arcs for a particular lib cell, do:
report_lib -timing MSL445_W_150_1.75_CORE.db { AN210 } => shows all timing arcs from .lib file for AN210 gate. Timing type/sense are specified in .lib file.

Arc Arc Pins
Lib Cell Attributes # Type/Sense From To When
----------------------------------------------------------------------------
AN210 0 positive_unate A Y => from i/p A to o/p Y
1 positive_unate B Y => from i/p B to o/p Y

5. set_false_path: to set false paths which are point to point timing exception. Declaring a path to be false removes all timing constraints from the path. PT still calculates the path delay, but does not report it to be an error. "report_timing" for such path will show "No constrained paths".
NOTE: false paths -to/-from are more strict than report_timing -to/-from.
---
For false paths, -to = I/P port or CLK, -from = O/P port or D
To remove false paths, do: reset_path ...

when we specify wild characters, false paths are expanded.

ex1: set_false_path -from Ireg/reg_0/* -to Ispi/s_reg_*
A single * expands to everything that matches before it hits a "/". So, "Ireg/reg_0/*" expands to pins of reg_0, while "Ispi/s_reg_*" expands to name of cells such as s_reg_0, s_reg_1 and so on. Since we didn't specify "Ispi/s_reg_*/*", it doesn't expand to name of pins on the cell. By specufying just the name of cell, we are asking PT to look at only valid endpoint of cell, which is Din pin of flop. Since reg_0 is a latch, startpoints are all i/p,o/p pins on latch, while end points are just the Din pins of cells, since they are flops. So, this expands to:
set_false_path -from [list [get_pins Ireg/reg_0/C] [get_pins Ireg/reg_0/D] [get_pins Ireg/reg_0/CLRZ] [get_pins Iregreg_0/Q]] -to [list [get_cells Ispi/s_reg_15] [get_cells Ispi/s_reg_14] ...]

ex: set_false_path -from Ireg/reg_0 -to Ispi/s_reg_* => NOTE: only cell name is specified in from list, so only clk and din pins are considered for this cell (which are the only valid startpoints for a ltach). So, this expands to:
set_false_path -from [list [get_cells Ireg/reg_0]] -to [list [get_cells Ispi/s_reg_15] [get_cells Ispi/s_reg_14] ...]

NOTE: So for a flop, we can just specify name of flop as starting point. That means clk of flop. Or, we could specify cell/clk. It means the same thing. cell/Q is invalid start point, though in this case, it refers to the same path. Similarly for destination flop, we can just specify the name of flop as ending pont. That means data_in of flop as ending point. Or, we could specify cell/data_in. cell/clk is invalid end point.

NOTE for PT: even though above style works for PT, when we do report_timing in PT, it warns about invalid start/end points. This is because, when we specify name of cell as startpoint, it checks for all pins on that cell. For a flop such as DTC20, its 5 pins (clk, din, clrz, Q, QZ) that it looks at all starting point of which only clk is valid, remaining 4 are invalid pins. Similarly for end point, it looks at 3 pins (clk, din, clrz) of which only din is valid, remaining 2 are invalid pins.

NOTE for VDIO/ETS: invalid start/endpoint paths will just be ignored in vdio/ets even though constraints.sdc file has it. We may even see invalid start/end points of such paths in vdio/ets timing report, but if we just cut and paste start/end point of such paths from vdio timing report, they may have cell/Q as startpoint, or cell/clk as end point which are invalid. These paths pasted in constraints.sdc file look fine, but don't get imported into vdio. When we do report_path_exceptions in vdio, we may not see the path in vdio. So, very IMPORTANT to remove Q or clk from such paths before putting them in false_path file.

Note: with a transparent latch, there's valid timing path from c2q and d2q as latch is transparent so path depends on whether data or clk comes first. So, when we just specify the cell name for a latch, it considers both cell/clk and cell/Data_in paths for start point.
A phase latch: rising clk path ( from Previous cell to D of latch, from D of latch to next cell and from C of latch to next cell ). falling clk path (from previous cell to latch)

SR latch: It has valid start point from some path to valid end point as SZ or RZ pin. If endpoint is RZ pin, that implies that SZ path is trying to setup to RZ pin. If endpoint is SZ pin, that implies that RZ path is trying to setup to SZ pin. Both setup/hold checks done. NOTE: for setup, data tries to setup in same cycle of clk (as apposed to normal paths, where setup of data is checked for next cycle of clk). This is because, these arcs are classified as nonseq arc(nonseq_setup/hold) since it's data to data arc, while normal setup/hold arcs are classified as seq arc(setup/hold_rising/falling), since they are data to clk arc.

#false path spanning different clk domain:
set_false_path -from [get_clocks I_CLK32K] -to [get_clocks I_CLK5M] => This false paths all paths starting from flops clocked by 32k clk, and going into D pins of flops clocked by 5Mhz clk.

special case of -through: clock can be specified as -from or -to and startpoint or endpoint can be specified as -through. This can be used in cases having muxed clocks. Ex:
pt_shell> report_timing -from [get_clocks ...] -through $startpoint
pt_shell> report_timing -through $endpoint -to [get_clocks ...]

combinational pins can't be path startpoints or endpoints (use -through for these). However with timing_report_always_use_valid_start_end_points variable set to false(default), PT considers these invalid start/end points to be -through points and continues searching. If set to true, it will just ignore these paths. with the exception of clk gating checks.

4. delay cmds:
---
set_input_delay: An input delay is specifying an arrival time at an input port relative to a clock edge from a register. The maximum input delay value should be equal to the length of the longest path to the register data pin, plus the max c2q time (max path delay) of the register. The minimum input delay value should be equal to the length of the shortest path to the register data pin, plus the min c2q time (min path delay) of the register.

set_output_delay: An output delay represents an external timing path from an output port to a register. The maximum output delay value should be equal to the length of the longest path to the register data pin, plus the setup time of the register. The minimum output delay value should be equal to the length of the shortest
path to the register data pin, minus the hold time (since that tells you how much min delay you should need inside your block to meet 0 hold slack).

5. misc cmds:
----
A. report_net U1/SCAN_ENABLE => This reports FO/FI/cap/res for given net. This is helpful to debug reset tree, scan_enable tree or clock tree to see if it has been buffered or not
B. report_ideal_network => This should be run in PT to make sure no n/w is set to ideal. It reports clk pins on all cells, on which it finds clk is set to ideal
C. set_case_analysis => Specifies that a port or pin is at a constant logic value 1 or 0, or is considered with a rising or falling transition. In case of pins, constant propagation is only executed forward. Also, even if these pins are driven by logic values from design, the values set by case_analysis dominate. When case analysis is specified as a constant value, this value is propagated through the network as long as the constant value is a controlling value for the traversed logic (i.e if 1 i/p of NAND2 is 0, then o/p is propagated as 1) . When some port or pin is set to constant, then the path thru that pin is unconstrained path, as it's a constant value on that pin. So, report_timing won't show any timing thru that path. That's why we never set constant value on i/p ports, so that we can have PT time all those paths from i/p ports. So, we have to be very careful when using set_case_analysis as that port/pin may never get timed, so even if it's violating setup/hold timing, it may never get reported. Use set_case_analysis only on scan_mode pin, and then have some other way to time setup/hold path from scan_mode pin. Do not use set_case_analysis on any other pins.
Note: When a logic value is propagated onto a a net, the associated design rule checking (DRC) constraint checks are disabled. However, the max_capacitance DRC check can be performed on driver pins for constant nets by setting timing_enable_max_capacitance_set_case_analysis variable to true. This variable is set to false by default. So, when we do set_case_analysis on scan_en pin, we may not see max_cap/max_tran violations on it, even though it may not be buffered and have large violations.
ex: set_case_analysis rising {U1/U2/A U1/U3/CI} => pins considered only for rise transition (fall transition on these pins is disabled)

D. remove_design -all => used to remove design from memory so that new PT run can be started w/o exiting PT. However it doesn't remove lib from memory. So do this too:
remove_lib -all => This removes all lib from mem. If we do not do this, then previous libs remain mem, so any new libs get added to prev libs. By default, libs added last are the ones that get used for final runs. Check it using report_design.
---------------

In PT, we can temporarily change design, like insert_buffer, size_cell, etc and see the impact on timing. then to import these changes, run characterize_context cmd whichcreates a script that can be used in DC to specify timing condition for resynthesis.

multiple clocks:
we can specify multiple clocks as sync (generated clocks by dividing, etc), async (no relation) or logically exclusive (like clocks coming thru mux, so only one can be active). Use set_clock_groups to define such groups. With multiple clocks, best way to analyze is to set_case_analysis for multiple scenarios.
when using multiple clocks in design, we can specify the relaionship b/w clocks to be sync (default), async (set_clock_groups -async -group {ck1} -group {ck2} => essentially declares a false path b/w 2 clks) or exclusive (set_clock_groups -logically exclusive -group {ck1} -group {ck2} =>essentially declares a false path from ck1 to ck2 and vice versa).

-------------
CHECKS:
------------
1. Min pulse width check for clk: Clk pulse should not be too small at reg clk pin, else data may not get captured. Also, if pulse width is too small, clk pulse may not even get propagated. Min pulse width check is specified in lib cell.

2. Unate check: PT keeps track of clk sense. It recognizes the positive or negative sense of the clock signal arriving at each register clock pin. No specific action is necessary to tell PrimeTime the sense of a clock tree that has only buffers and inverters. In this case, the clock signal arriving at the register clock pin is said to be unate.
+ve unate: A clock signal is positive unate if a rising edge at the clock source can only cause a rising edge at the register clock pin, and a falling edge at the clock source can only cause a falling edge at the register clock pin.
-ve unate: Similarly, a clock signal is negative unate if a rising edge at the clock source can only cause a falling edge at the register clock pin, and a falling edge at the clock source can only cause a rising edge at the register clock pin. In other words, the clock signal is inverted.
non unate: A clock signal is not unate if the clock sense is ambiguous as a result of non-unate timing arcs in the clock path. For example, a clock that passes through an XOR gate is not unate because there are non-unate arcs in the gate. The clock sense could be either positive or negative, depending on the state of the other input to the XOR gate

ERRORS and WARNINGS: applies to both PT and ETS
--------------------------
A. check_timing: Shows possible timing problems for design.
-------------------
1. 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.

Generally, for the multiclocks defined, PrimeTime must ensure that the common base period for a set of related clocks is divisible by every clock in the set. The 'unexpandable_clocks' check warns if there are pairs of clocks where the periods
are not expandable with respect to each other.
In the case where the two clock periods differ, PrimeTime calculates a common base period (LCM) between the two clocks and expands both clocks to this common base period until it finds the common edge between the two clocks. If the clocks can not expand to a common base period, the "PTE-053" warning is issued.

The relationship between the clocks within a set is known as "related". This means, the cross-clock domain timing paths require all the clocks in the set to expand to a common base period, but due to differences in the clock period they can not be expanded.

2. unconstrained_endpoints:
--------------------------------
#Warns about unconstrained timing endpoints. This warning identifies 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 commands.
endpoint is unconstrained because of no_capture_clock (create_clock needed on the capture flop clk pin to fix this), dangling_end_point (set_output_delay needed on the o/p pin to fix this), or fanin_of_disabled (paths ending at fanin of disabled timing arc. to fix this, undo disable timing arc)
#startpoint is unconstrained because of no_launch_clock, dangling_start_point or fanout_of_disabled (paths starting from fanout of disabled timing arc)
#In both PT and ETS reports, whenever there is "no clk found" associated with any capture flop, all i/p (D, CLRZ, PREZ) are reported as unconstrained.

3. UITE-216: Object not valid (Important)
-------------------------------
-from , -to in set_false_path, set_multicycle_path, etc is not valid. (see page 200/494)

-from should have objects to be valid timing startpoints (i/p port, bidir port, seq cell, seq cell clk pins, data pin of level sensitive latch, clk or pin that has i/p delay specified). If a clock is specified as the -from object, all primary inputs clocked by that clock and registers clocked by that clock are used as startpoints. If cell is specified, cmd applies to one path startpoint on that cell (for seq cell, it's clk pin, while for latch it's clk as well as data pin).

-to should be valid timing endpoints (o/p ports, bidir ports, seq cell. seq cell data i/p pins, clk or pins that has o/p delay specified). If a clock is specified as the -to object, all primary outputs clocked by that clock and registers clocked by that clock (reg data pins are used as endpoints for each of these registers) are used as endpoints. If cell is specified, cmd applies to one path endpoint on that cell.

4. no_driving_cell: when i/p ports don't have drivers.

5. ideal_clocks: reports not propagated clocks. disabled by default. To enable, do check_timing -include { ideal_clocks }

6. PTE-060. Warning: No clock-gating check is inferred for clock at pins of cell. See solvnet article for details: https://solvnet.synopsys.com/retrieve/015769.html
This is a clock gating check warning, where PT is unable to infer clk gating check for complex gate (as MUX etc). By default, PT infers clk gating checks for simple gates as AND/OR/NAND/NOR only. We need to have PT check for clk gating on these complex gates: 2 options:
A. By doing "set_case_analysis" on one of the i/p of complex gate, we may be able to reduce it to simpler gate, which will allow clk gating check to be inferred.
B. help PT find correct gating relation by issuing clk gating cmds. Consider a mux with gating signal on S pin and clk on A pin,
- set_clock_gating_check -high UMUX/A => says that clk pin on UMUX/A is active high clk, so clk gating signal can only change while clk is low
- set_disable_clock_gating_check UMUX/B => says that other i/p pin of mux is not to be checked for clk gating. This may be needed if we are interested in clk gating check wrt S pin of mux only. Otherwise PT treats both pin B and S as gating pins, and reports worst case gating.

NOTE: Use report_clock_gating_check to see all clk gating checks. For multiple clk signal, use "set_multicycle_path" to get correct clk gating checks for setup/hold. All delay arcs thru clk gating cells are still honored during timing analysis. If we want to disable gating signal to get propagated (since clk gating check ensures that gating signal is clean, so won't cotribute to delay thru gating cell), we may set "timing_clock_gating_propagate_enable false".

7. PTE-052: expanding clocks to common base period. PrimeTime limits the waveform expansion of the smallest period to be no more than 1000 times and the waveform expansion of the largest period to be no more than 101 times. If the largest period is too large, then PT takes largest period as the common base period but still has not expanded the smallest period beyond its limit.In certain situations, this can cause paths between these clocks to be unconstrained.

---------------------------

------------------------------------------
VDIO/ETS vs PT: most of commands same b/w ETS and PT, but slight variations.
-------------------------------------

Commands used in ETS can be used within VDIO.

path groups: In PT, path groups are divided based on clks, but for same clk, all paths are in same path group. However, in ETS, for the same clk, paths are subdivided into 4 groups: in2reg, reg2reg, reg2out, in2out.

In VDIO: report_path_exceptions can be used to see list of all false paths used by VDIO.

report_timing: almost same syntax as in DC.
#-format used to format report. default is -format {instance arc cell delay arrival required}. -format {instance cell arc load slew delay arrival required} typically used. use incr_delay to show inc delay due to noise.
#-max_paths in PT reports paths with -ve slack, whilein ETS, it reports +ve slack paths too. So, use -slack_lesser_than option in PT. Also, max_paths in VDIO reports specified number of worst paths in the design, regardless of the endpoint. Use -max_points instead of max_paths to get worst path for each endpoint only once.
#-nworst Specifies the number of paths to be enumerated for each endpoint. This behaviour is same across PT and VDIO/ETS. By default, only the worst path to each endpoint is reported. However, in VDIO, this option can't be used with -max_paths, as that shows all worst paths, even if ending at the same end point.
#full_clock in ETS reports with clk delay expanded while in PT, it shows clk starting point and adds clk delay upto that point in "clock source latency". so, use full_clock_expanded in PT, so that it expands this clk src latency, and compares to ETS rpts.
PT: report_timing -delay max -path full_clock_expanded -slack_lesser_than 20 -max_paths 500
ETS/VDIO: report_timing -early -path_type full_clock -view func_max -max_points 500 -format {instance cell arc load slew delay arrival required}

---------------

For normal latches, report_timing behaves differently than in DC/PT. see primetime section above for details:
Ex: startpoints may be from D, Q or CLK. For DC/PT, CLK and Q startpoints are treated as starting from the clk of latch, while D is treated as starting from the D i/p of latch and going thru the latch to Q o/p pin of latch. However, in VDIO/ETS path from startpoint D is still the same, but paths from CLK and Q startpoints are treated as worst case slack paths from D, CLK or Q.

------------

Details

Published: Friday, 15 March 2019 19:03

Hits: 1351

Linux/Unix cmds: All shell support majority of simple cmds used in scripting. Many of these simple cmds came from unix world, and as such we will refer to them as unix cmds (as ls, cd, mkdir, etc).

The syntax for these unix cmds is something like this:

Syntax: cmd <options prefixed by "-"> <other args for filtering>

• Options: These unix cmds allow options to be used in the args, which may be specified prefixed by a "-" (i.e ls -a => here "a" is an option that specifies how listing should be done). The purpose of these options is to customize on how these cmds behave.We may combine multiple option in one by using just one "-", i.e ls -a -l -S may be written as ls -alS => here we combined 3 separate options into one. The options may be put in any order, so ls -lSa is same as ls -alS or ls -al -S, etc.
• Other args: These unix cmds also allow other args such as name of file, etc that might be needed for that particular cmd. Not all cmds need these other args. Wildcards (as *, ?, etc) may also be used (in lieu of full name, etc), which we'll discuss under "regular expression" section. These wildcards are not part of cmd syntax, but rather part of shell. The shell expands these wild cards based on it's rules, and then passes the final expanded form to the unix cmd, which is then executed. However, some options in cmd line may dictate how these wildcards should be treated. POSIX std defines the behaviour of cmds, and all shells try to conform to POSIX std, so these unix cmds behave consistently across most of the shells. Also, quoting mechanism (single quote, double quote, backslash, etc) may hide special characters from being interpreted by shell, so that they are passed untouched to the unix cmd. Read man page of a unix cmd on your system (details below). So, sntax for unit cmds is:

There are more than 200 unix cmds supported by major shells. We'll just discuss a few in unix cmds section later (rest available in "advanced bash manual - part 4", see bash section, note some of unix cmds may be bash speciic or csh specific).

very good website: http://www.grymoire.com

Versions: Unix cmds may be implemented differently on different Linux systems. To make it consistent, POSIX defines a standard syntax for unix cmds. All GNU implementation of these Unix cmds follow this standard, by supporting a minimum set of options that those unix cmds will support. Since most Linux systems originate from same Linux kerenl and incorporate lot of basic stuff from gnu.org, they adhere to GNU POSIX standard. However, some vendors start supporting extra options on some of these unix cmds, which are not POSIX standard. These keep on getting added with time, and sometimes they become POSIX standard later on, and newer versions of these cmds start incorporating them. It's impossible to know what variant of unix cmd is supported on your particular system, but knowing the flavor of that Unix cmd can help you a lot to debug why some linux cmd works fine on some machine but not on other.

For any unix cmd, run -V for that cmd on cmdline. If -V is not supported, run "rpm -q <cmd>" on RHEL type OS. Both cmds should work on any Linux distro. That will show version number and other details. It's recommended to always use GNU cmd (downloaded from gnu.org), as that is what is supported on most Linux systems, and most of the documentation on the web refers to GNU implementation of these cmds (even though they may not state it explicitly). Some linux distro may implement their own version of some of these unix cmds, which may be slightly differently, so always check.

Ex: -V: running "grep -V" shows that grep is GNU grep and is version 2.20.

/home/aseth $ grep -V
GNU grep 2.20

Ex: rpm: running "rpm -q grep" shows that grep is version 2.20-3.

/home/aseth $  rpm -q grep
grep-2.20-3.el7.x86_64

If I want to update grep to later version, I can do that by going to gnu.org and downloading the latest grep. I could even download some other flavor of grep instead of GNU grep (i.e Solaris grep) by going to that vendor's website, but as I said, stick to GNU. Do not worry too much even if you are on a older version of a cmd, as most basic features are supported even on very old versions, and suffice for 99.9% of users.

MAN: man stands for manual, and is used to find all the details of any cmd. For ex, to see what "ls" cmd does, and all it's options supported, we can type this on terminal:

• man ls =>  shows description and all options for "ls" cmd. man can be used for any other utility also such as diff, etc (not just unix cmds)

A kernel doesn't have any user interface. Kernel can only interact with other pgms. Any shell (bash, csh, etc) is a pgm that reads a line of input from you, and then interprets it as one or more commands to manipulate files or run other programs. These cmds may be of 2 types: built in or external. We'll look at both types of cmds:

CMDS: There are tons of Linux/Unix cmds with lots of options, that probably no one can learn. However, I'm listing some common ones that will allow you to get your job done. Of these cmds, grep and find are 2 most powerful cmds used widely, that you should look into. Below is a link to cheatsheet of most used linux cmds.

https://phoenixnap.com/kb/linux-commands-cheat-sheet

I'm also listing imp linux cmds separately in the list below:

1. dir/file cmds:

cd: cd <dir> => change dir to specified dir

• cd  - => changes to previous working dir
• ~ corresponds to internal variable $HOME (i.e home dir as /home/ashish). cd ~ is same as cd $HOME. Also ~ followed by user name means home dir of that user. i.e ~rohan means /home/rohan.
• ~+ corresponds to internal variable $PWD or current working dir. Similarly ~- corresponds to internal variable $OLDPWD or previous working dir. 

mkdir/rmdir: mkdir <dir> => makes new dir. rmdir <dir> => removes the named dir.

• If -p used then it creates dir if it doesn't already exist (-p is usually used for creating nested dir). ex: mkdir -p dir1/dir2/dir3 =>creates nested dirs dir1/dir2/dir3 instead of creating them one by one (so all 3 dirs creted by just 1 cmd).
• -m is used to assign dir permissions. ex: mkdir -m 755 dir1 => applies "chmod 755" to dir1 (instead of running a separate chmod cmd on dir1)

pushd: pushd <dir>: (pushd means push dir) => saves current dir on top of dir stack and then cd into dir. This is convenient way to remember previous dir, and then goto that dir using popd.

popd: popd (popd means pop dir) => This pops dir from top of dir stack, and then cd into that dir. pushd and popd

dirs: This prints the dir stack that was formed by doing push cmds

cp: copies files/dirs. syntax: cp [options] src dest.

More details: https://www.tutorialspoint.com/unix_commands/cp.htm

• copy files: cp src.txt dest.txt => cp file named as src.txt as dest.txt. Even links are followed and the actual files are copied. If you want to just copy the link (i.e preserve the soft link as it is), use -P.
• copy dir: cp -r src_dir mydir/dest_dir => Here all files from src dir are copied to dest dir, as -r (or -R) means copy recursively. There's no diff b/w -r and -R. Behaviour of cp cmd varies based on whether dest dir exists or not. If the dest_dir doesn’t exist, cp creates it and copies content of src_dir recursively as it is. But if dest_dir exists, then copy of src_dir becomes sub-directory under dest_dir. When -r option is used, all soft links are preserved when copying recursively, i.e links are copied rather than the contents pointed to by the link. This is different behaviour than regular cp cmd without -r option, that copies the contents and not the links. To get same behaviour as regular cp cmd, we have to use -L which dereferences symbolic links. So, use cmd: cp -rL to copy files pointed by the links, when copying recursively.
• Copy updated files only: cp -u [source] [destination] or cp --update [source] [destination] which will only copy files if the source files are newer than the destination files, or if the destination files do not exist.
• preserve all attr: This is called "archive" and can be enabled with option "-a". It preserves link, mode, ownership, timestamps and all other attributes.
• copy hidden files only: If you are wanting to copy hidden files and folders in Linux using the cp command, the first thing people will think of is cp -r .* /dir/ but this will actually match ./ and ../ as well, which will copy all files in the current working directory, and also copy all the files from the parent directory. So to copy only hidden files in Linux, you would want to run cp -r .[a-z,A-Z,0-9]* /dir/ this way it will only match files that start with a . and the next character is a-z, A-Z, or 0-9 and everything after that being a wildcard.
  
  

rm: removes files and dirs. To remove dir recursively, use rm -r *. However, sometimes dir can't get removed, because of permission not set correctly in all levels of hier. So, do chmod 777 -R top_dir_name. This sets rwx permissions to 777 in all subdir recursively. Then use rm cmd. An empty dir won't get deleted by rm <dir_name>. Either we need to use rm *dir_name* where we risk deleting other dirs too, or we can just use rmdir <dir_name>.

ls: list all files and dirs in specified dir. If nothing specified, then list for current dir.

• ls dir1/dir2 => lists all files and dir in dir1/dir2. WE can also put \ at end, it makes no diff. i.e ls dir1/dir2/
• ls dir1/dir2/* => ls by itself lists all files and dir in given dir, but no contents of subdir within that dir. By using *, we make ls list contents of that subdir too.
• ls dir1/*my* will list all files and dir which have letters "my" in them. But if there's a dir which has my in it's name, then it will list it's contents too. We may not want that. In such case, we may use option "-d" to list dir only (since contents of most dir are files, so all those will be omitted making it easier to see). ls -d dir1/*my* => lists dir only which have "my" in their name. Other way to list such dir is by using find cmd with mindepth and maxdepth option. Check on "find" cmd details later.
• ls -l -a => This gives long listing of files (i.e with all details as time, permissions, etc). -a causes all files/dir to be shown (including hidden files/dirs whose names start with ".")
• ls -S -r => S option causes files to be listed by size (with largest file at top by default). -r option causes files to be listed in reverse, so largest file is at bottom (this is more commonly used). -h causes sizes to be displayed in human readable format (i.e MB, GB, etc).
• ls -lrt => very commonly used cmd. long lists all files sorted by their timestamp (with latest file at bottom due to -r being used)

readlink: display full file path
ex: readlink -f file1.txt => displays full path of that file (so it's easy to cp and paste)

realpath: expands all symbolic links and resolves references to produce absolute path name:

ex: realpath /home/ash/project/../arm => displays real absolute path = /home/ash/arm

tree: tree -f => displays all dir/files etc in that dir as a tree structure. Easy to see.

less/more: These cmds allow us to read a file from within terminal itself, w/o opening any other pgm as emacs, vi, etc. less is most widely used, as it can do everything that more does. less is one the most used cmds for reading a file (NOT writing as that requires other text editors as vi), so get used to it. The options in less are similar to those in vi test editor cmd (many key bindings are same), so it's comfortable to use if you have used vi editor in the past. 

less file1.txt => shows contents of file.txt within the terminal few lines at a time. Use arrow keys to scroll up/down.

There are many options in less that can customize the file appearance.

less -N -M file1 => -N displays line numbers for each line in file. -M displays filename while the file is open.

Apart from cmd line options above, there are many interactive keystrokes/cmds that we can apply while the file is open. Many of the cmd line options above, work in interactive mode also, so you can apply them anywhere.

-N => When you type "-N", and then hit enter, it will show line numbers for each line in file. Pressing -N again gets rid of the line numbers. If file is very large, it may take a while, before it displays line numbers, so don't assume that the pgm is hung

g / G(-shift+g) =>hitting small "g" takes you to beginning of file while capital G takes you to end of file. If you prefix g with a number then it takes you to that line, i.e 234g takes you to line 234.

^G => hitting ctrl + G key displays the file name. Same as -M option.

2. exit => to exit from script. exit with optional number as arg, returns that exit code. So "exit 5" exits withs return code of 5 (failure)

3. input/output cmd: To print on screen or get input from keyboard, bash has multiple cmds. For outputting on screen, 2 cmds: echo and printf. To get input from user, builtin cmd "read". read is specific to bash, but echo and printf are POSIX unix cmds, and supported by most shells. However, behaviour of echo is inconsistent from shell to shell, so printf is prefrred.

echo: echo prints whatever is provided in it's args, terminated by newline (to suppress automatic newline at end, use option -n). However, \n, \t etc within args are printed as is. In order to recognize \n or "newline", use option -e (i.e echo -e "my \t name"). -e recognizes all backslash escaped char. ANSI C quoting may also be used to recognize these special char. ANSI C quoting puts these escape char in form $'\n', so that they are expanded by bash, as newline, tab, etc.

ex: echo me $'\t' name $'\n' => This prints tab and newline correctly. NOTE: everything until the end of line or ; (whichever comes first) is considered part of echo cmd (unless ; is hidden from shell by putting it inside single or double quotes)

printf: similar to C style printf cmd. It can print string to STDOUT by default, or using option "-v <var_name>" causes the o/p of printf to be assigned to var name "var_name"

read: It has lot of options to read from keyboard (read year => reads and stores value in var "year") or from file (read -u FD => to read from file descriptor FD)

ex: echo -n "Enter your gender"; read -n 1 gender; if [ $gender == "M" ] ...; => -n num option says read only "num" characters and return, instead of waiting for newline char

4. alias: allows a string to be an alias or substitute name for a simple cmd. unalias is used to remove an alias.

ex: alias ml="ls -al"

To see what alias is being used for any cmd, use "type" cmd. See in section below.

NOTE: alias are not expanded when shell is not interactive, so scripts using aliases may break. Using shell function is always preferred over using alias.

5. history: displays the history of all cmds run in that shell (with line numbers). A lot of options supported. History expansion is provided similar to csh. This helps to run a cmd quickly, without doing copy/paste or using up/down arrow keys.

NOTE: there are settings in .bashrc (for bash shell) that controls number of history cmds to show (HISTSIZE=100) and max no. of entries to hold in .bash_history file (HISTFILESIZE 2000). Many more settings possible.

!n => run cmd line n from history. ex: !123 => run cmd number 123 from history of cmds

!-n => run cmd n lines back. So, !-2 means run 2nd last cmd in history.

!! => runs last cmd. We can also apend to this cmd, i.e !! | grep "a" => this runs last cmd and searches "a" from o/p of that cmd. other ex: !!2 => appends 2 to last cmd run. So, if last cmd was "ls prog", then this becomes "ls prog2"

!string => run most recent cmd in history that starts with string <string> ex: !ma => runs last cmd that started with letters ma.

!?string? => run most recent cmd in history that has string <string>in it. ex: !?prog1? => runs last cmd that matches pattern "prog1". i.e if 2 cmds were run "make prog1" and "make prog2", then "make prog2" will be run.

What if we don't want to run cmd, but ibstead just display such cmds. For that use :p at the end => tht will display all such cmds w/o running it.

ex: !sudo:p => This will show all cmds starting with word "sudo" w/o executing it.

ex: history | grep <string> => This will searchf= for all cmds with matching string and display it. Here we used pipe and another linux cmd "grep" to filter out results.

6. eval => shell built in cmd. If we set a unix cmd to a variable, then to run that cmd, we need to use eval.

ex: CMD="ls -lrt"; eval $CMD; => If we just type $CMD that will error out.

7. exec: Normally when we run a new pgm, a new process is created. It runs in a new subshell, inheriting env var from it's parent shell. Sometimes, we want to run a new process which has no connection with parent process. In such cases, we can replace the new process with current process .In such cases, exec cmd is used to run the new process. It will replace contents of current process with this binary image of this new process. exec cmd may have 0 or more arguments. If no arguments provided, then exec is only used to redefine the current shell file descriptors. The shell continue after the exec. However if 1 or more arguments provided, then the first arg is taken as cmd, the remaining args are passed as arguments to that cmd. In this case, if there are cmds in a script after the exec cmd, then those cmds will never get executed. In this case, exec never returns as is the case with calling other pgms (since the new pgm has replaced the original pgm).

ex: exec wc -l myfile.txt => runs wc cmd passing "-l myfile.txt" as args to wc

ex: sometimes we see code where we execute a script2 within a shell script1, which sources the same original script1. This looks like a recursive infinite loop, bt can work well when script1 has tcl commands. This script myscript.sh is a bash shell script. Only 1st 3 lines are bash cmds, remaining are pt_shell cmds. On running, this script starts running as bash based on 1st line, ignores 2nd line which is a comment, and runs 3rd line "exec" cmd. That calls a pgm pt_shell which has a source $0 in its arg. pt_shell gets called in a new shell and sources myscript.sh. However, pt_shell is a pgm that can only source tcl files. It sees myscript.sh as a tcl file. So anyline starting with # is treated as comment. So, it ignores first line as comment. It looks at 2nd line, sees contiuation of it on 3rd line (due to \ at end of 2nd line being treated as valid continuation of comment line in tcl), and so considers 2nd line as comment (with 3rd line included in it). Then it moves to 4th line and start reading the file normally. So, here we are able to use the same file as both script and source file.

#!/bin/sh

# \

  exec pt_shell "source $0"

other tcl cmds ....

8. env: Unix has a way of defining a list of strings. These can be assigned a value (in the form name=value). These whole set is called the environment. When shell is invoked, it scans its environment and stores these environment var to pass it to any pgm, that is invoked from within the shell. Whenever any pgm is invoked, shell passes these env var to child processes. Some var are already set by default, as PATH, DISPLAY, SHELL, USER, etc. We can also add new var or modify existing var. Syntax differs slightly b/w bash and csh (more details in bash and csh sections.

csh:

setenv X_ROOT /some/specified/path
setenv XDB    ${X_ROOT}/db
setenv PATH   ${X_ROOT}/bin:${PATH} => PATH env var is unique in sense that we are adding values to PATH w/o deleting the old ones. To append new values, we use :

bash:

X_ROOT=/som/paths => This just defines a var X_ROOT with some value. However, it is not a env var
export X_ROOT => keyword export makes this var an env var, and it's now available to all child process

export X_ROOT=/some/paths => this cmd is equiv to above 2 cmds combined.

using Linux cmd "env" prints all these env var with their values. There are few other uses of env cmd:

1. env is used to run pgms, instead of running them directly. This is useful in cases where we do not want any aliases, shell functions, shell builtin cmds to replace or alter args of any cmd run from within shell. Since env is an external cmd, it has no knowledge of aliases, and simply passes the pgm and it's args to an "exec" call.

ex: env name=value name2=value2 program and args => here pgm and args are preceeded by extra env var whose values are as defined. This runs the cmd "program and args" with an environment formed by extending the current environment with the environment variables and values as shown. This is helpful in cases, where we want just this pgm to have these appened env var, but still leave the env intact for the current shell

ex: env -i <your cmd> => -i ignores environment completely when running the cmd. This is generally useful when creating a new environment (without any existing environment variables) for a new shell. ex: env -i /bin/sh => Here new bash shell is created with environment completely cleared out.

ex: env -u VAR1 => This unsets VAR1 environment variable

2. env is used as first line in scripts. The reason is this => env always searches the PATH for cmd. So, if we provide first line of bash script as #!/bin/bash, it's possible that bash is not in bin dir. Even if bash is in bin, #!bash doesn't work (even though PATH variable has /bin in it). This happens because the first line doesn't search the PATH variable for that bash pgm. To avoid specifying a hardcoded path to bash, we do this:

ex: #!/usr/bin/env bash => Here env being an external program searches PATH for bash pgm, which it finds in /bin/bash, and then runs that pgm called "/bin/bash". NOTE: this still requirs absolute path for env, but env is almost always in "/usr/bin/env" on Linux systems.

NOTE: When Bash invokes an external command, the variable ‘$_’ is set to the full pathname of the command and passed to that command in its environment. 

9. grep: Global Regular Expression Print. Most powerful for searching any pattern in multiple files across dir hier. This cmd is most widely used unix cmd. Lots of options available that you should look into.

detailed usage here: https://www.computerhope.com/unix/ugrep.htm

grep <pattern> file_name => As explained under regular expression section, pattern is Regular expression while filenames are simple glob patterns. By default, grep patterns are BRE, but can be made ERE with -E. To search for any pattern as it is without interpreting it, use -F (this means searching for /a/b#[$"/ef\f will serach for this pattern exactly w/o interpreting any character as special character). Using -F is same as using fgrep (called as fast grep), and using -E is same as egrep (called as extended grep) but usage of fgrep and egrep is deprecated. -r is used to earch recursivel, and is same as using rgrep.(-r doesn't search thru soft links, use -R for that) grep returns names of files that match the given pattern along with the line that matched (separated by :).

grep --color "am(18a)" *.txt => This will search for BRE "am(18a)" as ( ) are not treated as metacharacters (but instead as literals) by default in BRE, so they do not need to be escaped. If we do escape them "am\(18a\)" then they will match "am18a" and anything matching 18a can be recalled later using \1. --color highlights the matched patterns.

grep -E "am\(18a\)" *.txt => This is exactly same as above (w/o the highlight for matched pattern). It will search for ERE "am(18a)" as ( ) are treated as metacharacters (and not as literals) by default in ERE, so they need to be escaped. If we do not escape them "am(18a)" then they will match "am18a" and anything matching 18a can be recalled later using \1.
grep -A 5 -B 4 "anon" *.txt => This will search for "anon" in all files, and then print 5 stmt after and 4 stmt before each matching line.
grep -rl "myname" . => searches for string "myname" in all files of that dir recursively. -l prints file names with a match

grep "name1" */*/*.tcl => This searches for "name1" in all files ending with .tcl extension in dir 2 levels down. If we use recurive option then grep -r "name1" *.tcl doesn't work (It will say doesn't match anything, even though there may be matches in .tcl files).

grep -r "name1" --include="*.tcl" . => With -r option, use option --include="*.tcl" to search only in .tcl files. "." in the end implies search in current dir.

grep -E "^start|^end" *.txt => To find all lines starting with either "start" or "end". Here | is or operator only available in Extended expression, so use -E (though grep "^start\|^end" works too implying | is valid in RE as long as escape char \ is used before it)

zgrep: grep doesn't work on zipped (compressed) files. zgrep is used instead in such cases. Most options remain the same as grep (-r or recursive doesn't work on zgrep).

ex: zgrep "abc" rpt.gz

10. find: find is other very powerful cmd to find any file or subdir in any dir matching a given name. This is very useful where you partially remember name of a file, or you want to find all files with a given file extension, etc. This searches recursively in all subdir starting from a given dir. Lots of options available that you should look into.

detailed usage here: https://www.computerhope.com/unix/ufind.htm

Both dir path and name of file are provided as glob pattern. Quotes are needed when pattern provided for name of file. Without quotes or some other mechanism to escape metacharacters, the patterns would be expanded be shell, which may give incorrect input to the "find" cmd. We want "find" cmd to see the pattern in the name of file, so we use single or double quotes.

find /dir1/dir2 -name file1 -type f => Find files named file1 in or below the directory /dir1/dir2. Here the file name "file1" needs to match exactly, i.e file11 won't match. "-type f" means find only files with given name, while "-type d" means find only dir with given name
find /home/docs/ -name "*driver*" => lists all files starting from dir "docs" that have "driver" in part of their name. This will match my_driver, driver.txt, or any such files

find . -iname "*.Php" => . means start searching from current dir. option -iname ignores case, so test.php, test2.PHP, test3.Php all match

find ./test ! -name "*.php" => ./test means start searching from "test" subdir in current dir. ! does invert match, i.e all files which don't end in .php. Instead of !, we could also use "-not" for invert matching

find ./test -name ".*.txt" -not -name "*.php" -o -name ".*.rpt" => Here we have multiple criteria with -name. However -not means not match .php, while -o means or, so match names with .txt or .rpt

find /home/*/project/*/*/code/ -name "*my_test?_??_.*.txt" => Here we match in multiple dir since * is in dir name. Pattern matching matches my_test1_00_rpt.txt, my_test2_99_.txt, etc.

find -mindepth 2 -maxdepth 3 /home/docs/ -name "*driver*" => This cmd is used to limit search to certain depth, otherwise find serches all the way to leaf dir. Here, it starts search from 2 dir below /home/docs and stops at 3 dir below that, so in essence it searches in only 2 dir at /home/docs/*/*/*driver* and /home/docs/*/*/*/*driver*. "-mindepth 1 -maxdepth 1" is used to search in current dir only without going any deeper.

11. cut: cut text from lines. cut can do most of what we do using scripting languages as perl, sed, etc.

cut -d":" -f2,4 file_in > out_file => This cuts the file using delimiter ":". By default delimiter is TAB (not individual space), so if you have TAB separated text, then you can omit -d.  To cut it by a sinngle space, do -d" ". After cutting, it names the columns as f1, f2, f3, etc that are separated by this delimiter. f2,4 says that print out column 2 and column 4. The output is then printed to out_file.

more file1 | cut -d'=' -f1 | grep REG2 => This cuts each line of file "file1", with delimiter =, and names fields as f1,f2 with = as delim. Then it takes field f1 out and prints it. Then grep prints only those lines that have REG2 in them
ex: CONFIG_REG2.RESERVED = new("RESERVED", 26,..) => for this file, cmd above gives CONFIG_REG2.RESERVED

grep and cut cmds may be combined via pipe to edit multiple files.

ex: grep "assign SDA" tests/I2C/*/test.v =>this may return o/p which is something like as shown below (names of files where pattern was found, along with the line where it matched separated by :) then cut gets file names, and then we checkout those files
tests/I2C/dir1/test.v:assign SDA = 1'b0
tests/I2C/dir2/test.v:assign SDA = 1'b1;

ex: cut -d":" -f1 => If we apply cut cmd to above o/p, then we get f1, which is names of files. Then we can do whatever we want with these files.

ex: grep "assign SDA" tests/I2C/*/test.v | cut -d":" -f1 | xargs cleartool co -nc => The 1st part greps "assign SDA" stmt and lists all the files that have it. Then we use ":" as delimiter, and extract name of files. Then "xargs" cmd takes all the names of files as arguments to cmd "cleartool co -nc". So, this causes all files to be checked out which had that "assign SDA" stmt in them.

ex: grep "assign SDA" tests/I2C/*/test.v | cut -d":" -f1 | xargs sed -i 's/assign SDA/assign #10 SDA/' => replaces "assign SDA" with "assign #10 SDA" using sed to all files that have this line. sed cmd explained later.

ex: more ~/z.txt | tr -s " " | cut -d" " -f2 | less => Here we are cutting by single space. If our text contains multiple spaces, then use "tr" cmd (explained below) to squeeze multiple spaces into one.

12. sort: sort is another very useful cmd to sort lines in a file. It sorts lines alphabetically (not ascii), and then prints o/p on screen. -u sorts them uniquely (i.e if it finds multiple lines with exactly same content, it only prints 1 of them)

ex: : grep Scope /sim/.../violations.txt | sort -u => It looks for "Scope", and then sorts them uniquely. This is very useful to uniqify gate level timing violations coming from cadence simulator.

sort can also be used to sort on specific columns separated by space (instead of from start of line) by using option "-k <col_num>", and can sort numerically on that entry (instead of sorting alphabetically) by using "-n" (sorts from smallest to largest number). -r reverses the sorting order (irrespective of whether it's ascii sorting or numerical sorting)

ex: grep "me" *.txt | sort -n -k 3 > sorted_col3.txt => This sorts the file based on entries in 3rd column and does that numerically. So, if 3rd col has 21, 36,05, 17, then it will sort as 05,17,21,36.

13. tee: used in complex pipes to record some stage o/p (diverts copy of that to the named file).
syntax: tee [ -ai ] file_list
-a => appends o/p to existing file, w/o this file is overwritten.
-i => Ignore interrupts. If you press the Delete key, tee ignores the interrupt signal sent to it and continues processing.

Ex: sort somefile.txt | tee sorted_file.txt | uniq -c | head 12 > top12.txt

14. list: returns list comprised of all the args. braces and backslashes get added as necessary
syntax: list ?arg ... ?arg
ex: list a b "c d e " " f {g h}" => returns this: a b {c d e } { f {g h}}

15. tr: This translates, squeezes or deletes characters. It takes input from STDIN (not a file), and writes to STDOUT. So, we can only use this cmd in a pipe |, or provide the text directly. With tr cmd, -d deletes, -t renaslates and -s squeezes each input sequence of a repeated character that is listed with a single occurrence of that character. This cmd is very useful to use to pipe to other unix cmds, which don't handle multiple spaces.

ex: more ~/z.txt | tr -s " " | less => This truncates multiple spaces in file z.txt with single space. Now, this can be used with "cut cmd" for ex. See in cut cmd section above.  

16. system cmds: These are cmds that show system related info.

ps: process info
ps -ef => lists all running process. /proc/ dir has all process in it as separate dir (with PID name), with files containing details about processes.
ps cmd greps process PID and other details from this /proc/ dir

lsof: list open files

lsof -D dir1/ => This lists all open files in a given dir, and the process which is using them. -D option is needed only if we want to recursively apply it on all the files in the dir. To apply on a single file only "lsof <file>". This is very helful, when you can't delete a file due to "device/resource busy", and ps doesn't show which process is keeping it open. This is reverse of "ps" where it says which process has that file open, and then we can kill that process using kill -9 <pid>.

uname: info about system
~ [538]$ uname -a => prints all system info: kernel name, hostname, kernel-release/version, macine, processor, h/w platform and OS.
Linux lindesk51.dal.design.ti.com 2.6.9-89.0.16.ELxenU #1 SMP Tue Oct 27 04:12:25 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
NOTE: above cmd doesn't show which Linux is used. To find that, do: ls /etc/*rel*. If it shows one of the files as "/etc/redhat-release", then its redhat OS. If it shows "/etc/SuSE-release", then it's SuSE OS. You can see the version number by looking into this file. As an ex for centOS: /etc/centos-release file shows => "CentOS Linux release 7.7 (core)" implying it's version 7.7
Other way to find OS is to run: lsb_release -a => std unix cmd which prints certain LSB (Linux Standard Base) and Distribution information. -a displays all info.

hostname => shows name of the host on which this cmd ran.

who/w: who and w cmds  displays info about all users on that machine. w cmd provides more details than who and also shows what processes they are running.

which: shows the full path of any cmd (i.e path of binary or pgm being executed). This is very useful cmd to see where any pgm is getting executed from.

ex: which ls => /usr/bin/ls => this shows that path to unix cmd "ls" is as shown

file: return the "type" of a file.

ex: file my.png => PNG image data, 1600 x 900, 8-bit/color RGB, non-interlaced

type: indicates how its argument would be interpreted if used as a command. If cd s aliased to something else, it would show that. See args for type cmd.

ex: type cd => returns "cd is a shell builtin"

NOTE: It only seems to work on bash shell, not on csh.

whereis: locate source, executable image, and/or manual pages for a command. this is a superset of "which" cmd, which also shows source of code, manual pages, etc. This is one of the most underrated cmd, and is very helpful

ex: whereis ls
ls: /usr/bin/ls /usr/share/man/man1/ls.1.gz /usr/share/man/man1p/ls.1p.gz

17. super user or root user cmds:

Whenever Linux is installed, a user with username "root" is created by default, and we set a password for root user at that time. Then we can create additional users, setting their own passwords. Root user is also called superuser, and has write permission to all files in system. / dir is called root dir, and root user has read/write permission to everything under this root dir. The prompt will change to "#" (from "$" in bash or "%" in csh) to indicate that current user is root. If user's name is displayed, then it will show root# for root and ashishb$ for other users.

sudo: super user do. "super user" and "root" are used interchangeably to imply a user who has admin rights. Most cmds for making any changes in Linux system (i.e install new software, etc) are allowed by root user only which has also system privileges. This is done for security reasons. However, since most of the users login into their own account, they can't have root privileges. sudo is the cmd that allows us to achieve that. By typing sudo before any cmd that requires root privileges, we temporarily allow current user to fake as a root user, and allow him to run that cmd. This cmd has many options, details here: https://www.sudo.ws/man/1.8.16/sudo.man.html

ex: sudo yum install tcl => yum install is reserved for root user only, so if any other user tries to run "yum install tcl", it will give "privilege error". However, by appending "sudo" before the cmd, it allows current user to act as root user for this cmd only. It will ask for current user password (NOT the root user password), and on matching password, it runs this cmd w/o issues.

So, sudo allows us to run a privileged cmd w/o logging in as root. This is most preferred way, as we don't have to login as root. So, the question is how is it secure? It's secure because only those users whose username match against names in special file called sudoers (in /etc/sudoers) are allowed to run the sudo cmd, and which cmds they can run is also specified in this file. Others will need to login as root by using su cmd. Other users on system can be granted super user rights by adding their user names to this file, and also specify what cmds that can be allowed to run.

sudo can be used to change user to root (similar to su cmd below):

sudo -i => -i or --login allows us to login as target user. Here, since sudo cmd is used, target user is root. So this allows us to login as root in that teminal, so that we don't have to type sudo cmd all the time. We see prompt change to root# from sanjay#. Now we can type any cmd w/o sudo prefix. This does what su cmd does below. su cmd below to change to root user doesn't work in ubuntu, but this cmd works.

su: switch user. This is similar to sudo cmd, but this is used to switch user from current user to any other user whose account exists on system. However, here we need password of the other user whose a/c we are switching to.

ex: su ashishb => this asks for the password for user "ashishb", and on matching the password, switches to user account "ashishb" from current account. However, this doesn't switch the environment of current user to ashishb env, so cmds as cd, running executables with permissions set to ashishb may not work. To get even the env of new user, we have to do proper login into other user via - or -l, i.e: su - ashishb (or su -l ashishb) => this switches the env to ashishb env

ex: su => su cmd w/o any options switches to root account. That is why sometimes su is abbreviated as "super user". However, we need to know the root password for this. Moreover, just as in sudo, su w/o - sign, doesn't switch the env to root, but when we use "su -", the env of current user switches to root (i.e pwd will print /root instead of /home/ankitk as user's current dir)

Other way to switch to root account is via "sudo -i".

To logout from root, run "exit" or "logout" to return back to your normal user account. "su -" (instead of just su) is preferred way to login as root, since this command simulates a complete root login (running init script, setting env var, etc)

Ubuntu root account:

Root account is setup on most linux distro when installing but is not done for ubuntu based derivatives. This means that you don't get to choose a root password for ubuntu based systems. Actually, the developers of Ubuntu decided to disable the administrative root account by default by not assigning a root password.

Article on enabling root a/c: https://www.computernetworkingnotes.com/linux-tutorials/how-to-enable-and-disable-root-login-in-ubuntu.html

So, when we run su cmd for ubuntu based systems, and provide a password, it will always say "incorrect password". We can enable root account as shown in link above. But using "sudo -i" works too.

CentOS root account:

In CentOS, su cmd works by default as root password is setup during installation. (If on single user system, default user is also assigned as admin, so that user's password is also the root password).  Now we can run any cmd w/o needing to enter "sudo" for any cmd, as we are root user and have all the privileges.

misc cmds: These cmds have been explained in other sections of linux, so look over there too for other details.

lsblk: lsblk cmd is explained in "File systems". It allows us to list all devices. 

dd: dd cmd is explained in "File systems". It allows us to copy contents of any device.

printer cmds:

lpr: print to printer
1. lpr -P LKE_4001 file.txt => prints file.txt in non-duplex mode. We can set options, to print it in desired way. for that we provide options with -o
. We can get valid option names for a printer by runnig cmd "lpoptions" on that printer. Different printers have different options
2. lpoptions -p LKE_4001 -l => gives all options for named printer. For ex: for duplex, we see option "Duplex/2-Sided Printing: *None DuplexNoTumble DuplexTumble" meaning option_name is Duplex, and option_value is cauurently set to none, although others values allowed are "DuplexNoTumble" and "DuplexTumble".
3. lpr -PLKE_4001 -p -o Duplex=DuplexNoTumble -o HPwmFontSize=pt30 file.txt => -p is used for pretty printing. default fontsize of pt48 too large, so using pt30
4. lpr -PLKE_4001 -duplex test.txt => instead of above, we can use this as for every printer that can duplex, there exists a -simplex and -duplex queue that simply forces either option

a2ps: converts to ps format
a2ps -s 2 -P LKE_4001 file.txt => prints duplex. use option -Pvoid to print to void printer(displays no. of pages that it's going to use). -f8 prints using font size=8.

enscript:
enscript -BH -r -2 -dLKE_4001 -fCourier7 -DDuplex:true file.txt => prints in a pretty format. alt to a2ps

lpstat: printer statistics
lpstat -d -p => gives names and desc of all printers connected.

misc programs and useful utilities: There are many other useful pgms included in all major linux distro by default.

tar/untar, zip/unzip: these cmds are actually linux pgms to compres/decompress files and dir. First tar is used to put the whole dir into a file (.tar), and then gzip/bzip2 is used to compress that file (.tar.gz). gzip/bzip2 compression doesn't directly work on dir, so we've to use tar. Both gzip and bzip2 compression algo are supported with tar, though gzip is more common. bzip2 has higher compression rate, but takes more time to compress. To get our dir back, we do the reverse: gunzip first and then untar (i.e tar with diff option). The resulting file .tar.gz/.tar.bz or .tgz/.tbz is called a "tarball". .gz is for gzip while .bz or .bz2 is for bzip2

• Tar and zip: First tar and then zip.
  
  • tar -cvf file1.tar dir1 => tars dir1 into file1.tar and puts the named tar in current dir. Option -c => create archive, -v=> verbose mode where progress is diplayed on terminal, -f => filename of archive (here it's file1.tar). W/o -f, tar will be created with same name as name of dir being tarred (i.e dir1.tar). We could also create tar of files by providing names of files or isung glob (*, etc). ex: tar -cvf file1.tar dir1 dir2 dir3/file1 file4 => This puts all these in a single tarball. "--exclude=file_name_pattern" switch can be used for each directory or file you want to exclude (so that not all files within a given dir are included in tarball).
  • gzip file1.tar => zips file1.tar into file1.tar.gz and puts it in current dir. .gz file is compressed to about 1/4th the orig size.
  • Both the cmds above can be combined into one by adding "z" option to tar which says zip the file using gzip compression too. -j compresses it using bzip2 compression algorithm. ex: "tar -zcvf archive.tar.gz directory/"
• Untar and Unzip: First unzip and then untar.
  
  • gunzip file1.tar.gz => unzips file and creates file1.tar file. If we want to keep existing tar file, and create new untarred file (usually in cases where we don't have write permission for that dir), we can use -c option of gunzip. The -c option will write the unzipped data to stdout and will not remove the original .gz file. We rediect this stdout to a file: ex: gunzip -c file1.tar.gz > ~/file1.tar
  • tar -xvf file1.tar => leaves original tar file intact. extracts all files from the tar file, and keeps them in same dir with dir name=file1. To get content of only desired files, we can provide names of files/dir and only those will be extracted, i.e "tar -xvf file1.tar file1/file2 file1/dir3/file3" => extracts only these files/dir in "file1" extracted dir.
  • Both the cmds above can be combined into one by adding "z" option to tar which says gunzip the file too. ex: "tar -zxvf archive.tar.gz". switch "-C ~/dir2" will extract the archive in ~/dir2 dir.
• Viewing contents w/o untarring or unzipping: We can extract files above using unzip and untar shown above. However, many times we've to look thru bunch of tar files, and it's not always possible to untar.unzip everything as it takes time and lots of space. We just want to look at contents of tarball or search for patterns in individual files. For this use below options:
  • less file1.tar => This will show all subdir and files inside the tarball. Won't show contectn of files though
  • zgrep -Hna "my*pattern" file1.tar => zgrep will search for given pattern "my*pattern" in individual files of the tarball. -H lists the filenmae that contains the mtach, -n shows the line number while -a treats all files as text files. Unfortunately -H doesn't show the individual filename, but only the tarball name which is not very helpful. "--label=filename" may also be added to zgrep to search only in given files.
  • tar -tvf file1.tar dir1 =>This shows the contents of archive. -t flag specifies that we need to only view the contents of the archive. This is same as using "less" above
  • tar -xOf /dir1/*.tar.gz */logs/syn.*.log => Option -O (NOT zero(0) but capital O) will not extract the files on disk, but will rather extract i to standard o/p (On screen). We can pipe it thru "less" to view the file or search for any pattern using grep. Very helpful option.

openssl: This is a linux pgm to encrypt/decrypt files, openssl supports wide range of ciphers.
openssl aes-128-cbc -e -in file1 -out file1.aes -K -iv 0 => uses aes for encryption (openssl enc -ciphername => openssl ciphername).e=encrypt, d=decrypt, i/p=file1, o/p=file1.aes, -iv specifies actual initialization vector(IV) to use. The cipher modes CBC, CFB, OFB and CTR all need an IV. -iv must be used when only the key is specified using -K, and no password is specified (-k or -pass specifies the password to use). IV should consist of hex digits only. A new, random IV should be created for every encryption of data. Think of the IV as a nonce (number used once) - it's public but random and unpredictable. -nopad disables padding (otherwise encrypted data is larger than i/p data, as engine adds extra bytes to i/p). key is in hex only (-K F01A95...4C => no need to use 0x...)

od: octal dumping pgm. Can also dump hex, decimal or ascii. -a=ascii, -x=hex, -d=decimal, -o=octal. See c_pgm_lang.txt for ASCII codings.
ex: od -a test1.txt (test1.txt has: abcd CR 1234 CR tab CR)
0000000 a b c d nl 1 2 3 4 nl ht nl => shows byte 1 is a, byte 2 is b, byte 5 is newline, byte 11 is tab(ht) and so on.
#NOTE: we can od for an executable file to see what's in there. Usually it's long, so do "head" to see only first few lines
od hello | head

sendmail: email: /usr/sbin/sendmail This email address is being protected from spambots. You need JavaScript enabled to view it.

diff: diff is very important pgm to find out differences b/w 2 text files. It's used very often. However, it's o/p is little cryptic, so "tkdiff" is used which is gui rep of differences. meld (open source) and bc (beyond compare, a proprietary tool) are other gui based diff tools which can diff entire dir recursively.

ex: diff -c file1.txt file2.txt => shows differences in content of file1.txt vs file2.txt. file2.txt is treated as reference for comparison purpose. o/p is little cryptic. To make it more human friendly, use option -c

ex: diff --color -c -i -w file1 file2 => here differences are highlighted in red color. -i ignores cases. -w ignores all white spaces (this is very helpful, where we don't want space differences in different files to be reported as actual diff). there are many other variants of space diff such as -b which ignores changes in amount of white space, -E,(ignores changes due to tab expansion), -Z (ignores white space at line end), -B (ignore blank lines), etc.

ex: diff -qr dir1/dir2 dir3/dir4 => -q only shows if files are different w/o showing actual differences. -r does recursive comparison for any subdir too, for all files in given dir

cron/at: Many times, we want to run a script automatically every day or at particular times. This can be easily be done via 2 cmds that are widely supported in Linux OS. However, you will need to install the software, if it isn't included by default.

• cron: "crond" is the cron daemon (background service) that runs cron jobs.
  
  • To install, type => sudo yum install cronie (for RPM OS m/c). Then start and enable service using systemctl.
  • To add jobs to cron, we ned to add jobs to crontab file. Open it using crontab -e.
  • Syntax for each cmd is => <time/date to execute> <cmd_to_execute>. There are 5 fields for time/date. 1st field is for inute, 2nd for hour, 3rd for day of month, 4th for month, 5th for day of week.
    • ex: 20 3 * * * /home/run_it.sh => This will run "run_it.sh" script everyday at 3:20am
• at: Many times, we need to run a job only once in future and never again. at is easier to use in such situations. Also, many times we don't have admin permissions to run cron on other m/c, in those cases at can stll be used. Similar to cron, at has it's daemon, "atd" that runs at jobs.
  • To install, type => sudo yum install at (for RPM OS m/c).
  • Syntax for running a acript at specific time => at <time/date> -f <script_name>
    • ex: at 3:50 -f ~/my_script.csh => This wll run script at 3:50am
  • To use at for running daily jobs, we can use a trick used in other scripts => We run the script using at, and then schedule the same script inside the main script. This way, the script will run once and then reschedule itself to run again after specified time. Ex below makes the script run every 24 hrs.
    • my_script.sh => (Add this line in script) => ./daily/script_daily.csh; echo "$0" | at now + 24 hours
    • chmod 755 my_script.sh
    • ./my_script.sh | at now

Details

Published: Sunday, 10 March 2019 22:24

Hits: 1045

Aside from Gnu Autotools, one other tool that is very popular for building projects is "CMake". Just like GNU Autotools, it's open source and cross platform. It also provides support for testsing and packaging using Ctest and Cpack. Cmake project started in 2000. The executable pgms Cmake,  Cpack and Ctest are all written in C++. CMake/CPack/Ctest are case insensitive, meaning that we can write name of pgms, files or text in files in any case, and it will mean the same (for ex: CMake can be written in any case, i.e cmake, Cmake, etc, and it still runs correctly).

Links:

https://cmake.org/cmake-tutorial/

https://www.johnlamp.net/cmake-tutorial.html  => whole tutorial also avilable on pdf: https://www.johnlamp.net/files/CMakeTutorial.pdf

 https://ecrafter.wordpress.com/category/programming/

https://ilcsoft.desy.de/portal/e279/e346/infoboxContent560/CMake_Tutorial.pdf

Just as Make uses Makefile which is used to build source code, CMake has CmakeLists.txt files. These describe your project to CMake. Cmake generates Makefiles for you in Linux, instead of we writing it manually. Then we run make using these Makefiles to create executables and libraries, just as we do with regular make. These Makefiles are native build files (i.e generated based on what's available on current system), so can be run on that system (hence called cross platform)

CmakeLists.txt are fairly simple especially compared to Makefiles.Note Cmake is also inteneded for other platforms as Microsoft Windows and Apple Mac, so it is used to generate other build system other than Makefiles. We'll talk only about Unix Makefile generation using Cmake, as that is what Cmake is used for on Linux platforms.

A simple 3 line CmakeLists.txt is as follows:

CMakeLists.txt: NOTE: End of each line is signaled with newline, no ; or anything else needed to signify end of line

cmake_minimum_required(VERSION 2.8 FATAL_ERROR) #This line is optional, but is strongly recommended. This adds version number. 2.8 as version number. Last option "FATAL_ERROR" is optional. This whole line says that if version of cmake is < 2.8, then cmake would error out with FATAL ERROR. If you aren’t sure what version to set use the version of CMake you have installed (cmake -version). It is recommended that this command be used in all top level CMakeLists.txt

#This is comment. Comments can also be used at end of cmd on same line as shown in above line. Multi line comments are as #[ ... #]
project("My tutorial") => Name of project, if name has spaces, put them inside " "

add_executable(tutorial tutorial.cxx) => This command tells CMake you want to make an executable and adds it as a target. The first argument is the name of the executable and the rest are the source files. You may notice that header files aren’t listed. CMake handles dependencies automatically so headers don’t need to be listed. 

 Once we have this file in a dir, we can run cmake. We will do an out of source build, where we create all new files in a separate dir. This is a recommended approach for any build software, as it keeps generated files separate from source files. We can also do in source build where we create all new files in same dir, but in source build are not preferred.

Let's start with same example as of the tutorial in Make:

 /home/aseth/ => cp hello.c and config.h in this dir.

Create CMakeLists.txt as below, with only 2 lines:

project("My tutorial") # Name of project,if multiple words, separated by spaces, put them inside " "
add_executable(hello hello.c) #name of config.h is not put here, as CMake handles headers automatically

mkdir build
cd build/
cmake -G "Unix Makefiles" .. => This creates "Makefile" for us in same dir as "Makefile". (option -G provides Generator name, here we create Unix Makefiles as generator). It also creates couple of subdir here. ".." is needed since that specifies path of CMakeLists.txt, which is 1 level up. Here we are doing an out of source build as we are in a separate dir build. If we were doing an in source build, by running this cmd in main dir (/home/aseth), we would have to replace ".." with "." as that specifies the path of CMakeLists.txt which is now in current dir for in source build.

Build package => similar to AutoTools
make VERBOSE=1 => runs make as you would with a Makefile created manually. Makefile created above by Cmake is quite fancy. It suppresses the standard output. While this provides a neater and cleaner experience it can make debugging more difficult as you can’t check the flags passed to the compiler, etc. We can get all of that output by running make VERBOSE=1.

NOTE: in make cmd above, we didn't specify a target. If you look at Makefile generated by cmake above, you will see it has lot of std targets as all, clean, etc. By default, target "all" is run, so above cmd is equiv to "make -all VERBOSE=1"

executable hello is created in this build dir. object files for hello and other related files are all created in CMakeFiles/hello.dir subdir.

Install package => similar to AutoTools

make install => we can omit build step above, as both build and install can be handled by this cmd

CMakeCache.txt => this is one other important file created during build process, in build dir itself. It has entries of form: VAR:TYPE=VALUE. It speeds up build process. There is no need to modify it manually.

Syntax: All files in CMake are written in CMake syntax. All details of syntax can be found on CMake website. We'll just discuss important ones.

Variables: Cmake comes with list of predefined var as CMAKE_BUILD_TYPE, etc. These Variables can be changed directly in the build files (CmakeLists.txt) or through the command line by prefixing a variable's name with -D (i.e -DBUILD_SHARED_LIBS=OFF )

CMAKE_MODULE_PATH => Path (dir) to where the CMake modules are locate. These CMake modules are loaded by the the include() or find_package() commands before checking the default modules that come with CMake. By default it is empty, it is intended to be set by the project.

CMAKE_INSTALL_PREFIX => Where to put files when calling 'make install'

CMAKE_BUILD_TYPE => Type of build (Debug, Release, ...)

BUILD_SHARED_LIBS => Switch between shared and static libraries

We can change predefined var or define our own variables using set cmd. Data type for variables are strings and list (which are lists of strings). All var can be accessed via ${VAR}.

set(STRING_VARIABLE "value")

set(LIST_VARIABLE "value1 value2")

To print the value of a variable, use the message command and deference the variable using ${}:

message("The value of STRING_VARIABLE is ${STRING_VARIABLE}")

ex:

set(CMAKE_CXX_FLAGS "-Wall -std=c++0x") => this sets additional compiler flags to be applied to both compiler and linker. This var is predefined var, but we can assign any value to it.

Conditional constructs:
1. IF() ... ELSE()/ELSEIF() ... ENDIF() => ex: IF (UNIX)

2. WHILE() ... ENDWHILE()

3. FOREACH() ... ENDFOREACH()

CMake Modules: Special cmake file written for the purpose of finding a certain piece of software and to set it's libraries, include files and definitions into appropriate variables so that they can be used in the build process of another project. (e.g. FindJava.cmake, FindGSL.cmake)

GSL_FOUND          - True if GSL found on the local system
GSL_INCLUDE_DIRS   - Location of GSL header files. => all include dir. Here, it's same as GSL_INCLUDE_DIR
GSL_LIBRARIES      - The GSL libraries. => all library, here it's both of these: GSL_LIBRARY, GSL_CBLAS_LIBRARY
GSL_VERSION        - The version of the discovered GSL install.

Packages: Packages provide dependency information to CMake based buildsystems. Let's say we installed a package for OpenCV. This package might have been built with CMake or may been built with any other pkg building software as AutoTools, etc. If package was built with CMake, then , then it has "<name>Config.cmake" (i.e OpenCVConfig.cmake) file associated  with it. This is called as Config-file package. If CMake was not used to make OpenCV, then we need to write a new file named Find<name>.cmake file (i.e FindOpenCV.cmake), and put it in the directories listed in MAKE_MODULE_PATH. This is called as Find-module package. Now, in order to use this package in another project, we have to tell our new project, how to find this package. Packages are found with the find_package() macro. Both of this kind can be found using find_package() cmd.

1. Find-module Packages => These are the ones that have Find<name>.cmake file associated. This is the default package type that is assumed for any package (i.e CMake assumes that external package was not built with CMake). In order to use YARP package in new project called "hello", CMake searches the directories listed in CMAKE_MODULE_PATH for a file called Find<name>.cmake. If found, this macro is executed and it is responsible for finding the package.

FIND_PACKAGE(YARP) => searches for file named FindYARP.cmake in dir specified by CMAKE_MODULE_PATH 

2. Config-file Packages => These are the ones that were built with Cmake and have "<name>Config.cmake" or or <lower-case-name>-config.cmake files associated. This file is created in build dir selected by user, when CMake was used to build that package. In order to use YARP package in new project called "hello", we specify the location of this file by filling a cache entry called <name>_DIR (this entry is created by CMake automatically). If the file is found, it is processed to load the settings of the package (an error or a warning is displayed otherwise).

So, we set YARP_DIR to appr dir where this file is, and then use FIND_PACKAGE macro.

SET(YARP_DIR "$ENV{YARP_ROOT}") #We can also specify DIR directly as \usr\include instead of having env var
FIND_PACKAGE(YARP) => searches for file named YARPConfig.cmake or yarp-config.cmake in YARP_DIR specified above.

YARPConfig.cmake creates the entries YARP_LIBRARIES, YARP_INCLUDE_DIRS and YARP_DEFINES. To use these in a project, do:

  INCLUDE_DIRECTORIES(${YARP_INCLUDE_DIRS})
  ADD_DEFINITIONS(${YARP_DEFINES}) # optional
  ...
  TARGET_LINK_LIBRARIES(your_target_name ${YARP_LIBRARIES})

include:  include(file|module) => Load and run CMake code from a file or module. If a module is specified instead of a file, the file with name <modulename>.cmake is searched first in CMAKE_MODULE_PATH, then in the CMake module directory. 

ex: include(FindGSL) => searches for FindGSL.cmake and runs it.

1. find_module(Qt4 MODULE) =>

1. pkg_check_modules(<PREFIX> <MODULE>) invokes pkg-config, queries for <MODULE> and returns the result in variables which have names beginning with <PREFIX>_. Thus module is the name of the software you or pkg-config are looking for.

With "pkg-config --list-all"  (type this in build dir on linux shell cmd line) you get a list of all modules known by pkg-config. If your <MODULE> is not listed here, then  pkg_check_modules can never find it. If it does find it, use "pkg-config --modversion <MODULE>" to find what version of <MODULE> it's finding.

Ctest:

/usr/local/------

Now, to enable testing, we can add more lines in CMakeLists.txt :

cmake_minimum_required(VERSION 2.8 FATAL_ERROR)

project("My tutorial") 
enable_testing() #Enables testing for this CMake project. This should only be used in top level CMakeLists.txt. The main thing this does is enable the add_test() command.  
add_executable(hello hello.c)
add_test(HelloTest hello) => The enable_testing() function we added to our CMakeLists.txt adds the “HelloTest” target to our Makefile. Making the “HelloTest” target will run CTest which will, in turn, run all of our tests. In our case just the one.

 CPack:

-------

Details

Published: Wednesday, 20 February 2019 20:35

Hits: 470

Design Reliability:

In chips, we have transistors and wires connecting them. They need to be functioning for 10 yrs or so. We run simulations to account for aging of transstors and wires.

BEOL=Back end of Line (metals and Vias),

FEOL = Front end of Line (transistors, everything below contact)

Transistor reliability: We measure many of these parameter affect for 10 yrs or 10K hrs of operation. FIT (failure in Time) rates are based on 10yrs of operation, so

1. CHC: channel hot carrier: affects Transistor VT
2. BTI: Bias Temperature instability: It degrades VT of Transistor during "ON" state at high temperature. It affects both NMOS and PMOS, though PMOS is affected more (reduces VT for NMOS, increases VT for PMOS => weaker tran).BTI happens when tran is ON, but starts fixing itself once tran is off.
   1. So, there are 2 BTI phase:
      1. Stress phase: here tran is ON, gate bias is max, causing max VT shift
      2. Relaxation phase: here tran is OFF, gate bias is min, reversing VT shift caused by stress phase. It's able to recover 20% of the VT shift caused by Stress phase. So, only 80% degradation of VT remains after Relaxation phase.
   2. Comparing BTI across tech:
      
      1. 180nm device => For PMOS which is contantly ON for 100K hrs @105C, with Vgs=1.8V, ΔVT = 10mv. 10mV is acceptable since there's already enough margin built into design.
      2. 10nm FinFet device => for NMOS, it's about 10mv, and PMOS is 50mv (assuming worst case 100% ON). At 1V applied across src/drn for 1nm device, Field is 1V/nm => 1KV/um, enough to break Si and SiO2 atoms. Better PBTI for finfet. NMOS BTI
   3. 2 kinds of BTI (-ve and +ve):
      1.  A. NBTI: -ve BTI, VT goes down. Here gate is at lower voltage than src, drn and subs. For tran to remain ON, this can only happen for PMOS. It is dominated by substrate interface traps. It's more severe than PBTI.
      2. B. PBTI: +ve BTI. VT goes up. Here gate is at higher voltage than src, drn and subs. For tran to remain ON, this can only happen for NMOS.  It is dominated by bulk HK trapped charges
3.  HCI: same as CHC? FinFet HCI very challenging
4. Self Heating: worse in Finfet as compared to planar, as fins surrounded by oxide.
5. SEU : soft error vulnebility in srm cells, logic.
6. ESD: ESD needed to protect gate oxide. In Finfet, Gate oxide breakdown is lower, and breakdown voltage of devices is also lower (=> FF more fragile). So, equiv ESD requires more area, bigger ESD devices.

Few more reliability notes:

• Effective VT degradation = CHC + BTI
• OverDrive capacity of Tran (i.e how much over voltage can they tolerate): For tran aging, stress voltages applied beyond rated voltages (1 V=rated voltage for 10nm NMOS/PMOS, stress voltage =1.2V), and higher temperatures. That's why thin oxide tran not used in IO. We make 2D plot of Voltage and temperature, and check the lifetime of tran, as well as VT shift of tran. We see that higher Voltage (30% higher than rated Voltage, so 1V rated tran stressed to 1.3V) and Higher Temp (> 50C), reduces lifetime of tran to couple of days. Very high voltages of >1.5V and Temp > 50C start causing VT shifts of 50mv or more (else it remains < 10mv). So, to assess Over Drive capability w/o getting the effect of VT shift, experiments limited to 30% voltage overdrive with Temp 50C.
• HTOL stress (high temp operating life): High vol, high temp for 12-24 hrs gets same effect as aging.

Wire reliability:

Wires/Vias may suffer from reliability too. They may develop open/shorts due to multiple reasons.

1. EM: lectro migration: Iavg/Irms/Ipeak calc.
2. Self heating: happens for wires too.