Reg.: vittima e aggressore netto

E

energeticdin

Guest
Ciao a tutti

Plz tell me ciò che è vittima e aggressore netto netto ....

Cosa sono per il controllo celtica Crosstalk strumento di analisi ....

Plz tell me chiaramente

Grazie in anticipo
DIN

 
Reti di commutazione ad alta frequenza (Es: orologio reti, reti dati ad alta frequenza) (aggressori) pregiudicare le reti ad essa adiacenti (vittima).Ciò è dovuto alla capacità di aggancio tra le due reti.

 
il concetto di vittima e aggressore, entra in gioco nel "nm" tech.!
come la geometria del chip riduce, la spaziatura tra le reti sono angusti ...così ci sarà cross-talk tra le reti

prendere in considerazione 2 reti a, b: a: unità di forza è più
b: unità di forza è meno

in questo caso "a" è l'aggressore e "b" è la vittima,
e quindi cambiare su "un" si rifletterà in "b" anche!

in modo netto tht è interessati (cos cambiamento della logica su l'altra rete) diventa la vittima e l'uno tht causato questo sarà il "aggressore"!

WBR
LakshmanAggiunto dopo 1 minuto:effetti di cross-talk tra le reti:
1) possono avere un impatto sulla nostra impostazione e tempo di
2) può causare difetti

questi sono gli unici 2 per quanto riguarda i kno ...pls aggiungere nebody se sa di più!!

 
Grazie Lakshman,

quello che sarà in tale relazione?
Supponiamo, se io sto usando celtica (Cadence strumento) per diafonia analisi.

Quale sarà la relazione inferire ....
Così, nel PT-SI o celtica si può venire a sapere se è o meno?
Se è colpito poi come una relazione a noi .....
Ha inoltre generare file sdf ....

Supponiamo che se è interessato, che la cosa r a prendere in considerazione per ridurre questo ....

DIN

 
Per funzionale rumore, credo si Celtic scrivere un file indicando quali sono le reti funzionali che le violazioni devono essere fissi (eco file?).E 'anche scrivere una relazione dettagliata che mostra i difetti (come% del VDD), su tutte le reti.Ciò mostra che le reti aggressori agire come su ogni vittima netto, che aiuta la fissazione funzionale violazioni.

Per ritardare il rumore, Celtic scrive sia min e max relazioni (in termini di ps o ns) per le reti che sono state eseguite sia più veloce o più lenta a causa di diafonia.Questi stessi valori sono writted al SDF, che si aggiunge al proprio strumento di cronometraggio.Supponendo tempistica era pulita pre-SI, con ri-eseguire SDF annotazioni per vedere se tutti i nuovi setup / tenere violazioni dovute a ritardi rumore.Per ogni nuova violazione, a seconda se l'ulteriore ritardo SI è un grande o piccolo effetto sul percorso, è possibile fissare il effettuati SI netto (s) o correggere i dati percorso.

Ora eco luogo / percorso, estrarre e verificare tempi / SI tutto nuovo.

 
Salve,

In seguito è la celtica cmd ...plz chiarire alcune cose di me ...
cmd celtica:
read_dotlib-tip 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-VSS GND
check_timing

process_netlist
read_dc_script constraints/constraints1.tcl

calculate_delay

# set_analysis_mode-single-setup
report_timing formato (esempio cella di carico ad arco uccise ritardo arrivo richiesto)
report_analysis_coverage
report_clocks

# Analizza SI Effetti sulla tempistica
analyze_noise ritardo
generate_report-sort_by rumore

Dopo questo comando generare,

Opzioni del rapporto:
-------------------------------------------------- ------------------------------
Slack: sì
Ordina per:
il rumore (ricevitore di ingresso di picco)
Soglia: 10,0 (mV)
Livello: VH e VL
-------------------------------------------------- ------------------------------
Peak (mV) Livello TotalArea% AreaTillPeak Larghezza (ps) VictimNet
612,421 VH 216,37 26,85 706,61 ../mc_cntr_out_reg_101_: D ../mr_out_temp_101_ ()

Ricevitore di uscita di picco:
Rapporto ReceiverNet
26,718 (270,000) c_cntr_out_reg_101_ / D (SDFFRX1)

Componenti:
Fonte di picco (mV) Offset (ps) Slew (ps) Xcap (FF) Edge TraceBackNet Net (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 uEcco qual è la relazione dedurre?
Come analizzare qui ....
r quanto le cose che abbiamo qui a prendere in considerazione?

Come generare sdf?
ciò che vedremo in difetto di analisi e di relazione di analisi del rumore?
Come ho imparato a conoscere questa è violazione o no?

Quindi i tempi di sintesi che ho trovato nel setup:
N. di controllo: 100
setup: 90
testate: 10
significa, che cosa significa testate ..
come per visualizzare il percorso testate in PT ...significa falso percorso?

Grazie in anticipo
DINAggiunto dopo 16 minuti:Salve,

In seguito è la celtica cmd ...plz chiarire alcune cose di me ...
cmd celtica:
read_dotlib-tip 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-VSS GND
check_timing

process_netlist
read_dc_script constraints/constraints1.tcl

calculate_delay

# set_analysis_mode-single-setup
report_timing formato (esempio cella di carico ad arco uccise ritardo arrivo richiesto)
report_analysis_coverage
report_clocks

# Analizza SI Effetti sulla tempistica
analyze_noise ritardo
generate_report-sort_by rumore

Dopo questo comando generare,

Opzioni del rapporto:
-------------------------------------------------- ------------------------------
Slack: sì
Ordina per:
il rumore (ricevitore di ingresso di picco)
Soglia: 10,0 (mV)
Livello: VH e VL
-------------------------------------------------- ------------------------------
Peak (mV) Livello TotalArea% AreaTillPeak Larghezza (ps) VictimNet
612,421 VH 216,37 26,85 706,61 ../mc_cntr_out_reg_101_: D ../mr_out_temp_101_ ()

Ricevitore di uscita di picco:
Rapporto ReceiverNet
26,718 (270,000) c_cntr_out_reg_101_ / D (SDFFRX1)

Componenti:
Fonte di picco (mV) Offset (ps) Slew (ps) Xcap (FF) Edge TraceBackNet Net (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 uEcco qual è la relazione dedurre?
Come analizzare qui ....
r quanto le cose che abbiamo qui a prendere in considerazione?

Come generare sdf?
ciò che vedremo in difetto di analisi e di relazione di analisi del rumore?
Come ho imparato a conoscere questa è violazione o no?

Quindi i tempi di sintesi che ho trovato nel setup:
N. di controllo: 100
setup: 90
testate: 10
significa, che cosa significa testate ..
come per visualizzare il percorso testate in PT ...significa falso percorso?

Grazie in anticipo
DIN

 
Sono in grado di rispondere ad alcune delle vostre domande:

:: Come visualizzare il percorso testate in PT ...significa falso percorso?
in incontro, che suona come avete, fare "report_timing-libero

:: Quello che vedremo in difetto di analisi e di relazione di analisi del rumore?
incontro di clock gating eseguire controlli, glitch controllo,
a meno che per disabili.

:: Come generare sdf?
setExtractRCMode-dettaglio
extractRC
delayRC-sdf your.sdf

 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top