Resultados

Os resultados finais e os mais relevantes de cada etapa est˜ao descritos novamente abaixo como forma de simplificar a visualiza¸c˜ao do projeto.

Identifica¸c˜ao e Classifica¸c˜ao dos Requisitos

• Funcionais:

– RF-001: “O m´odulo deve ser capaz de ler um caractere armazenado”;

– RF-002: “O m´odulo deve ser capaz de converter um c´odigo ASCII para o padr˜ao de visualiza¸c˜ao do “display” de v´ıdeo”;

– RF-003: “O m´odulo deve ser capaz de enviar caracteres para um “display” de v´ıdeo”;

– RF-004: “O m´odulo dever´a controlar os sinais de v´ıdeo necess´arios para o funcionamento do “display””;

• N˜ao-funcionais:

– RNF-001: “Os caracteres dever˜ao ser armazenados em mem´oria”;

– RNF-002: “Os caracteres ser˜ao representados atrav´es do c´odigo ASCII”;

– RNF-003: “Cada endere¸co da mem´oria equivaler´a a um c´odigo ASCII em particular”; – RNF-004: “O “display” de v´ıdeo ter´a a resolu¸c˜ao padr˜ao de uma imagem no

formato CIF(352Cx288L) - Detalhado no padr˜ao H.261 de compress˜ao de v´ıdeo”; – RNF-005: “O mem´oria deve ser capaz de armazenar uma tela completa”; (Requisito

Extra)

– RNF-006: “O “display” dever´a receber dados dos caracteres da linha de forma serial”;

– RNF-007: “O m´odulo deve permitir a visualiza¸c˜ao de caracteres mai´usculos e min´usculos”;

– RNF-008: “O m´odulo deve permitir a visualiza¸c˜ao de espa¸cos”;

– RNF-009: “O m´odulo deve ser capaz de gerar um quadro completo (ou varredura vertical) do “display””;

– RNF-010: “O m´odulo dever´a gerar o sinal de sincronismo horizontal”; – RNF-011: “O m´odulo dever´a gerar o sinal de sincronismo vertical”; – RNF-012: “O m´odulo dever´a gerar o sinal de retra¸co horizontal”; – RNF-013: “O m´odulo dever´a gerar o sinal de retra¸co vertical”;

– RNF-014: “O m´odulo dever´a enviar uma linha de caracteres por vez”;

– RNF-015: “O m´odulo dever´a ser capaz de transformar um c´odigo ASCII em uma matriz de pontos (pixels) 8x8”;

Identifica¸c˜ao dos Casos e dos Atores

• Gerador de Caracteres - Atores identificados:

– Mem´oria – Display – Interface

– ROM de caracteres

• Gerador de Caracteres - Casos de uso identificados:

– Obter caractere da mem´oria

– Converter c´odigo ASCII em uma matriz de pontos – Gerar seq¨uˆencia de pixels para cada linha

Descri¸c˜ao do Diagrama de Caso de Uso

Descri¸c˜ao do Diagrama de Seq¨uˆencia

Descri¸c˜ao do Diagrama de Classes

Figura 4.26: Resultados - Diagrama de Classes

A visualiza¸c˜ao dos resultados ´e feita de duas maneiras. A primeira ´e por meio do pr´oprio simulador de v´ıdeo que foi implementado e pode ser encontrado nos anexos (simulador video). A segunda, ´e atrav´es da visualiza¸c˜ao das formas de ondas geradas pelo arquivo “tracefile” definido no “main”. O arquivo com extens˜ao “*.vcd” (“Value Change Dump”) gerado pode ser visualizado no programa “GTKWave”, de licen¸ca publica (“GNU - General Public License”).

A FIG. 4.27 abaixo apresenta a tela resultado da simula¸c˜ao do gerador de caracteres em conjunto com o simulador de v´ıdeo.

Figura 4.27: Resultado - Quadro gerado pelo simulador de v´ıdeo

Observe que o caractere “-” no simulador representa o pixel apagado e o caracter “w” representa o pixel aceso. A mem´oria do gerador de caracteres foi preenchida com os caracteres ASCII que formam a palavra “ufmg”.

Para fins de teste, definiu-se que a tela suportaria 4 linhas x 8 colunas de caracteres. Como cada caractere ´e representado por uma matriz de pontos 8x8, ent˜ao o simulador de v´ıdeo implementa um quadro que contem 32x64 pontos. O sincronismo de cada quadro do “display” pode ser conferido na FIG. 4.28 abaixo.

Figura 4.28: Resultado - Formas de onda referente aos sinais de sincronismo do v´ıdeo

A varredura horizontal (“HSYNC”) somente ´e ativada ap´os a varredura de todas as colunas da linha (“PX COL”), 64 pontos. A varredura vertical(“VSYNC”) somente ´e

ativada ap´os a varredura horizontal de todas as 32 linhas de pontos (“PX LINE”), formando assim um quadro completo para a visualiza¸c˜ao na tela.

Cap´ıtulo 5

Conclus˜ao

O presente trabalho apresentou uma vis˜ao geral (overview ) das mais recentes pequisas em desenvolvimento de projeto de SoC’s, das propostas de novas metodologias de projeto e das ferramentas de gera¸c˜ao de c´odigo SystemC. Demonstrou tamb´em a necessidade e a importˆancia de novas metodologias serem continuamente propostas.

A contribui¸c˜ao cient´ıfica deste trabalho pode ser resumida em dois aspectos principais: a proposta de uma nova metodologia de desenvolvimento de SoC’s a partir de descri¸c˜oes UML e a ferramenta para tradu¸c˜ao de c´odigo execut´avel para SystemC, ambas validadas funcionalmente por meio do estudo de caso apresentado (cap´ıtulo 4).

A metodologia proposta (cap´ıtulo 3) teve como fator principal de motiva¸c˜ao a necessidade de diminui¸c˜ao no tempo gasto durante as fases de concep¸c˜ao e valida¸c˜ao do projeto. O desenvolvimento do “plug-in” UML-SystemC foi motivado, al´em da importˆancia da documenta¸c˜ao e organiza¸c˜ao das informa¸c˜oes, pela necessidade de cria¸c˜ao de uma ferramenta que desse suporte ao projetista desde a fase de concep¸c˜ao ao primeiro modelo execut´avel do projeto. N˜ao menos importante dos que os fatores citados ´e o fato dela ter sido desenvolvida a partir de um software livre e de c´odigo aberto, o que permitir´a o seu aprimoramento por meio do auxilio da comunidade, podendo at´e surgir uma vers˜ao livre para outros sistemas

operacionais dispon´ıveis.

O autor, por meio da experiˆencia adquirida como monitor da linguagem SystemC no Laborat´orio de Sistemas Computacionais Integrados (LABSCI) do CPDEE, afirma que existe uma grande dificuldade por parte dos novos projetistas de SoC em desenvolver especifica¸c˜oes execut´aveis para novos projetos. A maioria parte diretamente para programa¸c˜ao, sem qualquer tipo de documenta¸c˜ao e/ou esbo¸co do que se pretende implementar. Freq¨uentemente refazem o mesmo trabalho v´arias vezes at´e conseguir resultados na simula¸c˜ao, isso quando realmente conseguem.

Embora o trabalho n˜ao apresente resultados com fins comparativos, o objetivo principal, de diminui¸c˜ao no tempo gasto at´e a primeira especifica¸c˜ao execut´avel foi alcan¸cado. A ferramenta que foi desenvolvida, al´em de diminuir o tempo de desperdi¸cado por um projetista de SoC’s na programa¸c˜ao do c´odigo, diminui tamb´em o tempo gasto no aprendizado da linguagem. A gera¸c˜ao de c´odigo automatizado diminui os riscos de erros de sintaxe na compila¸c˜ao do c´odigo gerado. Pode-se dizer tamb´em que a metodologia proposta obriga o projetista a trabalhar no n´ıvel mais alto de abstra¸c˜ao suportado pela linguagem, bem acima do RTL, facilitando a implementa¸c˜ao e conseq¨uentemente diminuindo mais uma vez o tempo de programa¸c˜ao.

As limita¸c˜oes da ferramenta foram os fatores principais de motiva¸c˜ao para a listagem de trabalhos futuros abaixo:

• Avalia¸c˜ao da metodologia proposta em um n´umero maior de projetos relacionados ao desenvolvimento de SoC ;

• Avalia¸c˜ao e compara¸c˜ao do desempenho da ferramenta em diferentes tipos de projetos de SoC ;

• Acrescentar novos recursos `a ferramenta: (i) automatizar o processo de interconex˜ao

dos m´odulos; (iii) permitir que a simula¸c˜ao SystemC seja iniciada no pr´oprio Umbrello; (iv) automatizar o processo de gera¸c˜ao de vetores de teste; (v) utilizar o diagrama de transi¸c˜ao de estados para tentar abstrair a funcionalidade dos processos;

Como contribui¸c˜ao final, podemos pensar ainda em uma ferramenta capaz de gerar descri¸c˜oes RTL sintetiz´aveis diretamente para FPGA partindo de uma modelagem em alto n´ıvel. Por´em, o contexto de projeto de hardware ainda precisa estar bem definido em uma ferramenta de modelagem visual que tenha robustez suficiente para representar toda e qualquer estrutura e/ou comunica¸c˜ao entre hardware e software de forma transparente para o projetista.

Referˆencias Bibliogr´aficas

[1] OMG Architecture Board. Model Driven Architecture (MDA). Technical Report ormsc/2001-07-01, OMG, (2001).

[2] Arnout, G. Eda moving up, again! 6th European SystemC Users Group (2002).

[3] Bhasker, J. A SystemC Primer. Star Galaxy Publishing, 2002.

[4] Booch, G. Object-Oriented Analysis and Design with Applications (3rd Edition). Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA, 1994.

[5] Dumoulin, C., Boulet, P., Dekeyser, J., and Marquet, P. Mda for soc design, intensive signal processing experiment. Forum on Design Languages (FDL’03), Frankfurt am Main, Germany (2003).

[6] Dumoulin, C., Boulet, P., Dekeyser, J., and Marquet, P. Uml 2.0 structure diagram for intensive signal processing application specication. Tech. rep., INRIA, March 2003. Research Report RR-4766.

[7] Edwards, S., Lavagno, L., Lee, E. A., and Vincentelli, A. S. Design of embedded systems: Formal models, validation and synthesis. Proceedings of the IEEE (1997), pages 366–390.

[8] Gajski, D. D., and Kuhn, R. Guest editor introduction: New vlsi-tools. IEEE Computer (December 1983).

[9] Gr¨otker, T., Liao, S., Martin, G., and Swan, S. System Design with SystemC. Kluwer Academic Publishers, 2002.

[10] Hammond, L., Nayfeh, B. A., and Olukotun, K. A single-chip multiprocessor. IEEE Computer (September 1997), pages 79–85.

[11] Harel, D., and Naamad, A. The statemate semantics of statecharts. ACM Trans. Softw. Eng. Methodol. 5, 4 (1996), 293–333.

[12] Jacobson, I. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA, 1992.

[13] Jerraya, A. A., Svarstad, K., Ben-Fredj, N., and Nicolescu, G. A higher level system communication model for object-oriented specification and design of embedded systems. In: Conference on Asia South Pacific Design Automation Con- ference - ASPDAC (2001), 69–77.

[14] Lavagno, L., Martin, G., and Selic, B. UML for Real: Design Embedded Real- Time Systems. Kluwer Academic Publishers, Norwell, MA, 2003.

[15] Micheli, G. D., and Benini, L. Network on chips: A new soc paradigm. IEEE Computer vol. 35-1 (2002), pages 70–78.

[16] Miller, J., and Mukerji, J. (editors). MDA Guide (Draft Version 0.2) - Captured at http://www.omg.org/docs/ab/03-01-03.pdf, (2003).

[17] Moreno, E. I., Rodolfo, T. A., and Calazans, N. L. V. Modelagem e descri¸c˜ao de socs em diferentes n´ıveis de abstra¸c˜ao. In: X WORKSHOP IBERCHIP - Cartagena 1 (2004), 1–11.

[18] Nguyen, K. D., Sun, Z., Thiagarajan, P. S., and Wong, W. Model-driven soc design via executable uml to systemc. Real-Time Systems Symposium. Proceedings. 25th IEEE International (December 2004), 459–468.

[19] Patt, Y. N., Patel, S. J., Evers, M., Friendly, D. H., and Stark, J. One billion transistors, one uniprocessors, one chip. IEEE Computer (September 1997), pages 51–57.

[20] Rajsuman, R. System on a Chip Design and Test, 1st ed. Artech House, Inc Norwood, MA, USA, 2000. 277.

[21] Rauscher, T. G. Time to market problems - the organiza-tion is the real cause. Proceedings of the IEEE Interna-tional Engineering Management Conference (1994), pages 338–345.

[22] Riccobene, E., Rosti, A., and Scandurra, P. Improving soc design flow by means of mda and uml profiles. 3rd Workshop on Software Model Engineering (WiSME)@UML (October 2004).

[23] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W. Object-oriented modeling and design. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1991.

[24] Schaller, R. R. Moore’s law: past, present and future. IEEE Spectrum vol. 34-6 (1997), pages 52–59.

[25] SIA. International techology roadmap for semiconductors. World Semiconductor Council, Edition 1999, Captured at http://public.itrs.net (1999). (Semiconductor Industry Association).

[26] Synopsys. Cocentric system studio enables verification at multiple levels of abstraction with systemc. Captured at http://www.synopsys.com/products/cocentric studio/cocentric studi wp.pdf (January 2002).

[27] Yu, A. The future of microprocessors: Intel’s head of microprocessor products looks 10 years ahead to 2006. IEEE MICRO (1996).

[28] Zhu, Q., Matsuda, A., Kuwamura, S., Nakata, T., and Shoji, M. An object-oriented design process for system-on-chip using uml. 15th International Sym- posium on System Synthesis (ISSS) , Kyoto, Japan (2002), pages 249–254.

Apˆendice A

Anexos

A.1

C´odigo Esqueleto

C´odigo Fonte A.1: C´odigo Esqueleto - Gerador de Caracteres

1 #i f n d e f GERADOR DE CARACTERES H 2 #define GERADOR DE CARACTERES H 3 #include <systemc . h> 4 5 template <c l a s s T> SC MODULE( G e r a d o r d e C a r a c t e r e s ) { 6 s c f i f o i n <T> ASCII ; 7 s c f i f o o u t <T> a d d r e s s ; 8 9 10 void p r o c e s s ( ) { 11 12 // Implemente a f u n c i o n a l i d a d e do p r o c e s s o a q u i ! 13 14 } 15 SC CTOR( G e r a d o r d e C a r a c t e r e s ) { SC THREAD( p r o c e s s ) ; } 16 } ;

17 #endif //GERADOR DE CARACTERES H

C´odigo Fonte A.2: C´odigo Esqueleto - Mem´oria

1 #i f n d e f MEMORIA H 2 #define MEMORIA H 3 #include <systemc . h> 4

5 template <c l a s s T> SC MODULE( Memoria ) { 6 s c f i f o i n <T> end ; 7 s c f i f o o u t <T> ASCII ; 8 s c i n t <32> b u f f e r [TAMBUFFER] ; 9 10 void p r o c e s s ( ) { 11 12 // Implemente a f u n c i o n a l i d a d e do p r o c e s s o a q u i ! 13 14 }

15 SC CTOR( Memoria ) { SC THREAD( p r o c e s s ) ; } 16 } ;

17 #endif //MEMORIA H

C´odigo Fonte A.3: C´odigo Esqueleto - ROM de Caracteres

1 #i f n d e f ROM DE CARACTERES H 2 #define ROM DE CARACTERES H 3 #include <systemc . h>

4

5 template <c l a s s T> SC MODULE( ROM de Caracteres ) { 6 s c f i f o i n <T> a d d r e s s ;

7 s c f i f o o u t <s c b v <8> > c h a r a c t e r l i n e ; 8

10 void p r o c e s s ( ) { 11

12 // Implemente a f u n c i o n a l i d a d e do p r o c e s s o a q u i !

13

14 }

15 SC CTOR( ROM de Caracteres ) { SC THREAD( p r o c e s s ) ; } 16 } ;

17 #endif //ROM DE CARACTERES H