Para este trabalho, desenvolveu-se um simulador de um display de v´ıdeo contendo todos os sinais de sincronismo de um monitor CRT (Cathode Ray Tube) padr˜ao o qual ser´a apresentado na pr´oxima se¸c˜ao (4.4), por´em o escopo deste trabalho ´e o desenvolvimento de um gerador de caracteres. Para a implementa¸c˜ao dos demais m´odulos, o projetista deve ter em m˜aos a referˆencia que informa quais ser˜ao os sinais e os tipos de dados que o SoC em desenvolvimento ir´a controlar.
A ferramenta de tradu¸c˜ao de c´odigo necessita que o projetista informe nos m´odulos descritos no diagrama de classes quais ser˜ao as interfaces de comunica¸c˜ao. Por mais simples que possa parecer, est´a ´e uma das tarefas mais complexas. Al´em de utilizar todo o conceito do projeto, que pode ser abstra´ıdo dos diagramas descritos nas etapas anteriores, deve-se ter um m´ınimo de conhecimento pr´evio da estrutura da linguagem (SystemC ) e dos processos de desenvolvimento de SoC.
(dados) ´e sincronizada por meio de “eventos”, deve-se utilizar somente FIFO’s (sc fifo in e sc fifo out) como canais de comunica¸c˜ao (“channels”) entre os m´odulos. A maneira mais simples de identific´a-los ´e atrav´es das informa¸c˜oes contidas no diagrama de seq¨uˆencia, por´em ´e aconselh´avel que o projetista tamb´em fa¸ca um pequeno esbo¸co, contendo o diagrama de blocos referente ao projeto, descrevendo passo a passo a funcionalidade do SoC como um todo.
A orienta¸c˜ao de cada mensagem no diagrama de seq¨uˆencia pode informar o tipo de interface que deve ser utilizada (entrada/sa´ıda). Quando se identifica que uma mensagem do diagrama ´e realmente um prov´avel “channel” a ser utilizado no projeto, deve observar o sentido de orienta¸c˜ao das mensagens. O in´ıcio de uma seta indica que o m´odulo de onde ela partiu possui uma interface de sa´ıda (sc fifo out). A extremidade final da seta indica que o m´odulo apontado possui uma interface do mesmo tipo de dados, por´em de entrada (sc fifo in), conforme podemos observar na FIG. 4.14.
Figura 4.14: Exemplo de msg no Diagrama de Seq¨uˆencia - A Orienta¸c˜ao da seta pode indicar o tipo de interface entre m´odulos
O nome representado da mensagem no diagrama pode ajudar a definir o nome de um “channel” que ir´a interconectar dois m´odulos. Para evitar erros em uma futura interconex˜ao destes m´odulos dentro do arquivo “main” ´e recomendado que se utilize o mesmo nome de interface (reveja FIG. 4.14), lembrando que uma ser´a de entrada e a outra de sa´ıda.
Conforme foi visto, as etapas descritas nos par´agrafos abaixo descrevem os passos utilizados no estudo de caso para a defini¸c˜ao das interfaces dos m´odulos por meio da an´alise do diagrama de seq¨uˆencia (FIG. 4.12) da se¸c˜ao 4.2.2.
A primeira mensagem do diagrama, “1: Endere¸co”, , esta indicando um fluxo de dados que vai do gerador de caracteres para a mem´oria. O projetista experiente logo ir´a questionar onde e como esses endere¸cos ser˜ao gerados e/ou armazenados. Como n˜ao foi informado na especifica¸c˜ao o formato da entrada de dados, definiu-se que os endere¸cos ficar˜ao armazenados em outro m´odulo que ser´a definido na pr´oxima se¸c˜ao (4.4). Isso elimina a possibilidade de uma interface de sa´ıda com este nome para o m´odulo gerador de caracteres.
Mesmo que n˜ao seja o gerador de caracteres o respons´avel pelo envio dos endere¸cos, eles ainda dever˜ao ser recebidos na mem´oria. Conforme a descri¸c˜ao, ela ´e a respons´avel pelo armazenamento dos c´odigos ASCII que ser˜ao representados no display. A partir dessa informa¸c˜ao obt´em-se a primeira interface de entrada, chamada de “end” (abrevia¸c˜ao de “endere¸co”). Ela dever´a ser inclu´ıda no m´odulo que representa a mem´oria no diagrama de classes como “sc fifo in<T>end”. Para inserir uma interface em um m´odulo do diagrama de classes basta clicar com o bot˜ao direito do mouse e acessar propriedades. Clique em atributos na tela `a esquerda e insira um novo atributo. Selecione a interface sc fifo in<T> em tipo e forne¸ca o nome “end” no formul´ario (FIG. 4.15).
Figura 4.15: Umbrello - Adicionando interfaces aos m´odulos
A mensagem “2: ASCII” - indica uma funcionalidade que foi descrita na especifica¸c˜ao. Ap´os o fornecimento de um endere¸co, a mem´oria envia uma mensagem contendo o c´odigo ASCII de um caractere para que o gerador de caracteres construa sua matriz de pixels. Esta mensagem caracteriza um “channel” entre a mem´oria e o gerador de caracteres. As interfaces que constituem este “channel” s˜ao: ASCII de sa´ıda na mem´oria e ASCII de entrada no gerador de caracteres (“sc fifo out<T>ASCII”, “sc fifo in<T>ASCII”).
Mensagem “3: ASCII” - Como a ROM de caracteres armazenas todos os c´odigos que constituem a tabela ASCII, o gerador de caracteres necessita transformar o c´odigo recebido da mem´oria (ASCII ) em um endere¸co v´alido que possa ser lido na ROM. Al´em disso, se fosse utilizado o nome “ASCII” para representar este “channel”, ter´ıamos duas interfaces de mesmo nome no m´odulo gerador de caracteres, uma de entrada, recebendo dados da mem´oria e outra de sa´ıda, enviando dados para a ROM. Por esse motivo utilizou-se “ad- dress” ao inv´es de “ASCII” para representar este “channel”. Ele ´e composto pelas seguintes
interfaces: “address” de sa´ıda do gerador de caracteres e “address” de entrada na ROM de caracteres.
Mensagens “4: Matriz de Pontos”, “5: Armazena Linha de Caracteres” e “6: Seq¨uˆencia de Pixels” - O gerador de caracteres, segundo a especifica¸c˜ao, ´e o respons´avel pela forma¸c˜ao da linha a ser enviada ao display. Para manter essa afirma¸c˜ao o m´odulo deveria ser capaz de armazenar uma grande quantidade de linhas a serem mostradas. Isso somente seria poss´ıvel se fosse introduzido um buffer (´area de armazenamento) dentro do pr´oprio m´odulo, e ele deveria ser capaz de realizar escrita e leitura simultˆaneas, aumentando a complexidade de implementa¸c˜ao. Para facilitar o desenvolvimento e evitar erros, optou-se pelo desenvolvimento de um m´odulo com esta fun¸c˜ao de armazenamento de linhas e quadros separadamente. A funcionalidade da ROM foi mantida, por´em ela n˜ao retornar´a a linha de pixels para o gerador de caracteres e sim para um m´odulo de armazenamento. Para este estudo de caso definiu-se que a representa¸c˜ao de cada c´odigo ASCII ser´a realizada por meio de uma matriz de pixels 8x8 de zeros(0) e um(1). Estes valores s˜ao respons´aveis pela representa¸c˜ao da forma, ou seja, desenho de cada caractere no display como mostra a FIG. 4.16.
Figura 4.16: Representa¸c˜ao do caractere ASCII “u” na ROM
Para este m´odulo o nome dado a interface de sa´ıda foi “character line”. Como cada linha de um caractere possui 8 pontos e cada ponto pode representar apenas 0 (zero) ou 1 (um), o tipo escolhido foi o sc bv<8>(Bit value de tamanho 8). Este tipo armazena
apenas zeros e 1(um) e permite opera¸c˜oes com outros tipos padr˜ao do SystemC.
A ´ultima mensagem restante, “6: Sinais de Controle”, acontece simultaneamente com a mensagem “6: Seq¨uˆencia de Pixels” j´a apresentada. Devido a complexidade e quantidade de sinais de controle necess´arios ao funcionamento correto do display, chegou-se a decis˜ao que este tamb´em deveria ser um m´odulo a parte. Esta mensagem n˜ao representa um tipo isolado de interface, mas diversas.
A mem´oria por si mesma n˜ao define automaticamente uma ´area de armazenamento. Para armazenar os caracteres ASCII que ser˜ao lidos atrav´es da interface “end” criou-se um buffer unidimensional de inteiros de 32 bits, de tamanho ainda a ser definido no “main” (sc int<32>buffer[TAMBUFFER]).
Em cada m´odulo adicionou-se um processo. Ele ´e o respons´avel pela descri¸c˜ao da funcionalidade de cada m´odulo em particular. O m´etodo de implementa¸c˜ao dessa funcionalidade ser´a descrita na pr´oxima se¸c˜ao. Para adicionar um processo ao m´odulo, acesse “propriedades” e clique em “operations”. Preencha o formul´ario com o nome do processo e clique em OK. Este processo ´e similar a adi¸c˜ao de interfaces. Utilize como referˆencia a FIG. 4.15.
A FIG. 4.17 abaixo apresenta o resultado do diagrama de classes contendo todos os m´odulos e suas respectivas interfaces.
Figura 4.17: Diagrama de Classes - Defini¸c˜ao das interfaces
Esta etapa deve ser refeita quantas vezes forem necess´arias. Para gerar o c´odigo Sys- temC por meio da ferramenta acesse o “code generation wizard” no menu “code”. Antes, verifique se a linguagem SystemC est´a configurada como padr˜ao no menu “code/active language”.
Figura 4.18: Umbrello - Acesso ao gerador de c´odigo (“Code Generation Wizard”)
Selecionar as classes que contem interfaces para a gera¸c˜ao do c´odigo e clicar em “next”.
Figura 4.19: Umbrello - Sele¸c˜ao de M´odulos para a Gera¸c˜ao de c´odigo SystemC
Indicar o caminho onde o c´odigo SystemC ser´a gravado em “write all generated files to folder”. Indicar o caminho do cabe¸calho dos arquivos fontes “include heading files from folder”. Clicar em “next”.
Figura 4.20: Umbrello - Indica¸c˜ao do local de grava¸c˜ao dos arquivos fonte e leitura do cabe¸calho
Os m´odulos selecionados ser˜ao mostrados com a informa¸c˜ao de que ainda n˜ao foram gerados (“Not Yet Generated”) .
Figura 4.21: Umbrello - Aguardando a confirma¸c˜ao para gerar o c´odigo
Figura 4.22: Umbrello - C´odigo gerado com sucesso
Na pasta onde os fontes foram gravados, deve-se descartar os arquivos com a extens˜ao “*.sc”. Para cada um dos m´odulos haver´a um arquivo de extens˜ao “*.h” contendo o c´odigo SystemC.