💻 computer science

AI-Generated RTL Code: A Functional Evaluation of Natural-Language and HLS Prompting

यह अध्ययन उच्च-स्तरीय विनिर्देशों (high-level specifications) से कार्यात्मक वर्डिग (Verilog) RTL उत्पन्न करने की वाणिज्यिक LLMs की क्षमता का मूल्यांकन करता है, जिसमें यह पाया गया है कि HLS-C प्रॉम्प्ट्स का उपयोग करने से प्राकृतिक भाषा की तुलना में शुद्धता में उल्लेखनीय सुधार होता है, जबकि सिमुलेशन त्रुटियों और परिवर्तनशील बिट-चौड़ाई (variable bit-widths) केAcross सीमित सामान्यीकरण (limited generalization) संबंधी निरंतर चुनौतियों का भी पता चलता है।

मूल लेखक: Giordano Santorum Lorenzetto, Vanderlei Bonato, Oliver Sinnen

प्रकाशित 2026-08-05

📖 7 मिनट में पढ़ें🧠 गहराई से पढ़ें

CC BY 4.0

मूल लेखक: Giordano Santorum Lorenzetto, Vanderlei Bonato, Oliver Sinnen

मूल पेपर CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। ✨ नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

कल्पना कीजिए कि आप एक माइक्रोचिप के भीतर एक छोटा, सुपर-फास्ट कारखाना बनाने की कोशिश कर रहे हैं। यह ऐसा कारखाना नहीं है जो खिलौने या कारें बनाता है; यह एक डिजिटल कारखाना है जो प्रकाश की गति से सूचनाओं को प्रोसेस करता है। इसे बनाने के लिए, इंजीनियर एक विशेष प्रकार की निर्देश पुस्तिका लिखते हैं जिसे RTL कोड (रजिस्टर-ट्रांसफर लेवल) कहा जाता है। इस कोड को कारखाने के कन्वेयर बेल्ट, असेंबली आर्म और ट्रैफिक लाइट के ब्लूप्रिंट (खाके) के रूप में समझें। यदि ब्लूप्रिंट में एक भी छोटी सी गलती होती है, तो पूरा कारखाना जाम हो सकता है, उसमें आग लग सकती है, या वह पूरी तरह से काम करना बंद कर सकता है।

लंबे समय तक, इन ब्लूप्रिंट्स को लिखना एक गुप्त, कठोर भाषा बोलने जैसा था जिसे केवल कुछ विशेषज्ञ ही समझते हैं। लेकिन अब, हमारे पास आर्टिफिशियल इंटेलिजेंस (AI) है जो सॉफ्टवेयर के लिए कोड लिखने में अविश्वसनीय रूप से कुशल है—जैसे आपके फोन के ऐप्स या वेबसाइटें। लोगों ने सोचना शुरू किया: "यदि AI सॉफ्टवेयर कोड इतनी अच्छी तरह से लिख सकता है, तो क्या वह ये जटिल हार्डवेयर ब्लूप्रिंट भी लिख सकता है?" यही वह बड़ा सवाल था जिसे शोधकर्ताओं ने हल करने की कोशिश की। वे देखना चाहते थे कि क्या एक स्मार्ट AI एक साधारण हार्डवेयर कार्य के विवरण को देखकर उसे एक काम करने वाले हार्डवेयर ब्लूप्रिंट में बदल सकता है, या वह सख्त नियमों के कारण भ्रमित हो जाएगा।

प्रयोग: बातचीत बनाम कोडिंग

शोधकर्ताओं ने यह देखने के लिए एक विशाल परीक्षण आयोजित किया कि विभिन्न AI मॉडल इस काम को कितनी अच्छी तरह कर सकते हैं। उन्होंने AI को ब्लूप्रिंट मांगने के दो बहुत अलग तरीके दिए:

"बातूनी" दृष्टिकोण (प्राकृतिक भाषा): उन्होंने AI को साधारण अंग्रेजी में बताया कि हार्डवेयर को क्या करना चाहिए। उदाहरण के लिए, "एक ऐसी मशीन बनाओ जो दो संख्याओं को गुणा करे।" यह किसी दोस्त से पूछने जैसा है, "हे, मेरे लिए एक सैंडविच बना दो," बिना किसी रेसिपी के।
"प्रोग्रामर" दृष्टिकोण (HLS-C प्रॉम्प्टिंग): साधारण अंग्रेजी के बजाय, उन्होंने AI को C कोड (एक सामान्य प्रोग्रामिंग भाषा) का एक हिस्सा दिया जिसने तर्क (logic) का वर्णन किया। यह AI को एक विस्तृत रेसिपी देने जैसा है जिसे वह बहुत अच्छी तरह जानता है, और फिर उससे उस रेसिपी को विशिष्ट "हार्डवेयर भाषा" (Verilog) में अनुवाद करने के लिए कहना।

उन्होंने सात अलग-अलग AI मॉडलों पर इसका परीक्षण किया (GPT-4 और Gemini जैसे बड़े नामों सहित) और उन्हें आठ अलग-अलग प्रकार के डिजिटल सर्किट बनाने के लिए कहा, जिनमें सरल ट्रैफिक लाइट कंट्रोलर से लेकर जटिल गणित कैलकुलेटर तक शामिल थे। उन्होंने प्रत्येक परीक्षण को 30 बार चलाया ताकि यह देखा जा सके कि क्या AI इसे संयोग से सही कर रहा है या वह वास्तव में कार्य को समझता है।

परिणाम: रेसिपी की जीत

निष्कर्ष काफी स्पष्ट थे, और वे आपको आश्चर्यचकित कर सकते हैं। जब AI के साथ केवल साधारण अंग्रेजी में "चैट" की गई, तो उसे संघर्ष करना पड़ा। औसतन, उसके द्वारा बनाए गए ब्लूप्रिंटों में से केवल लगभग 26.9% ही वास्तव में काम कर रहे थे। ज्यादातर समय, AI ने ऐसी गलतियाँ कीं जो गलत ईंटों के साथ घर बनाने की कोशिश करने जैसी थीं—कोड या तो कंपाइल (शुरू) ही नहीं हो पाता था, या वह चलता तो था लेकिन गलत परिणाम देता था।

हालाँकि, जब शोधकर्ताओं ने C कोड रेसिपी (HLS-C प्रॉम्प्टिंग) का उपयोग किया, तो AI का प्रदर्शन काफी बढ़ गया। सफलता दर बढ़कर 39.5% हो गई। यह एक बड़ी सुधार है! यह सुझाव देता है कि भले ही AI स्मार्ट है, लेकिन वह एक प्रोग्रामर की तरह सोचता है, न कि एक हार्डवेयर इंजीनियर की तरह। जब आप उसे एक संरचित कोड रेसिपी देते हैं, तो वह उन चरणों को हार्डवेयर भाषा में अनुवाद करने का सटीक तरीका जान जाता है। यह ऐसा है जैसे AI कह रहा हो, "ओह, आपने मुझे फ्रेंच में रेसिपी दी? मैं उसे पूरी तरह से स्पेनिश में अनुवाद कर सकता हूँ। लेकिन अगर आप सिर्फ अंग्रेजी में 'सैंडविच बनाओ' कहेंगे, तो मैं गलत सामग्री का अनुमान लगा सकता हूँ।"

"अजीब नंबर" परीक्षण: क्या यह याद रख रहा है या समझ रहा है?

यह देखने के लिए कि क्या AI केवल पहले देखे गए उत्तरों की नकल कर रहा था (याद रखना) या वास्तव में इन मशीनों को बनाने की समझ रखता था, शोधकर्ताओं ने एक चाल चली। उन्होंने AI को अजीब, असामान्य बिट्स (bits) का उपयोग करके एक मल्टीप्लायर (गणित की मशीन) बनाने के लिए कहा, जैसे कि 7 बिट्स या 31 बिट्स। ये ऐसे नंबर हैं जिन्हें आप वास्तविक जीवन में लगभग कभी नहीं देखते, इसलिए AI इसे अपने प्रशिक्षण डेटा से केवल कॉपी नहीं कर सकता था।

यहाँ के परिणाम दिलचस्प थे। कुछ स्मार्ट AI मॉडल (जैसे o4-mini और Gemini 2.5 Pro) ने इन अजीब नंबरों को लगभग पूरी तरह से संभाला, और 90% से अधिक बार सही परिणाम दिए। यह दर्शाता है कि ये मॉडल केवल कॉपी-पेस्ट नहीं कर रहे हैं; वे वास्तव में मशीन बनाने के तर्क को समझते हैं। वे सामान्यीकरण (generalize) कर सकते हैं, जिसका अर्थ है कि वे नियमों को उन नई स्थितियों पर लागू कर सकते हैं जिन्हें उन्होंने पहले कभी नहीं देखा।

कमी: यह अभी भी पूर्ण नहीं है

इन सुधारों के बावजूद, यह शोध पत्र स्पष्ट रूप रूप से कहता है कि हम अभी वहां नहीं पहुंचे हैं। भले ही "रेसिपी" दृष्टिकोण के साथ, AI अभी भी सफलता से अधिक बार विफल होता है। सबसे बड़ी समस्या यह नहीं है कि AI सिंटैक्स (जैसे स्पेलिंग की गलती) को गलत करता है, बल्कि यह है कि वह टाइमिंग (समय) को गलत करता है।

कल्पना कीजिए कि AI एक ऐसा कारखाना बनाता है जहाँ कन्वेयर बेल्ट एक सेकंड बहुत तेज़ चलती है। ब्लूप्रिंट एकदम सही दिखता है, और मशीन चालू हो जाती है, लेकिन उत्पाद पैक होने से पहले ही लाइन से गिर जाते हैं। अध्ययन में, ये "सिमुलेशन त्रुटियां" सबसे आम विफलताएं थीं। AI अक्सर ऐसा कोड बनाता है जो दिखने में सही लगता है लेकिन जब घड़ी टिक-टिक करती है, तो व्यवहार थोड़ा गलत हो जाता है। इन त्रुटियों को ठीक करना कठिन है क्योंकि इसके लिए हार्डवेयर के समय के साथ व्यवहार की गहरी समझ की आवश्यकता होती है, जो AI के पास अभी भी कम है।

शोधकर्ताओं ने यह भी पाया कि जब AI सफल होता था, तो परिणामी हार्डवेयर अक्सर मानव विशेषज्ञों द्वारा लिखे गए ब्लूप्रिंट के समान या उससे भी तेज़ होता था। यह एक बड़ी जीत है, जो सुझाव देती है कि यदि हम AI को उन छोटी टाइमिंग गलतियों को रोकने में सक्षम बना सकें, तो यह इंजीनियरों के लिए एक अत्यंत शक्तिशाली सहायक बन सकता है।

मुख्य निष्कर्ष

तो, इससे क्या सीख मिलती है? AI कंप्यूटर चिप्स को डिजाइन करने में हमारी मदद करने में बहुत अच्छा हो रहा है, लेकिन यह अभी पूरी तरह से काम संभालने के लिए तैयार नहीं है। यह एक प्रतिभाशाली इंटर्न की तरह है जो एक शानदार डिज़ाइन का मसौदा तैयार कर सकता है यदि आप उसे एक स्पष्ट, संरचित योजना (जैसे C कोड रेसिपी) दें, लेकिन उसे अंतिम विवरणों की जांच करने और यह सुनिश्चित करने के लिए एक मानव पर्यवेक्षक की आवश्यकता होती है कि कारखाना क्रैश न हो।

अध्ययन बताता है कि इन AI मॉडलों से बात करने के लिए केवल साधारण अंग्रेजी में चैट करने की तुलना में कोड-आधारित प्रॉम्प्ट का उपयोग करना कहीं बेहतर तरीका है। हालांकि AI अभी भी ऐसी गलतियाँ करता है जिनके लिए मानवीय सुधार (debugging) की आवश्यकता होती है, लेकिन यह पहले से ही हार्डवेयर इंजीनियरिंग में नए लोगों को शुरुआत करने में मदद करने और डिजाइन प्रक्रिया को तेज करने के लिए एक शक्तिशाली उपकरण साबित हो रहा है। हम उस बिंदु पर नहीं हैं जहाँ AI बिना किसी मदद के शून्य से चिप बना सके, लेकिन हम निश्चित रूप से सही दिशा में बढ़ रहे हैं।

तकनीकी सारांश: AI-जनरेटेड RTL कोड: नेचुरल-लैंग्वेज और HLS प्रॉम्प्टिंग का एक कार्यात्मक मूल्यांकन

समस्या विवरण
हार्डवेयर डिज़ाइन की बढ़ती जटिलता ने रजिस्टर-ट्रांसफर लेवल (RTL) कोड उत्पन्न करने के लिए लार्ज लैंग्वेज मॉडल्स (LLMs) का उपयोग करने में रुचि जगाई है। जबकि LLMs ने सॉफ्टवेयर कोड जनरेशन में दक्षता प्रदर्शित की है, हार्डवेयर विकास के लिए उनकी प्रयोज्यता अभी भी कम खोजी गई है। हार्डवेयर डिज़ाइन अधिक सख्त आवश्यकताओं को लागू करता है, जिसमें कार्यात्मक शुद्धता, संसाधन अनुकूलन, और कंकरेंसी (concurrency) एवं टाइमिंग का सटीक प्रबंधन आवश्यक है। हालांकि हाई-लेवल सिंथेसिस (HLS) टूल्स डिजाइनरों को C/C++ में हार्डवेयर का वर्णन करने की अनुमति देते हैं, लेकिन उन्हें अक्सर विशिष्ट निर्देशों की आवश्यकता होती है और परिणामी RTL संरचना पर सीमित नियंत्रण प्रदान करते हैं। यह अध्ययन जांच करता है कि क्या व्यावसायिक रूप से उपलब्ध, सामान्य-उद्देश्य वाले LLMs बिना फाइन-ट्यूनिंग के उच्च-स्तरीय विशिष्टताओं से सीधे कार्यात्मक रूप से सही Verilog RTL उत्पन्न कर सकते हैं, और यह मूल्यांकन करता है कि विभिन्न प्रॉम्प्टिंग रणनीतियाँ जनरेशन की गुणवत्ता को कैसे प्रभावित करती हैं।

कार्यप्रणाली
अनुसंधान में RTLLM बेंचमार्क का उपयोग किया गया, जो विभिन्न हार्डवेयर मॉड्यूल (कॉम्बिनेशनल लॉजिक से लेकर सीक्वेंशियल सर्किट तक) के लिए नेचुरल लैंग्वेज स्पेसिफिकेशन, रेफरेंस Verilog इम्प्लीमेंटेशन और फंक्शनल टेस्टबेंचेस का एक डेटासेट है। लेखकों ने OpenAI (GPT-4.1, GPT-4o, o4-mini) और Google (Gemini 1.5 Pro, 2.0 Flash, 2.5 Flash, 2.5 Pro) के सात अलग-अलग LLMs का मूल्यांकन किया।

दो प्रॉम्प्टिंग रणनीतियों की ज़ीरो-शॉट दृष्टिकोण का उपयोग करके तुलना की गई:

नेचुरल लैंग्वेज (NL) प्रॉम्प्टिंग: कार्यक्षमता, I/O पोर्ट्स और कार्यान्वयन दिशानिर्देशों के प्रत्यक्ष टेक्स्ट विवरण।
HLS-स्टाइल C प्रॉम्प्टिंग: वांछित हार्डवेयर कार्यक्षमता का प्रतिनिधित्व करने वाले संरचित C कोड स्निपेट्स, जिन्हें AMD Vitis HLS द्वारा सिंथेसाइज़ करने के लिए डिज़ाइन किया गया है।

मूल्यांकन वर्कफ़्लो पूरी तरह से स्वचालित था:

जनरेशन: प्रत्येक मॉडल ने प्रत्येक प्रॉम्प्ट के लिए $n=30$ स्वतंत्र Verilog आउटपुट उत्पन्न किए।
कंपाइलेशन: कोड की सिंटैक्स त्रुटियों की जाँच Questa सिम्युलेटर का उपयोग करके की गई।
सिमुलेशन: सफलतापूर्वक कंपाइल किए गए कोड को टेस्टबेंचेस के साथ एकीकृत किया गया और सिम्युलेट किया गया।
वेरिफिकेशन: आउटपुट्स की तुलना अपेक्षित परिणामों से की गई। त्रुटियों को कंपाइलेशन, इंटीग्रेशन, या सिमुलेशन त्रुटियों के रूप में वर्गीकृत किया गया।
सिंथेसिस: अधिकतम ऑपरेटिंग फ्रीक्वेंसी ( $F_{max}$ ) और एरिया यूटिलाइजेशन (ALMs) को मानव-लिखित रेफरेंस डिज़ाइन्स के विरुद्ध मापने के लिए सही ढंग से कार्य करने वाले डिज़ाइन्स को Intel Cyclone V FPGA पर सिंथेसाइज़ किया गया।

इसके अतिरिक्त, एक सीक्वेंशियल मल्टीप्लायर डिज़ाइन का उपयोग करके बिट-विड्थ स्केलिंग पर एक खोजपूर्ण केस स्टडी संचालित की गई। एल्गोरिदम लॉजिक बनाम केवल ट्रेनिंग पैटर्न को याद करने की मॉडल्स की क्षमता का परीक्षण करने के लिए बिट-विड्थ को मानक मानों (8, 32, 64) और असामान्य, स्पार्स मानों (7, 12, 15, 23, 24, 31, 50, 63) के बीच बदला गया।

प्रमुख परिणाम

प्रॉम्प्टिंग रणनीति का प्रभाव: HLS-C प्रॉम्प्टिंग ने नेचुरल लैंग्वेज प्रॉम्प्टिंग की तुलना में काफी बेहतर प्रदर्शन किया। औसत कार्यात्मक शुद्धता दर 26.9% (NL) से बढ़कर 39.5% (HLS-C) हो गई।
त्रुटि वितरण: HLS-C प्रॉम्प्ट्स ने कंपाइलेशन त्रुटियों (औसतन 33.5% से 24.2% तक) और इंटीग्रेशन त्रुटियों को काफी कम कर दिया। हालांकि, सिमुलेशन त्रुटियां प्राथमिक चुनौती बनी रहीं, जो HLS-C के साथ भी लगभग 35% प्रयासों में मुख्य समस्या थीं, जो यह संकेत देती है कि मॉडल्स अभी भी जटिल हार्डवेयर व्यवहार के साइकिल-एक्यूरेट ट्रांसलेशन में संघर्ष करते हैं।
मॉडल प्रदर्शन: o4-mini और Gemini 2.5 Pro मॉडल्स ने दोनों रणनीतियों में लगातार उच्चतम शुद्धता दर प्राप्त की।
सामान्यीकरण (Generalization): बिट-विड्थ स्केलिंग प्रयोग में, o4-mini और Gemini 2.5 Pro ने मजबूत सामान्यीकरण प्रदर्शित किया, गैर-मानक चौड़ाई (जैसे 7-बिट, 23-बिट) में उच्च शुद्धता (>90%) बनाए रखी, जो सुझाव देता है कि वे केवल ट्रेनिंग डेटा को याद नहीं कर रहे हैं बल्कि अंतर्निहित एल्गोरिदम को समझ रहे हैं।
हार्डवेयर गुणवत्ता: सिंथेसाइज्ड डिज़ाइन्स ने अक्सर मानव-लिखित रेफरेंस डिज़ाइन्स से अधिक $F_{max}$ मान प्राप्त किए। हालांकि, NL प्रॉम्प्ट्स की तुलना में HLS-C प्रॉम्प्ट्स ने कम प्रदर्शन परिवर्तनशीलता वाले डिज़ाइन उत्पन्न किए, लेकिन कभी-कभी बड़े एरिया फुटप्रिंट भी बनाए, जो संभवतः मॉडल्स द्वारा प्रोसीजरल C कंस्ट्रक्ट्स को कठोर हार्डवेयर स्ट्रक्चर में अनुवादित करने के कारण हुआ।

प्रमुख योगदान

प्रॉम्प्ट्स का तुलनात्मक विश्लेषण: अध्ययन यह प्रदर्शित करता है कि संरचित, कोड-केंद्रित इनपुट (HLS-स्टाइल C) प्रदान करना नेचुरल लैंग्वेज विवरणों की तुलना में LLM-जनरेटेड RTL की कार्यात्मक शुद्धता में काफी सुधार करता है।
सामान्यीकरण मूल्यांकन: यह विश्लेषण करता है कि LLMs असामान्य डिज़ाइन पैरामीटर्स को कैसे संभालते हैं, जिससे पता चलता है कि फ्रंटियर मॉडल्स प्रभावी ढंग से एल्गोरिदम लॉजिक को एब्स्ट्रैक्ट कर सकते हैं, जबकि हल्के मॉडल्स मानक पैटर्न से आगे बढ़ने में विफल रहते हैं।
हार्डवेयर गुणवत्ता मूल्यांकन: यह कार्य $F_{max}$ और एरिया के संदर्भ में मानव रेफरेंस के विरुद्ध LLM-जनरेटेड डिज़ाइन्स का गुणवत्ता विश्लेषण प्रदान करता है, जो यह उजागर करता है कि हालांकि LLMs प्रतिस्पर्धी आर्किटेक्चर बना सकते हैं, लेकिन इष्टतम परिणाम प्राप्त करने के लिए उन्हें कई प्रयासों में से मैनुअल चयन की आवश्यकता होती है।

महत्व और दावे
लेखक निष्कर्ष निकालते हैं कि निरंतर सिमुलेशन त्रुटियों और डीबगिंग की उच्च लागत के कारण LLMs अभी तक स्वायत्त रूप से प्रोडक्शन-रेडी RTL कोड उत्पन्न करने में सक्षम नहीं हैं, फिर भी वे हार्डवेयर डेवलपर्स के लिए एक शक्तिशाली सहायक उपकरण (assistive tool) के रूप में प्रतिनिधित्व करते हैं। HLS-C प्रॉम्प्ट्स के साथ बेहतर प्रदर्शन यह सुझाव देता है कि सॉफ्टवेयर सिंटैक्स के प्रति मॉडल्स की परिचितता का लाभ उठाकर हार्डवेयर जनरेशन के अंतर को पाटा जा सकता है। पेपर का तर्क है कि LLMs अनुभवी इंजीनियरों द्वारा समीक्षा और अनुकूलन के लिए ड्राफ्ट इम्प्लीमेंटेशन या "बॉयलरप्लेट" कोड उत्पन्न करने के लिए विशेष रूप से मूल्यवान हैं, और सॉफ्टवेयर इंजीनियरों को परिचित C कंस्ट्रक्ट्स को RTL में मैप करके हार्डवेयर डिज़ाइन में संक्रमण करने में मदद करने के लिए शैक्षिक उपकरण के रूप में भी उपयोगी हैं। अध्ययन इस बात पर जोर देता है कि वर्तमान सीमाएं मानव निरीक्षण की आवश्यकता को अनिवार्य बनाती हैं, विशेष रूप से जटिल सीक्वेंशियल लॉजिक और टाइमिंग-क्रिटिकल डिज़ाइन्स के लिए।

प्रयोग: बातचीत बनाम कोडिंग

परिणाम: रेसिपी की जीत

"अजीब नंबर" परीक्षण: क्या यह याद रख रहा है या समझ रहा है?

कमी: यह अभी भी पूर्ण नहीं है

मुख्य निष्कर्ष

इसी तरह के और पेपर