Comandi dei motori CLI

Panoramica

Questa pagina descrive i comandi dei motori di progettazione locali, i loro argomenti principali e i limiti di esecuzione. Usare l'opzione --help del sottocomando installato per l'elenco completo di opzioni e valori enumerati. Leggere i limiti dichiarati dal risultato prima di usarlo come prova ingegneristica.

Leggere Interfaccia dei comandi CLI per prima cosa. Definisce l'instradamento, i codici di uscita, gli involucri delle ricevute e la regola di risoluzione nella stessa directory da cui dipendono tutti i comandi seguenti. Il namespace job e il comando analyze run e il comando evolve run sono descritti in Comandi CLI per job e Cloud.

Convenzioni usate nelle tabelle:

• <ANGLE> è un argomento posizionale; [ANGLE]... è un argomento facoltativo ripetibile.

• Le opzioni nella colonna Obbligatorio devono essere presenti, altrimenti il comando termina con 2 prima di avviare qualsiasi operazione.

• Ogni sottocomando accetta anche --json e -h/--help. Non vengono ripetute in ogni riga.

• --project è --project <PROJECT>, una directory di lavoro facoltativa per i percorsi relativi di input e output, salvo diversa indicazione nella riga. Deve risolversi in una directory reale; un valore non risolvibile termina con 2.

capabilities

alti capabilities esamina la struttura installata autenticata e ne descrive le operazioni disponibili. Completare prima Installazione su Linux; il bootstrap incorporato della versione 0.1.9 fornisce la ricevuta e la struttura del payload precedentemente mancanti. Una risposta sulle capacità non dimostra l'esecuzione di un kernel o di un progetto.

rtl

Ventotto sottocomandi. rtl compile e rtl synthesize sono i due percorsi di compatibilità che accettano --runner; ogni altro sottocomando rtl viene eseguito localmente e senza condizioni.

A differenza di physical run e px analyze, questi due avviano il proprio motore anche senza argomenti inoltrati, poiché ciascuno fornisce un'operazione fissa del motore. Il motore segnala quindi il proprio errore di argomenti mancanti e il suo stato di uscita viene trasmesso senza modifiche. Specificare gli argomenti necessari dopo --.

--schematic sui tre sottocomandi rtl artifact seleziona l'archivio fisso delle ricevute degli schemi invece dell'archivio dei risultati delle operazioni RTL.

--entry-id nei sottocomandi finali delle identità confermate deve contenere esattamente 64 caratteri esadecimali minuscoli. Qualsiasi altro valore termina con 2 con entry id must be exactly 64 lowercase hexadecimal characters.

Limiti di rtl schematic

rtl schematic valida i percorsi prima di avviare qualsiasi operazione. Ogni file sorgente, directory di inclusione e definizione viene rifiutato all'ammissione se viola uno di questi limiti:

I percorsi devono essere relativi al progetto selezionato, non devono iniziare con -, non devono contenere byte di controllo e non devono contenere ... --top e il nome di una definizione devono essere identificatori SystemVerilog da 1 a 128 byte; una definizione può contenere un valore dopo = per un totale massimo di 4096 byte.

Opzioni di rtl target-analysis

admit e preflight leggono il JSON canonico del bundle sorgente da stdin ed entrambi richiedono le stesse undici opzioni: --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> e --deadline-unix-ms <N>. --cell-decomposition è un flag booleano facoltativo.

--cpu-slots è un intero senza segno a 32 bit; --memory-bytes, --max-wall-time-ms e --deadline-unix-ms sono interi senza segno a 64 bit.

Un valore duplicato o non elencato in uno dei due CSV viene rifiutato durante il parsing, per esempio targets must be a comma-separated subset of: generic-asic, sky130-asic, xc7-fpga.

L'involucro della richiesta di simulazione

<REQUEST_JSON> è un percorso relativo al progetto verso un file che la CLI legge e controlla prima di avviare qualsiasi operazione. Il percorso deve essere normalizzato e relativo, non deve attraversare collegamenti simbolici in alcun componente e deve risolversi all'interno della radice del progetto. Il file deve essere un file regolare di dimensioni non superiori a 260 MiB.

Il suo JSON deve essere un oggetto con esattamente quattro chiavi:

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

operationId deve essere altifigence.rtl.simulate.v1 per rtl simulate e altifigence.rtl.simulate.v2 per rtl simulate-v2. Una mancata corrispondenza viene rifiutata prima dell'avvio con RTL simulation request must be the exact <id> envelope.

I sottocomandi delle identità confermate non possono essere eseguiti

Gli otto sottocomandi rtl *-committed-identities list e read inoltrano l'operazione a un motore chiamato alti-rtl-runner. Questo binario non è uno dei 24 binari dei motori compilati e distribuiti dalla release, quindi non può essere risolto né nella stessa directory di alti né tramite PATH in un'installazione corretta. Invocarne uno produce una ricevuta del motore locale con status: "unavailable" e exitCode: 127:

Testo

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

Non basare l'automazione su questi otto comandi.

sv

Ventitré sottocomandi, tutti locali e senza condizioni. Nessuno accetta --runner.

Regole per i valori posizionali:

• <LINE> e <COLUMN> sono interi non nulli con base 1. 0 termina con 2.

• <REPLACEMENT> deve essere un identificatore SystemVerilog: il primo carattere è una lettera, _ oppure $, e i successivi sono alfanumerici, _ oppure $.

• <REVIEWED_PLAN_SHA256> deve contenere 64 caratteri esadecimali minuscoli.

• <STABLE_ID> deve contenere da 1 a 128 caratteri tra lettere minuscole, cifre e trattini.

• --filter deve contenere da 1 a 128 byte non di controllo; --limit deve essere un intero da 1 a 64 e --limit 65 termina con 2.

sv frontend rename-apply è l'unico sottocomando sv che richiede --project, il cui valore deve essere un percorso assoluto verso una directory reale che non sia un collegamento simbolico. Senza di esso il comando termina con 1 con SV rename apply requires --project <absolute-workspace>.

sv review immediate e sv review interprocess leggono il sorgente SystemVerilog da stdin. Sono gli unici sottocomandi sv supportati da motori propri, alti-sv-immediate-review e alti-sv-interprocess-review; tutti gli altri nel namespace usano alti-sv-frontend.

sv uvm simulation admit richiede tredici opzioni: --bundle-id, --bundle-sha256, --source-count, --source-bytes, --test, --top, --clock, --period-ps, --cycles, --max-wall-time-ms, --max-cpu-cores, --max-memory-bytes e --max-artifact-bytes. sv uvm simulation preflight richiede queste tredici più --attempt-id, --observed-at-unix-ms e --deadline-unix-ms, e accetta inoltre il booleano --cancellation-requested (predefinito: false). --source-count è un intero senza segno a 32 bit, --max-cpu-cores è un intero senza segno a 16 bit e le restanti opzioni numeriche sono interi senza segno a 64 bit.

verification

--tolerance-pct deve essere un numero finito non negativo; un valore negativo o non numerico termina con 2 con tolerance-pct must be a finite non-negative number.

--format qui seleziona il formato di output del motore ed è indipendente dal flag --json dell'involucro a livello CLI. Entrambi possono essere usati insieme.

trace

<FORMAT> su trace export è un valore enumerato posizionale, non un flag, e precede il percorso di input. I suoi valori sono vcd e chrome.

--reference può essere ripetuto per indicare ulteriori artefatti di riferimento. <TRACE_ARTIFACT_ID>, gli ID di riferimento e <PACKAGE_ID> possono iniziare con un trattino senza richiedere --.

Si osservi che alti trace senza sottocomandi raggiunge il parser locale e termina con 2 richiedendo un sottocomando. L'azione di una sola parola trace nel manifesto incorporato delle azioni non è quindi raggiungibile dalla riga di comando in questa release; vedere Comandi CLI per job e Cloud.

labs

Descrittori e validazione in sola lettura. La CLI non espone l'esecuzione dei flussi di lavoro.

labs validate impone requisiti rigorosi ai due input e ogni regola seguente viene controllata prima dell'avvio del motore:

• --project deve essere un percorso assoluto verso una directory reale, non un collegamento simbolico.

• <DESCRIPTOR> deve essere relativo all'area di lavoro, non deve contenere .. né componenti di radice e deve avere una lunghezza massima di 4096 byte.

• Deve usare l'estensione .json.

• Deve risolversi in un file regolare reale di al massimo 1048576 byte e il percorso risolto deve rimanere all'interno del progetto.

tcl

I primi quattro rispondono tramite descrittori usando il motore incluso alti-tcl e generano l'involucro standard del motore locale.

tcl evaluate differisce per tre aspetti. Legge lo script da stdin con un limite di 4194304 byte; l'input vuoto viene rifiutato. Richiede alti-tcl-local-runner rigorosamente nella stessa directory di alti senza ripiego su PATH e lo verifica rispetto alla catena di fiducia installata. Il bootstrap 0.1.9 installa il componente Tcl fisso e firmato necessario per questo percorso; usare il binario installato. Genera inoltre il proprio schema di ricevuta, altifigence.cli.tcl-evaluation.v1, con i propri codici di uscita: entrambi sono descritti in Interfaccia dei comandi CLI.

eidb

eidb capabilities, eidb readback e eidb semantic-readback non accettano --project; per la CLI non usano percorsi.

physical

Quarantadue sottocomandi. physical run è il percorso di compatibilità che accetta --runner; gli altri vengono eseguiti localmente e senza condizioni e ciascuno inoltra direttamente il nome del proprio sottocomando a alti-physical-runner come operazione del motore. In questo namespace il ruolo della CLI è l'ammissione degli argomenti e la costruzione delle ricevute, quindi l'interfaccia è abbastanza regolare da essere presentata in due gruppi.

Ogni operazione successiva nell'ambito di una voce legge una voce persistente prodotta da una precedente operazione nell'ambito del progetto. Omettere --entry-id termina con 2 prima di avviare qualsiasi operazione. Si tratta di trentasei dei quarantadue sottocomandi. I sei rimanenti sono:

physical route-evidence-closure read è un comando in due passaggi: la CLI elenca prima le identità confermate, richiede che --identity-key-sha256 compaia nell'elenco e rilegge poi esattamente quella voce. Una chiave che non contiene 64 caratteri esadecimali minuscoli o che non è nell'elenco corrente viene rifiutata con uscita 1 prima del secondo passaggio. Il passaggio di elenco non usa percorsi e non accetta --project.

physical run non si avvia senza un'operazione del motore dopo --:

Testo

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

Il comando termina con 1. Le operazioni legacy accettate sono --capabilities-json, capabilities e execute; qualsiasi altra termina con 1 con legacy local engine operation ... is not in the public allowlist.

px

px analyze è il percorso di compatibilità che accetta --runner. Quando un argomento posizionale si chiama <INPUTS_RELATIVE_...>, viene risolto nella directory inputs/ del progetto, non rispetto alla directory di lavoro.

Tre di questi dichiarano i propri limiti nel testo della propria guida e quei limiti fanno parte del contratto: px static-timing esclude esplicitamente il signoff, px spef-summary esclude esplicitamente qualsiasi autorità di analisi e px fdtd2d preflight segnala un impedimento alla disponibilità anziché un risultato. Interpretare l'output di conseguenza.

Come physical run, px analyze richiede un'operazione legacy dopo -- e altrimenti termina con 1. Il suo elenco consentito è capabilities e execute.

Operazioni PX su CPU e CUDA

Questi comandi accettano --project; i primi due accettano anche --timeout-ms 1..300000. Il valore esplicito cuda richiede un'esecuzione CUDA utilizzabile. auto consente separatamente il ripiego sulla CPU registrato dal motore; controllare il backend riportato. Queste operazioni numeriche limitate non dimostrano un signoff fisico generale né l'accelerazione GPU di ogni operazione PX.

isa

Quattro dei sei sottocomandi leggono il sorgente CX esclusivamente da stdin. isa run è il percorso di compatibilità che accetta --runner.

--check accetta esattamente elaboration, static-semantics, encoding-uniqueness e decode-determinism. --bit-len è un intero senza segno a 32 bit. --text e --bits non devono essere vuoti né contenere soltanto spazi.

A differenza di physical run e px analyze, isa run fornisce un'operazione fissa del motore, quindi si avvia senza argomenti inoltrati e il motore segnala i propri requisiti:

Testo

$ 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

Operazioni dell'host desktop. Il calcolo rimane nei namespace dei motori descritti sopra.

ide open avvia l'applicazione desktop installata separatamente. I comandi nativi per area di lavoro, Cloud, servizio e creazione di progetti riportati sotto usano ciascuno un backend esplicito.

--project deve essere una directory assoluta e canonica: assoluta, esistente, priva di collegamenti simbolici e uguale alla propria forma canonica. Un percorso che si risolve attraverso un collegamento simbolico viene rifiutato anziché seguito implicitamente.

ide open non usa un binario di motore. Risolve un eseguibile chiamato altifigence-ide nella stessa directory di alti e poi tramite PATH, lo avvia con --project <canonical-dir>, e genera una ricevuta altifigence.ide-launcher-receipt.v1:

Lo stato di uscita è 0 per spawned e 1 negli altri casi. altifigence-ide è distribuito con Digital Design Studio, non con l'archivio della CLI, quindi ide open segnala unavailable in un'installazione della sola CLI.

Operazioni native su progetti e aree di lavoro

ide init --parent ABSOLUTE_DIR --name NAME crea una nuova struttura iniziale in una directory padre canonica di proprietà del chiamante. Non sovrascrive un progetto esistente. ide workspace opera sui file locali salvati senza aprire l'interfaccia:

Il risultato del piano nativo è un input completo e opaco per l'applicazione. Salvare l'output grezzo del motore senza l'opzione globale --json, esaminarlo e passare poi lo stesso documento al comando di applicazione corrispondente. Per esempio, usando il progetto assoluto esistente e la richiesta gerarchica tipizzata:

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"

Non inoltrare l'output di un comando fallito a un comando di applicazione. Scegliere un nuovo file di piano e controllare ogni stato di uscita. La creazione dei file usa transazioni durevoli e serializzate e gli hash correnti dei sorgenti; non fornisce atomicità istantanea sull'intero filesystem rispetto a scritture estranee. I conflitti richiedono una nuova revisione. La creazione gerarchica comprende selezione limitata dei sorgenti e strutture iniziali, non un refactoring semantico completo di SystemVerilog né una prova di equivalenza.

Le impostazioni mantengono il formato DDS .alti/ide-settings.json, le chiavi sconosciute e i valori letterali null. La patch esegue una fusione ricorsiva, non la cancellazione di RFC 7396. Il budget di richiesta/risultato è 256 KiB con profondità 8; l'interfaccia nativa e la CLI usano lo stesso .alti/.ide-settings.lock. La CLI gestisce il formato del progetto corrente, non un secondo ambito indipendente di impostazioni globali desktop.

Le transazioni native e Git richiedono il contratto Linux. Il recupero corrente legge i journal V1 e V2. Dopo una creazione/eliminazione o un'applicazione gerarchica interrotta, eseguire il comando health della nuova CLI prima di aprire un backend DDS precedente che supporta solo V1. Un backend precedente rifiuta un journal V2 in sospeso senza cancellarlo. Le transazioni normalmente completate cancellano il journal attivo; è consigliato un aggiornamento del backend con recupero trasparente, ma non è un requisito per ogni modifica CLI già completata.

Git

Nel namespace ide workspace git, tutti i comandi accettano --project ABS:

Queste operazioni recuperano le transazioni native dell'area di lavoro e si serializzano rispetto a esse. Non espongono argomenti Git arbitrari, hook o credenziali di push remoto.

Ricerca nei sorgenti salvati

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

La ricerca nativa supporta --match-case, --whole-word, un'espressione conservativa a larghezza fissa --regex, limiti da 1 a 500 corrispondenze e --timeout-seconds 1..120. Legge il testo salvato tramite l'interfaccia nativa files/read, con budget di 500 file, 4 MiB per file, 16 MiB totali e 1 MiB di output. Controllare il troncamento e le prove sul contenuto. I buffer non salvati dell'editor non vengono cercati. La ricerca Cloud e la ricerca/sostituzione HTTP legacy sono operazioni di servizio separate.

xls

Il percorso nativo supporta funzioni DSLX e XLS IR limitate con valori da 1 a 64 bit, valutazione delle costanti/rimozione del codice morto e RTL combinatorio oppure RTL con da 1 a 16 stadi di registri di uscita. La richiesta seleziona cpu, oppure esplicitamente cuda per la valutazione in batch supportata. Un backend CUDA non disponibile è un errore, non un'esecuzione automatica sulla CPU. Iniziare con l'esempio CPU.

Il percorso upstream separato installa una toolchain Linux pubblica di Google XLS fissata a una versione, verifica l'archivio e l'inventario degli strumenti/stdlib e conserva i file di licenza. Supporta importazioni, parametri, strutture, enum, tipi aggregati e a larghezza arbitraria e procs quando lo strumento upstream selezionato supporta l'operazione richiesta. Non usa il parser bits64 limitato e non accelera l'intera toolchain Google con CUDA.

Le richieste upstream selezionano check, eval, convert, optimize, oppure codegen. La valutazione DSLX senza vettori/tick espliciti esegue i test reali del modulo; zero test unitari eseguiti non costituisce un successo. L'archivio base non contiene gli eseguibili autonomi di valutazione IR/proc. Vettori espliciti o tick dei canali richiedono un bundle di valutazione verificato aggiuntivo, ammesso durante l'installazione con --evaluator-bundle e --evaluator-manifest-sha256. Esaminare le capacità prima di richiedere queste operazioni. La generazione di codice pipeline upstream supporta da 1 a 64 stadi; la pianificazione con ritardo unitario non è una temporizzazione del silicio caratterizzata.

compute

I comandi di richiesta accettano --project. L'input di simulazione/Evolve è limitato a 4 MiB; quello di verifica a 16 MiB. Il componente incluso alti-rtl-cuda gestisce questo percorso. compute rtl-evolve accetta altifigence.rtl.evolve-request.v1, con la richiesta di generazione nativa esistente annidata in request; non è un involucro di operazione evolve run.

Evolve CUDA calcola diagnostica limitata dell'attività combinatoria. Generazione dei candidati, controlli di correttezza, sintesi e valutazione degli obiettivi rimangono sulla CPU. Gli strumenti Icarus effettivi iverilog e vvp devono essere disponibili nella configurazione degli strumenti dell'host. cpu-reference richiede cuda_timeout_ms: 0 e device_memory_bytes: 0; cuda rifiuta l'esecuzione non disponibile anziché usare un ripiego. Usare un nuovo request.run_dir con una directory padre esistente.

La richiesta limita generazioni e figli a 1–16, isole a 1–4, valutazioni pianificate totali a 256 e figli LLM a zero. La memoria del dispositivo è un budget limitato per i buffer del worker, non un limite alla memoria totale del driver. Il valore locale facoltativo cancel_file e le scadenze supportano l'annullamento cooperativo; le chiamate agli strumenti nativi mantengono i propri limiti. Un risultato CUDA riuscito richiede attività effettiva dei candidati accettati e provenienza hardware archiviata, non il semplice rilevamento del dispositivo o una verifica iniziale. L'accordo funzionale CPU/CUDA non dimostra un incremento di velocità.

Comandi mancanti nel download corrente

I namespace precedentemente omessi eda e reports sono ora instradati:

Si tratta di operazioni limitate di ispezione, parsing o associazione, non di esecuzione generale di strumenti EDA. ide init e i comandi Evolve nativi espliciti sono anch'essi disponibili. Il percorso di compatibilità alti-rtl-runner non distribuito descritto sopra rimane una limitazione distinta; non dedurre il supporto dalla sola guida.

Preparare un flusso di lavoro del motore

1. Scegliere l'operazione e leggere la risposta delle capacità installate e la guida del sottocomando.

2. Creare un piccolo input salvato nel progetto selezionato e identificarne il top/modulo o il punto di ingresso.

3. Fornire gli strumenti esterni richiesti e usare un backend esplicito quando la richiesta supporta la selezione CPU/CUDA.

4. Eseguire una volta con risorse limitate e conservare la diagnostica e il risultato nativo completo.

5. Esaminare il backend effettivo, gli input, gli artefatti di output e le metriche non supportate prima di costruire un flusso più ampio.

Usare Analisi DDS per il flusso grafico ed Evolve per il confronto dei candidati. Il supporto dei motori CLI, un pannello desktop e un percorso Cloud sono integrazioni distinte; verificare il flusso che verrà effettivamente usato.