CLI इंजन कमांड

परिचय

यह पृष्ठ स्थानीय डिज़ाइन इंजन कमांड, उनके मुख्य तर्क और निष्पादन सीमाएँ बताता है। सभी विकल्प और मान enum की सूची के लिए इंस्टॉल कमांड के अंतिम उपकमांड की --help उपयोग करें। इंजीनियरिंग प्रमाण के रूप में उपयोग करने से पहले परिणाम की अपनी सीमाएँ पढ़ें।

पहले CLI कमांड इंटरफ़ेस पढ़ें। इसमें रूटिंग, निकास कोड, रसीद एनवेलप और निकटवर्ती बाइनरी हल करने का नियम है, जिन पर नीचे हर कमांड निर्भर है। job नेमस्पेस, analyze run, और evolve run को CLI जॉब और Cloud कमांड में देखें।

तालिकाओं में उपयोग की गई परिपाटी:

• <ANGLE> स्थितीय तर्क है; [ANGLE]... दोहराया जा सकने वाला वैकल्पिक तर्क है।

• तालिका के आवश्यक कॉलम के विकल्प मौजूद होने चाहिए, नहीं तो कुछ लॉन्च करने से पहले कमांड 2 से बाहर निकलता है।

• हर उपकमांड --json और -h/--help भी स्वीकार करता है। इन्हें हर पंक्ति में दोहराया नहीं गया है।

• --project का अर्थ --project <PROJECT> है, सापेक्ष इनपुट और आउटपुट पथ के लिए वैकल्पिक कार्य डायरेक्टरी, जब तक कोई पंक्ति कुछ और न बताए। उसे वास्तविक डायरेक्टरी पर हल होना चाहिए; हल न हो सकने वाले मान का निकास 2 है।

capabilities

alti capabilities प्रमाणित इंस्टॉल संरचना जाँचता है और उसका ऑपरेशन इंटरफ़ेस बताता है। पहले Linux पर इंस्टॉल करें पूरा करें; 0.1.9 का अंतर्निहित बूटस्ट्रैप पहले गायब रसीद और पेलोड संरचना देता है। क्षमता जवाब किसी कर्नेल या डिज़ाइन के निष्पादन का प्रमाण नहीं है।

rtl

अट्ठाईस उपकमांड। rtl compile और rtl synthesize दो संगतता मार्ग हैं जिनमें --runner होता है; हर अन्य rtl उपकमांड स्थानीय और बिना शर्त चलता है।

कमांड physical run और px analyze के विपरीत, ये दोनों passthrough तर्कों के बिना भी इंजन लॉन्च करते हैं, क्योंकि प्रत्येक निश्चित इंजन ऑपरेशन देता है। फिर इंजन गायब तर्क की अपनी त्रुटि बताता है और उसकी निकास स्थिति बिना बदलाव आगे जाती है। उन्हें आवश्यक तर्क -- के बाद दें।

--schematic तीन rtl artifact उपकमांड पर निश्चित स्कीमैटिक रसीद स्टोर चुनता है, RTL ऑपरेशन परिणाम स्टोर के बजाय।

--entry-id कमिट की गई पहचान के अंतिम उपकमांड पर ठीक 64 छोटे हेक्साडेसिमल वर्ण होना चाहिए। किसी अन्य मान का निकास 2 और संदेश entry id must be exactly 64 lowercase hexadecimal characters है।

rtl schematic की सीमाएँ

rtl schematic कुछ लॉन्च करने से पहले पथ सत्यापित करता है। निम्न में किसी नियम को तोड़ने पर हर स्रोत फ़ाइल, इनक्लूड डायरेक्टरी और डिफ़ाइन प्रवेश में अस्वीकार होता है:

पथ चुने प्रोजेक्ट के सापेक्ष होने चाहिए, - से शुरू नहीं होने चाहिए, नियंत्रण बाइट और .. शामिल नहीं होने चाहिए। --top और डिफ़ाइन नाम 1 से 128 बाइट के SystemVerilog पहचानकर्ता होने चाहिए; डिफ़ाइन में = के बाद मान हो सकता है, कुल अधिकतम 4096 बाइट।

rtl target-analysis विकल्प

admit और preflight stdin से मानक स्रोत बंडल JSON पढ़ते हैं और दोनों को वही ग्यारह विकल्प चाहिए: --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>, और --deadline-unix-ms <N>. --cell-decomposition वैकल्पिक बूलियन फ़्लैग है।

--cpu-slots 32-बिट अहस्ताक्षरित पूर्णांक है; --memory-bytes, --max-wall-time-ms, और --deadline-unix-ms 64-बिट अहस्ताक्षरित पूर्णांक हैं।

दोनों CSV में दोहराया या सूची से बाहर मान पार्स करते समय अस्वीकार होता है, उदाहरण के लिए targets must be a comma-separated subset of: generic-asic, sky130-asic, xc7-fpga।

सिमुलेशन अनुरोध एनवेलप

<REQUEST_JSON> फ़ाइल का प्रोजेक्ट सापेक्ष पथ है, जिसे CLI कुछ लॉन्च करने से पहले पढ़ता और जाँचता है। पथ सामान्यीकृत और सापेक्ष होना चाहिए, किसी घटक पर सांकेतिक लिंक पार नहीं करना चाहिए और प्रोजेक्ट रूट के भीतर हल होना चाहिए। फ़ाइल नियमित हो और 260 MiB से बड़ी न हो।

उसका JSON ठीक चार कुंजियों वाला ऑब्जेक्ट होना चाहिए:

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

operationId का मान altifigence.rtl.simulate.v1 होना चाहिए जब कमांड rtl simulate हो, और altifigence.rtl.simulate.v2 होना चाहिए जब कमांड rtl simulate-v2 हो। बेमेल होने पर लॉन्च से पहले RTL simulation request must be the exact <id> envelope देकर अस्वीकार होता है।

कमिट की गई पहचान के उपकमांड नहीं चल सकते

आठ rtl *-committed-identities list और read अंतिम उपकमांड alti-rtl-runner नाम वाले इंजन को डिस्पैच करते हैं। यह बाइनरी रिलीज़ द्वारा बिल्ड और भेजी गई 24 इंजन बाइनरी में से नहीं है, इसलिए सही इंस्टॉलेशन से यह न alti के निकटवर्ती स्थान पर और न PATH पर मिल सकती है। इन्हें चलाने पर स्थानीय इंजन रसीद में status: "unavailable" और 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",
  ...
}

इन आठ कमांड पर स्वचालन न बनाएँ।

sv

तेईस उपकमांड, सभी स्थानीय और बिना शर्त। कोई --runner स्वीकार नहीं करता।

स्थितीय मान के नियम:

• <LINE> और <COLUMN> 1-आधारित गैर-शून्य पूर्णांक हैं। 0 का निकास 2 है।

• <REPLACEMENT> SystemVerilog पहचानकर्ता होना चाहिए: पहला वर्ण अक्षर, _, या $ है और बाकी अक्षर-अंक, _, या $ हैं।

• <REVIEWED_PLAN_SHA256> 64 छोटे हेक्साडेसिमल वर्ण होने चाहिए।

• <STABLE_ID> छोटे अक्षर, अंक और हाइफ़न से बना 1 से 128 वर्ण का होना चाहिए।

• --filter 1 से 128 गैर-नियंत्रण बाइट होना चाहिए; --limit 1 से 64 का पूर्णांक होना चाहिए, और --limit 65 का निकास 2 है।

sv frontend rename-apply एकमात्र sv उपकमांड है जिसे --project चाहिए, और मान वास्तविक डायरेक्टरी का पूर्ण पथ होना चाहिए जो सांकेतिक लिंक न हो। इसके बिना कमांड 1 से बाहर निकलता है और संदेश SV rename apply requires --project <absolute-workspace> देता है।

sv review immediate और sv review interprocess stdin से SystemVerilog स्रोत पढ़ते हैं। वे एकमात्र sv उपकमांड हैं जिनके अपने इंजन alti-sv-immediate-review और alti-sv-interprocess-review हैं; नेमस्पेस का बाकी सब alti-sv-frontend उपयोग करता है।

sv uvm simulation admit को तेरह विकल्प चाहिए: --bundle-id, --bundle-sha256, --source-count, --source-bytes, --test, --top, --clock, --period-ps, --cycles, --max-wall-time-ms, --max-cpu-cores, --max-memory-bytes, और --max-artifact-bytes. sv uvm simulation preflight को इन तेरह के साथ --attempt-id, --observed-at-unix-ms, और --deadline-unix-ms चाहिए, तथा वह बूलियन --cancellation-requested (डिफ़ॉल्ट false) भी स्वीकार करता है। --source-count 32-बिट अहस्ताक्षरित पूर्णांक है, --max-cpu-cores 16-बिट अहस्ताक्षरित पूर्णांक है और बाकी संख्यात्मक विकल्प 64-बिट अहस्ताक्षरित पूर्णांक हैं।

verification

--tolerance-pct परिमित गैर-ऋणात्मक संख्या होना चाहिए; ऋणात्मक या गैर-संख्यात्मक मान का निकास 2 और संदेश tolerance-pct must be a finite non-negative number है।

--format यहाँ इंजन का अपना आउटपुट फ़ॉर्मैट चुनता है और CLI स्तर के --json एनवेलप फ़्लैग से स्वतंत्र है। दोनों साथ उपयोग कर सकते हैं।

trace

<FORMAT> विकल्प trace export पर स्थितीय मान enum है, फ़्लैग नहीं, और इनपुट पथ से पहले आता है। उसके मान vcd और chrome हैं।

--reference अतिरिक्त संदर्भ आर्टिफ़ैक्ट नाम देने के लिए दोहराया जा सकता है। <TRACE_ARTIFACT_ID>, संदर्भ ID और <PACKAGE_ID> हाइफ़न से शुरू हो सकते हैं और -- की ज़रूरत नहीं है।

ध्यान दें कि alti trace बिना उपकमांड स्थानीय पार्सर तक जाता है और 2 से बाहर निकलकर उपकमांड माँगता है। अंतर्निहित कार्रवाई मैनिफ़ेस्ट की एक शब्द वाली trace कार्रवाई इस रिलीज़ में कमांड लाइन से पहुँच योग्य नहीं है; CLI जॉब और Cloud कमांड देखें।

labs

केवल पढ़ने वाले विवरणक और सत्यापन। CLI से वर्कफ़्लो निष्पादन उपलब्ध नहीं है।

labs validate अपने दो इनपुट पर सख्त है और नीचे हर नियम इंजन शुरू होने से पहले जाँचा जाता है:

• --project वास्तविक डायरेक्टरी का पूर्ण पथ होना चाहिए, सांकेतिक लिंक नहीं।

• <DESCRIPTOR> वर्कस्पेस सापेक्ष होना चाहिए, इसमें .. या रूट घटक नहीं होना चाहिए और अधिकतम 4096 बाइट होना चाहिए।

• इसका एक्सटेंशन .json होना चाहिए।

• इसे अधिकतम 1048576 बाइट की वास्तविक नियमित फ़ाइल पर हल होना चाहिए और हल किया पथ अब भी प्रोजेक्ट के भीतर होना चाहिए।

tcl

पहले चार पैकेज किए alti-tcl इंजन के विवरणकों से उत्तर देते हैं और मानक स्थानीय इंजन एनवेलप निकालते हैं।

tcl evaluate तीन तरह से अलग है। यह stdin से स्क्रिप्ट पढ़ता है, सीमा 4194304 बाइट है; खाली इनपुट अस्वीकार होता है। इसे alti-tcl-local-runner चाहिए, जो alti के बिल्कुल निकटवर्ती स्थान पर हो और कोई PATH फ़ॉलबैक नहीं है; यह उसे इंस्टॉल भरोसा श्रृंखला के अनुसार जाँचता है। 0.1.9 बूटस्ट्रैप इस मार्ग के लिए आवश्यक निश्चित हस्ताक्षरित Tcl घटक इंस्टॉल करता है; इंस्टॉल बाइनरी उपयोग करें। यह अपनी रसीद स्कीमा altifigence.cli.tcl-evaluation.v1 और अपने निकास कोड निकालता है — दोनों CLI कमांड इंटरफ़ेस में हैं।

eidb

eidb capabilities, eidb readback, और eidb semantic-readback कोई --project नहीं लेते; CLI के संदर्भ में वे बिना पथ के हैं।

physical

बयालीस उपकमांड। physical run संगतता मार्ग है जिसमें --runner होता है; बाकी स्थानीय और बिना शर्त चलते हैं, और हर एक अपना उपकमांड नाम सीधे alti-physical-runner को इंजन ऑपरेशन के रूप में देता है। इस नेमस्पेस में CLI की भूमिका तर्क प्रवेश और रसीद संरचना है, इसलिए इंटरफ़ेस इतना नियमित है कि दो समूहों में दिया जा सकता है।

हर प्रविष्टि स्कोप की आगे की कार्रवाई पहले के प्रोजेक्ट स्कोप ऑपरेशन से बनी स्थायी प्रविष्टि पढ़ती है। --entry-id न देने पर 2 से कुछ लॉन्च करने से पहले निकास होता है। यह बयालीस में से छत्तीस हैं। बाकी छह हैं:

physical route-evidence-closure read दो चरण वाला कमांड है: CLI पहले कमिट की गई पहचानें सूचीबद्ध करता है, आपकी --identity-key-sha256 उस सूची में होना आवश्यक करता है, फिर ठीक वही एक पहचान पढ़ता है। 64 छोटे हेक्साडेसिमल वर्ण की न हो या वर्तमान सूची में न हो तो कुंजी दूसरे चरण से पहले निकास 1 से अस्वीकार होती है। सूची चरण बिना पथ का है और --project नहीं लेता।

physical run बिना इंजन ऑपरेशन के लॉन्च नहीं होगा; ऑपरेशन -- के बाद दें:

पाठ

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

इसका निकास 1 है। स्वीकृत पुराने ऑपरेशन --capabilities-json, capabilities, और execute हैं; अन्य कोई भी निकास 1 और संदेश legacy local engine operation ... is not in the public allowlist देता है।

px

px analyze संगतता मार्ग है जिसमें --runner होता है। स्थितीय तर्क का नाम <INPUTS_RELATIVE_...> हो तो उसे प्रोजेक्ट की inputs/ डायरेक्टरी के अंतर्गत हल किया जाता है, आपकी कार्य डायरेक्टरी के अनुसार नहीं।

इनमें से तीन अपनी सहायता में अपनी सीमाएँ बताते हैं और वे अनुबंध का हिस्सा हैं: px static-timing स्पष्ट रूप से गैर-साइनऑफ़ है, px spef-summary में स्पष्ट रूप से विश्लेषण अधिकार नहीं है, और px fdtd2d preflight परिणाम के बजाय तैयारी बाधा बताता है। आउटपुट को उसी अनुसार मानें।

जैसे physical run, वैसे ही px analyze के लिए भी -- के बाद पुराना ऑपरेशन चाहिए, नहीं तो निकास 1 है। उसकी अनुमति सूची capabilities और execute है।

PX CPU और CUDA ऑपरेशन

ये कमांड --project स्वीकार करते हैं; पहले दो --timeout-ms 1..300000 भी स्वीकार करते हैं। स्पष्ट cuda के लिए उपयोग योग्य CUDA निष्पादन चाहिए। auto अलग से इंजन का दर्ज CPU फ़ॉलबैक अनुमत करता है; बताए बैकएंड को देखें। ये सीमित संख्यात्मक ऑपरेशन सामान्य भौतिक साइनऑफ़ या हर PX ऑपरेशन का GPU त्वरण स्थापित नहीं करते।

isa

छह में से चार उपकमांड CX स्रोत केवल stdin से पढ़ते हैं। isa run संगतता मार्ग है जिसमें --runner होता है।

--check ठीक elaboration, static-semantics, encoding-uniqueness, और decode-determinism स्वीकार करता है। --bit-len 32-बिट अहस्ताक्षरित पूर्णांक है। --text और --bits खाली या केवल रिक्त स्थान वाले नहीं होने चाहिए।

कमांड physical run और px analyze के विपरीत, isa run निश्चित इंजन ऑपरेशन देता है, इसलिए passthrough तर्कों के बिना लॉन्च होता है और इंजन अपनी आवश्यकताएँ बताता है:

पाठ

$ 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

डेस्कटॉप होस्ट ऑपरेशन। गणना ऊपर के इंजन नेमस्पेस में रहती है।

ide open अलग इंस्टॉल डेस्कटॉप अनुप्रयोग लॉन्च करता है। नीचे के नेटिव वर्कस्पेस, Cloud, सेवा और प्रोजेक्ट निर्माण कमांड अपने स्पष्ट बैकएंड से काम करते हैं।

--project मानक पूर्ण डायरेक्टरी होना चाहिए: पूर्ण, मौजूद डायरेक्टरी, सांकेतिक लिंक न हो और अपने मानक रूप के बराबर हो। symlink से हल होने वाला पथ चुपचाप मानने के बजाय अस्वीकार होता है।

ide open इंजन बाइनरी नहीं उपयोग करता। यह altifigence-ide नाम का निष्पादन योग्य पहले alti के निकटवर्ती स्थान पर और फिर PATH पर ढूँढ़ता है, उसे --project <canonical-dir> के साथ शुरू करता है और altifigence.ide-launcher-receipt.v1 रसीद निकालता है:

निकास स्थिति 0 है जब स्थिति spawned हो, और 1 अन्यथा है। altifigence-ide बाइनरी Digital Design Studio के साथ आता है, CLI आर्काइव के साथ नहीं, इसलिए ide open केवल CLI वाले इंस्टॉलेशन से unavailable बताता है।

नेटिव प्रोजेक्ट और वर्कस्पेस ऑपरेशन

ide init --parent ABSOLUTE_DIR --name NAME मानक, कॉलर स्वामित्व वाली मूल डायरेक्टरी के अंतर्गत नया ढाँचा बनाता है। यह मौजूदा प्रोजेक्ट अधिलेखित नहीं करता। ide workspace UI खोले बिना सहेजी स्थानीय फ़ाइलों पर काम करता है:

नेटिव योजना परिणाम अपारदर्शी, पूरा लागू करने का इनपुट है। वैश्विक --json के बिना कच्चा इंजन आउटपुट सहेजें, समीक्षा करें, फिर वही दस्तावेज़ संबंधित apply कमांड को दें। उदाहरण के लिए, अपने मौजूदा पूर्ण प्रोजेक्ट और टाइप किए पदानुक्रम अनुरोध के साथ:

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"

विफल कमांड का आउटपुट apply में पाइप न करें। नई योजना फ़ाइल चुनें और हर निकास स्थिति जाँचें। फ़ाइल लेखन स्थायी, क्रमबद्ध लेन-देन और वर्तमान स्रोत हैश उपयोग करता है; यह असंबंधित लेखक प्रक्रियाओं के विरुद्ध पूरे फ़ाइलसिस्टम की तात्कालिक परमाण्विकता नहीं है। टकराव के लिए नई समीक्षा चाहिए। पदानुक्रम लेखन सीमित स्रोत चयन और ढाँचा निर्माण है, पूर्ण SystemVerilog अर्थगत रिफ़ैक्टरिंग या समतुल्यता का प्रमाण नहीं।

सेटिंग DDS .alti/ide-settings.json फ़ॉर्मैट, अज्ञात कुंजियाँ और शाब्दिक null मान रखती हैं। पैच रिकर्सिव मर्ज है, RFC 7396 विलोपन नहीं। अनुरोध/परिणाम बजट 256 KiB और गहराई 8 है; नेटिव UI और CLI एक ही .alti/.ide-settings.lock उपयोग करते हैं। CLI वर्तमान प्रोजेक्ट फ़ॉर्मैट को संबोधित करता है, दूसरे स्वतंत्र वैश्विक डेस्कटॉप सेटिंग स्कोप को नहीं।

नेटिव लेन-देन और Git के लिए Linux अनुबंध चाहिए। वर्तमान पुनर्प्राप्ति V1 और V2 दोनों जर्नल पढ़ती है। बाधित create/delete या पदानुक्रम apply के बाद पुराना केवल V1 वाला DDS बैकएंड खोलने से पहले नए CLI का health चलाएँ। पुराना बैकएंड लंबित V2 जर्नल साफ़ किए बिना अस्वीकार करता है। सामान्य रूप से पूर्ण लेन-देन अपना सक्रिय जर्नल साफ़ करते हैं; पारदर्शी पुनर्प्राप्ति बैकएंड अपग्रेड की सलाह है, यह हर पूर्ण CLI संपादन की पूर्वशर्त नहीं।

Git

नेमस्पेस ide workspace git के अंतर्गत सभी कमांड --project ABS लेते हैं:

ये ऑपरेशन नेटिव वर्कस्पेस लेन-देन के अनुसार पुनर्प्राप्ति और क्रमबद्धता करते हैं। वे मनमाने Git तर्क, हुक या रिमोट पुश क्रेडेंशियल उपलब्ध नहीं कराते।

सहेजे स्रोत की खोज

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

नेटिव खोज --match-case, --whole-word, सीमित निश्चित चौड़ाई का --regex, 1–500 मिलान की सीमाएँ और --timeout-seconds 1..120 समर्थन करती है। यह नेटिव files/read सीमा से सहेजा पाठ पढ़ती है, बजट 500 फ़ाइल, हर फ़ाइल 4 MiB, कुल 16 MiB और 1 MiB आउटपुट है। काटे जाने और सामग्री प्रमाण जाँचें। असहेजे संपादक बफ़र खोजे नहीं जाते। Cloud खोज और पुरानी HTTP खोज/प्रतिस्थापन अलग सेवा ऑपरेशन हैं।

xls

नेटिव मार्ग 1–64-बिट मानों वाले सीमित DSLX और XLS IR फ़ंक्शन, constant folding/dead-code removal तथा संयोजी RTL या 1–16 आउटपुट रजिस्टर चरण वाले RTL का समर्थन करता है। अनुरोध cpu या समर्थित बैच मूल्यांकन के लिए स्पष्ट cuda चुनता है। अनुपलब्ध CUDA बैकएंड त्रुटि है, स्वतः CPU रन नहीं। CPU उदाहरण से शुरू करें।

अलग अपस्ट्रीम मार्ग पिन किया सार्वजनिक Google XLS Linux टूलचेन इंस्टॉल करता है, उसका आर्काइव और टूल/stdlib सूची सत्यापित करता है और लाइसेंस फ़ाइलें सुरक्षित रखता है। जब चुना अपस्ट्रीम टूल अनुरोधित ऑपरेशन समर्थन करे, तब यह imports, parametrics, structs, enums, aggregate और मनमानी चौड़ाई के प्रकार तथा procs समर्थन करता है। यह सीमित bits64 पार्सर नहीं उपयोग करता और पूरे Google टूलचेन को CUDA से तेज़ नहीं करता।

अपस्ट्रीम अनुरोध check, eval, convert, optimize, या codegen चुनते हैं। स्पष्ट vectors/ticks के बिना DSLX eval वास्तविक मॉड्यूल टेस्ट चलाता है; शून्य निष्पादित यूनिट टेस्ट सफलता नहीं हैं। आधार आर्काइव में स्वतंत्र IR/proc मूल्यांकनकर्ता निष्पादन योग्य नहीं हैं। स्पष्ट वेक्टर या चैनल टिक के लिए अतिरिक्त सत्यापित मूल्यांकनकर्ता बंडल चाहिए जिसे इंस्टॉल करते समय --evaluator-bundle और --evaluator-manifest-sha256 से स्वीकार किया गया हो। ये ऑपरेशन माँगने से पहले क्षमताएँ देखें। अपस्ट्रीम पाइपलाइन codegen 1–64 चरण समर्थन करता है; उसका unit-delay शेड्यूल विशेषीकृत सिलिकॉन टाइमिंग नहीं है।

compute

अनुरोध कमांड --project स्वीकार करते हैं। Simulation/Evolve इनपुट की सीमा 4 MiB; verify इनपुट की 16 MiB है। पैकेज किया alti-rtl-cuda इस मार्ग का स्वामी है। compute rtl-evolve अनुरोध altifigence.rtl.evolve-request.v1 लेता है, जिसमें मौजूदा नेटिव जनरेशन अनुरोध request के भीतर होता है; यह evolve run ऑपरेशन एनवेलप नहीं है।

Evolve CUDA सीमित संयोजी गतिविधि डायग्नोस्टिक की गणना करता है। प्रस्ताव निर्माण, शुद्धता जाँच, संश्लेषण और उद्देश्य मूल्यांकन CPU पर ही रहते हैं। वास्तविक Icarus iverilog और vvp होस्ट टूल कॉन्फ़िगरेशन से उपलब्ध होने चाहिए। cpu-reference के लिए cuda_timeout_ms: 0 और device_memory_bytes: 0 चाहिए; cuda फ़ॉलबैक करने के बजाय अनुपलब्ध निष्पादन अस्वीकार करता है। नया request.run_dir उपयोग करें जिसका मूल फ़ोल्डर मौजूद हो।

अनुरोध में पीढ़ियाँ और बच्चे 1–16, द्वीप 1–4, कुल नियोजित मूल्यांकन 256 और LLM बच्चे शून्य तक सीमित हैं। डिवाइस मेमोरी सीमित वर्कर बफ़र बजट है, कुल ड्राइवर मेमोरी की सीमा नहीं। वैकल्पिक स्थानीय cancel_file और समय सीमाएँ सहयोगी रद्दीकरण समर्थन करते हैं; नेटिव टूल कॉल अपनी सीमाएँ रखते हैं। सफल CUDA परिणाम के लिए वास्तव में स्वीकृत प्रस्ताव गतिविधि और संग्रहीत हार्डवेयर उत्पत्ति चाहिए, केवल डिवाइस खोज या प्रारंभिक जाँच नहीं। CPU/CUDA कार्यात्मक सहमति गति बढ़ने का दावा नहीं है।

वर्तमान डाउनलोड से गायब कमांड

पहले छोड़े गए eda और reports नेमस्पेस अब रूट किए जाते हैं:

ये सीमित निरीक्षण, पार्सिंग या बाइंडिंग ऑपरेशन हैं, सामान्य EDA टूल निष्पादन नहीं। ide init और स्पष्ट नेटिव Evolve कमांड भी उपलब्ध हैं। ऊपर बताया न भेजा गया alti-rtl-runner संगतता मार्ग अलग सीमा बना रहता है; केवल सहायता से समर्थन का अनुमान न लगाएँ।

इंजन वर्कफ़्लो तैयार करें

1. ऑपरेशन चुनें और उसका इंस्टॉल क्षमता जवाब तथा अंतिम उपकमांड की सहायता पढ़ें।

2. चुने प्रोजेक्ट में छोटा सहेजा इनपुट बनाएँ और उसका टॉप/मॉड्यूल या प्रवेश बिंदु पहचानें।

3. आवश्यक बाहरी टूल दें और अनुरोध CPU/CUDA चयन समर्थन करे तो स्पष्ट बैकएंड उपयोग करें।

4. सीमित संसाधनों के साथ एक बार चलाएँ और डायग्नोस्टिक तथा पूरा नेटिव परिणाम रखें।

5. बड़ा वर्कफ़्लो बनाने से पहले वास्तविक बैकएंड, इनपुट, आउटपुट आर्टिफ़ैक्ट और असमर्थित मेट्रिक देखें।

ग्राफ़िकल वर्कफ़्लो के लिए DDS विश्लेषण और प्रस्ताव तुलना के लिए Evolve उपयोग करें। CLI इंजन समर्थन, डेस्कटॉप पैनल और Cloud रूट अलग एकीकरण हैं; वास्तव में उपयोग किए जाने वाले वर्कफ़्लो को जाँचें।