Artículo
AMD Ross: diseñar con agentes exige una revisión propia
1. Qué anunció AMD
El 30 de septiembre de 2026, AMD presentó Ross, un asistente agéntico para diseño y desarrollo embebido. Según el anuncio, reúne conexiones MCP, documentación de AMD, habilidades reutilizables y ejemplos para trabajar con herramientas de ingeniería. AMD limita su funcionamiento a permisos configurados y entornos compatibles; exige revisar resultados y acciones, y autorizar el uso de datos confidenciales, personales o regulados según modelo, herramienta y despliegue. El anuncio no aporta una medición independiente de velocidad o calidad.
Fuente: anuncio original de AMD.
2. Del código a una descripción de hardware
Como contexto técnico, el tutorial de Vitis HLS explica la transformación de C/C++ en RTL, una descripción destinada a la lógica programable. Su recorrido incluye simulación, síntesis y optimización. Son etapas de una herramienta de diseño, no pruebas de capacidades del asistente anunciado. Aquí usamos documentación 2026.1 para entender qué evidencia pedir en una revisión de ingeniería.
Referencia: introducción oficial a Vitis HLS.
3. Un filtro ficticio para discutir una propuesta
Ejemplo didáctico original, sin ejecución ni resultados medidos. Imaginemos un filtro de señal que promedia la lectura actual y la anterior. La especificación debe decidir qué ocurre con la primera muestra, cómo representa los valores y qué redondeo acepta. Proponemos conservar esa función mientras comparamos alternativas de diseño. Una modificación que altere esas reglas necesitaría una aceptación distinta, aunque conserve el nombre del filtro.
En el ejemplo, escribiríamos primero la regla en pseudocódigo y prepararíamos entradas para revisar el caso inicial. Esa descripción fija el comportamiento que queremos conservar; todavía no acredita una realización física.
4. Latencia y cadencia responden preguntas distintas
La guía de optimización describe el pipelining: una ejecución puede comenzar antes de que termine la anterior. Por eso conviene separar cuánto tarda una muestra en producir su salida de cada cuánto puede empezar la siguiente. Una menor espera para una muestra no demuestra por sí sola una mayor cadencia sostenida. Esta distinción debe aparecer al comparar propuestas.
¿Cuándo termina?
¿Cuándo empieza la siguiente?
Referencia: optimización y restricciones en HLS.
5. El presupuesto de recursos también importa
Ese mismo documento contempla objetivos de latencia y límites de recursos. Una comparación necesita revisar ambas dimensiones y las dependencias que condicionan el trabajo. Pedir una cadencia determinada expresa un objetivo; su cumplimiento debe comprobarse en los resultados correspondientes. Un cambio propuesto todavía necesita evidencia de qué consiguió y qué utilizó.
Para el filtro, redactaríamos dos preguntas separadas: cuándo estará disponible una salida y qué intervalo entre entradas intenta admitir la alternativa. El informe tendría que permitir seguir cada objetivo sin mezclarlo con el otro.
6. La estimación tiene una etapa
La documentación de implementación aclara que HLS estima frecuencia y uso de recursos sin conocer todavía las optimizaciones finales ni los retrasos del ruteo. Para un análisis más preciso describe síntesis con Vivado, colocación y ruteo del RTL generado, y revisión de informes de temporización y utilización. Una estimación HLS y un informe de implementación corresponden a etapas distintas.
Referencia: implementación e informes oficiales.
7. Identificar qué sostiene cada conclusión
| Evidencia | Propuesta que permite revisar | Dependencia pendiente |
|---|---|---|
| Estimación HLS | Objetivo previsto | Implementación posterior |
| Informe tras colocación y ruteo | Temporización y recursos de esa implementación | Condiciones del proyecto comparado |
La tabla es una síntesis didáctica propia del documento anterior. Conservar la etapa evita presentar una estimación como si describiera una implementación ya revisada.
Para nuestra comparación conservaríamos el mismo dispositivo de destino, las restricciones y la versión del proyecto. Si esas condiciones cambian, registraríamos la diferencia antes de discutir si los informes respaldan la misma conclusión.
8. Preparar una comparación que otra persona pueda cuestionar
Propuesta original de revisión para nuestro filtro ficticio. Antes de pedir cambios, el equipo podría escribir tres condiciones de aceptación: conservar el comportamiento acordado, explicar qué objetivo intenta mejorar y dejar una comparación recuperable. Son reglas que proponemos para este ejercicio, no resultados obtenidos ni instrucciones ejecutadas sobre una placa.
La primera revisión se concentra en el significado de la salida. Dos personas redactan, por separado, qué esperan de una entrada inicial, una secuencia constante y un cambio brusco. Después comparan sus respuestas. Si discrepan sobre el redondeo, anotar esa diferencia resulta más útil que continuar con una consigna ambigua. No asignamos valores de rendimiento a ninguno de esos casos.
La segunda revisión examina la propuesta del agente. Pedimos que identifique qué desea modificar, qué conservaría y qué pregunta intenta resolver. Una explicación que omita esas piezas vuelve difícil aceptar el cambio con conocimiento de su alcance.
Por último, proponemos conservar juntos la versión de partida, la alternativa, la pregunta de revisión y el motivo de la decisión. Otra persona debería poder encontrar dónde se justificó la aceptación y señalar qué evidencia falta. Si el equipo cambia también su criterio de éxito, tendría que declarar esa decisión antes de atribuir una mejora al nuevo diseño.
9. Convertir la revisión en un entregable útil
Para llevar esta conversación al trabajo, prepara una ficha de revisión de tu propia tarea. Incluye su propósito, una pregunta concreta, el material de partida y quién puede aceptar cambios. Puedes empezar con un ejercicio pequeño que no contenga datos sensibles y cuyo alcance pueda explicar otra persona.
En nuestro filtro imaginario, el entregable sería una decisión razonada sobre la alternativa propuesta. Si falta información, también puede contener una pregunta pendiente. La calidad del ejercicio depende de que el lector distinga qué se observó, qué se propone y qué queda por comprobar. Una frase persuasiva todavía necesita ese recorrido para convertirse en una decisión defendible.
Invita a un colega a revisar el material sin escuchar tu explicación inicial. Pídele que encuentre una condición ambigua, una conclusión demasiado amplia y una evidencia que cambiaría su opinión. Utiliza esas observaciones para mejorar la consigna antes de ampliar el trabajo.
El objetivo de esta práctica propia es terminar con una pregunta mejor delimitada y una revisión que pueda recuperarse. Cada equipo tendrá que decidir después qué evaluación necesita para su caso real.
