Uma implementa¸c˜ao em hardware/software do estudo de caso deste trabalho foi feita, utilizando a plataforma de prototipa¸c˜ao descrita no Cap´ıtulo 6. O parti- cionamento do sistema em dois m´odulos (hardware e software) n˜ao foi baseado em uma metodologia formal, mas levou-se em considera¸c˜ao m´etricas de custo de comunica¸c˜ao, tempo e ´area de hardware como estimadores para o particiona- mento manual do algoritmo.
A an´alise do diagrama de blocos representando o fluxo de processamento do algoritmo detector de ve´ıculos sugere algumas alternativas de particionamento (Figura 5.5).
Figura 5.5: Diagrama em blocos do algoritmo de detec¸c˜ao de ve´ıculos.
Da forma como est´a implementado o prot´otipo do DVI, as imagens cap- turadas s˜ao lidas a partir do disco r´ıgido do PC. Deste modo, a abertura destes bitmaps dever˜ao permanecer nesta parti¸c˜ao, sendo executados a partir do m´etodo
serialize da aplica¸c˜ao em software (ver Sec¸c˜ao 5.1.1). Esta aloca¸c˜ao ´e princi- palmente justificada pelas seguintes raz˜oes:
1o) Complexidade do hardware necess´ario para acessar os arquivos;
2o) Alto custo de comunica¸c˜ao devido ao overhead da transa¸c˜ao;
3o) O formato serializado do arquivo inibe a utiliza¸c˜ao do paralelismo de hardware na melhoria do desempenho.
Definindo a ´area de interesse na imagem, a facilidade do posicionamento da janela com o uso do mouse oferece vantagens que justificam sua implementa¸c˜ao em software. Al´em disso, a sua opera¸c˜ao n˜ao implica no aumento da complexi- dade do algoritmo de detec¸c˜ao, pois resume-se na tarefa de uma ´unica captura das coordenadas das extremidades da janela de sele¸c˜ao. Por isso, este bloco tamb´em dever´a permanecer em software.
O processo seguinte refere-se a convers˜ao das imagens coloridas (RGB) em imagens monocrom´aticas (Y). Este processo merece uma an´alise especial sobre a op¸c˜ao de sua implementa¸c˜ao em software ou em hardware pois a independˆencia de dados das opera¸c˜oes pontuais envolvidas permitem o uso de paralelismo na sua execu¸c˜ao.
A ado¸c˜ao de uma implementa¸c˜ao em hardware, no entanto, implica em um alto custo de comunica¸c˜ao necess´ario para transferir as 3 matrizes que formam a imagem colorida para a plataforma de hardware.
Al´em disso, a placa de prototipa¸c˜ao adotada, possui apenas um ´unico banco de mem´oria RAM dispon´ıvel, o que impossibilita o acesso simultˆaneo a difer- entes endere¸cos de mem´oria, necess´ario para a implementa¸c˜ao do paralelismo no processamento.
Por estas raz˜oes, a convers˜ao RGB para tons de cinza permaneceu na parti¸c˜ao de software do sistema. Assim, uma vez convertida para tons de cinza, a matriz ´e ent˜ao transferida do PC para a placa com um custo de comunica¸c˜ao trˆes vezes mais baixo que na etapa anterior, o que j´a pode ser considerado razo´avel.
De acordo com a literatura da ´area [43], na busca pela melhoria de desem- penho da execu¸c˜ao de um sistema, a aten¸c˜ao do projetista deve se voltar princi- palmente para a otimiza¸c˜ao de trechos do c´odigo caracterizados por loops. Este tipo de processamento ocorre com freq¨uˆencia na etapa de convolu¸c˜ao do filtro adotado no algoritmo de detec¸c˜ao de ve´ıculos.
Apesar da limita¸c˜ao do n´umero de bancos de mem´oria na placa impedindo o acesso paralelo de dados na mem´oria, a possibilidade da s´ıntese de um circuito espec´ıfico para a opera¸c˜ao da convolu¸c˜ao desta aplica¸c˜ao pode proporcionar um ganho consider´avel no tempo de execu¸c˜ao se comparado com o c´odigo gerado pela compila¸c˜ao do programa em C++, executado no ambiente de um sistema operacional multitarefa.
Uma das alternativas consideradas foi transferir o bloco de filtragem para hardware, funcionando como um processador anexado, como ´e definido em [48], onde a imagem em tons de cinza seria enviada ao hardware e este a retornaria convolu´ıda com o kernel 3 × 3.
Neste caso, existe a necessidade de transferˆencia da imagem do PC para a placa e novamente, ap´os o processamento, a volta da placa para o PC, implicando na duplica¸c˜ao do custo de comunica¸c˜ao.
Para solucionar este problema, decidiu-se tranferir para a parti¸c˜ao de hard- ware as etapas seguintes do processamento, quais sejam, a subtra¸c˜ao de imagens, a quantifica¸c˜ao e a an´alise de mudan¸cas. Com isto, o resultado final do proces- samento seria um flag, indicando a ocorrˆencia ou n˜ao do ve´ıculo na cena.
Este flag, representa um custo de comunica¸c˜ao muito baixo e pode ser im- plementado atrav´es do bit de interrup¸c˜ao da arquitetura.
Deste modo, o particionamento hardware/software do algortimo ´e sugerido pela Figura 5.6, apresentando em uma ´area hachurada os processos que foram mapeados em hardware.
A filtragem da imagem de referˆencia continuou na parti¸c˜ao de software porque este processo ´e executado somente uma vez, n˜ao influindo portanto no desem- penho do processamento de cada quadro.
Com isto, a parti¸c˜ao de software implementa o controle do algoritmo, abrindo as imagens, convertendo em tons de cinza e enviando ao hardware as imagens de referˆencia filtrada e cada novo frame para ser processado. O hardware filtra cada novo frame e compara com a imagem de referˆencia, contabilizando as mudan¸cas ocorridas na cena, detectando ou n˜ao a presen¸ca do objeto invasor. Ao final, o resultado informado pelo flag de hardware ´e anunciado pela inteface visual do software.
Figura 5.6: Particionamento hardware/software do algortimo de detec¸c˜ao de ve´ıculos.