8 Comentários

Projeto em FPGA – Pensando na Velocidade e em Pipeline

Caro leitor, o texto a seguir é baseado nos livros [1] e [3], em anotações pessoais e artigos na web. Neste texto e nos próximos iremos tratar tópicos mais pontuais sobre umas das características físicas primárias de um projeto digital - a velocidade.

Quando analisamos a velocidade de um circuito digital devemos estar atento a três definições primárias básicas (amplamente discutido aqui no Embarcados pelo André Prado):

  • Throughput (ou vasão) - segundo [1], no contexto de processamento de dados em um FPGA, throughput refere-se à quantidade de dados processados por ciclo de clock. Já [2] define throughput como o número de ações executadas ou os resultados produzidos por unidade de tempo. Isso é medido em unidades do que está sendo produzido (carros, motocicletas, amostras de I/O, palavras de memória, iterações) por unidade de tempo. Em sistemas digitais estamos falando aqui de bps (bits per second) ou também samples per second;
  • Latência - aqui estamos falando do tempo entre a entrada do dado em uma lógica, seu processamento, e a saída deste dado depois de processado. Segundo [2] latência corresponde ao tempo necessário para executar alguma ação ou para produzir algum resultado. A latência é medida em unidades de tempo - horas, minutos, segundos, nanossegundos ou períodos de clock. Em sistemas digitais, estamos falando em ciclos de clock [2];
  • Timing - aqui estamos falando do atraso (delay) entre dois elementos sequenciais. Segundo [1], quando o sintetizador de lógica acusa - "does not meet timing", significa que esse atraso entre esses dois elementos sequencias é maior que um período de clock desses dois elementos sequenciais. Para ampliar seu conhecimento sobre o tema dê uma olhada aqui e aqui

Existem algumas arquiteturas e otimizações que permitem que o desenvolvedor maximize o número de bits por segundo do projeto, minimize os atrasos entre uma entrada e a respectiva saída e, por fim, reduza o atraso combinacional de um caminho crítico (ou critical path, definido como o caminho entre uma entrada e uma saída com o atraso máximo possível).

Alto Throughput (High Throughput)

Segundo [1], um projeto que possui alto throughput está mais preocupado com a estabilidade da taxa de dados e menos preocupado com qualquer tipo de tempo requerido pelo projeto (no caso latência). Em [1] é feita uma comparação entre alto throughput com uma linha de montagem de carros. Imagine uma linha de montagem na qual a matéria prima entra na fábrica e depois de vários estágios de produção temos o produto final - o carro. Na área de sistemas digitais, essa linha de produção assemelha-se a estágios de pipeline.

Sendo menos puritano, conceitualmente um pipeline se assemelha à linha de produção acima, pois os dados brutos (dados RAW) entram no pipeline, atravessam estágios de processamento e manipulação dos dados até que na saída tenhamos o dado desejado. Nesse sentido, sistemas com uso de pipeline são utilizados para dispositivos que requerem alta-performance. No clássico livro [3], na página 306 em diante, existe uma seção sobre Lendas e Falhas sobre pipeline. Vale a pena a leitura.

Vamos analisar do ponto de vista de um algorítimo essa questão. Observe o código (Código 1) a seguir (adaptado de [1]) cujo resultado é um valor X qualquer elevado à terceira potência.

No código acima, a mesmas variáveis e endereços são acessados enquanto o cálculo é executado. Não existe uso de paralelismo, pois o microprocessador executa uma única instrução no referido tempo (considere um único processador para a afirmação). O mesmo código pode ser descrito em hardware. Considere a implementação (Código 2) em Verilog a seguir.

A Figura 1 ilustra o RTL do Código 2 utilizando a ferramenta Quartus II da Altera.

RTL da Implementação Código 2
Figura 1 - RTL da Implementação Código 2

Como é possível observar o último registrador (XPower) é utilizado novamente realimentando o multiplicador com o seu valor. É aqui que começamos a entender a beleza da computação com alto throughput. Observe que nenhum novo cálculo poderá iniciar até que o cálculo anterior esteja completo. Para piorar, o Código 2 ainda necessita de um sinal (finished) para sinalizar o início e o fim do cálculo.

Analise abaixo as performances do Código 2:

  • Throughput = 8/3 = 2.7 bits/clock;
  • Latência = 3 clocks;
  • Timing = Um multiplicador com seu respectivo atraso no caminho crítico.

Agora observe a seguir a mesma solução mas utilizando uma abordagem com pipeline (Código 3).

A Figura 2 ilustra o RTL do Código 3 utilizando a ferramenta Quartus II da Altera.

RTL da Implementação Código 3 com Pipeline
Figura 2 - RTL da Implementação Código 3 com Pipeline

Observe que na implementação do Código 3, o valor entrada de X "atravessa" estágios de registradores, ou seja, estágios com pipelines. Enquanto X (ou X[0]) está sendo usado para o cálculo no segundo estágio, após um ciclo de clock, o próximo valor de X (ou X[1]) já pode ser enviado para o primeiro estágio para um novo cálculo, ou seja, estamos falando aqui em aproveitar os ciclos de clock do sistema para executar novos cálculos.

Observe a performance do Código 3:

  • Throughput = 8/1 ou 8 bits/clock;
  • Latência = 3 clocks;
  • Timing = Um multiplicador com seu respectivo atraso no caminho crítico.

A figura 3 (A) ilustra a simulação do Código 2 e a figura 3 (B) ilustra a simulação do Código 3.

 
 
(A) Sem Pipeline(B) Com Pipeline
Figura 3 - Simulações dos Código 2 (A - Sem Pipeline) e Código 3 (B - Com Pipeline)

Observe nas Figuras 3.A e 3.B que todas as operações levam 3 ciclos, contudo a operação com pipeline após 1 ciclo de clock já deixa disponível a variável X para um próximo cálculo. Agora observe a grande diferença no número de ciclos para o cálculo do cubo X. O Código 2 leva obrigatoriamente 3 ciclos para cada cálculo (não estou contanto o ciclo do sinal de start), ou seja, foram necessários 6 ciclos para elevar o número 3 e o número 2 ao cubo. Já no Código 3 foram necessários 3 ciclos mais 1 ciclo, ou seja, 4 ciclos para elevar o número 3 e o número 2 ao cubo. Tivemos uma economia de 2 ciclos com essa abordagem.

Considerações

Segundo [1] é possível observar que a latência continua a ser de 3 ciclos, com ou sem pipeline, ou seja, ainda são necessários 3 ciclos de clock para o fim dos cálculos. Contudo, a performance do Throughput para um sistema com pipeline aumentou em um fator de 3. Ainda assim, não existe mudança no timing do sistema para um multiplicador no caminho crítico. Em contra partida, aumentamos o número de registradores, o que aumenta a área do projeto. Contudo são possíveis otimizações nos estágios de pipeline (em [1] capítulo 2 esse tema é amplamente discutido).

Saiba mais

Desenvolvendo hardware, técnicas de design voltadas a velocidade em FPGA!

MiniZed - Um ARM+FPGA para IoT

Como estruturar projetos em FPGA e VHDL

Referências

[1] Advanced FPGA Design: Architecture Implmentation, and Optimization. Steve Kilts. ISBN: 978-0-470-05437-6

[2] Understanding Latency vs Throughput 

[3] Organização e Projeto de Computadores - 2 ª Ed. 2000. Hennessy, John L.;Patterson, David A.

Agradeço ao Henrique pela foto de capa.

Licença Creative Commons Esta obra está licenciada com uma Licença Creative Commons Atribuição-CompartilhaIgual 4.0 Internacional.

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

Hardware » Projeto em FPGA - Pensando na Velocidade e em Pipeline
Comentários:
Notificações
Notificar
guest
8 Comentários
recentes
antigos mais votados
Inline Feedbacks
View all comments
Cesar Mayor
08/01/2018 08:06

Excelente artigo, embora eu prefiro VHDL. O conceito de pipeline ta explicado de uma forma simples e clara. Mais fácil do que isso, difícil!

Anderson Gonçalves Marco
Anderson
08/01/2018 08:00

O segundo código postado possui um erro. Você precisa trocar <= por =. O <= não é bloqueante deste modo isto pode dar problema. Outra coisa importante e que usar muitos operadores bloqueantes faz o FPGA gastar mais circuitos lógicos.

Fernando Souza de Faria
Fernando Souza de Faria
28/12/2017 22:47

Muito legal seu artigo, programo em VHDL porém preciso aprender muito e pesquisar bastante para desfrutar dessas técnicas, quem sabe uma hora tomando café com você ou estudando com você absorva melhor esse conhecimento, um grande abraço e obrigado por demonstrar algo interessante.

Bruno Fernandes Estevão
Bruno Fernandes
23/12/2017 14:03

Muito bom artigo Rodrigo Pereira! mesmo eu sendo iniciante em FPGA, compreendi bem o artigo, já vou avaliar melhor até meus projetos simples! Obrigado!

Talvez você goste:

Séries

Menu

WEBINAR
 
Sensores e soluções para aplicações em indústria inteligente

Data: 13/08 às 15:00h - Apoio: STMicroelectronics
 
INSCREVA-SE AGORA »



 
close-link