Commandes CLI des moteurs

Présentation

Cette page présente les commandes des moteurs de conception locaux, leurs principaux arguments et leurs limites d’exécution. Consultez l’aide --help de la commande installée pour obtenir la liste complète des options et des valeurs énumérées. Lisez les limites propres au résultat avant de l’utiliser comme preuve d’ingénierie.

Lisez d’abord Surface des commandes CLI. Cette page définit le routage, les codes de sortie, les enveloppes de reçus et la règle de résolution des exécutables voisins dont dépendent toutes les commandes ci-dessous. L’espace de noms job, analyze run, et evolve run sont présentés dans Commandes CLI pour les tâches et le Cloud.

Conventions utilisées dans les tableaux :

• <ANGLE> est un argument positionnel ; [ANGLE]... est une option facultative répétable.

• Les options de la colonne Requis doivent être présentes, sinon la commande se termine avec le code 2 avant tout lancement.

• Chaque sous-commande accepte également --json et -h/--help. Ces options ne sont pas répétées dans chaque ligne.

• --project est --project <PROJECT>, un répertoire de travail facultatif pour les chemins d’entrée et de sortie relatifs, sauf indication contraire dans une ligne. Il doit correspondre à un répertoire réel ; une valeur impossible à résoudre entraîne le code de sortie 2.

capabilities

alti capabilities inspecte l’installation authentifiée et indique les opérations disponibles. Effectuez d’abord Installation sous Linux ; le bootstrap intégré de la version 0.1.9 fournit les reçus et l’organisation des charges utiles auparavant manquants. Une réponse de capacité ne prouve pas l’exécution d’un noyau ou d’une conception.

rtl

Vingt-huit sous-commandes. rtl compile et rtl synthesize sont les deux chemins de compatibilité portant --runner ; toutes les autres sous-commandes rtl s’exécutent localement et sans condition.

Contrairement à physical run et px analyze, ces deux commandes lancent leur moteur sans arguments transmis, car chacune fournit une opération fixe au moteur. Celui-ci signale alors ses propres arguments manquants et son code de sortie est transmis sans modification. Fournissez les arguments requis après --.

--schematic sur les trois sous-commandes rtl artifact sélectionne le magasin fixe de reçus de schéma au lieu du magasin des résultats d’opérations RTL.

--entry-id sur les commandes terminales d’identité enregistrée doit contenir exactement 64 caractères hexadécimaux minuscules. Toute autre valeur entraîne le code de sortie 2 avec entry id must be exactly 64 lowercase hexadecimal characters.

Limites de rtl schematic

rtl schematic valide ses chemins avant tout lancement. Chaque fichier source, répertoire d’inclusion et définition est rejeté à l’admission s’il enfreint l’une des règles suivantes :

Les chemins doivent être relatifs au projet sélectionné, ne doivent pas commencer par -, ne doivent pas contenir d’octets de contrôle et ne doivent pas contenir ... --top et le nom d’une définition doivent être des identifiants SystemVerilog de 1 à 128 octets ; une définition peut porter une valeur après = dans une limite totale de 4096 octets.

Options de rtl target-analysis

admit et preflight lisent le JSON canonique du paquet de sources sur stdin et exigent les mêmes onze options : --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>, et --deadline-unix-ms <N>. --cell-decomposition est un indicateur booléen facultatif.

--cpu-slots est un entier non signé de 32 bits ; --memory-bytes, --max-wall-time-ms, et --deadline-unix-ms sont des entiers non signés de 64 bits.

Toute valeur dupliquée ou absente de la liste dans l’un des CSV est refusée à l’analyse des arguments, par exemple targets must be a comma-separated subset of: generic-asic, sky130-asic, xc7-fpga.

L’enveloppe de la requête de simulation

<REQUEST_JSON> est un chemin relatif au projet vers un fichier que le CLI lit et vérifie avant tout lancement. Ce chemin doit être normalisé et relatif, ne doit traverser aucun lien symbolique et doit aboutir à l’intérieur de la racine du projet. Le fichier doit être un fichier ordinaire de 260 MiB au maximum.

Son JSON doit être un objet comportant exactement quatre clés :

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

operationId doit valoir altifigence.rtl.simulate.v1 pour rtl simulate et altifigence.rtl.simulate.v2 pour rtl simulate-v2. Une incompatibilité est refusée avant le lancement avec RTL simulation request must be the exact <id> envelope.

Les sous-commandes d’identité enregistrée ne peuvent pas s’exécuter

Les huit commandes terminales rtl *-committed-identities list et read sont acheminées vers un moteur nommé alti-rtl-runner. Ce binaire ne fait pas partie des 24 binaires de moteurs compilés et livrés dans la version ; il est donc introuvable aussi bien à côté de alti que dans PATH dans une installation correcte. L’invocation de l’une de ces commandes produit un reçu de moteur local avec status: "unavailable" et exitCode: 127:

Texte

$ 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",
  ...
}

Ne construisez pas d’automatisation sur ces huit commandes.

sv

Vingt-trois sous-commandes, toutes locales et inconditionnelles. Aucune n’accepte --runner.

Règles des valeurs positionnelles :

• <LINE> et <COLUMN> sont des entiers non nuls indexés à partir de 1. 0 entraîne le code de sortie 2.

• <REPLACEMENT> doit être un identifiant SystemVerilog : son premier caractère est une lettre, _, ou $, et les suivants sont alphanumériques, _, ou $.

• <REVIEWED_PLAN_SHA256> doit comporter 64 caractères hexadécimaux minuscules.

• <STABLE_ID> doit comporter de 1 à 128 caractères parmi les lettres minuscules, les chiffres et les traits d’union.

• --filter doit comporter de 1 à 128 octets hors caractères de contrôle ; --limit doit être un entier compris entre 1 et 64, et --limit 65 entraîne le code de sortie 2.

sv frontend rename-apply est la seule sous-commande sv qui exige --project, dont la valeur doit être un chemin absolu vers un répertoire réel qui n’est pas un lien symbolique. Sans cette option, la commande se termine avec le code 1 avec SV rename apply requires --project <absolute-workspace>.

sv review immediate et sv review interprocess lisent la source SystemVerilog sur stdin. Ce sont les seules sous-commandes sv prises en charge par leurs propres moteurs, alti-sv-immediate-review et alti-sv-interprocess-review ; toutes les autres de cet espace de noms utilisent alti-sv-frontend.

sv uvm simulation admit exige treize options : --bundle-id, --bundle-sha256, --source-count, --source-bytes, --test, --top, --clock, --period-ps, --cycles, --max-wall-time-ms, --max-cpu-cores, --max-memory-bytes, et --max-artifact-bytes. sv uvm simulation preflight exige ces treize options ainsi que --attempt-id, --observed-at-unix-ms, et --deadline-unix-ms, et accepte en plus le booléen --cancellation-requested (par défaut false). --source-count est un entier non signé de 32 bits, --max-cpu-cores est un entier non signé de 16 bits, et les autres options numériques sont des entiers non signés de 64 bits.

verification

--tolerance-pct doit être un nombre fini non négatif ; une valeur négative ou non numérique entraîne le code de sortie 2 avec tolerance-pct must be a finite non-negative number.

--format sélectionne ici le format de sortie propre au moteur, indépendamment de l’indicateur d’enveloppe --json du CLI. Les deux peuvent être utilisés ensemble.

trace

<FORMAT> dans trace export est une valeur énumérée positionnelle, et non un indicateur ; elle précède le chemin d’entrée. Ses valeurs sont vcd et chrome.

--reference peut être répété pour nommer des artefacts de référence supplémentaires. <TRACE_ARTIFACT_ID>, les identifiants de référence et <PACKAGE_ID> peuvent commencer par un trait d’union sans nécessiter --.

Notez que alti trace sans sous-commande atteint l’analyseur local et se termine avec le code 2 en demandant une sous-commande. L’action d’un seul mot trace du manifeste d’actions intégré n’est donc pas accessible depuis la ligne de commande dans cette version ; consultez Commandes CLI pour les tâches et le Cloud.

labs

Descripteurs et validation en lecture seule. L’exécution des workflows n’est pas exposée par le CLI.

labs validate impose des règles strictes à ses deux entrées, toutes vérifiées avant le démarrage du moteur :

• --project doit être un chemin absolu vers un répertoire réel, et non un lien symbolique.

• <DESCRIPTOR> doit être relatif à l’espace de travail, ne doit contenir ni .. ni composant racine, et ne doit pas dépasser 4096 octets.

• Il doit utiliser .json comme extension.

• Il doit aboutir à un fichier ordinaire réel de 1048576 octets au maximum, et le chemin résolu doit rester à l’intérieur du projet.

tcl

Les quatre premières répondent à partir de descripteurs via le moteur fourni alti-tcl et produisent l’enveloppe standard de moteur local.

tcl evaluate se distingue sur trois points. Elle lit le script sur stdin, avec une limite de 4194304 octets ; une entrée vide est refusée. Elle exige alti-tcl-local-runner strictement à côté de alti sans recours à PATH, et le vérifie selon la chaîne de confiance installée. Le bootstrap 0.1.9 installe le composant Tcl fixe signé nécessaire à ce chemin ; utilisez le binaire installé. Elle produit également son propre schéma de reçu, altifigence.cli.tcl-evaluation.v1, avec ses propres codes de sortie — tous deux sont décrits dans Surface des commandes CLI.

eidb

eidb capabilities, eidb readback, et eidb semantic-readback n’acceptent pas --project ; ces commandes sont sans chemin du point de vue du CLI.

physical

Quarante-deux sous-commandes. physical run est le chemin de compatibilité portant --runner ; les autres s’exécutent localement et sans condition, et transmettent directement leur nom de sous-commande à alti-physical-runner comme opération du moteur. Le rôle du CLI dans cet espace de noms est l’admission des arguments et l’encadrement des reçus ; la surface est donc assez régulière pour être présentée en deux groupes.

Chaque opération de suivi d’une entrée lit une entrée persistée produite par une opération précédente à l’échelle du projet. L’absence de --entry-id entraîne le code de sortie 2 avant tout lancement. Cela concerne trente-six des quarante-deux commandes. Les six restantes sont :

physical route-evidence-closure read est une commande en deux étapes : le CLI liste d’abord les identités enregistrées, exige que votre --identity-key-sha256 figure dans cette liste, puis relit précisément celle-ci. Une clé qui ne comporte pas 64 caractères hexadécimaux minuscules, ou qui ne figure pas dans la liste actuelle, est refusée avec le code de sortie 1 avant la seconde étape. L’étape de liste est sans chemin et n’accepte pas --project.

physical run ne se lance pas sans opération du moteur après --:

Texte

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

Cela entraîne le code de sortie 1. Les opérations héritées acceptées sont --capabilities-json, capabilities, et execute ; toute autre valeur entraîne le code de sortie 1 avec legacy local engine operation ... is not in the public allowlist.

px

px analyze est le chemin de compatibilité portant --runner. Lorsqu’un argument positionnel est nommé <INPUTS_RELATIVE_...>, il est résolu sous le répertoire inputs/ du projet, et non par rapport à votre répertoire de travail.

Trois de ces commandes précisent leurs propres limites dans leur aide, et ces limites font partie du contrat : px static-timing exclut explicitement le signoff, px spef-summary ne confère explicitement aucune autorité d’analyse, et px fdtd2d preflight indique un obstacle à la préparation plutôt qu’un résultat. Interprétez leurs sorties en conséquence.

Comme physical run, px analyze exige une opération héritée après -- et se termine sinon avec le code 1. Sa liste autorisée est capabilities et execute.

Opérations PX sur CPU et CUDA

Ces commandes acceptent --project ; les deux premières acceptent également --timeout-ms 1..300000. L’utilisation explicite de cuda exige une exécution CUDA utilisable. auto autorise séparément le repli CPU enregistré par le moteur ; inspectez le backend indiqué. Ces opérations numériques bornées n’établissent ni un signoff physique général ni l’accélération GPU de toutes les opérations PX.

isa

Quatre des six sous-commandes lisent les sources CX exclusivement sur stdin. isa run est le chemin de compatibilité portant --runner.

--check accepte exactement elaboration, static-semantics, encoding-uniqueness, et decode-determinism. --bit-len est un entier non signé de 32 bits. --text et --bits ne doivent être ni vides ni composés uniquement d’espaces.

Contrairement à physical run et px analyze, isa run porte une opération fixe du moteur ; elle se lance donc sans arguments transmis et le moteur indique ses propres exigences :

Texte

$ 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

Opérations de l’hôte desktop. Les calculs restent dans les espaces de noms des moteurs ci-dessus.

ide open lance l’application desktop installée séparément. Les commandes natives d’espace de travail, de Cloud, de service et de création de projet ci-dessous passent par leurs propres backends explicites.

--project doit être un répertoire absolu canonique : absolu, existant, sans lien symbolique et égal à sa propre forme canonique. Un chemin résolu via un lien symbolique est refusé au lieu d’être suivi silencieusement.

ide open n’utilise pas de binaire de moteur. Elle recherche un exécutable nommé altifigence-ide à côté de alti puis dans PATH, le lance avec --project <canonical-dir>, et produit un reçu altifigence.ide-launcher-receipt.v1 :

Le code de sortie est 0 pour spawned et 1 dans les autres cas. altifigence-ide est fourni avec Digital Design Studio, et non avec l’archive du CLI ; ainsi, ide open indique unavailable dans une installation limitée au CLI.

Opérations natives de projet et d’espace de travail

ide init --parent ABSOLUTE_DIR --name NAME crée une nouvelle ossature sous un parent canonique appartenant à l’appelant. Elle n’écrase pas un projet existant. ide workspace agit sur les fichiers locaux enregistrés sans ouvrir l’interface :

Le résultat du plan natif est une entrée d’application complète et opaque. Enregistrez la sortie brute du moteur sans l’option globale --json, examinez-la, puis fournissez le même document à la commande d’application correspondante. Par exemple, avec votre projet absolu existant et votre requête de hiérarchie typée :

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"

Ne transmettez pas la sortie d’une commande échouée à une commande d’application. Choisissez un nouveau fichier de plan et vérifiez chaque code de sortie. La création de fichiers utilise des transactions durables sérialisées et les hachages actuels des sources ; elle n’offre pas une atomicité instantanée à l’échelle du système de fichiers face à des écritures sans rapport. Les conflits exigent un nouvel examen. La création de hiérarchie consiste en une sélection bornée de sources et une ossature, et ne constitue pas une refactorisation sémantique complète de SystemVerilog ni une preuve d’équivalence.

Les paramètres conservent le format DDS .alti/ide-settings.json, les clés inconnues et les valeurs littérales null. Le correctif effectue une fusion récursive, et non une suppression RFC 7396. Le budget requête/résultat est de 256 KiB et la profondeur de 8 ; l’interface native et le CLI utilisent le même .alti/.ide-settings.lock. Le CLI vise le format de projet actuel, et non un second périmètre indépendant de paramètres globaux desktop.

Les transactions natives et Git exigent le contrat Linux. La récupération actuelle lit les journaux V1 et V2. Après une création/suppression ou une application de hiérarchie interrompue, exécutez health du nouveau CLI avant d’ouvrir un ancien backend DDS limité à V1. Un ancien backend refuse un journal V2 en attente sans l’effacer. Les transactions achevées normalement effacent leur journal actif ; une mise à niveau du backend permettant une récupération transparente est recommandée, mais n’est pas un préalable à chaque modification CLI achevée.

Git

Sous ide workspace git, toutes les commandes acceptent --project ABS:

Ces opérations récupèrent et sérialisent les accès avec les transactions natives de l’espace de travail. Elles n’exposent ni arguments Git arbitraires, ni hooks, ni identifiants de push distant.

Recherche dans les sources enregistrées

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

La recherche native prend en charge --match-case, --whole-word, un --regex prudent de largeur fixe, des limites de 1 à 500 correspondances et --timeout-seconds 1..120. Elle lit le texte enregistré via la frontière native files/read, avec des budgets de 500 fichiers, 4 MiB par fichier, 16 MiB au total et 1 MiB de sortie. Vérifiez la troncature et les éléments probants du contenu. Les buffers non enregistrés de l’éditeur ne sont pas recherchés. La recherche Cloud et la recherche/remplacement HTTP héritée sont des opérations de service.

xls

Le chemin natif prend en charge des fonctions DSLX et XLS IR bornées avec des valeurs de 1 à 64 bits, le repliement des constantes/l’élimination du code mort, ainsi que le RTL combinatoire ou le RTL avec 1 à 16 étages de registres de sortie. La requête sélectionne cpu, ou explicitement cuda pour l’évaluation par lot prise en charge. Un backend CUDA indisponible entraîne une erreur, et non une exécution CPU automatique. Commencez par l’exemple CPU.

Le chemin upstream distinct installe une chaîne d’outils Linux publique Google XLS épinglée, vérifie son archive et l’inventaire des outils/de la bibliothèque standard, et conserve les fichiers de licence. Il prend en charge les imports, les paramètres, les structures, les énumérations, les types agrégés et de largeur arbitraire ainsi que les procs lorsque l’outil upstream sélectionné prend en charge l’opération demandée. Il n’utilise pas l’analyseur borné bits64 et n’accélère pas l’ensemble de la chaîne Google avec CUDA.

Les requêtes upstream sélectionnent check, eval, convert, optimize, ou codegen. L’évaluation DSLX sans vecteurs/ticks explicites exécute de vrais tests de module ; zéro test unitaire exécuté ne constitue pas une réussite. L’archive de base ne contient pas les exécutables autonomes d’évaluation IR/proc. Les vecteurs explicites ou ticks de canaux nécessitent un paquet supplémentaire d’évaluateurs vérifiés admis à l’installation avec --evaluator-bundle et --evaluator-manifest-sha256. Inspectez les capacités avant de demander ces opérations. La génération de code pipeline upstream prend en charge 1 à 64 étages ; sa planification à délai unitaire ne correspond pas à une temporisation silicium caractérisée.

compute

Les commandes de requête acceptent --project. L’entrée Simulation/Evolve est limitée à 4 MiB ; l’entrée de vérification à 16 MiB. Le moteur fourni alti-rtl-cuda est responsable de ce chemin. compute rtl-evolve accepte altifigence.rtl.evolve-request.v1, avec la requête native de génération existante imbriquée sous request ; ce n’est pas une enveloppe d’opération evolve run.

Evolve CUDA calcule des diagnostics bornés d’activité combinatoire. La génération des candidats, les contrôles de correction, la synthèse et l’évaluation des objectifs restent sur CPU. Les véritables outils Icarus iverilog et vvp doivent être disponibles via la configuration des outils de l’hôte. cpu-reference exige cuda_timeout_ms: 0 et device_memory_bytes: 0; cuda refuse une exécution indisponible au lieu de se replier. Utilisez un nouveau request.run_dir avec un parent existant.

La requête borne les générations et les enfants à 1–16, les îlots à 1–4, le total des évaluations prévues à 256 et les enfants LLM à zéro. La mémoire du périphérique est un budget borné de buffer de worker, et non une limite sur la mémoire totale du pilote. Le cancel_file local facultatif et les délais permettent une annulation coopérative ; les appels d’outils natifs conservent leurs propres limites. Un résultat CUDA réussi exige une activité réelle de candidats acceptés et une provenance matérielle enregistrée, et non la seule découverte d’un périphérique ou une sonde initiale. L’accord fonctionnel CPU/CUDA ne démontre pas un gain de vitesse.

Commandes absentes du téléchargement actuel

Les espaces de noms auparavant omis eda et reports sont désormais routés :

Il s’agit d’opérations bornées d’inspection, d’analyse ou de liaison, et non d’exécution générale d’outils EDA. ide init et les commandes natives explicites Evolve sont également disponibles. Le chemin de compatibilité non livré alti-rtl-runner décrit plus haut reste une limite distincte ; ne déduisez pas une prise en charge de la seule aide.

Préparer un workflow de moteur

1. Choisissez l’opération et lisez la réponse de capacité installée ainsi que l’aide de la commande terminale.

2. Créez une petite entrée enregistrée dans le projet sélectionné et identifiez son top/module ou son point d’entrée.

3. Fournissez les outils externes requis et utilisez un backend explicite lorsque la requête permet de choisir CPU/CUDA.

4. Exécutez une fois avec des ressources bornées et conservez les diagnostics ainsi que le résultat natif complet.

5. Inspectez le backend réel, les entrées, les artefacts de sortie et les métriques non prises en charge avant de construire un workflow plus vaste.

Utilisez Analyses DDS pour le workflow graphique et Evolve pour comparer les candidats. La prise en charge par un moteur CLI, un panneau desktop et une route Cloud sont des intégrations distinctes ; vérifiez le workflow que vous utiliserez réellement.