Etapa 1

A primeira etapa foi a especificação dos registradores, mapeamento dos registradores internos e do protocolo de comunicação simplificado. A declaração dos registradores e do

Capítulo 7. Experimentos e Resultados 154

Figura 62 – Tela da ferramenta TDevCGen com o detalhes de uma especificação em TDevC

1 ...

g l o b a l s t a t e {

3 o r t h o r e g i o n phy {

i n i t i a l s t a t e PH YDN {

5 a d d e x i t p o i n t ( PH YUP ) { wr ite ( GPR . P HYP D ) == 0} }

7 st ate SW RST {

a d d e n t r y p o i n t { wri te ( NCR . RST ) == 1}

9 }

st ate PH YUP {

11 a d d e x i t p o i n t ( PH YDN ) { wr ite ( GPR . P HYP D ) == 1}

}

13 }

a d d p r o p e r t y ( c r i t i c a l ) n o A c c e s s R S T {

15 ltlf ( [] ( S WRS T -> (~ read ( any ) && ~ wri te ( any ) ) ) ) }

17 } ...

Figura 63 – FSM-Monitor especificada para a etapa 1 do primeiro experimento

mapeamentos podem ser vistas no Apêndice B. Por uma questão de organização deste capítulo, serão apresentados aqui apenas as especificações dos protocolos de comunicação, uma vez que a seção de interface da TDevC para este experimento é grande e sua apresentação neste capítulo tornaria a visualização dos experimento mais complexa.

A Figura 63 mostra uma declaração do protocolo de comunicação do controlador do DM9000A. É possível perceber que esta declaração é composta do estado global na Figura 63-linha 2, por uma região ortogonal phy na Figura 63-linha 3 e mais três estados: o

Capítulo 7. Experimentos e Resultados 155 PHYUP OR: phy PHYDN SwRst Global State noAccessRST

Figura 64 – Representação gráfica da FSM-Monitor especificada para a etapa 1 do primeiro experimento

PHYDN (Figura 63-linha 4), representando o estado do dispositivo em que o módulo PHY está desligado, o PHYUP (Figura 63-linha 10), representando o estado do dispositivo em que o módulo PHY está ligado, e o SWRST (Figura 63-linha 7), representando o estado do dispositivo após a ocorrência de um reset de software.

De acordo com o datasheet do controlador DM9000A, quando o dispositivo é inicializado, o estado inicial do módulo PHY é o estado de desligado. Assim, como pode ser visto na Figura 63-linha 4, o estado PHYDN é o o estado inicial da região ortogonal phy.

Para que o módulo PHY seja ligado, o driver deve escrever no registrador General

Purpose Register (GPR), mais especificamente no campo PHYDN (bit 0), o valor 0 (zero).

Esta transição do estado de desligado (PHYDN) para o estado de ligado (PHYUP) foi declarada na especificação e pode ser vista na Figura 63-linha 5.

Já a transição do estado de ligado para o estado de desligado acontece quando o driver escreve no registrador General Purpose Register (GPR), mais especificamente no campo

PHYDN (bit 0), o valor 1 (um). Esta transição foi declarada na especificação e pode ser

vista na Figura 63-linha 11.

Na Figura 63-linha 8 há declaração de uma transição do tipo entrypoint, especificada dentro da declaração do estado SWRST. Esta transição ocorre sempre que driver escreve no registrador Network Control Register (NCR), mais especificamente no campo RST (bit 0), o valor 1 (um). Como já mencionando no Capítulo 6, esta transição será convertida em transições com origem em todos os outros estados da região ortogonal phy e com destino o estado SWRST.

Também é possível ver na especificação mostrada na Figura 63-linha 14 a declaração de uma restrição crítica de uso do protocolo, chamada de noAccessRST. De acordo com o manual de uso fornecido pelo fabricante do controlado DM9000A, sempre que o dispositivo entrar em um estado de reset não é permitido a realização de escritas ou leituras de dados no dispositivo, até que o mesmo volte ao estado de desligado. Em outros palavras, sempre que o dispositivo estiver no estado de reset (SWRST ), a escrita ou leitura de qualquer valor em seus registradores poderá levar o dispositivo a um estado desconhecido.

Esta restrição foi especificada através da formula LTL "[] (SWRST -> (~read(any)

Capítulo 7. Experimentos e Resultados 156

no estado SWRST implica (SWRST ->) em não haver um leitura em qualquer registrador (~read(any)) e uma escrita em qualquer registrador ~write(any).

A Figura 69 mostra uma representação gráfica da FSM-Monitor especificada na Figura 63. As seta tracejadas representam as transições geradas a partir do entrypoint declarado no estado SWRST.

É possível perceber tanto na Figura 63 quanto na Figura 69 que não há uma transição de saída do estado SWRST. De acordo com o datasheet do controlador, existe uma saída automática (sem a atuação do device driver ) para o estado PHYDN 20 𝜇s após o reset ser realizado. A técnica proposta suporta parcialmente transições e restrições com base em tempo, uma vez que o monitor já possui módulos desenvolvidos para sinalizar eventos temporais. Entretanto, a sintaxe e semântica da linguagem com suporte à especificação destes eventos ainda não foram totalmente finalizadas.

Para que a abordagem aceite totalmente a especificação de transições e restrições temporais, se faz necessária a especificação tanto da sintaxe como da semântica para que haja o mapeamento destas especificações para o módulo já implementado. Dessa maneira, a transição entre o estado SWRST e o PHUDN foi representada na Figura 69 através da seta pontinhada.

Após a especificação o MDDC é gerado e integrado manualmente na plataforma. Esta integração, que pode ser vista através do trecho de código em SystemaVerilog mostrado na Figura 65, é realizada de duas maneiras. A primeira é a através da porta de observação (BSPI), onde são criadas replicações de sinais, como uma espécie de bifurcação em uma trilha de sinais. Esta replicação de informações pode ser vista na Figura 65, da linha 1 à linha 8.

A palavra reservada faz a atribuição de um sinal a outro, criando um trilha conectada ao sinal de origem. Por exemplo, a linha 1 da Figura 65 contém a seguinte linha de código: "as-

sign avalon_bus_address_to_the_MDDC_0 = cpu_0_data_master_address_to_slave;".

Este exemplo resulta em uma atribuição do mesmo valor do sinal cpu_0_data_master_address_to_slave ao sinal avalon_bus_address_to_the_MDDC_0.

Com esta replicação de sinais, é possível então repassá-los para o MDDC. A Figura 65, da linha 10 à linha 31, mostra a instanciação do MDDC e as suas portas de entrada e saída representando sua interface. A porta de observação (BSPI) é composta pelos sinais especificados entre as linhas 12 e 19 da Figura 65. É possível perceber que os sinais atribuidos a esta porta são exatamente os sinais replicados.

A porta de periférico escravo (BSI) é composta pelos sinais especificados entre as linhas 22 e 30 da Figura 65. Os sinais atribuídos a esta interface não são sinais replicados. Eles são sinais criados a partir do barramento diretamente para o MDDC e vice-versa.

Após a integração, é possível então executar a plataforma com o MDDC incluído. Como mencionado anteriormente, a execução da plataforma conta com um 𝜇Clinux rodando no processador NiosII. A Figura 66 mostra um screenshot do 𝜇Clinux sendo executado

Capítulo 7. Experimentos e Resultados 157 a s s i g n a v a l o n _ b u s _ a d d r e s s _ t o _ t h e _ M D D C _ 0 = c p u _ 0 _ d a t a _ m a s t e r _ a d d r e s s _ t o _ s l a v e ; 2 a ss i g n a v a l o n _ b u s _ w r i t e d a t a _ t o _ t h e _ M D D C _ 0 = c p u _ 0 _ d a t a _ m a s t e r _ w r i t e d a t a ; a s s i g n a v a l o n _ b u s _ w r i t e _ t o _ t h e _ M D D C _ 0 = c p u _ 0 _ d a t a _ m a s t e r _ w r i t e ; 4 a ss i g n a v a l o n _ b u s _ r e a d d a t a _ t o _ t h e _ M D D C _ 0 = c p u _ 0 _ d a t a _ m a s t e r _ r e a d d a t a ; a s s i g n a v a l o n _ b u s _ r e a d _ t o _ t h e _ M D D C _ 0 = c p u _ 0 _ d a t a _ m a s t e r _ r e a d ; 6 a ss i g n a v a l o n _ b u s _ w a i t r e q u e s t _ t o _ t h e _ M D D C _ 0 = c p u _ 0 _ d a t a _ m a s t e r _ w a i t r e q u e s t ; a s s i g n a v a l o n _ s l a v e _ 0 _ w a i t _ c o u n t e r _ e q _ 0 _ t o _ t h e _ M D D C _ 0 = D M 9 0 0 0 A _ a v a l o n _ s l a v e _ 0 _ w a i t _ c o u n t e r _ e q _ 0 ; 8 a ss i g n a v a l o n _ s l a v e _ 0 _ w a i t _ c o u n t e r _ e q _ 1 _ t o _ t h e _ M D D C _ 0 = D M 9 0 0 0 A _ a v a l o n _ s l a v e _ 0 _ w a i t _ c o u n t e r _ e q _ 1 ; 10 M DD C _ 0 t h e _ M D D C _ 0 ( 12 . a v a l o n _ b u s _ a d d r e s s ( a v a l o n _ b u s _ a d d r e s s _ t o _ t h e _ M D D C _ 0 ) , . a v a l o n _ b u s _ r e a d ( a v a l o n _ b u s _ r e a d _ t o _ t h e _ M D D C _ 0 ) , 14 . a v a l o n _ b u s _ r e a d d a t a ( a v a l o n _ b u s _ r e a d d a t a _ t o _ t h e _ M D D C _ 0 ) , . a v a l o n _ b u s _ w a i t r e q u e s t ( a v a l o n _ b u s _ w a i t r e q u e s t _ t o _ t h e _ M D D C _ 0 ) , 16 . a v a l o n _ b u s _ w r i t e ( a v a l o n _ b u s _ w r i t e _ t o _ t h e _ M D D C _ 0 ) , . a v a l o n _ b u s _ w r i t e d a t a ( a v a l o n _ b u s _ w r i t e d a t a _ t o _ t h e _ M D D C _ 0 ) , 18 . a v a l o n _ s l a v e _ w a i t _ c o u n t e r _ e q _ 0 ( a v a l o n _ s l a v e _ w a i t _ c o u n t e r _ e q _ 0 _ t o _ t h e _ M D D C _ 0 ) , . a v a l o n _ s l a v e _ w a i t _ c o u n t e r _ e q _ 1 ( a v a l o n _ s l a v e _ w a i t _ c o u n t e r _ e q _ 1 _ t o _ t h e _ M D D C _ 0 ) , 20 . clk ( clk ) , . o p e r M o d e ( o p e r M o d e _ f r o m _ t h e _ M D D C _ 0 ) , 22 . c h i p s e l e c t ( M D D C _ 0 _ a v a l o n _ s l a v e _ 0 _ c h i p s e l e c t ) , . a d d r e s s ( M D D C _ 0 _ a v a l o n _ s l a v e _ 0 _ a d d r e s s ) , 24 . i n t e r r u p t L i n e ( M D D C _ 0 _ a v a l o n _ s l a v e _ 0 _ i r q ) , . p kgC t ( p k g C t _ f r o m _ t h e _ M D D C _ 0 ) , 26 . read ( M D D C _ 0 _ a v a l o n _ s l a v e _ 0 _ r e a d ) , . r e a d d a t a ( M D D C _ 0 _ a v a l o n _ s l a v e _ 0 _ r e a d d a t a ) , 28 . r st_ n ( M D D C _ 0 _ a v a l o n _ s l a v e _ 0 _ r e s e t _ n ) , . w rit e ( M D D C _ 0 _ a v a l o n _ s l a v e _ 0 _ w r i t e ) , 30 . w r i t e d a t a ( M D D C _ 0 _ a v a l o n _ s l a v e _ 0 _ w r i t e d a t a ) ) ;

Figura 65 – Adaptação realizada na plataforma para a integração do Monitor

na plataforma. É possível ver na Figura 66 a inicialização do controlador do dispositivo

DM9000A a partir da segunda até a sexta linha de log do terminal.

Foram realizadas execuções com o MDDC para validar o device driver oficial do do dispositivo DM9000A fornecido pelo kernel linux, versão 2.6. Com a especificação realizada na etapa um deste experimento, nenhuma quebra de restrição foi identificada.

Dessa maneira, por questões de validação da técnica, a restrição foi propositalmente violada. A Figura 67 mostra a função de reset do driver do controlador do DM9000A com a modificação proposital que induz a quebra de restrição de maneira aleatória.

Na Figura 67, das linhas 8 à 15 e a linha 17, estão as modificações realizadas para induzir o erro. Na linhas 8 é atribuído á variável 𝑟 um valor aleatório de um número inteiro positivo. Assim, na linha 10, é verificado se o valor do byte mais significativo deste inteiro é menor do que 50. Se for menor do que 50, o driver executa o reset do dispositivo com a violação da restrição, ou seja, fazendo um acesso ao dispositivo (linha 13) logo após a solicitação de reset (linha 12).

Capítulo 7. Experimentos e Resultados 158

Figura 66 – Screenshot do 𝜇Clinux sendo executado na plataforma

1 d m 9 0 0 0 _ r e s e t ( b o a r d _ i n f o _ t * db ) { 3 int tmp ; d e v _ d b g ( db - > dev , " r e s e t t i n g d e v i c e \ n ") ; 5 /* RES ET d e v i c e */ w r i t e b ( DM9 000 _NC R , db - > i o _ a d d r ) ; 7 u d e l a y (20 0) ; g e t _ r a n d o m _ b y t e s (& r , s i z e o f ( u n s i g n e d int ) ) ; 9 // * * * * * * * Erro i n d u z i d o ! if (( r >> 24) < 50) { 11 p r i n t k (" \ n [ D M 9 0 0 0 A ] Res et F a i l u r e I n d u c e d !\ n ") ; w r i t e b ( NCR_RST , db - > i o _ d a t a ) ; 13 tmp = ior ( db , D M 9 0 0 0 _ N C R ) ; // * * * * * * * * * * * * * * * * * * * * * * * 15 } else { w r i t e b ( NCR_RST , db - > i o _ d a t a ) ; 17 } u d e l a y (20 0) ; 19 }

Figura 67 – Trecho da função de reset alterada do device driver do DM9000A

restrição foi feita também de maneira aleatória. Este valor nada influencia na validação do dispositivo. Ele apenas influencia na chance de que a execução passe por esta condição. Isto apenas acelera ou retarda a chance de que a execução caia neste caso de violação.

Na arquitetura proposta neste experimento, quando há uma violação de restrição, o MDDC envia uma interrupção para o processador NiosII, onde este executa o callback da função de interrupção registrada pelo driver do MDDC. Esta função pode ser vista na Figura 68.

Quando esta função é invocada, ou seja, quando há uma interrupção devido a detecção de uma violação de restrição por parte do MDDC, a função requisita ao dispositivo MDDC qual foi a violação detectada. O monitor então responde a requisição com um identificador do erro, previamente definida no monitor e catalogada no driver do MDDC. A linha 4

Capítulo 7. Experimentos e Resultados 159

1 // D r i v e r MDDC IRQ H a n d l e r f u n c t i o n .

s ta t i c i r q r e t u r n _ t m d d c D r i v e r _ i r q h a n d l e r (int irq , void * d e v _ i d /) {

3 int f a i l u r e = 0;

f a i l u r e = inl ( mddc_ref - > er ror ) ;

5 s wi t c h ( f a i l u r e ) { case M D D C _ F A I L _ N O A C C E S S R S T 7 p r i n t k (" \ n [ MDDC - D r i v e r ] F a i l u r e D e t e c t e d : Re set \ n ") ; break; 9 d e f a u l t: p r i n t k (" \ n [ MDDC - D r i v e r ] U n d e f i n e d F a i l u r e ! \ n ") ; 11 break; } 13 r et u r n I R Q _ H A N D L E D ; }

Figura 68 – Função de tratamento de interrupção do device driver do Monitor para a etapa 1 do primeiro experimento

Figura 69 – Terminal do 𝜇Clinux mostrando a violação e detecção da restrição de reset

da Figura 68 mostra o momento em que o driver solicita o código da violação. A seguir no código da função de tratamento da interrupção, entre as linhas 5 e 12 da Figura 68, é possível ver o bloco condicional que identifica qual o código da violação e efetua a impressão no terminal do linux do texto indicando a violação, como pode ser visto na Figura 67 o texto destacado pela chave.

É importante chamar a atenção para o fato de que são dois componentes isolados que efetuam a impressão dos textos n o terminal. Isso mostra que a ação de impressão do texto realizada pelo driver do MDDC disparada puramente devido a detecção da violação pela porta de observação. A impressão do texto foi apenas uma escolha de reação para que fosse possível visualizar e reportar nesta tese a detecção.

Em testes isolados, sem a necessidade de reportar textualmente a ocorrência da violação, esta abordagem também identificou a violação através de LEDs instalados na placa de prototipação onde a plataforma está sendo executada. Assim, não houve qualquer

Capítulo 7. Experimentos e Resultados 160

Barramento

NiosII uClinux

[DM9000A] lololo Failure Induced! [MDDC_Driver] Failure Detected: lololo />_ Terminal Driver MDDCD * FALHA DETECTADA * Driver DM9000A * FALHA INDUZIDA * MDDC Passo 2 Passo 1 Passo 2 Passo 3 Passo 4 Passo 5 Passo 1 Passo 5

Figura 70 – Sequencia de passos do funcionamento da indução e captura de violações de restrições

interferência de software relativa à checagem do monitor, incluindo a interrupção do MDDC no processador NiosII.

A Figura 70 mostra a dinâmica da utilização do driver do MDDC para imprimir no terminal a mensagem de identificação da violação. A Figura 70 mostra uma arquitetura composta pelo processador NiosII e o MDDC conectados em um barramento. No passo 1 sinalizado na Figura 70 é possível ver que é o exato momento em que o erro induzido ocorre no driver do controlador do DM9000A. Neste mesmo instante há a impressão do texto "[DM9000A] Reset Failure Induced! "no terminal do Linux. Logo em seguida, no passo 2 da Figura 70, o driver do controlador do DM9000A envia a sequencia de comandos indesejados para o dispositivo DM9000A. Automaticamente o MDDC captura esta sequencia de comandos. No passo 3 da Figura 70, o MDDC então identifica a violação e dispara uma interrupção para o processador NiosII. O processador então repassa essa interrupção para o driver do MDDC. No passo 4 da Figura 70, o driver do monitor trata a interrupção requisitando ao MDDC o identificador do erro via porta escrava do monitor. Por fim, no passo 5 da Figura 70, o driver do MDDC, já com a identificação da violação, imprime no terminal do Linux exatamente qual foi esta violação detectada.

Para esta primeira etapa do experimento foi induzida uma violação da restrição

noAccessRST do estado global. A função de reset do driver do controlador DM9000A

é invocada no inicializador do 𝜇Clinux. Dessa maneira o Linux foi inicializado 50 vezes. Dentre estas 50 vezes, o erro ocorreu 23 vezes e a esta violação foi detectada todas as 23 vezes, no momento em que ela ocorreu. É importante destacar que não houveram falsos-positivos, o que significa que o MDDC somente sinalizou a violação quando ela

Capítulo 7. Experimentos e Resultados 161 g l o b a l s t a t e { 2 ... // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * [ LINK MODE ] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 4 o r t h o r e g i o n l i n k s t a t u s { i n i t i a l s t a t e DOWN { 6 a d d e x i t p o i n t ( UP ) { read ( NSR . L I N K S T ) == 1} } 8 st ate UP { a d d e x i t p o i n t ( DOWN ) { read ( NSR . L I N K S T ) == 0} 10 } } 12 // * * * * * * * * * * * * * * * * * * * * * * * * * * * [ OPER MODE ] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * o r t h o r e g i o n o p e r m o d e { 14 i n i t i a l s t a t e U N D E F _ O P E R _ M O D E { a d d e x i t p o i n t ( O P E R 1 6 B I T S ) { read ( ISR . I O M O D E ) == 0} 16 a d d e x i t p o i n t ( O P E R 8 B I T S ) { read ( ISR . I O M O D E ) == 1} a d d e n t r y p o i n t { wri te ( NCR . RST ) == 1} 18 } st ate O P E R 1 6 B I T S { 20 a d d e x i t p o i n t ( O P E R 8 B I T S ) { read ( ISR . I O M O D E ) == 1} } 22 st ate O P E R 8 B I T S { a d d e x i t p o i n t ( O P E R 1 6 B I T S ) { read ( ISR . I O M O D E ) == 0} 24 } } 26 // * * * * * * * * * * * * * * * * * * * * * * * * * * * * [ PHY ] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * o r t h o r e g i o n phy { 28 i n i t i a l s t a t e PH YDN {

a d d e x i t p o i n t ( PH YUP ) { wr ite ( GPR . P HYP D ) == 0}

30 }

st ate SW RST {

32 a d d e n t r y p o i n t { wri te ( NCR . RST ) == 1}

}

34 st ate PH YUP {

a d d e x i t p o i n t ( PH YDN ) { wr ite ( GPR . P HYP D ) == 1}

36 a d d p r o p e r t y ( c r i t i c a l ) U n d e f i n e d O p e r M o d e { ltlf ( []( ~ U N D E F _ O P E R _ M O D E ) ) 38 } } 40 } a d d p r o p e r t y ( c r i t i c a l ) n o A c c e s s R S T {

42 ltlf ( [] ( S WRS T -> (~ read ( any ) && ~ wri te ( any ) ) ) ) }

44 } ...

Figura 71 – FSM-Monitor extraída da especificação em TDevC utilizada na etapa 2 do primeiro experimento

realmente aconteceu.