Як прискорити проектування систем на кристалі
( https://www.semiwiki.com/forum/content/4965-improve-soc-front-end-design-productivity.html )
Про свій досвід розробки мікросхем на рівні RTL ділиться Кан Кібріа, що працює в цій галузі більше 30 років.
Три фактори: складність функціональності, брак однаковості в проекті і поточні зміни у вимогах є основними факторами, що гальмують проектування мікросхем.
Складові блоки проекту системи на кристалі (СНК) – віртуальні модулі (IP), можуть поставлятися з різних джерел. Ці модулі, як правило, використовуються повторно в різних проектах. Але стиль їх опису, імена портів і сигналів різняться в залежності від місця їх походження. Відсутність однаковості в подібних ситуаціях збільшує потреби в ресурсах і має негативний вплив на вартість.
Як правило, вимоги до проекту, які диктуються ринком, змінюються кілька разів під час його циклу проектування. І адаптація до них суттєво впливає на терміни і вартість проекту. Тому зараз працюють над засобами проектування, в яких зміни параметрів проекту менше позначаються на збільшенні термінів його виконання і вартості.
Через підвищену складність функціональності віртуального модуля потрібен додатковий час для його вбудовування в систему на кристалі. Включення в систему блоку, описаного на рівні регістрів – це нетривіальне завдання. Згадаймо як з’явився такий опис мовою опису апаратури (HDL).
Коли з’явилися HDL, багато розробників неохоче їх приймали через відсутність надійних інструментів синтезу логічних схем. Але тоді проектування велося на рівні вентилів і мікросхеми були вельми простими. Робота проектувальника була надто стомлюючою і нецікавою. Мови Verilog та VHDL, що з’явилися тоді, мали зручності і недоліки, але розробка на рівні регістрових передач дала великі перспективи для творчості. А головне, набагато збільшилася продуктивність проектувальників.
Тепер історія повторюється. Набирає обертів високорівневий синтез (HLS), у якого вже багато прихильників і який спрощує реалізацію складних алгоритмів. Але складність функціональності залишається чинником, що гальмує проектування мікросхем. Розглянемо причини цього.
Велика кількість міжз’єднань.
Міжз’єднання пронизують проект знизу доверху через його рівні ієрархії.
Якщо міжз’єднаня різнорідні, то їх включення займає багато часу, причому досить легко зробити помилку з’єднання. Правда, групування з’єднаннь у інтерфейси і використання перевірених протоколів зв’язку спрощує цей процес. Але в складному проекті таких інтерфейсів багато і вони різнорідні, отже, неможливо приєднати пристрій з одним інтерфейсом замість іншого.
У цьому питанні зручно використовувати конструкцію record з мови VHDL, щоб об’єднати кілька різнорідних сигналів у групу, абстрагувавшись від окремих сигналів. Аналогічні можливості з’явилися в System Verilog і нових засобах високорівневого проектування.
Однак у будь-якій СНК стоїть кілька IP, описаних різними мовами і різними стилями. Об’єднання їх у систему робиться виснажливим. Цей процес можна автоматизувати. Але для IP повинен супроводжуватися метаданими, що описують всі з’єднання і протокол обміну даними. Такий підхід міг би істотно підвищити продуктивність розробників і зменшити ймовірність помилок в проекті.
Нещодавно з’явився стандарт 1685 IEEE, в якому дається формат IP-XACT, який забезпечує XML-опис метаданих. Все більше постачальників засобів САПР забезпечують підтримку IP-XACT. В результаті, все більше продавців IP також надають IP-XACT-файли для своїх IP.
Формат IP-XACT-цілком всеосяжний, але складний. Він розглядає широкий спектр потреб міжз’єднань, заснованих на протоколах. Формат XML призначений для полегшення машиного читання специфікацій. Так що IP-XACT – файли важко складати вручну.
Тому засобам САПР необхідна якась інша мова або графічні засоби для простого опису метаданих до міжз’єднань і інтерфейсів, з яким зручно було б працювати людині. Простота є потужним фактором збільшення продуктивності.
Проектування додаткової логіки.
Дуже часто, щоб з’єднати різнорідні IP, необхідно додати додаткову логіку, яка «склеює» їх між собою (glue logic). Розробники витрачають на це дуже багато часу. Така логіка зазвичай нескладна, але можуть бути виключення.
Якби з’явилися засоби САПР, орієнтовані на таку логіку, то вони б набагато прискорили процес проектування. Така логіка могла б впроваджуватися в проект на поведінковому рівні, щоб мати можливість промоделювати його на ранніх стадіях проектування. Пізніше вона замінялася б своєю конкретною RTL-реалізацією.
Настроювані віртуальні модулі.
На жаль, зараз мало використовуються IP, які можна налаштувати під конкретну мікросхему. Якби таких IP було більше, то збільшилося б число їх повторних використань, а значить, зменшився час на їх освоєння і адаптацію. Хотілося б бачити такі настроювані IP, як буфери, що підключаються до виводів мікросхем, а також засоби вбудованого тестування.