نصائح عالية الأجر لمهندسي FPGA الذين يكسبون 700 ألف سنويًا

بالنسبة لمهندسي FPGA الذين يتطلعون إلى الحصول على راتب مرتفع، هناك العديد من الاستراتيجيات الرئيسية التي يجب مراعاتها. أولاً وقبل كل شيء، يعد صقل مهاراتك في تصميم وتطوير FPGA أمرًا بالغ الأهمية. إن كونك خبيرًا في لغات مثل Verilog وVHDL، بالإضافة إلى إتقان أدوات ومنصات تطوير FPGA، سيجعلك من الأصول القيمة في هذا المجال.

لقد مرت أكثر من عشر سنوات منذ أن اتصلت لأول مرة بـ FPGA خلال أيام دراستي الجامعية. ما زلت أتذكر الإثارة الناتجة عن إكمال تجارب مثل ساعات التوقف الرقمية، وصفارات الاختبار، وأقفال كلمة المرور على منصة EDA لأول مرة. في ذلك الوقت، لم أتعرض بعد للغات وصف أجهزة HDL، لذلك تم إنشاء التصميمات باستخدام أجهزة منطقية من سلسلة 74 في البيئة التخطيطية MAX+plus II. لاحقًا، أثناء دراستي العليا وعملي اللاحق، استخدمت Quartus II وFoundation وISE وLibero، وتعلمت أيضًا لغة Verilog HDL. من خلال عملية التعلم هذه، أصبحت أقدر تدريجيًا ذكاء فيريلوج. أدركت أن جزءًا صغيرًا من التعليمات البرمجية يمكن أن يكمل تصميمات تخطيطية معقدة، وكانت قابلية نقل اللغة وقابليتها للتشغيل أقوى بكثير من تلك الخاصة بالتصميمات التخطيطية.

أهمية المعايير في التصميم المنطقي FPGA

يعرف الأصدقاء الذين عملوا في الصناعة أن الشركات تؤكد على المعايير، خاصة بالنسبة للتصميمات الكبيرة (سواء كانت برمجيات أو أجهزة). يكاد يكون من المستحيل تحقيقه دون اتباع المعايير. التصميم المنطقي ليس استثناءً: إذا لم تتبع المعايير، فقد تجد أخطاء عند تصحيح الأخطاء بعد شهر. بالنظر إلى الكود الذي كتبته، ربما تكون قد نسيت العديد من وظائف الإشارة، ناهيك عن التحقق من الأخطاء. إذا غادر شخص ما منتصف الطريق خلال المشروع، فمن المحتمل أن يضطر الخلف إلى بدء التصميم من الصفر. إذا كنت بحاجة إلى إضافة ميزات جديدة إلى الإصدار الأصلي، فمن المرجح أن تبدأ من جديد، مما يجعل من الصعب تحقيق إمكانية إعادة استخدام التصميم.

من الناحية المنطقية، أعتقد أن المعايير التالية مهمة:

1. توثيق التصميم: يجب كتابة أفكار التصميم والتنفيذ التفصيلي وما إلى ذلك في المستندات، ولا يمكن تنفيذ الخطوة التالية من العمل إلا بعد المراجعة والموافقة الصارمة. هذا النهج يمكن أن يبقي المشروع في حالة يمكن السيطرة عليها وتحقيقها.
2. توحيد الكود: توحيد تسمية الإشارة، واستخدام الأحرف الصغيرة لأسماء الإشارات والأحرف الكبيرة للمعلمات، ووضع علامة على الإشارات الفعالة ذات المستوى المنخفض _n في النهاية (على سبيل المثال، rst_n)، وترتيب إشارات المنفذ بإشارة واحدة لكل سطر لتسهيل اكتشاف الأخطاء في التحقق من المحاكاة.
3. إدارة المجال على مدار الساعة: استخدم ساعة واحدة فقط لكل وحدة، واستخدم وحدة مخصصة لعزل نطاق الساعة في التصميمات التي تتضمن مجالات ساعة متعددة للسماح للمركب بتجميع نتيجة أكثر مثالية.
4. تجنب المنطق التوافقي للمزالج: في تصميمات FPGA، يُمنع استخدام المنطق التوافقي الخالص لإنشاء المزالج. يُسمح بالمزالج ذات الوجه المتأرجح على شكل حرف D، مثل سجلات التكوين.
5. مزامنة الإشارة: بشكل عام، يجب مزامنة الإشارات التي تدخل إلى FPGA أولاً لزيادة تردد عمل النظام.
6. تسجيل كافة المخرجات: يجب تسجيل جميع مخرجات الوحدة لزيادة تردد العمل وتحقيق تقارب التوقيت في التصميم.
7. تجنب الساعات المسورة: ما لم يكن التصميم منخفض الطاقة، لا تستخدم الساعات المسورة، لأن ذلك سيزيد من عدم استقرار التصميم.
8. إشارات تمكين الساعة: يمنع استخدام الإشارات المقسمة على العدادات كساعات للوحدات الأخرى. بدلاً من ذلك، استخدم إشارات تمكين الساعة.

تصميم التوقيت للأداء العالي

يتمتع مديري بخبرة في العمل في Huawei وJunlong، لذلك من الطبيعي أن يخبرنا عن بعض ممارسات التصميم المنطقي في Huawei وAltera. تعتمد معايير مشروعنا بشكل أساسي على الممارسات المتبعة في شركة Huawei. في الأشهر القليلة الماضية من العمل، كان الانطباع الأعمق بالنسبة لي هو القول المأثور في شركة هواوي: التوقيت مصمم، وليس محاكاته أو اختلاقه. في شركتنا، يخضع كل مشروع لمراجعة صارمة. فقط بعد اجتياز المراجعة يمكن تنفيذ الخطوة التالية من العمل. بأخذ التصميم المنطقي كمثال، بدلاً من البدء في كتابة التعليمات البرمجية على الفور، نحتاج أولاً إلى كتابة خطة التصميم الشاملة وخطة التصميم المنطقي التفصيلية. بعد مراجعة هذه الخطط واعتبارها مجدية، يمكن أن يبدأ الترميز. بشكل عام، الوقت المستغرق في هذه المهام أكبر بكثير من الوقت المستغرق في البرمجة.

تتضمن الخطة الشاملة بشكل أساسي تقسيم الوحدات وإشارات الواجهة وتوقيت وحدات المستوى الأول والثاني وكيفية اختبار التصميم في المستقبل. في هذا المستوى من الخطة، من المهم التأكد من أن التوقيت يتقارب مع وحدة المستوى الأول (وأخيرًا مع وحدة المستوى الثاني). ماذا يعني هذا؟ عندما نقوم بالتصميم التفصيلي، سنقوم بالتأكيد بإجراء بعض التعديلات على توقيت بعض الإشارات. ومع ذلك، يمكن أن تؤثر تعديلات التوقيت هذه على وحدة المستوى الأول، وليس التصميم بأكمله. أتذكر عندما كنت في المدرسة، لأنني لم أفهم تصميم التوقيت، كان علي في كثير من الأحيان ضبط توقيت إشارات الوحدة الأخرى لأنه لم يتم استيفاء توقيت إشارة واحدة، وهو أمر محبط للغاية.

في خطة التصميم المنطقي التفصيلية، قمنا بالفعل بتصميم توقيت الواجهة لكل مستوى من الوحدات، ويتم تحديد كيفية تنفيذ كل مستوى من الوحدات بشكل أساسي. ولأننا حققنا ذلك، أصبحت البرمجة أسرع بطبيعة الحال. والأهم من ذلك، أن هذا النهج يمكن أن يحافظ على التصميم في حالة يمكن التحكم فيها ويمنع الحاجة إلى بدء التصميم بالكامل من جديد بسبب حدوث أخطاء في مكان واحد.

ما هي العوامل التي تؤثر على تردد التشغيل للدائرة؟

يرتبط تردد عمل الدائرة بشكل أساسي بتأخير انتشار الإشارة بين السجلات وانحراف الساعة. إذا كانت الساعة في FPGA تعمل على طول خطوط طويلة، فإن انحراف الساعة يكون صغيرًا جدًا ويمكن تجاهله. ومن أجل التبسيط، لا تؤخذ في الاعتبار هنا سوى العوامل التي تؤثر على تأخير انتشار الإشارة. يتضمن تأخير انتشار الإشارة تأخير فتح وإغلاق السجل، وتأخير التوجيه، والتأخير من خلال المنطق التوافقي. لزيادة تردد عمل الدائرة، علينا العمل على هذه التأخيرات الثلاثة وجعلها صغيرة قدر الإمكان.

1. تقليل التأخير عن طريق تغيير التوجيه: تحديد مسار بعض الإشارات المهمة، مثل الساعات وإشارات التحكم، لجعلها تمر عبر FPGA أقل قدر ممكن. وهذا يمكن أن يقلل بشكل فعال من تأخير التوجيه.
2. تقليل عدد المنطق التوافقي: استخدم جداول البحث (LUT) قدر الإمكان بدلاً من البوابات المنطقية. بالإضافة إلى ذلك، يستخدم بعض الأشخاص سجلات متتالية لتقليل عدد البوابات، ولكن أفضل طريقة هي استخدام خطوط الأنابيب لتقليل عدد البوابات.

بشكل عام، يُعدّ تقليل عدد البوابات وتغيير مسار الإشارات من الطرق الفعّالة لزيادة تردد تشغيل الدائرة. وفي التصميم الفعلي، غالبًا ما يكون الجمع بينهما ضروريًا. مع ذلك، هذه ليست قاعدة مطلقة. ففي بعض الحالات، قد لا يُؤدي تغيير مسار الإشارات إلى تقليل التأخير، ويكون الحل الأمثل هو تقليل عدد البوابات.

تحديات التصميم المنطقي: هندسة النظام والتحقق من المحاكاة

عندما انضممت إلى الشركة لأول مرة، أخبرني مديري أن صعوبة التصميم المنطقي لا تكمن في تصميم التعليمات البرمجية على مستوى RTL، ولكن في تصميم بنية النظام والتحقق من المحاكاة. حاليًا، في الصين، هناك تركيز أكبر على التصاميم القابلة للتوليف، ولكن لا يبدو أن هناك الكثير من المعلومات حول تصميم بنية النظام والتحقق من المحاكاة، مما قد يعكس المستوى المنخفض نسبيًا للتصميم في الصين.

عندما كنت في المدرسة، اعتقدت دائمًا أنه طالما تم تنفيذ كود مستوى RTL بشكل جيد، فإن التحقق من المحاكاة كان مجرد إجراء شكلي، لذلك تجاهلت بازدراء صياغة الوصف السلوكي لـ HDL وكنت مترددًا في التعرف على مقاعد الاختبار - لأنني اعتقدت كان رسم الأشكال الموجية مناسبًا؛ لم أكن أعرف شيئًا عن تصميم بنية النظام. لم أدرك أن الأمر مختلف تمامًا إلا عندما واجهت بعض الأشياء في الشركة.

في الواقع، في البلدان الأجنبية، ربما يكون الوقت والجهد المبذولين في التحقق من المحاكاة ضعف ما يتم إنفاقه على التعليمات البرمجية على مستوى RTL. الآن، يعد التحقق من المحاكاة هو المسار الحاسم لتصميم شرائح المليون بوابة.

التحقق من المحاكاة: النمذجة والأتمتة

تكمن صعوبة التحقق من المحاكاة بشكل أساسي في كيفية النمذجة للتحقق بشكل كامل ودقيق من صحة التصميم (بشكل أساسي لزيادة تغطية الكود). وفي هذه العملية، تعتبر سرعة التحقق مهمة أيضًا.

والتحقق، بعبارات بسيطة، هو كيفية توليد تغطية كافية لمصادر التحفيز ثم اكتشاف الأخطاء. أنا شخصياً أعتقد أن الشيء الأساسي في التحقق من المحاكاة هو تحقيق أتمتة التحقق. ولهذا السبب أيضًا نحتاج إلى كتابة مقاعد الاختبار. في أحد تصميماتي الحالية، يستغرق الأمر حوالي ساعة لكل عملية محاكاة (وهو في الواقع تصميم صغير). نظرًا لأن رسم الأشكال الموجية لا يمكن أن يحقق أتمتة التحقق، إذا قمنا بالمحاكاة عن طريق رسم الأشكال الموجية، أولاً، سيتم رسم الشكل الموجي حتى الموت (خاصة بالنسبة للتصميمات ذات الخوارزميات المعقدة والتوزيع الإحصائي للمدخلات)، ثانيًا، سيكون النظر إلى الشكل الموجي مميتًا، وثالثًا، معدل اكتشاف الأخطاء هو ما يقرب من الصفر. فكيف نحقق الأتمتة؟ لا يزال مستواي محدودًا للغاية، لذا لا يمكنني التحدث إلا باختصار عن BFM (نموذج وظيفة الناقل).

بأخذ مثال إنشاء نواة MAC (اللوحة المعززة هي ناقل PCI)، نحتاج إلى MAC_BFM وPCI_BFM وPCI_BM (نموذج سلوك PCI). تتمثل الوظيفة الرئيسية لـ MAC_BFM في إنشاء إطارات Ethernet (مصادر التحفيز)، بأطوال ورؤوس إطارات عشوائية، كما أن المحتوى عشوائي أيضًا. أثناء الإرسال، يقوم أيضًا بنسخه إلى PCI_BM؛ تتمثل وظيفة PCI_BFM في محاكاة سلوك ناقل PCI، على سبيل المثال، عندما يتلقى الجهاز قيد الاختبار إطارًا صحيحًا، سيرسل طلبًا إلى ناقل PCI، وسوف يستجيب له PCI_BFM ويحضر البيانات؛ تتمثل الوظيفة الرئيسية لـ PCI_BM في مقارنة ما يرسله MAC_BFM مع ما يتلقاه PCI_BFM. نظرًا لأنه يحتوي على معلومات إرسال MAC_BFM ومعلومات استقبال PCI_BFM، طالما أن التصميم معقول، فيمكنه دائمًا اختبار ما إذا كان الجهاز قيد الاختبار يعمل بشكل طبيعي بشكل تلقائي وكامل، وبالتالي تحقيق الكشف التلقائي.

تشير التقديرات إلى أن أداء شركة Huawei جيد نسبيًا في مجال التحقق من المحاكاة في الصين. لقد أنشأوا منصة تحقق جيدة نسبيًا، وتم تنفيذ معظم آلية تلقي اقتراحات المستفيدين وملاحظاتهم وشكاويهم المتعلقة بالاتصالات بشكل جيد. سمعت من صديقي أنهم الآن يحتاجون فقط إلى وضع الجهاز قيد الاختبار في منصة الاختبار وتكوين المعلمات لاكتشاف ما إذا كان الجهاز قيد الاختبار يعمل بشكل صحيح تلقائيًا.

اعتبارات اللغة

فيما يتعلق بلغات HDL، يتجادل العديد من الأشخاص في الصين حول أيهما أفضل بين VHDL وVerilog. في الواقع، أنا شخصياً أعتقد أن هذا ليس له معنى كبير. تستخدم معظم الشركات الكبرى في الخارج Verilog بشكل أساسي للتعليمات البرمجية على مستوى RTL، لذلك ما زلت أوصي الجميع بتعلم Verilog قدر الإمكان. فيما يتعلق بالمحاكاة، نظرًا لأن VHDL أضعف من Verilog في النمذجة السلوكية، فهناك عدد قليل جدًا من نماذج المحاكاة التي يتم إجراؤها باستخدام VHDL. وبطبيعة الحال، فيريلوج ليست مثالية أيضا. في الواقع، قدرة Verilog في النمذجة السلوكية المعقدة محدودة أيضًا. على سبيل المثال، لا يدعم المصفوفات بعد. في بعض تصميمات الخوارزميات المعقدة، هناك حاجة إلى لغات عالية المستوى للتجريد لوصف النماذج السلوكية. في الدول الأجنبية، يتم إجراء العديد من نماذج المحاكاة باستخدام لغة SystemC وE، ويعتبر استخدام Verilog قديمًا. يبدو أن منصة التحقق الخاصة بشركة Huawei في الصين مكتوبة بلغة SystemC.

الآفاق المستقبلية

فيما يتعلق بتصميم بنية النظام، نظرًا لأن التصميم الذي أعمل عليه ليس كبيرًا بدرجة كافية، فليس لدي الكثير من الخبرة حتى الآن. أشعر فقط أنه يجب أن يكون لدي بعض المعرفة بهندسة نظام الكمبيوتر. الأساس الأساسي للتقسيم هو الوظيفة، يليها اختيار هيكل الناقل المناسب، وهيكل التخزين، وهندسة المعالج. يجب أن يجعل تقسيم بنية النظام كل وحدة وظيفية واضحة وسهلة التنفيذ. أعتقد أنني سأشارك بعض الأفكار بعد أن يكون لدي القليل من الخبرة في هذا الجزء بعد فترة، لذلك لن أقوم بتضليلك في الوقت الحالي.

رؤى شخصية

وأخيرا، اسمحوا لي أن ألخص بإيجاز. كل ذلك يعود إلى المزيد من الممارسة، والمزيد من التفكير، والمزيد من التساؤلات. مع التدريب يأتي الإتقان. من الأفضل أن تمارس ذلك بنفسك بدلاً من قراءة حلول الآخرين مائة مرة. يأتي الدافع للممارسة جزئيًا من الاهتمام وجزئيًا من الضغط. أنا شخصيا أعتقد أن الأخير هو أكثر أهمية. سيؤدي وجود المتطلبات إلى خلق الضغط بسهولة، أي أنه من الأفضل التدرب على تطوير المشروع الفعلي بدلاً من الدراسة من أجل الدراسة.

في عملية الممارسة، يجب عليك التفكير أكثر والتفكير في أسباب المشاكل. بعد حل المشكلات، اسأل لماذا عدة مرات. وهذه أيضًا عملية تراكم للخبرة. إذا كانت لديك عادة كتابة سجلات المشاريع، فهذا أفضل. - كتابة المشاكل والأسباب والحلول وطرق حلها. وأخيرا، طرح المزيد من الأسئلة. إذا لم تتمكن من حل مشكلة ما بعد التفكير فيها، فاسأل. بعد كل شيء، القدرات الفردية محدودة. اسأل زملاء الدراسة والزملاء ومحركات البحث ومستخدمي الإنترنت. قد تساعدك المقالة أو إرشادات الأصدقاء في حل المشكلات بسرعة.

خاتمة

بعد المحاكاة الوظيفية، نظرًا لأننا نقوم بالتصميم في FPGA، فإن الكود على مستوى RTL مضمون بشكل أساسي ليكون متسقًا مع نتيجة التوليف ونتيجة المحاكاة الوظيفية أثناء التصميم. طالما أن تقرير التوقيت الثابت بعد تخطيط التوليف لم يتم تحذيره من انتهاك قيود التوقيت، فيمكننا المضي قدمًا في تصحيح الأخطاء على اللوحة. في الواقع، في Huawei وZTE، لا يقومون أيضًا بمحاكاة التوقيت عند تصميم FPGA لأن محاكاة التوقيت تستغرق الكثير من الوقت والتأثير ليس بالضرورة أفضل من النظر إلى تقرير تحليل التوقيت الثابت.

وبطبيعة الحال، إذا كان تصميم ASIC، فإن عبء العمل للتحقق من المحاكاة يكون أكبر. عندما يتعلق الأمر بتصميم نطاق متعدد الساعات، يتم إجراء ما بعد المحاكاة بشكل عام. ومع ذلك، قبل إجراء ما بعد المحاكاة، عادةً ما يتم استخدام أدوات التحقق الرسمية ويستخدم تقرير تحليل التوقيت الثابت للتحقق من أي انتهاكات لمتطلبات التصميم. بعد القيام بذلك، يمكن أن يكون عبء العمل بعد المحاكاة أصغر بكثير.

إذا كان هذا الشرط يؤثر على التوريد أو إصدار الإنتاج، فقم بمقارنته مع توريد المكونات الإلكترونية ومقارنة تشطيب السطح قبل إرسال الملفات النهائية للمراجعة.