Reg: victim and aggressor net

report path aggressors

Hi all

Plz tell me what is victime net and aggressor net....

What they are checking for Celtic crosstalk analysis tool....

Plz tell me clearly

Thanks in advance
DIN

reg aggressor

Nets switching at high frequency (Ex: clock nets, High freq data nets) (Aggressors) affect the nets adjacent to it (victim). This is due to the coupling capacitance between the two nets.

aggressor@ulz.net

the concept of victim and aggressor comes into play in the "nm" tech. !!!
as the geometry of the chip reduces, the spacing between nets are cramped ... so ther will be cross-talk between the nets

consider 2 nets a,b : a : drive strength is more
b: drive strength is less

in this case "a" is the aggressor and "b" is the victim, hence change on "a" will be reflected in "b" also !!

so the net tht is affected ( cos of the logic change on the other net) becomes the victim and the one tht caused this will be the "aggressor" !!!

WBR
Lakshman

Added after 1 minutes:

effects of cross-talk between nets :
1) can impact on ur setup and hold time
2) can cause glitches

these are the only 2 as far as i kno ... pls add if nebody knows more !!

cross talk slew

Thanks Lakshman,

what will be in that report?
Suppose, if i am using celtic (Cadence tool) for crosstalk analysis.

What will the report infer....
So, in PT-SI or celtic we can come to know whether it is affected or not?
If it is affected then how it will report to us.....
It also generating sdf file....

Suppose if it is affected, what r the thing to consider for reduce this....

DIN

clock net is victim

For functional noise, I believe Celtic will write out a file showing which nets have functional violations that need to be fixed (eco file?). It will also write out a detailed report showing the glitches (as a % of vdd) on all nets. This will show which nets act as aggressors on each victim net, which helps when fixing functional violations.

For delay noise, Celtic writes out both min and max reports (shown in terms of ps or ns) for nets that are made either faster or slower due to crosstalk. These same values are writted to the SDF which you add in to your timing tool. Assuming timing was clean pre-SI, re-run with SDF annotations to see if any new setup/hold violations occur due to delay noise. For each new violation, depending on if the additional SI delay has a big or small effect on the overall path, you can either fix the effected SI net(s) or fix the data path.

Now eco place/route, extract and check timing/SI all over again.

spef crosstalk inputs cdb command file

Hi,

Following is the celtic cmd... plz clarify me few things...
celtic cmd :
read_dotlib -typ $libpath/typical.lib
read_dotlib -max $libpath/slow.lib
read_dotlib -min $libpath/fast.lib

load_netlist \
-top aesctr_top -verilog top.v \
-cdb $cdbpath/typical.cdB \
-spef_annotate filespef.spef \
-vdd vdd -gnd vss
check_timing

process_netlist
read_dc_script constraints/constraints1.tcl

calculate_delay

#set_analysis_mode -single -setup
report_timing -format {instance cell arc load slew delay arrival required}
report_analysis_coverage
report_clocks

#Analyze SI Effects on timing
analyze_noise -delay
generate_report -sort_by noise

After this generate command,

Report Options:
--------------------------------------------------------------------------------
Slack : yes
Sort by : noise (receiver input peak)
Threshold : 10.0 (mV)
Level : VH and VL
--------------------------------------------------------------------------------
Peak(mV) Level TotalArea %AreaTillPeak Width(ps) VictimNet
612.421 VH 216.37 26.85 706.61 ../mc_cntr_out_reg_101_ {../mr_out_temp_101_}

Receiver output peak:
Value ReceiverNet
26.718 (270.000) c_cntr_out_reg_101_/D (SDFFRX1)

Constituents:
Source Peak(mV) Offset(ps) Slew(ps) Xcap(fF) Edge Net TraceBackNet(NoiseType)
Cpl: 216.575 4880.000 121.338 29.147 F ~../mc_cntr_out_temp_101_ -
Cpl: 101.807 4820.000 167.236 15.123 F
aes_pr_key_in[425] -
Cpl: 83.712 4860.000 138.489 11.486 F u



Here what is this report infer?
How to analyze here....
what r the things we have to consider here???

How to generate sdf?
what we will see in glitch analysis and noise analysis report?
How i come to know this is violation or not?

Then timing summary i found in setup :
No of check: 100
setup : 90
untested: 10
means, what it means untested..
how to see the untested path in PT... it means false path ?

Thanks in advance
DIN

Added after 16 minutes:

Hi,

Following is the celtic cmd... plz clarify me few things...
celtic cmd :
read_dotlib -typ $libpath/typical.lib
read_dotlib -max $libpath/slow.lib
read_dotlib -min $libpath/fast.lib

load_netlist \
-top aesctr_top -verilog top.v \
-cdb $cdbpath/typical.cdB \
-spef_annotate filespef.spef \
-vdd vdd -gnd vss
check_timing

process_netlist
read_dc_script constraints/constraints1.tcl

calculate_delay

#set_analysis_mode -single -setup
report_timing -format {instance cell arc load slew delay arrival required}
report_analysis_coverage
report_clocks

#Analyze SI Effects on timing
analyze_noise -delay
generate_report -sort_by noise

After this generate command,

Report Options:
--------------------------------------------------------------------------------
Slack : yes
Sort by : noise (receiver input peak)
Threshold : 10.0 (mV)
Level : VH and VL
--------------------------------------------------------------------------------
Peak(mV) Level TotalArea %AreaTillPeak Width(ps) VictimNet
612.421 VH 216.37 26.85 706.61 ../mc_cntr_out_reg_101_ {../mr_out_temp_101_}

Receiver output peak:
Value ReceiverNet
26.718 (270.000) c_cntr_out_reg_101_/D (SDFFRX1)

Constituents:
Source Peak(mV) Offset(ps) Slew(ps) Xcap(fF) Edge Net TraceBackNet(NoiseType)
Cpl: 216.575 4880.000 121.338 29.147 F ~../mc_cntr_out_temp_101_ -
Cpl: 101.807 4820.000 167.236 15.123 F
aes_pr_key_in[425] -
Cpl: 83.712 4860.000 138.489 11.486 F u



Here what is this report infer?
How to analyze here....
what r the things we have to consider here???

How to generate sdf?
what we will see in glitch analysis and noise analysis report?
How i come to know this is violation or not?

Then timing summary i found in setup :
No of check: 100
setup : 90
untested: 10
means, what it means untested..
how to see the untested path in PT... it means false path ?

Thanks in advance
DIN

agreesor.net

i can answer a few of your questions:

:: how to see the untested path in PT... it means false path ?
in encounter, which sounds like you have, do "report_timing -unconstrained

:: what we will see in glitch analysis and noise analysis report?
encounter will perform clock gating checks, glitch check, unless disabled.

:: How to generate sdf?
setExtractRCMode -detail
extractRC
delayRC -sdf your.sdf