با توجه به پست قبلی بد نیست یه مروری کنیم ببینیم چی شد که ساخت یه چیپ اختصاصی حتی برای یک نوجوون ۱۶ساله با هزینه ۱۸۰ دلار ممکن شد!
ماجرا برمیگرده به چند سال پیش، وقتی ایدهی «ارزونکردن Tapeout» تازه جدی شد. ریشهی کار از همکاری Google و فب SkyWater شروع شد. گوگل اومد با اسکایواتر روی یه ایده تاریخی دست گذاشت: فرآیند ساخت تراشهی ۱۳۰ نانومتری رو از حالت محرمانه درآورد و بهشکل یک Open PDK عمومی منتشر کرد. یعنی دیتایی که قبلاً فقط شرکتهای میلیارددلاری بهش دسترسی داشتن، یکباره شد عمومی. این لحظه واقعاً نقطهی عطف بود.
اینطوری راه برای ابزارهای طراحی متنباز باز شد. ابزارهایی مثل OpenLane و Yosys و Magic که قبلاً فقط تو حاشیه بودن، یهدفعه تبدیل شدن به گزینههای واقعی برای طراحی ASIC بدون لایسنسهای چندمیلیوندلاری! یعنی از این لحظه طراحی چیپ از «باشگاه اختصاصی چند شرکت غول» تبدیل شد به چیزی که عملاً روی لپتاپ خونه هم میشد انجامش داد.
منفعتش برای اسکایواتر چی بود؟ خب اسکایواتر یه فب ۱۳۰نانومتری داشت که دیگه برای صنعت موبایل و CPUهای جدید جذاب نبود، اما برای چیپهای دیجیتالی ساده، IoT، مدارهای ترکیبی و هزار مدل کاربرد ساده، هنوز کاملاً بهدردبخور بود. اونها به جای خاک خوردن خط تولید، گفتن: «خب چرا تبدیلش نکنیم به یه پلتفرم Tapeout ارزون؟» اینجاست که ایدهی Multi Project Wafer جرقه خورد: چند نفر طراحیهاشون رو با هم میفرستن و هزینهی یه ویفر بین همه تقسیم میشه. خط قدیمی دوباره فعال شد، ولی اینبار نه برای تولید انبوه، بلکه بهعنوان ماشین Tapeout کمهزینه. و در کنارش، مشتریهای آینده هم تربیت شدن!
همینجا بود که یه سری آدم خوره و خوشفکر دور هم جمع شدن که بگن طراحی ASIC باید «برای همه» قابل انجام باشه. از دل همین فضا پروژهی TinyTapeout بیرون اومد. Matt Venn شد چهرهی جلوی صحنه! آدمی که از روز اول دنبال این بود که ساخت چیپ مثل پروژههای نرمافزاری بشه: متنباز، قابل تجربه، و بدون مانعهای سنگین مالی. گوگل هم ظرفیت شاتل و حمایت مالی گذاشت که دانشگاهیها، هکرها و آدمهای کنجکاو واقعاً بتونن Tapeout کنن، نه فقط حرفش رو بزنن.
این حمایت گوگل هم اصلاً از روی خیرخواهی نبود! بلکه دقیق و بلندمدت بود. گوگل دنبال آیندهایه که سختافزار هم مثل نرمافزار «قابل اتوماسیون و تولید بهوسیله ابزارها» باشه. برای رسیدن به «AI-Silicon Design» باید جامعهی طراح وجود داشته باشه. این پروژه عملاً داشت نسل بعدی مهندسهای سیلیکون رو میساخت.
در نهایت هم هیچ آسیبی به «رازهای بزرگ» وارد نشد. نه فرایند ۵ نانومتر باز شد، نه ۷ نانومتر. چیزی که باز شد، فرآیندی بود که از نظر اقتصادی از اوجش گذشته بود و حالا ارزش جدید پیدا کرد. در عوض چی بهدست اومد؟ نیروی انسانی بیشتر، اکوسیستم متنباز قویتر، بازگشت جریان درآمد به فبی که عملاً از چرخه خارج شده بود، و نفوذ استراتژیک در آیندهی طراحی تراشه.
در اصل جایی که بقیه فقط «یه چیپ ۱۳۰ نانومتری» میدیدن، گوگل و اسکایواتر داشتن نسل طراحهای فردا رو میساختن و راه رو برای «سختافزار مثل نرمافزار» هموار میکردن.
📡openpcb
ماجرا برمیگرده به چند سال پیش، وقتی ایدهی «ارزونکردن Tapeout» تازه جدی شد. ریشهی کار از همکاری Google و فب SkyWater شروع شد. گوگل اومد با اسکایواتر روی یه ایده تاریخی دست گذاشت: فرآیند ساخت تراشهی ۱۳۰ نانومتری رو از حالت محرمانه درآورد و بهشکل یک Open PDK عمومی منتشر کرد. یعنی دیتایی که قبلاً فقط شرکتهای میلیارددلاری بهش دسترسی داشتن، یکباره شد عمومی. این لحظه واقعاً نقطهی عطف بود.
اینطوری راه برای ابزارهای طراحی متنباز باز شد. ابزارهایی مثل OpenLane و Yosys و Magic که قبلاً فقط تو حاشیه بودن، یهدفعه تبدیل شدن به گزینههای واقعی برای طراحی ASIC بدون لایسنسهای چندمیلیوندلاری! یعنی از این لحظه طراحی چیپ از «باشگاه اختصاصی چند شرکت غول» تبدیل شد به چیزی که عملاً روی لپتاپ خونه هم میشد انجامش داد.
منفعتش برای اسکایواتر چی بود؟ خب اسکایواتر یه فب ۱۳۰نانومتری داشت که دیگه برای صنعت موبایل و CPUهای جدید جذاب نبود، اما برای چیپهای دیجیتالی ساده، IoT، مدارهای ترکیبی و هزار مدل کاربرد ساده، هنوز کاملاً بهدردبخور بود. اونها به جای خاک خوردن خط تولید، گفتن: «خب چرا تبدیلش نکنیم به یه پلتفرم Tapeout ارزون؟» اینجاست که ایدهی Multi Project Wafer جرقه خورد: چند نفر طراحیهاشون رو با هم میفرستن و هزینهی یه ویفر بین همه تقسیم میشه. خط قدیمی دوباره فعال شد، ولی اینبار نه برای تولید انبوه، بلکه بهعنوان ماشین Tapeout کمهزینه. و در کنارش، مشتریهای آینده هم تربیت شدن!
همینجا بود که یه سری آدم خوره و خوشفکر دور هم جمع شدن که بگن طراحی ASIC باید «برای همه» قابل انجام باشه. از دل همین فضا پروژهی TinyTapeout بیرون اومد. Matt Venn شد چهرهی جلوی صحنه! آدمی که از روز اول دنبال این بود که ساخت چیپ مثل پروژههای نرمافزاری بشه: متنباز، قابل تجربه، و بدون مانعهای سنگین مالی. گوگل هم ظرفیت شاتل و حمایت مالی گذاشت که دانشگاهیها، هکرها و آدمهای کنجکاو واقعاً بتونن Tapeout کنن، نه فقط حرفش رو بزنن.
این حمایت گوگل هم اصلاً از روی خیرخواهی نبود! بلکه دقیق و بلندمدت بود. گوگل دنبال آیندهایه که سختافزار هم مثل نرمافزار «قابل اتوماسیون و تولید بهوسیله ابزارها» باشه. برای رسیدن به «AI-Silicon Design» باید جامعهی طراح وجود داشته باشه. این پروژه عملاً داشت نسل بعدی مهندسهای سیلیکون رو میساخت.
در نهایت هم هیچ آسیبی به «رازهای بزرگ» وارد نشد. نه فرایند ۵ نانومتر باز شد، نه ۷ نانومتر. چیزی که باز شد، فرآیندی بود که از نظر اقتصادی از اوجش گذشته بود و حالا ارزش جدید پیدا کرد. در عوض چی بهدست اومد؟ نیروی انسانی بیشتر، اکوسیستم متنباز قویتر، بازگشت جریان درآمد به فبی که عملاً از چرخه خارج شده بود، و نفوذ استراتژیک در آیندهی طراحی تراشه.
در اصل جایی که بقیه فقط «یه چیپ ۱۳۰ نانومتری» میدیدن، گوگل و اسکایواتر داشتن نسل طراحهای فردا رو میساختن و راه رو برای «سختافزار مثل نرمافزار» هموار میکردن.
📡openpcb
👍30❤14🔥7
در ادامه دو پست قبلی میخوام توضیح بدم کل روند Tapeout کردن چطور کار میکنه و چطور میتونید چیپ ASIC خودتون رو با زیر ۲۰۰ دلار بسازید.
از اونجایی که TinyTapeout کل زنجیرهی «طراحی > سنتز > P&R > تولید» رو تبدیل کرده به یک خط اتوماتیک و دمدستی. اول شما مدار دیجیتالتون رو طراحی و تست میکنید. این مرحله کاملاً رایگانه. میتونید از Wokwi استفاده کنید که بهشکل شماتیک و منطقی مدار رو میسازید و شبیه سازی میکنید!
اگر هم از اونایی هستید که با HDL راحتید، مستقیم Verilog مینویسید و تستبنچ میزنید. نکتهی کلیدی اینه که TinyTapeout یک Interface ثابت بین طراحی شما و پدهای چیپ داره, یعنی شما فقط «منطق داخلی» رو میسازید، بخش «پدها، باندینگ، IO آپشنها, کلاک و ریست» استاندارد شده و همین باعث میشه طراحی خیلی قابل اعتماد و قابل Tapeout باشه.
وقتی از صحت مدار مطمئن شدید، پروژهتون رو روی GitHub میذارید و فقط یک فایل info.yaml رو پر میکنید. از اینجا به بعد، GitHub Actions وارد بازی میشه و پروسه سنتز منطق با Yosys، Place & Route با OpenLane، و در نهایت تولید فایل GDSII. GDS همون نقشهی واقعی سیمکشی لایههای فلز و ترانزیستورهای پلی/دیفیوژن هست اتفاق میافته و مستقیم میره فب. این مرحله اتوماتیکه یعنی شما دقیقاً دارید از همون پایپلاین ابزارهای اپنسورس صنعتی استفاده میکنید! بدون لایسنسهای میلیون دلاری Cadence و Synopsys.
هزینه فقط وقتی پرداخت میشه که تصمیم میگیرید طرحتون رو روی شاتل Tapeout واقعی بفرستید. همونطور که قبلا گفتم TinyTapeout از Multi-Project Wafer استفاده میکنه یعنی چند ده طرح با هم روی یک ویفر ساخته میشن و هزینه بین همه تقسیم میشه. همین باعث میشه قیمت Tapeout بیاد روی حدود ۱۸۵ یورو.
وقتی چیپ تولید شد، براتون روی یک هدر برد دمو مونتاژ شده ارسال میشه. این برد شامل IOهای استاندارد، 7-Segment، هدرهای توسعه، و یک Raspberry Pi Pico بهعنوان «درایور + محیط تست» هست. با MicroPython یا حتی UART ساده میتونید ورودی بدید، خروجی بخونید، و رفتار چیپتون رو ببینید و وریفای کنید. این همون لحظهایه که پروژه از یک شبیهسازی دیجیتال تبدیل میشه به یک چیپ واقعی روی میز! اون لحظه، لحظهی «این دیگه شوخی نیست، این دیگه واقعاً چیپه» هستش.
اگر کسی بخواد عمیقتر بره سمت طراحی جدیتر، منابع درجهیک و کاملاً رایگانی در دسترس هست که تا همین چند سال پیش عملاً غیرممکن بود بهشون دسترسی داشته باشید. مثلاً کورس طراحی مدار آنالوگ مبتنی بر جریان باز و معماری آزاد از Prof. Pretl در JKU که طراحی آنالوگ رو از سطح Device تا Tapeout آموزش میده، یا برنامهی SSCS-Chipathon تحت هدایت Prof. Mourmann که عملاً یک بوتکمپ Tapeout محور برای عمومه!
از اون طرف، گروه Prof. Frank Gürkaynak در ETH که یکی از فعالترین تیمها در RISC-V و طراحی بازه، پلتفرمها و هستههایی مثل croc رو منتشر کرده که بسیار جذابه. در نهایت اگر دنبال جامعهای هستید که بیشتر با این مبحث آشنا بشید، جامعهی طراحان مدار باز در اینجا رو دنبال کنید.
و نکتهی آخر و البته مهم:
به لطف یکی از خوانندههای کانال، پنج کوپن TinyTapeout برای شاتلهای بعدی موجوده. یعنی اگر طرحتون به مرحلهای رسیده که تست سیمولیشن و تست منطقی پشتسر گذاشته و واقعاً قصد Tapeout دارید، پیغام بدید تا یکی از کوپنها در اختیارتون قرار بگیره.
📡openpcb
از اونجایی که TinyTapeout کل زنجیرهی «طراحی > سنتز > P&R > تولید» رو تبدیل کرده به یک خط اتوماتیک و دمدستی. اول شما مدار دیجیتالتون رو طراحی و تست میکنید. این مرحله کاملاً رایگانه. میتونید از Wokwi استفاده کنید که بهشکل شماتیک و منطقی مدار رو میسازید و شبیه سازی میکنید!
اگر هم از اونایی هستید که با HDL راحتید، مستقیم Verilog مینویسید و تستبنچ میزنید. نکتهی کلیدی اینه که TinyTapeout یک Interface ثابت بین طراحی شما و پدهای چیپ داره, یعنی شما فقط «منطق داخلی» رو میسازید، بخش «پدها، باندینگ، IO آپشنها, کلاک و ریست» استاندارد شده و همین باعث میشه طراحی خیلی قابل اعتماد و قابل Tapeout باشه.
وقتی از صحت مدار مطمئن شدید، پروژهتون رو روی GitHub میذارید و فقط یک فایل info.yaml رو پر میکنید. از اینجا به بعد، GitHub Actions وارد بازی میشه و پروسه سنتز منطق با Yosys، Place & Route با OpenLane، و در نهایت تولید فایل GDSII. GDS همون نقشهی واقعی سیمکشی لایههای فلز و ترانزیستورهای پلی/دیفیوژن هست اتفاق میافته و مستقیم میره فب. این مرحله اتوماتیکه یعنی شما دقیقاً دارید از همون پایپلاین ابزارهای اپنسورس صنعتی استفاده میکنید! بدون لایسنسهای میلیون دلاری Cadence و Synopsys.
هزینه فقط وقتی پرداخت میشه که تصمیم میگیرید طرحتون رو روی شاتل Tapeout واقعی بفرستید. همونطور که قبلا گفتم TinyTapeout از Multi-Project Wafer استفاده میکنه یعنی چند ده طرح با هم روی یک ویفر ساخته میشن و هزینه بین همه تقسیم میشه. همین باعث میشه قیمت Tapeout بیاد روی حدود ۱۸۵ یورو.
وقتی چیپ تولید شد، براتون روی یک هدر برد دمو مونتاژ شده ارسال میشه. این برد شامل IOهای استاندارد، 7-Segment، هدرهای توسعه، و یک Raspberry Pi Pico بهعنوان «درایور + محیط تست» هست. با MicroPython یا حتی UART ساده میتونید ورودی بدید، خروجی بخونید، و رفتار چیپتون رو ببینید و وریفای کنید. این همون لحظهایه که پروژه از یک شبیهسازی دیجیتال تبدیل میشه به یک چیپ واقعی روی میز! اون لحظه، لحظهی «این دیگه شوخی نیست، این دیگه واقعاً چیپه» هستش.
اگر کسی بخواد عمیقتر بره سمت طراحی جدیتر، منابع درجهیک و کاملاً رایگانی در دسترس هست که تا همین چند سال پیش عملاً غیرممکن بود بهشون دسترسی داشته باشید. مثلاً کورس طراحی مدار آنالوگ مبتنی بر جریان باز و معماری آزاد از Prof. Pretl در JKU که طراحی آنالوگ رو از سطح Device تا Tapeout آموزش میده، یا برنامهی SSCS-Chipathon تحت هدایت Prof. Mourmann که عملاً یک بوتکمپ Tapeout محور برای عمومه!
از اون طرف، گروه Prof. Frank Gürkaynak در ETH که یکی از فعالترین تیمها در RISC-V و طراحی بازه، پلتفرمها و هستههایی مثل croc رو منتشر کرده که بسیار جذابه. در نهایت اگر دنبال جامعهای هستید که بیشتر با این مبحث آشنا بشید، جامعهی طراحان مدار باز در اینجا رو دنبال کنید.
و نکتهی آخر و البته مهم:
به لطف یکی از خوانندههای کانال، پنج کوپن TinyTapeout برای شاتلهای بعدی موجوده. یعنی اگر طرحتون به مرحلهای رسیده که تست سیمولیشن و تست منطقی پشتسر گذاشته و واقعاً قصد Tapeout دارید، پیغام بدید تا یکی از کوپنها در اختیارتون قرار بگیره.
📡openpcb
1❤33👍11😍3
شاید براتون جالب باشه بدونید اولین میکروپروسسور دنیا یعنی Intel 4004 کاملا با دست طراحی و ساخته شد.
اون موقع هنوز خبری از CAD و نرمافزارهای مدرن امروزی نبود. Bob Noyce و تیمش از روشی به اسم Rubylith استفاده میکردن! یه ورق قرمز که ماسک لیتوگرافی رو روی اون به صورت دستی میبریدن.
یعنی مسیر ترانزیستورها، گیتها، لایهها… همش واقعاً با کاتر و خطکش. فکر کنید مدار چند هزار ترانزیستوری رو مثل معرقکاری تیکهتیکه کنار هم بذاری. نه Undo، نه Grid، نه DRC/ ERC… فقط چشم، دست، دقت و صبر.
همین که اینا تونستن در اون شرایط اولین میکروپروسسور تاریخ رو بسازن و جواب بده، خودش یه شاهکار واقعیه. گاهی تکنولوژی امروز رو میبینیم و فراموش میکنیم که ریشهاش رو یه مشت آدم با دست خالی شروع کردن. این بهنظرم واقعاً خفنه.
📡openpcb
اون موقع هنوز خبری از CAD و نرمافزارهای مدرن امروزی نبود. Bob Noyce و تیمش از روشی به اسم Rubylith استفاده میکردن! یه ورق قرمز که ماسک لیتوگرافی رو روی اون به صورت دستی میبریدن.
یعنی مسیر ترانزیستورها، گیتها، لایهها… همش واقعاً با کاتر و خطکش. فکر کنید مدار چند هزار ترانزیستوری رو مثل معرقکاری تیکهتیکه کنار هم بذاری. نه Undo، نه Grid، نه DRC/ ERC… فقط چشم، دست، دقت و صبر.
همین که اینا تونستن در اون شرایط اولین میکروپروسسور تاریخ رو بسازن و جواب بده، خودش یه شاهکار واقعیه. گاهی تکنولوژی امروز رو میبینیم و فراموش میکنیم که ریشهاش رو یه مشت آدم با دست خالی شروع کردن. این بهنظرم واقعاً خفنه.
📡openpcb
1❤83🔥19😍4
طبق گفته FFmpeg پچ جدید باعث شده یه تابع مهم تو پردازش ویدیو ۳.۴۶ برابر سریعتر بشه. ماجرا اینه که یکی از کانتریبیوترها به اسم mkver اومده تابع add_8x8basis_sse3 رو که قبلاً با C نوشته شده بود رو کاملا با اسمبلی x86 بازنویسی کرده و خروجی هم شده همین جهش سرعت جدی.
دلیلش اینه که کامپایلرهای GCC و Clang وقتی با فلگ O3 کد رو کامپایل میکنند، معمولاً یه سری حلقه هایی که اصلاً قرار نیست زیاد اجرا بشن رو باز میکنن و کد رو حجیمتر میکنن. اینجا هم اون فانکشن رو از ۱۷۶ بایت رسونده به ۱۴۰۶ بایت! تو این مدل پردازشها، چون دستورهای خاص و عجیبغریبی مثل pmulhrsw وجود داره، کامپایلر همیشه انتخابهای درستی نمیکنه. دولوپرهای FFmpeg هم میگن: «باشه، خودمون درستش میکنیم.» نکته مهم اینه که لزوماً کد C مشکل نداره! این رفتار کامپایلر تو مرحله بهینهسازیه که گاهی خودش دردسر درست میکنه.
این اولینبار نیست FFmpeg از اسمبلی برای گرفتن نهایت قدرت سختافزار استفاده میکنه واین همون بحث معروف چند وقت پیشه که چرا پلیر dav1d که چندتا آدم معمولی ساختنش، بعضی جاها از libgav1 گوگل بهتره. جواب همون همیشگیه: وقتی دقیق میدونی چی میخوای و خودت دستی کد اسمبلی رو مینویسی، خروجی معمولاً از نسخهی تولیدشده توسط کامپایلر بهتره.
یه سوال هم که همیشه مطرح میشه اینه که «چرا این مشکلات رو به سازندههای کامپایلر گزارش نمیکنن؟» گزارش میدن، ولی تا نسخه جدید کامپایلر بیاد مدتها طول میکشه. یعنی عملاً بهترین کار اینه که خودشون همزمان دست به آچار باشن و مشکل رو دور بزنن.
برای همین پروژههایی مثل FFmpeg اینقدر ارزشمندن. از یه طرف همیشه تو بهینهترین حالت ممکنه، از یه طرف دیگه همین مواردی که پیدا میکنن عملاً به کل کامیونیتی C و کامپایلرها سود میرسونه و باعث میشه ابزارهایی که همه استفاده میکنن، کمکم بهتر بشن.
📺Source
📡openpcb
دلیلش اینه که کامپایلرهای GCC و Clang وقتی با فلگ O3 کد رو کامپایل میکنند، معمولاً یه سری حلقه هایی که اصلاً قرار نیست زیاد اجرا بشن رو باز میکنن و کد رو حجیمتر میکنن. اینجا هم اون فانکشن رو از ۱۷۶ بایت رسونده به ۱۴۰۶ بایت! تو این مدل پردازشها، چون دستورهای خاص و عجیبغریبی مثل pmulhrsw وجود داره، کامپایلر همیشه انتخابهای درستی نمیکنه. دولوپرهای FFmpeg هم میگن: «باشه، خودمون درستش میکنیم.» نکته مهم اینه که لزوماً کد C مشکل نداره! این رفتار کامپایلر تو مرحله بهینهسازیه که گاهی خودش دردسر درست میکنه.
این اولینبار نیست FFmpeg از اسمبلی برای گرفتن نهایت قدرت سختافزار استفاده میکنه واین همون بحث معروف چند وقت پیشه که چرا پلیر dav1d که چندتا آدم معمولی ساختنش، بعضی جاها از libgav1 گوگل بهتره. جواب همون همیشگیه: وقتی دقیق میدونی چی میخوای و خودت دستی کد اسمبلی رو مینویسی، خروجی معمولاً از نسخهی تولیدشده توسط کامپایلر بهتره.
یه سوال هم که همیشه مطرح میشه اینه که «چرا این مشکلات رو به سازندههای کامپایلر گزارش نمیکنن؟» گزارش میدن، ولی تا نسخه جدید کامپایلر بیاد مدتها طول میکشه. یعنی عملاً بهترین کار اینه که خودشون همزمان دست به آچار باشن و مشکل رو دور بزنن.
برای همین پروژههایی مثل FFmpeg اینقدر ارزشمندن. از یه طرف همیشه تو بهینهترین حالت ممکنه، از یه طرف دیگه همین مواردی که پیدا میکنن عملاً به کل کامیونیتی C و کامپایلرها سود میرسونه و باعث میشه ابزارهایی که همه استفاده میکنن، کمکم بهتر بشن.
📺Source
📡openpcb
2❤80👍12🙏2
بعد از ادعای بزرگ بنیاد رزبری در مورد غیر قابل هک بودن میکروکنترلر RP2350 و فراخوان به هک و تعیین کردن جایزه برای کسی که بتونه code امضا نشده رو روی میکرو اجرا کنه، چند تیم مستقل امنیتی موفق شدن حداقل پنج روش اجرایی رو پیدا کنن که عملاً تمام لایههای دفاعی سختافزاری و نرمافزاری این چیپ رو دور میزنه، این حملات نشون دهنده شکست کامل مکانیزمهای Secure Boot و حتی استخراج فیزیکی کلیدها از سیلیکون بود.
اولین حفرهای امنیتی که پیدا شد مربوط به (State Machine)سختافزاری بود که مسئول خوندن اطلاعات حیاتی از حافظه OTP موقع بوت شدنه! محققان متوجه شدن که با یه گلیچ ولتاژ دقیق روی پین تغذیه USB_OTP_VDD در بازه زمانی ۲۴۵ تا ۲۷۵ میکروثانیه بعد از استارت، میشه کاری کرد که سیستم به جای دادههای واقعی، مقادیر "Guard Read" (که اتفاقاً 0x333333 هستن) رو بخونه و این باعث میشه چیپ اشتباهاً دیباگ رو باز کنه و با معماری RISC-V بالا بیاد که هیچکدوم از تنظیمات امنیتی روش اعمال نشده.
روش دوم حمله به بوتلودر USB بود که توی فضای Non-Secure اجرا میشه! اونجا یه تابع reboot هست که با دو تا دستور اسمبلی چک میکنه کسی درخواست (Vector Boot) نکرده باشه، ولی با (Crowbar Glitching) و اسکیپ کردن یکی از این دستورات، تونستن سیستم رو گول بزنن تا کد امضا نشده رو اجرا کنه و جالب اینجاست که حتی آشکارسازهای گلیچ و (Random Delays) هم نتونستن جلوی این حمله رو بگیرن.
قشنگترین حمله وقتی بود که پای لیزر وسط اومد و با یه ستاپ لیزری خونگی زیر ۸۰۰ دلار، پروسه تایید امضا رو هدف گرفتن! تکنیک اینجا یه جور TOCTOU بود که فرمور سالم رو برای تایید امضا میفرستادن اما با استفاده از لیزر پوینتر حافظه رو تغییر میدادن تا موقع اجرا، کد مخرب از یه آدرس دیگه لود بشه.
حمله چهارم هم روی مکانیزم قفل نرمافزاری OTP سوار شد، جایی که بوتلودر سعی میکنه دسترسیها رو ببنده و این کار رو دو بار چک میکنه، ولی با ایجاد "دو تا گلیچ" الکترومغناطیسی (EMFI) پشت سر هم روی دستورات شیفت بیت، تونستن کاری کنن که قفل اعمال نشه و کلیدها از طریق USB قابل خوندن بشن.
نهایتاً تیر خلاص استخراج فیزیکی بود! با اینکه سلولهای آنتیفیوز ۴۰ نانومتری خیلی کوچیکن، با استفاده از تکنیک کنتراست ولتاژ غیرفعال (PVC) زیر میکروسکوپ FIB، تونستن مستقیماً وضعیت ۰ یا ۱ بودن بیتها رو از روی سیلیکون ببینن چون فیوزهای سوخته بار الکتریکی رو تخلیه میکردن و روشنتر دیده میشدن.
رزبریپای همه این موارد رو تایید کرد و برای بعضیهاش Errata داد، ولی نکته ترسناک اینه که حملاتی مثل OTP PSM یا لیزر نیاز به تغییر سیلیکون دارن و با آپدیت نرمافزاری درست نمیشن، که نشون میده پیچیدگی زیاد بوتلودر و اتکا به سختافزاری که قبل از اجرای کد امنیتی گلیچ میخوره (Pre-boot attacks)، میتونه کل معماری امنیتی رو به باد بده.
نکته قابل توجه ماجرا اینه که حتی شرکتهایی مثل رزبری که اسمشون با «مهندسی تمیز» و «قابل اعتماد بودن» گره خورده و ادعاهای بزرگی در مورد امن بودن دارن، ممکنه همینقدر قاطع تو پیاده سازی ساز و کارهای امنیتی شکست بخورن.
اگه به جزییات این ماجرا علاقه داشتید میتونید تو این مقاله در موردش بخونید.
📡openpcb
اولین حفرهای امنیتی که پیدا شد مربوط به (State Machine)سختافزاری بود که مسئول خوندن اطلاعات حیاتی از حافظه OTP موقع بوت شدنه! محققان متوجه شدن که با یه گلیچ ولتاژ دقیق روی پین تغذیه USB_OTP_VDD در بازه زمانی ۲۴۵ تا ۲۷۵ میکروثانیه بعد از استارت، میشه کاری کرد که سیستم به جای دادههای واقعی، مقادیر "Guard Read" (که اتفاقاً 0x333333 هستن) رو بخونه و این باعث میشه چیپ اشتباهاً دیباگ رو باز کنه و با معماری RISC-V بالا بیاد که هیچکدوم از تنظیمات امنیتی روش اعمال نشده.
روش دوم حمله به بوتلودر USB بود که توی فضای Non-Secure اجرا میشه! اونجا یه تابع reboot هست که با دو تا دستور اسمبلی چک میکنه کسی درخواست (Vector Boot) نکرده باشه، ولی با (Crowbar Glitching) و اسکیپ کردن یکی از این دستورات، تونستن سیستم رو گول بزنن تا کد امضا نشده رو اجرا کنه و جالب اینجاست که حتی آشکارسازهای گلیچ و (Random Delays) هم نتونستن جلوی این حمله رو بگیرن.
قشنگترین حمله وقتی بود که پای لیزر وسط اومد و با یه ستاپ لیزری خونگی زیر ۸۰۰ دلار، پروسه تایید امضا رو هدف گرفتن! تکنیک اینجا یه جور TOCTOU بود که فرمور سالم رو برای تایید امضا میفرستادن اما با استفاده از لیزر پوینتر حافظه رو تغییر میدادن تا موقع اجرا، کد مخرب از یه آدرس دیگه لود بشه.
حمله چهارم هم روی مکانیزم قفل نرمافزاری OTP سوار شد، جایی که بوتلودر سعی میکنه دسترسیها رو ببنده و این کار رو دو بار چک میکنه، ولی با ایجاد "دو تا گلیچ" الکترومغناطیسی (EMFI) پشت سر هم روی دستورات شیفت بیت، تونستن کاری کنن که قفل اعمال نشه و کلیدها از طریق USB قابل خوندن بشن.
نهایتاً تیر خلاص استخراج فیزیکی بود! با اینکه سلولهای آنتیفیوز ۴۰ نانومتری خیلی کوچیکن، با استفاده از تکنیک کنتراست ولتاژ غیرفعال (PVC) زیر میکروسکوپ FIB، تونستن مستقیماً وضعیت ۰ یا ۱ بودن بیتها رو از روی سیلیکون ببینن چون فیوزهای سوخته بار الکتریکی رو تخلیه میکردن و روشنتر دیده میشدن.
رزبریپای همه این موارد رو تایید کرد و برای بعضیهاش Errata داد، ولی نکته ترسناک اینه که حملاتی مثل OTP PSM یا لیزر نیاز به تغییر سیلیکون دارن و با آپدیت نرمافزاری درست نمیشن، که نشون میده پیچیدگی زیاد بوتلودر و اتکا به سختافزاری که قبل از اجرای کد امنیتی گلیچ میخوره (Pre-boot attacks)، میتونه کل معماری امنیتی رو به باد بده.
نکته قابل توجه ماجرا اینه که حتی شرکتهایی مثل رزبری که اسمشون با «مهندسی تمیز» و «قابل اعتماد بودن» گره خورده و ادعاهای بزرگی در مورد امن بودن دارن، ممکنه همینقدر قاطع تو پیاده سازی ساز و کارهای امنیتی شکست بخورن.
اگه به جزییات این ماجرا علاقه داشتید میتونید تو این مقاله در موردش بخونید.
📡openpcb
2👌87😐10😢1
اگه یه نگاهی به ارزش کل صنعت بازار نیمههادی بندازیم, نکته عجیب این دیتا تمرکز وحشتناک ۳۷ درصدی این صنعت ۱۲ تریلیون دلاریه که دست انویدیاست این نشون میده بازار الان عملاً فقط داره روی "هوش مصنوعی" قیمتگذاری میکنه و نه خودِ سیلیکون به معنای سنتی.
یه پارادوکس جالب مهندسی هم اینجاست که آمریکا با ۷ تریلیون دلار سهم بازار، قدرت بلامنازع به نظر میاد، اما اکثر این غولها (انویدیا، برادکام، AMD) مدل Fabless دارن، یعنی عملاً هیچ چیپی نمیسازن و برای فیزیکِ کار کاملاً وابسته به TSMC تایوان هستن که این یعنی گلوگاه واقعی سختافزار دنیا هنوز توی آسیای شرقیه.
اروپا هم عملاً تبدیل شده به یه "تکخال" به اسم ASML! یعنی اگه لیتوگرافی EUV هلند رو از معادله حذف کنی، اروپا با شرکتهایی مثل ST و Infineon و NXP که بیشتر توی حوزه امبدد، خودرو و پاور کار میکنن.
نکته عجیب بعدی، غیبت شرکتهای مهمی مثل Nordic Semiconductor و Silicon Labs تو این دیتاست! اونم در حالی که چندتا شرکت نسبتا گمنام اسرائیلی تو لیست دیده میشن.
📡openpcb
یه پارادوکس جالب مهندسی هم اینجاست که آمریکا با ۷ تریلیون دلار سهم بازار، قدرت بلامنازع به نظر میاد، اما اکثر این غولها (انویدیا، برادکام، AMD) مدل Fabless دارن، یعنی عملاً هیچ چیپی نمیسازن و برای فیزیکِ کار کاملاً وابسته به TSMC تایوان هستن که این یعنی گلوگاه واقعی سختافزار دنیا هنوز توی آسیای شرقیه.
اروپا هم عملاً تبدیل شده به یه "تکخال" به اسم ASML! یعنی اگه لیتوگرافی EUV هلند رو از معادله حذف کنی، اروپا با شرکتهایی مثل ST و Infineon و NXP که بیشتر توی حوزه امبدد، خودرو و پاور کار میکنن.
نکته عجیب بعدی، غیبت شرکتهای مهمی مثل Nordic Semiconductor و Silicon Labs تو این دیتاست! اونم در حالی که چندتا شرکت نسبتا گمنام اسرائیلی تو لیست دیده میشن.
📡openpcb
👍33⚡10🤔5
شما هم ممکنه مثل پیتر کاولی (@corsix) کد سادهی C خودتون را با GCC کامپایل کنید و خروجی اسمبلی ARM64 را باز کنید و همینطور که دارید کد اسمبلی تولید شده رو میبینید از خودتون بپرسید:
«این دیگه چیه؟ چرا کامپایلر دو بار w4 & w1 رو حساب کرده، بعد هم دو بار w0 & w4 رو تکرار کرده! مگه نمیشد یک mov بزنه و خلاص؟»
چیزی که در نگاه اول مثل یک باگ یا تنبلی کامپایلر به نظر میرسه، در واقع یکی از بهترین درسهای بهینهسازی CPUهای مدرنه!
قبلش باید ببینیم چرا GCC (و گاهی Clang) همچین کار «عجیبی» میکنن و چرا تقریباً همیشه تو این موارد حق با کامپایلره.
کد سی احتمالاً همچین چیزی بوده:
و در نتیجه کد اسمبلی تولید شده توسط GCC همچین چیزیه!
کدهای تکراری! ولی چرا؟ تو 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 خروجی متفاوتی داره و کمی تمیزتره!
دلیلش اینه که Clang کمی محافظهکارتره و بیشتر به «کد تمیز» اهمیت میده، تو بنچمارکهای واقعی روی M2/M3/M4 معمولاً تفاوت سرعت از ۱٪ کمتره. یعنی GCC با کد «زشتتر» گاهی حتی چند صدم درصد سریعتره!
پس یادتون نره در بیشتر مواقع «کامپایلر بیشتر از من میفهمه»، کد اسمبلی کوتاهتر هم نشونه سریعتر بودنش نیست. دفعهی بعدی هم که GCC یا Clang چیزی تولید کرد که در نگاه اول «احمقانه» به نظر رسید، قبل از آهکشیدن یه بنچمارک کوچیک بزنین و یه نگاهی به معماری همون CPU بندازید. تو ۹۹٪ مواقع میبینین کامپایلر حق داشته. البته چیزهایی که هکرهای ffmpeg دستی بهینه میکنن رو هم نمیشه نادیده گرفت، ولی اونها قرار نیست به ما ثابت کنن که کامپایلر خنگه و ما ازش باهوشتریم. و در نهایت هم یادمون نره که روی آرم، GCC معمولاً یه ذره، خیلی کم اسمبلی بهینهتری تولید میکنه.
📡openpcb
«این دیگه چیه؟ چرا کامپایلر دو بار 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
1❤47👍13🔥3
جف گیرلینگ (معروف به 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
روی این برد پردازنده RP3A0 به همراه حافظه ۱۶ گیگابایت eMMC دیده میشه، و فقط برای بازار چین عرضه شده (بهخاطر کمبود جهانی حافظه LPDDR2)! این برد برای پروژههای صنعتی و embedded که نیاز به حجم تولید بالا و رزیریپای دارن و تولیدشون چینمحوره مناسبه.
خبر خوب اینه که شرکت EDATEC تأیید کرده CM0 رسماً توی سایت Raspberry Pi لیست شده و از ژانویه ۲۰۲۶ محصولات صنعتی مبتنی بر اون در سطح جهانی عرضه میشه.
با اینکه محصول جذابی به نظر میرسه، ولی اگه دنبال یه راهحل کممصرف، ارزان و قابل تولید انبوه برای پروژههای IoT یا صنعتی هستین، همین الان هم گزینههای جذابتری توی بازار وجود داره.
📡openpcb
👍20🔥3
چند وقتیه تو شبکه های اجتماعی مثل 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
گجت 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
❤22👌10🥱2
محققای دانشگاه استنفورد با همکاری کارخونه SkyWater Technology و دانشگاههای MIT، Penn و CMU موفق شدن اولین چیپ سهبعدی یکپارچه (Monolithic 3D) رو توی یه خط تولید تجاری بسازن تا قبل از این همیشه تو آزمایشگاه بوده ولی اینبار تو به صورت تجاری و تولید انبوه بوده.
این تکنولوژی برای حل مشکل گلوگاه معماری von Neumann تو چیپهای دوبعدی طراحی شده که توش جابجایی دیتا بین پردازنده و حافظه باعث تاخیر و مصرف انرژی زیاد میشه. راهکار این تیم استفاده از ترانزیستورهای نانولولهکربنی (CNFET) روی حافظههای RRAM بوده! چون CNFETها رو میشه توی دمای پایین ساخت، امکان لایهگذاری مدارات منطقی مستقیماً روی حافظه بدون آسیب زدن به لایههای زیرین فراهم شده.
این معماری اجازه میده اتصالات عمودی بین لایهها به شدت متراکم باشن که خروجیش افزایش سرعت پردازش و بهرهوری انرژی خیلی بالاتر برای بارهای کاری هوش مصنوعیه. نکته کلیدی این دستاورد، اثبات قابلیت تولید این چیپها با ابزارهای استاندارد صنعتیه که مسیر رو برای تولید انبوه سختافزارهای نسل بعدی AI باز میکنه.
خبری اصلی رو میتونید اینجا بخونید.
📡openpcb
این تکنولوژی برای حل مشکل گلوگاه معماری von Neumann تو چیپهای دوبعدی طراحی شده که توش جابجایی دیتا بین پردازنده و حافظه باعث تاخیر و مصرف انرژی زیاد میشه. راهکار این تیم استفاده از ترانزیستورهای نانولولهکربنی (CNFET) روی حافظههای RRAM بوده! چون CNFETها رو میشه توی دمای پایین ساخت، امکان لایهگذاری مدارات منطقی مستقیماً روی حافظه بدون آسیب زدن به لایههای زیرین فراهم شده.
این معماری اجازه میده اتصالات عمودی بین لایهها به شدت متراکم باشن که خروجیش افزایش سرعت پردازش و بهرهوری انرژی خیلی بالاتر برای بارهای کاری هوش مصنوعیه. نکته کلیدی این دستاورد، اثبات قابلیت تولید این چیپها با ابزارهای استاندارد صنعتیه که مسیر رو برای تولید انبوه سختافزارهای نسل بعدی AI باز میکنه.
خبری اصلی رو میتونید اینجا بخونید.
📡openpcb
❤21👍9🔥4
یه مهندس خوش ذوق به اسم 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
این برد از 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
👍29❤14🔥11
دولت هنداعلام کرده که بالاخره تونسته اولین ریزپردازندهی ۶۴ بیتی دو هستهای با فرکانس ۱ گیگاهرتز رو که کاملاً داخل خود کشور طراحی شده، رو بسازه. اسم این پردازنده 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
این پردازنده بخشی از برنامهی Digital India RISC-Vـه! یعنی دقیقاً رفتن سراغ معماری متنباز RISC-V تا هم درگیر لایسنسهای گرون و دستوپاگیر ARM نشن هم بتونن زنجیرهی طراحی تا تولید رو خودشون کنترل کنن. DHRUV64 یه پردازنده دو هستهایه، ۶۴ بیتی، و برای کاربردهای نسبتاً جدی مثل زیرساختهای مخابراتی، 5G، سیستمهای صنعتی، خودرو و حتی IoT در مقیاس بزرگ طراحی شده.
نکتهی مهمتر اینه که این چیپ قرار نیست اولین و آخرین نوع خودش باشه. بعد از این، نسلهای بعدی به اسم Dhanush و Dhanush+ هم در راهن، یعنی عملاً دارن یه خانوادهی پردازنده درست میکنن، نه یه دمو یا پروژهی دانشگاهی. این حرکت ادامهی همون مسیر پروژههای قبلی هند مثل SHAKTI، AJIT، VIKRAM و THEJAS ـه که هر کدوم یه تیکه از پازل استقلال سختافزاریشون بوده.
مشخصه هند نمیخواد فقط مصرفکنندهی چیپ باشه. میخواد طراحی، مالکیت فکری و اکوسیستم اطرافش رو خودش داشته باشه، مخصوصاً برای جاهایی که امنیت، پایداری و تحریمناپذیری مهمه. برای همین هم دولت با برنامههایی مثل India Semiconductor Mission و Chips to Startup داره مستقیم پول و زیرساخت میریزه توی این فضا.
در مجموع، DHRUV64 شاید از نظر عدد و رقم با پردازندههای تجاری روز دنیا قابل مقایسه نباشه، ولی از نظر سیاسی، صنعتی و راهبردی، یه قدم بزرگ حساب میشه. دقیقاً همون نقطهای که خیلی از کشورها دوست دارن بهش برسن.
خبر اصلی رو اینجا بخونید.
📡openpcb
👍60🔥2😁2
بریم برای کالبدشکافی 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
تا اینکه یه روز تصمیم گرفته میشه همین تیکه کد رو با فلسفهی «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
👍43❤11👏5
یه تیم تحقیقاتی تو MIT یه ربات پرنده ساخته که سرعت پروازش در حد زنبور عسله و در آینده میتونه به درد عملیات جستوجو و نجات بخوره.
اندازه این ربات حدود ۴ سانتیمتره و وزنش هم کمتر از یه گرمه. بهخاطر همین میتونه از جاهای خیلی تنگ رد بشه و مثلاً بعد از زلزله، لابهلای آوار بره و اگه آدم زندهای اون زیر باشه، به تیمهای امداد خبر بده.
کوین چن، استاد برق و کامپیوتر MIT و یکی از نویسندههای مقاله، میگه این نوع رباتها میتونن برای بازرسی جاهای تنگ مثل داخل توربینها هم استفاده بشن، یا حتی تو مزارع عمودی به گردهافشانی کمک کنن.
سالهاست که میکرورباتها رو برای محیطهایی که برای انسان خطرناک یا غیرقابل دسترسه بررسیت میکنن. بعضیها مثل سوسک میخزن، بعضیها مثل یه حشره فنری میپرن. ولی مشکل مشترکشون این بوده که خیلی ظریف و شکنندهان، کنترلشون سخته و با یه جریان هوای غیرقابل پیشبینی نامتعادل میشن.
برای کنترل این ربات از یه مدل یادگیری عمیق که رفتار ربات رو «پیشبینی» میکنه و بهترین توالی حرکتها رو برای دنبال کردن یه مسیر امن میچینه استفاده کردن. یعنی ربات بهجای دستورهای ثابت و از پیشنوشتهشده یاد میگیره تو شرایط مختلف چطور حرکت میکنه و همون لحظه بالها رو تنظیم میکنه تا پایدار بمونه و از مسیر خارج نشه.
این ربات تونسته تو ۱۱ ثانیه ۱۰ تا پشتک هوایی پشتسرهم بزنه، اون هم تو شرایط بادی، پشتک یه نمونهی خوب و از سختترین مانورهاست. اگه یه ربات بتونه پشتک بزنه، یعنی میتونه خیلی سریع تغییر جهت بده و این برای مقابله با تندبادهای لحظهای خیلی مهمه.
این تیم حسابی آیرودینامیک بالزدن حشرات رو بررسی کردن تا حرکت بال مگسها و زنبورها رو تقلید کنن. نتیجهاش رباتیه که ۳۳۰ بار در ثانیه بال میزنه تقریباً همردهی زنبور عسل واقعی.
متن خبر رو میتونید اینجا بخونید.
📡openpcb
اندازه این ربات حدود ۴ سانتیمتره و وزنش هم کمتر از یه گرمه. بهخاطر همین میتونه از جاهای خیلی تنگ رد بشه و مثلاً بعد از زلزله، لابهلای آوار بره و اگه آدم زندهای اون زیر باشه، به تیمهای امداد خبر بده.
کوین چن، استاد برق و کامپیوتر MIT و یکی از نویسندههای مقاله، میگه این نوع رباتها میتونن برای بازرسی جاهای تنگ مثل داخل توربینها هم استفاده بشن، یا حتی تو مزارع عمودی به گردهافشانی کمک کنن.
سالهاست که میکرورباتها رو برای محیطهایی که برای انسان خطرناک یا غیرقابل دسترسه بررسیت میکنن. بعضیها مثل سوسک میخزن، بعضیها مثل یه حشره فنری میپرن. ولی مشکل مشترکشون این بوده که خیلی ظریف و شکنندهان، کنترلشون سخته و با یه جریان هوای غیرقابل پیشبینی نامتعادل میشن.
برای کنترل این ربات از یه مدل یادگیری عمیق که رفتار ربات رو «پیشبینی» میکنه و بهترین توالی حرکتها رو برای دنبال کردن یه مسیر امن میچینه استفاده کردن. یعنی ربات بهجای دستورهای ثابت و از پیشنوشتهشده یاد میگیره تو شرایط مختلف چطور حرکت میکنه و همون لحظه بالها رو تنظیم میکنه تا پایدار بمونه و از مسیر خارج نشه.
این ربات تونسته تو ۱۱ ثانیه ۱۰ تا پشتک هوایی پشتسرهم بزنه، اون هم تو شرایط بادی، پشتک یه نمونهی خوب و از سختترین مانورهاست. اگه یه ربات بتونه پشتک بزنه، یعنی میتونه خیلی سریع تغییر جهت بده و این برای مقابله با تندبادهای لحظهای خیلی مهمه.
این تیم حسابی آیرودینامیک بالزدن حشرات رو بررسی کردن تا حرکت بال مگسها و زنبورها رو تقلید کنن. نتیجهاش رباتیه که ۳۳۰ بار در ثانیه بال میزنه تقریباً همردهی زنبور عسل واقعی.
متن خبر رو میتونید اینجا بخونید.
📡openpcb
❤22🔥15👍6
چند روزیه تو اخبار تکنولوژی گفته میشه که چین نمونه اولیه دستگاه لیتوگرافی EUV را ساخته و اون رو کنار محصولات ASML قرار میدن! ولی اصل ماجرا اینه که ما با یه کپی مهندسی معکوس شده از دستگاههای کامپکت Twinscan NXE هلندی طرف نیستیم، بلکه خروجی "پروژه منهتن" که توی شنژنه بیشتر یه تأسیسات عظیمه شبیه یه کارخونه(چیزی شبیه تصویر بالا که یکی از Synchrotronهای چینیه) تا یه دستگاه اندازه اتوبوس داخل کلینروم.
چینیها چون به زنجیره تأمین قطعات اپتیک و لیزرهای خاص ASML دسترسی نداشتن، مسیر فیزیک رو عوض کردن و به جای متد LPP که لیزر به قطرات مذاب شناور قلع شلیک میشه، رفتن سراغ تکنولوژی SSMB یا یه سینکروترون (Synchrotron) خیلی بزرگ که بتونن نور ۱۳.۵ نانومتری رو با توان بالا ولی در ابعاد یک کارخونه تولید کنن، در نتیجه الان گلوگاه فیزیک پلاسما و تولید فوتون رو شکستن ولی با ابعاد خیلی خیلی عظیم البته با بازدهی تولید خیلی پایین.
در واقع چیزی که الان داره جور صنعت چیپ چین رو میکشه و بهشون خروجی ۵ نانومتری میده، این دستگاه جدید نیست، بلکه فشار آوردن روی لیتوگرافی DUV با دستگاههای داخلی مثل سری SSA800 و استفاده از تکنیکهای کثیف مهندسی ولی موثر SAQP (Self-Aligned Quadruple Patterning) هست که توش ویفر رو ۴ بار اکسپوز میکنن! این روش سرعت تولید رو پایین میاره و مدیریت Overlay Error توش کابوسه، ولی عملاً تحریم رو دور زده و نشون میده که چین حتی با هزینه بالاتر و پروسه کندتر، به استقلال تو لایههای حساس سیلیکون رسیده که نهایتاً سرریز این تکنولوژی باعث میشه تو نودهای پایینتر دستشون بازتر بشه.
📡openpcb
چینیها چون به زنجیره تأمین قطعات اپتیک و لیزرهای خاص ASML دسترسی نداشتن، مسیر فیزیک رو عوض کردن و به جای متد LPP که لیزر به قطرات مذاب شناور قلع شلیک میشه، رفتن سراغ تکنولوژی SSMB یا یه سینکروترون (Synchrotron) خیلی بزرگ که بتونن نور ۱۳.۵ نانومتری رو با توان بالا ولی در ابعاد یک کارخونه تولید کنن، در نتیجه الان گلوگاه فیزیک پلاسما و تولید فوتون رو شکستن ولی با ابعاد خیلی خیلی عظیم البته با بازدهی تولید خیلی پایین.
در واقع چیزی که الان داره جور صنعت چیپ چین رو میکشه و بهشون خروجی ۵ نانومتری میده، این دستگاه جدید نیست، بلکه فشار آوردن روی لیتوگرافی DUV با دستگاههای داخلی مثل سری SSA800 و استفاده از تکنیکهای کثیف مهندسی ولی موثر SAQP (Self-Aligned Quadruple Patterning) هست که توش ویفر رو ۴ بار اکسپوز میکنن! این روش سرعت تولید رو پایین میاره و مدیریت Overlay Error توش کابوسه، ولی عملاً تحریم رو دور زده و نشون میده که چین حتی با هزینه بالاتر و پروسه کندتر، به استقلال تو لایههای حساس سیلیکون رسیده که نهایتاً سرریز این تکنولوژی باعث میشه تو نودهای پایینتر دستشون بازتر بشه.
📡openpcb
❤39👍23❤🔥5