Comandos de motor de la CLI

Descripción general

Esta página cubre los comandos de motores locales de diseño, sus argumentos principales y sus límites de ejecución. Usa la ayuda específica --help del comando instalado para conocer su lista completa de opciones y valores enumerados. Lee los límites propios del resultado antes de usarlo como evidencia de ingeniería.

Lee primero Interfaz de comandos de la CLI. Define el enrutado, los códigos de salida, los sobres de comprobantes y la regla de resolución entre ejecutables del mismo directorio de la que dependen todos los comandos siguientes. El espacio de nombres job, analyze run, y evolve run están en Comandos de trabajos y Cloud de la CLI.

Convenciones utilizadas en las tablas:

• <ANGLE> es un argumento posicional; [ANGLE]... es uno opcional repetible.

• Las opciones de la columna Obligatorio deben estar presentes o el comando termina con 2 antes de iniciar nada.

• Todos los subcomandos también aceptan --json y -h/--help. No se repiten en cada fila.

• --project es --project <PROJECT>, un directorio de trabajo opcional para rutas relativas de entrada y salida, salvo que una fila indique otra cosa. Debe resolverse a un directorio real; un valor que no pueda resolverse termina con 2.

capabilities

alti capabilities inspecciona la estructura de instalación autenticada e informa de las operaciones que ofrece. Completa primero Instalación en Linux; el bootstrap integrado de 0.1.9 proporciona la estructura de comprobantes y carga útil que antes faltaba. Una respuesta de capacidades no es evidencia de que se haya ejecutado un kernel o un diseño.

rtl

Veintiocho subcomandos. rtl compile y rtl synthesize son las dos rutas de compatibilidad que incluyen --runner; todos los demás subcomandos rtl se ejecutan de forma local e incondicional.

A diferencia de physical run y px analyze, esas dos sí inician su motor sin argumentos de paso directo, porque cada una proporciona una operación fija del motor. El motor informa entonces de su propio error por argumentos ausentes y su estado de salida se transmite sin cambios. Dales los argumentos necesarios después de --.

--schematic en los tres subcomandos rtl artifact selecciona el almacén fijo de comprobantes de esquemático en lugar del almacén de resultados de operaciones RTL.

--entry-id en los comandos específicos de identidad confirmada debe ser exactamente 64 caracteres hexadecimales en minúsculas. Cualquier otro valor termina con 2 con entry id must be exactly 64 lowercase hexadecimal characters.

Límites de rtl schematic

rtl schematic valida sus rutas antes de iniciar nada. Se rechaza en la admisión cada archivo fuente, directorio de includes o define que incumpla uno de estos límites:

Las rutas deben ser relativas al proyecto seleccionado, no deben empezar por -, no deben contener bytes de control ni ... --top y un nombre de define deben ser identificadores de SystemVerilog de 1 a 128 bytes; un define puede incluir un valor después de = hasta un total de 4096 bytes.

Opciones de rtl target-analysis

admit y preflight leen JSON canónico de paquete de código fuente desde stdin y ambos requieren las mismas once opciones: --module <NAME>, --top <NAME>, --targets <CSV>, --primary-target <ID>, --tools <CSV>, --report-detail <LEVEL>, --profile <ID>, --cpu-slots <N>, --memory-bytes <N>, --max-wall-time-ms <N>, y --deadline-unix-ms <N>. --cell-decomposition es un indicador booleano opcional.

--cpu-slots es un entero sin signo de 32 bits; --memory-bytes, --max-wall-time-ms, y --deadline-unix-ms son enteros sin signo de 64 bits.

Un valor duplicado o no enumerado en cualquiera de los CSV se rechaza al analizar, por ejemplo targets must be a comma-separated subset of: generic-asic, sky130-asic, xc7-fpga.

El sobre de solicitud de simulación

<REQUEST_JSON> es una ruta relativa al proyecto a un archivo que la CLI lee y comprueba antes de iniciar nada. La ruta debe estar normalizada y ser relativa, no debe atravesar enlaces simbólicos en ningún componente y debe resolverse dentro de la raíz del proyecto. El archivo debe ser regular y no superar los 260 MiB.

Su JSON debe ser un objeto con exactamente cuatro claves:

{
  "schema": "altifigence.rtl.operation-request.v1",
  "version": 1,
  "operationId": "altifigence.rtl.simulate.v1",
  "request": {}
}

operationId debe ser altifigence.rtl.simulate.v1 para rtl simulate y altifigence.rtl.simulate.v2 para rtl simulate-v2. Una discrepancia se rechaza antes del inicio con RTL simulation request must be the exact <id> envelope.

Los subcomandos de identidad confirmada no pueden ejecutarse

Los ocho comandos específicos rtl *-committed-identities list y read despachan a un motor llamado alti-rtl-runner. Ese binario no es uno de los 24 binarios de motor que la versión compila y distribuye, por lo que no puede resolverse como ejecutable del mismo directorio que alti ni mediante PATH en una instalación correcta. Invocar uno produce un comprobante de motor local con status: "unavailable" y exitCode: 127:

Texto

$ alti --json rtl fanout-free-committed-identities list
{
  "schema": "altifigence.local-engine-execution.v1",
  "status": "unavailable",
  "domain": "rtl",
  "operation": "fanout-free-committed-identities-list",
  "runner": "local",
  "binary": "alti-rtl-runner",
  ...
}

No bases la automatización en estos ocho comandos.

sv

Veintitrés subcomandos, todos locales e incondicionales. Ninguno acepta --runner.

Reglas de valores posicionales:

• <LINE> y <COLUMN> son enteros distintos de cero con base 1. 0 termina con 2.

• <REPLACEMENT> debe ser un identificador de SystemVerilog: el primer carácter es una letra, _, o $, y el resto son caracteres alfanuméricos, _, o $.

• <REVIEWED_PLAN_SHA256> debe tener 64 caracteres hexadecimales en minúsculas.

• <STABLE_ID> debe tener entre 1 y 128 caracteres de letras minúsculas, dígitos y guiones.

• --filter debe tener entre 1 y 128 bytes que no sean de control; --limit debe ser un entero entre 1 y 64, y --limit 65 termina con 2.

sv frontend rename-apply es el único subcomando sv que requiere --project, y el valor debe ser una ruta absoluta a un directorio real que no sea un enlace simbólico. Sin él, el comando termina con 1 con SV rename apply requires --project <absolute-workspace>.

sv review immediate y sv review interprocess leen código fuente SystemVerilog desde stdin. Son los únicos subcomandos sv respaldados por sus propios motores, alti-sv-immediate-review y alti-sv-interprocess-review; todo lo demás en el espacio de nombres usa alti-sv-frontend.

sv uvm simulation admit requiere trece opciones: --bundle-id, --bundle-sha256, --source-count, --source-bytes, --test, --top, --clock, --period-ps, --cycles, --max-wall-time-ms, --max-cpu-cores, --max-memory-bytes, y --max-artifact-bytes. sv uvm simulation preflight requiere esas trece más --attempt-id, --observed-at-unix-ms, y --deadline-unix-ms, y además acepta el booleano --cancellation-requested (predeterminado false). --source-count es un entero sin signo de 32 bits, --max-cpu-cores es un entero sin signo de 16 bits y las opciones numéricas restantes son enteros sin signo de 64 bits.

verification

--tolerance-pct debe ser un número finito no negativo; un valor negativo o no numérico termina con 2 con tolerance-pct must be a finite non-negative number.

--format aquí selecciona el formato de salida propio del motor y es independiente del indicador de sobre --json de nivel CLI. Ambos pueden usarse juntos.

trace

<FORMAT> en trace export es un valor enumerado posicional, no un indicador, y precede a la ruta de entrada. Sus valores son vcd y chrome.

--reference puede repetirse para indicar artefactos de referencia adicionales. <TRACE_ARTIFACT_ID>, los IDs de referencia y <PACKAGE_ID> pueden empezar por un guion sin necesidad de --.

Ten en cuenta que alti trace sin subcomando llega al analizador local y termina con 2 solicitando un subcomando. Por ello, la acción de una sola palabra trace del manifiesto de acciones integrado no es accesible desde la línea de comandos en esta versión; consulta Comandos de trabajos y Cloud de la CLI.

labs

Descriptores de solo lectura y validación. La CLI no ofrece ejecución de flujos de trabajo.

labs validate es estricto con sus dos entradas y se comprueban todas las reglas siguientes antes de iniciar el motor:

• --project debe ser una ruta absoluta a un directorio real, no un enlace simbólico.

• <DESCRIPTOR> debe ser relativa al espacio de trabajo, no contener .. ni componente de raíz y tener como máximo 4096 bytes.

• Debe usar la extensión .json.

• Debe resolverse a un archivo regular real de como máximo 1048576 bytes, y la ruta resuelta debe seguir dentro del proyecto.

tcl

Los cuatro primeros responden a partir de descriptores mediante el motor empaquetado alti-tcl y emiten el sobre estándar de motor local.

tcl evaluate difiere en tres aspectos. Lee el script desde stdin, con un límite de 4194304 bytes; se rechaza una entrada vacía. Requiere alti-tcl-local-runner como ejecutable estrictamente en el mismo directorio que alti sin alternativa mediante PATH, y lo comprueba con la cadena de confianza instalada. El bootstrap de 0.1.9 instala el componente fijo de Tcl firmado necesario para esta ruta; usa el binario instalado. Además, emite su propio esquema de comprobantes, altifigence.cli.tcl-evaluation.v1, con sus propios códigos de salida; ambos se describen en Interfaz de comandos de la CLI.

eidb

eidb capabilities, eidb readback, y eidb semantic-readback no aceptan --project; carecen de rutas respecto a la CLI.

physical

Cuarenta y dos subcomandos. physical run es la ruta de compatibilidad que incluye --runner; el resto se ejecutan local e incondicionalmente, y cada uno transmite directamente su nombre de subcomando a alti-physical-runner como operación del motor. El papel de la CLI en este espacio de nombres es admitir argumentos y enmarcar comprobantes, por lo que la interfaz es lo bastante uniforme para presentarla en dos grupos.

Cada operación posterior con ámbito de entrada lee una entrada persistida producida por una operación anterior con ámbito de proyecto. Omitir --entry-id hace que termine con 2 antes de iniciar nada. Eso cubre treinta y seis de los cuarenta y dos. Los seis restantes son:

physical route-evidence-closure read es un comando de dos pasos: la CLI enumera primero las identidades confirmadas, exige que tu --identity-key-sha256 aparezca en esa lista y después vuelve a leer exactamente esa. Una clave que no tenga 64 caracteres hexadecimales en minúsculas o no esté en la lista actual se rechaza con salida 1 antes del segundo paso. El paso de listado no tiene rutas ni acepta --project.

physical run no se inicia sin una operación del motor después de --:

Texto

$ alti physical run
error: legacy local engine operation is required after `--`

Eso termina con 1. Las operaciones heredadas aceptadas son --capabilities-json, capabilities, y execute; cualquier otra termina con 1 con legacy local engine operation ... is not in the public allowlist.

px

px analyze es la ruta de compatibilidad que incluye --runner. Cuando un argumento posicional se llama <INPUTS_RELATIVE_...>, se resuelve bajo el directorio inputs/ del proyecto, no respecto a tu directorio de trabajo.

Tres de estos indican sus propios límites en su texto de ayuda, y esos límites forman parte del contrato: px static-timing explícitamente no proporciona aprobación final, px spef-summary explícitamente no confiere autoridad de análisis, y px fdtd2d preflight informa de un bloqueo de preparación en lugar de un resultado. Trata sus salidas conforme a ello.

Al igual que physical run, px analyze requiere una operación heredada después de -- y, si falta, termina con 1. Su lista de operaciones permitidas es capabilities y execute.

Operaciones PX de CPU y CUDA

Estos comandos aceptan --project; los dos primeros también aceptan --timeout-ms 1..300000. El valor explícito cuda requiere ejecución CUDA utilizable. auto permite por separado la alternativa de CPU registrada por el motor; inspecciona el backend informado. Estas operaciones numéricas acotadas no acreditan aprobación final física general ni aceleración de todas las operaciones PX por GPU.

isa

Cuatro de los seis subcomandos leen código fuente CX exclusivamente desde stdin. isa run es la ruta de compatibilidad que incluye --runner.

--check acepta exactamente elaboration, static-semantics, encoding-uniqueness, y decode-determinism. --bit-len es un entero sin signo de 32 bits. --text y --bits no deben estar vacíos ni contener solo espacios en blanco.

A diferencia de physical run y px analyze, isa run incluye una operación fija del motor, por lo que se inicia sin argumentos de paso directo y el motor informa de sus propios requisitos:

Texto

$ alti isa run
cx run: run requires --program <path> or --program-text
[failed] isa.run runner=local engine=alti-cx/run executable=alti-cx resolution=path exit=1 project=.

ide

Operaciones del host de escritorio. Los cálculos permanecen en los espacios de nombres de motor anteriores.

ide open inicia la aplicación de escritorio instalada por separado. Los comandos nativos de espacio de trabajo, Cloud, servicio y creación de proyectos siguientes funcionan mediante sus propios backends explícitos.

--project debe ser un directorio absoluto canónico: absoluto, un directorio existente, no un enlace simbólico e igual a su propia forma canónica. Una ruta que se resuelva mediante un enlace simbólico se rechaza en lugar de seguirse silenciosamente.

ide open no usa un binario de motor. Resuelve un ejecutable llamado altifigence-ide en el mismo directorio que alti y después mediante PATH, lo inicia con --project <canonical-dir> y emite un comprobante altifigence.ide-launcher-receipt.v1:

El estado de salida es 0 para spawned y 1 en caso contrario. altifigence-ide se distribuye con Digital Design Studio, no con el archivo de la CLI, por lo que ide open informa de unavailable en una instalación que solo incluya la CLI.

Operaciones nativas de proyecto y espacio de trabajo

ide init --parent ABSOLUTE_DIR --name NAME crea una estructura inicial nueva bajo un directorio padre canónico propiedad de quien invoca. No sobrescribe un proyecto existente. ide workspace opera sobre archivos locales guardados sin abrir la interfaz:

El resultado del plan nativo es una entrada de aplicación completa y opaca. Guarda la salida sin procesar del motor sin el indicador global --json, revísala y después pasa el mismo documento a su comando de aplicación correspondiente. Por ejemplo, con tu proyecto absoluto existente y una solicitud tipada de jerarquía:

alti ide workspace hierarchy-plan --project "$PROJECT" \
  --request "$HIERARCHY_REQUEST" > "$PLAN_FILE"
# Review the complete plan and changed source before the next command.
alti ide workspace hierarchy-apply --project "$PROJECT" --request "$PLAN_FILE"

No canalices la salida de un comando fallido a la aplicación. Elige un archivo de plan nuevo y comprueba cada estado de salida. La autoría de archivos usa transacciones duraderas y serializadas y hashes actuales del código fuente; no ofrece atomicidad instantánea de todo el sistema de archivos frente a procesos de escritura ajenos. Los conflictos requieren una nueva revisión. La autoría de jerarquías es selección de código fuente y creación de estructuras acotadas, no refactorización semántica completa de SystemVerilog ni prueba de equivalencia.

Los ajustes conservan el formato DDS .alti/ide-settings.json, las claves desconocidas y los valores literales null. El parche es una fusión recursiva, no una eliminación de RFC 7396. El presupuesto de solicitud y resultado es de 256 KiB y profundidad 8; la interfaz nativa y la CLI usan el mismo .alti/.ide-settings.lock. La CLI se dirige al formato actual de proyecto, no a un segundo ámbito independiente de ajustes globales de escritorio.

Las transacciones nativas y Git requieren el contrato de Linux. La recuperación actual lee diarios tanto V1 como V2. Después de interrumpir una creación o eliminación, o una aplicación de jerarquía, ejecuta health de la CLI nueva antes de abrir un backend DDS antiguo que solo admita V1. Un backend anterior rechaza un diario V2 pendiente sin borrarlo. Las transacciones completadas normalmente borran su diario activo; se recomienda actualizar a un backend de recuperación transparente, pero no es un requisito previo para cada edición completada de CLI.

Git

En ide workspace git, todos los comandos aceptan --project ABS:

Estas operaciones recuperan y se serializan respecto a las transacciones nativas del espacio de trabajo. No ofrecen argumentos Git arbitrarios, hooks ni credenciales de push remoto.

Búsqueda en código fuente guardado

alti ide workspace search --project "$PROJECT" --query 'module' --limit 80

La búsqueda nativa admite --match-case, --whole-word, un --regex conservador de ancho fijo, límites de 1 a 500 coincidencias y --timeout-seconds 1..120. Lee texto guardado mediante el límite nativo files/read, con presupuestos de 500 archivos, 4 MiB por archivo, 16 MiB en total y 1 MiB de salida. Comprueba el truncamiento y la evidencia de contenido. No se buscan los búferes del editor sin guardar. La búsqueda de Cloud y la búsqueda y reemplazo HTTP heredados son operaciones de servicio.

xls

La ruta nativa admite funciones DSLX y XLS IR acotadas con valores de 1 a 64 bits, plegado de constantes y eliminación de código muerto, y RTL combinacional o RTL con 1 a 16 etapas de registros de salida. La solicitud selecciona cpu, o explícitamente cuda para evaluación por lotes compatible. Un backend CUDA no disponible es un error, no una ejecución automática en CPU. Empieza con el ejemplo de CPU.

La ruta upstream independiente instala una cadena de herramientas pública de Google XLS para Linux con versión fijada, verifica su archivo y el inventario de herramientas y stdlib, y conserva los archivos de licencia. Admite imports, parámetros, structs, enums, tipos agregados y de ancho arbitrario, y procs cuando la herramienta upstream seleccionada admite la operación solicitada. No usa el analizador acotado bits64 ni acelera toda la cadena de herramientas de Google con CUDA.

Las solicitudes upstream seleccionan check, eval, convert, optimize, o codegen. La evaluación DSLX sin vectores ni ticks explícitos ejecuta pruebas reales del módulo; cero pruebas unitarias ejecutadas no es éxito. El archivo base no contiene los ejecutables de evaluación independientes de IR o procs. Los vectores explícitos o ticks de canal requieren un paquete adicional verificado de evaluadores admitido durante la instalación con --evaluator-bundle y --evaluator-manifest-sha256. Inspecciona las capacidades antes de solicitar esas operaciones. La generación de código de pipeline upstream admite de 1 a 64 etapas; su planificación con retardo unitario no es temporización caracterizada de silicio.

compute

Los comandos de solicitud aceptan --project. La entrada de simulación y Evolve está limitada a 4 MiB; la de verificación, a 16 MiB. El componente empaquetado alti-rtl-cuda es responsable de esta ruta. compute rtl-evolve acepta altifigence.rtl.evolve-request.v1, con la solicitud existente de generación nativa anidada en request; no es un sobre de operación evolve run.

Evolve CUDA calcula diagnósticos acotados de actividad combinacional. La generación de candidatos, las comprobaciones de corrección, la síntesis y la evaluación del objetivo permanecen en CPU. Los ejecutables reales de Icarus iverilog y vvp deben estar disponibles mediante la configuración de herramientas del host. cpu-reference requiere cuda_timeout_ms: 0 y device_memory_bytes: 0; cuda rechaza la ejecución no disponible en lugar de usar una alternativa. Usa un request.run_dir nuevo con un directorio padre existente.

La solicitud limita las generaciones y los descendientes de 1 a 16, las islas de 1 a 4, las evaluaciones planificadas totales a 256 y los descendientes LLM a cero. La memoria del dispositivo es un presupuesto acotado de búfer del proceso de trabajo, no un límite de la memoria total del controlador. El valor local opcional cancel_file y los plazos permiten cancelación cooperativa; las llamadas a herramientas nativas conservan sus propios límites. Un resultado CUDA satisfactorio necesita actividad real de candidatos aceptados y procedencia de hardware almacenada, no solo detección de dispositivos o una prueba inicial. La coincidencia funcional entre CPU y CUDA no es una afirmación de aceleración.

Comandos ausentes de la descarga actual

Los espacios de nombres anteriormente omitidos eda y reports ya se enrutan:

Estas son operaciones acotadas de inspección, análisis sintáctico o vinculación, no ejecución general de herramientas EDA. ide init y los comandos nativos explícitos de Evolve también están disponibles. La ruta de compatibilidad alti-rtl-runner no distribuida descrita antes sigue siendo una limitación independiente; no infieras compatibilidad solo a partir de la ayuda.

Prepara un flujo de motor

1. Elige la operación y lee su respuesta de capacidades instaladas y la ayuda específica del comando.

2. Crea una pequeña entrada guardada dentro del proyecto seleccionado e identifica su módulo superior o punto de entrada.

3. Proporciona las herramientas externas necesarias y usa un backend explícito cuando la solicitud permita seleccionar CPU/CUDA.

4. Ejecuta una vez con recursos acotados y conserva los diagnósticos y el resultado nativo completo.

5. Inspecciona el backend real, las entradas, los artefactos de salida y las métricas no compatibles antes de crear un flujo más amplio.

Usa Análisis de DDS para el flujo gráfico y Evolve para comparar candidatos. La compatibilidad del motor de CLI, un panel de escritorio y una ruta de Cloud son integraciones distintas; comprueba el flujo que realmente usarás.