Parámetros de Virtuoso
Responsable de la modificación de parámetros, análisis de sensibilidad y optimización en bucle cerrado de circuitos existentes. Por defecto, tras cada simulación, el agente ChatGPT/Codex actual analiza y decide el siguiente conjunto de parámetros; no se genera un barrido completo de combinaciones W1×W2×… Se entregan "los mejores parámetros factibles verificados dentro del rango y presupuesto actuales", sin garantizar un óptimo global. El diseño topológico del circuito y la creación de nuevas plataformas de prueba no están dentro del alcance de esta habilidad.
Antes de comenzar
- Lea las convenciones de plataforma, lea la configuración compartida local según el protocolo de configuración del entorno; cuando necesite conexión, use virtuoso-connect. El intérprete, el alcance del trabajo, el PDK y las rutas se obtienen de la configuración.
- Defina claramente DUT/TB, definiciones de medición, objetivo, restricciones, unidades de parámetros/límites superior e inferior/pasos legales, esquinas y presupuesto de evaluación. Si puede deducirlo de la documentación del proyecto, primero organícelo; si faltan objetivos o límites que cambiarían los resultados, pregunte al usuario mientras lee el diseño existente.
- Guarde los parámetros originales y un resultado de referencia de una ronda. Si la plataforma de prueba está incompleta, entréguela primero a virtuoso-testbench; una vez completado el bucle de medición, continúe con la optimización.
Parámetros y evaluación
- Utilice preferentemente variables de ADE o netlists parametrizadas existentes, evitando reconstruir el circuito para cada candidato. Al modificar directamente CDF de MOS, consulte parameter-editing.md.
- Evalúe todos los candidatos con la misma configuración y esquinas; guarde la configuración antes de cada ejecución, asigne un directorio y un identificador independientes para esta ronda; al leer resultados, vincule explícitamente history, test, corner/point.
- Utilice las definiciones de medición existentes de ADE/OCEAN, especialmente el margen de fase debe provenir de una medición de bucle adecuada; no tome automáticamente la fase de cualquier voltaje de salida como PM.
- Se ha verificado localmente que SKILL/ADE cambia variables y ejecuta, y que subprocesos OCEAN independientes leen PSF específicos y métricas JSON para realimentar el buscador; utilícelo según ocean-skill-flow.md, conservando todos los identificadores de ejecución y registros.
- Fallos de simulación, métricas faltantes, valores no finitos o historial de resultados no coincidente son evaluaciones no válidas; no se tratan como puntuaciones altas o cero.
- Cuando se requieran múltiples esquinas, tome el peor valor según las convenciones de métricas; las esquinas no ejecutadas se marcan como no verificadas. La factibilidad de las restricciones tiene prioridad sobre la mejora del rendimiento; no se pueden usar promedios para ocultar puntos de incumplimiento.
Búsqueda y parada
Siga adaptive-loop.md para elegir la estrategia:
- Bucle cerrado de agente por defecto: Lee el circuito y el punto de operación, las métricas actuales e históricas, diagnostica las principales limitaciones, explica la hipótesis y la razón del siguiente conjunto de parámetros, y luego ejecuta solo ese conjunto. Incluye iterate_params.py que realiza solo una evaluación por vez y devuelve el control al agente; el agente actual razona por sí mismo, no se requiere crear otro cliente API de Claude/Gemini/OpenAI.
- Bucle cerrado Bayesiano o híbrido: Incluye bayes_suggest.py que reajusta un proceso Gaussiano con todas las observaciones válidas completadas, prioriza la probabilidad de factibilidad/mejora esperada restringida, y sugiere solo un nuevo punto. El agente puede verificar la legalidad del dispositivo, la simetría y las hipótesis del circuito antes de aceptar o revisar. Las predicciones no cuentan como mediciones reales; un pequeño número de pruebas iniciales no es un barrido completo de combinaciones.
- Barrido explícito/búsqueda antigua: Se usa solo cuando el usuario solicita curvas, diagnostica sensibilidad local o explora dominios discretos muy pequeños; search_params.py se conserva como entrada de compatibilidad, es una exploración local de cuadrícula/aleatoria, no se denomina razonamiento de IA ni optimización Bayesiana.
Ambos bucles cerrados por defecto comparten el adaptador de proyecto, la simulación real y el contrato de registro de optimization.md. Se puede cambiar de estrategia continuando con el mismo historial. Backends especializados como BoTorch/TuRBO pueden reemplazar la capa de propuesta después de instalación y verificación; este kit actualmente no tiene instalados ni probados estos backends, no copie ejemplos no verificados de Maestro de un optimizador anterior.
Respete el presupuesto de simulación/tiempo dado por el usuario; si no se especifica, declare un presupuesto finito adecuado para la tarea. Primero corrija los errores de configuración repetidos antes de buscar; no avance mediante reintentos infinitos. Cuando se agote el presupuesto, no haya puntos factibles o la medición no se pueda realizar, entregue la evidencia actual y los cuellos de botella.
Entrega
Vuelva a ejecutar de forma independiente los candidatos y verifique las restricciones, luego proporcione los parámetros originales/mejores, las métricas de referencia/re-ejecución, la configuración de medición, las esquinas, el número de evaluaciones y la evidencia original. No tome las predicciones del optimizador como mediciones reales. Cuando el usuario solicite aplicar parámetros, escríbalos con la autorización existente y léalos de nuevo; si solo es exploración, conserve el diseño de referencia y los registros de candidatos.
Cuando haya un esquemático editable, marque permanentemente las dimensiones recomendadas reales que hayan pasado la re-ejecución independiente al lado del circuito, con el título Recommended (verified), incluyendo unidades, condiciones/métricas clave, fecha y history/test final; guárdelo y léalo de nuevo según especificaciones de dibujo y etiquetado de recomendaciones. Conserve las expresiones paramétricas del dispositivo; las anotaciones de recomendación no reemplazan las variables de ADE. Las actualizaciones de optimización posteriores gestionan la misma anotación gestionada por el agente; cuando cambien las condiciones, indique claramente que el registro anterior es un resultado histórico, no se puede afirmar incorrectamente que es una configuración actual verificada. Si no hay puntos factibles, no marque recomendaciones.
El flujo de trabajo del usuario por defecto requiere entrega visual: escriba los mejores parámetros factibles de esta ronda en ADE y léalos de nuevo, vuelva a ejecutar de forma independiente con estos parámetros; abra las formas de onda OUT y los valores de medición de Maestro y las variables de diseño de esa ronda, conserve las ventanas de esquemático, Maestro y ViVA para que el usuario continúe modificando. Vincule explícitamente el history final; no puede mostrar formas de onda de la ronda anterior ni predicciones del agente. A menos que el usuario solicite explícitamente solo exploración o cerrar ventanas, no restaure la línea base ni cierre la sesión final al terminar. ADE local volverá a leer el startup projectDir global durante la ejecución; no se puede restaurar antes de abrir la sesión. Confirme el directorio de resultados autorizado antes de cada ronda de ejecución, consulte la ubicación real después de la ejecución; si se conserva una sesión editable, mantenga la configuración del directorio adecuada para que el usuario continúe ejecutando y registre el valor original. La configuración persistente específica de la sesión verificada puede tener prioridad.
La ejecución de la plataforma de prueba y la exportación de resultados utilizan simulation-flow.md y API de Maestro; no mantenga una interfaz de simulación separada.