anÁlise da implementaÇÃo do protocolo lin em …siaibib01.univali.br/pdf/rodrigo vinicius...
TRANSCRIPT
RODRIGO VINÍCIUS MENDONÇA PEREIRA
ANÁLISE DA IMPLEMENTAÇÃO DO PROTOCOLO LIN EM
HARDWARE E EM SOFTWARE
São José (SC), Maio de 2011
UNIVERSIDADE DO VALE DO ITAJAÍ
CURSO DE MESTRADO ACADÊMICO EM
COMPUTAÇÃO APLICADA
ANÁLISE DA IMPLEMENTAÇÃO DO PROTOCOLO LIN EM
HARDWARE E EM SOFTWARE
por
Rodrigo Vinícius Mendonça Pereira
Dissertação apresentada como requisito à
obtenção do grau de Mestre em Computação
Aplicada.
Orientador: Cesar Albenes Zeferino, Dr.
São José (SC), Maio de 2011
Quando a matéria exerce uma função tão insignificante na produção, há menos resistência
material ao aumento do volume. Os semicondutores representam a derrocada da matéria na
economia. George Gilder, autor de Microcosm
Aquele que recebe de mim uma idéia tem aumentada sua instrução sem que eu tenha diminuída a
minha. Como aquele que acende sua vela na minha recebe luz sem apagar a minha vela.
Thomas Jefferson inventor e pai do sistema de patentes.
Combati o bom combate, terminei a corrida, guardei a fé.
2 Timóteo 4:7
AGRADECIMENTOS
Agradeço a paciência, a dedicação, o otimismo e a ajuda prestimosa do meu orientador,
professor Dr. Cesar A. Zeferino.
Ao CNPq pela bolsa concedida no âmbito do Programa Nacional de Microeletrônica.
Ao Programa Brazil IP pelo conhecimento compartilhado e pela oportunidade de interagir
pessoas com pessoas tão maravilhosas como a professora Dra. Edna Barros, professor Dr. Elmar
Melcher e toda a equipe da UFPE e do LAD, em especial a pessoa do Jorgeluis Guerra e Adalberto
Teixeira.
Ao professor Dr. José Luís A. Güntzel pelo apoio e infraestrutura cedida no âmbito do
LAPS e principalmente ao amigo Msc. Vinicius Livramento pela valiosa ajuda em todas as etapas
do desenvolvimento do LIN IP.
Aos meus professores que sempre souberam me incentivar a buscar conhecimento e me
encaminharam nos estudos.
Aos amigos (visíveis e invisíveis) pelo apoio e estímulo dedicado ao longo desses anos.
Aos amores da minha vida, tanto do passado, quando aos atuais e principalmente aos do
futuro.
Aos meus filhos, que um dia terei, ou se já tenho, agradeço à vocês.
E sempre a Deus, pela minha família maravilhosa e indescritível.
ANÁLISE DA IMPLEMENTAÇÃO DO PROTOCOLO LIN EM
HARDWARE E EM SOFTWARE
Rodrigo Vinícius Mendonça Pereira
Maio/2011
Orientador: Cesar Albenes Zeferino, Dr.
Área de Concentração: Computação Aplicada
Linha de Pesquisa: Sistemas Embarcados e Distribuídos
Palavras-chave: Redes Automotivas, LIN, FPGA.
Número de páginas: 119
RESUMO
No setor automotivo contemporâneo, a maior parte da inovação está relacionada à inclusão
de itens adicionais de conforto, desempenho e segurança do automóvel. Contudo, o maior desafio
para este setor está no preço final que esses dispositivos impõem ao produto. Uma das soluções
encontradas para inovar no setor automotivo consiste no uso de dispositivos eletrônicos interligados
por uma rede intra-veicular padrão, como no caso da arquitetura de rede do tipo barramento CAN –
Controller Area Network, associada a uma rede de baixo custo LIN – Local Interconnect Network.
Nesse contexto, este trabalho vem contribuir com estudos na área de sistemas embarcados por meio
da análise das métricas de implementação das camadas de transporte e de enlace do protocolo
automotivo LIN em um dispositivo FPGA (Field Programmable Gate Array), sob duas abordagens
diferentes: software e em hardware. A primeira abordagem baseou-se na implementação das
camadas do protocolo sobre o processador Altera Nios II. Na segunda abordagem, as camadas do
protocolo foram implementadas como um hardware dedicado, usando Verilog (linguagem de
descrição de hardware). Os resultados demonstram que a solução baseada em hardware apresentou
os menores custos (consumo de energia e área de silício), enquanto que a abordagem baseada em
software apresenta mais flexibilidade para atualizações.
ANALYSIS OF THE IMPLEMENTATIONS OF THE HARDWARE
AND SOFTWARE LIN PROTOCOL
Rodrigo Vinícius Mendonça Pereira
May/2011
Advisor: Cesar Albenes Zeferino, Dr.
Area of Concentration: Applied Computer Science
Research Line: Embedded and Distributed Systems
Keywords: Automotive Networks, LIN, FPGA.
Number of pages: 119
ABSTRACT
In the contemporary automotive area, the largest part of innovation is related to the inclusion
of additional comfort, performance, and safety items to vehicles. However, the challenge is the final
price that these items impose on the product. One of the solutions adopted to innovate in the
automotive area consists in the use of smart electronic devices interconnected by means of a
standard intra-vehicular network, such as the hierarchical architecture composed of CAN
(Controller Area Network) associated with a low cost sub-network as LIN (Local Interconnect
Network). In this context, this work aims at contributing with the embedded systems area by means
of the analysis of metrics for implementation of the Transport and Link layers of the LIN
automotive protocol in an FPGA (Field Programmable Gate Array) device under two different
approaches: software- and hardware-based. The first approach was based on the implementation of
protocol layers on the Altera Nios II embedded processor. In the second approach, the protocol
layers were implemented as a dedicated hardware described using Verilog hardware description
language. Results demonstrate that the hardware-based approach presented the smaller costs (power
consumption and silicon area), while the software-based approach has more flexibility for updates.
LISTA DE ILUSTRAÇÕES
Figura 1. Abordagens propostas: (a) baseada em software; (b) baseada em hardware ..................... 17
Figura 2. Formato de um quadro LIN ................................................................................................ 30 Figura 3. Exemplo de um sistema com o processador Nios II ........................................................... 38 Figura 4. Arquitetura do ipPROCESS ............................................................................................... 40 Figura 5. Modelo de testbench ........................................................................................................... 43 Figura 6. Modelo de testbench BVM ................................................................................................. 44
Figura 7. IP adaptador banda base bluetooth ..................................................................................... 49 Figura 8. Modelo de testbench baseado na filtragem de estímulos redundantes ............................... 50 Figura 9. Exemplo de SoC para sistemas automotivos ...................................................................... 53 Figura 10. Módulo LIN ...................................................................................................................... 53
Figura 11. Atores do sistema.............................................................................................................. 59 Figura 12. Diagrama geral de casos de uso das abordagens em software e em hardware ................. 60 Figura 13. Diagrama lógico preliminar do sistema ............................................................................ 62
Figura 14. Diagrama de sequência de um barramento LIN ............................................................... 65 Figura 15. Descrição de topo do LIN HW ......................................................................................... 66 Figura 16. Descrição do LIN HW em blocos lógicos interconectados com o barramento AMBA
AXI............................................................................................................................................. 67
Figura 17. Estrutura BVM do testbench do LIN Bus core ................................................................ 68 Figura 18. Modelo de referência simples ........................................................................................... 69
Figura 19. Modelo de referência duplo .............................................................................................. 69 Figura 20. Emulação do DUV............................................................................................................ 70 Figura 21. Modelo de referência decomposto em seis subsistemas ................................................... 70
Figura 22. Testbench completo .......................................................................................................... 71
Figura 23. Especificação do sistema utilizando a ferramenta SOPC ................................................. 72 Figura 24. Projeto do hardware utilizado no LIN SW utilizando o processador Nios II ................... 73 Figura 25. Diagrama de classes do LIN SW ...................................................................................... 74
Figura 26. Funcionamento do LIN HW TESTBENCH e do LIN HW .............................................. 75 Figura 27. Diagrama de blocos do protótipo para teste físico ........................................................... 77 Figura 28. Bancada de testes LIN ...................................................................................................... 77
Figura 29. Caso de uso tabela de escalonamento de mensagens ....................................................... 78 Figura 30. Fluxo de mensagens enviadas no Barramento LIN .......................................................... 78
Figura 31. Quadro enviado do nodo mestre para o Escravo_0 com a mensagem de ID 0xd3 (escala
em 5 volts) .................................................................................................................................. 79 Figura 32. Quadro enviado do nodo mestre para o Escravo_1 com a mensagem de ID 0x42 e sua
respectiva resposta (escala em 2 volts) ...................................................................................... 80 Figura 33. Gráfico da potência consumida pelo LIN HW ................................................................. 84
Figura 34. Gráfico da potência consumida do LIN SW ..................................................................... 85 Figura 35. Gráfico comparativo em colunas das potências consumidas entre o LIN SW e LIN HW
.................................................................................................................................................... 85 Figura 36. Gráfico comparativo linear das potências consumidas entre o LIN SW e LIN HW ........ 86 Figura 37. Síntese Física do LIN HW ................................................................................................ 87
Figura 38. Resultado final do ciclo de desenvolvimento ................................................................... 87 Figura 39. Etapa 1.1 – Decomposição Simples do Modelo de Referência ........................................ 96 Figura 40. Modelo de referência hierárquico duplo. .......................................................................... 97 Figura 41. Emulação DUV ................................................................................................................. 97
Figura 42. Decomposição simples do modelo de referência RX ....................................................... 98 Figura 43. Decomposição simples do modelo de referência MUX ................................................... 98
Figura 44. Decomposição simples do modelo de referência LIN2AXI ............................................. 98 Figura 45. Decomposição simples do modelo de referência AXI2LIN ............................................. 99 Figura 46. Decomposição simples do modelo de referência CHECKSUM ...................................... 99 Figura 47. Decomposição simples do modelo de referência TX ....................................................... 99 Figura 48. Decomposição Hierárquica do Modelo de Referência ................................................... 100
Figura 49. Modelo de referência RX hierárquico duplo .................................................................. 100 Figura 50. Modelo de referência MUX hierárquico duplo .............................................................. 101 Figura 51. Modelo de referência LIN2AXI hierárquico duplo ........................................................ 101 Figura 52. Modelo de referência AXI2LIN hierárquico duplo ........................................................ 101 Figura 53. Modelo de referência CHECKSUM hierárquico duplo ................................................. 102
Figura 54. Modelo de referência TX hierárquico duplo .................................................................. 102
Figura 55. Emulação do DUV do modelo de referência RX hierárquico ........................................ 103
Figura 56. Emulação do DUV do modelo de referência MUX hierárquico .................................... 103 Figura 57. Emulação do DUV do modelo de referência LIN2AXI hierárquico .............................. 103 Figura 58. Emulação do DUV do Modelo de Referência AXI2LIN Hierárquico ........................... 104 Figura 59. Emulação do DUV do modelo de referência CHECKSUM hierárquico ....................... 104
Figura 60. Emulação do DUV do modelo de referência RX hierárquico ........................................ 104 Figura 61. DUV hierárquico do modelo de referência RX .............................................................. 105
Figura 62. DUV hierárquico do modelo de referência MUX .......................................................... 105 Figura 63. DUV hierárquico do modelo de referência LIN2AXI .................................................... 106 Figura 64. DUV hierárquico do modelo de referência AXI2LIN .................................................... 106
Figura 65. DUV Hierárquico do modelo de referência CHECKSUM ............................................ 106 Figura 66. DUV Hierárquico do Modelo de Referência TX. ........................................................... 107
Figura 67. Verificação Funcional do LIN HW ................................................................................ 107 Figura 68. Síntese Física – Distribuição da lógica na etapa de placement ...................................... 108
Figura 69. Síntese física – Clock Tree do LIN HW ......................................................................... 109
Quadro 1. Análise comparativa das características de núcleos de propriedade intelectual LIN........ 55
Quadro 2. Análise comparativa dos trabalhos relacionados. ............................................................. 57
Quadro 3. Análise comparativa das características de núcleos de propriedade intelectual LIN........ 89 Quadro 4. Descrição do campo de parada em SystemVerilog. ........................................................ 110 Quadro 5. Descrição do campo de sincronismo em SystemVerilog. ............................................... 110 Quadro 6. Descrição do campo de sincronismo em SystemVerilog. ............................................... 110 Quadro 7. Código-fonte do temporizador do Nios II ....................................................................... 117
Quadro 8. Código interrupção dos PIOs do Nios II ......................................................................... 118
LISTA DE TABELAS
Tabela 1. Comparação dos resultados das implementações do bloco de cifragem do algoritmo AES
.................................................................................................................................................... 48 Tabela 2.Custos da síntese dos principais blocos do LIN HW para a família Cyclone II ................. 81 Tabela 3.Custos da síntese dos principais blocos do LIN HW para a família Cyclone III ................ 82 Tabela 4. Custos da síntese do LIN SW para as famílias Cyclone II e Cyclone III .......................... 82 Tabela 5. Comparação entre as duas abordagens para a família Cyclone II ...................................... 82
Tabela 6. Comparação entre as duas abordagens para a família Cyclone III .................................... 83 Tabela 7. Potências dissipadas pelo LIN HW operando sob diferentes frequências ......................... 84 Tabela 8. Potências dissipadas pelo LIN SW operando sob diferentes frequências .......................... 84 Tabela 9. Resultados da síntese física do LIN HW para a tecnologia XFAB 0.35μ ......................... 87
LISTA DE ABREVIATURAS E SIGLAS
ASIC Application Specific Integrated Circuit
BVM Brazil-IP Verification Methodology
CAN Controller Area Network
CPLDs Complex Programmable Logic Devices
CPU Central Processing Unit
CMOS Complementary Metal-Oxide-Semiconductor
CS Chip Select
DC Direct Current
CI Circuito Integrado
DSC Dynamic Stability Control
DUV Device Under Verification
EU União Européia
EUA Estados Unidos da América
FPGA Field Programmable Gate Array
FIFO First In First Out
PWM Pulse-width modulation
HDL Hardware Description Language
IEEE Institute of Electrical and Electronics Engineers
ICC IC Compiler
IP Intellectual Property
IPI Imposto Sobre Produtos Industrializados
ISO International Organization for Standardization
JTAG Joint Test Action Group
LIN Local Interconect Network
LUT Lookup Tables
MCA Mestrado em Computação Aplicada
MICS Mitsubishi Intelligent Cockpit System
NRE Non-Recurring Engineering cost
NOC Network on Chips
OEM Original Equipment Manufacturer
OVM Open Verification Methodology
PALs Programmable Array Logic
PID Protected Identifier
PLAs Programmable Logic AND
PLDs Programmable Logic Devices
PWM Pulse Width Modulation
RX Receiver Bus
SAE Society of Automotive Engineers
SBCCI Symposium on Integrated Circuits and Systems Desig
SoC System-on-Chip
TTNC Time Triggered Network-on-Chip
TLM Transaction Level Modeling
TX Transmitter Bus
UBPs UART base protocols
UART Universal Asynchronous Receiver/Transmitter
UNIVALI Universidade do Vale do Itajaí
VAN Vehicle Area Network
VCT Volcano Communication Technology
VHDL VHSIC Hardware Description Language
LISTA DE SÍMBOLOS
bps bits por segundo
K kilo
KHz Kilo Hertz
MHz Mega Hertz
μm Micrometro
SUMÁRIO
1. INTRODUÇÃO .................................................................................... 14
1.1 PROBLEMA DE PESQUISA........................................................................... 15
1.1.1 Solução Proposta ............................................................................................. 17
1.1.2 Delimitação de Escopo .................................................................................... 18
1.1.3 Justificativa ...................................................................................................... 18
1.2 OBJETIVOS ...................................................................................................... 20
1.2.1 Objetivo Geral ................................................................................................. 20
1.2.2 Objetivos Específicos ...................................................................................... 20
1.3 METODOLOGIA .............................................................................................. 20
1.3.1 Metodologia da Pesquisa ................................................................................ 20
1.3.2 Procedimentos Metodológicos ........................................................................ 21
1.4 ESTRUTURA DA DISSERTAÇÃO ................................................................ 21
2 REDES AUTOMOTIVAS E O PROTOCOLO LIN ....................... 23
2.1 DEFINIÇÕES E CLASSIFICAÇÃO DAS REDES AUTOMOTIVAS ....... 23
2.2 PADRÕES DE REDES AUTOMOTIVAS ..................................................... 26
2.3 PROTOCOLO LIN ........................................................................................... 27
2.4 TÉCNICAS DE PROJETO DE CIRCUITOS INTEGRADOS .................... 32
2.4.1 Métricas de Projeto ......................................................................................... 32
2.4.2 Tecnologias de Circuitos Integrados ............................................................. 33
2.4.3 Processador Embarcado Nios II .................................................................... 36
2.5 A METODOLOGIA DE PROJETO IPPROCESS ........................................ 39
2.6 VERIFICAÇÃO ................................................................................................. 40
2.6.1 Verificação Formal ......................................................................................... 41
2.6.2 Verificação Funcional ..................................................................................... 41
2.7 CONSIDERAÇÕES .......................................................................................... 46
3 TRABALHOS CORRELATOS ......................................................... 47
3.1 COMPARAÇÃO DO DESEMPENHO DE IMPLEMENTAÇÕES DO
ALGORITMO AES .................................................................................................. 47
3.2 COMPARAÇÃO DE METODOLOGIAS DE TESTBENCH PARA
VERIFICAÇÃO FUNCIONAL HIERÁRQUICA................................................. 48
3.3 VERIFICAÇÃO FUNCIONAL DE HW ATRAVÉS DE CO-SIMULAÇÃO
DE HW/SW EM SISTEMAS COMPLEXOS ........................................................ 50
3.4 SISTEMA DE CAIXA-PRETA PARA VEÍCULOS INTELIGENTES COM
COMUNICAÇÃO INTRAVEICULAR LIN/FLEXRAY ..................................... 52
3.5 IMPLEMENTAÇÕES EM HARDWARE DO PROTOCOLO LIN ........... 54
3.6 ANÁLISE COMPARATIVA............................................................................ 56
3.7 CONSIDERAÇÕES .......................................................................................... 58
4 PROJETO BASEADO NA METODOLOGIA ipPROCESS ......... 59
4.1 ESPECIFICAÇÃO DOS SISTEMAS .............................................................. 59
4.1.1 Atores do Sistema ............................................................................................ 59
4.1.2 Projeto Arquitetural ....................................................................................... 60
4.1.3 Descrição da Arquitetura ............................................................................... 63
4.1.4 Diagrama de Sequência .................................................................................. 65
4.2 ABORDAGEM BASEADA EM HARDWARE – LIN HW .......................... 66
4.2.1 Implementação do IP LIN HW (DUV) ......................................................... 66
4.2.2 Implementação do Testbench ......................................................................... 68
4.2.3 Verificação Funcional ..................................................................................... 71
4.3 ABORDAGEM BASEADA EM SOFTWARE – LIN SW ............................ 71
4.3.1 Implementação do Processador Embarcado Utilizando a Ferramenta
SOPC........................................................................................................................... 72
4.3.2 Programação do LIN SW ............................................................................... 73
5 RESULTADOS .................................................................................... 75
5.1 VERIFICAÇÃO FUNCIONAL ....................................................................... 75
5.2 PROTOTIPAÇÃO E TESTE ........................................................................... 76
5.3 CUSTO DE SILÍCIO ........................................................................................ 81
5.4 TEMPO DE PROJETO .................................................................................... 83
5.5 POTÊNCIA DISSIPADA .................................................................................. 83
5.6 RESULTADOS ADICIONAIS - SÍNTESE EM ASIC .................................. 86
5.7 ANÁLISE DOS RESULTADOS ...................................................................... 88
5.8 CONSIDERAÇÕES .......................................................................................... 90
6 CONCLUSÕES .................................................................................... 91
6.1 TRABALHOS FUTUROS ................................................................................ 92
REFERÊNCIAS ....................................................................................... 93
APÊNDICE A - IMPLEMENTAÇÃO DO ASIC DO LINIP ............ 96
APÊNDICE B ESTÍMULOS GERADOS .......................................... 110
ANEXO A – REVISÃO SISTEMÁTICA – PROTOCOLO DE
BUSCA ...................................................................................................111
ANEXO B – PROGRAMAÇÃO DO TEMPORIZADOR E DA
INTERRUPÇÃO DO SINAL RX ......................................................... 117
14
1. INTRODUÇÃO
Inovar introduzindo novos itens de conforto, desempenho ou segurança e, ainda assim, não
agregar custos ao projeto final do automóvel é o constante desafio da indústria automotiva. A
principal solução adotada para inovar no setor automotivo consiste no uso de dispositivos
eletrônicos interligados por meio de uma rede intra-veicular padrão (GUIMARÃES, 2007). Em
geral, essas redes são baseadas em arquiteturas do tipo barramento, sendo que, dentre as diversas
tecnologias de redes automotivas, o padrão norte-americano J1850 (OLIVER, 1996) e o seu
correspondente europeu CAN – Controller Area Network (BOSCH, 2008) destacam-se por serem
os mais utilizados.
Com o incremento desses dispositivos eletrônicos no automóvel e o aumento do tráfego de
informações nas redes automotivas, surgiu a necessidade de se adotar arquiteturas de redes
hierárquicas. Nessas arquiteturas, a rede principal (backbone) é associada a sub-redes, aliviando a
carga de comunicação na rede principal. O LIN – Local Interconnect Network (LIN, 2006) é uma
das soluções de sub-redes complementares desenvolvidas para esse fim. Seu protocolo foi
especificado no final da década de 90 pelo LIN Consortium, uma iniciativa formada por cinco
indústrias automobilísticas Européias (Audi, BMW, Daimler Chrysler, VW e Volvo) e duas
indústrias de semicondutores (a Motorola e a VCT – Volcano Communication Technology).
Uma rede baseada no protocolo LIN caracteriza-se por suportar um único nodo mestre
(mono-mestre) e até dezesseis nodos escravos que se comunicam por meio de um canal bidirecional
com um único fio. Com largura de banda na faixa de 1 a 20 kbps, comunicação assíncrona,
dispensando o uso de cristal de quartzo nos nodos escravos, entre outras características, permitiram
alcançar soluções de baixo custo para comunicação entre dispositivos com requisitos de largura de
banda limitados.
Os nodos interconectados ao barramento implementam quatro camadas do protocolo LIN:
(i) Física; (ii) Enlace de dados; (iii) Transporte; e (iv) Aplicação. A camada Física é baseada em um
circuito integrado do tipo transceiver ou PHY (MCP201 da Microchip), enquanto que as demais
camadas podem ser implementadas por software ou por hardware, ou utilizando ambas abordagens.
Tipicamente, em uma implementação LIN baseada em software, as camadas de Aplicação,
Transporte e Enlace do protocolo são programadas para serem executadas pela CPU (Central
15
Processing Unit) de um microcontrolador. Já em uma abordagem baseada em hardware, as camadas
de Transporte e de Enlace são implementadas na forma de um periférico do microcontrolador, o
qual implementa a camada de Aplicação em software e fornece uma interface para a camada Física.
Outra abordagem possível consiste em implementar em hardware as camadas do protocolo que
necessitam mais tempo de processamento de CPU, como a camada de Enlace de dados e
Transporte. Esta abordagem permite que o microcontrolador utilizado esteja dedicado
exclusivamente para a camada de Aplicação em software. Neste momento, o uso da solução em
hardware justifica-se pela necessidade de reduzir o overhead em uma solução LIN puramente em
software, tais como o cálculo da paridade, identificação do início da transmissão LIN.
Nesse contexto, tendo em vista que não existem trabalhos que analisem a implementação em
software e em hardware do protocolo LIN, esta dissertação de mestrado procurou contribuir por
meio da análise de métricas (como as mencionadas acima) de implementação das camadas de
Transporte e de Enlace do protocolo, utilizando duas abordagens: software e hardware.
1.1 PROBLEMA DE PESQUISA
Como apresentado anteriormente, o protocolo LIN caracteriza-se por suportar um único
mestre e múltiplos escravos, ser de baixo custo e possuir escalabilidade de até dezesseis escravos
por barramento. O LIN é consolidado na indústria automotiva como o protocolo empregado em
aplicações de conforto e controle do automóvel. Entre as diversas aplicações de conforto e controle
podem ser citados, como exemplos, o controle de sistemas de ar-condicionado direcional,
acionamento de vidros e espelhos retrovisores com acionamento elétrico, os sensores do grupo
motopropulsor e os sistemas de acionamento e trava do teto solar, entre outros.
Para reduzir custos e tempo de projeto, o desenvolvimento de subsistemas compatíveis com
o protocolo LIN é em geral baseado em soluções OEM1 (Original Equipment Manufacturer) como
1 Modalidade de venda cujo produto desenvolvido por uma empresa é vendido para outra empresa e esta, por sua vez, se
encarrega de gerar o produto final e alcançar o consumidor. Essa modalidade de venda ocorre devido à necessidade de
cortes de diversos custos como o de pesquisa e de desenvolvimento do produto, gerando um produto final competitivo.
16
bibliotecas de software, núcleos2 sintetizáveis ou dispositivos periféricos. A Microchip, a Freescale
e a Cypress são exemplos de indústrias que oferecem bibliotecas de software (parciais ou integrais)
com implementações do protocolo LIN para os seus microcontroladores. Já a CAST (CAST, 2007),
a Intelliga (INTELLIGA, 2003) e a BOSCH (BOSCH, 2008) oferecem núcleos sintetizáveis,
implementando parcialmente ou integralmente as camadas do protocolo LIN, em linguagens de
descrição de hardware.
No contexto das soluções baseadas em software, a Microchip oferece bibliotecas que
acompanham seus kits de desenvolvimento LIN para microcontroladores da família PIC16F e
PIC18F. Um exemplo de kit de desenvolvimento da Microchip é o PICDEM 3 CAN-LIN
(MICROCHIP, 2009), o qual foi usado como um dos modelos de referência nesta pesquisa. Já a
Freescale oferece bibliotecas de software para os microcontroladores da família S12X, utilizada no
kit DEMO9S12XEP100 da Softec-Microsystems, usado como o gerador do sinal mestre para os
testes finais do projeto. Por fim, a Cypress disponibiliza bibliotecas de software para os seus kits de
PSoC (Programmable System-on-Chip), uma tecnologia de circuito integrado que inclui um
microcontrolodar e blocos configuráveis de circuitos analógicos e digitais (CYPRESS, 2009). Já no
contexto das soluções baseadas em hardware, alguns núcleos sintetizáveis são disponibilizados
comercialmente pela CAST, pela Intelliga e pela BOSCH. Tais núcleos serão detalhados
posteriormente na Seção 3.5 deste trabalho.
Cada tipo de implementação (baseada em software ou hardware) apresenta resultados
diferentes em relação a métricas de desempenho e de custo, bem como graus específicos de
dificuldade. O conhecimento dessas métricas pode auxiliar a indústria na tomada de decisões quanto
à melhor abordagem a ser adotada em diferentes cenários
No entanto, até o presente momento, não foi possível identificar na literatura trabalhos que
façam uma análise comparativa dos dois tipos de implementação do protocolo LIN, demonstrando
as vantagens, desvantagens e limitações de cada alternativa com base em informações quantitativas
2 Núcleos (do inglês, cores) são blocos de hardware sintetizáveis pré-projetados e pré-verificados que podem ser
utilizados na implementação de um sistema integrado em silício. Também são conhecidos por blocos IP (do inglês,
Intelectual Property blocks) ou IP cores.
17
e qualitativas. Esta pesquisa buscou então preencher essa lacuna por meio da implementação,
caracterização e análise de soluções LIN baseadas em software e em hardware.
1.1.1 Solução Proposta
A solução proposta para o problema de pesquisa apresentado consiste na implementação das
camadas de Transporte e de Enlace do protocolo LIN nos dois tipos de abordagem (software e
hardware) e na comparação dessas implementações quanto às métricas de desempenho, custo e
flexibilidade de atualização, entre outras. Nesse contexto, a solução proposta consiste na
implementação de nodos LIN escravos baseados no processador embarcado Nios II da Altera e na
modelagem das camadas de Transporte e de Enlace em Verilog para FPGAs (Field Programmable
Gate Array) da Altera.
Na abordagem baseada em software, as camadas de Transporte e de Enlace são
implementadas por meio de funções programadas em linguagem C (conforme ilustrado na Figura
1.a). Já na abordagem baseada em hardware, essas camadas são implementadas na linguagem de
descrição de hardware Verilog (THOMAS et al. 1998), constituindo um periférico do processador
(Figura 1.b). Nas duas abordagens, a camada de aplicação é implementada no processador, via
software, e a camada física é baseada em um circuito integrado comercial.
Aplicação
Transporte
Enlace
NIOS II
FPGA
Física
LIN IP
Transporte
Enlace
Física
FPGA
Aplicação
(a) (b)
Figura 1. Abordagens propostas: (a) baseada em software; (b) baseada em hardware
18
As duas implementações são sintetizadas em dispositivos lógicos programáveis do tipo
FPGA utilizando uma ferramenta de síntese que forneça métricas para avaliação: o Quartus II da
Altera (2010). A partir de métricas fornecidas pela ferramenta, como células lógicas, LUTs (Lookup
Tables), frequência máxima de operação, bits de memória e potência dissipada é feita a análise
comparativa proposta visando avaliar a seguintes hipóteses:
1. A implementação baseada em software ocupa uma menor lógica;
2. A implementação baseada em software é mais flexível para atualizações; e
3. A implementação baseada em hardware consome menos energia.
1.1.2 Delimitação de Escopo
Nesta dissertação, o escopo do trabalho foi delimitado à implementação de um subconjunto
do LIN compatível com a Revisão 2.1 do protocolo (LIN, 2006), incluindo o modo de diagnóstico
Classe I na camada de Transporte e o modo simples de soma e verificação (checksum) na camada
de Enlace. Para os experimentos de análise, foram definidas duas famílias de FPGA, Cyclone II e
Cyclone III da Altera e para síntese física a tecnologia XFAB 0.35μ, para fins de análise de
métricas.
1.1.3 Justificativa
Estimativas citadas em Beretta (2003) apontavam que, em 2010, do custo total para a
produção mundial de automóveis de US$ 240 bilhões, US$ 150 bilhões seriam gastos em
componentes de hardware e US$ 90 bilhões em software.
Em 2008, a Visteon, empresa especializada no desenvolvimento de hardware automotivo,
que divide seus produtos automotivos em quatro grupos (interior, eletrônica, climatização e outros
sistemas), estimava que, em 2010, suas vendas seriam distribuídas da seguinte forma: 34% devidos
ao grupo de interior, 38% devidos ao grupo de climatização, 25% devidos ao grupo de eletrônica e
os restantes 3% devido a outros sistemas. Isso apontava para aumento expressivo da parcela
referente aos dois primeiros grupos (interior e climatização), os quais corresponderam,
respectivamente, a 27% e a 31% do volume de vendas de 2007 (VISTEON, 2008).
19
Considerando tais estimativas, evidencia-se que para se tornar competitivo, nos próximos
anos, o mercado automotivo precisará de um modelo de negócios voltado para a redução de custos
de hardware, mas que ao mesmo tempo permita aumentar o conforto dentro do automóvel sem
comprometer a segurança dos seus ocupantes.
Assim, duas abordagens podem ser adotadas na implementação do hardware do carro:
arquitetura centralizada ou arquitetura distribuída. A arquitetura centralizada prevê que uma única
ECU3 (Electronic Control Unit) receba os sinais de todos os sensores (entradas), processe-os e
acione os atuadores (saídas). Já em uma arquitetura distribuída, existem múltiplas ECUs, cada uma
responsável por um subconjunto dos sensores e atuadores do veículo. Essas ECUs são interligadas
por uma rede intra-veicular hierárquica e comunicam-se através de protocolos de comunicação, a
exemplo do protocolo CAN, o qual possui alta velocidade e confiabilidade, associado à sub-redes
LIN, cuja razão “custo por bytes trafegados por nó” é metade que a do CAN. Assim, a presente
dissertação utiliza a arquitetura distribuída com uma ECU principal (mestre) para escalonar as
mensagens LIN entre os múltiplos escravos, estes por sua vez enviam e recebem dados dos sensores
e atuadores para a rede LIN.
Nesse contexto, esta dissertação contribui por meio da análise das métricas da
implementação em software e em hardware do protocolo LIN, bem como os aspectos
metodológicos utilizados no transcorrer do trabalho. A metodologia de projeto adotada para o
desenvolvimento dos núcleos foi o ipPROCESS (LIMA et al., 2005), a qual é baseada em dois
processos de software: RUP – Rational Unified Process (RUP, 2001) e XP – Extreme Programming
(PAPO, 2002) e cuja idéia principal consiste em usar conceitos de Engenharia de Software na
concepção de núcleos de propriedade intelectual (IPs).
A solução aqui apresentada é continuidade do trabalho de conclusão do curso de graduação
do autor (PEREIRA, 2008) e executada no âmbito do Programa Brazil IP do Ministério de Ciência
e Tecnologia (MCT) com apoio Conselho Nacional de Desenvolvimento Científico e Tecnológico
(CNPq). A solução também está inserida no programa UNIESPAÇO da Agência Espacial Brasileira
3 Uma ECU (Electronic Central Unit) é constituída por um sistema embarcado, o qual controla uma ou mais
funcionalidades em um automóvel. É o caso do sistema de injeção do motor ou do sistema de controle de acionamento
dos freios ABS, os quais podem eventualmente estar localizados em uma mesma unidade de controle eletrônico (ECU),
ou separadamente.
20
(AEB), com o projeto intitulado – Uso do Protocolo LIN na Interconexão de Sistemas em Satélites
Artificiais.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Analisar métricas de custo, potência, desempenho e flexibilidade de implementações
baseadas em software e em hardware das camadas de Transporte e de Enlace do protocolo do LIN.
1.2.2 Objetivos Específicos
Levantar os requisitos do protocolo LIN e identificar métodos e métricas utilizadas para
avaliação de implementações em software e hardware;
Caracterizar as implementações protocolo de comunicação LIN (camadas de Transporte
e de Enlace) em níveis de hardware e de software; e
Comparar as implementações por meio da análise de métricas de custo, desempenho e
flexibilidade.
1.3 METODOLOGIA
Nesta seção, são apresentados os procedimentos metodológicos utilizados para o
desenvolvimento da dissertação.
1.3.1 Metodologia da Pesquisa
O presente trabalho está enquadrado no contexto de pesquisa aplicada (LAKATOS et al.,
1992), pois os conhecimentos aqui descritos possuem resultados práticos e visíveis em problemas
como a escolha e a análise das métricas de soluções de design de software ou hardware mais
adequado a serem empregadas no desenvolvimento de uma rede automotiva que utilize
necessariamente um barramento LIN.
Este trabalho empregou o método qualitativo (LAKATOS et al., 1992), valendo-se de uma
análise inicial do protocolo LIN, buscando entender o seu mecanismo de funcionamento, analisando
21
descrições do protocolo e comparando e interpretando os dados de diversas fontes. Em um segundo
momento, valeu-se do método quantitativo (LAKATOS et al., 1992), pois faz uso de dados
estatísticos obtidos pelas ferramentas de síntese para os dois sistemas propostos neste projeto
(software e hardware), tais como:
A potência consumida nos dois sistemas; e
A quantidade de células lógicas para dois sistemas sintetizados em uma mesma família
de dispositivos lógicos programáveis.
Também foi feita uma pesquisa exploratória (LAKATOS et al., 1992), pois as investigações
de trabalhos correlacionados tiveram o intuito de aproximar o pesquisador com o objetivo principal
da pesquisa, a fim de familiarizar o mesmo com as características e peculiaridades do tema a ser
explorado.
1.3.2 Procedimentos Metodológicos
Este trabalho é uma pesquisa exploratória acerca das duas abordagens de desenvolvimento
de Soft IP-cores (Soft IPs) apresentadas anteriormente. Os procedimentos técnicos utilizados são
classificados em: (i) pesquisa bibliográfica, com base em assuntos relacionados a sistemas
automotivos, métricas e desenvolvimento de Soft IPs e metodologia de projeto de Soft IPs; e (ii)
pesquisa experimental, cujo objeto de estudo são métricas do Soft IP-core a serem analisadas em
uma rede automotiva LIN.
1.4 ESTRUTURA DA DISSERTAÇÃO
O presente documento está organizado em seis capítulos e quatro apêndices. O primeiro
capítulo, Introdução, apresentou-se por meio de sua contextualização do tema proposto neste
trabalho. Da mesma forma, foram estabelecidos os resultados esperados por meio da definição dos
objetivos geral e específicos, as limitações do escopo do trabalho e os procedimentos metodológicos
utilizados no desenvolvimento da dissertação. O Capítulo 2 apresenta um breve estudo sobre redes
automotivas, discorrendo sobre aspectos econômicos do uso desses sistemas, os padrões
estabelecidos no mercado e uma breve análise dos aspectos fundamentais do protocolo LIN, objeto
de estudo deste projeto. Além disso, é apresentado um estudo sobre sistemas embarcados, bem
como as métricas de projeto, as tecnologias de circuitos integrados existentes um estudo sobre a
22
metodologia de processo ipPROCESS. É também feita uma análise sobre verificação formal e
funcional e os trabalhos relacionados. O Capítulo 3 apresenta uma discussão sobre trabalhos
relacionados à implementação em software e em hardware de sistemas de natureza similar ao
protocolo LIN, permitindo assim a identificação de métodos e métricas para a avaliação do
protocolo LIN. No Capítulo 4 são apresentados detalhes sobre projeto do LIN SW e do LIN HW à
luz da metodologia ipPROCESS. Já no Capítulo 5 são apresentados os resultados obtidos da
verificação funcional, das etapas de testes, dos custos de silício e potência consumida, uma análise
dos resultados e por fim as considerações finais. Finalmente, no Capítulo 6, são apresentadas as
conclusões finais, as contribuições e as sugestões para trabalhos futuros.
23
2 REDES AUTOMOTIVAS E O PROTOCOLO LIN
O primeiro automóvel a gasolina foi produzido na Europa por Karl Benz, em 1885, mas o
impulso industrial foi dado por Henry Ford com o lançamento do FORD MODEL T nos EUA em
outubro de 1908. Neste um século, que separa o pioneirismo de Benz e Ford e a indústria
contemporânea, o automóvel evoluiu e estabeleceu padrões, conceitos e economias. Neste sentindo,
o Capítulo 2 pretende analisar alguns aspectos das redes automotivas modernas, sem a pretensão de
se constituir um estudo completo.
Este capítulo é dividido em sete seções, nas quais são apresentadas definições e
classificações das redes automotivas com relação às topologias utilizadas e as classificações SAE
(Society of Automotive Engineers), entre outros aspectos. São ainda analisados os padrões
estabelecidos de redes automotivas (CAN, MOST, FLEXRAY e LIN) e aspectos principais do
protocolo LIN. Também são apresentadas métricas de projeto de sistemas embarcados, as
tecnologias de circuitos, a metodologia de projeto ipPROCESS, aspectos da verificação de núcleos
e por fim, são apresentadas algumas considerações ao final do capítulo.
2.1 DEFINIÇÕES E CLASSIFICAÇÃO DAS REDES AUTOMOTIVAS
Sistemas automotivos agregam diversos dispositivos eletromecânicos, muito destes
controlados por unidades de processamento central ou ECU (Electronic Central Units), que
interagem entre si. Essa interação somente é possível com a troca de informações entre os sistemas,
como ocorre com o sistema de combustível no qual necessita trocar informação com o painel do
automóvel (dashboard) a fim de informar ao motorista o nível de combustível do tanque. Uma
solução encontrada é a interconexão desses dispositivos através de uma rede automotiva, formando
assim um barramento principal e os barramentos complementares ou sub-redes. Algumas topologias
são amplamente empregadas nesse barramento principal, tais como: (i) estrela; (ii) barramento; e
(iii) em anel.
A escolha da topologia de cada rede dentro do automóvel depende, entre outros fatores, da
eficiência e da velocidade da troca de mensagens (SOARES et al., 1995) e do tipo de arquitetura
escolhida (centralizada ou distribuída).
24
Em um automóvel, a arquitetura centralizada comum, consiste em uma ECU gerenciando
todas as informações oriundas dos sensores e atuadores do automóvel. O uso dessa arquitetura
implica em uma maior quantidade de cabos interligando os dispositivos bem como convergência
das decisões para a ECU. Ocorre que com o emprego dessa arquitetura, o automóvel para de
funcionar no caso de uma pane na unidade central. Ainda assim, a arquitetura centralizada possui
aspectos positivos devido à simplicidade da interconexão e por dispensar uma lógica mais complexa
para a aquisição dos dados.
Já na arquitetura distribuída, as ECUs são interligadas por uma rede de comunicação cuja
função é a troca de mensagens pré-estabelecidas. Essa arquitetura resulta em sistemas mais
robustos, pois uma pane4 de uma ECU não compromete a comunicação entre os outros dispositivos.
Outro aspecto que deve ser levado em consideração é a redução no cabeamento5 do automóvel, o
que significa menor tempo na montagem, menor custo de manutenção e peso final do automóvel.
O uso dessa arquitetura somente foi possível com a utilização em larga escala de
dispositivos OEM (Original Equipment Manufacturer), tanto em nível de hardware quanto em
software. Eles tornaram as redes distribuídas mais modulares e permitiram que a indústria avaliasse
melhor os custos finais do automóvel. Segundo Soares et al. (1995) vários são os fatores que tornam
a utilização dessa arquitetura mais atraente, tais como: (i) custo/desempenho; (ii) tempo de resposta;
(iii) modularidade; (iv) confiabilidade; e (v) concorrência. Este último, utilizado em sistemas que
necessitam de processamento concorrente.
As redes automotivas são padronizadas por órgãos internacionais como a SAE, a ISO
(International Organization for Standardization) e o IEEE (Institute of Electrical and Electronics
Engineers), de forma que todas as especificações e normalizações sejam cumpridas pelas empresas
que se dispõe a trabalhar com esses padrões. A SAE também é a responsável por especificações de
padrões automotivos como CAN (SAE J1939) e LIN (SAE J2602). Nesse sentido, a SAE classifica
as redes automotivas em:
4 Considerando uma pane que isole a referida ECU da rede de comunicação, ou seja, que não comprometa a integridade
da rede. 5 Tendo em vista uma arquitetura centralizada ou ponto-a-ponto, cujos dispositivos são interligados à ECU utilizando
um cabo de dados e alimentação.
25
SAE – Classe A: protocolos utilizados em dispositivos como sensores e atuadores
inteligentes. Esses dispositivos não executam tarefas críticas dentro do automóvel e em
geral atuam em sistemas cuja taxa de transmissão é baixa, na faixa entre 1 e 10 kbps6.
Segundo Lupini (2004), utilizam SAE - Classe A em seus dispositivos: a BMW com o
I - Bus (Instrumentation bus); a Fiat, Daimlerchrysler, Honda, Jaguar, Renault e
Volkswagen com o LIN; Ford e General Motors com a UART (Universal Asynchronous
Receiver/Transmitter); Mitsubishi com o MICS (Mitsubishi Intelligent Cockpit System);
e a Peugeut com a VAN (Vehicle Area Network);
SAE – Classe B: compreendem os dispositivos cuja taxa de transmissão está entre 10 e
125 kbps. São amplamente utilizados em interconexões de ECUs devido a aspectos
como: suporte a modo diagnóstico, escalabilidade, detecção de erros entre outros.
Segundo Lupini (2004), utilizam SAE – Classe B em seus dispositivos a AUDI com o
CAN, ABUS e ISO 9141-2 (diagnóstico); a BMW com o TTP/B (TimeTriggered
Protocol/B), ISO 9141-2 (diagnóstico) e o CAN7; a DaimlerChrysler VPW J1850, ISO
9141-2 (diagnóstico) e Néon 1995; a Citroën e a Fiat com a VAN; a Ford com o SCP,
ISO 9141-2 (diagnóstico) e MSCAN; a General Motors com a UART e GMLAN; a
Honda com o J1850 e Single-wire CAN; e a Jaguar com o J1850, CAN e o Sallon;
SAE – Classe C: aplicado em dispositivos cuja taxa de transmissão está compreendida
na faixa entre 125 kbps e 1 Mbps. Esse protocolo envolve dispositivos que requerem
transmissão em tempo real, como o sistema de navegação e cruzeiro e os sistemas de
segurança como o ABS (Anti-lock Braking System). Lupini (2004) cita o CAN e suas
variações como o protocolo mais utilizado pela indústria automotiva; e
6 O LIN Consortium (2006) é considerado um protocolo classe A.
7 Segundo Lupini (2004) a BMW utiliza o CAN somente para os seguintes automóveis: 530i, 540i, 730i, 740i, 840i e
850i.
26
Infotainment8: consistem em protocolos que integram o uso de computadores pessoais,
GPS (Global Positioning System), Web e vídeo/som ao veículo, ou seja, são dispositivos
relacionados ao entretenimento dentro do veículo e à troca de informação com a rede
mundial de computadores.
2.2 PADRÕES DE REDES AUTOMOTIVAS
Para Day (2005), mesmo com a maturidade dos padrões de protocolo de comunicação
automotivos, as intermináveis variações e versões dos produtos OEM dificultam a venda dos
dispositivos em larga escala. Dessa forma, em especial as grandes montadoras têm focado suas
tecnologias de redes automotivas em padrões consolidados como o CAN, LIN, FlexRay e MOST. O
benefício da adoção de um padrão dá-se pela possibilidade do uso de diversos fornecedores (livre
concorrência), a significativa redução de custos, fornecedores mais focados em suas competências,
e outros fatores, como tempo de projeto e confiabilidade dos sistemas.
Nesse sentido, o protocolo CAN consolidou-se como padrão ISO 11898 (para aplicações de
alta velocidade, classe C) e ISO 11519 (para aplicações de baixa velocidade, classe B), cuja
normativa especifica rigorosamente detalhes do meio de transmissão, métodos de tolerância a
falhas, controle e confinamento de erros9, tipo de mensagens e detalhes de
temporização (GUIMARÃES, 2007).
Já o protocolo FlexRay (BMW, 2005) é amplamente utilizado pela BMW em especial nos
sistemas de controle de suspensão, ou DSC (Dynamic Stability Control), do BMW X5. O FlexRay
em sua topologia de rede utiliza várias CPUs, sendo que apenas uma CPU ocupa o barramento de
cada vez. A topologia do protocolo FlexRay ainda permite a existência de um canal (single channel)
8 Infotainment trata-se de um termo adotado para padrões de rede que agregam informação e entretenimento no
automóvel. Esse conceito vem sendo amplamente divulgado especialmente quando se trata de acesso à rede mundial de
computadores através de tecnologias sem fio. Não existem limites para esse novo conceito, tendo em vista que, no
presente momento já se associa a palavra infotainment a smart-grid. Nesse contexto, é possível vislumbrar um cenário
com automóveis com GPS trocando informações entre si, determinando melhores rotas, fornecendo ao condutor
informações de preços e qualidade de combustível. Outro cenário possível é a compra on-line de mídias pelo condutor,
armazenamento desses dados no automóvel, a utilização de comandos viva-voz e projeção de informações acerca das
condições da estrada no vidro frontal do automóvel (HUD - Head Up Display). 9 Confinamento de erros é uma característica que delimita a propagação dos erros no barramento, ou seja, a ocorrência
de uma pane em uma unidade central não acarreta na pane de todo o sistema.
27
ou dois canais (dual channels), para garantir redundância. Este protocolo ainda é subdividido em
grupo de comunicação, distribuído em topologias de barramento, estrela e híbrida (combinação de
topologia barramento e estrela).
O protocolo MOST (Media Oriented Systems Transport) cobre aspectos relacionados a
transmissão multimídia e infotainment no automóvel. A rede MOST caracteriza-se por ser de fácil
uso, amplo escopo de aplicações, flexibilidade, sinergia entre consumidor e indústria e baixo custo
de implementação (MOST, 2010). A empresa VECTOR possui diversas soluções que utilizam
MOST, tais como ferramentas de análise da rede, software em conformidade com o padrão
AUTOSAR10
para ECU, ferramentas de desenvolvimento e teste e ampla documentação.
Outro protocolo amplamente utilizado em dispositivos inteligentes11
é o LIN, em especial
devido ao seu baixo custo e por ser complementar ao CAN. O protocolo LIN é utilizado em
dispositivos de baixa velocidade (entre 1 kbps e 20 kbps), para complementar aplicação como
travas de porta, janelas e sistemas de ajuste de banco, entre outros dispositivos. Por ser o protocolo
alvo deste trabalho, a seção a seguir apresenta uma descrição mais detalhada sobre ele.
2.3 PROTOCOLO LIN
Charette (2009) ressalta a evolução da eletrônica no automóvel analisando a primeira ECU
automotiva produzida comercialmente, cujo propósito único era controlar o sistema de ignição
eletrônica do Tornado 1977 da GM, com as atuais 30 ou 50 ECUs utilizadas em carros de baixo
custo. A idéia de usar redes para interligar esses dispositivos dentro de um automóvel emergiu de
práticas e arquiteturas de redes adotadas na década de 1980 pelos maiores fabricantes de
automóveis do mundo. Na sua grande maioria, esses dispositivos eram interligados utilizando o
padrão UART, mas, mesmo dividindo características comuns, eram raramente compatíveis devido à
grande gama de fornecedores e seus padrões proprietários. Neste sentido, o amadurecimento das
redes automotivas começou com o surgimento de práticas e da adoção de arquiteturas padrão pelos
10
AUTOSAR - Automotive Open System Architecture, é uma arquitetura de software aberto e padronizado para
sistemas automotivos, desenvolvido em conjunto com grandes montadoras de automóveis, fornecedores e
desenvolvedores de ferramentas automotivas. ( www.autosar.org) 11
O autor deste trabalho define como Dispositivos Inteligentes em Automóveis todo(s) dispositivo(s) que troca(m),
repassa(m) ou adquire(m) informações de sensores e atuadores, através de um protocolo de comunicação com outro(s)
dispositivo(s).
28
grandes fabricantes automotivos. Estas arquiteturas baseadas na UART12
compartilhavam
características comuns, mas raramente eram compatíveis entre si (RUFF, 2003).
Padronização do protocolo e adoção pela indústria automotiva
A padronização do protocolo foi estabelecida pelo LIN Consortium (LIN, 2006), sendo a
primeira revisão estável a revisão 1.1 em 1990, seguida de grandes mudanças na revisão 1.3 e
revisão 2.0. Esta última expandindo os modos de configuração do barramento e introduzindo a
capacidade de diagnóstico do sistema. Atualmente, vigora a revisão 2.1, sendo que essas
modificações trouxeram uma flexibilidade maior, mas aumentaram potencialmente a complexidade
do sistema. Inicialmente as montadoras norte-americanas foram temerosas em adotar o LIN como
um padrão para interconectar seus dispositivos. Contudo, com a proliferação de componentes de
baixo custo bem como a simplificação dos processos de manufatura, a SAE adotou o protocolo e
influenciou fortemente na revisão 2.1. Com as mudanças drásticas a partir da revisão 2.0, a qual
expande as versões anteriores, foram abordadas questões como: (i) recursos adicionais de
diagnóstico; e (ii) interfaces de ferramentas padrão. Como mencionado anteriormente, essas
modificações proporcionaram maior flexibilidade, entretanto aumentaram ao mesmo tempo a
complexidade do sistema.
Toda essa inquietação gerada pelos fabricantes de automóveis dos EUA, combinada com a
falta de representação direta do Consórcio LIN na América do Norte, levou a SAE a formar uma
força-tarefa que assessorou e influenciou a nova revisão do LIN, o SAE J2602. Dessa forma, foi
garantida uma adoção global do padrão (RUFF, 2003). A União Européia (UE) e os Estados Unidos
da América (EUA) aprovaram o LIN, principalmente devido à proliferação dos diversos
componentes de baixo custo (em especial chineses), a redução dos custos e simplificação dos
sistemas de manufatura que utilizam LIN.
Segundo Ruff (2003), soluções em hardware especializado (ASIC semi-custom) para LIN
podem ser desenvolvidas em larga escala (baixo custo). Essas soluções simplificam etapas e
questões de fabricação, desenvolvimento e manutenção de sistemas, cujos problemas são
recorrentes na indústria automotiva. Uma tendência de soluções especializadas está na integração e
12
São comumente chamados de UBPs - UART base protocols
29
automatização dos detalhes do protocolo LIN dentro do próprio hardware (alguns detalhes são
tratados no software, como é o caso da sinalização de início de pacote). Essas soluções simplificam
etapas e questões de fabricação, desenvolvimento e manutenção de sistemas, cujos problemas são
recorrentes na indústria automotiva. Outro grande benefício da implementação de hardware é a
possível integração com outros dispositivos semicondutores, cujos custos, em geral foram reduzidos
devido ao alto nível de integração dos semicondutores (RUFF, 2003).
Dessa forma, supõe-se que o hardware dedicado utilizado na manipulação lógica dos
protocolos não é mais do que uma etapa de integração entre núcleos, tanto que essa integração vem
redefinindo as fronteiras entre hardware embarcado e software gerenciando os dispositivos. A
integração de funcionalidade em dispositivos semicondutores compreende combinar componentes
discretos, circuitos analógicos, lógica digital e reguladores de tensão em um único dispositivo.
Essa integração proporciona projetos de módulos eletrônicos para o veículo com dimensões
reduzidas e mais confiáveis, além de possibilitar o incremento desses módulos na rede do
automóvel, em especial em locais cuja arquitetura do veículo não seja possível ou economicamente
viável.
Características do protocolo
As características mais marcantes do protocolo LIN são: sistema mono-mestre com
múltiplos escravos (até 16 escravos) e monofilar, taxa de transferência entre 1 e 20 kbps e baixo
custo de silício (baseado no padrão UART/SCI), entre outras.
A Figura 2 descreve o formato da mensagem LIN, cujos dados são encapsulados em quadros
(frames) de dados com estrutura fixa, ou seja, que necessariamente deve conter um campo de
cabeçalho (também chamado de request, o qual identifica o tipo de requisição) e outro campo de
resposta (chamado de response) (LIN, 2006). O cabeçalho deve, necessariamente, conter: (i) um
campo de parada (break-field); (ii) um campo de sincronização; e (iii) um byte de identificação do
referido quadro. O campo de resposta encapsula: os (iv) dados do protocolo LIN; e um (v) byte de
soma e verificação (LIN, 2006).
30
O break-field indica o início da transmissão de um novo quadro, o qual difere do caractere
ASCII zero (0x00) de uma UART por possuir extensão entre 11 e 14 bits. Já os campos que se
seguem possuem o padrão UART/SCI 8N113
(LIN, 2006). Depois do break-field vem o campo de
sincronização, o qual é representado pelo caractere hexadecimal 0x55 e viabiliza que o escravo se
sincronize com o clock do mestre (LIN, 2006). O campo de identificação permite que o escravo
saiba como interpretar o campo de dados a seguir. Além disso, o campo de identificação reserva os
bits 6 e 7 para fim de verificação por meio da paridade (LIN, 2006). A sequência de dados pode
possuir entre 2 ou 4 ou 8 bytes de dados, seguido do byte de soma e verificação, o qual garante a
correta recepção do campo de dados.
Figura 2. Formato de um quadro LIN
Fonte: LIN Consortium (2006)
Para Ruff (2003), a primeira geração de soluções LIN exigia que o nó mestre gerasse um
break-field de 13 bits. Esse comprimento, anormal para uma UART, era gerado de duas formas. Na
primeira forma, é responsabilidade do desenvolvedor utilizar os mecanismos de software descritos a
seguir:
13
Oito bits de dados, sem paridade e um stop bit.
31
Configurar o bit-rate da UART para ser 30% mais lento do que o bit-rate correto da
rede;
Gerar um break-field com 10 bits, que poderia aparecer para o resto da rede como 13
bits; e
Reconfigurar o bit-rate para o valor correto do protocolo LIN.
Essa solução proporciona uma significativa sobrecarga (overhead) de software,
especialmente considerando que tal processo deve ser realizado em todos os quadros de mensagem
enviada pelo mestre. A segunda alternativa, menos elegante, segundo Ruff (2003), faz uso de uma
característica específica da maioria das UARTs: mantendo um bit de controle ativo por tempo
suficiente para o envio de um segundo break-field, o que possibilita gerar o break-field com o
tamanho de 20 tempos de bit na rede. Isso foi considerado pela maioria dos desenvolvedores como
uma solução inaceitável devido ao enorme desperdício de banda do barramento (RUFF, 2003).
Assim, a solução encontrada pela indústria de semicondutores foi permitir que a UART transmitisse
o break-field com 13 bits de comprimento, como ocorre com a família de microcontroladores da
Freescale HCS12.
Outro aspecto do protocolo LIN está nos tipo de mensagens enviadas no barramento. O
protocolo possui dois tipos de mensagens distintas: (i) mensagens de transmissão de quadros (frame
request), as quais contêm dados enviados do mestre para o escravo com um campo requisição
seguido de um campo de resposta enviado pelo mestre; e (ii) mensagens de quadro de resposta
(frame response), na qual o mestre envia um campo de requisição e aguarda um campo de resposta
enviado pelo escravo. Em ambos os casos, o campo de requisição é enviado pelo nó mestre.
O protocolo (LIN, 2006) descreve ainda uma especificação da interface de programação
(API), a LIN API. Essa interface de programação abstrai da camada de Transporte detalhes da
configuração da rede LIN, facilitando para o usuário comum a criação de aplicações. A API descrita
é focada no transporte de sinais dentro do barramento LIN, provendo assim uma maior flexibilidade
na configuração do protocolo. A LIN API trata da inicialização, processamento e interação de sinal
entre a aplicação e o núcleo LIN. A especificação também detalha uma API para identificação e
configuração do nodo e outra API descrevendo detalhes da camada de Transporte. Toda essa
descrição tratada pelo protocolo facilita para o desenvolvedor a criação de soluções, em especial de
baixo custo utilizando microcontroladores.
32
Com o passar do tempo, o protocolo sofreu modificações, proporcionando um grande
desafio para as montadoras e fornecedores de produtos. Para Ruff (2003) a especificação LIN
mantém a promessa de se tornar um padrão global para redes de sensores e sistemas de acionamento
de baixo custo. Basta analisar as variedades de dispositivos apresentados pela indústria de
semicondutores, cuja gama de soluções OEM vai de microcontroladores e transceivers até a
possibilidade de uso de códigos abertos e kits de desenvolvimento para acelerar o processo de
desenvolvimento de sistemas utilizando o protocolo. Outro aspecto interessante que deve ser
mencionado, que devido às características do protocolo, as aplicações em geral estão relacionadas a
sistemas de controle da porta (acionamento do vidro elétrico), controle do assento, iluminação
veicular, sistemas de sensores do volante, controle de posição dos espelhos retrovisores, além do
controle e acionamento do teto solar, entre outras possíveis soluções que abrangem as
características do protocolo LIN.
2.4 TÉCNICAS DE PROJETO DE CIRCUITOS INTEGRADOS
Segundo Vahid (2002), foi estimado que, em 1999, uma típica casa norte-americana possuía
um computador tipo desktop e mais outros 35 a 50 computadores embarcados. Além disso, em
geral, um computador embarcado executa um único programa repetidamente e é sujeito a fortes
restrições quanto ao custo do produto, às suas dimensões físicas, ao desempenho e ao consumo de
energia elétrica.
2.4.1 Métricas de Projeto
As métricas ou requisitos de projeto servem como referência para medir as características, a
qualidade e a evolução do sistema desenvolvido. Quanto mais próximo o projeto está das métricas,
mais fácil será para entender e avaliar os atributos do sistema criado. Segundo Vahid (2002), as
métricas mais comuns utilizadas em sistemas embarcados são:
Custo NRE (Non-Recurring Engineering): custo relacionado ao desenvolvimento inicial
do sistema, cuja manufatura de novas unidades não incorre em novo custo NRE
adicional;
Custo unitário: custo de produção de cada exemplar do sistema;
33
Tamanho: define o espaço físico que o sistema utiliza para encapsular a sua
funcionalidade;
Desempenho: está relacionado ao tempo de execução do sistema;
Consumo de energia: consiste na quantidade de energia utilizada pelo sistema (também
representada pela potência dissipada);
Flexibilidade: compreende a característica de mudar uma funcionalidade sem a
necessidade de novamente re-projetar todo o sistema, ou seja, sem maiores custos NRE
(Non-Recurring Engineering);
Time-to-Prototype: tempo para o desenvolvimento de uma versão estável de um sistema;
Time-to-Market: tempo entre a concepção de um sistema e a venda ao consumidor;
Segurança: consiste na probabilidade do sistema não causar danos ao seu ambiente ou
usuários; e
Exatidão (correctness): consiste na correta implementação do sistema, cuja
funcionalidade esperada condiz com a implementação executada.
2.4.2 Tecnologias de Circuitos Integrados
Para Vahid (2002), todo o processador deve ser implementado em um circuito integrado
(CI). A maneira como os transistores e outros periféricos são interconectados no CI é o que torna
uma tecnologia diferente da outra. Nesse sentido, existem diversos processos para fabricação dessas
tecnologias de semicondutores, sendo a mais comum a CMOS (Semicondutor Metal-Óxido
Complementar). Um CI pode ser fabricado para implementar uma funcionalidade específica ou
mesmo ser genérico o suficiente para implementar qualquer funcionalidade. As três principais
tecnologias de circuito integrado são: full-custom, semi-custom e lógica programável.
Na tecnologia full-custom, todas as camadas do CI são otimizadas para uma implementação
específica em um sistema embarcado (Vahid 2002). Essa otimização inclui todas as etapas de
fabricação do transistor e as etapas de síntese lógica e síntese física do projeto. O uso de tecnologia
full-custom possui uma escala de integração grande entre os blocos lógicos, entretanto também
possui um custo NRE bastante alto e longo time-to-market. O emprego dessa tecnologia é
34
justificável em grandes volumes de manufatura para sistemas que requer um desempenho muito
grande.
Na tecnologia semi-custom, o projeto é desenvolvido utilizando blocos pré-existentes ou
Standart Cells14
. Somente na etapa final são estabelecidas as conexões por meio de interligações
entre as células lógicas. Os CIs semi-custom são os mais populares do mercado, pois possuem boas
características de desempenho e tamanho com um custo NRE muito menor se comparado com os
CIs full-custom. Já na tecnologia de lógica programável, ou CI programável existe duas tecnologias
que se destacam: os PLDs e os FPGAS.
Os dispositivos lógicos programáveis ou PLDs (Programmable Logic Devices) possuem
arranjos de células lógicas com interconexões programáveis eletricamente. Dessa forma o projetista
fica encarregado de configurar as interconexões das células, dispensando a participação do
fabricante. Os PLDs podem ter diferentes níveis de densidade lógica. Segundo Brown et al. (1996),
os primeiros dispositivos de baixa densidade desenvolvidos para programar circuitos lógicos foram
os PLAs (Programmable Logic Array). Os PLAs são constituídos por arranjo de dois tipos de portas
lógicas programáveis: a porta lógica AND e a porta lógica OR. Um segundo tipo são os PALs
(Programmable Array Logic), os quais diferem dos PLAs por não possuírem a porta lógica OR
programável, mas sim fixa. Já os CPLDs (Complex Programmable Logic Devices) possuem de
baixa a média densidade lógica e caracterizam-se por utilizarem uma estrutura de interconexão
contínua em que os atrasos são não cumulativos, possuírem sincronização (timing) fixa e previsível
e rápida compilação do projeto. Além dos PLDs, existem os FPGAs (Field Programmable Gate
Array ou Arranjo, ou matriz de portas programável em campo) que possuem uma densidade lógica
de média a alta, com estrutura de interconexão segmentada, resultando em atrasos acumulativos,
variável com roteamento e não previsível. A compilação é mais lenta (VAHID, 2008).
A tecnologia mais consolidada de CI programável é o FPGA (VAHID, 2008). Essa
tecnologia é basicamente constituída de blocos de entrada e saída, tabelas de consulta (LUTs –
Lookup Tables) e matrizes de chaveamento. Segundo Vahid (2008), FPGAs fundamentalmente
14
Para Vahid (2008) um projeto que utiliza células padrão ou standard cells usa bibliotecas de células que utilizam
leiautes prévios. Essas células devem ser escolhidas conforme a especificação do projeto (low-power, RF, entre outras),
devendo ser interconectadas formando assim um circuito.
35
implementam lógica combinacional utilizando memórias para implementar as tabelas de consulta.
Para implementar circuitos sequenciais, em cada saída da tabela lookup há um flip-flop. Assim, a
cada ciclo de clock, o flip-flop é carregado com o valor correspondente da tabela de consulta. Com o
uso das matrizes de chaveamento é possível programar as conexões entre as tabelas de consulta,
customizando assim as conexões entre as memórias. Por fim, existem os blocos de entradas e saídas
responsáveis pelos interfaceamento entre as saídas das tabelas de consulta e as entradas e saídas do
FPGA. Este bloco consiste em buffers e um conjunto de circuitos de chaveamento ou
multiplexadores, que funcionam como pinos bidirecionais entrada e saída do FPGA.
A pioneira na tecnologia de dispositivos lógicos programáveis do tipo FPGA foi a Xilinx. A
tecnologia foi criada inicialmente em 1984 para suprir a demanda para o desenvolvimento de
circuitos integrados customizados. Não obstante, a Altera foi pioneira na criação e desenvolvimento
de dispositivos do tipo CPLD, em 1983, suprindo a demanda por dispositivos não voláteis para a
indústria de semicondutores.
Do ponto de vista comercial, os FPGAs possuem um preço unitário maior que os CIs (full-
custom ou semi-custom) produzidos em escala, mas constituem em uma boa opção quando a
necessidade é de um projeto customizado, com poucas unidades, baixo time-to-market, rápido time-
to-prototype e exatidão, entre outros fatores.
Nesse contexto, o desenvolvimento de um projeto de circuito digital para um CI exige
semanas ou mesmo muitos meses de esforço das equipes de projeto. Esse esforço possui custo
considerável, tanto em mão-de-obra quanto em ferramentas de desenvolvimento. Dessa forma,
projetos de CIs full-custom ou semi-custom que possuam algum risco ao investidor, tal como erros
na especificação, na síntese lógica ou na síntese física, não se justificam. Assim, quando requisitos
de tamanho e consumo de energia (low-power), entre outros, não são determinantes e quando existe
a necessidade de desenvolvimento rápido, justifica-se então o uso de tecnologias de CI
programáveis (VAHID, 2008), como os PLDs e FPGAS.
Para facilitar o desenvolvimento de aplicações, fabricantes ou empresas especializadas
oferecem soluções pré-projetadas e pré-verificadas para serem utilizadas na tecnologia desejada.
Estas soluções são os núcleos (do inglês, cores) ou blocos de propriedade intelectual – Intellectual
Property (IP). Assim, por se tratar de propriedade intelectual, todos os núcleos estão sujeitos a
alguma forma de licença, patente ou direito autoral.
36
Os núcleos são desenvolvidos para uma tecnologia alvo (ex. FPGAs ou ASIC) e são
descritos utilizando alguma linguagem de descrição de hardware (HDL – Hardware Description
Language), tal como VHDL ou Verilog. Segundo Zeferino (2003), os núcleos disponibilizados ao
projetista de integração são classificados segundo a forma como são disponibilizados pelo
fabricante, em:
Soft IP-core: HDL sintetizada para diferentes processos de fabricação. Possui grande
flexibilidade, contudo a área, o timing e a potência consumida não podem ser estimados
devido à necessidade de uma tecnologia-alvo;
Netlist ou firm-core: descreve a conectividade de um projeto, ou seja, contém
informações relativas ao posicionamento e roteamento da lógica na tecnologia alvo.
Inclui uma combinação do RTL sintetizado, a biblioteca de referência da tecnologia,
detalhamento do floorplan e o detalhamento do roteamento (netlist) (LIMA et al., 2005);
e
Máscara da tecnologia ou hard-core: contém todas as informações de leiaute e
temporização (timing) do circuito. Hard-cores são otimizados para um melhor
aproveitamento de área e consumo de energia, contudo não são flexíveis a mudanças,
como os modelos anteriores.
Para Tobar (2005), uma das principais características de um bloco IP está na sua prévia e
clara definição da forma de comunicação do bloco, no fato de ser sintetizável e atingir métricas de
exatidão que asseguram que a implementação executada condiz com a funcionalidade esperada.
2.4.3 Processador Embarcado Nios II
Diversas são as soluções de processadores do tipo Soft-IPs cores que atendem a demanda de
flexibilidade e baixo custo (Nios II, ARM, Microblaze, etc). A arquitetura desses processadores
(RISC15
, CISC16
, SPARC17
) evidencia a fácil programação dos microcontroladores e mantém a
flexibilidade de customizar aplicações, tais como processamento de sinais (DCT, FIR), automotiva
15
RISC – Reduced Instruction Set Computing 16
CISC – Complex Instruction Set Computing 17
SPARC – Scalable Processor Architecture
37
(CAN, LIN, MOST) e telecomunicações (GSM, 3G, CDMA). A comunicação entre o processador e
os blocos customizados se dá por meio de barramentos proprietários como o AMBA, Avalon e o
IBM CoreConnect (YASSINE et al., 2004), costumeiramente utilizando escrita e leitura em blocos
de memória por meio de uma lógica de controle.
O processador Nios II (ALTERA, 2011) pertence à família dos Soft-IPs cores, RISC e de
propósito geral. As principais características desse processador são: (i) set de instrução de 32bits
(caminho de dados e espaço de endereçamento); (ii) 32 registradores de propósitos gerais; (iii)
suporte a MMU; (iv) ambiente de desenvolvimento baseado em Eclipse (Integrated Development
Environment – IDE); (v) temporizadores; e (vi) diversas formas de interrupções e de acesso a
periféricos. Assim, os sistemas desenvolvidos utilizando o processador Nios II são similares a um
microcontrolador ou mesmo a “computador em um chip” (ALTERA, 2011). Esses sistemas
constituem um arranjo do núcleo do Nios II, periféricos e memórias on-chip, controladoras de
interfaces de comunicação com dispositivos off-chip, tudo implementado em um único dispositivo
do tipo FPGA.
Na Figura 3, tem-se um exemplo de um sistema que utiliza Nios II. Nessa figura, é possível
observar os periféricos externos e suas controladoras, como memórias Flash, LCD e Ethernet
MAC/PHY, bem como temporizadores e UART, todos interligados ao processador Nios II por meio
do barramento Avalon e programados utilizando JTAG (Joint Test Action Group ou IEEE 1149.).
38
Figura 3. Exemplo de um sistema com o processador Nios II
Fonte: Altera (2011)
A maior diferença entre o Nios II e um microcontrolador padrão está na flexibilidade em
adicionar periféricos padrões ou customizados (ALTERA, 2011). Assim sendo, o processador
Nios II, por ser implementado utilizando lógica programável, permite que periféricos desenvolvidos
para uma aplicação específica (ou seja, periféricos customizados) sejam adicionados ao sistema.
Periféricos
Podem ser usados diversos periféricos no Nios II, tais como: (i) controladoras de memória;
(ii) interfaces de comunicação; (iii) timers; e (iv) interfaces controladoras de entrada e saída de
dados (I/O) de propósito geral.
No Nios II, a interface controladora de intervalo de tempo ou timer é baseada no barramento
Avalon e possui as seguintes características (ALTERA, 2011):
Contador de 32 bits e 64 bits;
Controle de start, stop e reset do timer;
39
Contador em dois modos: contagem regressiva por uma vez e contagem regressiva
contínua;
Registrador do período de contagem regressiva;
Habilitar ou desabilitar a interrupção (IRQ) quando o timer chega à zero;
Watchdog para reiniciar o sistema caso a interrupção do timer nunca ocorra;
Saída geradora de pulso quando timer chega zero; e
Compatibilidade com processador de 16 e 32 bits.
Todos os periféricos são configurados por meio das ferramentas SOPC ou MegaWizard da
Altera.
2.5 A METODOLOGIA DE PROJETO IPPROCESS
O ipPROCESS (LIMA et al., 2005) foi concebido como uma metodologia de
desenvolvimento de Soft IP-cores com prototipação em FPGAs. O ipPROCESS define as tarefas de
projeto do IP como um conjunto de atividades, na qual cada atividade determina: (i) o que deve ser
feito; (ii) quando; e (iii) por quem. A metodologia ipPROCESS possui um ciclo de vida cujo início
dá-se com o levantamento dos requisitos e das restrições do IP. Em um segundo momento, após
definida a estrutura do IP, as funcionalidades e os requisitos são modelados utilizando UML e
somente após o final das duas fases anteriores inicia-se a codificação em HDL. A fase de
codificação em RTL inicia primeiramente com uma descrição comportamental do IP, sendo todo o
processo com um refinamento cíclico do RTL, até a obtenção do comportamento e do código
desejado. Concomitantemente, são empregadas etapas de verificação funcional, a fim de garantir
que o RTL desenvolvido possua um comportamento similar ao modelo de referência18
(golden
model) utilizado.
Os conceitos do ipPROCESS foram definidos com base nas metodologias de processo de
desenvolvimento de software RUP – Rational Unified Process, da IBM e XP - eXtreme
18
O modelo de referência ou golden model consiste em uma abstração do IP desejado. Possui a função de servir como
base para a validação do IP ou DUV - Device Under Verification, em geral esse modelo é descrito em nível TL.
40
Programming, da Object Mentor Inc. A principal idéia no uso de engenharia de software está no
fato de o desenvolvedor conceber o sistema utilizando um nível de abstração mais alto, sem que
exista a necessidade do desenvolvimento em algum hardware específico (LIMA et al., 2005).
A Figura 4 traz um gráfico (gráfico de baleia) da arquitetura do ipPROCESS, no qual o eixo
vertical representa as disciplinas e o eixo horizontal representa o ciclo de vida do projeto (LIMA et
al., 2005).
Ainda segundo Lima et al. (2005), os aspectos relacionados com a dinâmica do ipPROCESS
abrangem todas as atividades distribuídas ao longo do tempo, representadas no primeiro plano da
Figura 4 como as fases (phases) e as interações (iterations) ou milestones. Já os aspectos estruturais
do ipPROCESS são representados em segundo plano pelas disciplinas (disciplines), atividades,
fluxo de trabalhos, artefatos e regras.
Figura 4. Arquitetura do ipPROCESS
Fonte: Lima et al. (2005)
Assim, a Figura 4 ilustra as diversas disciplinas e o quanto o desenvolvedor deve priorizá-
las, como ocorre na fase de concepção (conception), cuja disciplina de requisitos (requirements)
demanda maior atenção quando comparada com disciplina de verificação (verification).
2.6 VERIFICAÇÃO
Uma forma encontrada pela indústria de semicondutores para que projetos de sistemas
eletrônicos atinjam rapidamente o mercado está na reutilização de módulos de IPs. Contudo,
algumas métricas de projetos devem ser respeitadas, sendo que uma das formas de garantir o
41
cumprimento dessas métricas está na aplicação de várias etapas de verificação. Ainda assim,
segundo Tobar (2005), a verificação tem o intuito de conferir um grau de qualidade ao projeto de
sistemas digitais. Bergeron (2006) complementa que o processo de verificação tem o intuito de
garantir que a intenção do projeto foi preservada após a sua implementação.
Bergeron (2006) e Tobar (2005) analisam duas abordagens distintas para serem utilizadas na
verificação de um IP, a primeira utilizando métodos formais ou verificação formal e a segunda
utilizando verificação funcional ou verificação funcional por simulação.
2.6.1 Verificação Formal
Para Bergeron (2006) a verificação formal (ou de equivalência) não exime a escrita de
testbenches e sua aplicação engloba duas categorias, a verificação de equivalência (equivalence
checking) e a verificação de propriedade (property checking). Assim, a verificação formal consiste
em um processo na qual matematicamente se prova que o(s) sinal (is) de origem e a saída(s)
resultante(s) são logicamente equivalentes e que dessa forma, a transformação desses sinal (is)
preservou a funcionalidade esperada. Bergeron (2006) cita que é comum na verificação de
equivalência a comparação de duas netlists a fim de garantir que após algumas etapas da síntese
física (netlist pós-síntese); como na inserção de scan-chain, síntese da árvore de clock (clock-tree) e
alguma modificações manuais; nada tenha mudado na funcionalidade do circuito. Outro aspecto na
verificação de equivalência está na análise da equivalência lógica de duas descrições em RTL, bem
como se a netlist implementa corretamente o código RTL original.
Na verificação de propriedade, um conjunto de afirmações (assertions) ou características do
projeto é utilizado para analisar o comportamento de uma propriedade (estados, variáveis, etc) do
projeto. Caso alguma violação ocorra em qualquer um desses comportamentos previstos (conjunto
de afirmações ou características), uma sinalização é ativada, evidenciando o erro ocorrido. Para
Bergeron (2006) o emprego de afirmações está também ligado à verificação das interfaces de
projetos estabelecidas.
2.6.2 Verificação Funcional
O surgimento da verificação funcional se deu principalmente pela necessidade de garantir
maior qualidade nos projetos de sistemas digitais. Ocorre que a codificação em RTL está sujeita a
42
erros humanos, necessitando, portanto da equipe de desenvolvimento constantes atividades de
simulações a fim de provar a correta funcionalidade do projeto. Tobar (2005) observa então que um
dos objetivos da verificação é compensar o erro humano, estruturando a verificação, aplicando
redundância na modelagem e automatizando as atividades de testes. Nesse contexto, Bergeron
(2006) afirma que o principal propósito da verificação funcional é que o projeto implemente a
funcionalidade prevista. Segundo ele, com uma verificação superficial é fácil provar a presença de
erros, mas a dificuldade maior é que não é possível provar a ausência desses erros. Segundo Tobar
(2005), o conceito principal na verificação funcional está no fato de que duas implementações com
níveis de abstração distintos (nível de transação e nível de registradores) e desenvolvidos por
equipes distintas, equipe verificação e equipe de projeto, devem conter erros distintos.
Nesse sentido, para uma eficiente verificação funcional, são utilizados ambientes
controlados de simulação. Além disso, utilizando linguagem formal, são desenvolvidos testbenches,
cujo objetivo é comparar e verificar a integridade dos sinais do projeto. Na visão de Tobar (2005),
um testbench deve: (i) aplicar estímulos ao sistema digital; (ii) monitorar as respostas; e (iii)
conferir a consistência dos sinais do projeto.
Bergeron (2006) propõe um modelo de testbench (Figura 5) dividido em duas partes, a
camada de função de teste (testcases) e uma camada em nível de transação. Tobar (2005)
complementa o mesmo modelo, detalhando os níveis de abstração e os sinais das duas camadas. A
camada de função de teste tem por objetivo gerar os estímulos para a camada em nível de transação
(ou camada de amarração de teste), conferir a integridade dos sinais e ainda gerar relatórios
apontando as diferenças entre os dois níveis, para posterior análise da equipe de verificação e
projeto. A camada em nível de transação tem por objetivo converter os sinais em nível de
transação19
para sinais RTL, de forma que a iteração entre as duas camadas seja abstraída para o
dispositivo em teste, também chamado de DUV (Device Under Verification).
19
Segundo Silva (2007), uma transação consiste na representação básica da troca de informação entre dois blocos
funcionais, ou seja, possui início e fim determinados e se caracteriza por um conjunto de dados utilizados para realizar
alguma operação. Silva (2007) cita como exemplo o envio de um pacote Ethernet pela rede, bem como a leitura ou
escrita de uma memória. No contexto do presente trabalho, uma transação pode ser caracterizada pelo envio de uma
requisição do mestre e a resposta do escravo, ou seja, um pacote enviado pelo mestre com um cabeçalho LIN seguido
do recebimento de 2, 4 ou 8 bytes e soma e verificação enviados pelo escravo.
43
O módulo Checker (Verificação), que utiliza transações, testa as funcionalidades do DUV
com relação a um modelo de referência. Para Tobar (2005), este modelo pode ser o resultado de
trabalhos anteriores ou mesmo ser uma função de transferência que simplifica o comportamento do
dispositivo e os detalhes da implementação. Em geral, o modelo de referência é descrito utilizando
linguagem de alto nível como C/C++, SystemVerilog ou mesmo Java. O módulo Driver tem por
objetivo converter os sinais em nível de transação para RTL, testando implicitamente a interface de
comunicação do dispositivo.
Função de Teste
Gerador de Sinais Estímulos Auto-checagem
Driver DUV Monitor
Amarração de Teste
Figura 5. Modelo de testbench
Fonte: Bergeron (2006 apud TOBAR, 2005)
O módulo Monitor, além de testar a interface de comunicação, converte os sinais RTL para
transação, ou seja, de sinais de tempo para dados abstratos – ou transação (TOBAR, 2005).
Dentre os diversos modelos de testbench já propostos, Silva et al. (2007) especifica um
modelo modular (Figura 6), com condições de comunicação entre os módulos bem definidas, no
intuito de facilitar a reutilização dos módulos. Ainda, segundo Silva et al. (2007), a comunicação
entre os módulos é feita utilizando transações (representações abstratas das funcionalidade do
DUV), convertidas em sinais para interagir com o DUV; sinais que por sua vez utilizam um modelo
de barramento funcional (BFM) contidos dentro dos módulos Driver e Monitor.
44
Checker Source
DUV
Modelo de Referência
Driver Monitor
Figura 6. Modelo de testbench BVM
Fonte: Silva et al. (2007)
Assim, as operações utilizando o modelo proposto por Silva et al. (2007) utilizam transações
produzidas pelo Source (gerador de estímulos) e posteriormente enviadas em nível de sinal ao
DUV, por meio do módulo Driver. Por sua vez, os resultados produzidos pelo DUV são traduzidos
do nível de sinal para o nível de transação pelo módulo Monitor. Por fim, os sinais capturados pelo
Monitor são enviados para o Checker. Da mesma forma e simultaneamente, as transações geradas
são enviadas e processadas no modelo referência, cujos resultados são enviados para o Checker.
O modelo proposto por Silva et al. (2007) é um modelo já consolidado e amplamente
empregado no meio acadêmico. Ele foi aplicado por Tobar (2005), por exemplo, para a verificação
funcional da camada banda base do protocolo Bluetooth. Esse modelo é utilizado pelo programa
Brazil IP, sendo intitulado BVM (Brazil IP Verification Methodology) e usado na verificação
funcional do projeto do hardware do presente trabalho.
Segundo Hekmatpour et al. (2003 apud TOBAR, 2005) o processo de verificação ainda
engloba etapas de planejamento, implementação de modelos de referência, desenvolvimento de
testbenches, aplicação de testes, análise de diferenças, correção de erros, teste de regressão, análise
de cobertura, estímulo dos casos de canto (corner cases) e por fim a documentação de todo o
processo de verificação.
Para Lima et al. (2005), na etapa de planejamento, o plano de verificação tem o propósito de
definir como a arquitetura proposta deve ser verificada e definir os casos de teste (ou estímulos).
Tobar (2005) relaciona também o sucesso de um planejamento a elementos do processo, tais como
quantidade de testbench, fontes de estímulos, recursos humanos, técnicos e de tempo alocados para
a verificação. Devido às características dinâmicas da etapa de planejamento, o plano de verificação
deve ser constantemente atualizado e analisado com a finalidade de incluir aspectos ignorados no
45
início do processo, tais como: aspectos de funcionamento, operações, cenários e condições de
operação (TOBAR, 2005).
Já os modelos de referência são necessários devido à etapa de análise e verificação dos
resultados da saída do DUV. Como explicado anteriormente, os estímulos enviados
simultaneamente tanto para o DUV quanto para o modelo de referência são comparados entre si e o
resultado obtido com essa comparação resulta em uma análise da conformidade do testebench.
Assim, os modelos mais utilizados nesse caso são os modelos de referência ou as funções de
transferência (TOBAR, 2005), sendo que os modelos de referência são implementações em alto
nível da especificação, já as funções de transferência são modelos simplificados que representam
funcionalidades detalhadas na especificação. Os dois modelos possuem características específicas, o
modelo de referência, por exemplo, consiste em um modelo mais detalhado da especificação e
possui um grau de complexidade maior; já as funções de transferência representam a funcionalidade
estabelecida na especificação (TOBAR, 2005), contudo abstraem muitas vezes aspectos específicos
do projeto, o que resulta muitas vezes em alertas de não conformidades na etapa de verificação.
Segundo Tobar (2005), os estímulos podem ser caracterizados conforme a aleatoriedade e a
sua representação do sistema, sendo então divididos em:
Estímulos dirigidos: caracterizados pelo prévio conhecimento das respostas (golden
vectors), como por exemplo, os casos dos testes de conformidade (compliance tests);
Estímulos aleatórios: são estímulos gerados através de funções probabilísticas;
Casos reais: consistem em estímulos reais, cujas entradas esperadas estão dentro do
próprio domínio de aplicação; e
Casos extremos: são estímulos que prevêem situações com condições de contorno, ou
seja, condições extremas ou situações críticas do sistema.
Durante a verificação funcional é desejado que uma ampla variedade de condições sejam
previstas, e que as mesmas venham a testar todas as funcionalidades do sistema de forma a atingir
ao máximo a cobertura especificada. Portanto, a cobertura tem o intuito de medir o nível de
abrangência dos estímulos entre os dois modelos, durante a etapa de simulação além de indicar o
progresso da etapa de verificação.
46
2.7 CONSIDERAÇÕES
O Capítulo 2 abordou aspectos das definições e classificações das redes automotivas, tais
como, a topologia e a classificação SAE, respectivamente. Também foram analisados aspectos
relacionados aos padrões de comunicação automotivos, como o protocolo CAN, FlexRAY, MOST
e LIN. Sobre este último, foram detalhados aspectos como o estabelecimento do padrão, a
padronização e a adoção do protocolo na indústria. Ainda sobre o Capítulo 2, foram abordados
aspectos relacionados às técnicas de projetos de circuito integrado, como as métricas de projeto que
servem para medir as características, a qualidade e a evolução dos sistemas desenvolvidos. Também
foram abordados aspectos relacionados às tecnologias de circuitos integrados, tais como as três
principais tecnologias de otimização de CIs, full-custom, semi-custom e lógica programável. Ainda
foram abordados aspectos relacionados a metodologia de projeto ipPROCESS, utilizada para o
desenvolvimento de Soft IP-cores. O último aspecto abordado tratou muitos aspectos da verificação
em módulos de IPs, em particular da verificação funcional e formal de módulos de IPs.
No contexto da presente dissertação, a análise dos padrões de redes automotivas, das
métricas de projeto e dos mecanismos de verificação funcional possibilitou um entendimento das
características adotadas no desenvolvimento do protocolo LIN proposto, tal como a complexidade
de uma rede automotiva, consumo de energia, desempenho, dispositivos de lógica programável
empregados e tecnologia de CI utilizados possivelmente em uma rede automotiva.
O capítulo a seguir (Capítulo 3), abordará os trabalhos relacionados a esta pesquisa,
identificando estudos correlatos, visando identificar os métodos e as métricas adotadas para
implementação e avaliação de implementações em hardware e em software.
47
3 TRABALHOS CORRELATOS
Neste trabalho foi realizada uma pesquisa bibliográfica preliminar baseada nos
procedimentos de revisão sistemática (ANEXO A) e não foram identificados trabalhos similares ao
proposto nesta dissertação, ou seja, trabalhos que tivessem como objetivo a comparação das
implementações em software e em hardware do protocolo LIN. A pesquisa foi então ampliada para
identificar trabalhos que tivessem realizado estudos similares para outras aplicações visando
identificar os métodos e as métricas adotadas para implementação e avaliação, bem como
caracterizar os resultados obtidos. Além deste estudo, fez-se uma pesquisa a respeito de soluções já
existentes de implementação em hardware do protocolo LIN, sumarizadas ao final do capítulo.
3.1 COMPARAÇÃO DO DESEMPENHO DE IMPLEMENTAÇÕES DO
ALGORITMO AES
Mali et al. (2005) comparam duas abordagens de implementações, software e hardware, do
algoritmo de criptografia AES para unidades de memórias externa (no caso, quatro blocos de
SRAM) utilizado em aplicações com alto requisito de segurança.
A implementação em software foi executada em um computador baseado no processador
AMD Athlon de 1.3 GHz. Já o algoritmo em hardware foi implementado seguindo duas
abordagens: sequencial e paralela. Essas implementações foram sintetizadas em FPGA utilizando a
placa Celoxica RC1000 com interface PCI. Essa placa possui um FPGA Xilinx da família Virtex
BG560, além de 8 Mb de SRAM conectados diretamente ao FPGA, sendo que esses bancos, por sua
vez, estão conectados em um barramento de 32 bits (4 bancos 512 Kb = 8Mb). Isso garante que
cada um dos bancos de memória pode ser concedido (granted) tanto à CPU quanto ao FPGA
simultaneamente.
A comparação das implementações do algoritmo foi focada no desempenho e as métricas
utilizadas para a avaliação foram (i) o tempo médio de execução de tarefas do algoritmo e (ii) a
vazão obtida (não tendo sido feita nenhuma avaliação quanto aos custos de silício de
implementação nas duas abordagens). As principais tarefas do algoritmo incluem a cifragem
(criptografia), a cifragem inversa e a chave de expansão, sendo que as duas cifragens foram
implementadas utilizando duas abordagens em hardware, sequencial e paralela. Assim, os
48
resultados obtidos pelos autores (decodificação/codificação de um bloco de 128bit de dados) para as
duas abordagens do bloco de cifragem do algoritmo AES estão sumarizados na Tabela 1.
Tabela 1. Comparação dos resultados das implementações do bloco de cifragem do algoritmo AES
Onde: TME: Tempo Médio de Execução (μs)
THP: Vazão (Mbit/s)
Atributos
Implementação
Software(SW) Hardware Sequencial
(Hseq)
Hardware Paralelo
(Hpar) Hseq/
Hpar
TME THP TME THP TME (SW/ Hseq) TME THP TME
(SW/ Hpar) TME
Cifragem 16,50 7,76 22,91 5,59 0,72 0,7 182,86 23,57 34,75
Cifragem
Inversa 20,56 6,23 22,91 5,59 0,89 0,7 182,86 29,37 37
Analisando a Tabela 1, é possível observar que a cifragem Hpar é 34,75 vezes mais rápida
quando comparada com uma implementação sequencial. Já comparando a cifragem Hpar com a
implementação em software é possível observar que ela é 23 vezes mais rápida que SW, bem como
a cifragem inversa Hpar é 29 vezes mais rápida que a cifragem inversa em SW.
Os resultados evidenciam que a abordagem utilizando Hpar para a implementação do
algoritmo de cifragem AES é mais rápida e, portanto, a melhor solução adotada quando comparada
com as soluções SW e Hseq.
3.2 COMPARAÇÃO DE METODOLOGIAS DE TESTBENCH PARA
VERIFICAÇÃO FUNCIONAL HIERÁRQUICA
Tobar (2005) compara duas técnicas aplicadas na verificação funcional do IP adaptador de
banda base Bluetooth (Figura 7). A primeira técnica é baseada em um framework tradicional, com
estímulos randômicos e analisando aspectos de cobertura funcional. A segunda técnica utiliza
funções de aceleração baseada em filtragem dos estímulos redundantes, reduzindo o tempo de
execução do testbench com estímulos randômicos.
49
SRAM ACESSCTR PACKETBUFFER
PACKETPROC
CRC FEC CIPHER
FHEC WHITE
BASEHW
RADIOCTR
Figura 7. IP adaptador banda base bluetooth
Fonte: Tobar (2005)
De acordo com Tobar (2005), na primeira técnica os resultados oriundos do DUV são
comparados com os resultados de um modelo de referência descrito em um nível de abstração maior
(Figura 6). Ainda segundo Tobar (2005), esse modelo tradicional torna a verificação baseada em
simulação mais fácil de ser gerenciada (incremento e manutenção de código); contudo, consiste na
fase que mais consome recursos e tempo de projeto segundo os desenvolvedores.
Nesse contexto, Tobar (2005) propõe uma técnica em looping fechado de filtragem dos
estímulos gerados, cuja premissa é baseada na observação de que a simulação do modelo de
referência é mais rápida que o RTL. Primeiramente, a simulação no modelo de referência é
executada, os resultados são analisados (Checker) e, por fim, são verificados os parâmetros de
cobertura de cada caso de teste injetado. Se não ocorrer redundância de testcase, o DUV é
simulado. Assim, a simulação do RTL é evitada caso o estímulo tenha sido previamente gerado pela
fonte (Stimuli Source).
No modelo proposto (Figura 8) por Tobar (2005), as saídas dos estímulos aplicados no
modelo de referência são analisadas após o módulo Checker pelo comparador. Depois disso,
informações relacionadas ao testcases são enviadas ao filtro, o qual é responsável por interromper
ou não a simulação no RTL.
50
Figura 8. Modelo de testbench baseado na filtragem de estímulos redundantes
Fonte: Tobar (2005)
Tobar (2005) utilizou um processador Pentium IV HT com 1 GB de DRAM de memória, na
qual foram comparados dois modelos de verificação, um em loop fechado e o outro básico (loop
aberto), nos quais foram injetados 10.000 itens e cuja cobertura atingiu 100%. Foram comparados
resultados como tempo de execução consumido pelo testbench para atingir 100% de cobertura de
cada um dos dois modelos propostos. Alguns casos ilustram ganhos (razão entre os tempos para
100% de cobertura de cada um dos dois modelos) próximos de 50-60%, outros de 25% e alguns
abaixo de 10%.
3.3 VERIFICAÇÃO FUNCIONAL DE HW ATRAVÉS DE CO-SIMULAÇÃO
DE HW/SW EM SISTEMAS COMPLEXOS
Deprá et al. (2009) apresentam um método de verificação funcional utilizando duas
abordagens de codificação: uma abordagem descrita em software e a outra em hardware. O método
proposto utiliza uma API para prover mecanismo de handshake (garantia de sincronismo entre os
dois módulos) e o paralelismo da co-simulação. Segundo Bergeron (2003 apud Deprá et al., 2009),
50% do tempo de projeto é gasto nessa fase de verificação20
, o que força a indústria e a academia a
encontrar métodos que possam reduzir os custos desta etapa sem que o processo de cobertura fique
20
É comum encontrar publicações que citam em 70% o tempo gasto na fase de verificação, contudo o autor deste
trabalho acredita que este valor pode variar entre 50% e 80% conforme a maturidade do grupo de desenvolvimento.
Essa afirmação baseia-se no contexto do presente projeto, cujas modificações feitas na ferramenta de verificação
desenvolvida para testar o núcleo LIN ao final do projeto, foram executadas sem maiores percalços (menor tempo)
quando comparado ao início da codificação da ferramenta (maior tempo).
DUV
Gerador de Estímulos
Filtro
Driver
Modelo de Referência
Monitor
Comparador
51
prejudicado. Outro aspecto considerado é o custo de detecção e correção de erros de projetos, o qual
possui um crescimento exponencial com a redução do nível de abstração.
Assim, o método de co-simulação proposto por Deprá et al. (2009) facilita o processo de
obtenção, armazenamento e injeção de dados (impraticável utilizando uma descrição HDL). São
utilizadas diretivas da linguagem PLI, possibilitando a simulação em software e em hardware em
paralelo garantindo o sincronismo da comunicação entre os módulos (através de um protocolo de
handshake) e o paralelismo da simulação com a utilização de threads.
Bergeron (2003 apud Deprá et al., 2009) definem verificação funcional como: “[...] um
processo usado para demonstrar que o objetivo do projeto é preservado na sua implementação”.
Neste sentido, duas são as abordagens que podem ser utilizadas para verificar se a descrição HDL é
equivalente com o que foi especificado no projeto: (i) verificação formal; e (ii) simulação baseada
em verificação.
Deprá et al. (2009) afirmam que os métodos convencionais de verificação funcional
consistem em uma sequência de estímulos aplicados ao hardware, cujos resultados são comparados
ao fim da simulação com um modelo de referência (descrito em uma linguagem mais abstrata).
Entretanto, para Deprá et al. (2009), em sistemas complexos, o processo para obtenção dos
estímulos de entrada e de saída não são triviais e faz-se necessário identificar os casos de teste,
injetar e gravar os estímulos no DUV através de um testbench, executar propriamente o testbench e
comparar os resultados entre os dois modelos adotados. Ainda, segundo Deprá et al. (2009), alguns
modelos de testbench necessitam executar leituras e escritas em arquivos externos (estímulos e
resultados), o que, consequentemente, tornam os testbenches maiores e mais complexos que o
próprio projeto do hardware.
Com o uso de APIs específicas para o controle de simulação, Deprá et al. (2009) propõem
um modelo para diminuir a complexidade dos testbenches, como por exemplo o uso de PLI para
verificação funcional dos DUVs descritos em Verilog. Contudo, as simulações utilizando PLI
possuem limitações: quando cada rotina de software é executada o simulador suspende a execução
em hardware e enquanto a rotina em software é executada sequencialmente. Nesse sentido, Deprá et
al. (2009) propõem uma alternativa para contornar essa limitação, utilizando rotinas com threads e
um mecanismo de handshake entre o software e o hardware, além de combinar rotinas de
requisição, espera e de leitura dos dados.
52
Segundo Deprá et al. (2009), inicialmente, são descritos três módulos: (i) binding; (ii)
wake_up; e (iii) hw_asic. O primeiro módulo possibilita a conexão dinâmica entre o software e o
simulador, ou seja, o módulo serve como uma ponte entre a implementação em software e o
hardware, através do mapeamento das portas de entrada e de saída do módulo hw_asic para os
ponteiros acessíveis dentro dos módulos de software. O módulo wake_up tem por objetivo fornecer
um sinal periódico para o bloco hw_asic, para que o mesmo execute periodicamente o protocolo de
handshake.
Deprá et al. (2009) utilizaram para estudo de caso e validação do método o software
JM10.2, o qual implementa funcionalidades do padrão H264/AVC. Além disso, o método foi
aplicado no hardware (DUV) em um bloco de interpolação de luminância (componente
compensação de movimento do padrão H264/AVC) desenvolvido de acordo com o padrão
H264/AVC. O estudo de caso apresentado por Deprá et al. (2009) possibilitou que a ferramenta de
co-simulação desenvolvida verificasse as funcionalidades do hardware utilizando estímulos de
vídeos. Por fim, o método apresentado utilizando a linguagem PLI, combinada com a utilização de
threads e do protocolo de handshake, possibilitou a co-simulação paralela dos dois módulos de
software e de hardware.
3.4 SISTEMA DE CAIXA-PRETA PARA VEÍCULOS INTELIGENTES COM
COMUNICAÇÃO INTRAVEICULAR LIN/FLEXRAY
Para Khanapurkarl et al. (2008), diversas são as arquiteturas existentes que podem ser
utilizadas para a comunicação intraveicular e interveicular, tais como o CAN, LIN, MOST e
FlexRay. A maturidade dessas arquiteturas deu-se principalmente nas últimas duas décadas,
especialmente com o amplo uso de padrões baseados em UARTs (transmissão serial) ou, como
citam Khanapurkarl et al. (2008), protocolos baseados em UART (UBPs – UART Base Protocols).
Nesse sentido, o protocolo LIN destaca-se no controle de nós em aplicações automotivas
distribuídas.
Dessa forma, Kopetz et al. (2007 apud KHANAPURKARL et al.,2008) enfatizam que um
carro típico possui mais de 15 ECUs e aproximadamente 5 tipos de redes. Ainda assim, afirmam
que é possível reduzir a quantidade de ECUs trocando processadores simples por
multiprocessadores, ou seja, um multi-core SoC (System on Chips). A Figura 9 ilustra uma
53
referência de um SoC para aplicações automotivas, utilizando uma NOC (Network-on-Chip) e um
barramento de comunicação (TTNC – Time Triggered Network-on-Chip).
Figura 9. Exemplo de SoC para sistemas automotivos
Fonte: Adaptado de Kopetz et al. (2007 apud KHANAPURKARL et al. 2008)
A Figura 10 ilustra um esquema simplificado de um IP do protocolo LIN. Este IP opera até
20 kbps, mono-mestre/multi-escravos e auto-sincronização.
Clk
Cs_n
Ad
Di
Do
Int
Host
Controller
interface
Register
Block
Control
FSM
Data
Buffer
Bit
Timing
Logic
Bit
Stream
Processor
Rs_n
We_n
RxD
TxD
Figura 10. Módulo LIN
Fonte: Adaptado de Kopetz et al. (2007 apud KHANAPURKARL et al. 2008)
Um aspecto importante ilustrado na Figura 10 consiste na arquitetura utilizada para o
desenvolvimento do referido IP. É possível observar que o referido IP possui 6 módulos distintos
interligados por dois barramentos. O módulo mais à esquerda, Interface de Controle Host (Host
54
Controller Inferface), é responsável por interagir o IP com a aplicação. Já os módulos centrais
Blocos de Registradores (Register Block), Controle da Máquina de Estados (Control FSM) e Buffer
de dados (Data Buffer) são responsáveis, respectivamente por gerenciamento dos registradores,
controle da máquina de estados e acúmulo dos dados.
3.5 IMPLEMENTAÇÕES EM HARDWARE DO PROTOCOLO LIN
Alguns IPs sintetizáveis comerciais que implementam o protocolo LIN são listados no
Quadro 1. Destacam-se modelos comerciais disponibilizados pela CAST, pela Intelliga e pela
Bosch, além de um núcleo do protocolo LIN desenvolvido na graduação pelo autor.
O Quadro 1 identifica algumas características de núcleos comerciais, como o nome e o tipo,
a linguagem de descrição de hardware (HDL – Hardware Description Language) utilizada, a
tecnologia alvo para implementação, a revisão da especificação LIN com a qual o núcleo é
compatível, a configurabilidade da taxa de dados, a capacidade de armazenamento (buffering), a
funcionalidade suportada (mestre e/ou escravo) e o custo de silício.
Ainda no Quadro 1, é possível observar que os núcleos comerciais são do tipo Soft IP-core e
visam as tecnologias FPGA e ASIC.
55
Quadro 1. Análise comparativa das características de núcleos de propriedade intelectual LIN
Atributo Desenvolvedor
CAST Intelliga BOSCH UNIVALI
Nome LIN Core iLIN C LIN LIN IP
Tipo de Núcleo Soft IP-core Soft IP-core Soft IP-core Soft IP-core
HDL VHDL
Verilog
VHDL
Verilog VHDL VHDL
Tecnologia Alvo FPGA
ASIC
FPGA
ASIC
FPGA
ASIC FPGA
Especificação Revisão 2.0 Revisão 1.3 Revisão 1.3, 2.0
e 2.1 Revisão 2.1
Configuração da
taxa de dados
Programável ou
automática Automática Fixa Fixa
Buffer de dados Um buffer de 8
bytes
Informação não
disponível
Buffers TX e
RX de 8 e 7
bytes
Buffers TX e RX
configuráveis
Funcionalidade Mestre ou
escravo
Mestre ou
escravo
Mestre ou
escravo Escravo
Custo de silício 2710 a 3760
gates 3000 gates
3100 a 3900
gates
598 células
lógicas
Referência CAST (2007) Intelliga (2003) BOSCH (2007) Pereira (2008)
O LIN IP (PEREIRA, 2008) consiste no trabalho de final do curso de graduação do presente
autor. Nesse trabalho de graduação, foi desenvolvido o núcleo do protocolo LIN utilizando a
linguagem VHDL. Esse núcleo foi sintetizado para FPGA da família Cyclone II da Altera e
verificado apenas por simulação funcional. Portanto, o trabalho limitou-se a um estudo exploratório
do protocolo, o qual, porém, permitiu constituir a base teórica para a submissão de um projeto ao
Programa Brazil IP do CNPq. Destaca-se que, diferentemente dos outros IPs, esse núcleo opera
apenas como escravo e não foi mapeado para ASIC. Por isso, o seu custo de silício é identificado
em células lógicas (LCs – Logic Cells) de FPGA. As características do LIN IP (mostradas no
Quadro 1) foram assim delimitadas de modo a viabilizar o seu desenvolvimento no curso de
graduação em Engenharia de Computação dentro do contexto do trabalho de conclusão de curso do
presente autor.
56
3.6 ANÁLISE COMPARATIVA
Nesta seção, são apresentadas as análises comparativas dos trabalhos selecionados (Quadro
2) visando resumir e identificar os métodos e as métricas adotadas em cada uma das
implementações, em software e em hardware.
No Quadro 2, a principal característica observada é que alguns trabalhos não analisaram
aspectos relacionados a uma tecnologia alvo, ou seja, não foram consideradas restrições finais de
tempo (timing), consumo de energia (power) e área de silício. Já o trabalho descrito por Tobar
(2005) ilustra o uso de um modelo híbrido de verificação funcional, cuja cobertura atinge 100%.
Esse modelo se assemelha com o modelo proposto na presente dissertação (Subseção 4.2.2 ). Ainda,
no Quadro 2, são abordados aspectos da implementação em software sequencial e paralelo de
alguns sistemas. Nesse sentido, o trabalho descrito por Deprá et al. (2009) analisa o uso de threads
e de diretivas da linguagem PLI para simulação do software e do hardware em paralelo. Essa
abordagem serve como parâmetro inicial para a implementação em software proposta pela
dissertação do protocolo LIN, ou seja, o uso de threads deve permitir a identificação do início de
um novo cabeçalho LIN (break_field) ao mesmo tempo em que os dados LIN são montados.
57
Quadro 2. Análise comparativa dos trabalhos relacionados.
Características Comparação do
Desempenho de
Implementações
do Algoritmo AES
Comparação de
Metodologias
de Testbench
para
Verificação
Funcional
Hierarquica
Verificação
Funcional de Hw
Através de Co-
Simulação de
HW/SW em
Sistemas
Complexos
Sistema de
Caixa-Preta
para Veículos
Inteligentes com
Comunicação
Intraveicular
LIN/Flexray
Implementações
em Hardware do
Protocolo LIN
Análise de
Métricas da
Implementação
do Protocolo LIN
em Hardware e
em Software
Métodos SW/HW HW SW/HW HW HW SW/HW
Vantagens Implementação em
HW
sequencial/paralela
100% de
cobertura
atingida
Implementação em
SW e em HW
paralela
Analisa uma
arquitetura LIN
Analisa diversas
arquiteturas LIN
Sintetizado para
FPGA e ASIC
Desvantagens Implementação em
SW sequencial
Testbench
Híbrido
Paralelismo
necessita de
diretivas da
linguagem PLI
combinadas com
threads
Utiliza Buffer
para acumulo de
dados
O LIN IP possui
custo de silício
identificado em
células lógicas e
atua somente como
escravo
Atua somente
como escravo na
rede
Limitações Portado somente
para Virtex BG560
Não analisa
características
em função de
uma tecnologia
CI alvo
Não analisa
características em
função de uma
tecnologia CI alvo
Não analisa
características
em função de
uma tecnologia
CI alvo
Algumas
arquiteturas são
proprietárias
Portado para
Altera DE2 e
DE0.
Referência Mali et al. (2005) Tobar (2005) Deprá et al. (2009) Khanapurkarl et
al. (2008)
Pereira (2008) Presente pesquisa
58
Por fim, as arquiteturas propostas por Khanapurkarl et al. (2008) e a arquitetura executada
em Pereira (2008) serviram como estudo de caso do protocolo LIN e como referência para a
implementação em hardware desta dissertação.
3.7 CONSIDERAÇÕES
Neste capítulo, foi realizada uma pesquisa bibliográfica onde foram analisados trabalhos
similares ao proposto nesta dissertação. O intuito deste levantamento bibliográfico foi analisar as
abordagens de implementações em software e/ou em hardware desses trabalhos. Os resultados desta
análise, como os métodos e as métricas utilizados, foram listados no Quadro 2.
A seguir, no Capítulo 4, são abordados detalhes do desenvolvimento do protocolo LIN à luz
da metodologia ipPROCESS, tais como a visão geral do projeto e as especificações da arquitetura
LIN no contexto da dissertação, e por fim são tecidas as considerações sobre o capítulo.
59
4 PROJETO BASEADO NA METODOLOGIA IPPROCESS
Este capítulo é dividido em três seções. Na primeira seção, é apresentada a especificação do
protocolo LIN, bem como os atores, o diagrama de caso de uso do projeto arquitetural e a descrição
de todos os módulos lógicos do sistema. Na segunda e terceira seções, são detalhados aspectos
relacionados ao desenvolvimento do hardware e software, respectivamente.
4.1 ESPECIFICAÇÃO DOS SISTEMAS
Os atores do sistema (Figura 11) e o diagrama de casos de uso (Figura 12), apresentados a
seguir, representam a implementação das funcionalidades do LIN HW e do LIN SW, bem como das
camadas de enlace de dados, rede e de aplicação. O protocolo também é descrito analisando a visão
lógica dos IPs, mostrando por meio de um diagrama de módulo (Figura 13) as classes organizadas
em subsistemas.
4.1.1 Atores do Sistema
A Figura 11 ilustra os principais atores do sistema, os quais incluem:
Mestre (Master): responsável pelo envio de todas as requisições (Seção 2.3) do
barramento LIN;
Escravos (Slaves): contém processos exclusivos dos nós escravos. O LIN SW e o LIN
HW são uma abstração de um escravo LIN; e
Aplicação (Application): interface que permite que a CPU comunique com o barramento
LIN.
Aplicação Host
Sistema Barramento LIN
Mestre
Escravos
Figura 11. Atores do sistema
60
4.1.2 Projeto Arquitetural
A Figura 12 apresenta o diagrama geral de casos de uso geral da abordagem em software e
da abordagem em hardware. Esses casos de uso são descritos após a figura, identificando-se as
ações realizadas em cada caso de uso.
Casos de Uso
Aplicação
Sensores/ Atuadores
Configuração e Identificação
Registradores
Handler
Rede/Transporte
Diagnóstico Gerenciamento da rede
Enlace
Controle PHY
TX Gerenciador
Tempo de BIT
RX
Barramento LIN
Figura 12. Diagrama geral de casos de uso das abordagens em software e em hardware
Camada de Enlace de Dados
Esta camada é responsável pela correta montagem dos sinais seriais do barramento LIN e
pelo controle da interface física (PHY), e inclui os seguintes módulos:
Receptor Serial (RX): responsável por detectar o cabeçalho do protocolo LIN
(break_field/Synch_field/PID), compreender o tipo de mensagem e agir de acordo com o
61
PID21
(Protected Identifier). Conforme o PID realiza a recepção de 2, 4 ou 8 bytes de
dados seguido de um byte de soma e verificação do barramento ou o aguardar a chegada
de um novo cabeçalho LIN;
Transmissor Serial (TX): responsável por transmitir ao barramento 2, 4 ou 8 bytes de
dados, seguido de um byte de soma e verificação;
Controle PHY: responsável pelo gerenciamento dos canais de transmissão e recepção de
dados e pelo controle do Modo Normal, Low Power Mode, Wake-Up e modo de espera
do PHY; e
Gerador de tempo de bit: responsável por gerar corretamente os sinais de tempo de bit.
Camada de Transporte
Esta camada é responsável pela geração de cabeçalhos corretos, por decidir qual quadro
deve ser enviado e pela manutenção do timing correto entre os quadros, tudo de acordo com a tabela
de escalonamento, e inclui os seguintes módulos:
Diagnóstico: responsável por gerenciar os erros do cabeçalho e dos bytes de soma e
verificação; e
Gerenciamento de Rede: responsável pelo controle do tipo de mensagem, ou (i)
transmissão ou (ii) recepção dos dados. No caso da implementação em hardware é
utilizado o protocolo de comunicação AMBA AXI 22
.
Camada de Aplicação
Esta camada é responsável pelo controle dos dados, das mensagens de erros e handshake, e
inclui os seguintes módulos:
21
Para o presente projeto foi estabelecido que os bits 5 e 4 do byte identificador devem representar os seguintes
tamanhos de pacotes de dados: 00 e 01 – 2 bytes de dados, 10 – 4 bytes de dados e 11 – 8 bytes de dados. O presente
padrão foi adotado analisando algumas aplicações sugeridas pela indústria, como o AN2633 da Freescale
Semicondutores; 22
A escolha do padrão AMBA AXI foi estabelecido pelo programa Brazil IP.
62
Registradores de Comunicação: fornece registros de controle e registrador de status e
erros para o controle da transferência das mensagens LIN, além de permitir o acesso aos
registros através de uma interface controladora (host);
Manipulador de Comunicação (handler): proporciona a troca de mensagem entre o
núcleo LIN IP e o controlador host usando um protocolo de comunicação AMBA AXI
(no caso da implementação em hardware); e
Configuração e Identificação: responsável pela correta identificação e configuração do
PID.
A Figura 13 apresenta a visão lógica em camadas dos módulos do sistema (descritos
anteriormente) e dos barramentos de controle, comunicação e dados. O barramento de controle
contém as classes responsáveis pelas atividades necessárias para o controle de todas as ações
realizadas pelo core, como transmissão, recepção, escrita/leitura lógica e controle dos dados. O
barramento de comunicação contém as classes responsáveis pelas atividades que permitem a
comunicação entre o core e a aplicação host, bem como entre os módulos. O protocolo usado para
comunicação com dispositivos externos, bem como a comunicação entre os módulos é o AMBA
AXI. Já o barramento de dados é composto por classes responsáveis pelo gerenciamento e
armazenamento dos dados utilizados nos processos do core.
Figura 13. Diagrama lógico preliminar do sistema
63
4.1.3 Descrição da Arquitetura
Nesta seção, são descritas as características funcionais dos módulos de casos de uso
incluídos em cada uma das camadas da Figura 13.
Receptor Serial (RX)
O módulo Receptor Serial (RX) tem por objetivo receber serialmente um pacote de
mensagens do barramento LIN, transformá-lo em dados e por fim gerar sinais de controle para a
operação do sistema. Assim, com o barramento inicialmente em nível lógico 1 (um), é dado o início
da transmissão das mensagens LIN com a detecção da mudança de nível do barramento (borda de
descida para nível lógico zero), cujo limite de 11 a 13 bits em nível lógico 0 (zero) identifica o
break-field. Após a detecção do break-field, dá-se o início a detecção do campo de sincronismo
(valor hexadecimal 0x55), seguido do PID. A qualquer momento, caso ocorra um novo break-field,
a identificação do campo de sincronismo ou mesmo os subsequentes campos devem ser anulados e
o processamento do novo quadro terá início.
Com o PID montado, é possível extrair informações como tamanho dos pacotes, paridade do
identificar e tipo de mensagem (escrita ou leitura de dados no barramento). Caso seja identificado
um comando de leitura de dados no PID, o bloco RX permanece montando os bytes de dados
subsequentes a partir dos bits recebidos até o limite do tamanho do pacote definido dentro do PID.
Por fim, o bloco recebe e monta o byte de soma e verificação para análise da integridade do dado
recebido.
Se for verificada uma mensagem de escrita de dados, cabe ao bloco RX sinalizar aos demais
blocos a transmissão de dados da aplicação para o barramento LIN.
Transmissor Serial (TX)
O módulo de Transmissão Serial (TX) tem objetivo único de transmitir serialmente os dados
da camada de aplicação para o barramento LIN. O tamanho do pacote de dados, conforme o PID
pode variar entre 2, 4 ou 8 bytes de dados, seguido de um byte de soma e verificação.
Módulo de controle PHY
64
O módulo de Controle do PHY tem por objetivo fornecer o controle dos PHYs nos modos
de transmissão e recepção do barramento LIN, tendo em vista as interfaces físicas (PHY) TPIC1020
da Texas Instruments e MCP201 da Microchip. No modo de recepção, o chip select (CS/WAKE) é
colocado em nível lógico 1 (um), permitindo ao PHY continuar recebendo dados pelo pino de
recepção serial e desabilitando o canal de transmissão serial. Já no modo de transmissão, ocorre o
inverso. O CS/WAKE é colocado em nível lógico 0 (zero), desabilitando o canal de recepção e
habilitando o canal de transmissão serial. No presente projeto, não foram previstos os modos Low
Power, Wake-Up e Idle especificados pelo protocolo LIN 2006 e nas folhas de dados dos PHYs.
Módulo de Gerenciamento da Rede
O módulo gerenciamento da rede é responsável pelo controle do tipo de mensagem de
transmissão ou de recepção de dados com a aplicação. O protocolo de comunicação utilizado entre
o módulo e a aplicação é o AMBA AXI.
Cabe ao núcleo LIN a transmissão do quadro de resposta quando ele é o editor23
(mensagem
de escrita no barramento) e a recepção do frame de resposta quando ele é um assinante (mensagem
de leitura no barramento). Isso ocorre tão logo são recebidos um break-field, um campo de
sincronismo e um PID, quando o bloco de configuração e identificação recebe o PID corretamente e
identifica o tipo de mensagem.
Módulo de Identificação e Configuração
O módulo de configuração e identificação define qual o comportamento (escrita ou leitura
de dados no barramento) do PID recebido. Nesse contexto, o bloco deve então identificar o tipo de
mensagem recebida (transmissão de dados ou recepção de dados) e informar às camadas inferiores
o tipo de mensagem. Já a etapa de configuração ocorre quando, estabelecida uma aplicação alvo24
,
são definidas as tabelas de PIDs pertencentes ao nó, bem como o tipo de mensagem pertencente a
cada PID (transmissão de dados ou recepção de dados).
23
Tradução para o termo originalmente utilizado no documento de especificação do LIN: “Publisher” 24
Aplicações como acionamento de sensores e atuadores de portas, luzes de sinalização traseira, sensores de baixa
velocidade do grupo motor de um automóvel ou mesmo em aplicações de automação residencial utilizando PLC como
proposto pela Yamar (www.yamar.com);
65
Gerador de tempo de bit
O bloco gerador de tempo de bit é responsável por gerar bits de amostragem a cada 1 (um)
tempo de bit e ½ (meio) tempo de bit para os blocos de transmissão serial (TX) e para o bloco de
recepção serial (RX), respectivamente.
4.1.4 Diagrama de Sequência
A Figura 14 representa o diagrama de sequência dos principais eventos que ocorrem em um
barramento LIN25
e ilustra três sequências de envio de mensagens previstas na especificação do LIN
HW e do LIN SW. A primeira sequência (a) corresponde ao envio de uma requisição (request) do
nó mestre seguido de uma resposta (response) de dados para todos os nós do barramento LIN. Na
sequência (b), o mestre envia uma requisição e aguarda uma resposta de dados de um nó escravo
específico. Por fim, em (c), o mestre envia uma requisição, enquanto o escravo N responde com
dados para o escravo 1.
25
O projeto limitou o escopo do protocolo LIN, não prevendo modos de envio em rajada, reconfiguração de PIDs e
NAD e diagnóstico classe II e III no desenvolvimento do LIN HW e do LIN SW.
Diagrama de Estado
Response(data,checksum)
(c) Request(id)
(b)
Response(data,checksum)
Request(id)
Response(data,checksum)
Request(id)
Mestre Escravo 1 Escravo N
(a)
Figura 14. Diagrama de sequência de um barramento LIN
66
As seções a seguir apresentam aspectos relativos à implementação do escravo LIN
utilizando as duas abordagens alvo deste trabalho: baseada em hardware (denominada LIN HW) e
baseada em software (LIN SW).
4.2 ABORDAGEM BASEADA EM HARDWARE – LIN HW
A presente seção analisa o esforço de desenvolvimento do IP denominado LIN HW. A seção
é dividida em cinco subseções. Na primeira subseção, é apresentada a implementação do DUV e a
divisão dos blocos lógicos do LIN HW. Na segunda subseção, é detalhado o plano de testes
utilizado para o planejamento e controle do esforço de verificação. A terceira subseção analisa a
implementação do modelo de testbench utilizado na verificação do LIN HW. A quarta subseção
descreve detalhes da verificação funcional, tais como o escalonamento das mensagens, os estímulos
e a cobertura alcançada. Na quinta subseção, são analisados os resultados do esforço de verificação
do DUV.
4.2.1 Implementação do IP LIN HW (DUV)
A Figura 15 ilustra a descrição do topo da entidade LIN HW, sendo que a Figura 16 divide a
mesma entidade em sub-blocos, nos quais cada um é verificado individualmente de acordo com a
metodologia BVM e conforme descrito na Subseção 4.2.2 .
LIN HW
i_reset
i_clk
o_tx
i_rx
o_lin2axi[7:0] o_lin2axi_id[7:0] o_lin2axi_last o_lin2axi_valid i_lin2axi_read
o_cs o_int_error o_error[3:0]
i_axi2lin_data[7:0] i_axi2lin_last i_axi2lin_valid o_axi2lin_ready
Figura 15. Descrição de topo do LIN HW
67
i_axi_valid i_clk i_int_axi_error i_lin2axi_ready i_reset i_axi_pid[7:0] i_axi_data[63:0] i_axi_error[3:0]
o_axi_ready o_int_error o_lin2axi_last o_lin2axi_valid o_lin2axi_data[7:0] o_lin2axi_id[7:0] o_error[3:0]
lin2axi
i_clk i_config_enable i_reset i_scl i_sda i_top_rst
o_top
o_top_delayed
genetop
i_clk i_request_ready i_reset i_rx i_top_delayed
o_request_valid o_top_rst o_request_data[63:0] o_request_id[7:0] o_request_crc[7:0] o_request_error[3:0]
rx
i_axi_ready i_clk i_id_ready i_request_valid i_reset i_request_error[3:0] i_request_id[7:0] i_request_data[63:0] i_request_crc[7:0] i_checksum[7:0]
o_axi_valid o_id_valid
o_int_axi_error o_request_ready
o_id[7:0] o_axi_pid[7:0]
o_axi_data[63:0] o_axi_error[3:0]
mux
i_axi2resp_valid i_clk i_reset i_top i_axi2resp_id[7:0] i_axi2resp_data[63:0] i_axi2resp_crc[7;0]
o_axi2resp_ready o_top_rst o_tx
tx
i_axi2lin_last i_axi_valid i_axi2resp_ready i_clk i_id_valid i_reset i_id[7:0] i_axi2lin_data[7:0]
o_axi2lin_ready o_axi2resp_valid o_id_ready o_axi2resp_data[63:0] o_axi2resp_id[7:0]
axi2lin
i_axi2lin_valid i_clk i_out_ready i_reset i_rx_valid i_rx_cks_data[63:0] i_axi_cks_data[63:0] i_axi_lengthframe[1:0] i_rx_lengthframe[1:0]
o_in_ready o_mux_valid
o_tx_valid o_checksum[7:0]
checksum
The blocks’ interconnections are
not detailed
Figura 16. Descrição do LIN HW em blocos lógicos interconectados com o barramento AMBA AXI
68
4.2.2 Implementação do Testbench
Conforme mencionado na Subseção 2.6.2 o testbench tem o intuito de verificar se as
funcionalidades previstas pela especificação de projeto foram contempladas na implementação do
IP. Nesse sentido, o modelo de testbench proposto (Figura 17) a seguir constitui uma abordagem
híbrida do modelo BVM (Subseção 2.6.2 ).
REFMOD_LIN
S O U R C E
Driver
Driver
C H E C K E R Monitor
Monitor
REFMOD2_LIN
Actor
12
1
1
25
Figura 17. Estrutura BVM do testbench do LIN Bus core
Por meio desta estrutura, é possível garantir que REFMOD2_LIN (DUV) cumpra todos os
requisitos especificados na Seção 4.1.
A seguir são descritos cada um dos componentes da estrutura do testbench:
SOURCE26
: envia as transações para as entradas do modelo de referência do Driver;
REFMOD_LIN: implementa as mesmas funcionalidades do REFMOD2_LIN, mas
tipicamente em um nível mais alto de abstração. O modelo de referência deve ser correto
e é tipicamente atemporal;
Driver: recebe operações do Source e convertê-los em sinais de acordo com a interface
do REFMOD2_LIN;
Monitor: recebe os sinais do REFMOD2_LIN e converte em transações;
26
Para esta pesquisa foram mantidos os termos dos componentes em inglês, por tratarem-se de termos já consolidados
na área de Verificação;
69
Actor: implementa o protocolo de comunicação (handshake); e
CHECKER: compara se as saídas REFMOD2_LIN são iguais às saídas do Modelo de
Referência. Se não, ele relata uma mensagem de erro.
A Figura 18 ilustra a Etapa 1.1, cujo objetivo é testar a capacidade do modelo de referência
interagir com o testbench.
REFMOD_LIN S I N K
P R E S O U R C E
Figura 18. Modelo de referência simples
O PRE_SOURCE é um subconjunto do SOURCE e implementa quase todas as
funcionalidades do SOURCE. O mesmo ocorre entre SINK e o CHECKER.
Os objetivos da Etapa 1.2 (Figura 19) são: (i) verificar a capacidade do PRE_SOURCE para
criar estímulos para ambos os modelos de referência; e (ii) verificar a capacidade do SINK
(posteriormente CHECKER) em detectar erros através da inserção, eventualmente, de um erro em
um dos modelos de referência.
REFMOD_LIN
S O U R C E
C H E C K E R
REFMOD2_LIN
Figura 19. Modelo de referência duplo
70
A Etapa 1.3, mostrada na Figura 20, possui componentes RTL – Register Transfer Level, ao
contrário dos modelos anteriores que trabalhavam somente no TL – Transaction Level. O principal
objetivo desse modelo é simular o REFMOD2_LIN por meio do uso do Driver, Actor e Monitor.
Driver
Driver REFMOD2_LIN
Monitor
Actor
Monitor
S O U R C E
C H E C K E R
Monitor
Monitor
Actor
REFMOD_LIN
Figura 20. Emulação do DUV
A Etapa 2.1, mostrada na Figura 21, divide no mesmo nível de abstração o modelo de
referência, hierarquicamente como REFMOD2_LIN.
RX
AXI2LIN TX
CHECKSUM
MUX LIN2AXI
REFMOD_LIN
Figura 21. Modelo de referência decomposto em seis subsistemas
No APÊNDICE A são descritas as Etapas 2.1 e 2.2, as quais repetem as Etapas 1.1 e 1.2,
respectivamente, para cada módulo da divisão hierárquica descrita na Figura 21. A Etapa 2.3, visa
verificar se a divisão hierárquica é equivalente ao modelo de referência. As Etapas 3.1 e 3.2
repetem as Etapas 1.1 e 1.2, respectivamente, para cada módulo da divisão hierárquica. Já a Figura
22 ilustra o testbench completo, após todas as etapas de verificação BVM.
71
Driver
Driver
DUV_LIN
Actor
REFMOD_LIN
S O U R C E
C H E C K E R
Monitor
Monitor
Figura 22. Testbench completo
Com a conclusão da Etapa 4.0 (LIN HW testbench) do modelo de verificação, o DUV_LIN
(LIN HW) pode ser analisado conforme descrito na Subseção 2.6.2 .Os resultados obtidos são
detalhados no Capítulo 5.
4.2.3 Verificação Funcional
O modelo de verificação funcional desenvolvido (doravante denominado LIN HW
TESTBENCH) possui estímulos dirigidos (apresentados no APÊNDICE B ) que emulam o
comportamento do barramento LIN, em especial os sinais oriundos do mestre e de um escravo;
comportamento este descrito no diagrama de sequência ilustrado previamente na Figura 14. Para a
reprodução desses estímulos, em mensagens geradas pelo mestre, foi desenvolvido um escalonador
de mensagens que atua diretamente no bloco SOURCE trocando sinais de controle com o bloco
CHECKER.
O LIN HW TESTBENCH implementa o fluxo principal especificado na Subseção 4.1.2
(Figura 12 e Figura 13), injetando mensagens de leitura e de escrita no LIN HW. Também foram
implementados no LIN HW TESTBENCH os fluxos secundários de diagnóstico e controle da
interface física. Por fim, o LIN HW TESTBENCH pode gerar uma frequência de operação entre 1 a
50 MHz para o funcionamento do LIN HW, bem como pode injetar dados no formato LIN entre 1 e
20 Kbps.
4.3 ABORDAGEM BASEADA EM SOFTWARE – LIN SW
A presente seção analisa o desenvolvimento do LIN SW, sendo dividido em três outras
subseções. Na primeira subseção, é apresentada a implementação do LIN SW utilizando a
72
ferramenta SOPC Builder da Altera e a sua divisão em blocos lógicos quando comparado ao projeto
arquitetural proposto (Subseção 4.1.2 ). A segunda subseção analisa a etapa de programação do
software. Na terceira subseção, é descrito o plano de testes utilizado para o desenvolvimento do
LIN SW.
4.3.1 Implementação do Processador Embarcado Utilizando a Ferramenta
SOPC
A Figura 23 descreve a especificação do projeto de hardware utilizando a ferramenta SOPC
Builder da Altera. Na figura, é possível observar o dispositivo alvo (Cyclone II), a frequência de
clock de 50 Mhz utilizada no kit de desenvolvimento DE2 e os componentes adicionados ao projeto
(processador Altera Nios II, timer, jtga-uart, sysid, pios).
Figura 23. Especificação do sistema utilizando a ferramenta SOPC
A Figura 24 (a) descreve o projeto do hardware, incluindo o processado Nios II (Figura 24
(b)) e os componentes necessários para o sistema o desenvolvimento do LIN SW. Assim, conforme
descrito no Projeto Arquitetural (Subseção 4.1.2 as camadas de Enlace, Transporte e Aplicação
estão abstraídas na programação do software do processador Nios II.
73
LIN SW
i_reset
i_clk
o_tx
i_rx o_cs
o_pio_led[7:0]
o_pio_pwm
i_pio_btn
(a)
NIOS II (b)
Figura 24. Projeto do hardware utilizado no LIN SW utilizando o processador Nios II
4.3.2 Programação do LIN SW
Na camada de Enlace, a amostragem dos sinais seriais inicia com a transmissão do break -
field e com a habilitação de um temporizador configurado a 9600bps. Em seguida, todo o quadro
LIN é amostrado a cada interrupção de 104μs, gerada pelo temporizador, amostrando todos os
campos do protocolo. Todo o processo de amostragem dá-se através de polling, analisando o
recebimento do campo de parada.
Durante o desenvolvimento do LIN SW, várias abordagens foram propostas pela equipe,
contudo, conforme descrito na Seção 2.3 por Ruff (2003), as abordagens que utilizavam a
reconfiguração do bit-rate da UART foram descartadas, por ser uma abordagem pouco
convencional (o grupo entendeu que o uso de interrupção seria mais apropriado).
Para a camada de aplicação, foram utilizados componentes de entrada e saída de dados
(PIOs) a fim de implementar um controle PWM, LEDs como saída e um botão de entrada de dados.
Ainda assim, não foi implementado nenhum mecanismo de diagnóstico, além dos previstos na
especificação do protocolo.
Na Figura 25, é possível observar o diagrama de classes e as camadas do projeto do software
do LIN SW.
74
Figura 25. Diagrama de classes do LIN SW
O ANEXO B detalha a programação do temporizador e a interrupção da porta de entrada e
saída de dados da recepção serial (sinal RX LIN) utilizados como referência da codificação do LIN
SW.
75
5 RESULTADOS
Este capítulo apresenta os resultados do desenvolvimento do LIN SW e do LIN HW. São
abordados aspectos da verificação funcional do LIN HW, a etapa de prototipação e testes, os custos
de silício e as potências obtidas nas duas implementações, a análise dos resultados e as
considerações finais do capítulo.
5.1 VERIFICAÇÃO FUNCIONAL
Com o suporte da verificação funcional feita pelo LIN HW TESTBENCH, foi possível
realizar diversas análises visando identificar eventuais erros na implementação do LIN HW para
que eles fossem corrigidos antes da síntese física do circuito.
A Figura 26 apresenta o diagrama de formas de ondas da simulação, a qual demonstra o
correto funcionamento do LIN HW submetido aos estímulos gerados pelo LIN HW TESTBENCH e
conforme estabelecido pela metodologia BVM. Assim, o diagrama ilustra duas transações
realizadas no barramento: (a) uma transação de escrita, na qual o LIN HW recebe o cabeçalho da
mensagem e os seus dados (ver sinal i_lin_request); e (b) uma transação de leitura, na qual o LIN
HW recebe o cabeçalho e responde com os dados solicitados (ver sinais i_lin_request e
i_lin_response).
Figura 26. Funcionamento do LIN HW TESTBENCH e do LIN HW
Com o escalonamento das mensagens pelo mestre, os campos de dados e de soma e
verificação podem possuir valores randômicos (conforme a aplicação implementada). Como o
campo de dados pode variar entre 2, 4 ou 8 bytes, esses bytes não foram gerados randomicamente,
76
mas sim direcionados para os corner cases27
, ou seja, os estímulos gerados pelo LIN HW
TESTBENCH são direcionados28
. Essa decisão de projeto foi tomada no intuito de possibilitar uma
abrangência de aplicações e de reduzir o tempo de verificação. Este último é justificado tendo em
vista a ocorrência do pior cenário possível para o LIN HW: baud-rate na transmissão/recepção de
dados em 1200 bps e frequência de operação do LIN HW abaixo de 2.4 KHz (frequência de
amostragem de ½ tbit).
Nesse sentido, analisando o LIN HW TESTBENCH com estímulos direcionados, com taxa
de transmissão/recepção de dados a 9600bps e frequência de operação de 50 MHz, a cobertura dos
sinais injetados atingiu 100%.
Uma descrição mais detalhada dos aspectos relativos à verificação funcional é apresentada
no APÊNDICE B .
5.2 PROTOTIPAÇÃO E TESTE
A Figura 27 ilustra o diagrama de blocos do protótipo definido para os testes das
implementações físicas do LIN HW e do LIN SW. Nessa figura, é possível observar o nodo mestre
responsável por gerar o cabeçalho LIN, interconectado pelo barramento a dois nodos escravos
implementados segundo as duas abordagens utilizadas neste trabalho (baseadas em software e em
hardware). O nodo mestre é baseado em um microcontrolador da Freescale e executa um código
baseado em um demonstrativo disponibilizado pela própria empresa. Nesse código, o mestre envia
quadros LIN aos nodos escravos que devem responder às transações. O LIN HW foi sintetizado em
um FPGA da família Cyclone III da Altera montado sobre o kit de desenvolvimento DE0 da
Terasic. Já o LIN SW foi sintetizado para um FPGA da família Cyclone II da Altera, montado sobre
o kit DE2 da Terasic. Os nodos escravos possuem camadas de aplicação distintas, incluindo:
acionamento de motores DC (utilizando PWM) e transmissão de sinais de acionamento de botões.
27
Refere-se a valores extremos do byte, como o valor 0x00 e 0xFF, ou mesmo a ausência do dado em um determinado
momento da verificação. O uso de dados randômicos permite muitas vezes cobrir valores que muitas vezes passam
despercebidos pela equipe de verificação, contudo existe o custo do tempo de simulação. No caso do projeto do LIN
HW como a granularidade do projeto é grande, o bloco que poderia apresentar alguma necessidade maior de
verificação, como o bloco de soma e verificação (Checksum), foi exaustivamente verificado utilizando valores
randômicos. 28
Estímulos direcionado possuem valores preestabelecidos como o header e os dados injetados.
77
LIN bus
Aplicação
Transporte
Enlace
NIOS II
Nodo Escravo 0 (LIN SW – DE2 – Cyclone II)
Aplicação
Transporte
Enlace
Nodo Escravo 1 (LIN HW – DE0 – Cyclone III)
Nodo Mestre (DEMO9S12XEP100)
Física Física Física
Figura 27. Diagrama de blocos do protótipo para teste físico
A Figura 28 ilustra a bancada de teste com a montagem de um nodo mestre (centro) e dois
nodos escravos (LIN HW à esquerda e LIN SW à direita), simulando uma rede automotiva. Para
auxiliar na verificação, é utilizado um osciloscópio digital. Ambos o kits de desenvolvimento (DE0
e DE 2) operaram a 50 MHz e a taxa de transmissão utilizada para o quadro LIN foi de 9600bps.
Figura 28. Bancada de testes LIN
O escalonador de mensagem (Figura 29) utilizado pelo nodo Mestre suporta dois tipos de
mensagem. A mensagem com identificador 0xd3 envia informação de um potenciômetro do nodo
Mestre para o nodo Escravo_0 baseado no LIN SW implementado na DE2. Este, por sua vez,
aciona o motor DC do velocímetro do painel simulando o acionamento do pedal do acelerador de
78
um automóvel pelo nodo Mestre. A mensagem com identificador 0x42 solicita para o nodo
Escravo_1 baseado no LIN HW implementado na DE0 informações sobre o status de dois botões, o
farol alto e a luz de alerta, acionados pelo motorista.
Mestre - Mensagem_0 ID 0xd3
Mestre - Mensagem_1 ID 0x42
Caso de Uso - Tabela de Escalonamento
Figura 29. Caso de uso tabela de escalonamento de mensagens
O diagrama da Figura 30 descreve o fluxo das mensagens adotado pela tabela de
escalonamento desenvolvido para o sistema. Cada escravo dentro do barramento possui
identificadores específicos para cada aplicação, sendo que todos recebem as mensagens em
broadcast, cabendo a cada escravo interpretar o identificador e agir conforme a sua aplicação.
Nesse diagrama, o nodo Mestre envia a mensagem com identificador 0xd3, o Escravo_0 interpreta
essa mensagem como pertencente a ele e aciona o velocímetro utilizando PWM. Já a mensagem
com identificador 0x42 enviada pelo mestre retorna o status dos interruptores dos faróis e da luz de
alerta do Escravo_1.
Figura 30. Fluxo de mensagens enviadas no Barramento LIN
A Figura 31 (captura de tela do osciloscópio) ilustra a transferência de um quadro LIN na
qual o nodo Mestre envia uma mensagem para que o Escravo_0 (DE2 – Cyclone II) atue utilizando
79
PWM para o acionamento do velocímetro do painel do automóvel. A Figura 31 possui três sinais
distintos, são eles: (a) o sinal do barramento LIN (12 volts); (b) o sinal no canal de recepção LIN do
PHY (RX); e (c) chip-select (CS) responsável por habilitar o canal de transmissão (TX) do PHY.
Figura 31. Quadro enviado do nodo mestre para o Escravo_0 com a mensagem de ID 0xd3 (escala
em 5 volts)
A Figura 32 ilustra o envio de uma mensagem pelo nodo Mestre, solicitando que o
Escravo_1 (DE0 – Cyclone III) atualize a rede com o status das chaves de acionamento dos faróis e
da luz de alerta do automóvel. Na figura, é possível observar: (a) o sinal do barramento LIN (12
volts); (b) o sinal do canal de transmissão de dados do PHY (TX); e (c) o sinal de chip-select (CS).
Cabe observar que o sinal TX é ativado no momento do envio da resposta solicitada pelo
barramento. No exemplo, o nodo Escravo_1 está enviando dois bytes com valor 0x01 (estado das
chaves) e o byte de soma e verificação.
80
Figura 32. Quadro enviado do nodo mestre para o Escravo_1 com a mensagem de ID 0x42 e sua
respectiva resposta (escala em 2 volts)
As implementações físicas foram validadas com a aplicação de planos de testes pré-
definidos a fim de:
Testar as funcionalidades das implementações, conforme descrito na Seção 4.1;
Verificar o correto funcionamento dos fluxos principais e secundários dos casos de uso
definidos na Subseção 4.1.2 ;
Confirmar o atendimento das especificações quanto às respostas esperadas para os
estímulos aplicados;
Validar as suposições e os requisitos elencados nas especificações de design por meio da
verificação; e
Minimizar os esforços redundantes.
81
5.3 CUSTO DE SILÍCIO
Concluídas as etapas de implementação, verificação29
, prototipação e teste, o LIN HW e o
LIN SW foram sintetizados para dispositivos das famílias Cyclone II e Cyclone III da Altera a fim
de se extrair métricas quanto ao custo de silício dessas implementações.
A Tabela 2 apresenta os custos de silício de FPGA para a família Cyclone II (dispositivo
EP2C35F672C6E). Os custos são expressos pela quantidade de Look-Up Tables (LUTs)30
, Flip-
Flops (FFs) e Células Lógicas (LCs) consumidas. Cada LC possui uma LUT e um FF, sendo que,
na síntese, o Quartus II pode utilizar ambos os recursos de uma LC, ou apenas um ou outro. Uma
vez que nem todas as LCs são ocupadas integralmente, em geral, o número de LCs utilizadas difere
da quantidade individual de LUTs ou de FFs, ou mesmo da soma dessas duas quantidades. Por
exemplo, o LIN HW sintetizado para o dispositivo Cyclone II consumiu 413 LUTs e 485 FFs, num
total de 794 LCs.
Tabela 2. Custos da síntese dos principais blocos do LIN HW para a família Cyclone II
Bloco LUTs FFs LCs
AXI2LIN 24 80 94
GENETOP 11 18 29
LIN2AXI 13 29 38
CHECKSUM 47 96 143
MUX 23 32 46
RX 180 139 239
TX 115 91 205
TOTAL 413 485 794
A Tabela 2 também apresenta os custos dos blocos que constituem o LIN HW. É possível
observar que o RX constitui o bloco com maior consumo de recursos, pois é o de maior
complexidade, sendo responsável pelas etapas de identificação do início do cabeçalho LIN, re-
sincronização e conversão serial/paralela dos dados recebidos.
Na Tabela 3, são apresentados os custos de silício de FPGA para a família Cyclone III
(dispositivo EP3C16F484C6E).
29
Vale destacar que a implementação LIN SW não foi submetida à verificação funcional, dado que o testbench (LIN
HW TESTBENCH) foi desenvolvido especialmente para a verificação do LIN HW. 30
As LUTs são blocos que implementam funções lógicas e refletem a área de silício devida à lógica combinacional.
82
Tabela 3.Custos da síntese dos principais blocos do LIN HW para a família Cyclone III
Bloco LUTs FFs LCs
AXI2LIN 29 81 95
GENETOP 11 18 29
LIN2AXI 13 29 38
CHECKSUM 47 96 143
MUX 22 32 45
RX 177 138 240
TX 114 91 204
TOTAL 413 485 794
LIN Software
A Tabela 4 apresenta os resultados da síntese lógica do projeto do LIN SW. O LIN SW foi
sintetizado para FPGA da família Cyclone II e Cyclone III.
Tabela 4. Custos da síntese do LIN SW para as famílias Cyclone II e Cyclone III
Família de FPGA LUTs FFs LCs Memória embutida (kb)
Cyclone II 770 769 1441 273,408
Cyclone III 768 777 1442 273,408
Comparativo Entre as Implementações
A Tabela 5 reúne os resultados da síntese lógica para as duas abordagens LIN HW e LIN
SW para a família Cyclone II da Altera.
Tabela 5. Comparação entre as duas abordagens para a família Cyclone II
Bloco LUTs FFs LCs
LIN_HW 413 485 794
LIN_SW 770 769 1441
A Tabela 6 reúne os resultados da síntese lógica para as duas abordagens LIN HW e LIN
SW para a família Cyclone III da Altera.
83
Tabela 6. Comparação entre as duas abordagens para a família Cyclone III
Bloco LUTs FFs LCs
LIN_HW 413 485 794
LIN_SW 768 777 1441
Nesse contexto, os resultados das Tabela 5 e da Tabela 6 quando comparados demonstram
que uma implementação em hardware é mais vantajosa quando se analisa o custo final em células
lógicas.
5.4 TEMPO DE PROJETO
Com relação ao tempo de desenvolvimento (especificação, implementação e verificação) das
duas abordagens, observou-se um menor tempo de projeto para a abordagem baseada em software,
aproximadamente 6 meses entre a codificação e o desenvolvimento da bancada de testes. Já no
projeto do hardware, entre o desenvolvimento da ferramenta de verificação do protocolo, o
desenvolvimento e a síntese física do núcleo LIN decorreram aproximadamente dois anos.
No desenvolvimento das duas implementações foi necessário um esforço para
aprendizagem de conceitos, tecnologias e ferramentas, tornou-se impossível quantificar
precisamente a diferença de tempo de projeto, contudo, no contexto da presente dissertação, estima-
se que o projeto em software foi quatro vezes mais rápido que o projeto em hardware.
5.5 POTÊNCIA DISSIPADA
Os resultados dos experimentos estimando as potências dissipadas pelo LIN HW foram
feitos utilizando as ferramentas PowerPlay da Altera e a ferramenta Modelsim da Mentor Graphics,
utilizando a configuração padrão das ferramentas. Nesses experimentos, foram extraídas quatro
métricas de potência para o dispositivo Cyclone II, são elas: (i) potência térmica dissipada total (ii)
potência térmica dinâmica dissipada pelo núcleo, (iii) potência térmica estática dissipada pelo
núcleo e a (iv) potência térmica dissipada pelos pinos de I/O. Na Tabela 7, são reunidos os
resultados das potências dissipadas pelo LIN HW, analisados nas frequências de operação de
1 MHz, 25 MHz e 50 MHz.
84
Tabela 7. Potências dissipadas pelo LIN HW operando sob diferentes frequências
Frequência 50 MHz 25 MHz 1 MHz
Potência Térmica I/O Dissipada 37,09 mW 36,72 mW 36,16 mW
Potência Térmica Dinâmica do Núcleo Dissipada 44,99 mW 19,70 mW 0,89 mW
Potência Térmica Estática do Núcleo Dissipada 80,10 mW 80,01 mW 79,95 mW
Potência Térmica Total Dissipada 162,17 mW 136,43 mW 117 mW
A Figura 33 compara graficamente todas as potências dissipadas pelo LIN HW.
Figura 33. Gráfico da potência consumida pelo LIN HW
A mesma abordagem foi utilizada para análise das potências dissipadas pelo LIN SW. A
Tabela 8 reúne os resultados obtidos:
Tabela 8. Potências dissipadas pelo LIN SW operando em diferentes frequências
Frequência 50 MHz 25 MHz 1 Mhz
Potência Térmica I/O Dissipada 35,19 mW 34,07 mW 32,99 mW
Potência Térmica Dinâmica do Núcleo Dissipada 24,58 mW 12,97 mW 0,48 mW
Potência Térmica Estática do Núcleo Dissipada 80,02 mW 79,98 mW 79,93 mW
Potência Térmica Total Dissipada 139,79 mW 127,97 mW 113,4 mW
0
20
40
60
80
100
120
140
160
180
50 25 1
Potência I/O
Potência Dinâmica
Potência Estática
Potência Total
Frequência (MHz)
Po
tên
cia
(mW
)
85
A Figura 34 compara graficamente todas as potências analisadas do LIN SW.
Figura 34. Gráfico da potência consumida do LIN SW
A Figura 35 compara graficamente (em colunas) as potências analisadas do LIN SW e do
LIN HW.
Figura 35. Gráfico comparativo em colunas das potências consumidas entre o LIN SW e LIN HW
0
20
40
60
80
100
120
140
50 25 1
Potência I/O
Potência Dinâmica
Potência Estática
Potência Total
Frequência (MHz)
Po
tên
cia
(mW
)
0
20
40
60
80
100
120
140
160
180
50 25 1
Potência I/O
PotênciaDinâmicaPotência Estática
Po
tên
cia
(mW
)
Frequência (MHz)
86
A Figura 36 compara, em um gráfico de linhas, as potências analisadas do LIN SW e do
LIN HW
Figura 36. Gráfico comparativo linear das potências consumidas entre o LIN SW e LIN HW
Na Figura 35 e na Figura 36 é possível observar que a Potência I/O e a Potência Estática nas
duas abordagens em todas as frequências propostas permanecem constantes, pois não ocorre
atividade de chaveamento (dispersão de corrente). Contudo, analisando-se a Potência Térmica
Dinâmica do Núcleo, a abordagem em hardware possui vantagens em relação à abordagem em
software nas frequências de operação de 25 MHz e 50 MHz, sendo a potência de 1 MHz é
desconsiderada devido a possível incerteza na medição.
Nesse sentido, como a Potência Térmica Total é constituída das três componentes de
potências anteriormente citadas e considerando as ferramentas de simulação utilizadas (com as
referidas configurações) para os respectivos dispositivos, torna-se vantagem utilizar a abordagem
em hardware para sistemas que utilizem frequência entre 25 MHz e 50 MHz.
5.6 RESULTADOS ADICIONAIS - SÍNTESE EM ASIC
Adicionalmente aos experimentos realizados para FPGA, foram obtidas métricas de custo da
síntese física do LIN HW em ASIC (Application Specific Integrated Circuit). A tabela a seguir
apresenta diversos resultados da síntese física (utilizando a ferramenta ICC da Synopsys) do
LIN HW para a tecnologia XFAB 0.35μm.
0
20
40
60
80
100
120
140
160
180
50 25 1
Po
tên
cia
(mW
)
Frequência (MHz)
Potência I/O
Potência Dinâmica
Potência Estática
Potência Total
87
Tabela 9. Resultados da síntese física do LIN HW para a tecnologia XFAB 0.35μ
Tecnologia XFAB 0.35μ
Camadas de Metal 4
Área Die 4,9 mm²
Área Combinacional 1 mm²
Área Não Combinacional 1 mm²
PADs 60
Encapsulamento CL CCJ 68 X-FAB
Tensão de Alimentação 3,3V
Potencia Dinâmica para 10 MHz 7,1 mW
A figura a seguir apresenta uma imagem do die do LIN HW após a síntese física do núcleo.
Figura 37. Síntese Física do LIN HW
O resultado final ou tape-out de todo o ciclo de desenvolvimento pode ser visto na figura a
seguir.
Figura 38. Resultado final do ciclo de desenvolvimento
88
5.7 ANÁLISE DOS RESULTADOS
Os resultados obtidos para as duas implementações sintetizadas em dispositivos lógicos
programáveis do tipo FPGA Altera Cyclone II e Cyclone III, utilizando a ferramenta Quartus II e
analisados sobre restrições de frequência de operação e quadros LIN, mostraram que:
A implementação baseada em hardware consome menos área de silício que a
implementação em software;
A implementação baseada em software é mais flexível para atualizações; e
A implementação baseada em hardware consome menos energia.
O Item 1 não confirma a hipótese levantada na Subseção 1.1.1 em decorrência da
metodologia de verificação funcional BVM e das otimizações da implementação em hardware.
Nesse caso, o LIN SW, tendo em vista que utiliza um processador de propósito geral (Nios II),
possui mais lógica inserida no projeto final.
O Item 2 confirma a hipótese levantada na Subseção 1.1.1 . Ainda que o LIN SW funcione
por polling para a detecção do início de um quadro LIN, a implementação em software foi
facilitada, pois utilizou o mesmo levantamento de requisitos e todo o conhecimento pré-adquirido
na implementação do LIN HW, além da análise das diversas soluções do protocolo LIN em
software para microcontroladores. Nesse sentido, qualquer modificação no LIN SW pode ser
rapidamente efetuada e verificada utilizando a ferramenta de simulação Modelsim.
O Item 3 confirma a hipótese levantada na Subseção 1.1.1 de que a solução baseada em
hardware consumiria menos energia do que a solução baseada em software. Porém, cabem algumas
ponderações. Em primeiro lugar, os resultados obtidos consideram as duas implementações
operando na mesma frequência. No entanto, estima-se que a frequência mínima de operação do LIN
SW seja cerca de uma ordem de magnitude superior à do LIN HW31
, o que resultaria em um maior
consumo de potência dinâmica. No entanto, conforme discutido, não foi possível se determinar a
frequência mínima de operação do LIN SW. Além disso, destaca-se o fato de que o projeto do LIN
HW não aplicou técnicas de projeto visando a redução do consumo de potência. Após análises dos
31
Cabe lembrar que as tarefas do protocolo LIN são executadas em paralelo pelos módulos do LIN HW, enquanto que o
LIN SW as executa de forma sequencial.
89
relatórios apresentados pela ferramenta PowerPlay, verificou-se que existem blocos lógicos que
podem ser otimizados em trabalhos futuros para consumir menos potência.
Por fim, os resultados obtidos nesse trabalho podem ser validados a partir do sucesso na
produção do ASIC LIN, da bancada de teste automotiva pelo desenvolvimento da ferramenta de
verificação, dentre outros.
No Quadro 3, é possível observar uma análise comparativa das principais características dos
núcleos comerciais anteriormente listados e do LIN HW e LIN SW da UNIVALI.
Quadro 3. Análise comparativa das características de núcleos de propriedade intelectual LIN
Atributo Desenvolvedor
CAST Intelliga BOSCH UNIVALI UNIVALI UNIVALI
Nome LIN Core iLIN C LIN LIN IP LIN HW LIN SW
Tipo de Núcleo Soft IP-core Soft IP-
core
Soft IP-
core Soft IP-core Soft IP-core
Soft IP -
core
HDL VHDL
Verilog
VHDL
Verilog VHDL VHDL Verilog Verilog
Tecnologia
Alvo
FPGA
ASIC
FPGA
ASIC
FPGA
ASIC FPGA
FPGA
ASIC FPGA
Especificação Revisão 2.0 Revisão 1.3
Revisão
1.3, 2.0 e
2.1
Revisão 2.1 Revisão 2.1 Revisão
2.1
Configuração
da taxa de
dados
Programável
ou
automática
Automática Fixa Fixa Programável Fixa
Buffer de dados Um buffer
de 8 bytes
Informação
não
disponível
Buffers
TX e RX
de 8 e 7
bytes
Buffers TX e
RX
configuráveis
Buffers TX e
RX
Não
possui
Buffer
Funcionalidade Mestre ou
escravo
Mestre ou
escravo
Mestre
ou
escravo
Escravo Escravo Mestre ou
Escravo
Custo de silício 2710 a 3760
gates 3000 gates
3100 a
3900
gates
598 células
lógicas
794 células
lógicas
1441
células
lógicas
Referência CAST
(2007)
Intelliga
(2003)
BOSCH
(2007)
Pereira
(2008)
Presente
Trabalho
Presente
Trabalho
90
5.8 CONSIDERAÇÕES
Esta pesquisa contribui como um guia para desenvolvimento do protocolo automotivo LIN
em software e em hardware. Para tal, fez-se uma revisão bibliográfica dos conceitos relacionados a
redes automotivas, tais como as definições, a classificação e os padrões das redes automotivas, bem
como uma revisão mais detalhada sobre o protocolo automotivo LIN. Também foi realizado um
estudo sobre as técnicas de projeto de circuito integrado, no qual foram analisados as métricas mais
usadas, a metodologia de verificação ipPROCESS e foi feito um estudo mais aprofundado sobre
verificação de blocos IP. Foram ainda relacionados trabalhos que abordaram o desenvolvimento, as
métricas, os modelos e as metodologias de verificação de bloco IP.
Apresentou-se também a especificação do projeto baseado na metodologia ipPROCESS.
Nesse sentido, foram feitas análises dos atores, do diagrama de sequência, da descrição e do projeto
arquitetural do projeto (software e hardware). Essa análise não foi totalmente exaustiva, mas
acreditamos que os aspectos fundamentais para o desenvolvimento tanto em software quanto em
hardware do protocolo LIN foram abordados.
A partir dessa análise, descreveu-se o desenvolvimento do protocolo LIN em hardware e em
software, apresentando-se toda a descrição lógica dos blocos, os métodos de verificação e os
resultados obtidos no desenvolvimento. Nesse sentido, os resultados demonstraram o
funcionamento do LIN HW/LIN SW e os custos da síntese em FPGA para as famílias Cyclone II
Cyclone III.
Os resultados da primeira versão do IP LIN foram publicados nos anais do XV Workshop
Iberchip (IBERCHIP 2009). Já os resultados da verificação funcional do LIN HW foram
apresentados no Fórum de Estudantes de Microeletrônica 2010 (SForum 2010).
O uso do protocolo LIN também está inserido no contexto do programa UNIESPAÇO da
Agência Espacial Brasileira (AEB), com o projeto intitulado – Uso do Protocolo LIN na
Interconexão de Sistemas em Satélites Artificiais. No qual visa avaliar a aplicabilidade do protocolo
LIN para uso na interconexão de sistemas aeroespaciais.
91
6 CONCLUSÕES
Os resultados obtidos no presente trabalho mostraram que as duas abordagens (hardware e
software) podem ser adotadas na implementação de uma rede LIN em um automóvel. Contudo, com
base nos experimentos realizados, verificou-se que o diferencial na escolha de uma das abordagens
está no modelo de negócio adotado pela empresa no momento. Em um cenário automotivo de
negócios, com necessidade de redução de custos em periféricos, estima-se que o melhor modelo
adotado deve possuir baixo Time-to-Prototype e baixo Time-to-Market, a melhor abordagem é em
software. Já em um cenário automotivo de negócios a longo prazo, com vistas à adoção em uma
plataforma consolidada, o qual implica em severas reduções no preço final do automóvel e que
permite o aumento do conforto dentro do automóvel sem comprometer a segurança dos seus
ocupantes, estima-se que a melhor abordagem é em hardware.
Nesse sentindo, o presente trabalho contribui como um guia para projetistas de sistemas
baseados em LIN, orientando-os na escolha da melhor abordagem para o desenvolvimento de
projetos baseados em redes automotivas, em especial na rede LIN.
Como contribuição adicional dessa dissertação, destaca-se a modelagem e o
desenvolvimento de um testbench para verificação funcional do protocolo LIN. Como o referido
protocolo é auto-sincronizado (self - synchronized), o testbench desenvolvido diferencia da
metodologia BVM proposta no escopo do programa Brazil IP devido à ausência do bloco “Actor”, o
qual é responsável pelo handshake necessário à comunicação entre os blocos durante a verificação
funcional. O projeto executado no contexto do Brazil IP produziu, como principais artefatos: o
testbench, a síntese lógica e a síntese física do core (LIN HW) para a produção de um ASIC
utilizando a tecnologia XFAB 0.35. Vale destacar que não foram encontrados trabalhos na literatura
que relacionem verificação funcional para sistemas automotivo, em especial a verificação funcional
do protocolo LIN.
Quanto às publicações, ao longo do período de estudos e pesquisa no mestrado, foram
publicados trabalhos nos anais dos eventos Students Forum on Microelectronics (SFORUM 2010) e
no Workshop IBERCHIP (IWS 2009).
92
6.1 TRABALHOS FUTUROS
Como trabalhos futuros, vislumbram-se algumas oportunidades a serem exploradas a partir
da experiência produzida com esta dissertação:
Obtenção de dados quantitativos acerca de métricas de projetos não cobertas por essa
dissertação, tais como a frequência e taxas mínimas e máximas de operação das duas
abordagens e o tempo de projeto de cada etapa do desenvolvimento;
Implementação e avaliação do nodo mestre LIN em hardware; e
Teste da abordagem de verificação funcional para dispositivos baseados em outras redes
automotivas, tais como CAN, FLEXRAY ou MOST.
93
REFERÊNCIAS
ALTERA. Nios Processor. 2011. Disponível em:
<http://www.altera.com/products/ip/processors/ipm-index.jsp>. Acesso em: 15 jan. 2011.
ALTERA. Quartus II Web Edition Software. 2010. Disponível em:
<https://www.altera.com/download/software/quartus-ii-se>. Acesso em: 10 jan. 2010.
BERETTA, Joseph. Goal and prospects of embedded electronics systems.[S.l.]: PSA Peugeot
Citroën, 2003.
BERGERON, Janick. Writing testbenches using system verilog. [S.l.]: Springer; 2006.
BMW. FLEX RAY. 2010. Disponível em:
<http://www.bmw.com/com/en/insights/technology/technology_guide/articles/flex_ray.html>.
Acesso em: 10 jan. 2010.
BORGES, José A.; SCHMITZ, Eber A. Projeto de circuitos integrados. Rio de Janeiro: LTC,
1990.
BOSCH, Robert. Automotive handbook. [S.l.]: John Wiley & Sons, 2008.
BOSCH, Robert. C_LIN Module - for low cost LIN slave designs. Reutlingen: Alemanha; 2007.
BROWN, Stephen.;ROSE, Jonathan. FPGA and CPLD architectures: a tutorial. IEEE Design &
Test of Computers, p. 42, 1996.
CARRO, Luigi. Projeto e prototipação de sistemas digitais. Porto Alegre: UFGRS, 2001.
CARVALHO, Leonardo Mello de. Indicador IPEA de produção industrial mensal, [S.l.: s.n.],
2011.
CAST Inc. LIN controller core. Woodcliff Lake: Cast, 2007.
CHARETTE, Robert N. This car runs on code. 2009. Disponível em:
< http://spectrum.ieee.org/green-tech/advanced-cars/this-car-runs-on-code/0>. Acesso em: 10 mar.
2010.
CYPRESS. PSoC technology. [S.l.: s.n.], 2009.
DAY, John H. In-vehicle network standards dance to automakers’ tunes. Ward’s auto electronics,
Março, 2005.
DEPRÁ Dieison A.; ZATT, Bruno; BAMPI, Sergio. A method for HW functional verification
through HW/SW co-simulation in complex systems: H.264/AVC decoder as case study. In. LATIN
AMERICAN TEST WORKSHOP, 10., 2009, Buzios. Proceedings… [S.l.: s.n.], 2009.
EBERT, Christof; JONES, Capers. Embedded software: facts, figure, and future. Computer. 2009.
94
EICHINER Friedrich. Annual accounts press conference. Munique: Alemanha, 2010.
GUIMARÃES, Alexandre de A. Eletrônica embarcada automotiva. 1. ed., São Paulo: Érica,
2007.
HEKMATMPOUR Amir, COULTER James, Coverage-directed management and optimization
of random functional verification. In: INTERNATIONAL TEST CONFERENCE (ITC), 2013.
Proceedings… [S.l.: s.n.], 2003.
INTELLIGA; Local interconnect network controller core – ILIN V1.3. Essex: Intelliga, 2003.
KHANAPURKAR, Milind; BAJAJ, Preeti; DAHAKE, Sandesh; WANDHARE, Hemant. Design
approach for VHDL and FPGA implementation of automotive black box using CAN Protocol.
International Journal of Computer Science and Network Security, v.8 n.9, 2008.
LAKATOS, Eva Maria; MARCONI, Marina de Andrade. Metodologia do trabalho científico. 4.
ed. São Paulo: Atlas, 1992
LIMA, Marília; SANTOS, Francielle; BIONE, João; LINS, Tiago; BARROS, Edna. IPPROCESS:
A development process for soft IP-Core with prototyping in FPGA. Recife: UFPE, 2005.
LIN, Consortium. LIN specification package - revision 2.1. Sttugart: Alemanha, 2006.
LUPINI, Christopher A. Vehicle multiplex communication - serial data networking applied to
vehicular engineering. SAE International, [S.l.: s.n.], 2004.
MALI, Marko; NOVAK; Franc; BIASIZZO, Anton. Hardware implementation of AES algorithm.
Electrical Engineering, v.56, n. 9-10, 2005.
MICROCHIP. PICDEM CAN-LIN 1 2 and 3 demonstration boards, 2009.
MOST. MOST, 2010. Disponível em: < http://www.mostnet.de/home/index.html>. Acesso em: 10
mar. 2010.
NEVES, José L. Pesquisa qualitativa: característica, usos e possibilidades. Caderno de Pesquisas
em Administração, São Paulo, v.1, n.3, 1996.
ALTERA. Nios II processor reference handbook. [S.l.]: Altera, 2009.
OLIVER, John D.; Implementing the J1850 protocol. [S.l.]: Intel, 1996.
PAPO, José P. Metodologias ágeis e extreme programming (XP): uma introdução, 2002.
Disponível em: <http://www.spinsp.org.br/apresentacao/SpinXP.pdf 0>. Acesso em: 15 mar. 2011.
PATTERSON, David A.; HENNESSY, John L.; Organização e projeto de computadores: a
interface hardware/software. 3.ed., Rio de Janeiro: Campus, 2005.
PEREIRA, Rodrigo V. M. Implementação do protocolo de comunicação automotivo LIN Bus
versão 2.0 em FPGA no modo escravo. Trabalho de Conclusão de Curso (Bacharelado em
Engenharia de Computação)– Universidade do Vale do Itajaí, São José, 2008.
95
RUF, Matthew. Evolution of local interconnect network (LIN) solutions. Motorola, Austin:
Texas, 2003.
RUP. Rational unified process - best practices for software development teams. White Paper.
2001. Disponível em:
<http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractice
s_TP026B.pdf>. Acesso em: 30 mar. 2011.
SILVA, Karina R. G. Uma metodologia de verificação funcional para circuitos digitais. 2007.
121f. Tese (Doutorado em Engenharia Elétrica )– Programa de Pós-Graduação em Engenharia
Elétrica, Universidade Federal de Capina Grande, Campina Grande, 2007.
SOARES, Luiz F.G.; LEMOS,Guido; COLCHER,Sérgio. Redes de computadores – das LANS,
MANS e WANS às redes ATM. 1. ed. Rio de Janeiro: Campus, 1995.
THOMAS, Donald. E; MOORBY, Philip R. The Verilog hardware description language. [S.l.]:
Springer, 4. ed. 1998.
TOBAR, Edgar L. R. Técnicas para a verificação funcional eficiente de uma implementação
RTL da camada banda base do protocolo Bluetooth. 2005. 71f. Dissertação (Mestrado em
Engenharia Elétrica)– Programa de Pós-Graduação em Engenharia Elétrica, Universidade de São
Paulo, São Paulo, 2005.
VAHID, Frank. Embedded system design: a unified hardware/software introduction. [S.l.]: Wiley,
2002.
VARID, Frank. Sistemas digitais: projeto, otimização e HDLS. 1.ed. Porto Alegre: Bookman,
2008.
VISTEON. 2007 Annual Report. Van Buren Township: Visteon, 2008.
96
APÊNDICE A - IMPLEMENTAÇÃO DO ASIC DO LINIP
Verificação Funcional
A metodologia BVM é uma reformulação da metodologia VeriSC, na qual tem como
premissa a construção do testbench de forma incremental. A diferença marcante nessa metodologia
está na criação do bloco Actor, de controle da comunicação entre o DUV e o testbench. Além disso,
o uso de uma FIFO com duas saídas possibilitou, em conjunto com o uso do Actor, a detecção de
erros na fase de integração entre o DUV e o testbench. Essa abordagem permite que em projetos
com múltiplos módulos, os erros de comunicação entre DUV e testbench, sejam facilmente
detectados. Assim como o VeriSC, a construção do testbench é priorizada com relação a criação
DUV.
A metodologia prevê a decomposição do testbench em três passos: (i) Refmod Simples; (ii)
Refmod Duplo; e (iii) Emulação do DUV.
A Figura 42 ilustra a Etapa 1.1 de decomposição simples do testbench. Essa etapa tem por
objetivo testar a capacidade do modelo de referência32
(Refmod_LIN) interagir com o bloco de
geração de estímulos, o Pre_Source, e com o bloco de verificação das saídas do sistema, o Sink.
Figura 39. Etapa 1.1 – Decomposição Simples do Modelo de Referência
32
Também conhecido como golden model, ou modelo de ouro, por se tratar de um modelo de referência já consolidado.
Esse modelo pode ser uma caixa-preta, uma caixa-cinza ou mesmo uma caixa-branca, descrito muitas vezes em
linguagem de alto nível como C, C++ ou SystemVerilog.
P R E S O U R C E
REFMOD_LIN
S I N K
97
A Figura 40 ilustra um incremento na Etapa 1.1 com a adição de mais um modelo de
referência (Refmod2_LIN) e substituição do gerador dos estímulos pelo bloco Source e o
verificador das saídas pelo Checker, sendo assim, os dois blocos são acrescidos de duas FIFOS de
saída.
REFMOD2_LIN
C H E C KER RX
C HECKER
REFMOD_LIN S O U R C E
Figura 40. Modelo de referência hierárquico duplo.
Na Etapa 1.3, com objetivo de transformar as transações em sinais, são introduzidos mais
dois módulo, o Driver e o Monitor (Figura 41) e conforme a metodologia BVM, o Actor é o
responsável por sincronizar a transferência das mensagens. Para o presente projeto, devido a
características do protocolo LIN o Actor foi suprimido na transmissão e recepção dos sinais seriais
do protocolo LIN.
Figura 41. Emulação DUV
Driver
REFMOD2_LIN
Actor
Actor
Monitor Driver
Monitor Driver Monitor Driver
REFMOD_LIN
S O U R C E
C H E C K E R
Monitor
98
Semelhantes ao passo 1.1, as figuras seguintes (Figura 42 à Figura 47), ilustram o modelo de
referência pertencentes a etapa 2.2, já decomposto e submódulos e incluídos no testbench.
P R E S O U R C E 1
REFMOD_RX
S I N K R X
Figura 42. Decomposição simples do modelo de referência RX
P R E S O U R C E 2
S I N K MU X
REFMOD_MUX
Figura 43. Decomposição simples do modelo de referência MUX
Figura 44. Decomposição simples do modelo de referência LIN2AXI
P R E S O U R C E 3
S I N K L I N2 AX
I
REFMOD_LIN2AXI
99
Figura 45. Decomposição simples do modelo de referência AXI2LIN
P R E S O U R C E 5
REFMOD_CHECKSUM
S I N K CH E C K S UM
Figura 46. Decomposição simples do modelo de referência CHECKSUM
P R E S O U R C E 6
S I N K TX
REFMOD_TX
Figura 47. Decomposição simples do modelo de referência TX
P R E S O U R C E 4
REFMOD_AXI2LIN
S I N K AX I 2 L I N
100
A Figura 48 ilustra como o modelo de referência foi decomposto hierarquicamente. Nessa
figura é possível observar a decomposição em cinco submódulos e as suas interligações, sendo que
cada submódulo é testado individualmente nas etapas a seguintes.
REFMOD_LIN
S O U R C E
C H E C K E R
RX
AXI2LIN TX
CHECKSUM
MUX LIN2AXI
Figura 48. Decomposição Hierárquica do Modelo de Referência
Semelhantes ao passo 1.2, as figuras seguintes (Figura 49 à Figura 54), pertencentes ao
passo 3.1, ilustram o modelo de referência já decomposta em dois submódulos e incluída no
testbench. O objetivo principal dessa abordagem é testar o correto funcionamento do Source e do
Checker.
REFMOD2_RX
C H E C KER RX
C HECKER RX
REFMOD_RX S O U R C E 1
Figura 49. Modelo de referência RX hierárquico duplo
101
CHECKER MU X
REFMOD_MUX
REFMOD2_MUX
S O U R C E 2
Figura 50. Modelo de referência MUX hierárquico duplo
S O U R C E 3
CHEKCER L I N2 AX
I
REFMOD_LIN2AXI
REFMOD2_LIN2AXI
Figura 51. Modelo de referência LIN2AXI hierárquico duplo
S O U R C E 4
REFMOD_AXI2LIN
CHECKER AX I 2 L I N
REFMOD2_AXI2LIN
Figura 52. Modelo de referência AXI2LIN hierárquico duplo
102
S O U R C E 5
REFMOD_CHECKSUM
SOURCE CH E C K S UM
REFMOD2_CHECKSUM
Figura 53. Modelo de referência CHECKSUM hierárquico duplo
S O U R C E 6
C H E CKER TX
REFMOD_TX
REFMOD2_TX
Figura 54. Modelo de referência TX hierárquico duplo
A etapa a seguir (Figura 55 à Figura 60) tem a mesma finalidade da Etapa 1.3, contudo o
testbench deve ser reconstruído atendendo a demanda de cada módulo. Para isso, blocos já
desenvolvidos nas etapas anteriores como Actor, Monitor e Driver, devem ser reutilizados.
103
Driver REFMOD2_RX Monitor Monitor
Actor
REFMOD_RX
S O U R C E 1
C H E C K E R R X
Figura 55. Emulação do DUV do modelo de referência RX hierárquico
Driver
Driver
REFMOD2_MUX
Monitor
Monitor
Monitor
Actor
Actor
Actor
C H E C K E R MUX
S O U R C E 2
REFMOD_MUX
Figura 56. Emulação do DUV do modelo de referência MUX hierárquico
Driver REFMOD2_LIN2AXI Monitor
REFMOD_LIN2AXI
Monitor
Actor
S O U R C E 3
C H E C K E R L I N2AX I
Actor
Figura 57. Emulação do DUV do modelo de referência LIN2AXI hierárquico
104
Driver REFMOD2_AXI2LIN Monitor
Actor
Actor
REFMOD_AXI2LIN
S O U R C E 4
C H E C K E R AX I 2L I N
Monitor
Monitor
Actor
Figura 58. Emulação do DUV do Modelo de Referência AXI2LIN Hierárquico
Driver
Driver
REFMOD2_CHECKSUM
Monitor
Monitor
REFMOD_CHECKSUM
Actor
Monitor
Actor
Actor
Actor
S O U R C E 5
C H E C K E R C HECKSUM
Monitor
Figura 59. Emulação do DUV do modelo de referência CHECKSUM hierárquico
Driver
Driver
REFMOD2_TX
Monitor
Monitor
Monitor
actor
actor
REFMOD_TX
S O U R C E 6
C H E C K E R T X
Figura 60. Emulação do DUV do modelo de referência RX hierárquico
105
A Etapa 3.3 ilustrada na Figura 61 à Figura 66, repete parte da estrutura descrita na Etapa
3.2, contudo o RTL é testado sem a necessidade dos blocos que convertem transação em sinais.
Driver DUV_RX Monitor
Actor
REFMOD_RX
S O U R C E 1
C H E C K E R R X
Figura 61. DUV hierárquico do modelo de referência RX
Driver
Driver
DUV_MUX
Monitor
Actor
C H E C K E R MUX
S O U R C E 2
REFMOD_MUX
Figura 62. DUV hierárquico do modelo de referência MUX
106
Driver DUV_LIN2AXI
REFMOD_LIN2AXI
Monitor
S O U R C E 3
C H E C K E R L I N2AX I
Actor
Figura 63. DUV hierárquico do modelo de referência LIN2AXI
Driver DUV_AXI2LIN
Actor
REFMOD_AXI2LIN
S O U R C E 4
C H E C K E R AX I 2L I N
Monitor
Monitor
Actor
Figura 64. DUV hierárquico do modelo de referência AXI2LIN
Driver
Driver
DUV_CHECKSUM
REFMOD_CHECKSUM
Actor
Monitor
Actor
S O U R C E 5
C H E C K E R C HECKSUM
Monitor
Figura 65. DUV Hierárquico do modelo de referência CHECKSUM
107
Driver
Driver
DUV_TX Monitor
REFMOD_TX
S O U R C E 6
C H E C K E R T X
Figura 66. DUV Hierárquico do Modelo de Referência TX.
A Etapa 4.0 (Figura 67) consiste na integração do DUV ao testbench, sendo, portanto a
etapa final da verificação funcional. O amplo reaproveitamento dos módulos trabalhados nas etapas
anteriores e a abordagem top-down possibilita que essa etapa encontre possíveis erros não
detectados nas etapas anteriores.
Driver
LIN_HW
Actor
Driver Monitor
REFMOD_LIN
S O U R C E
C H E C K E R
Monitor
Figura 67. Verificação Funcional do LIN HW
Etapas de Síntese
Concluída a etapa de verificação, o LIN HW segue para a etapa de Síntese Lógica a fim de
transformar o RTL para uma tecnologia específica de portas lógicas, no caso XFAB .35. Com o
resultado da etapa anterior, o LIN HW passa pela etapa de Síntese Física.
108
A Síntese Física por sua vez é dividida em cinco etapas antes da criação do GDSII33
, são
elas:
1. Floor Planning: etapa que determina o tamanho do DIE, cria os limites do núcleo e as
trilhas para a colocação das células;
2. Placement: etapa que configura as direções para a ferramenta de roteamento, além de
configurar a porcentagem de uso e espaço livre do chip;
3. Clock Tree: distribuição dos sinais de clocks;
4. Routing: interconexão entre os vários componentes e as diferentes camadas do Die.
Na etapa de Placement do LIN HW os PADS, as interconexões de alimentação e a lógica
são distribuídos na área do chip, como ilustrado na Figura 68.
Figura 68. Síntese Física – Distribuição da lógica na etapa de placement
33
Formato de arquivo utilizado pela indústria de semicondutores para representar circuitos integrados ou leiaute de
circuitos integrados.
109
A Figura 69 ilustra a etapa de distribuição do clock (Clock Tree) do LIN HW.
Figura 69. Síntese física – Clock Tree do LIN HW
110
APÊNDICE B ESTÍMULOS GERADOS
Os quadros abaixo ilustram a solução em SystemVerilog encontrada para a emulação do
cabeçalho LIN no LIN HW TESTBENCH.
rand shortint break_field;constraint setbreak { break_field inside {
16'b1111_1100_0000_0000, //10 BITS EM ZERO
16'b1111_1000_0000_0000, //11
16'b1111_0000_0000_0000, //12
16'b1110_0000_0000_0000, //13
16'b1100_0000_0000_0000 };}
Quadro 4. Descrição do campo de parada em SystemVerilog.
byte synch = 8'b01010101;
Quadro 5. Descrição do campo de sincronismo em SystemVerilog.
bit [0:8][7:0] msg_scheduler = '{ 8'h92, 8'h61, 8'hC4, 8'hC1, 8'h80, 8'hB1, 8'h78, 8'h7D, 8'h3C};
Quadro 6. Descrição do campo de sincronismo em SystemVerilog.
111
ANEXO A – REVISÃO SISTEMÁTICA – PROTOCOLO DE
BUSCA
- REVISÃO SISTEMÁTICA -
PROTOCOLO DE BUSCA
UNIVALI
MCA – Mestrado em Computação Aplicada
Mestrando: Rodrigo Pereira
Orientador: Prof.Dr.Eng.Cesar Albenes Zeferino
A presente revisão sistemática é um estudo secundário que utiliza uma metodologia
definida, identificando, analisando e interpretando as evidências disponíveis relacionadas a uma
pergunta de pesquisa específica, evitando viés (tendência) e permitindo certo grau de reprodução da
pesquisa.
1. PLANEJAMENTO
1.1. IDENTIFICAÇÃO DA NECESSIDADE DA REVISÃO:
OBJETIVO DA REVISÃO
OBJETIVO
“O objetivo desta revisão é um estudo da análise das técnicas e tecnologias de
desenvolvimento e métricas de avaliação utilizadas na implementação em software e
em hardware de protocolos de comunicação, em especial o protocolo automotivo
LIN.”
Conforme proposto por Sampaio e Mancini (2006) uma boa revisão sistemática requer uma
pergunta de pesquisa ou questão bem formulada e clara.
PERGUNTA DE PESQUISA
Observando métricas de avaliação como throughput, área de cilício e frequência de
operação, o desenvolvimento das camadas de transporte e de enlace do protocolo LIN
em software utilizando NiosII e em hardware descrito em RTL possuem diferenças?
AS FONTES PARA IDENTIFICAR ESTUDOS PRIMÁRIOS E OS CRITÉRIOS PARA
INCLUSÃO E EXCLUSÃO DAS MESMAS.
112
As fontes usadas serão artigos publicados em congressos, dissertações mestrado, teses de
doutorado, periódicos e dados oriundos da indústria tais como application note e folha de dados.
Serão incluídos os documentos que respondam a pergunta de pesquisa e estejam relacionados à
implementação em software e hardware, sistemas automotivos, processadores embarcados,
metodologia de projeto de soft-IP e o protocolo LIN.
CRITÉRIOS USADOS PARA AVALIAR A QUALIDADE DOS ESTUDOS PRIMÁRIOS
Os critérios usados para avaliar a qualidade dos estudos primários estão relacionados com a
relevância da publicação, a metodologia utilizada, a abrangência dos resultados obtidos, os critérios
de avaliação dos resultados obtidos, o acesso aos códigos fontes e a base de dados (no caso do
protocolo LIN, entendesse como base de dados às mensagens utilizadas). Estes critérios serão
medidos pelo número de citações de outros autores, precedência no site de busca, o uso da
metodologia de projeto OVM ou BVM bem como o uso de linguagem RTL.
APLICAÇÃO DOS CRITÉRIOS DE QUALIDADE
Serão considerados critérios de qualidade a uniformidade, o impacto e a relevância dos
dados obtidos, bem como se os resultados podem ser reproduzidos e analisados utilizando métodos
estatísticos. É o caso da descrição de um IP, cuja versão da ferramenta de síntese está descrita, bem
como a descrição detalhada dos critérios de análise e suas unidades de medidas.
EXTRAÇÃO DOS DADOS DOS ESTUDOS PRIMÁRIOS
Serão selecionados os dados que respondam diretamente a pergunta de pesquisa, ou os
dados que estejam relacionados à implementação em software e hardware, sistemas automotivos,
processadores embarcados, metodologia de projeto de soft-IP e o protocolo LIN.
SINTETIZE DOS DADOS EXTRAÍDOS
Será utilizada uma síntese quantitativa que inclui um método estatístico (meta análise).
Dados como frequência de operação, throughput e área de cilício serão comparados analisando os
resultados das sínteses do compilador QuartusII na mesma versão utilizada pela fonte dos dados,
bem como será feito um análise do percentual comparativo entre as duas fontes de dados,
estabelecendo assim uma ordem de grandeza entre as fontes.
113
TRATAMENTO DAS DIFERENÇAS ENTRE OS ESTUDOS INVESTIGADOS
Devido a modularidade do projeto proposto, serão analisados somente os aspectos referentes
aos módulos do projeto, como exemplo: em um estudo que aborda um IP para tecnologia bluetooth,
serão comparadas a metodologia de verificação adotada e os critérios de avaliação do IP, contudo
aspectos como througthput, área de cilício e frequência de operação não serão considerados
relevantes para o estudo.
COMBINAÇÃO DOS DADOS
Os dados das sínteses podem ser combinados caso tenham sido obtidos utilizando os
resultados de sínteses do mesmo compilador e mesma família de FPGA
Os dados da metodologia podem ser combinados se utilizarem a metodologia BVM ou
OVM.
A COMBINAÇÃO DOS ESTUDOS
Os estudos podem ser combinados ambos abordem implementação em software utilizando
Nios II e implementação em Hardware utilizando linguagem de descrição de hardware.
CONCLUSÕES A PARTIR DAS EVIDÊNCIAS
1.2. ESPECIFICAÇÃO DAS PERGUNTAS DE PESQUISA:
1.2.1. Existem trabalhos abordando desenvolvimento de IPs em software utilizando Nios II
e em hardware utilizando linguagem de descrição de hardware (descrito em RTL)?
1.2.2. Como é possível comparar o desenvolvimento de uma aplicação que utiliza Nios II e
uma mesma aplicação descrita em RTL?
1.2.3. Considerando duas abordagens de desenvolvimento de sistemas embarcados, uma
em software e outra em hardware, quais são as métricas utilizadas para a análise?
1.2.4. Qual a linguagem de programação utilizada no Nios II? E em hardware?
1.2.5. Considerando duas abordagens de desenvolvimento de sistemas embarcados, existe
alguma metodologia de desenvolvimento de soft - core disponível na literatura?
1.2.6. Quais são as técnicas utilizadas para garantir a correta codificação do problema
proposto?
1.2.7. Quais foram as ferramentas utilizadas para: codificação e verificação do sistema e
aquisição dos resultados?
1.2.8. Algum trabalho utilizou hardware dedicado?
1.2.9. Algum trabalho utilizou processador embarcado? Se sim, qual processador e qual a
metodologia utilizada?
1.2.10. Qual foi o protocolo de comunicação alvo?
1.2.11. Quais foram as camadas implementadas em hardware e em software?
114
1.3. DESENVOLVIMENTO DO PROTOCOLO DE REVISÃO
1.3.1. ESTRATÉGIA DE BUSCA: TERMOS E FONTES
FONTES DE PESQUISA
Sites:
IEEExplore - http://ieeexplore.ieee.org
ACM Digital library - http://portal.acm.org
SpringerLink - http://www.springerlink.com
Google scholar - http://scholar.google.com
Cappes - http://servicos.capes.gov.br/capesdw/
UNICAMP - http://libdigi.unicamp.br/document/list.php?tid=7
USP - http://www.teses.usp.br/
TERMOS DE BUSCA UTILIZADOS
Como strings de buscas será utilizado a string AND e OR ex. (Automotive AND Software)
OR (Automotive AND Hardware AND LIN) e dependendo da fonte utilizada será necessário a
adaptação dos termos de pesquisa ao idioma local.
A ferramenta Harzing’s Publish or Perish possui mecanismos e termos próprios de busca os
quais estabelecem indicadores estatísticos das áreas de pesquisa de interesse. A revisão também
deve abranger termos de pesquisa relacionados aos diversos protocolos de comunicação existentes,
bem como termos automotivos e relacionados ao desenvolvimento de sistemas embarcados
utilizando FPGA, a seguir são listados alguns termos relevantes:
Área Automotiva: LIN, CAN, bus, reliability, automotive protocol, serial protocol;
Área de Sistemas Embarcados: Software, hardware, Intelectual property, verilog, layers,
methodology;
Protocolos de comunicação: RS-232, UART, TCP/IP.
1.3.2. PROCEDIMENTOS E CRITÉRIOS DE SELEÇÃO DOS ESTUDOS
(FILTRAGEM)
i. Pela análise do título do trabalho, considerando a similaridade com tema da
pesquisa;
ii. Pela análise do resumo do trabalho, considerando a similaridade com o tema da
pesquisa;
iii. Pelas conclusões do trabalho;
iv. Pela análise total do trabalho;
v. Pela relevância/abrangência do trabalho;
115
vi. Linguagem de programação utilizada;
vii. Pela metodologia utilizada no trabalho;
viii. Pelas fontes utilizadas (periódico, conferência,etc);
ix. Pela data de publicação;
x. Pelo projeto de pesquisa; e
xi. Pelo método de amostragem.
1.3.3. CHECKLISTS PARA AVALIAÇÃO DA QUALIDADE DOS ESTUDOS
– Projeto
Os objetivos estão bem definidos?
A delimitação do projeto está bem definida?
As medidas utilizadas permitem responder às questões?
Foram encontrados trabalhos com o mesmo contexto da pesquisa?
– Condução
Ocorreram eventos negativos durante o estudo?
Os métodos de coleta foram adequadamente descritos?
Algum trabalho coletado possui dados incompletos?
– Análise
Qual foi a taxa de respostas de estudo similares (busca/estudos similares)?
Os dados coletados podem ser comparados entre eles?
Qual o método estatístico utilizado para analisar os dados?
Os dados coletados respondem as questões de pesquisa?
Os dados coletados utilizaram as mesmas ferramentas de hardware?
Experimentos
Alguma pesquisa utilizou experimentos que possam ser reproduzido?
Existe algum modelo de referência da pesquisa?
1.3.4. ESTRATÉGIA DE EXTRAÇÃO DOS DADOS
Como a informação de cada estudo primário será obtida?
A extração dos dados foi uniforme ou é necessária alguma manipulação dos dados?
Existem premissas ou inferências a serem feitas?
Como validar?
1.3.5. SÍNTESE DOS DADOS EXTRAÍDOS
Será utilizada alguma técnica estatística para a extração dos dados?
1.4. AVALIAÇÃO DO PROTOCOLO DE REVISÃO
116
O protocolo será revisado por mais de um especialista e sendo que pelo menos um não pode
estar envolvido na atividade de elaboração da revisão. Como se trata de um trabalho acadêmico, o
referido protocolo também será revisado pelo professor orientado.
O revisor deve se ater a:
- Se os termos de pesquisa são derivados das pergunta de pesquisa?
Os dados a serem extraídos irão endereçar as perguntas de pesquisa?
-O procedimento de análise de dados é adequado para responder as perguntas de
pesquisa?
117
ANEXO B – PROGRAMAÇÃO DO TEMPORIZADOR E DA
INTERRUPÇÃO DO SINAL RX
#include <stdio.h>
#include "system.h"
#include "altera_avalon_pio_regs.h"
#include "altera_avalon_timer_regs.h"
#include "sys/alt_irq.h"
#include "alt_types.h"
alt_u8 x;
int main()
{
printf("[main]\n");
init_timer_interrupts();
while(1){
IOWR_ALTERA_AVALON_PIO_DATA(I_PIO_BASE, x);
}
return 0;
}
/******************************************************************
* static void handle_button_interrupts( void* context, alt_u32 id)*
* *
* Handle interrupts for the timer. *
/*****************************************************************/
void init_timer_interrupts()
{
alt_irq_register(TIMER_IRQ, 0, handle_timer_interrupts);
IOWR_ALTERA_AVALON_TIMER_PERIODL(TIMER_BASE, 0x1F40);// timer interrupt period is 100us
IOWR_ALTERA_AVALON_TIMER_PERIODH(TIMER_BASE, 0x00);
IOWR_ALTERA_AVALON_TIMER_CONTROL(TIMER_BASE, 7);
}
static void handle_timer_interrupts(void* context, alt_u32 id)
{
IOWR_ALTERA_AVALON_TIMER_STATUS(TIMER_BASE, 0);
x = x ^ 0xFF;
}
Quadro 7. Código-fonte do temporizador do Nios II
118
Quadro 8. Código interrupção dos PIOs do Nios II
#include <stdio.h>#include "system.h"
#include "altera_avalon_pio_regs.h"
#include "sys/alt_irq.h"
#include "alt_types.h"
#include "parameter.h"
volatile alt_u8 flag =0;
volatile alt_u8 x;
volatile int edge_capture;
int main()
{
printf("[main] interrupt\n");
init_pio_interrupts();
while(1){}
return 0;
}
/******************************************************************
* static void handle_button_interrupts( void* context, alt_u32 id)*
* *
******************************************************************/
void handle_button_interrupts(void* context, alt_u32 id)
{
/* Cast context to edge_capture's type. It is important that this be
* declared volatile to avoid unwanted compiler optimization.*/
volatile int* edge_capture_ptr = (volatile int*) context;
/* Store the value in the Button's edge capture register in *context. */
*edge_capture_ptr = IORD_ALTERA_AVALON_PIO_EDGE_CAP(I_RX_BASE);
// Reset the Button edge capture register.
IOWR_ALTERA_AVALON_PIO_EDGE_CAP(I_RX_BASE, 0x0);
//IOWR_ALTERA_AVALON_PIO_IRQ_MASK(I_RX_BASE, 0x1);
flag = 1;
}
/* Initialize the pio. */
void init_pio_interrupts()
{
/* Recast the edge_capture pointer to match the alt_irq_register() function
* prototype. */
void* edge_capture_ptr = (void*) &edge_capture;
/* Enable first four interrupts. */
IOWR_ALTERA_AVALON_PIO_IRQ_MASK(I_RX_BASE, 0x1);
/* Reset the edge capture register. */
IOWR_ALTERA_AVALON_PIO_EDGE_CAP(I_RX_BASE, 0x0);
//data = IORD_ALTERA_AVALON_PIO_EDGE_CAP(I_PIO_BASE);
/* Register the interrupt handler. */
alt_irq_register(I_RX_IRQ,
edge_capture_ptr,
handle_button_interrupts );
}
As emissões de carbono geradas durante esse trabalho foram neutralizadas com o plantio de
mudas nativas de árvores na comunidade da Caieira da Barra do Sul, Florianópolis.