Високооплачувані поради для інженерів FPGA, які заробляють 700 тис. на рік

Для інженерів FPGA, які хочуть отримати високу зарплату, є кілька ключових стратегій, які слід розглянути. Перш за все, вирішальним є вдосконалення ваших навичок проектування та розробки FPGA. Ставши фахівцем у таких мовах, як Verilog і VHDL, а також опанувавши інструменти та платформи розробки FPGA, ви станете цінним активом у цій галузі.

Минуло більше десяти років з тих пір, як я вперше познайомився з FPGA під час навчання в університеті. Я досі пам’ятаю хвилювання, коли вперше проходив такі експерименти, як цифрові секундоміри, зумери вікторин і блокування паролями на платформі EDA. На той час я ще не мав контакту з мовами опису апаратного забезпечення HDL, тому проекти були побудовані з використанням логічних пристроїв серії 74 у схемному середовищі MAX+plus II. Пізніше, під час навчання в аспірантурі та подальшої роботи, я використовував Quartus II, Foundation, ISE та Libero, а також вивчив мову Verilog HDL. Завдяки цьому процесу навчання я поступово оцінив кмітливість Verilog. Я зрозумів, що невеликий фрагмент коду може завершити складні схеми, а мобільність і працездатність мови були набагато сильнішими, ніж у схематичних конструкцій.

Важливість стандартів у логіці FPGA

Друзі, які працювали в галузі, знають, що компанії наголошують на стандартах, особливо для великих проектів (програмного чи апаратного забезпечення). Цього практично неможливо досягти без дотримання стандартів. Логічне проектування не є винятком: якщо ви не дотримуєтесь стандартів, ви можете виявити помилки при налагодженні через місяць. Озираючись на код, який ви написали, ви, можливо, забули багато функцій сигналу, не кажучи вже про перевірку помилок. Якщо хтось залишить проект на півдорозі, наступнику, ймовірно, доведеться починати дизайн з нуля. Якщо вам потрібно додати нові функції до оригінальної версії, вам, швидше за все, доведеться починати спочатку, що ускладнить повторне використання дизайну.

З точки зору логіки, я вважаю важливими такі стандарти:

1. Проектна документація: Ідеї дизайну, детальна реалізація тощо повинні бути записані в документи, і лише після ретельного розгляду та затвердження можна виконувати наступний крок роботи. Такий підхід може підтримувати проект у контрольованому та досяжному стані.
2. Стандартизація коду: стандартизуйте імена сигналів, використовуйте малі літери для імен сигналів і великі літери для параметрів, позначайте ефективні сигнали низького рівня за допомогою _n в кінці (наприклад, rst_n), і організуйте сигнали портів по одному сигналу на рядок для легшого виявлення помилок під час перевірки симуляції.
3. Управління доменом Clock: використовуйте лише один тактовий сигнал для кожного модуля та використовуйте спеціальний модуль для ізоляції тактового домену в проектах, що включають кілька тактових доменів, щоб дозволити синтезатору синтезувати більш оптимальний результат.
4. Уникайте комбінаторної логіки для засувок: У конструкціях FPGA заборонено використовувати чисту комбінаторну логіку для створення фіксаторів. Допускаються засувки з D-тригерами, наприклад, регістри конфігурації.
5. Синхронізація сигналу: Як правило, сигнали, що надходять на FPGA, повинні бути спочатку синхронізовані, щоб збільшити робочу частоту системи.
6. Зареєструвати всі виходи: Усі виходи модуля повинні бути зареєстровані для збільшення робочої частоти та досягнення збіжності синхронізації в проекті.
7. Уникайте закритих годинників: Якщо це не малопотужна конструкція, не використовуйте закриті годинники, оскільки це збільшить нестабільність конструкції.
8. Сигнали ввімкнення годинника: Забороняється використовувати сигнали, розділені лічильниками, як годинники для інших модулів. Замість цього використовуйте сигнали включення годинника.

Дизайн синхронізації для високої продуктивності

Мій бос має досвід роботи в Huawei і Junlong, тож, природно, він розповів нам про деякі практики логічного проектування в Huawei і Altera. Наші стандарти проекту в основному базуються на практиці Huawei. За останні кілька місяців роботи на мене найглибше враження справила приказка Huawei: час розробляється, а не моделюється чи вигадується. У нашій компанії кожен проект проходить сувору перевірку. Тільки після проходження перевірки можна приступати до наступного етапу роботи. Розглянемо як приклад логічний дизайн, замість того, щоб почати писати код одразу, нам спочатку потрібно написати загальний план дизайну та детальний план логічного проектування. Коли ці плани будуть розглянуті та визнані здійсненними, можна починати кодування. Загалом час, витрачений на виконання цих завдань, набагато більше, ніж час, витрачений на кодування.

Загальний план головним чином включає поділ модулів, сигнали інтерфейсу та синхронізацію модулів першого та другого рівнів, а також те, як тестувати дизайн у майбутньому. На цьому рівні плану важливо переконатися, що синхронізація збігається з модулем першого рівня (і, нарешті, з модулем другого рівня). Що це означає? Коли ми будемо робити детальне проектування, ми обов’язково внесемо певні корективи в синхронізацію деяких сигналів. Однак ці коригування часу можуть щонайбільше вплинути на модуль першого рівня, а не на весь дизайн. Я пам’ятаю, коли я навчався в школі, тому що я не розумівся на розробці синхронізації, мені часто доводилося регулювати синхронізацію сигналів інших модулів, оскільки синхронізація одного сигналу не відповідала, що дуже засмучувало.

У детальному плані розробки логіки ми вже розробили синхронізацію інтерфейсу кожного рівня модулів, і в основному визначено, як реалізовано кожен рівень модулів. Оскільки ми досягли цього, кодування природно стає швидшим. Найважливіше те, що цей підхід може підтримувати дизайн у контрольованому стані та запобігати необхідності починати весь дизайн заново через помилки в одному місці.

Які фактори впливають на робочу частоту кола?

Робоча частота схеми в основному пов'язана із затримкою поширення сигналу між регістрами та перекосом годинника. Якщо тактовий сигнал у ПЛІС працює вздовж довгих ліній, перекіс тактового сигналу дуже малий і ним можна ігнорувати. Тут для простоти розглядаються лише фактори, що впливають на затримку поширення сигналу. Затримка поширення сигналу включає затримку відкриття та закриття регістра, затримку маршрутизації та затримку через комбінаторну логіку. Щоб збільшити робочу частоту схеми, нам потрібно попрацювати над цими трьома затримками і зробити їх якомога меншими.

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 відносно добре справляється з перевіркою моделювання в Китаї. Вони створили відносно хорошу платформу перевірки, і більшість BFM, пов’язаних із комунікацією, виконані добре. Я почув від свого друга, що тепер їм потрібно лише поставити тестовий пристрій на тестову платформу та налаштувати параметри, щоб автоматично визначити, чи правильно функціонує тестований пристрій.

Мовні міркування

Щодо мов HDL, багато людей у ​​Китаї сперечаються про те, що краще між VHDL та Verilog. Насправді, особисто я вважаю, що це не має сенсу. Більшість великих компаній за кордоном в основному використовують Verilog для коду рівня RTL, тому я все одно рекомендую всім вивчити Verilog якомога більше. З точки зору симуляції, оскільки VHDL слабший, ніж Verilog, у поведінковому моделюванні, існує дуже мало імітаційних моделей, створених за допомогою VHDL. Звичайно, Verilog також не ідеальний. Фактично можливості Verilog у складному моделюванні поведінки також обмежені. Наприклад, він ще не підтримує масиви. У деяких складних схемах алгоритмів мови високого рівня необхідні для абстракції для опису поведінкових моделей. В інших країнах багато симуляційних моделей виконуються з використанням мов SystemC і E, а використання Verilog вважається застарілим. Платформа перевірки Huawei в Китаї, здається, написана на SystemC.

Майбутні перспективи

Що стосується проектування архітектури системи, оскільки проект, над яким я працюю, недостатньо великий, я ще не маю великого досвіду. Я просто відчуваю, що я повинен мати певні знання про архітектуру комп’ютерної системи. Основною основою для поділу є функціональність, а потім вибір відповідної структури шини, структури зберігання та архітектури процесора. Поділ архітектури системи має зробити кожен функціональний модуль зрозумілим і простим у реалізації. Я думаю, що через деякий час я поділюся деякими ідеями, коли маю невеликий досвід у цій частині, тож поки що не вводитиму вас в оману.

Особисті думки

Нарешті, дозвольте мені коротко підсумувати. Усе зводиться до додаткової практики, більше роздумів і додаткових запитань. Практика робить досконалим. Краще потренуватися самому, ніж сто разів читати чужі рішення. Мотивація до практики походить частково від інтересу, а частково від тиску. Особисто я вважаю, що останнє важливіше. Наявність вимог легко створить тиск, тобто найкраще практикуватися в реальній розробці проекту, а не навчатися заради навчання.

У процесі практики варто більше думати і думати про причини проблем. Розв’язавши задачі, ще кілька разів запитайте чому. Це теж процес накопичення досвіду. Якщо у вас є звичка писати журнали проекту, це ще краще. Запишіть у ньому проблеми, причини, шляхи вирішення та способи вирішення. Нарешті, ставте більше запитань. Якщо ви не можете вирішити проблему, подумавши про неї, запитайте. Адже індивідуальні можливості обмежені. Запитайте однокласників, колег, пошукових систем і користувачів мережі. Стаття або поради друзів можуть допомогти вам швидко вирішити проблеми.

Висновок

Після функціонального моделювання, оскільки ми проектуємо в FPGA, код рівня RTL в основному гарантовано узгоджується з результатом синтезу та результатом функціонального моделювання під час проектування. Поки статичний звіт про синхронізацію після макета синтезу не попереджає про порушення часових обмежень, ми можемо перейти до налагодження на платі. Насправді Huawei та ZTE також не проводять симуляцію синхронізації під час проектування FPGA, оскільки симуляція синхронізації займає багато часу, і ефект не обов’язково кращий, ніж перегляд звіту аналізу статичного часу.

Звичайно, якщо це дизайн ASIC, робоче навантаження на верифікацію симуляції більше. Коли йдеться про проектування домену з декількома годинниками, зазвичай виконується постсимуляція. Однак перед виконанням пост-симуляції зазвичай використовуються формальні інструменти перевірки, а також використовується звіт про аналіз статичного часу для перевірки будь-яких порушень вимог до проекту. Після цього робоче навантаження після моделювання може бути набагато меншим.

Якщо ця вимога впливає на постачання або випуск продукції, порівняйте її з постачанням електронних компонентів та порівнянням якості поверхні, перш ніж надсилати остаточні файли на розгляд.