آموزش اِف‌پی‌جی‌اِی از صفر

تا زمانی که تنظیمات IP تغییر نکرده باشد، همان نتیجه قبلی دوباره استفاده می‌شود و عملاً زمان اضافه‌ای از شما نمی‌گیرد. اگر بدون نیاز Output Products را Reset یا دوباره Generate کنید، این مزیت را از دست می‌دهید. یک فرآیند عملی که معمولاً خوب جواب می‌دهد: ماژول را بنویسید. مرحله Elaborate را انجام دهید. با شبیه‌سازی آن را بررسی کنید و تا زمانی که خروجی درست نشده، همان‌جا بمانید. بعد همان ماژول را به‌صورت Out-of-Context سنتز کنید تا Resource Usage و سرعت آن را بررسی کنید. سپس آن را وارد طراحی اصلی کنید و یک پیاده‌سازی کامل انجام دهید. این را به‌عنوان مرجع نگه دارید. از آن به بعد، برای تغییرات کوچک‌تر اجازه دهید Incremental Implementation کار را انجام دهد. الگوی اصلی پشت همه این نکات یک چیز است: هرچه در Flow جلوتر می‌روید، هزینه زمانی مراحل به‌شدت بیشتر می‌شود. بنابراین هر سؤال را در ارزان‌ترین و سریع‌ترین مرحله‌ای پاسخ دهید که قادر است جواب آن سؤال را به شما بدهد. بخش عمده زمان توسعه شما باید در شبیه‌سازی بگذرد. اجرای Implementation مرحله آخر کار است، نه حلقه‌ای که برای هر تغییر کوچک بارها و بارها تکرار شود. 🆔 @FPGA0

فایل بیتی را فقط زمانی تولید کنید که واقعاً می‌خواهید FPGA روی برد را پروگرام کنید. ۵- Incremental Implementation را فعال کنید به Settings و سپس بخش Implementation بروید. در آنجا گزینه مربوط به Incremental Implementation را پیدا کنید و تنظیم کنید که به‌صورت خودکار از Run قبلی استفاده شود. این قابلیت چه کاری انجام می‌دهد؟ بعد از یک Implementation موفق، ویوادو یک Snapshot از Placement و Routing طراحی نگه می‌دارد. در اجرای بعدی، طراحی جدید را با آن Snapshot مقایسه می‌کند. برای قسمت‌هایی که تغییری نکرده‌اند، همان Placement و Routing قبلی را نگه می‌دارد و دوباره همه چیز را از ابتدا محاسبه نمی‌کند. در واقع فقط روی بخش‌هایی کار سنگین انجام می‌شود که شما تغییر داده‌اید. اگر در یک طراحی بزرگ فقط یک بلوک کوچک را تغییر داده باشید، این قابلیت می‌تواند زمان Implementation را حتی به نصف یا کمتر کاهش دهد. یک مزیت مهم دیگر هم وجود دارد که معمولاً کمتر به آن توجه می‌شود. چون محل قرارگیری و مسیرهای بخش‌های تغییرنکرده حفظ می‌شوند، نتایج Timing آنها نیز ثابت‌تر باقی می‌ماند. یعنی برای بلوک‌هایی که اصلاً دست نزده‌اید، مجبور نیستید دوباره Timing Closure انجام دهید. یک نکته هم کمک می‌کند Incremental Implementation بهتر عمل کند: طراحی را به ماژول‌های مشخص و مستقل تقسیم کنید. ویوادو می‌تواند نتایج را ماژول به ماژول دوباره استفاده کند. بنابراین یک Hierarchy مرتب، چیز مشخصی برای استفاده دوباره از نتایج در اختیار ابزار قرار می‌دهد. اگر کل طراحی را در یک فایل بسیار بزرگ نوشته باشید، امکان استفاده مجدد از نتایج بسیار کمتر می‌شود. ۶- هنگام توسعه از Strategy سریع‌تر استفاده کنید در تنظیمات Synthesis و Implementation گزینه‌ای به نام Strategy وجود دارد. گزینه Strategy در واقع مجموعه‌ای از تنظیمات ابزار است که از قبل برای یک هدف خاص انتخاب شده‌اند. یکی از این گزینه‌ها Flow_RuntimeOptimized نام دارد. این Strategy تعدادی از مراحل سنگین‌تر Optimization را اجرا نمی‌کند. در نتیجه ممکن است طراحی نهایی کمی کندتر باشد یا کمی منابع بیشتری مصرف کند، اما اجرای Flow سریع‌تر تمام می‌شود. وقتی هنوز در حال بررسی گزینه‌های مختلف و تغییر دادن طراحی هستید، می‌توانید از این Strategy استفاده کنید. برای پیاده‌سازی نهایی دوباره به Strategy پیش‌فرض برگردید؛ یعنی زمانی که واقعاً چند درصد آخر Performance یا Optimization برایتان اهمیت دارد. ۷- فقط همان فرکانسی را درخواست کنید که واقعاً نیاز دارید این نکته خیلی‌ها را غافلگیر می‌کند: تنظیم Timing Constraint شما می‌تواند روی مدت زمان اجرای ابزارها تأثیر بگذارد. ابزار Placer و Router تلاش می‌کنند طراحی را طوری پیاده‌سازی کنند که Timing موردنظر شما برآورده شود. اگر طراحی شما فقط باید با فرکانس ۵۰ مگاهرتز کار کند، اما قید آن را روی ۱۵۰ مگاهرتز تنظیم کنید چون فکر می‌کنید این کار «مطمئن‌تر» است، ابزار ممکن است زمان زیادی صرف رسیدن به هدفی کند که اساساً هیچ نیازی به آن ندارید. قیدها را بر اساس نیاز واقعی سیستم انتخاب کنید. ۸- Debug Probeها را بعد از Synthesis اضافه کنید، نه داخل کد استفاده از ILA رایگان نیست. هم Block RAM مصرف می‌کند، هم Routing بیشتری ایجاد می‌کند و هم کار ابزارهای Implementation را سنگین‌تر می‌کند. اگر تعداد Probeها زیاد باشد و Capture Depth بزرگی انتخاب کرده باشید، ممکن است زمان زیادی به هر Run اضافه شود. دو عادت ساده می‌تواند کمک زیادی کند. اول اینکه تا زمانی که هنوز مرتب طراحی را تغییر می‌دهید، Capture Depth را کوچک نگه دارید. فقط زمانی آن را افزایش دهید که واقعاً برای Debug نهایی به تعداد نمونه بیشتری نیاز دارید. دوم اینکه Probeها را روی طرح سنتز شده اضافه کنید، نه اینکه ILA را مستقیماً داخل Source Code قرار دهید. ابتدا Synthesized Design را باز کنید، سیگنال‌هایی را که می‌خواهید مشاهده کنید مشخص کنید و از Set Up Debug استفاده کنید. مزیت این روش این است که با تغییر Probeها مجبور نمی‌شوید کل پروژه را دوباره Synthesize کنید. ۹- چند نکته کوچک که در مجموع تفاوت زیادی ایجاد می‌کنند پروژه را روی حافظه داخلی کامپیوتر نگه دارید. ویوادو هنگام اجرای Flow حجم زیادی داده می‌خواند و می‌نویسد. اگر پروژه روی Network Drive یا USB Drive باشد، تقریباً تمام مراحل کندتر می‌شوند. تعداد Threadها را هم در تنظیمات Vivado افزایش دهید. مراحل Placement و Routing می‌توانند از چند هسته پردازنده استفاده کنند، اما تنظیم پیش‌فرض معمولاً محافظه‌کارانه است. و در نهایت، تا زمانی که لازم نیست به IP Coreها دست نزنید. ویوادو معمولاً هر IP Core را یک بار سنتز می‌کند و نتیجه را در Cache نگه می‌دارد.

📩 ایمیل امروز... ⚡️ یکی از شرکت کنندگان در دوره طراحی دیجیتال با FPGA اخیراً این سؤال را مطرح کرد: "یکی از چیزهایی که متوجه شده‌ام زمان زیادی می‌گیرد، فرایند Implementation پروژه و تولید Bitstream است. خیلی راحت ممکن است زمان زیادی فقط صرف همین کار شود." این یکی از مشکلات رایج در کار با FPGA است. سه خط از کد را تغییر می‌دهید، روی Run Implementation کلیک می‌کنید و بعد باید منتظر بمانید. در یک طراحی کوچک شاید این انتظار فقط چند دقیقه باشد. اما در یک طراحی بزرگ‌تر ممکن است هر بار بیست دقیقه، چهل دقیقه یا حتی بیشتر طول بکشد. اگر این کار را ده بار در طول روز تکرار کنید، بخش بزرگی از روزتان فقط صرف منتظر ماندن می‌شود. اما نکته مهم اینجاست: اجرای کامل Flow هزینه زمانی زیادی دارد، ولی در بیشتر مواقع اصلاً نیازی نیست کل Flow را اجرا کنید. بیشتر سؤال‌هایی که هنگام توسعه یک طراحی برایتان پیش می‌آید، با یک مرحله بسیار سریع‌تر و ساده‌تر قابل پاسخ دادن است. در ادامه چند روشی را توضیح می‌دهم که خودم برای کوتاه نگه داشتن چرخه‌های تست و اصلاح طراحی استفاده می‌کنم. ۱- تا جای ممکن در Simulation بمانید تقریباً تمام خطاهای عملکردی طراحی را می‌توان با Testbench پیدا کرد. شبیه‌سازی معمولاً چند ثانیه طول می‌کشد. Implementation چندین دقیقه. دلیلش هم ساده است. شبیه‌سازی فقط رفتار طراحی را بررسی می‌کند. در واقع به این سؤال پاسخ می‌دهد: آیا منطق طراحی من خروجی درست را تولید می‌کند؟ اما Implementation باید به سؤال کاملاً متفاوتی پاسخ دهد: آیا این منطق واقعاً می‌تواند روی LUTها، Flip-Flopها و مسیرهای فیزیکی همین FPGA پیاده‌سازی شود؟ و آیا سیگنال‌ها می‌توانند با سرعت موردنیاز بین این منابع حرکت کنند؟ پاسخ دادن به سؤال دوم بسیار سخت‌تر است و به همین دلیل زمان بیشتری می‌برد. وقتی طراحی شما درست کار نمی‌کند، در بیشتر مواقع مشکل از رفتار منطقی طراحی است. پس رفتار طراحی را جایی بررسی کنید که هزینه‌اش بسیار کمتر است: Simulation. ۲- از Elaboration برای یک بررسی سریع استفاده کنید در Flow Navigator و در بخش RTL Analysis گزینه‌ای به نام Open Elaborated Design وجود دارد. از آن استفاده کنید. در مرحله Elaboration، نرم‌افزار Vivado فایل‌های Source را می‌خواند، ساختار سلسله‌مراتبی طراحی را مشخص می‌کند، ماژول‌ها را به هم متصل می‌کند و یک نمایش منطقی عمومی از مدار می‌سازد. اما هنوز چیزی را روی منابع واقعی FPGA پیاده‌سازی نمی‌کند. به همین دلیل این مرحله معمولاً فقط چند ثانیه طول می‌کشد، نه چند دقیقه. با این حال، همین مرحله ساده می‌تواند تعداد زیادی از مشکلات واقعی طراحی را پیدا کند: خطاهای تایپی، اتصال اشتباه پورت‌ها، یکسان نبودن عرض سیگنال‌ها یا ساخته شدن ناخواسته Latch. عادت کنید بعد از هر تغییر مهم در کد، یک بار Elaborated Design را باز کنید. هزینه زمانی بسیار کمی دارد، ولی می‌تواند جلوی اجرای بیهوده مراحل سنگین‌تر را بگیرد. ۳- به‌جای کل طراحی، فقط همان ماژولی را سنتز کنید که روی آن کار می‌کنید اگر می‌خواهید فقط یک بلوک از طراحی را بررسی کنید، لازم نیست بقیه پروژه را Comment کنید. در پنجره Sources روی ماژول موردنظر راست‌کلیک کنید و گزینه Set as Out-of-Context Module را انتخاب کنید. انتخاب Out-of-Context یعنی ویوادو آن ماژول را به‌صورت مستقل سنتز می‌کند. پورت‌های ماژول صرفاً به‌عنوان سیگنال در نظر گرفته می‌شوند و Vivado تلاش نمی‌کند آنها را به پین‌های فیزیکی FPGA اختصاص دهد. بقیه طراحی نیز در این فرایند دخالت داده نمی‌شود. نتیجه‌ای که از این کار می‌گیرید بسیار مفید است. می‌توانید Synthesized Design را باز کنید و با Report Utilization ببینید این ماژول چند LUT، چند Flip-Flop، چند DSP Slice و چه مقدار Block RAM مصرف می‌کند. همچنین با Report Timing Summary می‌توانید بررسی کنید که این بلوک تقریباً تا چه سرعتی می‌تواند کار کند. این روش از Comment کردن قسمت‌های مختلف پروژه بهتر است. اول اینکه چیزی را از طراحی حذف نمی‌کنید و بعداً هم خطر این وجود ندارد که یادتان برود بخشی از کد را دوباره فعال کنید. دوم اینکه اعدادی که در گزارش‌ها می‌بینید فقط مربوط به همان ماژول هستند و در نتیجه تحلیل آنها ساده‌تر می‌شود. ۴- قبل از Bitstream متوقف شوید تولید Bitstream یک مرحله جداگانه در انتهای Flow است. وظیفه آن فقط یک چیز است: ساخت فایلی که بتوان با آن FPGA واقعی را پیکره‌بندی کرد. اگر سؤال شما این است که طراحی چه مقدار Resource مصرف می‌کند یا آیا Timing را پاس می‌کند، نیازی به Bitstream ندارید. مرحله Synthesis یا Implementation را اجرا کنید، گزارش‌ها را بررسی کنید و همان‌جا متوقف شوید.

📣 آخرین فرصت... ⚡️ شش پیشنهاد ویژه و تخفیف‌هایی تا ۴۵% ❇️ روی لینک زیر کلیک کنید تا از شش پیشنهاد ویژه تابستان مطلع شوید: 🌎 https://faradandish.com/summer-offer 🗓 امکان پرداخت در چهار قسط از طرق دیجی‌پِی 🔺 فرصت استفاده از این پیشنهادها فقط تا ساعت ۲۳:۵۹ دقیقه امشب است. 🆔 @FPGA0

⚡️ پرداخت قسطی برای اولین بار در فراد اندیش... 🗓 امکان پرداخت در چهار قسط از طرق دیجی‌پِی ❇️ روی لینک زیر کلیک کنید تا از شش پیشنهاد ویژه تابستان مطلع شوید: 🌎 https://faradandish.com/summer-offer 🔺 با توجه به عدم دسترسی به سایت در روز گذشته، مهلت استفاده از پیشنهادات تابستان تا چهارشنبه ۲۴ تیر تمدید شد. 🆔 @FPGA0

آموزش اِف‌پی‌جی‌اِی از صفر pinned a photo

⚡️ فروش ویژه تعطیلات تابستان تمدید شد! ❇️ روی لینک زیر کلیک کنید تا از شش پیشنهاد ویژه تابستان مطلع شوید: 🌎 https://faradandish.com/summer-offer 🔺 فرصت استفاده از این پیشنهادها فقط تا چهارشنبه ۲۴ تیر است. 🆔 @FPGA0

✴️ نحوه برگزاری دوره‌های آنلاین فراد اندیش... 🔷 بسیاری از افرادی که تمایل به شرکت در دوره‌های آنلاین فراد اندیش را دارند تصور می‌کنند که باید حتما در زمان خاصی آنلاین باشند تا بتوانند از آموزش‌ها استفاده کنند؛ اما... 🔹 تمام آموزش‌های تخصصی که در قالب دوره‌های آنلاین ارائه می‌شوند به صورت ویدئوهای آموزشی از قبل ضبط شده هستند... 🔹 در عین حال، وقتی این آموزش‌ها در دسترس شما قرار گرفتند، برای همیشه در بخش مخصوصی در حساب کاربری شما باقی می‌مانند... 🔹 و به همین دلیل، شما می‌توانید آموزش‌ها را در زمان مورد نظر خودتان و با سرعت دلخواه خودتان پیگیری کنید... 🔹 و مهمتر از همه این موارد، شما این امکان را دارید که سوالات خودتان در مورد درس‌های دوره‌ها را در زیر ویدئوی مربوط به همان درس مطرح کنید ⚡️ همانطور که احتمالا می‌دانید، فروش ویژه تابستان از چند روز پیش شروع شده است که مجموعا شامل ۶ پیشنهاد فوق‌العاده است. 🔷 برای اطلاع از جزئیات ۶ پیشنهاد ویژه تابستان وارد صفحه زیر شوید: 🌎 https://faradandish.com/summer-offer 🔺 مهلت استفاده از این پیشنهادها تا فردا شب است. 🆔 @FPGA0

📩 ایمیل امروز... ⚡️ میشه بی‌خیال HDL شد؟ یکی از مخاطبان سایت اخیراً سؤال جالبی از من پرسید: "آیا ابزاری وجود دارد که کار با FPGA را نسبت به نوشتن مستقیم کد HDL در Vivado یا Quartus ساده‌تر کند؟" پاسخ کوتاه این است: بله. ابزارهای مختلفی وجود دارند که می‌توانند فرآیند توسعه FPGA را سریع‌تر کنند. برای مثال، با استفاده از High-Level Synthesis (HLS) می‌توانید الگوریتم‌تان را با زبان C یا ++C بنویسید و این ابزار، آن را به‌صورت خودکار به HDL تبدیل کند. اگر از تراشه‌های Zynq استفاده می‌کنید، علاوه بر بخش FPGA، یک پردازنده ARM هم در اختیار دارید. بسیاری از وظایف کنترلی، پروتکل‌های ارتباطی و کارهای مربوط به مدیریت سیستم را می‌توان روی همین پردازنده اجرا کرد، بدون اینکه لازم باشد آن‌ها را داخل خود FPGA پیاده‌سازی کنید. اگر هم در حوزه پردازش سیگنال فعالیت می‌کنید، MATLAB ابزارهایی در اختیار شما قرار می‌دهد که می‌توانید با استفاده از بلوک‌های گرافیکی، سیستم مورد نظرتان را طراحی کنید و در نهایت HDL را به‌صورت خودکار تولید کنید. با این حساب شاید این سؤال پیش بیاید: اگر این همه ابزار وجود دارد، چرا من همچنان زمان زیادی را صرف آموزش طراحی با HDL می‌کنم؟ دلیلش ساده است. هیچ‌کدام از این ابزارها نمی‌توانند جای درک عمیق از نحوه کار سخت‌افزار FPGA را بگیرند. دیر یا زود، هر مهندس FPGA به جایی می‌رسد که همه چیز آن‌طور که انتظار دارد پیش نمی‌رود. ممکن است طراحی از نظر Timing به نتیجه نرسد. ممکن است HDL تولیدشده منابع بسیار زیادی مصرف کند. ممکن است رابط سخت‌افزاری به‌درستی کار نکند. ممکن است میزان Latency با چیزی که انتظار داشتید متفاوت باشد. یا حتی ممکن است سخت‌افزار تولیدشده اصلاً آن کاری را که مدنظر داشتید انجام ندهد. در چنین شرایطی، کسی که اصول طراحی FPGA را می‌داند، می‌تواند مشکل را پیدا و برطرف کند. اما کسی که فقط کار با ابزار را یاد گرفته، معمولاً در همین نقطه متوقف می‌شود. به همین دلیل، در همه آموزش‌هایمان هدف من فقط این نیست که به شما کمک کنم کار با نرم‌افزارها را یاد بگیرید و چند پروژه انجام دهید. تمام کردن یک پروژه، بخش آسان ماجراست. ارزش واقعی زمانی ایجاد می‌شود که دقیقاً بدانید چرا آن پروژه به آن شکل کار می‌کند. وقتی اصول طراحی FPGA را به‌خوبی درک کنید، دیگر فرقی نمی‌کند از کدنویسی HDL استفاده کنید، از IP Coreها کمک بگیرید، سراغ HLS بروید، HDL را با MATLAB تولید کنید، از پردازنده‌های نهفته استفاده کنید یا هر فناوری جدیدی که در آینده معرفی شود. ابزارها ممکن است تغییر کنند. اما اصول، ثابت می‌مانند. به همین دلیل هم در طول آموزش، تأکید اصلی ما روی طراحی با HDL است. البته هر جا استفاده از IP Coreها انتخاب منطقی و کاربردی‌تری باشد، بدون تردید از آن‌ها نیز استفاده می‌کنیم. هدف من این است که وقتی آموزش‌تان را به پایان می‌رسانید، مطمئن باشید که اگر فردا بخواهید کار مشابهی را انجام دهید، از پس آن برمی‌آیید. این نتیجه، تفاوت زیادی با این دارد که فقط یک پروژه را به هر شکلی به مرحله اجرا برسانید. 🆔 @FPGA0

✴️ پاسخ به ۶ سوال در مورد ۶ پیشنهاد ویژه تابستان 1️⃣ این ۶ پیشنهاد دقیقا چه هستند؟ 🔹 ۱- شرکت در دوره آنلاین طراحی دیجیتال با FPGA (تخفیف ۳۵%) 🔹 ۲-شرکت در دوره آنلاین پردازش سیگنال با FPGA (تخفیف ۳۵%) 🔹 ۳-شرکت در دوره آنلاین اینترفیس با FPGA (تخفیف ۳۵%) 🔹 ۴، ۵ و ۶- ثبت‌نام همزمان در دو دوره آنلاین دلخواه (تخفیف ۴۵%) 2️⃣ بعد ثبت‌نام در دوره آنلاین، چه اتفاقی می‌افتد؟ 🔹 به محض ثبت‌نام در دوره، شما به محتوای آموزشی جلسه اول دسترسی خواهید داشت. 3️⃣ ویدئوها چگونه در دسترس من قرار می‌گیرند؟ 🔹 تمام فایل‌های ویدئویی و دیگر موارد آموزشی، برای همیشه در حساب کاربری شما در سایت قابل دسترسی هستند. 4️⃣ ویدئوهای جلسات بعدی کی قابل دسترسی هستند؟ 🔹 یک هفته بعد از جلسه اول، محتوای آموزشی جلسه دوم قابل دسترسی است و همین طور هفته به هفته به محتوای جلسات بعد دسترسی خواهید داشت. (در مورد دوره پردازش سیگنال با FPGA، هر هفته به دو جلسه دسترسی خواهید داشت.) 5️⃣ چه پیش‌نیازی برای شرکت در دوره لازم است؟ 🔹 برای دوره طراحی دیجیتال با FPGA: فقط آشنایی عمومی با مدارات منطقی 🔹 برای دوره پردازش سیگنال با FPGA: آشنایی نسبی با FPGA و زبان VHDL 🔺 هیچ نیازی به آشنایی با الگوریتم‌های پردازش سیگنال و حتی نرم‌افزار متلب نیست 🔹 برای دوره اینترفیس با FPGA: آشنایی نسبی با FPGA و زبان VHDL 6️⃣ هدایای این دوره، چطور به دست من می‌رسند؟ 🔹 مشابه محتوای آموزشی دوره اصلی، هدایای آموزشی هم از طریق حساب کاربری شما در سایت قابل دسترسی هستند. 🌟 توضیحات کامل این ۶ پیشنهاد 👇 🌎 https://faradandish.com/summer-offer 🔺 مهلت استفاده از این ۶ پیشنهاد تا جمعه ۱۲ تیر است. 🆔 @FPGA0

📩 ایمیل امروز... ⚡️ کلاک جدید یا شمارنده؟ یکی از طراحان FPGA که این روزها با او کار می‌کنم، در حال پیاده‌سازی یک پروژه RS232 است. در بخشی از این پروژه، باید سیگنال خروجی فرستنده (Tx) را بر مبنای Baud Rate مورد نظر مسئله (۹۶۰۰ بیت در ثانیه) ایجاد می‌کرد. راه‌حلی که انتخاب کرده بود این بود که کلاک اصلی ۱۰۰ مگاهرتز سیستم را با استفاده از تقسیم فرکانسی به کمک یک شمارنده به یک کلاک بسیار کندتر تبدیل کند و سپس از آن کلاک جدید به عنوان کلاک یک Process دیگر استفاده کند. در نگاه اول، این راه‌حل کاملاً منطقی به نظر می‌رسد. بالاخره اگر به یک سیگنال با نرخ ۹۶۰۰ بیت در ثانیه نیاز دارید، چرا یک کلاک ۹۶۰۰ هرتز نسازید و از همان استفاده نکنید؟ اما مشکل اینجاست که با این کار، یک حوزه کلاک (Clock Domain) جدید داخل طراحی خود ایجاد می‌کنید. و در پیاده‌سازی با FPGA، این معمولاً چیزی است که بهتر است از آن اجتناب شود. یکی از اصولی که همیشه آموزش می‌دهم این است: تا حد ممکن از کمترین تعداد کلاک در طراحی استفاده کنید. اگر بتوانید کل طراحی را تنها با یک کلاک اجرا کنید، معمولاً این بهترین انتخاب است. البته در سیستم‌های بزرگ، گاهی استفاده از چند کلاک با فرکانس‌های مختلف اجتناب‌ناپذیر است. اما در چنین شرایطی، این کلاک‌ها باید به‌صورت صحیح و با استفاده از منابع اختصاصی مدیریت کلاک در FPGA مانند DCM یا MMCM، تولید شوند. گاهی هم این کلاک‌ها خارج از FPGA تولید می‌شوند و از طریق پایه‌های ورودی وارد تراشه می‌شوند. در این حالت نیز بهتر است قبل از استفاده، از یک Clock Buffer اختصاصی و حتی ترجیحاً از یک MMCM عبور داده شوند. اما کاری که معمولاً نباید انجام دهید این است که با استفاده از یک شمارنده یک کلاک تولید کنید و بعد از همان سیگنال به‌عنوان کلاک Processهای دیگر استفاده کنید. دلیلش این است که چنین سیگنال‌هایی دیگر از شبکه اختصاصی توزیع کلاک FPGA عبور نمی‌کنند، بلکه مانند یک سیگنال منطقی معمولی مسیریابی می‌شوند. این موضوع می‌تواند مشکلات زمانی (Timing) ایجاد کند و قابلیت اطمینان طراحی را کاهش دهد. بنابراین حتی اگر به هر دلیلی یک کلاک را به این روش تولید کردید، بهتر است قبل از استفاده، آن را از یک Global Clock Buffer عبور دهید تا FPGA آن را از طریق مسیرهای اختصاصی کلاک توزیع کند، نه از طریق مسیرهای معمولی سیگنال. اما نکته جالب اینجاست که در بسیاری از موارد اصلاً نیازی به ساختن یک کلاک جدید ندارید. همان پروژه RS232 را در نظر بگیرید. به جای اینکه یک کلاک ۹۶۰۰ هرتز ایجاد کنید، می‌توانید کل طراحی را همچنان با همان کلاک اصلی ۱۰۰ مگاهرتز اجرا کنید. داخل همان Process، یک شمارنده ایجاد کنید. در هر سیکل کلاک، مقدار شمارنده یک واحد افزایش پیدا کند. هر زمان که مقدار شمارنده به تعداد سیکل‌های متناظر با یک عرض بیت فرستنده Tx یا همان پریود Baud Rate رسید، بیت بعدی دیتا را ارسال کنید و سپس شمارنده را صفر کنید. به همین سادگی. در این حالت، ارسال بیت‌ها همچنان با همان Baud Rate انجام می‌شود، اما کل طراحی فقط یک حوزه کلاک خواهد داشت. این طرز فکر را تقریباً در همه پروژه‌های FPGA می‌توانید ببینید. بیشتر افراد معمولاً این‌طور فکر می‌کنند: "اگر بخواهم بخشی از طراحی کندتر کار کند، پس به یک کلاک کندتر نیاز دارم." اما یک طراح با تجربه FPGA معمولاً این‌گونه فکر می‌کند: "من همین حالا هم یک کلاک دارم. کافی است با استفاده از یک شمارنده، سیگنال با زمان‌بندی دلخواهم را ایجاد کنم." نتیجه این رویکرد، طراحی ساده‌تر، مشکلات Timing کمتر و سخت‌افزاری است که با بزرگ‌تر و پیچیده‌تر شدن پروژه، بسیار راحت‌تر توسعه پیدا می‌کند. این فقط یک تغییر کوچک در نحوه فکر کردن است، اما تأثیر آن در کیفیت طراحی، بسیار بیشتر از چیزی است که در ابتدا به نظر می‌رسد. 🆔 @FPGA0

آموزش اِف‌پی‌جی‌اِی از صفر pinned a photo

📣 ثبت‌نام ویژه تعطیلات تابستان شروع شد... ⚡️ تا ۴۵% تخفیف! ❇️ روی لینک زیر کلیک کنید تا از شش پیشنهاد ویژه تابستان مطلع شوید: 🌎 https://faradandish.com/summer-offer 🔺 فرصت استفاده از این پیشنهادها فقط تا جمعه 12 تیر است 🆔 @FPGA0

📩 ایمیل امروز... (ادامه از پست قبل) ⚡️ چرا باید سخت‌افزارِ خودم را طراحی کنم؟ قبل از اینکه یک شرکت متحمل هزینه‌های نجومی شود تا یک تراشه اختصاصی (ASIC) بسازد؛ فرآیندی که ممکن است ماه‌ها زمان ببرد، ابتدا کل طراحی را روی FPGA آزمایش می‌کند. اگر مشکلی وجود داشته باشد، طراحی را اصلاح می‌کنند و دوباره روی FPGA بارگذاری می‌کنند. اما وقتی یک تراشه ASIC ساخته شد، دیگر چنین امکانی وجود ندارد. و البته قابلیت جالب‌تری هم وجود دارد: Partial Reconfiguration یعنی FPGA می‌تواند فقط بخشی از خودش را در حین کار بازنویسی کند، بدون اینکه بقیه مدار متوقف شود. یک رادیوی نرم‌افزاری (SDR) مثال بسیار خوبی برای این قابلیت است. در SDR بخش پردازش سیگنال توسط سخت‌افزاری انجام می‌شود که خودتان طراحی کرده‌اید، نه توسط مدارهای آنالوگ ثابت. با استفاده از Partial Reconfiguration، رادیو می‌تواند هنگام کار، یک دمودلاتور جدید بارگذاری کند و از دریافت یک نوع سیگنال به نوع کاملاً متفاوتی سوئیچ کند؛ بدون اینکه حتی یک لحظه متوقف شود. سخت‌افزار در همان لحظه خودش را تغییر می‌دهد تا وظیفه جدیدی را انجام دهد. پس به طور خلاصه، ما FPGA را انتخاب می‌کنیم... چون چیزی را در اختیار شما قرار می‌دهد که هیچ پردازنده آماده‌ای نمی‌تواند ارائه کند: آزادی طراحی برای ساخت اختصاصیً همان سخت‌افزاری که مسئله شما به آن نیاز دارد. سخت‌افزاری که همه چیز را به‌صورت موازی اجرا می‌کند، رفتارش تا سطح نانوثانیه قابل پیش‌بینی است، به طور هم‌زمان با تمام قطعات جانبی ارتباط برقرار می‌کند و حتی می‌تواند هنگام اجرا خودش را تغییر دهد. اینجا شما فقط برای یک تراشه برنامه نمی‌نویسید؛ بلکه خودِ تراشه را خلق می‌کنید. و وقتی اولین طراحی‌تان را روی یک FPGA واقعی اجرا کنید و ببینید که مدار دقیقاً همان‌طور که خودتان ساخته‌اید عمل می‌کند، نگاهتان به تراشه‌های آماده برای همیشه تغییر خواهد کرد. این همان دنیایی است که ما هر روز در آن کار می‌کنیم. و خوشحال می‌شوم اگر بتوانم در این مسیر همراه شما باشم. 🆔 @FPGA0

📩 ایمیل امروز... ⚡️ چرا باید سخت‌افزارِ خودم را طراحی کنم؟ وقتی انواع و اقسام پردازنده‌های آماده وجود دارند، چرا اصلاً کسی باید از FPGA استفاده کند و سخت‌افزار خودش را طراحی کند؟ این یک سؤال کاملاً منطقی است. وقتی نرم‌افزار می‌نویسید، از سخت‌افزاری استفاده می‌کنید که شخص دیگری آن را طراحی کرده است. تراشه از قبل ساخته شده، مجموعه دستورالعمل‌های مشخصی دارد و وظیفه شما این است که آن دستورالعمل‌ها را به شکلی هوشمندانه کنار هم قرار دهید تا به نتیجه دلخواه برسید. اما FPGA داستان کاملاً متفاوتی دارد. اینجا دیگر برای سخت‌افزار برنامه نمی‌نویسید؛ بلکه خودِ سخت‌افزار را دقیقاً متناسب با مسئله‌ای که می‌خواهید حل کنید، طراحی می‌کنید. همین یک تفاوت، پاسخ واقعی سؤال ابتدای این ایمیل است و خودش را به سه شکل نشان می‌دهد؛ سه قابلیتی که تقریباً هیچ فناوری دیگری نمی‌تواند هم‌زمان در اختیار شما قرار دهد. اجازه دهید یکی‌یکی آن‌ها را مرور کنیم. ۱. سخت‌افزاری می‌سازید که همه چیز را به‌صورت موازی انجام می‌دهد. به نحوه کار یک پردازنده فکر کنید. پردازنده یک دستور را اجرا می‌کند، بعد دستور بعدی، بعد دستور بعدی... یعنی یک زنجیره از عملیات که یکی پس از دیگری انجام می‌شوند. هرچند این کار با سرعت بسیار زیادی انجام می‌شود، اما همچنان عملیات به‌صورت پشت سر هم اجرا می‌شوند. اما FPGA به این روش کار نمی‌کند. تراشه FPGA با یک صف از دستورالعمل‌ها کار نمی‌کند. در اینجا اگر مسئله شما نیاز داشته باشد که مثلا صد عملیات مختلف به طور هم‌زمان انجام شوند، کافی است صد مدار کوچک طراحی کنید تا همگی دقیقاً در یک لبه کلاک با هم کار کنند. هیچ عملیاتی منتظر دیگری نمی‌ماند. مثلاً یک فیلتر دیجیتال FIR با تعداد زیادی Tap را در نظر بگیرید. یک پردازنده باید تمام ضرب‌ها و جمع‌ها را یکی‌یکی انجام دهد تا در نهایت فقط یک نمونه خروجی تولید کند. اما در FPGA می‌توانید تمام ضرب‌کننده‌ها را کنار هم قرار دهید و در هر سیکل کلاک، یک نمونه جدید تحویل بگیرید؛ پشت سر هم و بدون وقفه. اینجا فقط بحث سریع‌تر شدن نرم‌افزار نیست. شما در حال استفاده از نوع کاملاً متفاوتی از سخت‌افزار هستید. اما یک مزیت مهم دیگر هم وجود دارد که به همان اندازه اهمیت دارد: رفتار کاملاً قابل پیش‌بینی (Determinism). در FPGA هر عملیات دقیقاً تعداد مشخصی سیکل کلاک طول می‌کشد. بنابراین همیشه دقیقاً می‌دانید چه اتفاقی در چه زمانی رخ خواهد داد. هیچ سیستم‌عاملی وجود ندارد که ناگهان کنترل پردازنده را در اختیار بگیرد و هیچ تأخیر تصادفی هم وجود ندارد. این دقیقاً همان چیزی است که سیستم‌های Real-Time به آن نیاز دارند: اینکه بتوانید با اطمینان بگویید: "این اتفاق دقیقاً بعد از این تعداد نانوثانیه رخ خواهد داد... هر بار، بدون استثنا." پردازش موازی سرعت مورد نیاز را ایجاد می‌کند. رفتار کاملا قابل پیش‌بینی، اطمینان کافی را. و سیستم‌های Real-Time به هر دوی آن‌ها نیاز دارند. ۲. می‌توانید هم‌زمان با همه قطعات جانبی ارتباط برقرار کنید. تراشه FPGA تعداد زیادی پایه ورودی و خروجی (I/O) در اختیار شما قرار می‌دهد. و نکته جالب اینجاست که تقریباً همه آن‌ها کاملاً در اختیار شما هستند. شما تصمیم می‌گیرید هر پایه چه کاری انجام دهد و حتی از چه استاندارد الکتریکی استفاده کند. این میزان از آزادی در دنیای سخت‌افزار بسیار کم‌نظیر است. اما ارزش واقعی آن زمانی مشخص می‌شود که این قابلیت را با پردازش موازی که در بخش قبل گفتیم ترکیب کنید. هر اینترفیس که طراحی می‌کنید مدار اختصاصی خودش را دارد. بنابراین دیگر فقط یک پردازنده نیست که مجبور باشد بین تمام قطعات جانبی نوبت‌بندی کند. هر وسیله سخت‌افزاری، مدار مخصوص خودش را دارد که دائماً مشغول رسیدگی به همان دستگاه است. فرض کنید FPGA به‌طور هم‌زمان در حال خواندن اطلاعات از دو ADC، دریافت تصویر از یک دوربین، راه‌اندازی یک نمایشگر، و برقراری ارتباط با چندین تراشه دیگر از طریق SPI، I²C و UART باشد. همه این کارها به‌صورت هم‌زمان انجام می‌شوند و هیچ‌کدام منتظر دیگری نمی‌ماند. به همین دلیل است که یک FPGA می‌تواند به مرکز کنترل و فرمان یک سیستم بزرگ تبدیل شود. هم‌زمان ده‌ها ارتباط را مدیریت می‌کند، بدون اینکه حتی یکی از آن‌ها را از دست بدهد. ۳. بعد از ساخت هم می‌توانید سخت‌افزار را تغییر دهید. این همان بخشی است که معمولاً بیشتر افراد را در ابتدای آشنایی با FPGA شگفت‌زده می‌کند. یک FPGA مجبور نیست تا آخر عمر فقط یک نوع سخت‌افزار باشد. کافی است یک طراحی جدید روی آن بارگذاری کنید. همان تراشه فیزیکی، بدون اینکه حتی یک سیم جابه‌جا شود، به یک سخت‌افزار کاملاً متفاوت تبدیل می‌شود. به همین دلیل FPGA محبوب‌ترین ابزار برای نمونه‌سازی (Prototyping) است.

هفته گذشته یک سؤال بسیار خوب از طرف یکی از شرکت کنندگان در دوره طراحی دیجیتال با FPGA مطرح شد که فکر کردم ارزش دارد با شما هم به اشتراک بگذارم، چون تقریباً هر مهندس FPGA دیر یا زود با این موضوع روبه‌رو می‌شود. یکی از شرکت کنندگان به‌تازگی فصل پنجم دوره طراحی دیجیتال را به پایان رسانده بود. او یک ALU با استفاده از Process ساخته بود و برای شبیه‌سازی، تمام ترکیب‌های ورودی را به صورت دستی در یک تست بنچ نوشته و خروجی‌ها را یکی‌یکی بررسی کرده بود. خوب برای یک ALU با فقط هشت دستورالعمل روش کاملا معقولی برای تست انتخاب کرده بود. اما بعد سؤالی پرسید که دقیقاً مرز بین یک مبتدی و یک مهندس را مشخص می‌کند: "اگر این ALU به‌جای چند عملکرد ساده، ۱۰۰۰ عملکرد مختلف داشت چه؟ نوشتن همه حالت‌ها و بررسی دستی تمام خروجی‌ها هم زمان‌بر است و هم احتمال خطا دارد. در عمل چطور چنین سیستمی را تست می‌کنید؟" سوال بسیار خوبی است و پاسخ ساده آن این است: شما این کار را دستی انجام نمی‌دهید. هیچ‌کس انجام نمی‌دهد. در عمل این مسئله به شکل دیگری حل می‌شود. برای ماژول‌های محاسباتی مانند ALU، فیلترها یا هر بلوک پردازش سیگنال دیگر، معمولاً از روشی به نام Model-Based Verification استفاده می‌کنیم. به‌جای اینکه سعی کنید تمام سناریوهای ممکن را به‌صورت دستی بررسی کنید، ابتدا یک مدل سطح بالا از ماژول خود می‌سازید. این مدل معمولاً در MATLAB، Simulink، Python یا C پیاده‌سازی می‌شود. سپس یک بردار ورودی (Input Vector) تولید می‌کنید که تمام شرایط و Corner Caseهایی را که برایتان مهم هستند پوشش دهد. این بردار را به مدل اعمال می‌کنید و هم ورودی‌ها و هم خروجی‌های تولیدشده را در فایل‌های متنی ذخیره می‌کنید. این خروجی‌ها به عنوان مرجع یا همان Golden Reference شما عمل می‌کنند. در مرحله بعد، دقیقاً همان ورودی‌ها را از طریق Testbench به ماژول VHDL خود اعمال می‌کنید و خروجی‌های VHDL را نیز در فایل جداگانه‌ای ذخیره می‌کنید. در نهایت دو مجموعه خروجی را با هم مقایسه می‌کنید. اگر نتایج یکسان باشند، می‌توانید با اطمینان زیادی بگویید که پیاده‌سازی HDL شما از نظر منطقی صحیح است. و اگر تفاوتی وجود داشته باشد، همان اختلاف‌ها مستقیماً شما را به محل خطا هدایت می‌کنند. این روش در پروژه‌های DSP و FPGA بسیار رایج است و دقیقاً همین رویکرد را زمانی که وارد پروژه‌های پردازش سیگنال شوید خواهید دید. بعد از آن، شرکت کننده ما یک سؤال بسیار جالب‌تر مطرح کرد: "برای تست یک ماژول اینترفیس مثل Ethernet MAC، چه کار می‌کنیم؟ آیا باید کل جریان داده را تولید کنیم و بعد رجیسترها و انتقال داده‌ها را در سمت دیگر بررسی کنیم؟ آیا این خودش تقریباً یک پروژه جداگانه نیست؟" و پاسخ این است که بله، دقیقاً همین‌طور است. در بسیاری از پروژه‌های اینترفیس، بازسازی کامل رفتار یک قطعه جانبی (peripheral) در محیط شبیه‌سازی می‌تواند از خود پروژه اصلی بزرگ‌تر و زمان‌برتر شود و معمولاً ارزش این حجم از تلاش را ندارد. بنابراین کاری که در عمل انجام می‌دهیم این است: تا جایی که منطقی و مقرون‌به‌صرفه باشد شبیه‌سازی انجام می‌دهیم و سپس به سراغ تست روی سخت‌افزار واقعی می‌رویم. برای مثال Ethernet را در نظر بگیرید. در اکثر طراحی‌ها ما از یک چیپ Ethernet Controller استفاده می‌کنیم که خودِ پروتکل Ethernet را پیاده‌سازی کرده است. تراشه FPGA از طریق یک رابط ساده‌تر مانند SPI با آن ارتباط برقرار می‌کند. این ارتباط SPI را می‌توان به‌طور کامل در شبیه‌سازی تست کرد، چون هر دو طرف آن به‌راحتی قابل مدل‌سازی هستند. اما ساختن یک محیط شبیه‌سازی کامل که تمام رفتارهای Ethernet را با دقت بازسازی کند، ممکن است به حجم بسیار زیادی از کار نیاز داشته باشد. در چنین شرایطی، تست روی سخت‌افزار واقعی بسیار منطقی‌تر و عملی‌تر است. اینجاست که ابزارهایی مانند ChipScope (یا ILA در Vivado) فوق‌العاده ارزشمند می‌شوند. این ابزارها به شما اجازه می‌دهند در حالی که طراحی روی FPGA در حال اجراست، سیگنال‌های داخلی FPGA را مشاهده کنید و سیستم را به‌صورت زنده و در زمان واقعی بررسی و دیباگ کنید. یکی از مهم‌ترین درس‌هایی که با کسب تجربه یاد خواهید گرفت این است که مهندسی به معنای شبیه‌سازی همه چیز نیست. بلکه به معنای انتخاب مناسب‌ترین استراتژی درستی آزمایی برای مسئله‌ای است که در حال حل آن هستید. گاهی این یعنی ساختن یک مدل ریاضی به‌عنوان مرجع. گاهی یعنی طراحی یک Testbench پیشرفته و دقیق. و گاهی هم یعنی اتصال FPGA به سخت‌افزار واقعی و استفاده از ابزارهای دیباگ برای مشاهده آنچه درون تراشه اتفاق می‌افتد. اینکه بدانید در هر شرایطی کدام رویکرد مناسب‌تر است، بخشی از مسیر تبدیل شدن به یک طراح FPGA حرفه‌ای و مؤثر است. 🆔 @FPGA0

🔷 در 12 سال گذشته، عمده ارتباط من و مخاطبانم از طریق ایمیل و پس از آن از طریق کانال تلگرام بوده است. در این مدت، صدها ایمیل ارسال شدند اما بعضی از آنها بسیار مورد توجه واقع شدند. تصمیم گرفتم از این به بعد، این نوع ایمیل ها را عینا در اینجا هم قرار بدهم تا افرادی که در لیست ایمیل ما نیستند هم بتوانند از آنها استفاده کنند. ایمیلی که در ادامه قرار می دهم، امروز ارسال شده است 👇🏻 🆔 @FPGA0

⚡️ سلام، در چند ماه گذشته، امکان برقراری ارتباط از طریق کانال های اصلی ما یعنی ایمیل و تلگرام به شدت محدود بود. با توجه به تمام اتفاقاتی که در این مدت رخ داده، بسیار مشتاقم بدانم آیا در این مدت، یادگیری FPGA را پیگیری کردید؟ لطفا در بخش کامنت همین پست، نظرات خودتان را بنویسید. 🆔 @FPGA0

⚫️ یادآوری... 📣 تخفیف ۳۵ درصدی به مناسبت روز مهندس ❇️ این تخفیف‌ها به طور خودکار در سایت اعمال شده‌اند و نیازی به وارد کردن کد نیست 👇 🌎 https://faradandish.com/courses/ 🆔 @FPGA0

📣 فقط تا ساعت ۲۳:۵۹ دقیقه امشب... ❇️ برای استفاده از پیشنهادات ویژه شب یلدا روی لینک زیر کلیک کنید: 🌎 https://faradandish.com/courses/ 🆔 @FPGA0