CATEular/skill

Parâmetros Virtuoso

Responsável pela modificação de parâmetros, análise de sensibilidade e otimização em loop fechado de circuitos existentes. Por padrão, após cada rodada de simulação, o agente ChatGPT/Codex atual analisa os resultados e decide o próximo conjunto de parâmetros; não gera a varredura completa W1×W2×… por padrão. A saída é "o melhor parâmetro viável verificado dentro do orçamento e limites atuais", sem promessa de ótimo global. Projeto de topologia de circuito e criação de novas plataformas de teste não estão no escopo desta skill.

Antes de começar

1. Leia a Convenção da Plataforma e siga o Protocolo de Configuração de Ambiente para ler a configuração local compartilhada; quando necessário conectar, use virtuoso-connect. O interpretador, escopo de trabalho, PDK e caminhos são obtidos da configuração.
2. Identifique claramente DUT/TB, definições de medição, objetivo, restrições, unidades de parâmetros/limites inferior e superior/passo legítimo, cantos e orçamento de avaliação. Se for possível inferir a partir dos documentos do projeto, organize primeiro; caso falte objetivos ou limites que alterariam o resultado, pergunte ao usuário, enquanto lê o design existente.
3. Salve os parâmetros originais e os resultados de uma rodada de linha de base. Se a plataforma de teste estiver incompleta, entregue primeiro a virtuoso-testbench e, após completar o loop de medição, continue a otimização.

Parâmetros e Avaliação

• Priorize o uso de variáveis ADE ou netlists parametrizadas existentes, evitando reconstruir o circuito para cada candidato. Ao modificar diretamente os CDFs MOS, leia parameter-editing.md.
• Avalie todos os candidatos com a mesma configuração e cantos; salve as configurações antes de cada execução, atribuindo um diretório e identificador independentes para esta rodada; ao ler os resultados, vincule-os explicitamente a history, test, corner/point.
• Use definições de medição ADE/OCEAN existentes, especialmente a margem de fase que deve vir de uma medição de loop apropriada, e não trate automaticamente a fase de uma tensão de saída arbitrária como PM.
• Esta máquina já verificou: alterar variáveis e executar via SKILL/ADE, e ler PSF específico e métricas JSON via subprocessos OCEAN independentes para realimentar o buscador; use conforme ocean-skill-flow.md, mantendo todos os identificadores de execução e logs.
• Simulações com falha, falta de métricas, resultados não finitos ou incompatibilidade com o histórico da avaliação são considerados inválidos, não pontuação alta ou zero.
• Para múltiplos cantos, tome o pior caso conforme a convenção da métrica; cantos não executados são marcados como não verificados. A viabilidade das restrições tem prioridade sobre a melhoria de desempenho; não se pode usar médias para mascarar pontos violadores.

Busca e Parada

Siga adaptive-loop.md para escolher a estratégia:

• Loop Fechado Padrão do Agente: Leia o circuito, ponto de operação, métricas atuais e históricas, diagnostique as principais limitações, explique a suposição e justificativa para o próximo conjunto de parâmetros e execute apenas este conjunto. O iterate_params.py incluso executa apenas uma única avaliação por vez e retorna o controle ao Agente; o Agente atual raciocina por si mesmo, sem exigir a criação de um cliente Claude/Gemini/OpenAI API separado.
• Loop Fechado Bayesiano ou Híbrido: O bayes_suggest.py incluso reajusta um Processo Gaussiano com todas as observações válidas concluídas, priorizando a probabilidade de viabilidade/melhoria esperada restrita e sugerindo apenas um novo ponto. O Agente pode verificar a legalidade do dispositivo, simetria e suposições do circuito antes de aceitar ou revisar. Previsões não contam como medições reais; algumas tentativas iniciais não são uma varredura combinatória completa.
• Varredura Explícita/Busca Antiga: Use somente quando o usuário solicitar curvas, diagnóstico de sensibilidade local ou varredura exaustiva em um domínio discreto muito pequeno; search_params.py é mantido como entrada de compatibilidade e pertence a exploração local em grade/aleatória, não sendo chamado de raciocínio de IA ou otimização Bayesiana.

Os dois loops fechados padrão compartilham o adaptador de projeto, simulação real e contrato de log descritos em optimization.md. É possível alternar estratégias e continuar o mesmo histórico. Backends especializados como BoTorch/TuRBO podem substituir a camada de proposta após instalação e verificação; este kit atualmente não tem esses backends instalados ou testados, e não copia exemplos não verificados do Maestro do otimizador antigo.

Respeite o orçamento de simulações/tempo fornecido pelo usuário; se não especificado, declare um orçamento finito adequado à tarefa. Corrija erros de configuração repetidos antes de buscar; não prossiga com repetições infinitas. Quando o orçamento acabar, não houver pontos viáveis ou as medições não puderem ser realizadas, entregue as evidências atuais e os gargalos.

Entrega

Execute novamente os candidatos de forma independente e verifique as restrições; em seguida, forneça os parâmetros originais/melhores, métricas de linha de base/re-execução, configuração de medição, cantos, número de avaliações e evidências originais. Não trate previsões do otimizador como medições reais. Quando o usuário solicitar a aplicação dos parâmetros, escreva conforme autorização prévia e leia de volta; se for apenas exploração, mantenha o design de linha de base e os registros dos candidatos.

Quando houver um esquemático editável, marque permanentemente ao lado do circuito o tamanho real recomendado que foi verificado pela re-execução independente, com o título Recommended (verified), incluindo a unidade, condições/métricas críticas, data e o history/test final; salve e leia de volta conforme a Especificação de Desenho e Anotação de Recomendação. Mantenha expressões paramétricas dos dispositivos; as anotações de recomendação não substituem variáveis ADE. Em otimizações subsequentes, o Agente atualiza a mesma anotação gerenciada; quando as condições mudarem, registre claramente que o registro antigo é um resultado histórico e não pode ser falsamente chamado de configuração atual verificada. Se não houver ponto viável, não marque recomendação.

O fluxo de trabalho do usuário, por padrão, exige entrega visual: escreva de volta os melhores parâmetros viáveis no ADE e leia-os; execute novamente de forma independente com esses parâmetros; abra as formas de onda OUT dessa rodada, os valores de medição do Maestro e as variáveis de design; mantenha as janelas de esquemático, Maestro e ViVA abertas para o usuário continuar a modificação. Vincule explicitamente o history final; não mostre formas de onda da rodada anterior ou previsões do otimizador. A menos que o usuário solicite explicitamente apenas exploração ou fechar as janelas, não restaure a linha de base nem feche a sessão final no término. O ADE local relerá o startup projectDir global durante a execução; não se pode restaurar prematuramente após abrir a sessão. Antes de cada rodada, confirme o diretório de resultados autorizado; após a execução, consulte o local real; ao manter a sessão editável no final, preserve as configurações de diretório adequadas para o usuário continuar e registre os valores originais. Configurações persistentes específicas da sessão verificadas podem ter prioridade.

Para execução da plataforma de teste e exportação de resultados, use simulation-flow.md e Maestro API; não mantenha uma interface de simulação separada.