Jitter em Sistemas Digitais: Introdução e Correção

Você olha o datasheet. Vê que o PLL que você usa tem um jitter aditivo de alguns femtossegundos. Como um femtossegundo não existe, você ignora. E o sistema não funciona. Por quê? Jitter!

 

Mas para entender de Jitter, você precisa entender de timing. O que você precisa saber:

 

O que é Jitter?

 

Nenhum clock é igual ao outro. Isso todo mundo sabe e ninguém é louco, a esta altura do campeonato (e depois das leituras que indiquei), de sair fazendo assincronismos. E tanto todo mundo sabe que existe uma infinidade de sistemas de recuperação de relógio, justamente porque o oscilador A não é igual ao oscilador B.

 

Porém, a coisa é um pouco mais complicada ainda: de um mesmo oscilador, as oscilações não têm o mesmo tamanho. Há uma variação no período das mesmas fazendo umas mais curtas e outras mais longas.

 

A tal variação damos o nome de Jitter.

 

O que caracteriza o Jitter?

 

Basicamente, jitter se mede usando duas grandezas: a frequência e a amplitude. A frequência é o quão rápido a variação entre ciclos acontece. Amplitude é a intensidade desta variação. Nada fora do usual.

 

Não tão usual são as unidades de medida para jitter. Frequência de jitter normalmente se mede em Hertz, já a amplitude em Segundos (Femto ou Pico, comumente). Pode parecer estranho, mas basicamente são duas medidas de tempo. Para diminuir tal "estranheza", muda-se a medida de amplitude de segundos para UI, que é uma medida relativa à referência original. Para fins deste artigo, a medida em segundos é mais intuitiva.

 

A frequência do jitter normalmente só é um problema para o pessoal que projeta PLLs. Para quem apenas os utiliza, normalmente a preocupação é existir Jitter e qual a amplitude do mesmo. Por isso, a amplitude do Jitter... Essa sim é perigosa. É essa grandeza que precisa ser medida.

 

Sugestão para medida de Jitter

 

Medir jitter de forma absoluta é complicado: normalmente se compara o jitter de um sistema com algum tipo de referência. Para fazer uma medida de jitter, você precisa:

  1. De algum sinal periódico;
  2. Um osciloscópio com capacidade de persistência infinita.

 

Basta iniciar a amostragem. A persistência infinita deve gerar uma tela como a abaixo:

 

Persistência infinita para medida de jjitter.
Persistência infinita.

 

Então, posicione o cursor no início da linha do sinal que corta o eixo x. Posicione o segundo cursor no final da linha onde ela corta o eixo x. Esse "delta" é o valor do jitter, em segundos.

 

A propósito: eu diria que, na grande maioria dos casos em que a referência é o próprio relógio de amostragem de um osciloscópio, tende a fornecer bons resultados. MAS sempre veja a especificação e requisitos para ter certeza disso.

 

Mas como Jitter afeta um sistema?

 

É um grande engano de muitos desenvolvedores de sistemas digitais acreditarem que jitter é algo que apenas "quem faz interfaces de telecom" precisa se preocupar. Na verdade, deve ser preocupação de todo mundo que trabalha com qualquer interface de alta velocidade.

 

Exemplos? PCI-e, DDR3, DDR4, JESD e por aí vai.

 

Para explicar, vamos a um exemplo. Imaginemos uma fila. Se for o tipo de fila em que todas as pessoas estão muito próximas, se a pessoa da parte de trás der um passo, acompanhado por todas as demais, todo mundo anda para frente. Se der um passo para trás, todo mundo volta junto, podemos dizer que todos se respeitam.

 

Essa analogia serve também para sistemas digitais, sendo bastante apropriada para explicar o que é jitter.

 

FFD2FFD (De Flip-Flop D para Flip-Flop D)

 

Assumindo que para dois FFD ligados diretamente ou em um caminho de atraso muito pequeno (um fio, trilha e etc curtos o suficiente para serem desprezados), passamos a ter o exemplo da fila de pessoas muito próximas, mas todas "em sincronia", ou seja, o passo para frente é dado por todos. O passo para trás é dado por todos.

 

Quando circuitos temporizados, com amostragem no mesmo relógio, avanços e regressos de fase instantâneos em todos os Flip-Flops do sistema irão acompanhar tal aumento ou redução do tempo entre amostragens e isso não gera impactos no sistema.

 

Esta situação é comum? Sim. Por exemplo, quando um dispositivo manda dado e relógio a outro dispositivo, a grande chance é que o receptor use este relógio para fazer a amostragem deste mesmo dado, até para garantir que qualquer jitter que venha embutido seja resolvido (como no caso da fila).

 

E depois o receptor pode, por exemplo, passar este relógio por um atenuador de jitter, tipo um PLL.

 

Mas é sabido que os sistemas digitais não são feitos apenas por FFDs. Existem portas lógicas...

 

Apertando a Janela de Propagação+Set/Hold

 

Essa situação é a mais comum a sofrer com problemas de jitter. Vejamos a figura:

 

 

E dela podemos tirar a equação de máxima frequência:

 

 

Quando o clock aumenta de forma instantânea e o tempo de propagação entre duas barreiras temporais se mantém constante então...

  • O sistema consegue acomodar (porque foi planejado, por sorte, seja como for). Não haverá problema.
  • Passa a desrespeitar set/hold. Nesse caso, o sistema para de funcionar ou pode apresentar comportamento espúrio.

 

Jitter e PLLs

 

Há um problema. Atenuar Jitter, uso de PLLs. Isso garante a solução do problema?

 

Exceto por atrasos de propagação extremamente pequenos e mantendo a garantia que o relógio chegará antes dos demais sinais que ele deve sinalizar para registrar, todos os demais casos o relógio deixa de ser "o mesmo" e passa a ser um relógio diferente. Situações que geram enganos:

  • Passou por um PLL. Isso garante apenas frequência e fase médios iguais. Não garante frequência e fase instantaneamente iguais.
  • Passou por um número desconhecido de buffers (comum quando um dispositivo devolve relógio a outro). Isso apenas nos garante uma frequência média igual, mas não uma relação constante de fase.
  • O relógio veio recuperado de um dado. O relógio recuperado não tem a mesma frequência do dado, ele tem uma relação garantida de fase e frequência suficientes para amostrar este mesmo dado, mas não possui uma relação constante (há sempre um erro que deve ser computado e compensado pelo sistema, tipo um "jitter de recuperação").

 

Bom... Se não é o mesmo relógio, como isso afeta o sistema? É assincronismo?

 

A reposta curta pra matar o problema é que é sim, assincronismo. Ao pensar como tal, é possível resolver o problema sistema. Pronto. Mas a resposta certa... É a resposta longa.

 

Se o PLL é um filtro de Jitter, o PLL não vai deixar passar variações instantâneas de fase e frequência, mas que, na média, irá seguir tais parâmetros de entrada. É aqui que os "femtossegundos" de jitter se tornam importantes.

 

Pode-se pensar novamente no exemplo da fila.

 

No caso da fila, se for colocado na ponta da mesma um peso, tipo um carro desengatado. Embora seja possível movê-lo, isso não acontece instantaneamente devido à inercia do carro. E o sujeito no final da fila resolve dar um passo para frente. Em algum momento, todos vão tentar e não vão conseguir dar este passo, pois o carro ainda não se moveu. Todos vão se apertar. Se houver espaço, ninguém será pressionado ou irá se machucar. Se não houver, alguém irá ser apertado, provavelmente o último elemento que será pressionado contra o carro.

 

É preciso que esse pessoal continue fazendo força para que o carro se mova. Porém, o cara do final da fila muda de ideia e volta. O carro, que nem havia se movido, deixa de receber força para se mexer.

 

Isso também acontece com a saída do PLL em relação à sua entrada. Não é porque a entrada está variando que haverá variação instantânea na saída.

 

Agora vamos supor o cenário abaixo, novamente:

 

O clock de entrada dá um passo adiante (diminui o período). O clock de saída vai continuar constante. Novamente teremos uma redução de período, teremos menos tempos para set e hold. A inclusão de um filtro ou atenuador de jitter não resolveu o problema. Pode até ser que tenha piorado.

 

Como resolver o problema de Jitter?

 

Colocar um atenuador de jitter é apenas parte da solução.

 

Tratando o sinal de entrada do PLL como assíncrono seria a reposta mais abrangente e, embora mais universal, talvez uma forma exagerada de resolver o problema. Talvez válida apenas em casos em que o jitter é medonho ou o desenvolvedor precisa da maior garantia possível por estar nos limites da tecnologia... Ou porque não sabe o que está fazendo.

 

Na verdade, é possível resolver de uma forma muito mais elegante... Com apenas 2 FFD, sem nada entre eles. Por quê? Porque em qualquer circuito funcional, ou pelo menos na vasta maioria deles, sempre haverá alguma coisa entre dois FFD e essa coisa sempre tomará mais tempo de propagação que um simples fio entre FFD.

 

Vamos pensar na fila novamente para entender isso. Suponhamos que eu coloque uns 10 passos entre cada elemento da fila. Isso quer dizer que um passo para frente ou para trás de qualquer elemento não vai influenciar na posição do próximo. Isso vale para dois FFD ligados diretamente.

 

 

O clock com jitter entra no primeiro FFD. O clock limpo no segundo FFD. Como o período total, mesmo com a influência negativa do jitter é muito maior que o tempo de propagação do sinal entre os FFD, assumimos que variações nesse período não são consideráveis.

 

Assim como clock...

Jitter é um negócio que, quando o sistema de relógios é bem pensado, nunca vai dar dor de cabeça. Exceto talvez para os limites extremos dos chips, o que configura um pequeno percentual dos sistemas digitais, prestar atenção na especificação faz com que o desenvolvedor jamais precise se preocupar com isso.

 

Tanto que informações sobre jitter e sua correção existem aos montes, mas explicando exatamente seus malefícios temos bem pouca. "Já foi resolvido."

 

Exemplo? A medida de frequência de jitter é normalmente irrelevante para engenheiros normais de sistemas embarcados. Ela se torna algo realmente relevante para desenvolvedores que projetem seus próprios PLLs e filtros de jitter. Se você apenas quer se livrar do jitter não interessa a frequência que ele aconteça, deve apenas se atentar em pegar um PLL que contemple a sua frequência de trabalho e pronto. Deixa o PLL se livrar do Jitter para você.

 

E antes que alguém pergunte, ainda existe o "Wander". Que é basicamente a mesma coisa que o jitter, mas com frequência de variação muito mais lenta. Seja como for, o sistema ou retira isso ou acomoda isso. Seja jitter ou wander, o segredo é pensar bem na árvore de relógios.

 

 

Saiba mais

 

Metaestabilidade

Controlador PLL - Phase Locked Loop

O que é um FFD

NEWSLETTER

Receba os melhores conteúdos sobre sistemas eletrônicos embarcados, dicas, tutoriais e promoções.

Obrigado! Sua inscrição foi um sucesso.

Ops, algo deu errado. Por favor tente novamente.

Ricardo Tafas
Ricardo F. Tafas Jr é Engenheiro Eletricista pela UFRGS com ênfase em Sistemas Digitais e mestre em Engenharia Elétrica pela PUC com ênfase em Gestão de Sistemas de Telecomunicações. É também escritor e autor do livro Autodesenvolvimento para Desenvolvedores. Possui +10 anos de experiência na gestão de P&D e de times de engenharia e +13 anos no desenvolvimento de sistemas embarcados. Seus maiores interesses são aplicação de RH Estratégico, Gestão de Inovação e Tecnologia Embarcada como diferenciais competitivos e também em Sistemas Digitais de alto desempenho em FPGA. Atualmente, é editor e escreve para o "Repositório” (https://www.repositorio.blog), é membro do editorial do Embarcados (https://embarcados.com.br) e é Especialista em Gestão de P&D e Inovação pela Repo Dinâmica - Aceleradora de Produtos.

Deixe um comentário

avatar
 
  Notificações  
Notificar