Diagramas de olho, PDN e parâmetros S

Três simulações leem os parâmetros S de uma execução FDTD para algo mais específico do que um gráfico: uma simulação de canal empurra um fluxo de bits através de um enlace e desenha o olho, uma simulação PDN transforma as portas de um rail na sua impedância contra um alvo, e agentee sparam analisa qualquer resultado no domínio do tempo. Cada uma precisa primeiro de uma execução FDTD da placa; ver Simulação RF para como configurar uma e mantê-la barata.

#Canal e eye

name = "usb-eye"
kind = "channel"
board = "usb-link"
pair = ["J1+", "J1-", "J2+", "J2-"]
bit_rate = "5Gbps"
rise = "40ps"
swing = "0.8V"
prbs = 7
ctle = { dc_gain = -6.0, zero = "1GHz", poles = ["5GHz", "10GHz"] }
dfe_taps = 2

board nomeia a simulação cujos parâmetros S transportam o enlace. through = [FROM, TO] é um caminho de extremidade única; pair = [IN+, IN-, OUT+, OUT-] um diferencial, lido de Sdd21. A resposta ao impulso vem do caminho, multiplicada pelo CTLE se houver um, com uma borda gaussiana, e o olho é um PRBS sobreposto a ela em 64 fases por intervalo unitário, com realimentação de decisão ideal nos primeiros dfe_taps pós-cursors.

agentee sim usb-eye
agentee show sim:usb-eye

As leituras são a altura do olho na melhor fase, a largura do olho, a pior distorção máxima, a perda em Nyquist e a contagem de cursors. Uma borda mais rápida do que os parâmetros S alcançam é abrandada para o que os dados suportam, com uma nota.

#Drivers reais de IBIS

tx = { file = "models/sn74lvc1g04.ibs", model = "LVC1G04_OUT_33", component = "LVC1G04_DBV", pin = "4" }
rx = { file = "models/sn74lvc1g04.ibs", model = "LVC1G04_IN_33", component = "LVC1G04_DBV", pin = "2" }

O driver torna-se uma fonte de Thevenin a partir das suas tabelas de pulldown e pullup, da sua capacitância de die e do seu encapsulamento; a sua rampa define a borda e o seu intervalo de tensão o swing, a menos que rise ou swing sejam dados. O receptor carrega a extremidade distante com a sua capacitância de encapsulamento e die, e o olho é lido no seu die. O IBIS funciona por agora em caminhos de extremidade única.

#Rede de distribuição de energia

name = "vcc-pdn"
kind = "pdn"
board = "rail"
sinks = ["U1_VCC"]
target = { voltage = "5V", ripple = 1.0, transient = "50mA" }

[[decaps]]
port = "C3"
ref = "C3"
file = "models/grm155r61a105ke15.s2p"
mount = "series"

[[decaps]]
port = "C4"
c = "1uF"
esl = "0.4nH"
esr = "15mohm"

[[vrm]]
port = "VRM"
r = "2mohm"
l = "20nH"

[frequency]
start = "100kHz"
stop = "1GHz"
points = 200

A simulação FDTD da placa coloca uma porta em cada pino de energia, cada pad de decap e o regulador. Cada porta tem de ser conduzida e tem de ser um sink, um decap ou o VRM. Dê a essas portas uma impedance baixa, 0,5 a 1 ohm, já que um rail fica muito abaixo de 50 ohm e converter de S11 a 50 ohm perde precisão.

O alvo é uma impedância ou uma tensão, percentagem de ondulação e corrente transitória. O visualizador desenha |Z| por fonte contra o alvo num gráfico log-log, e as leituras dão a impedância de pico contra o alvo e as maiores antirressonâncias, que é onde adicionar ou alterar um decap. Os decaps são ficheiros S-parametrizados medidos ou um C ideal com ESL e ESR.

#Análise de parâmetros S

agentee sparam lna-rf --tdr IN --rise 50ps
agentee sparam link --pair 1,2,3,4
agentee sparam link --xtalk 1,3

• --tdr PORT é a impedância em função do tempo a partir de uma porta: os dados reamostrados para uma grelha uniforme, extrapolados para CC, com uma borda gaussiana e integrados. Emite um aviso quando a borda é mais rápida do que os dados suportam. O visualizador mostra o mesmo TDR para todas as portas conduzidas.
• --pair IN+,IN-,OUT+,OUT- dá Sdd21, Sdd11, Scc21, Scd21 e Sdc21 em modo misto.
• --xtalk FROM,TO dá o acoplamento em dB e o ruído cruzado de um degrau.

Cada execução relata a passividade (o maior valor singular de S na banda) e a reciprocidade (a maior diferença entre Sij e Sji) quando todas as portas foram conduzidas. Uma passividade acima de 1 significa que a execução não convergiu ou que a malha é demasiado grosseira.

#Manter um link para os seus números

Uma interface no layout pode ler simulações concluídas e falhar a verificação quando um link não atinge os seus números:

[[interfaces]]
name = "usb-ss"
preset = "usb3-gen1"
nets = ["SS_TX*", "SS_RX*"]

[[interfaces.measure]]
sim = "usb-link"
pair = ["TX1_FX+", "TX1_FX-", "TX1_J+", "TX1_J-"]
up_to = "2.5GHz"
max_loss = 1.5
min_return_loss = 10.0
max_mode_conversion = -30.0

[[interfaces.measure]]
sim = "usb-eye"
min_eye_height = "70mV"
min_eye_width = "0.47UI"

Um resultado em falta ou desatualizado também é um erro, por isso uma alteração no layout que as simulações ainda não viram falha a verificação até serem refeitas. Esse é o objetivo: o olho que aprovou é o olho do cobre que está prestes a encomendar. A referência de interfaces lista todos os limites.