چکیده

طراحی تراشه‌های دیجیتال مدرن به دلیل افزایش چشمگیر پیچیدگی پردازنده‌ها و سیستم‌های روی تراشه (SoC)، به فرایندهای دقیق و گسترده‌ای برای شبیه‌سازی و تأیید نیاز دارد. امروزه یک تراشه می‌تواند شامل صدها جزء پیچیده مانند هسته‌های پردازنده، شتاب‌دهنده‌ها و سلسله‌مراتب‌های مختلف حافظه باشد. پیش از ساخت نهایی چنین سیستم‌هایی، مهندسان باید عملکرد، صحت و ویژگی‌های طراحی را بررسی کنند. در این میان، شبیه‌سازی در سطح انتقال ثبات (Register-Transfer-Level یا RTL) یکی از مهم‌ترین ابزارهای چرخه طراحی تراشه است؛ زیرا امکان بررسی دقیق رفتار مدار، اشکال‌زدایی طراحی و ارزیابی ویژگی‌هایی مانند عملکرد، توان و مساحت را فراهم می‌کند. با این حال، افزایش پیچیدگی مدارها باعث شده سرعت شبیه‌سازی RTL به یکی از گلوگاه‌های اصلی طراحی تراشه تبدیل شود.

مسئله اصلی این پایان‌نامه از همین محدودیت آغاز می‌شود. شبیه‌سازهای سریع RTL مانند Verilator، کد سخت‌افزار نوشته‌شده با زبان‌هایی مانند Verilog را به برنامه‌های نرم‌افزاری کارآمد، از جمله C++، تبدیل می‌کنند. اگرچه این روش زمان کامپایل نسبتاً کوتاهی دارد، اجرای آن روی چندین هسته پردازنده به‌خوبی مقیاس‌پذیر نیست. علت مهم این مشکل آن است که شبیه‌سازی RTL ذاتاً از تعداد بسیار زیادی وظیفه کوچک تشکیل می‌شود که وابستگی‌های داده‌ای فراوانی دارند و برای اجرای صحیح به هماهنگی مکرر میان هسته‌ها نیازمندند. در پردازنده‌های چند‌هسته‌ای معمولی، هزینه ارتباط و همگام‌سازی میان هسته‌ها برای چنین وظایف کوچکی بسیار زیاد است و در نتیجه بخش قابل توجهی از مزیت موازی‌سازی از بین می‌رود.

این مشکل در واقع یک تضاد اساسی ایجاد می‌کند: برای دستیابی به موازی‌سازی زیاد، باید کار شبیه‌سازی به وظایف بسیار کوچک تقسیم شود؛ اما سخت‌افزارهای چند‌هسته‌ای متداول برای اجرای کارهای بسیار کوچک، سربار ارتباطی و همگام‌سازی بالایی دارند. بنابراین، شبیه‌سازهای موجود مجبور می‌شوند وظایف کوچک را با یکدیگر ادغام کنند و وظایف بزرگ‌تری بسازند. این کار هزینه ارتباطی را کاهش می‌دهد، اما همزمان میزان موازی‌سازی را نیز کم می‌کند و وابستگی‌های بیشتری را در هر وظیفه ایجاد می‌کند. نتایج ارائه‌شده در پایان‌نامه نشان می‌دهد که حتی زمانی که موازی‌سازی بالقوه زیادی وجود دارد، شبیه‌سازی موازی موجود نمی‌تواند به‌طور مؤثر از آن استفاده کند؛ برای نمونه، بهترین حالت بررسی‌شده برای Verilator روی یک پردازنده ۳۲ هسته‌ای تنها حدود ۳٫۵ برابر سریع‌تر از شبیه‌سازی سریالی بود.

مشکل دوم این است که در هر چرخه شبیه‌سازی، همه بخش‌های مدار الزاماً فعال نیستند. در بسیاری از طراحی‌های دیجیتال، تنها بخش کوچکی از سیگنال‌ها در هر چرخه تغییر می‌کنند. بنابراین اجرای مجدد تمام مدار در هر چرخه باعث انجام حجم زیادی از کارهای بی‌اثر می‌شود. راهکار طبیعی برای این مسئله، «اجرای انتخابی» (Selective Execution) است؛ یعنی تنها وظایفی اجرا شوند که ورودی‌هایشان نسبت به چرخه قبلی تغییر کرده‌اند. با وجود این، اجرای انتخابی نیز به وظایف ریزدانه نیاز دارد، زیرا هرچه وظایف کوچک‌تر باشند، امکان تشخیص دقیق بخش فعال مدار بیشتر خواهد بود. مشکل اینجاست که همین وظایف ریزدانه روی معماری‌های چند‌هسته‌ای معمولی سربار ارتباطی زیادی ایجاد می‌کنند. در نتیجه، دو فرصت مهم برای افزایش سرعت شبیه‌سازی یعنی موازی‌سازی و اجرای انتخابی، در معماری‌های رایج به‌سادگی قابل ترکیب نیستند.

در کنار شبیه‌سازی نرم‌افزاری، روش دیگری که در صنعت برای افزایش سرعت اجرای طراحی‌های دیجیتال استفاده می‌شود، شبیه‌سازی سخت‌افزاری یا امولیشن (Hardware Emulation) است. در این روش، طراحی روی تعداد زیادی FPGA یا پردازنده‌های تخصصی نگاشت می‌شود و می‌تواند با سرعت بسیار بالاتری اجرا شود. با این حال، امولاتورها مشکلات مهمی دارند. کامپایل طراحی‌های بزرگ روی چندین FPGA می‌تواند از چند روز تا چند هفته طول بکشد و سیستم‌های امولیشن نیز بزرگ، پیچیده و پرهزینه هستند. بنابراین، امولیشن بیشتر برای مراحل پایانی طراحی که تغییرات سخت‌افزار کمتر شده است مناسب است، در حالی که شبیه‌سازی نرم‌افزاری به دلیل زمان کامپایل کوتاه، در بخش عمده چرخه طراحی که تغییرات مکرر هستند، کاربرد بیشتری دارد. پایان‌نامه بنابراین تلاش می‌کند سرعت شبیه‌سازی نرم‌افزاری را افزایش دهد، بدون اینکه مزیت زمان کامپایل کوتاه و انعطاف‌پذیری آن از بین برود.

برای حل این مسئله، پایان‌نامه سیستم جدیدی با نام ASH (Accelerator of Simulated Hardware) ارائه می‌کند. ASH یک معماری سخت‌افزاری و کامپایلر RTL است که به‌صورت مشترک برای شتاب‌دهی شبیه‌سازی طراحی شده‌اند. ایده اصلی این سیستم استفاده از دو ویژگی مهم در ماهیت شبیه‌سازی RTL است: نخست، امکان نمایش محاسبات به‌صورت جریان داده (Dataflow) و اجرای وظایف مستقل به شکل موازی؛ و دوم، امکان اجرای تنها قسمت‌هایی از مدار که واقعاً در هر چرخه فعال هستند.

اولین بخش اصلی ASH، معماری DASH (Dataflow ASH) است. DASH شبیه‌سازی RTL را به مجموعه‌ای از وظایف کوچک تقسیم می‌کند که خروجی هر وظیفه می‌تواند ورودی وظایف دیگر باشد. سخت‌افزار به‌جای استفاده از روش‌های متداول برای ارتباط میان هسته‌ها، وظایف را بر اساس آماده‌شدن ورودی‌هایشان مدیریت و اجرا می‌کند. در این معماری، وظیفه زمانی آماده اجرا می‌شود که ورودی‌های مورد نیاز آن دریافت شده باشند. یکی از ویژگی‌های مهم DASH، اجرای جریان داده‌ای اولویت‌بندی‌شده است. وظایف دارای زمان‌مُهر (Timestamp) هستند و سخت‌افزار آن‌ها را با توجه به اولویت اجرا می‌کند. این روش باعث کاهش تعداد داده‌ها و وظایف در حال انتظار و در نتیجه کاهش نیاز به حافظه و ساختارهای پیچیده می‌شود.

DASH علاوه بر سخت‌افزار، یک کامپایلر تخصصی نیز دارد که بر پایه Verilator توسعه داده شده است. این کامپایلر کد RTL را به گراف جریان داده تبدیل می‌کند، گراف را برای آشکار کردن موازی‌سازی بیشتر باز می‌کند، وظایف را میان بخش‌های مختلف سخت‌افزار توزیع می‌کند، آن‌ها را در اندازه مناسب ترکیب می‌کند و برای اجرای آن‌ها زمان‌مُهر تعیین می‌کند. یکی از ایده‌های مهم کامپایلر، استفاده از «گراف جریان داده بازشده» (Unrolled Dataflow Graph) است که وابستگی‌های مربوط به ثبات‌ها را به وابستگی‌های بین چرخه‌ای تبدیل می‌کند. به این ترتیب، اجرای بخش‌هایی از چرخه‌های مختلف می‌تواند با یکدیگر هم‌پوشانی داشته باشد و میزان موازی‌سازی افزایش یابد.

بخش دوم ASH، یعنی SASH (Selective Event-Driven ASH)، قابلیت اجرای انتخابی را به DASH اضافه می‌کند. در SASH، اگر خروجی یک وظیفه نسبت به چرخه قبلی تغییر نکرده باشد، نیازی نیست همان اطلاعات دوباره برای وظیفه بعدی ارسال شود. بنابراین وظایفی که هیچ ورودی مؤثری دریافت نکرده‌اند، اجرا نمی‌شوند. این موضوع باعث می‌شود سیستم به‌جای شبیه‌سازی کل مدار در هر چرخه، تنها بخش فعال مدار را پردازش کند.

اما اجرای انتخابی یک مشکل جدید ایجاد می‌کند: یک وظیفه ممکن است برخی ورودی‌های خود را دریافت کند و برخی دیگر را دریافت نکند. SASH برای حل این مسئله از اجرای حدسی یا گمانه‌زنانه (Speculative Execution) استفاده می‌کند. اگر وظیفه حداقل یک ورودی جدید دریافت کرده باشد، سیستم می‌تواند آن را با استفاده از ورودی‌های جدید و مقادیر قبلی سایر ورودی‌ها اجرا کند. اگر بعداً مشخص شود که یک ورودی جدید و دیررس وجود داشته است، اجرای قبلی لغو شده و وظیفه با اطلاعات صحیح دوباره اجرا می‌شود. این روش امکان ترکیب موازی‌سازی ریزدانه، اجرای انتخابی و مدیریت وابستگی‌های پویا را فراهم می‌کند.

یکی از مهم‌ترین ویژگی‌های پایان‌نامه، ترکیب این دو ایده است. طبق بیان نویسنده، کارهای قبلی یا از جریان داده‌ای در سطح وظیفه استفاده کرده‌اند یا از اجرای حدسی، اما ASH این دو مفهوم را در یک سیستم واحد ترکیب می‌کند. هدف این ترکیب آن است که هم موازی‌سازی گسترده ایجاد شود و هم از اجرای کارهایی که در یک چرخه واقعاً مورد نیاز نیستند جلوگیری شود.

برای ارزیابی سیستم، نویسنده DASH و SASH را روی چهار طراحی بزرگ Verilog شامل هسته‌های CPU، هسته‌های GPU، شتاب‌دهنده‌ها و طراحی‌های پردازشی مختلف آزمایش کرده است. ارزیابی با استفاده از یک شبیه‌ساز جزئیات‌دار انجام شده که مدل چرخه‌ای هسته‌ها، حافظه‌ها، کش‌ها، شبکه روی تراشه و اجزای مختلف ASH را دربرمی‌گیرد. زمان کامپایل نیز همچنان کوتاه باقی می‌ماند و برای طراحی‌های مورد آزمایش حدود ۷٫۲ تا ۱۴۰ ثانیه گزارش شده است.

نتایج ارزیابی نشان می‌دهد که ASH می‌تواند مقیاس‌پذیری شبیه‌سازی RTL را به صدها هسته برساند. در نتایج اصلی، سیستم SASH با ۲۵۶ هسته به‌طور میانگین هندسی حدود ۳۲ برابر سریع‌تر از Verilator روی پردازنده ۳۲ هسته‌ای Zen2 عمل کرده است، در حالی که مساحت آن حدود سه برابر کمتر گزارش شده است. همچنین SASH نسبت به بهترین اجرای موازی خط پایه شبیه‌سازی‌شده حدود ۲۱ برابر سریع‌تر بوده است.

در مقایسه با FPGA نیز هدف پایان‌نامه صرفاً دستیابی به بالاترین سرعت خام نیست، بلکه ایجاد تعادل میان سرعت، زمان کامپایل و انعطاف‌پذیری است. برای نمونه، در آزمایش مربوط به Chronos، SASH در حدود دو دقیقه کامپایل می‌شود، در حالی که اجرای طراحی روی دو FPGA پس از فرایند آماده‌سازی حدود ۱۳ ساعت زمان کامپایل نیاز داشته است. بنابراین، اگرچه امولیشن FPGA در برخی شرایط سرعت اجرای بالاتری دارد، SASH می‌تواند چرخه طراحی و اشکال‌زدایی را بسیار کوتاه‌تر کند.

در نهایت، این پایان‌نامه نشان می‌دهد که مشکل سرعت پایین شبیه‌سازی RTL را نمی‌توان صرفاً با اضافه‌کردن هسته‌های بیشتر به یک پردازنده معمولی حل کرد. ساختار خود شبیه‌سازی به معماری‌ای نیاز دارد که بتواند وظایف بسیار کوچک، وابستگی‌های داده‌ای فراوان و فعالیت انتخابی مدار را به‌صورت مستقیم مدیریت کند. ASH با طراحی همزمان سخت‌افزار و کامپایلر، جریان داده‌ای ریزدانه را با اجرای انتخابی و اجرای حدسی ترکیب می‌کند و به این ترتیب تلاش می‌کند شکاف میان سرعت بالای امولیشن و انعطاف‌پذیری شبیه‌سازی نرم‌افزاری را کاهش دهد. نویسنده در پایان نیز مسیرهایی مانند استفاده از عناصر پردازشی قابل پیکربندی مجدد، نگاشت پویای وظایف برای کاهش عدم‌تعادل بار و گسترش ایده‌های ASH به انواع دیگر شبیه‌سازی و حتی حوزه‌هایی فراتر از شبیه‌سازی را به‌عنوان جهت‌های آینده مطرح می‌کند.

شبیه‌سازی RTL چرا این‌قدر کند است؟ داستان ASH و تلاشی برای شکستن یکی از گلوگاه‌های طراحی تراشه

در طراحی تراشه، یک سؤال ساده می‌تواند ساعت‌ها یا حتی روزها زمان مهندسان را بگیرد: آیا مداری که طراحی کرده‌ایم واقعاً همان‌طور که انتظار داریم کار می‌کند؟

پاسخ این سؤال معمولاً با شبیه‌سازی در سطح انتقال ثبات یا RTL (Register-Transfer Level) به دست می‌آید. اما هرچه تراشه‌ها پیچیده‌تر شده‌اند، خودِ فرایند شبیه‌سازی به یک مشکل جدی تبدیل شده است. عجیب‌تر اینکه گاهی اضافه‌کردن هسته‌های پردازشی بیشتر، آن‌قدر که انتظار داریم شبیه‌سازی را سریع‌تر نمی‌کند.

این پایان‌نامه دقیقاً سراغ همین تناقض می‌رود: چگونه می‌توان شبیه‌سازی RTL را به‌شدت سریع‌تر کرد، بدون اینکه انعطاف‌پذیری و زمان کامپایل کوتاه شبیه‌سازهای نرم‌افزاری از بین برود؟

۱. مشکل اصلی فقط «کمبود قدرت پردازنده» نیست

شبیه‌سازهایی مانند Verilator طراحی RTL را به برنامه‌های نرم‌افزاری کارآمد تبدیل می‌کنند. مشکل زمانی آغاز می‌شود که بخواهیم این کار را روی تعداد زیادی هسته پردازنده به‌صورت موازی اجرا کنیم.

شبیه‌سازی RTL از تعداد بسیار زیادی وظیفه کوچک تشکیل می‌شود. این وظایف به داده‌های یکدیگر وابسته‌اند و مرتباً باید با هم هماهنگ شوند. بنابراین، اگرچه از نظر تئوری امکان موازی‌سازی بسیار زیادی وجود دارد، پردازنده‌های چند‌هسته‌ای معمولی برای مدیریت این حجم از وظایف ریزدانه و ارتباط میان آن‌ها هزینه زیادی پرداخت می‌کنند.

نتیجه جالب است: داشتن هسته‌های بیشتر الزاماً به معنای سرعت بیشتر نیست.

پایان‌نامه نشان می‌دهد که حتی Verilator روی یک پردازنده ۳۲ هسته‌ای نمی‌تواند از موازی‌سازی موجود به‌طور کامل استفاده کند. این یعنی مسئله صرفاً تعداد هسته‌ها نیست؛ بلکه معماری اجرای وظایف نیز اهمیت اساسی دارد.

۲. یک تناقض عجیب: وظایف باید کوچک باشند، اما کوچک‌بودنشان دردسرساز است

برای افزایش موازی‌سازی، باید محاسبات را به وظایف کوچک تقسیم کرد.

هرچه وظایف کوچک‌تر باشند، تعداد بیشتری از آن‌ها می‌توانند همزمان روی هسته‌های مختلف اجرا شوند. اما همین کوچک‌شدن، هزینه ارتباط و هماهنگ‌سازی را افزایش می‌دهد.

در معماری‌های معمولی، پردازنده باید مرتباً وضعیت وظایف و داده‌های موردنیازشان را بررسی و هماهنگ کند. اگر یک وظیفه فقط چند عملیات ساده انجام دهد، ممکن است هزینه هماهنگی تقریباً به اندازه خود محاسبه یا حتی بیشتر باشد.

این همان جایی است که ایده اصلی پایان‌نامه شکل می‌گیرد:

مشکل شبیه‌سازی RTL را نمی‌توان صرفاً با «هسته‌های بیشتر» حل کرد؛ باید شیوه ارتباط و اجرای وظایف نیز تغییر کند.

۳. شاید عجیب‌ترین بخش ماجرا این باشد که بیشتر مدارها در هر چرخه کاری انجام نمی‌دهند

یک مشاهده بسیار مهم در پایان‌نامه این است که در بیشتر طراحی‌های دیجیتال، فقط بخش کوچکی از سیگنال‌ها در هر چرخه تغییر می‌کنند.

پس چرا باید کل مدار را در هر چرخه دوباره شبیه‌سازی کنیم؟

اینجا مفهوم اجرای انتخابی (Selective Execution) وارد می‌شود. ایده ساده است: اگر ورودی‌های یک وظیفه نسبت به اجرای قبلی تغییری نکرده‌اند، اجرای دوباره آن وظیفه احتمالاً بی‌فایده است.

پایان‌نامه نشان می‌دهد که وقتی وظایف به اندازه کافی کوچک باشند، تنها حدود ۲۰ درصد کارها می‌توانند فعال باشند. اما برای استفاده از این فرصت، سیستم باید بتواند همین وظایف کوچک را با هزینه بسیار پایین مدیریت کند.

اینجا دوباره همان مشکل قبلی ظاهر می‌شود: اجرای انتخابی به وظایف کوچک نیاز دارد و وظایف کوچک روی معماری‌های چند‌هسته‌ای معمولی گران تمام می‌شوند.

۴. چرا FPGA همه مشکلات را حل نمی‌کند؟

وقتی شبیه‌سازی نرم‌افزاری کند است، یک گزینه قدرتمند وجود دارد: امولیشن سخت‌افزاری (Hardware Emulation).

در امولیشن، طراحی روی تعداد زیادی FPGA یا پردازنده تخصصی نگاشت می‌شود و می‌تواند با سرعت بسیار بالاتری اجرا شود.

اما این راه‌حل یک هزینه بزرگ دارد: زمان کامپایل.

برای سیستم‌های مبتنی بر FPGA، فرایندهایی مانند پارتیشن‌بندی، مکان‌یابی و مسیریابی طراحی روی چندین FPGA پیچیده است و ممکن است ساعت‌ها، روزها یا حتی هفته‌ها طول بکشد.

در مقابل، شبیه‌ساز نرم‌افزاری بسیار سریع‌تر کامپایل می‌شود و به همین دلیل در بخش عمده چرخه طراحی که تغییرات مرتب اتفاق می‌افتند، انعطاف‌پذیری بیشتری دارد.

جدول مقایسه پایان‌نامه این تفاوت را به‌خوبی نشان می‌دهد: برای یک میلیون چرخه، شبیه‌سازی نرم‌افزاری و SASH تقریباً در چند دقیقه آماده نتیجه هستند، در حالی که پلتفرم FPGA زمان کامپایل بسیار بیشتری نیاز دارد.

بنابراین هدف این نیست که FPGA را شکست بدهیم؛ هدف این است که سرعت شبیه‌سازی نرم‌افزاری را تا حد امکان به قلمرو سخت‌افزار نزدیک کنیم، بدون از دست دادن انعطاف‌پذیری آن.

۵. ASH: وقتی شبیه‌سازی را مثل یک جریان داده ببینیم

راه‌حل پیشنهادی پایان‌نامه ASH (Accelerator of Simulated Hardware) نام دارد.

ایده ASH این است که ساختار طبیعی شبیه‌سازی RTL را به‌عنوان یک جریان داده (Dataflow) در نظر بگیریم.

در این دیدگاه، وظایف زمانی اجرا می‌شوند که ورودی‌های موردنیازشان آماده شده باشد. خروجی یک وظیفه می‌تواند مستقیماً ورودی وظیفه دیگری باشد.

این مدل یک مزیت بزرگ دارد: به‌جای اینکه پردازنده دائماً منتظر هماهنگی مرکزی باشد، خود داده می‌تواند مشخص کند چه کاری باید اجرا شود.

پایان‌نامه برای پیاده‌سازی این ایده، نسخه‌ای از ASH با نام DASH (Dataflow ASH) معرفی می‌کند. DASH سخت‌افزارهایی اضافه می‌کند که ورودی‌ها را جمع‌آوری کرده و پس از آماده‌شدن آن‌ها، وظایف را برای اجرا ارسال می‌کنند.

۶. یک ایده ظریف: وظایف را بر اساس زمان اولویت‌بندی کنیم

DASH فقط از جریان داده استفاده نمی‌کند؛ بلکه وظایف را با توجه به زمان‌مُهر (Timestamp) آن‌ها اولویت‌بندی می‌کند.

این تصمیم در نگاه اول شاید جزئی به نظر برسد، اما اثر مهمی دارد.

در معماری‌های جریان داده، اگر وظایف زیادی همزمان در حالت انتظار قرار بگیرند، نیاز به بافرها و حافظه‌های بزرگی ایجاد می‌شود. اولویت‌بندی بر اساس زمان کمک می‌کند وظایف با نظم مناسب‌تری اجرا شوند و تعداد وظایف و داده‌های در حال انتظار کاهش پیدا کند.

به بیان ساده، DASH فقط نمی‌گوید «هر کاری که آماده شد اجرا کن»؛ بلکه تلاش می‌کند کارهای آماده را به ترتیبی اجرا کند که کل سیستم کمتر گرفتار کارهای معلق شود.

۷. SASH قدم بعدی است: اصلاً کاری را که لازم نیست انجام نده

DASH موازی‌سازی را حل می‌کند، اما هنوز یک سؤال باقی می‌ماند: اگر یک وظیفه هیچ ورودی جدیدی دریافت نکرده، چرا باید اجرا شود؟

اینجا SASH (Selective Event-Driven ASH) وارد می‌شود.

SASH، DASH را با اجرای انتخابی ترکیب می‌کند و فقط وظایفی را اجرا می‌کند که ورودی‌هایشان در چرخه جاری تغییر کرده‌اند.

این ترکیب بسیار مهم است، چون دو ایده‌ای که معمولاً جدا از هم مشکل داشتند، کنار هم قرار می‌گیرند:

جریان داده‌ای → افزایش موازی‌سازی

اجرای انتخابی → حذف کارهای غیرضروری

در واقع SASH تلاش می‌کند همزمان از «بیشتر انجام دادن کارها با هم» و «کمتر انجام دادن کارهای بی‌فایده» استفاده کند.

۸. اما اجرای انتخابی یک مشکل جدید ایجاد می‌کند

فرض کنید یک وظیفه سه ورودی دارد.

در چرخه جدید، ورودی اول تغییر کرده، ورودی دوم تغییر نکرده و ورودی سوم هنوز نرسیده است.

آیا باید منتظر ورودی سوم بمانیم؟

اگر پاسخ مثبت باشد، بخشی از موازی‌سازی از بین می‌رود.

SASH راه دیگری انتخاب می‌کند: اجرای حدسی (Speculative Execution).

وظیفه با ورودی‌های جدید اجرا می‌شود و برای ورودی‌هایی که هنوز نرسیده‌اند، موقتاً مقدار قبلی استفاده می‌شود؛ اگر بعداً مشخص شود که ورودی دیررس تغییر کرده است، اجرای قبلی لغو و وظیفه دوباره اجرا می‌شود.

این ایده شبیه این است که به‌جای منتظر ماندن برای کامل‌شدن همه اطلاعات، با اطلاعات فعلی جلو برویم و فقط اگر حدس اشتباه بود، عقب‌نشینی کنیم.

۹. نکته کلیدی پایان‌نامه: ترکیب سه ایده، نه اختراع یک ایده منفرد

یکی از مهم‌ترین جنبه‌های کار این پایان‌نامه این است که ASH صرفاً یک تکنیک کاملاً جدا از گذشته معرفی نمی‌کند.

نویسنده از مفاهیم شناخته‌شده‌ای مانند جریان داده‌ای و اجرای حدسی استفاده می‌کند، اما آن‌ها را به شکلی جدید برای شبیه‌سازی RTL ترکیب می‌کند.

در پایان‌نامه تأکید می‌شود که کارهای قبلی عمدتاً یا از جریان داده‌ای در سطح وظیفه استفاده کرده‌اند یا از اجرای حدسی؛ در حالی که ASH این دو را در یک سیستم ترکیب می‌کند.

و همین ترکیب است که ایده را جذاب می‌کند: گاهی جهش بزرگ از اختراع یک مفهوم کاملاً جدید نمی‌آید؛ بلکه از قرار دادن چند مفهوم شناخته‌شده در کنار یکدیگر به شیوه‌ای مناسب حاصل می‌شود.

۱۰. نتیجه واقعاً چشمگیر است: صدها هسته

ASH در چهار طراحی بزرگ Verilog شامل هسته‌های CPU، هسته‌های GPU و شتاب‌دهنده‌ها ارزیابی شده است.

نتایج نشان می‌دهند که یک سیستم ۲۵۶ هسته‌ای ASH نسبت به اجرای سریالی Verilator روی یک هسته ساده، به‌طور میانگین هندسی حدود ۱۴۸۵ برابر سریع‌تر است.

مهم‌تر اینکه در مقایسه با Verilator موازی روی یک پردازنده تجاری ۳۲ هسته‌ای، سیستم ۲۵۶ هسته‌ای ASH به‌طور میانگین حدود ۳۲ برابر سریع‌تر بوده و در عین حال حدود سه برابر مساحت کمتر داشته است.

این اعداد نشان می‌دهند که مسئله فقط افزایش تعداد واحدهای پردازشی نیست؛ اگر معماری بتواند ساختار واقعی کار را بهتر درک کند، افزایش منابع پردازشی می‌تواند واقعاً به افزایش سرعت تبدیل شود.

۱۱. مهم‌ترین درس: شبیه‌سازی باید خودش را با ساختار مدار تطبیق دهد

شاید مهم‌ترین نکته این پایان‌نامه فراتر از ASH، DASH یا SASH باشد.

یک شبیه‌ساز سنتی ممکن است تلاش کند کل مدار را به‌صورت منظم و تکراری پردازش کند. اما مدار واقعی همیشه این‌گونه رفتار نمی‌کند. بخش‌های مختلف آن در زمان‌های مختلف فعال می‌شوند و وابستگی‌های داده‌ای متفاوتی دارند.

ASH تلاش می‌کند معماری شبیه‌ساز را به این واقعیت نزدیک کند:

داده آماده شد → وظیفه آماده است.

ورودی تغییر نکرد → وظیفه را اجرا نکن.

اطلاعات کامل نیست → در صورت امکان حدس بزن و جلو برو.

این نگاه، شبیه‌سازی را از یک برنامه صرفاً محاسباتی به سیستمی تبدیل می‌کند که ساختار محاسبات را به‌صورت مستقیم در معماری خود منعکس می‌کند.

۱۲. پایان ماجرا نیست؛ ASH هنوز جای رشد دارد

خود پایان‌نامه نیز ASH را پایان مسیر نمی‌داند.

یکی از مسیرهای آینده، جایگزین‌کردن هسته‌های عمومی با عناصر پردازشی قابل پیکربندی مجدد مانند CGRA است تا عملیات پرتکرار در RTL با سخت‌افزار تخصصی‌تر اجرا شوند.

مسیر دیگر، حل مشکل عدم‌تعادل بار (Load Imbalance) در SASH است؛ زیرا در هر بخش از اجرای شبیه‌سازی ممکن است قسمت‌های متفاوتی از مدار فعال باشند و در نتیجه بعضی هسته‌ها بیشتر از بقیه کار کنند.

همچنین نویسنده معتقد است ترکیب جریان داده‌ای و اجرای انتخابی می‌تواند فراتر از شبیه‌سازی RTL نیز کاربرد داشته باشد؛ برای مثال در انواع دیگر شبیه‌سازی یا حتی بارهای کاری غیرمرتبط با شبیه‌سازی.

جمع‌بندی: آینده شبیه‌سازی، فقط «سریع‌تر» نیست؛ «هوشمندتر» است

داستان ASH در اصل داستان تلاش برای حل یک تناقض است: شبیه‌ساز نرم‌افزاری انعطاف‌پذیر و سریع‌کامپایل است، اما اجرای آن کند است؛ امولیشن سخت‌افزاری بسیار سریع است، اما آماده‌سازی آن زمان‌بر و پرهزینه است.

ASH تلاش می‌کند فاصله میان این دو را کم کند.

با ترکیب جریان داده‌ای ریزدانه، اجرای انتخابی و اجرای حدسی، سیستم به‌جای اینکه کورکورانه همه مدار را در هر چرخه اجرا کند، تلاش می‌کند بفهمد چه چیزی آماده است، چه چیزی تغییر کرده و چه چیزی واقعاً ارزش اجرا دارد.

و شاید سؤال مهمی که از این پژوهش باقی می‌ماند همین باشد:

اگر بتوانیم شبیه‌ساز را طوری طراحی کنیم که دقیقاً مانند خود مدار، فقط زمانی و فقط در جایی کار کند که واقعاً لازم است، سرعت شبیه‌سازی در آینده تا کجا می‌تواند پیش برود؟