Fluxo de projeto

O fluxo típido de projeto para FPGA consiste no processo de criar, implementar, verificar e descarregar uma especificação no hardware. O fluxo completo descreve um processo iterativo em que se faz a verificação dos resultados obtidos em simulação comportamental e temporal e, posteriormente, a verificação direta no circuito físico. Uma especificação inicial é validada assim que se demonstre que a funcionalidade pretendida está correta (ver figura 2.8). O fluxo consiste então em três passos [4]:

Especificação do projeto e síntese Uma especificação de arquitetura pode ser feita de duas ma- neiras distintas e/ou interlaçar ambas. A primeira é com recurso a um editor de esquemáticos que permite especificar diretamente a estrutura do circuito com portas e elementos lógicos. A segunda é a partir de uma Linguagem de Descrição de Hardware (HDL), que permite fazer uma descrição textual dos circuitos não apenas em estrutura mas também em com- portamento. Estas linguagens suportam um conjunto de regras, instruções e operadores que permitem organizar uma especificação em módulos distintos, com entradas e saídas, e des- crever o seu comportamento a partir de estruturas de código que se traduzem em elementos lógicos de circuitos digitais, como flip-flops, multiplexadores, portas lógicas, somadores,

multiplexadores, LUTs, etc. A ferramenta da Xilinx designada por XST (Xilinx Synthesis Technology), permite traduzir uma descrição textual de comportamento para uma descrição estrutural, isto é, uma netlist; a este passo dá-se o nome de síntese e traduz um ou mais ficheiros HDL para um único ficheiro ficheiro NGC (Native Generic Circuit).

Implementação Esta fase recebe um ficheiro NGC gerado no processo de síntese, cujo formato descreve uma estrutura lógica da especificação, e é convertido num formato de representação física dos circuitos da mesma para uma arquitetura de FPGA alvo. O formato de saída é designado por NCD (Native Circuit Description) que contém a informação associada ao mapeamento da lógica da especificação aos componentes físicos da FPGA. Este ficheiro pode ser posteriormente usado para gerar o ficheiro de configuração da FPGA, um ficheiro binário designado por bitstream, cujo conteúdo define a configuração da lógica interna da FPGA e encaminhamento de interligações. O bitstream é descarregado na FPGA a partir da ferramenta da Xilinx específica para o efeito, o iMPACT. A ligação entre um PC e a FPGA, dependendo da plataforma de desenvolvimento, pode ser feita através de um cabo USB (Universal Serial Bus), série ou paralelo para uma interface JTAG (Joint Test Action Group).

Verificação A verificação é feita a nível funcional e temporal, a partir da construção de uma ban- cada de teste (testbench), de modo a assegurar que a funcionalidade pretendida é a correta e que não existem violações temporais. Esta pode ser feita com um simulador RTL, aplicando estímulos nas entradas e ver o comportamento das saídas, ou então fazer debugging direta- mente na FPGA a partir, também, da interface JTAG. A Xilinx providencia um simulador RTL, o ISim, com uma interface gráfica onde se pode visualizar as formas de onda.

Na figura 2.8, apresenta-se um diagrama de alto nível do fluxo típico de projeto para FPGA. A geração de informação atrasos corresponde à criação do ficheiro SDF (Standard Delay Format), durante a fase de implementação, que especifica os atrasos nos elementos de arquitetura de hard- ware e das suas interligações. Esta informação é usada para a simulação temporal dos circuitos para a verificação do cumprimento das restrições temporais [35].

A análise temporal estática ocorre depois da fase de implementação (mapeamento, coloca- ção e encaminhamento) e antes da simulação temporal, e tem como objetivo analisar os atrasos induzidos nas interligações dos circuitos e concluir se respeitam ou não as restrições temporais especificadas. Esta análise não incluí a aplicação de vetores de estímulos nas entradas, daí ser simplesmente estática, avaliando apenas o impacto a nível temporal de propagar um ou mais bits por um caminho específico. O caminho que introduz o maior atraso no circuito designa-se por caminho crítico, e é o que limita a frequência máxima de operação do sistema.

A simulação funcional ocorre depois do processo de síntese e, ao contrário da simulação tem- poral, as restrições temporais não são tidas em conta. Desta forma, o comportamento do circuito pode ser avaliado como se operasse num cenário ideal, onde não fossem induzidos atrasos de pro- pagação nas interligações no circuito real. Esta simulação é particularmente útil para detetar erros de projeto numa fase inicial, associados à funcionalidade, que normalmente acontecem.

2.2 Field-Gate Programmable Array (FPGA) 19 Especificação de arquitetura Simulação funcional Síntese Otimização FPGAs · Mapeamento · Colocação · Encaminhamento Geração de bitstream Descarregar bitstream na FPGA Verificação no circuito físico Simulação temporal Análise Temporal Estática Gerar informação de atrasos Implementação Verificação

Figura 2.8: Fluxo típico de projeto para FPGA (alto nível) (segundo [4])

HDL Simulação Síntese NGC (XST Netlist) NGDBuild Captura de esquemático Estímulos do testbench CORE Generator Verilog, VHDL, SDF NetGen NCF NGC NGD MAP NGM, PCF NetGen NCD, PCF PAR NCD Bitgen BIT TRACE, Timing Analyzer Floorplanning no PlanAhead UCF Editor de restrições iMPACT

Na figura 2.9, ilustra-se um diagrama do fluxo típico de projeto para FPGA detalhado. A es- pecificação do projeto da arquitetura de hardware pode ser feita a partir de uma descrição textual de estrutura e/ou comportamento, uma linguagem de descrição de hardware (HDL), ou a partir da captura de um esquemático que descreve a estrutura do circuito a partir de elementos lógicos. A ferramenta da Xilinx designada por CORE Generator disponibiliza módulos pré-construídos pa- rametrizáveis e otimizados para FPGAs da Xilinx, que podem ser incluídos no projeto. A livraria da ferramenta inclui módulos para implementar FIFOs (First In First Out), instanciar BRAMs, etc. Durante o processo de síntese são construídas as netlists associadas ao HDL desenvolvido e ao HDL que descreve os módulos especificados pelo CORE Generator. Se o projeto incluir algum esquemático, é incluído o respetivo ficheiro NCF (Netlist Constraints File) que contém as restrições lógicas associadas ao esquemático. A ferramenta NGDBuild recebe posteriormente os ficheiros NGC, NCF e UCF (User Constraints File), sendo que o último contém restrições tempo- rais e de layout que afetam como é que a lógica especificada no projeto é implementada na FPGA alvo. NGDBuild lê as netlists e as restrições associadas e produz um ficheiro no formato NGD Native Generic Description) que contém a descrição lógica do projeto em termos de elementos lógicos (flip-flops, multiplexadores, portas lógicas, ...) e primitivas de baixo nível.

A fase de implementação inicia-se com o mapeamento da lógica do projeto para uma FPGA específica e é concluída quando o projeto a nível físico é encaminhado com sucesso e o respetivo ficheiro de bitstream gerado. Realizam-se então três processos distintos e pela seguinte sequência: mapeamento, colocação e encaminhamento e a geração do ficheiro de bitstream.

O mapeamento é realizado pela ferramenta MAP que recebe um ficheiro no formato NGD e ficheiros NMC (Macro Library File), caso sejam instanciadas macros no ficheiro NGD, que contêm a descrição física de hard-macros, e mapeia a lógica por este descrita em componentes da FPGA alvo (células lógicas, células de E/S e outros). É produzido um ficheiro NCD (Native Circuit Description) cujo conteúdo é uma representação física do projeto mapeado em componentes da FPGA alvo, um ficheiro PCF (Physical Constraints File) que contém restrições fornecidas na fase de especificação da arquitetura de projeto exprimidas em termos dos elementos físicos mapeados e um ficheiro NGM que contém a informação relativa ao mapeamento físico do projeto produzida por MAP. Este último é usado pela ferramenta Netgen para gerar o ficheiro SDF para as simulações temporais.

A colocação e encaminhamento são realizados pela ferramenta PAR (Place and Route). A ferramenta recebe um ficheiro NCD mapeado e PCF, aloca (coloca) componentes físicos ao ma- peamento do ficheiro NCD e estabelece as interligações (encaminha) entre esses componentes em função das restrições fisicas do ficheiro PCF. O ficheiro de saída é também do formato NCD co- locado e encaminhado. A fase de colocação depende fatores como o comprimento das ligações e dos recursos disponíveis para encaminhamento. Já na fase de encaminhamento, o encaminhador executa um procedimento iterativo e convergente de forma a que as restrições temporais sejam cumpridas.

Concluída a fase de colocação e encaminhamento, a ferramenta TRACE (Timing Reporter And Circuit Evaluator) permite realizar a análise temporal estática do projeto especificado. A