S´ıntese e Implementa¸c˜ ao do Gestor de Mem´ oria Dinˆ amica O projecto do gestor de mem´oria dinˆamica foi sintetizado na ferramenta de desenvolvi-

mento Xilinx ISE vers˜ao 9.2.04i, para a placa de desenvolvimento RC10 da Celoxica. Este projecto inclui os m´odulos memory manager e memory pool. A frequˆencia m´axima estimada durante a s´ıntese foi de 52.756 MHz, e a l´ogica prevista necess´aria para implementar o projecto na FPGA encontra-se sumariada na tabela A.7. Seguidamente procedeu-se `a implementa¸c˜ao da mesma unidade. A tabela A.8 sumaria a l´ogica real consumida pela implementa¸c˜ao do projecto na FPGA. Como se pode verificar os valores estimados, n˜ao fogem muito aos valores reais.

Logic Utilization Used Available Utilization

Number of Slices 368 13312 2%

Number of Slice Flip Flops 446 26624 1%

Total Number of 4 input LUTs 675 26624 2%

Number of bonded IOBs 186 221 84%

Number of BRAMs 17 32 53%

Number of GCLKs 2 8 25%

Tabela A.7: Sum´ario do relat´orio de s´ıntese do gestor de mem´oria dinˆamica (extra´ıdo da ferramenta de desenvolvimento ISE vers˜ao 9.2.04i).

Logic Utilization Used Available Utilization

Number of Slices 408 13312 3%

Number of Slice Flip Flops 319 26624 1%

Total Number of 4 input LUTs 626 26624 2%

Number of bonded IOBs 186 221 84%

Number of BRAMs 17 32 53%

Number of GCLKs 2 8 25%

Tabela A.8: Sum´ario do relat´orio de implementa¸c˜ao do gestor de mem´oria dinˆamica (extra´ıdo da ferramenta de desenvolvimento ISE vers˜ao 9.2.04i).

As funcionalidades do gestor de mem´oria dinˆamica foram simuladas recorrendo ao ISE Simulator providenciado na ferramenta de s´ıntese ISE. A simula¸c˜ao efectuou-se criando vec- tores de teste para os sinais de controlo dos portos de uplink do switch, de forma a serem recebidas v´arias mensagens na memory pool. A interac¸c˜ao de recep¸c˜ao memory pool-memory manager foi simulada com sucesso para as diversas situa¸c˜oes analisadas na sec¸c˜ao A.2.2.2 (p´agina 118). Para simular as funcionalidades de transmiss˜ao das mensagens, foi necess´ario criar vectores de teste para cada um dos sinais de interface da forwarding unit, uma vez que esta n˜ao se encontra ainda implementada. As interac¸c˜oes de transmiss˜ao memory manager- forwarding unit e memory pool-forwarding unit foram igualmente simuladas com sucesso para as diversas situa¸c˜oes analisadas na sec¸c˜ao A.2.3 (p´agina 125). O sistema foi simulado compor- talmente, ou seja, de uma forma ideal ap´os a fase de s´ıntese do projecto, e tamb´em simulado temporalmente, ou seja, de uma forma real, considerando os atrasos de propaga¸c˜ao dos v´arios sinais na FPGA, ap´os a fase de implementa¸c˜ao do sistema. Em ambas as simula¸c˜oes o gestor

de mem´oria dinˆamica desenvolvido funcionou como esperado, encontrando-se apto para ser integrado num switch.

A implementa¸c˜ao do gestor de mem´oria dinˆamica ocupa uma quantidade de recursos muito reduzida da FPGA, apenas 408 slices (3%). No entanto, apesar da frequˆencia m´axima de opera¸c˜ao ser elevada (52.756 MHz ), pode ser limitativa para a operacionalidade do sistema. Ao colocar o m´odulo memory manager a operar `a frequˆencia m´axima de 52.756 MHz, o m´odulo memory pool poder´a funcionar no m´aximo a cerca de 1 MHz. A solu¸c˜ao para aumentar esta frequˆencia poder´a passar por:

• Implementar o gestor de mem´oria numa fam´ılia de FPGAs de maior desempenho. A titulo de exemplo, ao implementar o sistema numa FPGA XC2VP30-7-ff896 da fam´ılia Virtex-II Pro da Xilinx, consegue-se uma frequˆencia m´axima de opera¸c˜ao de 108.673 MHz. Isto permite aumentar a frequˆencia da memory pool para cerca de 2 MHz ;

• Optimizar o c´odigo do memory manager de forma a reduzir o n´umero m´aximo de in- stru¸c˜oes. A titulo de exemplo, se a unidade de forwarding e a memory pool acederem ao memory manager em ciclos de rel´ogio distintos, poder´a reduzir-se o n´umero de in- stru¸c˜oes, fazendo com que a memory pool aceda por interrup¸c˜ao ao PicoBlaze. Isto permite separar o programa de recep¸c˜ao do programa de transmiss˜ao, e assim reduzir o n´umero de instru¸c˜oes necess´arias para realizar o loop de polling aos registos de status de recep¸c˜ao e transmiss˜ao. Nesta situa¸c˜ao, o pior caso seria a soma das 15 instru¸c˜oes necess´arias para executar o estado Msg Ended do programa de recep¸c˜ao com as 5 in- stru¸c˜oes m´aximas necess´arias para realizar a interrup¸c˜ao. Desta forma, ao implementar- se o sistema na FPGA Virtex-II Pro consegue-se aumentar a frequˆencia da memory pool para cerca de 2.7 MHz.

Ora, um switch ethernet a 10 Mbit/s com N portos, exige que a memory pool funcione a uma frequˆencia m´ınima de pelo menos 10/32×N MHz. Admitindo 8 portos, a frequˆencia m´ınima de funcionamento da memory pool necess´aria seria 2.5 (10/32×8) MHz. Considerando os melhoramentos anteriores (uma frequˆencia de opera¸c˜ao da memory pool de 2.7 MHz ), se- ria poss´ıvel integrar o gestor de mem´oria dinˆamica desenvolvido num switch ethernet com estas caracter´ısticas. J´a um switch ethernet convencional a 100 Mbit/s com N portos, exige que a memory pool funcione a uma frequˆencia m´ınima de pelo menos 100/32×N MHz. Este facto, torna invi´avel o uso do gestor de mem´oria dinˆamica desenvolvido num switch com estas caracter´ısticas, uma vez que s´o para um porto ´e necess´ario que a memory pool opere a uma frequˆencia m´ınima de 3.125 MHz.

A grande limita¸c˜ao do gestor de mem´oria dinˆamica desenvolvido reside no facto do mecan- ismo de recep¸c˜ao da memory pool manter os registos, que permitem ao memory manager construir a lista ligada de blocos atribu´ıdos a uma dada mensagem, est´aveis apenas durante um ciclo de rel´ogio. Este facto obriga o memory manager a executar todo o seu software neste ciclo de rel´ogio de opera¸c˜ao da memory pool. Ora, efectuando pequenas altera¸c˜oes `a l´ogica do mecanismo de recep¸c˜ao da memory pool, poderia-se fazer com que estes registos ficassem est´aveis durante um maior n´umero de ciclos de rel´ogio sem afectar o correcto funcionamento do gestor de mem´oria. Uma vez que o memory manager s´o actua quando uma mensagem necessita de mais um bloco livre e quando o mecanismo de recep¸c˜ao da memory pool termina a recep¸c˜ao de uma dada mensagem, a pior situa¸c˜ao que ´e exigida ao memory manager ´e que ele execute todo o seu software num n´umero de ciclos de rel´ogio equivalente `a recep¸c˜ao de

uma mensagem ethernet de tamanho m´ınimo (64 bytes). Dado que o mecanismo de recep¸c˜ao da memory pool necessita de dois ciclos de rel´ogio para armazenar em mem´oria cada palavra de 32 bits constituinte da mensagem, o memory manager ter´a de executar o seu software no m´aximo em ((64×8/32)×2) 32 ciclos de rel´ogio de opera¸c˜ao da memory pool, de forma a n˜ao comprometer o funcionamento do sistema. Ou seja, acrescentando ao mecanismo de recep¸c˜ao da memory pool, uma estrutura l´ogica (e.g. um buffer ) que permita manter est´aveis os registos acedidos pelo memory manager durante 32 ciclos de rel´ogio, permitiria aumentar significativamente o desempenho do gestor de mem´oria, sem comprometer o seu funciona- mento. Nestas circunstˆancias, a rela¸c˜ao de frequˆencias de opera¸c˜ao entre o m´odulo memory manager e o m´odulo memory pool seria de (27×2) 54 para 32, respectivamente. Considerando que o memory manager opera a uma frequˆencia aproximada de 50 MHz, o m´odulo memory pool poder´a funcionar no m´aximo a cerca de (50/(54/32)) 29 MHz. Ora, a esta frequˆencia de funcionamento, seria poss´ıvel integrar o gestor de mem´oria dinˆamica num switch ethernet a 100 Mbit/s com 8 portos (29 MHz > (100/(32×8)) 25 MHz), o que ´e interessante. Caso ainda o gestor de mem´oria seja implementado numa FPGA de maior desempenho (e.g. Virtex-II Pro da Xilinx ) e o c´odigo do memory manager seja optimizado (o programa de recep¸c˜ao separado do programa de transmiss˜ao), seria poss´ıvel integrar o gestor de mem´oria dinˆamica num switch ethernet a 100 Mbit/s com 24 portos ((100/(40/32)) 80 MHz > (100/(32×24)) 75 MHz), o que ´e bastante interessante.