GAINS AND LOSSES!
3. SIS II Changes: gains and losses
Para que a estrutura da framework fosse o mais modular possível foi necessário dividi-la em vários módulos. Esta divisão tem como objetivo separar as diversas funcionalidades da framework, em módulos independentes e cooperantes entre si de maneira a poderem desempenhar as suas funções. Com esta abordagem é fácil a integração de outros módulos na framework com objetivo de estender as fun- cionalidades da mesma. Além disso, facilita a validação das funcionalidades da
framework, pois permite que o teste dos módulos seja efetuado de forma indepen-
dente.
Alguns dos módulos mais importantes já foram descritos anteriormente, outros serão analisados nesta secção. A figura 3.34 representa o digrama UML seguido pela framework.
Nessa figura não se encontram todos as classes integrantes à arquitetura seguida pela framework, mas sim os mais importantes, pois torna-se impossível representar todas numa só imagem. A arquitetura adotada, segue um padrão de desenho sin-
gleton. A classe CSystem é das classes principais e mais importante da framework,
pois esta serve como ponto de ligação dos vários módulos e permite lançar todos os mecanismos e verificações para que a framework possa correr com normalidade.
O diagrama da figura 3.35 traduz o comportamento da framework no momento de arranque.
Figura 3.35: Diagrama de sequência da inicialização da Framework
Neste momento é necessário que a framework leia e verifique todos os ficheiros presentes no repositório de IP, conseguindo assim identificar os ficheiros válidos a serem inseridos no sistema, este processo de inserção já foi analisado anterior- mente. No caso de serem encontrados erros ao longo do processamento dos ficheiros por parte da framework foi criado um ficheiro de erros que permite ao utilizador identificar todos os IP corrompidos no repositório. Lidos todos os IP presentes no repositório, é enviado um pedido ao módulo da interface gráfica para inicializar os seus módulos e objetos de sincronismo que representam o frontend da framework. Com esta arquitetura facilmente se pode integrar um novo frontend sem ter que se fazer alterações no backend. A ferramenta utilizada para desenvolver o frontend foi o QT Creator.
Além destes módulos descritos fazem também parte da framework as classes CSet- tings, CGeneratorToolChain e CCoSimulation. Esta primeira não é nada mais que uma classe que contém todas as configurações e localizações de todas as ferramen- tas importantes ao bom funcionamento da framework. Estas configurações são extraídas de um ficheiro XML criado para o efeito o que torna mais fácil e prático para o utilizador a edição destas informações, quando necessário. A classe CGe- neratorToolChain, incorpora o módulo TGI que permite aos geradores externos à
lançar os geradores descritos anteriormente de maneira a criar toda a toolchain, necessária ao desenvolvimento de um co-design hardware/software. O mesmo se passa com a classe CCoSimulation que gere todo o processo de verificação do sis- tema a desenvolver.
Capítulo 4
Cenário de Aplicação
Neste capítulo irá ser modelado um cenário de aplicação simples, que irá servir como forma de validação do comportamento da framework. Este sistema irá seguir o design flow suportado pela framework, onde serão analisados os vários passos desse processo e comentados os ficheiros gerados pela framework.
4.1
Modelação do Sistema
Para poder validar o comportamento da framework foi modulado um sistema sim- ples que permite o cálculo da potência ativa e reativa instantânea, baseado na teoria p-q. Esta aplicação consiste na aquisição de valores da rede e do respectivo processamento que permite ao utilizador a consulta das potências instantâneas. A figura 4.1 representa o comportamento da aplicação.
Figura 4.1: Diagrama de blocos da aplicação
Esta aplicação é composta por duas unidades de processamento, uma responsável pelo cálculo das coordenadas α − β-0 através da transformada de Clarke, outra responsável pelo cálculo da potência ativa e reativa instantânea através das coor- denadas α − β-0. Como o intuito desta aplicação é validar o comportamento da
framework, decidiu-se colocar o módulo que permite calcular a transformada de
Clarke em hardware e o módulo que calcula as potências instantâneas em software.
A aplicação segue a arquitetura representada na figura 4.2
Figura 4.2: UML da aplicação de teste
Para poder simular as correntes e tensões lidas da rede, foi criada uma classe CADC que permite emular o comportamento do ADC através da leitura de dados de um ficheiro. A classe CThread_ClarkeTransformHW e CThread_PowerPQSW são as classes geradas pela framework que permitem o interface com os IPs referidos anteriormente. A classe CSystem representa o sistema por completo, como tal foi seguido um padrão singleton para o seu desenho.
4.2
IP-PACKGING
Para que framework possa gerar o sistema proposto é necessário inserir os IPs responsáveis pelo cálculo da transformada de Clarke e potências instantâneas no repositório. Para elucidar este processo será demonstrado o processo de inserção da transformada de Clarke no repositório.
Como foi decidido que este IP iria ser instanciado em hardware no projeto é ne- cessário modelar o seu comportamento em HDL de maneira a este ser compatível
com o barramento virtual QEMU. A figura 4.3 elucida o top-level do hardware-IP desenvolvido e a associação de cada sinal aos sinais lógicos do barramento virtual QEMU.
Figura 4.3: Top level IP core Clarke Transform
O IP é definido por um processo que é constituído por três entradas, três saídas, um sinal de trigger que permite indicar o início do processamento e um sinal ready que indica o fim do processamento, este sinal irá ser também associado ao WENABLE porque também indica que as saídas estão prontas a ser escritas na memória.
Para que o IP fosse o mais optimizado possível a realizar as operações aritméticas assentes no seu processamento, foi decidido introduzir dois IPs-cores do repositório do Vivado IP Catalog, um somador de 32 bits e um multiplicador de 32 bits.
Com a modelação do IP realizada é necessário proceder à sua implementação para isso foi recorreu-se à framework que permite criar um IP from the scratch.
O processo começa por criar uma descrição do IP através do GUI da framework, como representado na figura 4.4. Nesta inserção é necessário introduzir o VLNV, que não pode ser coincidente com o nenhum IP presente no repositório
Figura 4.4: Menu de inserção de um novo IP
Inserido o IP no repositório é necessário introduzir a informação relativa a cada porto constituinte do IP. A figura 4.5 representa a inserção da descrição de um porto relativo ao IP. Nesta etapa é necessário definir o nome do porto, o tipo de porto, e o tamanho. Para além dessa descrição foi acrescentado um outro campo
que tem como objetivo definir o tipo variável associado ao porto caso este seja instanciado em software.
Figura 4.5: Menu de inserção da informação de um porto
Inserida a informação de todos os portos do IP na framework, é necessário definir que o IP é compatível com o barramento virtual QEMU. Para isso é necessário criar um interface denominado de QEMU_BUS e associar a esse interface o modelo que descreve esse barramento. Na descrição desse interface é necessário definir o número de processos, interrupções e o espaço de memória alocado que representa o número de bytes necessários para guardar os dados de saída e entrada do IP. Posto isto, é necessário associar os portos do IP aos portos lógicos do barramento virtual QEMU. Ao fazer essa associação é necessário especificar o offset de cada sinal de dados para que possam ser mapeados na memória. É obrigatório que os
offsets dos sinais de dados de saída e entrada sejam consecutivos. Este processo é
representado pela figura 4.6
Neste momento é possível gerar os ficheiros onde se define o comportamento do IP, tanto em software como hardware através da framework. A figura 4.7 apresenta os ficheiros gerados. Na imagem do lado esquerdo é representado o código Verilog gerado pela framework, onde define o módulo do IP e as suas entradas e saídas,
Figura 4.6: Menu de inserção do interface QEMU_BUS
sendo necessário introduzir o comportamento em Verilog do IP no ficheiro. Na imagem do lado direito é representada a função gerada pela framework onde é possível introduzir o comportamento em software do IP, assim como a informação relativa à estrutura de dados que permite o acesso aos portos do IP. Para que o modelo descritivo do IP possa referenciar estes ficheiros, foi acrescentado de uma forma automática pela framework um fileset que referencia cada um dos comportamentos ao modelo descritivo IP-XACT.
Como foi referido anteriormente o IP da transformada de Clarke usa dois IPs-cores que fazem parte do Vivado IP Catalog, sendo assim necessário associar os ficheiros que definem as configurações desses IPs à descrição criada. Para isso é necessário, acrescentar ao fileset que define o comportamento HDL do IP, esse dois ficheiros como elucida a figura 4.8.
Figura 4.8: Menu de inserção de filesets da framework
Como resultado final desta inserção foi criado um ficheiro XML que descreve o IP respeitando as normas impostas pelo standard IP-XACT. Partes desse ficheiro gerado estão representadas no apêndiceE.
4.3
Design
A próxima etapa no desenvolvimento do sistema proposto é construir um design com as especificações acima descritas. Para esse efeito recorreu-se à framework, para que esta possa gerar todos os ficheiros e configurações necessárias à imple- mentação do sistema proposto.
A figura 4.9 apresenta o interface proporcionado pela framework que permite a criação desse mesmo design.
Figura 4.9: Menu de criação de um projeto
Neste menu é possível especificar quais os IPs presentes no repositório que integram o design, podendo definir o seu modo de instanciação em hardware ou software. Se for instanciado em hardware é necessário definir o endereço de memória em que este está mapeado e o número de interrupção. Neste caso foi instanciado a transformada de Clarke em hardware e o cálculo das potências em software. Além disso é possível especificar a board para ser possível criar toda toolchain necessária à realização do design. Foi escolhida uma board suportada pelo QEMU para ser possível realizar a co-simulação. Por último o utilizador pode selecionar o dispositivo FPGA e a diretoria de output do design.
Especificadas todas as definições do design a framework é capaz de gerar todos os ficheiros e configurações necessários à sua realização. O menu da figura 4.10 apresenta o estado dessa geração ao programador.
Criada toda a toolchain estão reunidas todas as condições para a implementação do sistema proposto. De seguida serão analisados alguns ficheiros gerados pela
framework.
O primeiro ficheiro a ser analisado é o warraper gerado pela framework que permite a comunicação do IP da transformada de Clarke com o barramento virtual QEMU. O código gerado pela framework encontra-se presente na figura 4.11.
Nessa figura é possível observar a instanciação do IP da transformada de Clarke, assim como a declaração de todos os sinais necessários à ligação do IP aos sinais
Figura 4.10: Menu de estado de geração de toda a toolchain
Figura 4.11: Código verilog gerado pela framework no wrapper que permite a ligação do IP ao barramento virtual QEMU
do wrapper. As atribuições geradas pela framework aos sinais de dados do IP permitem mapear esses mesmos dados de entrada e saída na memória do wrapper para que possam ser acedidos pelo device driver. As restantes atribuições permitem associar os sinais de controlo do IP aos sinais do wrapper que fazem a gestão de acesso do barramento virtual QEMU ao IP.
O próximo ficheiro a ser analisado é o Tcl script gerado pela framework para a criação do projeto de hardware, esse ficheiro encontra-se representado abaixo.
1 set o u t p u t D i r / h o m e / c e s a r / t e s e r e p o s / p q A n a l y s e r / HDL / V I V A D O 2 set R e p o s i t o r y D i r / h o m e / c e s a r / t e s e r e p o s / c e s a r / c e s a r / F r a m e w o r k / R e p o s i t o r y / c o m p o n e n t 3 f i l e m k d i r $ o u t p u t D i r 4 c r e a t e _ p r o j e c t p q A n a l y s e r $ o u t p u t D i r - p a r t xc 7z 0 10 - clg225 -1 - f o r c e 5 set p r o j _ d i r [ g e t _ p r o p e r t y d i r e c t o r y [ c u r r e n t _ p r o j e c t ]] 6 a d d _ f i l e s $ R e p o s i t o r y D i r / c l a r k e T r a n s f o r m _ v 1 _ 0 / HDL / c l a r k e T r a n s f o r m . v 7 a d d _ f i l e s $ R e p o s i t o r y D i r / c l a r k e T r a n s f o r m _ v 1 _ 0 / HDL / a d d s u b . xci 8 a d d _ f i l e s $ R e p o s i t o r y D i r / c l a r k e T r a n s f o r m _ v 1 _ 0 / HDL / m u l t i p l i e r . xci 9 a d d _ f i l e s - f i l e s e t s i m _ 1 - n o r e c u r s e / h o m e / c e s a r / t e s e r e p o s / p q _ A n a l y s e r / HDL / V I V A D O / t e m p / c l a r k e t r a n s f o r m H W . v 10 a d d _ f i l e s - f i l e s e t s i m _ 1 - n o r e c u r s e / h o m e / c e s a r / t e s e r e p o s / p q _ A n a l y s e r / HDL / V I V A D O / t e m p / m a s t e r _ t b . v 11 i m p o r t _ f i l e s - f o r c e - n o r e c u r s e 12 s e t _ p r o p e r t y top m a s t e r _ t b [ g e t _ f i l e s e t s s i m _ 1 ] 13 u p d a t e _ c o m p i l e _ o r d e r - f i l e s e t s i m _ 1 14 u p g r a d e _ i p [ g e t _ i p s *] 15 s e t _ p r o p e r t y s i m u l a t o r _ l a n g u a g e M i x e d [ c u r r e n t _ p r o j e c t ] 16 s e t _ p r o p e r t y t a r g e t _ s i m u l a t o r M o d e l S i m [ c u r r e n t _ p r o j e c t ] 17 set m o d e l S i m L i b O u t $ p r o j _ d i r /[ c u r r e n t _ p r o j e c t ]. c a c h e / c o m p i l e _ s i m l i b 18 set m o d e l S i m L i b P a t h / h o m e / c e s a r / X i l i n x / m o d e l t e c h / l i n u x _ x 8 6 _ 6 4 19 c o m p i l e _ s i m l i b - l a n g u a g e all - dir $ m o d e l S i m L i b O u t - s i m u l a t o r m o d e l s i m - s i m u l a t o r _ e x e c _ p a t h $ m o d e l S i m L i b P a t h - l i b r a r y all - f a m i l y all 20 s e t _ p r o p e r t y - n a m e { m o d e l s i m . s i m u l a t e . v s i m . m o r e _ o p t i o n s } - v a l u e { - pli / h o m e / c e s a r / t e s e r e p o s / c e s a r / c e s a r / F r a m e w o r k / S e t t i n g s / vpi . so } - o b j e c t s [ c u r r e n t _ f i l e s e t - s i m s e t ] 21 q u i t
Os comandos gerados, permitem a criação e configuração do projeto especificado. O script começa pela criação do projeto especificando o nome do projeto e dispo- sitivo FPGA escolhido. De seguida são adicionados e copiados para a pasta do projeto todos os ficheiros integrantes do projeto de acordo com as especificações escolhidas. Para finalizar é configurado o ModelSim como simulador de HDL.
O próximo ficheiro a ser analisado é o do device driver gerado para que hard-
ware delegate thread possa ter acesso aos dados do IP.Mais abaixo encontra-se
representado excerto de código gerado pela framework.
1 # d e f i n e D E V I C E _ N A M E " c l a r k e t r a n s f o r m H W "
2 # d e f i n e C L A S S _ N A M E " hw - ip - c l a r k e t r a n s f o r m H W "
4 # d e f i n e M A P P E D _ B L O C K _ S I Z E 26 5 # d e f i n e S E T _ H W P R O C 0 6 # d e f i n e N U M B E R _ O F _ P R O C E S S E S 1 7 8 // P R O C E S S 0 9 # d e f i n e I N T E R R U P T _ 0 40 10 # d e f i n e R E A D _ O F F S E T _ 0 5 11 # d e f i n e W R I T E _ O F F S E T _ 0 2 12 13 t y p e d e f s t r u c t h w _ p r o c e s s 14 { 15 int irq ; 16 u i n t 8 _ t r e a d y ; 17 int r e a d _ o f f s e t ; 18 int w r i t e _ o f f s e t ; 19 int s t a r t _ o f f s e t ; 20 int i r q _ o f f s e t ; 21 s t r u c t m u t e x m u t e x ; 22 w a i t _ q u e u e _ h e a d _ t r e a d _ q u e u e ; 23 } h w _ p r o c e s s ; 24 25 s t a t i c h w _ p r o c e s s p r o c e s s e s [ N U M B E R _ O F _ P R O C E S S E S ] = 26 { 27 // P R O C E S S 0 28 { 29 . irq = I N T E R R U P T _ 0 , 30 . r e a d _ o f f s e t = R E A D _ O F F S E T _ 0 , 31 . w r i t e _ o f f s e t = W R I T E _ O F F S E T _ 0 32 } 33 // P U T _ H E R E _ P R O C E S S _ I N S T A N C E 34 };
Neste excerto de código é possível observar as configurações gerais do device driver. É possível identificar que o número da interrupção é diferente do número inicial, aquando da configuração do projeto. Isto acontece devido ao QEMU acrescentar um offset ao número real de cada interrupção presente no processador escolhido. A estrutura de dados definida, referencia as informações relevantes de cada processo do IP e mecanismos que permitem a gestão de acessos ao IP definido em hardware. Como os sinais de dados de entrada e saída de cada processo estão mapeados de forma seguida na memória é possível definir no código o offset mínimo de leitura e escrita de dados para cada processo, sendo assim, possível fazer as transações de dados entre o IP e o device driver de uma forma mais eficiente.
Na figura 4.12 são apresentadas as duas threads geradas pela framework.
A thread do lado esquerdo referencia a hardware delegate thread que unicamente delega funções de escrita e leitura que permitem a escrita no device driver res- ponsável pela comunicação com o IP da transformada de Clarke, já explicadas
Figura 4.12: Threads geradas pela framework
no capítulo anterior. O que faz com que seja possível a troca de dados entre a componente de hardware e software do sistema de uma maneira transparente ao utilizador. A thread do lado direito diz respeito à thread de software que invoca o comportamento do IP responsável pelo cálculo das potências instantâneas em software. Estas duas threads seguem o modelo de threads seguido pela framework, o que faz com que o o interface e o corpo da mesma seja semelhante.
Para finalizar é apresentado o ficheiro XML gerado pela framework que permite descrever o design, de acordo com as normas definidas no standard IP-XACT. Este ficheiro descreve em que moldes estão os IPs instanciados e encontra-se represen- tado no apêndiceE.
4.4
Verificação
Criada toda a toolchain necessária à realização do sistema proposto é possível a implementação desse mesmo sistema. Isto leva a que seja necessário validar as componentes de software e hardware de uma forma conjunta. Para isso recorreu- se à ferramenta da framework que permite uma co-verificação do sistema. Esta ferramenta, possui um interface que permite ao utilizador abrir um projeto criado pela framework a qualquer altura e mostrar o tipo de projeto e os IPs instanciados neste mesmo projeto. Esse interface está representado na figura 4.13
Com esta ferramenta o programador pode compilar a aplicação e lançar o ambi- ente de co-simulação. Ao lançar o ambiente de co-simulação é possível verificar o
Figura 4.13: Menu de co-simulação proporcionado pela framework
processamento da parte de hardware do sistema através do ModelSim e a parte de software através do QEMU. Nesta simulação pode fazer-se uma análise mais detalhada das transações de dados entre a componente de hardware e software o que permite, fazer uma melhor deteção de erros na integração destas duas compo- nentes.
A figura 4.14 apresenta o QEMU a emular a plataforma escolhida pelo utilizador, onde é lançada a aplicação de software desenvolvida de acordo com as especificações do sistema proposto.
Figura 4.14: Aplicação de cálculo das potências instantâneas a correr sobre uma plataforma emulada pelo QEMU
A framework irá lançar o ModelSim para que seja possível simular a componente de hardware do sistema, onde é possível observar os sinais do IP responsável pelo cálculo da transformada de Clarke. Através do interface do Modelsim é possível controlar a execução da simulação de hardware. O programador tem acesso a todos os sinais presentes na componente de hardware, o que faz com que seja mais fácil a análise do sistema e detecção de erros.
Para poder ter certeza do correto funcionamento do sistema, foi criado um circuito bastante simples no PSIM representado pela figura 4.15, onde foi ligado à rede um circuito puramente resistivo.
Figura 4.15: Circuito de teste do sistema desenvolvido
Com isto foi possível obter conjunto de valores que traduz as correntes e tensões de um sistema deste tipo. Assim é possível usar estes valores obtidos como en- trada do ADC ofline, para que seja possível validar o comportamento da aplicação desenvolvida. As tensões e correntes lidas estão representadas na figura 4.16.
Figura 4.16: Tensões e correntes de entrada do ADC
Os valores das potências instantâneas calculadas pela aplicação encontram-se re- presentados na figura 4.17.
Figura 4.17: Potências instantâneas calculadas pela aplicação
Como é possível observar a única componente que não é nula é a potência activa instantânea, pelo facto circuito testado tratar-se de um circuito puramente resis- tivo, o que faz com que não haja aparecimento de potência reativa instantânea nem P0, o que vai de encontro aos resultados esperados.
Capítulo 5
Conclusão
Nesta capítulo é analisado o trabalho desenvolvido, onde são abordados e discu- tidos os aspectos importantes sobre o seu desenvolvimento. Para além disso são propostas melhorias ao sistema para trabalho futuro.
5.1
Trabalho Desenvolvido
Esta dissertação descreve as considerações tomadas na implementação de uma fra-
mework compatível com um repositório IP-XACT para um domínio especifico de
aplicações. Ao adotar um design flow foi possível identificar métricas e processos que podiam ser agilizados e ao mesmo tempo adotar padrões de modelação de sistemas que podem ser reproduzidos automaticamente, para assim ser possível a adoção de abordagens generativas. Ao construir uma base dados IP-XACT foi possível armazenar as informações dos IP com intuito de os reutilizar em projetos futuros. O facto de ser possível inserir os comportamentos dos IPs em software e hardware no repositório, permitiu criar uma framework que automatiza o pro- cesso de desenvolvimento de um co-design hardware/software. A integração de um módulo TGI baseado num mecanismo de comunicação SOAP levou à criação de módulos independentes da framework que são compatíveis com diferentes DE que suportam o standard IP-XACT. Assim, foi possível acrescentar funcionalidades de geração da toolchain sem ter que se fazer grandes alterações à estrutura interna da
framework. Com a integração destes módulos possibilitou-se a construção de um
módulo de verificação do sistema, permitindo criar um ambiente de co-simulação. A divisão da framework em back-end e front-end possibilitou a integração de um
GUI que facilmente pode ser substituído ou atualizado, de forma a permitir o in- terface do programador com as funcionalidades da framework. Ao utilizar uma abordagem modular no desenvolvimento da framework permite a integração de novos módulos, de maneira a estender as funcionalidades da framework.
Através do cenário de aplicação foi possível validar o comportamento da framework. O processo de geração de um projeto hardware/software mostrou-se bastante in- tuitivo e prático, só com uma ferramenta foi possível gerar os device drivers, a componente de hardware do sistema e toda a toolchain de software que permite ao programador desenvolver o seu sistema. Ao recorrer a uma framework que dá suporte às funcionalidades das ferramentas que integram as diferentes etapas do
design flow hardware/software faz com que o desenvolvimento de projetos desta
natureza seja muito mais rápida e automático.
É espectável com cenários mais exigentes que surjam limitações no desempenho dos sistemas gerados pela framework. Num cenário onde é necessário instanciar um grande número IPs em hardware vai levar a que hajam limitações da componente física do sistema, como por exemplo a falta de linhas de interrupção, pois cada IP