Trabalho Prático I

Trabalho Prático II – SDAC
Última revisão: 16/06/2005
Especificação:
O trabalho prático II da disciplina de SDAC (versão 2005) consiste no acréscimo de
um novo módulo à descrição TL do processador R8, bem como de algumas pequenas
alterações na arquitetura original para suportar as novas funcionalidades. A idéia
fundamental do trabalho é que este novo módulo seja um controlador de DMA simples.
Este deve permitir carregar/descarregar um conjunto de informações em/de blocos
contíguos da memória do processador, sem intervenção do processador. A estrutura geral
da implementação é mostrada na Figura 1 abaixo. A implementação do módulo deve
também ser realizada no nível de abstração de transação (TL).
Figura 1 – Estrutura do Processador R8 com Módulo DMA acrescentado.
O funcionamento do módulo DMA deve obedecer à especificação a seguir.
Primeiro, este módulo deve possuir um interface de comunicação exclusiva com o
processador, usando um protocolo do tipo “aperto de mão” implementado através do canal
handshakeChl da Figura 1.
Segundo, o processador escolhe se deseja atender a solicitações por parte do DMA
ou não. Isto deve ser feito permitindo controle por software. Para tanto, deve-se criar duas
novas instruções no processador, denominadas, por exemplo, ENI e DISI, abreviaturas de
Enable Interrupt e Disable Interrupt, respectivamente. As instruções não possuem
operandos explícitos, e devem controlar a condição de possibilidade ou impossibilidade
para atender solicitações do módulo DMA. Tipicamente, após uma operação de
inicialização (reset) do processador, solicitações não são atendidas. Apenas após a
execução de uma instrução ENI solicitações do DMA podem ser atendidas. Obviamente,
após a execução de uma instrução DISI solicitações do DMA não são atendidas, até que
uma instrução ENI seja executada.
Terceiro, o funcionamento do módulo de DMA se dá em 4 etapas: (i) aguardar que
algum periférico externo solicite serviço, arbitrando quem atender em primeiro lugar, caso
mais de um periférico solicite serviço ao mesmo tempo; (ii) interagir com o processador
para assumir o controle da interface com a memória; (iii) comandar o processo de
transferência de dados do periférico para a memória; (iv) ao final da transferência, liberar a
interface de memória para o processador e informar ao periférico o final de atendimento da
solicitação de transferência, voltando à etapa (i) acima. Note-se que não foram
representados canais de comunicação e interfaces entre periféricos e o DMA. Escolher
como implementar estas interfaces é deixado como parte do trabalho de especificação. A
escolha deve ser documentada no relatório final. Sugere-se uma interface de comunicação
simples entre o DMA e seus periféricos, com a seguinte funcionalidade. Periféricos de
entrada fornecem o endereço inicial de escrita do bloco, seguido do tamanho do bloco.
Após estas informações de controle serem recebidas pelo DMA, a transmissão se dá como
uma rajada de envios pelo periférico, considerando o DMA rápido o suficiente para
escrever na memória pelo menos na mesma taxa de recepção dos dados do periférico.
Periféricos de saída fornecem inicialmente o endereço inicial do bloco a ser lido, seguido
do tamanho do bloco. Após estas informações de controle serem recebidas pelo DMA, este
inicia a transmissão como uma rajada de envios para o periférico, considerado rápido o
suficiente para receber dados pelo menos na mesma taxa de envio pelo DMA. A
implementação dos periféricos deve ser parte do desenvolvimento do testbench do sistema.
Algumas regras básicas a serem respeitadas no trabalho são apresentadas abaixo:
1. Todas as instruções originais da R8 devem continuar sendo passíveis de execução,
sem modificação do seu código objeto original. Ou seja, o novo processador deve
ser compatível com o R8 original a nível de código objeto.
2. O testbench desenvolvido deve incluir um software de aplicação na R8, que recebe
dados via DMA, processa os mesmos e os disponibiliza a um periférico externo.
Atenção aos problemas de sincronização entre o software e os periféricos de leitura
e escrita via DMA, uma vez que nenhum recurso disponível no processador permite
que esta sincronização seja realizada de forma explícita. Sugestão de funcionalidade
da aplicação: (i) o processador é inicializado via reset; (ii) a aplicação habilita
solicitações de DMA e escreve 0000H na primeira posição do bloco de memória a
ser escrito, posição esta reservada para sincronização entre o software e a entrada
via DMA, que escreve um valor diferente de 0000H como primeiro dado do bloco;
(iii) a aplicação entra em laço, lendo o conteúdo do endereço de sincronização,
saindo fora deste laço apenas quando o valor lido for diferente de 0000H1; (iv) as
solicitações de DMA são imediatamente desabilitadas2, os dados são processados e
escritos em alguma região de memória (tipicamente diferente daquela dos dados de
entrada); (v) solicitações de DMA são novamente habilitadas e a aplicação conclui3.
1
Note-se que o software executa em paralelo com o periférico, mas ao atender uma solicitação do DMA, o
processador automaticamente suspende a execução de instruções, pois deve liberar o barramento de memória
para a transferência. Assim, cada execução de uma leitura do endereço de sincronização ocorrerá ou antes do
início da transferência do bloco para a memória, ou após o término desta transferência, não existindo a
possibilidade de conflito de acesso à memória entre o software e o DMA.
2
Note-se que, devido à simplicidade do DMA proposto, existe aqui um risco de o pedido de saída via DMA
ser atendido entre o término do processamento de entrada via DMA e a desabilitação de solicitações antes do
processamento dos dados pelo software. Construa o testbench de forma a garantir que o pedido de saída via
DMA não incorra nesta situação.
3
Novamente, devido à simplicidade do DMA proposto, não há como o software detectar que os dados foram
repassados ao periférico de saída. Assim, este termina a execução logo após habilitar as solicitações de DMA.
Grupos de alunos devem ser de 2 ou 3. Não façam trabalhos individuais.
Prazo para entrega dos trabalhos: 7/07/2005. Devem ser enviados por e-mail e
apresentados aos professores da disciplina. O trabalho inclui a distribuição do sistema
completo, bem como um relatório de 3-5 páginas. No seu relatório, além da descrição da
implementação, proponham sugestões de como aumentar a funcionalidade do DMA
proposto para sanar os problemas mencionados nas notas de rodapé da presente
especificação, indiquem os problemas de implementação encontrados (tais como
inadequações/erros no código TL fornecido como parte da especificação, etc)
Implementar o trabalho usando as ferramentas do gcc. Para depuração, recomenda-se uso
depurador gráfico-interativo DDD, instalado na máquina Kriti. Se desejado, o mesmo
depurador poderá ser instalado na máquina Leros para prover os mesmos recursos.