درون XLS؛ نگاهی به زیرساخت متن‌باز گوگل برای خودکارسازی سخت‌افزار

طراحی سخت‌افزار سفارشی دیگر تنها در انحصار معماران تراشه نیست؛ این حوزه در حال تبدیل شدن به یک مسئله مهندسی نرم‌افزار است. گوگل با معرفی XLS (Accelerated HW Synthesis)، ابزاری را ارائه داده که توصیفات منعطف عملکردی را به کدهای قابل سنتز Verilog و SystemVerilog تبدیل می‌کند و در واقع توسعه مالکیت معنوی سخت‌افزاری (Hardware IP) را شبیه به توسعه نرم‌افزار می‌کند. این پروژه تحت لایسنس Apache 2 منتشر شده است.

ما وارد «عصر تخصصی‌سازی» شده‌ایم که اغلب آن را دوران پایان قانون مور (End of Moore's Law یا EoML) می‌نامند. در این محیط، دیوار سنتی میان مهندسان نرم‌افزار و سخت‌افزار باید فرو بریزد. برای دستیابی به عملکرد بالاتر، تیم‌ها باید روی مستندات و آرتیفکت‌های مشترک همکاری کنند و مدل‌های هزینه یکدیگر را به‌صورت لحظه‌ای درک کنند. XLS به‌عنوان یک SDK طراحی شده تا این فرآیند طراحی مشترک (Co-design) را با استفاده از چرخه‌های ماشین و متدولوژی‌های نرم‌افزاری خودکار کند. هدف این پروژه تبدیل شدن به SDK اصلی دوران پس از قانون مور است تا با تکیه بر اتوماسیون، سرعت کلی فرآیند توسعه را بالا ببرد.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی زیرساخت‌های محاسباتی اشاره کردیم، حذف اصطکاک میان لایه‌های انتزاعی، کلید دستیابی به کارایی است. این رویکرد با تلاش‌های اخیر برای بهینه‌سازی مصرف منابع در مدل‌های عظیم هم‌سو است؛ برای مثال، موتور FreeToken توانسته است مدل‌های بسیار حجیم را روی سخت‌افزارهای محدودتر اجرا کند که نشان‌دهنده اهمیت بهینه‌سازی در لایه‌های پایین‌تر است. به نقل از مستندات پروژه، XLS اجازه می‌دهد یک طراحی به‌صورت نرم‌افزار میزبان یا در یک شبیه‌ساز با سرعت بومی اجرا شود و هم‌زمان خروجی بلوک سخت‌افزاری تولید کند. این زنجیره ابزار تضمین می‌کند که این دو نسخه از نظر عملکردی یکسان باشند و ابزارهایی برای تایید رسمی (Formal Verification) فراهم می‌کند تا صحت طراحی تضمین شود. این قابلیت، توسعه سریع IPهای سخت‌افزاری را ممکن می‌کند که هم‌زمان به‌عنوان نرم‌افزارهای میزبان کارآمد نیز عمل می‌کنند.

معماری فنی

XLS بر پایه یک پشته پیچیده بنا شده که از زبان سطح بالا به سخت‌افزار فیزیکی می‌رسد. این فرآیند با DSLX آغاز می‌شود؛ یک زبان تخصصی دامنه (DSL) با الهام از زبان Rust. برخلاف زبان‌هایی که برای محاسبات فون نویمان طراحی شده‌اند، DSLX یک DSL جریان‌داده (Dataflow) با عبارات تغییرناپذیر (Immutable) است. این زبان از ویژگی‌های خاص سخت‌افزار مانند پهنای بیت‌های دلخواه (Arbitrary Bitwidths) و اشیایی با اندازه کاملاً ثابت پشتیبانی می‌کند و دارای یک گراف فراخوانی کاملاً تحلیل‌پذیر است.

پس از DSLX، زنجیره ابزار مسیر زیر را طی می‌کند:

• تبدیل به IR: زبان DSL به یک نمایش میانی (Intermediate Representation) تبدیل می‌شود که ابزار ir_converter_main این انتقال را مدیریت می‌کند.
• بهینه‌سازی: مجموعه‌ای از گذرها (Passes) روی IR اجرا می‌شوند تا طراحی پیش از زمان‌بندی بهینه شود. این فرآیندها در دایرکتوری passes مدیریت می‌شوند.
• زمان‌بندی (Scheduling): الگوریتم‌ها دقیقاً تعیین می‌کنند که عملیات چه زمانی اجرا شوند، مثلاً تخصیص آن‌ها به مراحل خاصی از خط لوله (Pipeline) در یک طراحی ساعت‌دار.
• تولید کد (Codegen): درخت نحو انتزاعی Verilog (VAST) عملیات نهایی و ماشین‌های حالت متناهی (FSM) را تولید می‌کند. این بخش توسط مولدهایی مانند PipelineGenerator و SequentialGenerator (برای FSMها) مدیریت می‌شود.

قابلیت‌های کلیدی و اجزا

XLS از دو نوع منطق پشتیبانی می‌کند: توابع خط‌لوله‌ای با رابط‌های ورودی/خروجی سیم‌محور خالص (Pure-wire I/O) و فرآیندهای هم‌زمان (Procs). فرآیندها دارای وضعیت (Stateful) هستند و اجازه استقراء روی زمان و رابط‌های ارتباطی کلی‌تر را می‌دهند.

برای تضمین قابلیت اطمینان، پروژه شامل یک Fuzzer چندپردازشی در کل پشته است. این ابزار برنامه‌هایی را در سطح DSL تولید کرده و اجرای آن‌ها را میان مفسر DSL، مفسر IR، JIT و شبیه‌ساز Verilog مقایسه می‌کند. برای اثبات‌های رسمی، XLS نمایش میانی را با استفاده از موتور Z3 به ورودی حل‌کننده SMT تبدیل می‌کند تا بررسی‌های هم‌ارزی منطقی (Logical Equivalence Checks) را بین IR و نت‌لیست نهایی انجام دهد. این دقت در طراحی سخت‌افزار برای کاهش تأخیر در سیستم‌های حساس حیاتی است؛ مشابه آنچه در مقایسه مدل‌های فضای حالت و ترنسفورمرها برای کاهش تأخیر صوتی مشاهده می‌کنیم.

جزئیات ساختار پروژه

پیمایش کدبیس XLS شامل چندین دایرکتوری کلیدی است که با پشته سیستم مطابقت دارد:

• xls/jit: یک JIT مبتنی بر LLVM برای IR که اجرای برنامه‌ها با سرعت بومی را ممکن می‌کند و توان عملیاتی بالاتری نسبت به مفسر استاندارد ارائه می‌دهد.
• xls/interpreter: مفسری برای IR که عمدتاً برای اشکال‌زدایی و اکتشاف استفاده می‌شود.
• xls/delay_model: قابلیت توصیف و درون‌یابی تأخیر داده‌ها برای عملیات IR روی بک‌اندهای هدف. مدل‌ها در xls/estimators/delay_model/models ذخیره شده و از طریق فلگ‌های خط فرمان قابل ارجاع هستند.
• xls/simulation: پوششی برای شبیه‌سازهای Verilog و تولید تست‌بنچ‌ها که در حال حاضر از iverilog استفاده می‌کند، زیرا از ساختارهای تست‌بنچ غیرقابل سنتز پشتیبانی می‌کند.
• xls/netlist: کتابخانه‌هایی برای تجزیه و تحلیل توصیفات سطح نت‌لیست که معمولاً به‌صورت Verilog ساختاری با یک کتابخانه سلول ارائه می‌شوند.
• xls/synthesis: رابطی که جریان‌های سنتز بک‌اند را پوشش می‌دهد و امکان تغییر هدف بین جریان‌های ASIC و FPGA را فراهم می‌کند.
• xls/data_structures: ساختارهای سخت‌افزار-محور مانند BDDها، Union Find و Min Cut که کتابخانه‌های استاندارد را تقویت می‌کنند.
• xls/common: قابلیت‌های پایه که روی کتابخانه‌های استاندارد و نسخه‌های Abseil بنا شده‌اند.
• xls/modules: کتابخانه‌های DSLX برای بلوک‌های ساختمانی سخت‌افزاری خارج از کتابخانه استاندارد جهت استفاده مجدد در طراحی‌های گسترده‌تر.
• xls/examples: محاسبات نمونه که در کل پشته XLS تست و قابل اجرا هستند.
• xls/experimental: آرتیفکت‌های حاصل از اکتشافات تجربی مختلف.
• xls/visualization: ابزارهایی برای بازرسی تعاملی کامپایلر و سیستم، از جمله بصری‌سازی IR.
• dependency_support: فایل‌های پیکربندی که اهداف Bazel را برای وابستگی‌های خارجی بارگذاری و نمایش می‌دهند.
• docs_src: منابع فایل‌های Markdown که از طریق mkdocs به مستندات تبدیل می‌شوند.

استقرار و ابزارها

طبق گزارش گوگل، برای توسعه‌دهندگانی که می‌خواهند سیستم را بدون نصب محلی تست کنند، نوت‌بوک‌های Colab فراهم شده است. «XLS Playground» (bit.ly/xls-playground) اجازه می‌دهد کاربران تبدیل IR، تولید کد Verilog و سنتز را از طریق Yosys و PDKهای باز مانند ASAP7 و SKY130 اجرا کنند. این محیط حتی از Place-and-Route (P&R) از طریق OpenROAD و جمع‌آوری معیارهای PPA (توان/عملکرد/مساحت) پشتیبانی می‌کند. همچنین یک راهنمای سریع «learn XLS in Y minutes» در آدرس bit.ly/learn-xls در دسترس است.

برای بیلد‌های محلی، XLS از سیستم ساخت Bazel استفاده می‌کند. نیازهای منابع در اینجا قابل توجه است: در یک ماشین مجازی ۸ هسته‌ای معمولی، یک بیلد کامل اولیه شامل فرانت‌اند C++ می‌تواند تا ۶ ساعت زمان ببرد. بیلد «فقط DSLX» (بدون فرانت‌اند C++) حدود ۲ ساعت زمان می‌برد.

برای کاهش این زمان، تیم توصیه می‌کند از کش دیسک مشترک با افزودن build --disk_cache و test --disk_cache به فایل .bazelrc استفاده شود (مثلاً در دایرکتوری ~/.bazel_disk_cache/). کاربران هشدار یافته‌اند که Bazel جمع‌آوری زباله‌های (Garbage Collection) این دایرکتوری را خودکار انجام نمی‌دهد و باید دستی پاک شود؛ در غیر این صورت می‌توان از bazel-remote برای مدیریت کش و جمع‌آوری زباله‌ها استفاده کرد.

محیط توسعه

راه‌اندازی محیط در اوبونتو ۲۲.۰۴ (Jammy Jellyfish) نیازمند وابستگی‌های خاصی است. کاربران باید python3-dev ،libtinfo6 و python-is-python3 را نصب کنند تا مسیر /usr/bin/env python به پایتون ۳ اشاره کند و از خطاهای مبهم جلوگیری شود.

برای کسانی که کانتینرها را ترجیح می‌دهند، Dockerfileهای آماده (مانند Dockerfile-ubuntu-22.04) ارائه شده است. توسعه‌دهندگان می‌توانند محیط را با SKIP_TESTS=1 بسازند تا تست‌ها را به‌صورت دستی در کانتینر اجرا کنند. برای مثال، یک توسعه‌دهنده می‌تواند با دستور docker run -it --rm xls-build-docker /bin/bash وارد محیط شده و دستوراتی مانند bazel build --verbose_failures -c opt //xls/jit:jit_channel_queue_test را اجرا کند.

برای دریافت تکمیل‌های clangd دو راه وجود دارد:

1. اجرای اسکریپت xls/dev_tools/make-compilation-db.sh برای ایجاد فایل compile_flags.txt (سریع‌تر اما با دقت کمتر).
2. استفاده از hedronvision/bazel-compile-commands-extractor برای تولید فایل compile_commands.json (راه‌اندازی کندتر اما با فلگ‌های دقیق برای هر هدف). این روش نیازمند اجرای bazel build -c opt //xls/... -k و سپس bazel run //:refresh_compile_commands است.

وضعیت تجربی

باید توجه داشت که XLS در حال حاضر تجربی است و یک محصول رسمی پشتیبانی‌شده از گوگل نیست. تیم توسعه صراحتاً هشدار داده است که کاربران باید منتظر باگ‌ها و «لبه‌های تیز» باشند. به‌دلیل مراحل اولیه توسعه، DSLX مکرراً به‌روزرسانی می‌شود بدون اینکه سازگاری با نسخه‌های قبلی (Backward Compatibility) حفظ شود. بنابراین کاربرانی که در حال ساخت مجموعه‌ای از سخت‌افزارها هستند، باید در فرآیند به‌روزرسانی نسخه‌های کامپایلر محتاط و متفکر باشند.

مشارکت در پروژه از طریق بحث‌های گیت‌هاب و لیست پستی xls-dev تشویق می‌شود. تیم درخواست کرده است که مشارکت‌کنندگان پیش از ارسال Pull Request (PR)، ابتدا یک Issue ایجاد کنند تا هم‌سویی اهداف تضمین شود. اگر یک PR ظرف دو روز کاری پاسخی دریافت نکرد، کاربران تشویق می‌شوند که در Issue مربوطه پیگیری کنند.

این چرخش به سمت طراحی سخت‌افزار به سبک نرم‌افزار، مفروضات بنیادی این حوزه را تغییر می‌دهد. با اجازه دادن به نوشتن سخت‌افزار در زبانی شبیه به Rust و تایید آن از طریق حل‌کننده‌های SMT، مانع ورود برای ایجاد شتاب‌دهنده‌های تخصصی هوش مصنوعی به‌شدت کاهش می‌یابد. این اتوماسیون در طراحی سخت‌افزار، مکمل تحولاتی در مدیریت زیرساخت‌های ابری است؛ همان‌طور که AWS با HyperPod InstantStart مدیریت خوشه‌های GPU را به صورت عامل‌محور و خودکار کرده است. اثر درجه دوم این تحول، چرخه تکرار سریع‌تر برای سیلیکون‌های سفارشی است؛ جایی که فاصله میان یک ایده ریاضی و یک نت‌لیست قابل سنتز از ماه‌ها به روزها کاهش می‌یابد.

برای علاقه‌مندان به مشارکت، این پروژه تحت لایسنس Apache 2 است. توسعه‌دهندگان می‌توانند با بررسی محاسبات نمونه یا راه‌اندازی محیط اوبونتو ۲۲.۰۴ از طریق Dockerfileها شروع کنند. این پروژه شاهد مشارکت مهندسان متعددی از جمله Aidan Kirk، Albert Magyar، Alex Light، Amin Kalantar و بسیاری دیگر بوده است.

در آینده باید منتظر تکامل پشتیبانی از نحو C++ در xlscc باشید. این ابزار که توسط تیمی همکار در گوگل توسعه یافته، IR را به‌عنوان مسیری جایگزین برای DSLX هدف قرار می‌دهد و ممکن است به تیم‌هایی که کدبیس‌های HLS موجود در C++ دارند، اجازه دهد به‌طور بهینه‌تری به XLS IR مهاجرت کنند.

گام بعدی شما

• اگر با زبان Rust آشنا هستید، مستندات DSLX را بررسی کنید تا متوجه شوید چگونه توصیفات نرم‌افزاری به سخت‌افزار تبدیل می‌شوند.
• از XLS Playground برای تست سریع ایده‌های سخت‌افزاری بدون نیاز به نصب Bazel استفاده کنید.
• در صورت قصد مشارکت، ابتدا در گیت‌هاب پروژه Issue ایجاد کنید تا با نقشه راه تیم گوگل هم‌سو شوید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.