CLI-Engine-Befehle

Überblick

Diese Seite beschreibt Befehle für lokale Design-Engines, ihre wichtigsten Argumente und ihre Ausführungsgrenzen. Verwenden Sie die --help-Hilfe des installierten Einzelbefehls für die vollständige Liste seiner Optionen und Werteaufzählungen. Lesen Sie die im Ergebnis selbst genannten Grenzen, bevor Sie es als technischen Nachweis verwenden.

Lesen Sie zuerst die CLI-Befehlsoberfläche. Sie definiert das Routing, die Exit-Codes, die Ergebnisbelege und die Regel zur Auflösung benachbarter Programme, von denen alle nachfolgenden Befehle abhängen. Der Namensraum job, analyze run und evolve run werden unter CLI-Befehle für Jobs und Cloud beschrieben.

Konventionen in den Tabellen:

• <ANGLE> ist ein Positionsargument; [ANGLE]... ist ein wiederholbares optionales Argument.

• Optionen in der Spalte Erforderlich müssen vorhanden sein; andernfalls beendet sich der Befehl mit 2, bevor etwas gestartet wird.

• Jeder Unterbefehl akzeptiert außerdem --json und -h/--help. Diese Optionen werden nicht in jeder Zeile wiederholt.

• --project steht für --project <PROJECT>, ein optionales Arbeitsverzeichnis für relative Eingabe- und Ausgabepfade, sofern die Zeile nichts anderes angibt. Es muss sich zu einem tatsächlichen Verzeichnis auflösen lassen; andernfalls erfolgt ein Abbruch mit 2.

capabilities

alti capabilities prüft den authentifizierten Aufbau der Installation und meldet die verfügbaren Operationen. Führen Sie zuerst die Installation unter Linux durch; der eingebettete Bootstrap von 0.1.9 liefert den zuvor fehlenden Aufbau für Belege und Nutzdaten. Eine Funktionsantwort ist kein Nachweis dafür, dass ein Kernel oder Design ausgeführt wurde.

rtl

Achtundzwanzig Unterbefehle. rtl compile und rtl synthesize sind die beiden Kompatibilitätspfade mit --runner; alle anderen rtl-Unterbefehle werden lokal und ohne weitere Bedingung ausgeführt.

Anders als physical run und px analyze starten diese beiden ihre Engine auch ohne durchgereichte Argumente, da jeder eine feste Engine-Operation vorgibt. Die Engine meldet dann selbst den Fehler zu fehlenden Argumenten; ihr Exit-Status wird unverändert weitergegeben. Übergeben Sie die benötigten Argumente nach --.

--schematic wählt bei den drei rtl artifact-Unterbefehlen den festen Speicher für Schaltplanbelege anstelle des Speichers für RTL-Operationsergebnisse.

--entry-id muss bei den Unterbefehlen für festgeschriebene Identitäten aus genau 64 hexadezimalen Kleinbuchstaben bzw. Ziffern bestehen. Jeder andere Wert führt zum Abbruch mit 2 und entry id must be exactly 64 lowercase hexadecimal characters.

Grenzen von rtl schematic

rtl schematic validiert seine Pfade, bevor etwas gestartet wird. Jede Quelldatei, jedes Include-Verzeichnis und jede Definition wird bei der Zulassung abgelehnt, wenn eine dieser Regeln verletzt wird:

Pfade müssen relativ zum ausgewählten Projekt sein, dürfen nicht mit - beginnen, keine Steuerbytes enthalten und nicht .. enthalten. --top und der Name einer Definition müssen SystemVerilog-Bezeichner mit 1 bis 128 Bytes sein; eine Definition darf nach = einen Wert enthalten, bis zu einer Gesamtlänge von 4096 Bytes.

Optionen von rtl target-analysis

admit und preflight lesen kanonisches Source-Bundle-JSON von stdin und benötigen dieselben elf Optionen: --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> und --deadline-unix-ms <N>. --cell-decomposition ist ein optionales boolesches Flag.

--cpu-slots ist eine vorzeichenlose 32-Bit-Ganzzahl; --memory-bytes, --max-wall-time-ms und --deadline-unix-ms sind vorzeichenlose 64-Bit-Ganzzahlen.

Ein doppelter oder nicht aufgeführter Wert in einer der beiden CSV-Listen wird bereits beim Parsen abgelehnt, zum Beispiel targets must be a comma-separated subset of: generic-asic, sky130-asic, xc7-fpga.

Die Hülle der Simulationsanfrage

<REQUEST_JSON> ist ein projektrelativer Pfad zu einer Datei, die die CLI liest und prüft, bevor sie etwas startet. Der Pfad muss normalisiert und relativ sein, darf in keiner Komponente einen symbolischen Link durchlaufen und muss innerhalb des Projektstammverzeichnisses liegen. Die Datei muss eine reguläre Datei mit höchstens 260 MiB sein.

Ihr JSON muss ein Objekt mit genau vier Schlüsseln sein:

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

operationId muss altifigence.rtl.simulate.v1 für rtl simulate oder entsprechend altifigence.rtl.simulate.v2 für rtl simulate-v2 sein. Eine Abweichung wird vor dem Start mit RTL simulation request must be the exact <id> envelope abgelehnt.

Die Unterbefehle für festgeschriebene Identitäten können nicht ausgeführt werden

Die acht Unterbefehle rtl *-committed-identities list und read leiten an eine Engine namens alti-rtl-runner weiter. Dieses Programm gehört nicht zu den 24 Engine-Programmen, die das Release baut und ausliefert, sodass es sich bei einer korrekten Installation weder als Nachbar von alti noch über PATH auflösen. Ein Aufruf erzeugt einen Beleg der lokalen Engine mit status: "unavailable" und exitCode: 127:

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

Bauen Sie keine Automatisierung auf diesen acht Befehlen auf.

sv

Dreiundzwanzig Unterbefehle, alle lokal und ohne weitere Bedingung. Keiner akzeptiert --runner.

Regeln für Positionswerte:

• <LINE> und <COLUMN> sind von 1 an gezählte Ganzzahlen ungleich null. 0 führt zum Abbruch mit 2.

• <REPLACEMENT> muss ein SystemVerilog-Bezeichner sein: Das erste Zeichen ist ein Buchstabe, _ oder $; die übrigen Zeichen sind alphanumerisch, _ oder $.

• <REVIEWED_PLAN_SHA256> muss aus 64 hexadezimalen Kleinbuchstaben bzw. Ziffern bestehen.

• <STABLE_ID> muss 1 bis 128 Zeichen aus Kleinbuchstaben, Ziffern und Bindestrichen umfassen.

• --filter muss 1 bis 128 Bytes ohne Steuerbytes umfassen; --limit muss eine Ganzzahl von 1 bis 64 sein, und --limit 65 führt zum Abbruch mit 2.

sv frontend rename-apply ist der einzige sv-Unterbefehl, der --project benötigt. Der Wert muss ein absoluter Pfad zu einem tatsächlichen Verzeichnis sein, das kein symbolischer Link ist. Ohne diese Option beendet sich der Befehl mit 1 und SV rename apply requires --project <absolute-workspace>.

sv review immediate und sv review interprocess lesen SystemVerilog-Quelltext von stdin. Sie sind die einzigen sv-Unterbefehle mit eigenen Engines, alti-sv-immediate-review und alti-sv-interprocess-review; alle anderen Befehle im Namensraum verwenden alti-sv-frontend.

sv uvm simulation admit benötigt dreizehn Optionen: --bundle-id, --bundle-sha256, --source-count, --source-bytes, --test, --top, --clock, --period-ps, --cycles, --max-wall-time-ms, --max-cpu-cores, --max-memory-bytes und --max-artifact-bytes. sv uvm simulation preflight benötigt diese dreizehn sowie --attempt-id, --observed-at-unix-ms und --deadline-unix-ms und akzeptiert zusätzlich das boolesche --cancellation-requested (Standardwert false). --source-count ist eine vorzeichenlose 32-Bit-Ganzzahl, --max-cpu-cores eine vorzeichenlose 16-Bit-Ganzzahl; die übrigen numerischen Optionen sind vorzeichenlose 64-Bit-Ganzzahlen.

verification

--tolerance-pct muss eine endliche, nicht negative Zahl sein; ein negativer oder nicht numerischer Wert führt zum Abbruch mit 2 und tolerance-pct must be a finite non-negative number.

--format wählt hier das eigene Ausgabeformat der Engine und ist unabhängig vom CLI-weiten Hüllen-Flag --json. Beide können zusammen verwendet werden.

trace

<FORMAT> ist bei trace export eine positionale Werteaufzählung, kein Flag, und steht vor dem Eingabepfad. Ihre Werte sind vcd und chrome.

--reference kann wiederholt werden, um zusätzliche Referenzartefakte anzugeben. <TRACE_ARTIFACT_ID>, die Referenz-IDs und <PACKAGE_ID> dürfen mit einem Bindestrich beginnen, ohne dass ein Trenner wie -- benötigt wird.

Beachten Sie: alti trace ohne Unterbefehl gelangt zum lokalen Parser und beendet sich mit 2 mit der Aufforderung, einen Unterbefehl anzugeben. Die einwortige trace-Aktion im eingebetteten Aktionsmanifest ist daher in diesem Release über die Befehlszeile nicht erreichbar; siehe CLI-Befehle für Jobs und Cloud.

labs

Schreibgeschützte Deskriptoren und Validierung. Workflow-Ausführung wird von der CLI nicht bereitgestellt.

labs validate prüft seine beiden Eingaben strikt. Jede folgende Regel wird geprüft, bevor die Engine startet:

• --project muss ein absoluter Pfad zu einem tatsächlichen Verzeichnis sein, nicht zu einem symbolischen Link.

• <DESCRIPTOR> muss relativ zum Workspace sein, darf weder .. noch eine Stammkomponente enthalten und höchstens 4096 Bytes umfassen.

• Er muss die Erweiterung .json verwenden.

• Er muss sich zu einer tatsächlichen regulären Datei mit höchstens 1048576 Bytes auflösen; der aufgelöste Pfad muss weiterhin innerhalb des Projekts liegen.

tcl

Die ersten vier antworten anhand von Deskriptoren über die mitgelieferte alti-tcl-Engine und geben die Standardhülle für lokale Engines aus.

tcl evaluate unterscheidet sich in drei Punkten. Es liest das Skript von stdin mit einer Grenze von 4194304 Bytes; leere Eingaben werden abgelehnt. Es benötigt alti-tcl-local-runner strikt als Nachbar von alti ohne Ausweichlösung über PATH und prüft es gegen die installierte Vertrauenskette. Der Bootstrap von 0.1.9 installiert die feste signierte Tcl-Komponente, die dieser Pfad benötigt; verwenden Sie das installierte Programm. Außerdem gibt es sein eigenes Belegschema altifigence.cli.tcl-evaluation.v1 mit eigenen Exit-Codes aus; beides finden Sie unter CLI-Befehlsoberfläche.

eidb

eidb capabilities, eidb readback und eidb semantic-readback akzeptieren kein --project; aus Sicht der CLI benötigen sie keine Pfadangaben.

physical

Zweiundvierzig Unterbefehle. physical run ist der Kompatibilitätspfad mit --runner; die übrigen werden lokal und ohne weitere Bedingung ausgeführt. Jeder reicht seinen eigenen Unterbefehlsnamen direkt als Engine-Operation an alti-physical-runner weiter. Die CLI übernimmt in diesem Namensraum die Argumentzulassung und die Belegformatierung; die Oberfläche ist daher regelmäßig genug, um sie in zwei Gruppen darzustellen.

Jede Folgeoperation mit Eintragsbezug liest einen dauerhaft gespeicherten Eintrag, den eine frühere Operation mit Projektbezug erzeugt hat. Wird --entry-id weggelassen, erfolgt ein Abbruch mit 2, bevor etwas gestartet wird. Das sind sechsunddreißig der zweiundvierzig Befehle. Die übrigen sechs sind:

physical route-evidence-closure read ist ein zweistufiger Befehl: Die CLI listet zuerst die festgeschriebenen Identitäten auf, verlangt, dass Ihr --identity-key-sha256 in dieser Liste enthalten ist, und liest anschließend genau diese Identität erneut. Ein Schlüssel, der nicht aus 64 hexadezimalen Kleinbuchstaben bzw. Ziffern besteht oder nicht in der aktuellen Liste vorkommt, wird vor dem zweiten Schritt mit Exit-Code 1 abgelehnt. Der Listenschritt benötigt keine Pfadangaben und akzeptiert kein --project.

physical run startet nicht ohne Engine-Operation nach --:

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

Dies führt zum Abbruch mit 1. Die akzeptierten Legacy-Operationen sind --capabilities-json, capabilities und execute; alles andere führt zum Abbruch mit 1 und legacy local engine operation ... is not in the public allowlist.

px

px analyze ist der Kompatibilitätspfad mit --runner. Wenn ein Positionsargument <INPUTS_RELATIVE_...> heißt, wird es unterhalb des Projektverzeichnisses inputs/ aufgelöst, nicht relativ zu Ihrem Arbeitsverzeichnis.

Drei dieser Befehle nennen ihre Grenzen in der eigenen Hilfe; diese Grenzen gehören zum Vertrag: px static-timing besitzt ausdrücklich keine Signoff-Gültigkeit, px spef-summary verleiht ausdrücklich keine Analyseberechtigung, und px fdtd2d preflight meldet ein Bereitschaftshindernis anstelle eines Ergebnisses. Behandeln Sie ihre Ausgaben entsprechend.

Wie physical run benötigt auch px analyze eine Legacy-Operation nach -- und beendet sich andernfalls mit 1. Seine Freigabeliste lautet capabilities und execute.

PX-Operationen für CPU und CUDA

Diese Befehle akzeptieren --project; die ersten beiden akzeptieren außerdem --timeout-ms 1..300000. Explizites cuda erfordert nutzbare CUDA-Ausführung. auto erlaubt separat den im Engine-Ergebnis dokumentierten CPU-Fallback; prüfen Sie das gemeldete Backend. Diese begrenzten numerischen Operationen belegen weder allgemeine physische Signoff-Gültigkeit noch GPU-Beschleunigung für jede PX-Operation.

isa

Vier der sechs Unterbefehle lesen CX-Quelltext ausschließlich von stdin. isa run ist der Kompatibilitätspfad mit --runner.

--check akzeptiert genau elaboration, static-semantics, encoding-uniqueness und decode-determinism. --bit-len ist eine vorzeichenlose 32-Bit-Ganzzahl. --text und --bits dürfen weder leer sein noch ausschließlich aus Leerzeichen bestehen.

Im Unterschied zu physical run und px analyze enthält isa run eine feste Engine-Operation, startet daher ohne durchgereichte Argumente und lässt die Engine ihre Anforderungen selbst melden:

$ 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

Operationen des Desktop-Hosts. Berechnungen verbleiben in den oben beschriebenen Engine-Namensräumen.

ide open startet die separat installierte Desktop-Anwendung. Die nachfolgenden nativen Workspace-, Cloud-, Dienst- und Projekterstellungsbefehle verwenden jeweils ihre eigenen expliziten Backends.

--project muss ein kanonisches absolutes Verzeichnis sein: absolut, vorhanden, kein symbolischer Link und identisch mit seiner eigenen kanonischen Form. Ein Pfad, der über einen Symlink aufgelöst wird, wird abgelehnt und nicht stillschweigend verfolgt.

ide open verwendet kein Engine-Programm. Es löst ein ausführbares Programm namens altifigence-ide zunächst als Nachbar von alti und dann über PATH auf, startet es mit --project <canonical-dir> und gibt einen altifigence.ide-launcher-receipt.v1-Beleg aus:

Der Exit-Status ist 0 für spawned und 1 andernfalls. altifigence-ide wird mit Digital Design Studio ausgeliefert, nicht im CLI-Archiv; daher meldet ide open bei einer reinen CLI-Installation unavailable.

Native Projekt- und Workspace-Operationen

ide init --parent ABSOLUTE_DIR --name NAME erstellt ein neues Grundgerüst unterhalb eines kanonischen übergeordneten Verzeichnisses, das dem Aufrufer gehört. Es überschreibt kein bestehendes Projekt. ide workspace arbeitet mit gespeicherten lokalen Dateien, ohne die Oberfläche zu öffnen:

Das Ergebnis eines nativen Plans ist eine opake, vollständige Eingabe für apply. Speichern Sie die rohe Engine-Ausgabe ohne globales --json, prüfen Sie sie und übergeben Sie dasselbe Dokument dann dem zugehörigen apply-Befehl. Beispiel mit Ihrem bestehenden absoluten Projekt und einer typisierten Hierarchieanfrage:

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"

Leiten Sie die Ausgabe eines fehlgeschlagenen Befehls nicht an apply weiter. Wählen Sie eine neue Plandatei und prüfen Sie jeden Exit-Status. Dateierstellung verwendet dauerhafte, serialisierte Transaktionen und aktuelle Quell-Hashes; sie bietet keine dateisystemweite sofortige Atomarität gegenüber anderen Schreibern. Konflikte erfordern eine neue Prüfung. Hierarchieerstellung umfasst begrenzte Quellauswahl und Grundgerüste, keine vollständige semantische SystemVerilog-Refaktorierung oder einen Äquivalenznachweis.

Einstellungen behalten das DDS-Format .alti/ide-settings.json, unbekannte Schlüssel und wörtliche null-Werte bei. Der Patch führt rekursiv zusammen und verwendet keine Löschsemantik nach RFC 7396. Die Grenze für Anfrage und Ergebnis beträgt 256 KiB bei Tiefe 8; native Oberfläche und CLI verwenden denselben .alti/.ide-settings.lock. Die CLI spricht das aktuelle Projektformat an, keinen zweiten unabhängigen Bereich für globale Desktop-Einstellungen.

Native Transaktionen und Git benötigen den Linux-Vertrag. Die aktuelle Wiederherstellung liest sowohl V1- als auch V2-Journale. Führen Sie nach einer unterbrochenen Erstellungs-, Lösch- oder Hierarchieanwendung den Befehl health der neuen CLI aus, bevor Sie ein älteres DDS-Backend öffnen, das nur V1 unterstützt. Ein älteres Backend lehnt ein ausstehendes V2-Journal ab, ohne es zu löschen. Regulär abgeschlossene Transaktionen entfernen ihr aktives Journal; ein Backend-Upgrade mit transparenter Wiederherstellung wird empfohlen, ist aber keine Voraussetzung für jede abgeschlossene CLI-Bearbeitung.

Git

Unter ide workspace git akzeptieren alle Befehle --project ABS:

Diese Operationen stellen native Workspace-Transaktionen wieder her und werden mit ihnen serialisiert. Sie stellen keine beliebigen Git-Argumente, Hooks oder Zugangsdaten für Remote-Push bereit.

Suche in gespeicherten Quellen

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

Die native Suche unterstützt --match-case, --whole-word, einen konservativen Regex mit fester Breite --regex, Grenzen von 1–500 Treffern und --timeout-seconds 1..120. Sie liest gespeicherten Text über die native files/read-Grenze mit Budgets von 500 Dateien, 4 MiB pro Datei, insgesamt 16 MiB und 1 MiB Ausgabe. Prüfen Sie Kürzungen und Inhaltsnachweise. Nicht gespeicherte Editorpuffer werden nicht durchsucht. Cloud-Suche und Legacy-HTTP-Suchen/Ersetzen sind separate Dienstoperationen.

xls

Der native Pfad unterstützt begrenzte DSLX- und XLS-IR-Funktionen mit 1–64-Bit-Werten, Konstantenfaltung/Entfernung toten Codes sowie kombinatorische RTL oder RTL mit 1–16 Ausgangsregisterstufen. Die Anfrage wählt cpu oder explizites cuda für unterstützte Stapelauswertung. Ein nicht verfügbares CUDA-Backend ist ein Fehler und löst keinen automatischen CPU-Lauf aus. Beginnen Sie mit dem CPU-Beispiel.

Der separate Upstream-Pfad installiert eine festgelegte öffentliche Google-XLS-Linux-Toolchain, verifiziert ihr Archiv und das Werkzeug-/Standardbibliotheksinventar und bewahrt Lizenzdateien. Er unterstützt Imports, Parametrik, Structs, Enums, zusammengesetzte Typen und Typen beliebiger Bitbreite sowie Procs, sofern das gewählte Upstream-Werkzeug die angeforderte Operation unterstützt. Er verwendet weder den begrenzten bits64-Parser noch beschleunigt er die gesamte Google-Toolchain mit CUDA.

Upstream-Anfragen wählen check, eval, convert, optimize oder codegen. DSLX eval ohne explizite Vektoren/Ticks führt tatsächliche Modultests aus; null ausgeführte Unit-Tests sind kein Erfolg. Das Basisarchiv enthält keine eigenständigen ausführbaren IR-/Proc-Evaluatorprogramme. Explizite Vektoren oder Kanal-Ticks benötigen ein zusätzliches verifiziertes Evaluator-Bundle, das während der Installation mit --evaluator-bundle und --evaluator-manifest-sha256 zugelassen wird. Prüfen Sie die Funktionen, bevor Sie diese Operationen anfordern. Upstream-Pipeline-Codegen unterstützt 1–64 Stufen; sein Plan mit Einheitsverzögerungen ist kein charakterisiertes Silizium-Timing.

compute

Die Anfragebefehle akzeptieren --project. Simulation-/Evolve-Eingaben sind auf 4 MiB begrenzt, verify-Eingaben auf 16 MiB. Die mitgelieferte alti-rtl-cuda-Engine ist für diesen Pfad zuständig. compute rtl-evolve akzeptiert altifigence.rtl.evolve-request.v1, wobei die vorhandene native Generierungsanfrage unter request eingebettet ist; es ist keine evolve run-Operationshülle.

Evolve CUDA berechnet begrenzte kombinatorische Aktivitätsdiagnosen. Kandidatenerzeugung, Korrektheitsprüfungen, Synthese und Zielfunktionsauswertung bleiben auf der CPU. Tatsächliche Icarus-Programme iverilog und vvp müssen über die Host-Werkzeugkonfiguration verfügbar sein. cpu-reference benötigt cuda_timeout_ms: 0 und device_memory_bytes: 0; cuda lehnt nicht verfügbare Ausführung ab, statt auszuweichen. Verwenden Sie ein neues request.run_dir mit vorhandenem übergeordnetem Verzeichnis.

Die Anfrage begrenzt Generationen und Nachkommen auf 1–16, Inseln auf 1–4, insgesamt geplante Auswertungen auf 256 und LLM-Nachkommen auf null. Gerätespeicher bezeichnet ein begrenztes Worker-Pufferbudget, keine Grenze des gesamten Treiberspeichers. Das optionale lokale cancel_file und Fristen unterstützen kooperativen Abbruch; native Werkzeugaufrufe behalten ihre eigenen Grenzen. Ein erfolgreiches CUDA-Ergebnis benötigt tatsächliche akzeptierte Kandidatenaktivität und gespeicherte Hardwareherkunft, nicht nur Geräteerkennung oder eine erste Probe. Funktionale CPU-/CUDA-Übereinstimmung ist keine Aussage über Beschleunigung.

Im aktuellen Download fehlende Befehle

Die zuvor ausgelassenen Namensräume eda und reports werden nun geroutet:

Dies sind begrenzte Prüf-, Parse- oder Bindungsoperationen, keine allgemeine EDA-Werkzeugausführung. ide init und die expliziten nativen Evolve-Befehle sind ebenfalls verfügbar. Der oben beschriebene nicht ausgelieferte alti-rtl-runner-Kompatibilitätspfad bleibt eine separate Einschränkung; leiten Sie Unterstützung nicht allein aus der Hilfe ab.

Einen Engine-Workflow vorbereiten

1. Wählen Sie die Operation und lesen Sie die Funktionsantwort der installierten Version sowie die Hilfe des Einzelbefehls.

2. Erstellen Sie eine kleine gespeicherte Eingabe innerhalb des ausgewählten Projekts und bestimmen Sie ihr Top/Modul oder ihren Einstiegspunkt.

3. Stellen Sie erforderliche externe Werkzeuge bereit und verwenden Sie ein explizites Backend, wenn die Anfrage CPU-/CUDA-Auswahl unterstützt.

4. Führen Sie einen Lauf mit begrenzten Ressourcen aus und bewahren Sie Diagnosen sowie das vollständige native Ergebnis auf.

5. Prüfen Sie tatsächliches Backend, Eingaben, Ausgabeartefakte und nicht unterstützte Metriken, bevor Sie einen größeren Workflow aufbauen.

Verwenden Sie DDS-Analyse für den grafischen Workflow und Evolve für Kandidatenvergleiche. CLI-Engine-Unterstützung, ein Desktop-Panel und eine Cloud-Route sind separate Integrationen; prüfen Sie den Workflow, den Sie tatsächlich verwenden werden.