شما هم ممکنه مثل پیتر کاولی (@corsix) کد ساده‌ی C خودتون را با GCC کامپایل کنید و خروجی اسمبلی ARM64 را باز کنید و همینطور که دارید کد اسمبلی تولید شده رو میبینید از خودتون بپرسید:
«این دیگه چیه؟ چرا کامپایلر دو بار w4 & w1 رو حساب کرده، بعد هم دو بار w0 & w4 رو تکرار کرده! مگه نمی‌شد یک mov بزنه و خلاص؟»
چیزی که در نگاه اول مثل یک باگ یا تنبلی کامپایلر به نظر می‌رسه، در واقع یکی از بهترین درس‌های بهینه‌سازی CPUهای مدرنه!

قبلش باید ببینیم چرا GCC (و گاهی Clang) همچین کار «عجیبی» می‌کنن و چرا تقریباً همیشه تو این موارد حق با کامپایلره.

کد سی احتمالاً همچین چیزی بوده:

uint32_t lookup(uint32_t index, uint32_t mask, const uint32_t* table) {
    uint32_t idx = index & mask;
    return table[idx];
}

و در نتیجه کد اسمبلی تولید شده توسط GCC همچین چیزیه!

and   w0, w4, w1        // w0 = w4 & w1
and   w2, w4, w1        //! w2 = w4 & w1
and   w0, w0, w4        // w0 = w0 & w4
and   w0, w0, w4        // !
ldr   w0, [x2, w0, uxtw #2]

کدهای تکراری! ولی چرا؟ تو CPUهای مدرن ARM64 (Apple M1/M2/M3/M4، Snapdragon X Elite، Graviton و …) اجرای دوباره‌ی یک دستور ساده‌ی AND تقریباً همیشه از mov سریعتره چون mov وابستگی داده (data dependency) ایجاد می‌کنه و pipeline را متوقف می‌کنه. یعنی وقتی می‌نویسی mov w2, w0،اتفاقی که میفته اینه که CPU باید صبر کنه تا w0 کاملاً آماده بشه، بعد w2 رو پر کنه. اما وقتی دو بار and w2, w4, w1 می‌نویسی، هر دو دستور ورودی یکسان (w4 و w1) داره و هیچ وابستگی‌ای بین‌شون نیست. نکته بعدی اینکه CPUهای out-of-order می‌تونند این دو دستور AND رو همزمان در دو واحد ALU مختلف اجرا کنند و از طرفی مکانیزم Register Renaming باعث می‌شه CPU این دو نتیجه را به‌عنوان دو رجیستر فیزیکی کاملاً جدا ببینه و هزینه‌ی واقعی خیلی خیلی کمه!

جالب اینه که clang خروجی متفاوتی داره و کمی تمیزتره!

and   w0, w1, w2      
and   w0, w0, w1    
ldr   w0, [x3, w0, uxtw #2]

دلیلش اینه که Clang کمی محافظه‌کارتره و بیشتر به «کد تمیز» اهمیت می‌ده، تو بنچمارک‌های واقعی روی M2/M3/M4 معمولاً تفاوت سرعت از ۱٪ کمتره. یعنی GCC با کد «زشت‌تر» گاهی حتی چند صدم درصد سریع‌تره!

پس یادتون نره در بیشتر مواقع «کامپایلر بیشتر از من می‌فهمه»، کد اسمبلی کوتاه‌تر هم نشونه سریعتر بودنش نیست. دفعه‌ی بعدی هم که GCC یا Clang چیزی تولید کرد که در نگاه اول «احمقانه» به نظر رسید، قبل از آه‌کشیدن یه بنچمارک کوچیک بزنین و یه نگاهی به معماری همون CPU بندازید. تو ۹۹٪ مواقع می‌بینین کامپایلر حق داشته. البته چیزهایی که هکرهای ffmpeg دستی بهینه می‌کنن رو هم نمی‌شه نادیده گرفت، ولی اونها قرار نیست به ما ثابت کنن که کامپایلر خنگه و ما ازش باهوش‌تریم. و در نهایت هم یادمون نره که روی آرم، GCC معمولاً یه ذره، خیلی کم اسمبلی بهینه‌تری تولید می‌کنه.


📡openpcb

جف گیرلینگ (معروف به GeerlingGuy) توییت جالبی منتشر کرده و برای اولین بار عکسی از Raspberry Pi Compute Module 0 (CM0) رو نشون داده! ماژولی که در واقع همون Raspberry Pi Zero 2 Wـه، ولی به شکل SoM (System on Module) البته با لبه‌های castellated برای لحیم مستقیم روی PCB.

روی این برد پردازنده RP3A0 به همراه حافظه ۱۶ گیگابایت eMMC دیده می‌شه، و فقط برای بازار چین عرضه شده (به‌خاطر کمبود جهانی حافظه LPDDR2)! این برد برای پروژه‌های صنعتی و embedded که نیاز به حجم تولید بالا و رزیری‌پای دارن و تولیدشون چین‌محوره مناسبه.

خبر خوب اینه که شرکت EDATEC تأیید کرده CM0 رسماً توی سایت Raspberry Pi لیست شده و از ژانویه ۲۰۲۶ محصولات صنعتی مبتنی بر اون در سطح جهانی عرضه می‌شه.



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



📡openpcb

چند وقتیه تو شبکه های اجتماعی مثل x حرف و حدیث‌هایی درباره گجت NanoKVM پخش شده که می‌گن این گجت یه میکروفون مخفی داره و بدون اینکه کاربر بدونه، می‌تونه حریم خصوصی رو تهدید کنه. ولی وقتی می‌ری سراغ مستندات، تاریخچه‌ی ماژول و روند توسعه‌ی خود محصول، داستان یه چیز دیگه‌ست.

گجت NanoKVM یه IP-KVM متن‌بازه که روی ماژول LicheeRV Nano ساخته شده. خود LicheeRV Nano یه ماژول استاندارد RISC-Vـه و از همون اول مثل اکثر بردهای توسعه امکانات پایه مثل MIPI LCD، تاچ، اسپیکر و میکروفون داشته. یعنی این قابلیت بخشی از برد اصلی بوده، نه اینکه NanoKVM بیاد یواشکی چیزی اضافه کنه.

اولین کاربران NanoKVM معمولاً کسایی بودن که قبلاً با LicheeRV Nano به عنوان یه برد لینوکسی کوچیک کار کرده بودن! پس براشون وجود میکروفون چیز جدیدی نبود. اما وقتی محصول بیشتر سر زبون‌ها افتاد و کاربرای جدید اومدن، تازه چشمشون به میکروفون افتاد و از همین‌جا قصه‌ی «میکروفون مخفی» ساخته شد.
ولی آیا اصلا این میکروفون مشکل امنیتی ایجاد می‌کنه؟ خیر! چند دلیل ساده داره: IP-KVM ذاتاً قابلیت صوت دوطرفه داره. حتی اگه روی بورد میکروفون نباشه، اگر KVM توسط یه نفر دیگه کنترل بشه، می‌تونه از میکروفون سیستم مقصد استفاده کنه. پس خود سخت‌افزار NanoKVM موضوع جدیدی ایجاد نمی‌کنه. از طرفی درایور میکروفون ۹ ماهه حذف شده و عملاً غیر فعاله. یعنی حتی اگه میکروفون فیزیکی باشه، صدایی نمی‌تونه بگیره.

ولی چرا میکروفون همچنان تو مدل‌های Cube و Lite باقی موند؟ مدل‌های NanoKVM-Cube و NanoKVM-Lite مستقیم روی LicheeRV-Nano ساخته می‌شن. حذف میکروفون یعنی تغییر BOM، تغییر تولید، تغییر QC، و هزینه‌ی اضافه. تیم توسعه ترجیح داده همون برد رو نگه داره تا قیمت و مدیریت موجودی پیچیده نشه. از نظر تجاری و تولید کاملاً منطقیه.

واقعیت اینه که خیلی از مقاله‌ها و پست‌هایی که پخش شدن، مشکل رو بزرگ‌نمایی کردن. NanoKVM ضعف‌هایی داره، ولی ضعف‌هاش به نت‌ورک و کانفیگ اشتباه کاربرا مربوطه. نه به وجود یه میکروفون خاموش که اساساً درایور هم نداره. مزیت مهم NanoKVM اینه که متن‌بازه! یعنی جامعه‌ی توسعه می‌تونه white-box و black-box تست انجام بده و امنیت رو واقعی بهتر کنه، نه با ترس رسانه‌ای. این داستان «میکروفون مخفی» هم بیشتر نتیجه‌ی سوءتفاهم کاربرای جدید با دانش کم سخت افزاری و هیجان رسانه‌هاست.

📡openpcb

محققای دانشگاه استنفورد با همکاری کارخونه SkyWater Technology و دانشگاه‌های MIT، Penn و CMU موفق شدن اولین چیپ سه‌بعدی یکپارچه (Monolithic 3D) رو توی یه خط تولید تجاری بسازن تا قبل از این همیشه تو آزمایشگاه بوده ولی اینبار تو به صورت تجاری و تولید انبوه بوده.

این تکنولوژی برای حل مشکل گلوگاه معماری von Neumann تو چیپ‌های دوبعدی طراحی شده که توش جابجایی دیتا بین پردازنده و حافظه باعث تاخیر و مصرف انرژی زیاد میشه. راهکار این تیم استفاده از ترانزیستورهای نانولوله‌کربنی (CNFET) روی حافظه‌های RRAM بوده! چون CNFETها رو میشه توی دمای پایین ساخت، امکان لایه‌گذاری مدارات منطقی مستقیماً روی حافظه بدون آسیب زدن به لایه‌های زیرین فراهم شده.

این معماری اجازه میده اتصالات عمودی بین لایه‌ها به شدت متراکم باشن که خروجیش افزایش سرعت پردازش و بهره‌وری انرژی خیلی بالاتر برای بارهای کاری هوش مصنوعیه. نکته کلیدی این دستاورد، اثبات قابلیت تولید این چیپ‌ها با ابزارهای استاندارد صنعتیه که مسیر رو برای تولید انبوه سخت‌افزارهای نسل بعدی AI باز می‌کنه.

خبری اصلی رو می‌تونید اینجا بخونید.

📡openpcb

یه مهندس خوش ذوق به اسم Kevin Yang با پروژه‌ی Commi Board، ادعا می‌کنه که می‌تونه دنیای پروتوتایپینگ تو حوزه امبدد رو تغییر بده, ایده ایشون ساده اما رادیکاله! در نگاه اول، Commi Board شبیه یه اکسسوری MagSafe معمولیه که پشت آیفون می‌چسبه که یه برد‌بورد کوچیک بهت میده. اما نکته اصلی در نحوه ارتباطش با گوشیه.

این برد از USB-C 3.2 استفاده می‌کنه و مستقیم به پردازنده آیفون متصل می‌شه بدون هیچ میکروکنترلر واسطی. این یعنی ما یه اتصال دیتا با سرعت بالا و Latency پایین داریم که اجازه میده اپلیکیشن موبایل، پین‌های فیزیکی روی برد رو تقریباً به صورت Real-time کنترل کنه. عملاً گوشی شما تبدیل میشه به یه پردازنده چند گیگاهرتزی که پایه‌های I/O رو درایو می‌کنه.

این گجت قراره از USB-C 3.2 برای کارهای Critical و BLE برای تسک‌های سبک‌تر استفاده کنه، تغذیه رو مستقیم از باتری گوشی (بدون نیاز به Li-Po جداگانه) تامین کنه و نرم‌افزار کنترلی هم داخل گوشی نصب میشه.

قدرت اصلی Commi Board توی اپلیکیشنشه که نقش IDE، کامپایلر و دیباگر رو بازی می‌کنه. چون پردازش روی CPU موبایل انجام میشه، فیچرهایی داره که روی میکروکنترلرهای معمولی (مثل سری AVR یا حتی STM32های سبک) به این راحتی در دسترس نیست:
مثلاً Real-time Circuit Validation داره که قبل از اینکه مدار رو بسوزونید، اپلیکیشن مسیرهای احتمالی جریان و لاجیک رو چک می‌کنه.
از پرامپت‌های AI برای تست‌های سریع گرفته تا محیط بلوکی و نهایتاً یه محیط کدنویسی کامل برای پیاده‌سازی لاجیک‌های پیچید استفاده می‌کنه و شبیه‌سازی رفتار مدار قبل از اجرای فیزیکی هم داره.

طرفداراش می‌گن برای Rapid Prototyping فوق‌العاده‌ست. تصور کنید می‌خواید رفتار یه سنسور جدید I2C رو چک کنید یا یه لاجیک ساده کنترلی رو تست کنید. به جای باز کردن لپ‌تاپ و ستاپ کردن محیط VS Code و PlatformIO، گوشی رو برمی‌گردونید، سنسور رو روی برد‌بورد می‌زنید و کد رو ران می‌کنید.

به نظر من گجت بامزه‌ایه ولی تو کار حرفه‌ای بعید می‌دونم جایگاهی پیدا کنه. ریسک وصل کردن مستقیم I/O به گوشی ۱۰۰۰ دلاری (بدون ایزولاسیون مطمئن) و محدودیت‌های OS Jitter توی iOS، باعث میشه برای کارهای جدی صنعتی قابل اعتماد نباشه.


اینجا می‌تونید بیشتر در موردش بخونید.

📡openpcb

دولت هنداعلام کرده که بالاخره تونسته اولین ریزپردازنده‌ی ۶۴ بیتی دو هسته‌ای با فرکانس ۱ گیگاهرتز رو که کاملاً داخل خود کشور طراحی شده، رو بسازه. اسم این پردازنده DHRUV64 هستش و از نظر دولت هند یه نقطه‌ی عطف حساب می‌شه، چون برای اولین بار دارن از فاز «ما می‌تونیم» وارد فاز «ما تونستیم» می‌شن.

این پردازنده بخشی از برنامه‌ی Digital India RISC-Vـه! یعنی دقیقاً رفتن سراغ معماری متن‌باز RISC-V تا هم درگیر لایسنس‌های گرون و دست‌وپاگیر ARM نشن هم بتونن زنجیره‌ی طراحی تا تولید رو خودشون کنترل کنن. DHRUV64 یه پردازنده دو هسته‌ایه، ۶۴ بیتی، و برای کاربردهای نسبتاً جدی مثل زیرساخت‌های مخابراتی، 5G، سیستم‌های صنعتی، خودرو و حتی IoT در مقیاس بزرگ طراحی شده.

نکته‌ی مهم‌تر اینه که این چیپ قرار نیست اولین و آخرین نوع خودش باشه. بعد از این، نسل‌های بعدی به اسم Dhanush و Dhanush+ هم در راهن، یعنی عملاً دارن یه خانواده‌ی پردازنده درست می‌کنن، نه یه دمو یا پروژه‌ی دانشگاهی. این حرکت ادامه‌ی همون مسیر پروژه‌های قبلی هند مثل SHAKTI، AJIT، VIKRAM و THEJAS ـه که هر کدوم یه تیکه از پازل استقلال سخت‌افزاری‌شون بوده.

مشخصه هند نمی‌خواد فقط مصرف‌کننده‌ی چیپ باشه. می‌خواد طراحی، مالکیت فکری و اکوسیستم اطرافش رو خودش داشته باشه، مخصوصاً برای جاهایی که امنیت، پایداری و تحریم‌ناپذیری مهمه. برای همین هم دولت با برنامه‌هایی مثل India Semiconductor Mission و Chips to Startup داره مستقیم پول و زیرساخت می‌ریزه توی این فضا.

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


خبر اصلی رو اینجا بخونید.

📡openpcb

بریم برای کالبدشکافی CVE-2025-68260. ماجرا از این قراره که یه فایل مشخص تو Binder کرنل لینوکس سال‌ها با C وجود داشته. یه کد C قدیمی، حوصله‌سربر، محافظه‌کارانه، ولی درست! لاک‌ها شاید کمی طولانی‌تر بودن، ولی قانونش خیلی ساده و سفت و سخت بوده: death_list همیشه زیر یه لاک واحد دستکاری می‌شد، مالکیتش هیچ‌وقت مبهم نمی‌شد، و لیست از کنترل صاحبش خارج نمی‌شد. همین.

تا اینکه یه روز تصمیم گرفته می‌شه همین تیکه کد رو با فلسفه‌ی «Rewrite it in Rust» بازنویسی کنن. نیت روی کاغذ خوبه: لاک کوتاه‌تر، کد تمیزتر، استفاده از Rust تو سطح کرنل، و طبیعتاً یه دور افتخار و کلی بوق.

تو پیاده‌سازی Rust، برای این‌که Borrow Checker راضی بشه و کد «Rusty» به نظر بیاد، تصمیم گرفته می‌شه که محتویات death_list رو موقتاً بکشن بیرون و بریزن تو یه لیست محلی، لاک رو رها کنن، بعد بیرون از لاک روش Iterate کنن.

روی کاغذ؟ عالی. لاک کوتاه‌تر شده.در عمل؟ یه قاعده‌ی همیشگی (Invariant) تاریخی Binder نابود شده.چیزی که تو نسخه‌ی C اصلاً قابل تصور نبوده، نه به‌خاطر امنیت C، بلکه به‌خاطر «ذهنیت کرنلی» که می‌گفت لیست درون‌ساختاری (Intrusive List) یا کاملاً مال لاکه، یا اصلاً وجود نداره. حد وسطی وجود نداشت. ولی تو نسخه‌ی Rust، این Invariant تبدیل می‌شه به یه کامنت قشنگ بالای یه unsafe: «این نود یا تو همین لیسته یا هیچ‌جا نیست.»
در حالی که دیگه درست نیست! نتیجه کاملاً قابل پیش‌بینیه: ایجاد Race Condition واقعی، دستکاری هم‌زمان پوینترهای prev/next، فساد حافظه، کرش کرنل، و در نهایت یه CVE رسمی.

طنز تلخ ماجرا؟ همون فایل تو نسخه‌ی C سال‌ها بدون این داستان‌ها کار کرده بوده. از نظر Performance هم داستان قشنگ نیست. نسخه‌ی Rust اینجا نه‌تنها unsafe داره، بلکه Abstraction ،Indirection ،Refcounting و پیچیدگی هم اضافه کرده. یعنی هم سربار بیشتر، هم Reasoning سخت‌تر. لاک کوتاه‌تر شده، ولی فهم کد سخت‌تر شده! و تو کرنل این دقیقاً خلاف جهته.

مسئله اینه که Rust ابزار خوبیه، ولی وقتی یه کد کرنلی بالغ و Battle-tested رو بدون نیاز واقعی و بدون بازطراحی عمیق مدل هم‌زمانی، صرفاً بازنویسی می‌کنی، احتمال این‌که بدترش کنی خیلی بالاست. مخصوصاً وقتی با Data Structureهای Intrusive و Invariantهای نانوشته سروکار داری.

از طرفی تو کرنل، کد Boring که سال‌ها درست کار کرده، یه داراییه. بازنویسی فقط به این دلیل که «می‌شه با Rust نوشت»، فضیلت نیست! می‌تونه منبع Regression، پیچیدگی و باگ جدید باشه.

این قضیه برای ما تو دنیای امبدد یه زنگ خطر جدی‌تری هم داره. وقتی منابع محدودن و دیوایس قراره سال‌ها تو فیلد بدون دسترسی فیزیکی کار کنه، «پیچیدگی» بزرگ‌ترین دشمنه. تو این سیستم‌ها ما دنبال قطعیت (Determinism) و پیش‌بینی‌پذیری (Predictability) هستیم، نه Abstractionهایی که معلوم نیست اون‌زیر چه سرباری (Overhead) دارن.

اگه قراره Rust جایگزین C بشه، باید بتونه همون سادگی و کارایی Bare-metal رو بده، نه اینکه برای حل مشکل مموری که خودش هم میتونه به بار بیاره، مشکل معماری درست کنه. تو امبدد، کدی که «شاید» Race داشته باشه ولی ۱۰ لایه رپ (Wrap) شده، خیلی ترسناک‌تر از کد C لُختیه که دقیق می‌دونی بیت‌به‌بیتش داره چیکار می‌کنه.

برای جزییات بیشتر اینجا رو بخونید.

📡openpcb

یه تیم تحقیقاتی تو MIT یه ربات پرنده ساخته که سرعت پروازش در حد زنبور عسله و در آینده می‌تونه به درد عملیات جست‌وجو و نجات بخوره.

اندازه این ربات حدود ۴ سانتی‌متره و وزنش هم کمتر از یه گرمه. به‌خاطر همین می‌تونه از جاهای خیلی تنگ رد بشه و مثلاً بعد از زلزله، لابه‌لای آوار بره و اگه آدم زنده‌ای اون زیر باشه، به تیم‌های امداد خبر بده.

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

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

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

این ربات تونسته تو ۱۱ ثانیه ۱۰ تا پشتک هوایی پشت‌سرهم بزنه، اون هم تو شرایط بادی، پشتک یه نمونه‌ی خوب و از سخت‌ترین مانورهاست. اگه یه ربات بتونه پشتک بزنه، یعنی می‌تونه خیلی سریع تغییر جهت بده و این برای مقابله با تندبادهای لحظه‌ای خیلی مهمه.

این تیم حسابی آیرودینامیک بال‌زدن حشرات رو بررسی کردن تا حرکت بال مگس‌ها و زنبورها رو تقلید کنن. نتیجه‌اش رباتیه که ۳۳۰ بار در ثانیه بال می‌زنه تقریباً هم‌رده‌ی زنبور عسل واقعی.


متن خبر رو می‌تونید اینجا بخونید.

📡openpcb

چند روزیه تو اخبار تکنولوژی گفته میشه که چین نمونه اولیه دستگاه لیتوگرافی EUV را ساخته و اون رو کنار محصولات ASML قرار می‌دن! ولی اصل ماجرا اینه که ما با یه کپی مهندسی معکوس شده از دستگاه‌های کامپکت Twinscan NXE هلندی طرف نیستیم، بلکه خروجی "پروژه منهتن" که توی شنژنه بیشتر یه تأسیسات عظیمه شبیه یه کارخونه(چیزی شبیه تصویر بالا که یکی از Synchrotronهای چینیه) تا یه دستگاه اندازه اتوبوس داخل کلین‌روم.

چینی‌ها چون به زنجیره تأمین قطعات اپتیک و لیزرهای خاص ASML دسترسی نداشتن، مسیر فیزیک رو عوض کردن و به جای متد LPP که لیزر به قطرات مذاب شناور قلع شلیک می‌شه، رفتن سراغ تکنولوژی SSMB یا یه سینکروترون (Synchrotron) خیلی بزرگ که بتونن نور ۱۳.۵ نانومتری رو با توان بالا ولی در ابعاد یک کارخونه تولید کنن، در نتیجه الان گلوگاه فیزیک پلاسما و تولید فوتون رو شکستن ولی با ابعاد خیلی خیلی عظیم البته با بازدهی تولید خیلی پایین.

در واقع چیزی که الان داره جور صنعت چیپ چین رو می‌کشه و بهشون خروجی ۵ نانومتری میده، این دستگاه جدید نیست، بلکه فشار آوردن روی لیتوگرافی DUV با دستگاه‌های داخلی مثل سری SSA800 و استفاده از تکنیکهای کثیف مهندسی ولی موثر SAQP (Self-Aligned Quadruple Patterning) هست که توش ویفر رو ۴ بار اکسپوز می‌کنن! این روش سرعت تولید رو پایین میاره و مدیریت Overlay Error توش کابوسه، ولی عملاً تحریم رو دور زده و نشون میده که چین حتی با هزینه بالاتر و پروسه کندتر، به استقلال تو لایه‌های حساس سیلیکون رسیده که نهایتاً سرریز این تکنولوژی باعث میشه تو نودهای پایین‌تر دستشون بازتر بشه.

📡openpcb