# Relatório de Auditoria V3 e Roadmap V4: A Fronteira Final

Este documento detalha as lacunas identificadas na implementação da Versão 3.0 e define o roteiro para a Versão 4.0, focada em transformar os "placeholders" restantes em engenharia de silício real.

## 1. Auditoria da V3 (O que falta?)

A análise exaustiva do código revelou que, embora a V3 tenha introduzido conceitos avançados, a implementação de algumas funcionalidades críticas permaneceu em estágio de "mock" ou "stub":

### A. Software e Compiladores
*   **Triton Kernel (`triton_rsr.py`):** O arquivo contém apenas esqueletos de funções com `pass`. Não há lógica real de kernel GPU implementada. A promessa de "portabilidade para GPU" não foi cumprida.
*   **Compiler Backend (`trme_compiler.py`):** A lógica de substituição de grafo (`node.target = ...`) está comentada e seguida por `pass`. O compilador detecta o nó `Linear`, mas não o substitui efetivamente pelo kernel TRME.
*   **FMM Integration:** O simulador Python (`trme_sim.py`) continua utilizando a implementação lenta em Python (`fmm_core.py`) e ignora o novo kernel C++ de alto desempenho (`fmm_octree.cpp`).

### B. Hardware RTL
*   **RNS Pipeline (`rns_pipeline.v`):** A implementação do Forward Transform utiliza o operador `%` (módulo). Em síntese de hardware real, isso infere divisores maciços que destroem o timing (frequência). A solução correta exige Redução de Barrett ou Montgomery.
*   **Co-Simulação:** O wrapper C++ (`cosim_verilator.cpp`) simula a interação com o Verilator imprimindo mensagens, em vez de incluir os headers reais do Verilator e dirigir os sinais de clock/reset.

---

## 2. Roadmap V4.0 (Tape-out Readiness)

A V4 não é sobre novas ideias, é sobre **rigor de implementação**. O objetivo é ter um design que possa ser enviado para fabricação (Tape-out) ou rodar em cluster GPU real.

### Fase 1: Hardware "Synthesizable" (Silício Real)
1.  **Redução Modular Eficiente:** Substituir o operador `%` em `rns_pipeline.v` por multiplicadores de ponto fixo usando o método de Barrett (evita divisão).
2.  **Gerador de Array Sistólico:** Transformar `systolic_array_4x4.v` em um gerador parametrizado (Python/Chisel ou Verilog `generate`) capaz de criar arrays $N \times N$ (ex: 16x16, 64x64).
3.  **HBM Controller Stub:** Adicionar uma interface AXI4-Full (não apenas Stream) para simular leitura de memória de alta largura de banda (HBM), crucial para alimentar o array sistólico.

### Fase 2: Software de Produção (Sem "Pass")
1.  **Triton RSR Real:** Implementar o kernel Triton completo. Isso envolve gerenciar ponteiros de bloco, carregar a LUT na memória compartilhada (SRAM da GPU) e realizar a acumulação paralela.
2.  **TorchDynamo Backend Funcional:** Descomentar e corrigir a lógica de substituição em `trme_compiler.py`. O grafo computacional deve ser efetivamente modificado para chamar `trme_torch.matmul`.
3.  **Integração FMM C++:** Criar bindings `ctypes` para `fmm_octree.cpp` e forçar `trme_sim.py` a usar esta implementação nativa.

### Fase 3: Física Avançada
1.  **Maxwell Solver (FDTD):** Substituir a multiplicação matricial da simulação óptica por um solver de Diferenças Finitas no Domínio do Tempo (FDTD) simplificado (1D/2D). Isso simula a propagação da onda eletromagnética real, não apenas a álgebra linear.

### Fase 4: Co-Simulação Verdadeira
1.  **Verilator Integration:** Escrever um `Makefile` que compile o RTL usando Verilator para um objeto compartilhado Python, permitindo que o PyTorch envie tensores que se tornam sinais `wire` no Verilog real.

---

## 3. Conclusão
A V3 construiu a estrutura (o esqueleto), mas a V4 deve preenchê-la com músculos reais. Eliminar os `pass` e operadores não sintetizáveis é o passo final para provar que o TRME não é apenas uma teoria bonita, mas uma máquina viável.
