Оптимізація простору дизайну Synopsys досягає віхи

Оптимізація простору дизайну Synopsys досягає віхи

Вихідний вузол: 1948345

Нещодавно я розмовляв зі Стеліосом Діамантидісом (відомим архітектором, керівником відділу стратегії автономних дизайнерських рішень) про оголошення Synopsys про 100th клієнт tapeout за допомогою свого рішення DSO.ai. Мене хвилює стаття, пов’язана з штучним інтелектом, щоб уникнути ажіотажу, який оточує штучний інтелект загалом, і, навпаки, скептицизм у реакції на цей галас, що спонукає деяких відкидати всі заяви щодо штучного інтелекту як зміїну олію. Мені було приємно почути, як Стеліос сміється і щиро погоджується. У нас була дуже обґрунтована дискусія про те, що DSO.ai може робити сьогодні, що їхні базові клієнти бачать у рішенні (на основі того, що він може робити сьогодні) і що він може сказати мені про цю технологію.

Оптимізація простору дизайну Synopsys

Що робить DSO.ai

DSO.ai поєднується з Fusion Compiler і IC Compiler II, що, як підкреслив Стеліос, означає, що це рішення для оптимізації на рівні блоків; Повноцінні SoC ще не є ціллю. Це відповідає поточній практиці проектування, оскільки Стеліос сказав, що важливу мету легко вписати в існуючі потоки. Мета технології полягає в тому, щоб дозволити інженерам із впровадження, часто одному інженеру, підвищити свою продуктивність, одночасно досліджуючи більший простір проектування для кращого PPA, ніж можна було б виявити інакше.

Synopsys анонсувала першу запис влітку 2021 року, а зараз анонсувала 100 записів. Це добре говорить про попит і ефективність такого рішення. Стеліос додав, що значення стає ще більш очевидним для додатків, які повинні створювати екземпляри блоку багато разів. Подумайте про багатоядерний сервер, графічний процесор або мережевий комутатор. Оптимізуйте блок один раз, створіть екземпляр багато разів – це може призвести до значного покращення PPA.

Я запитав, чи всі клієнти, які роблять це, працюють на 7 нм і нижче. Дивно, але активно використовується аж до 40 нм. Одним із цікавих прикладів є контролер спалаху, конструкція якого не надто чутлива до продуктивності, але може працювати від десятків до сотень мільйонів одиниць. Зменшення розміру навіть на 5% тут може мати великий вплив на маржу.

Що під капотом

DSO.ai заснований на навчанні з підкріпленням, гарячою темою в наші дні, але я обіцяв, що в цій статті не буде галасу. Я попросив Стеліоса детальніше розібратися, але не здивувався, коли він сказав, що не може розкрити надто багато. Те, що він міг мені сказати, було досить цікавим. Він звернув увагу на те, що в більш загальних програмах один цикл навчання (епоха) передбачає швидкий (від секунд до хвилин) метод оцінки наступних можливих кроків, наприклад, через порівняння градієнтів.

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

З цією метою ця можливість дійсно повинна працювати в хмарі, щоб підтримувати паралелізм. Одним із варіантів є приватна локальна хмара. Microsoft оголосила, що вони розміщують DSO.ai на Azure, і ST повідомляє в прес-релізі DSO.ai, що вони використовували цю можливість для оптимізації реалізації ядра Arm. Я припускаю, що можуть виникнути цікаві дебати щодо переваг і недоліків оптимізації в загальнодоступній хмарі, наприклад, на 1000 серверах, якщо зменшення площі того варте.

Відгуки клієнтів

Synopsys стверджує, що клієнти (включаючи ST і SK Hynix у цьому оголошенні) повідомляють про підвищення продуктивності в 3 рази, зниження загальної потужності до 25% і значне зменшення розміру кристала, і все це з меншим використанням загальних ресурсів. Враховуючи те, що описав Стеліос, це звучить мені розумно. Інструмент дозволяє досліджувати більше точок у просторі стану проекту в рамках певного розкладу, ніж це було б можливо, якби це дослідження було ручним. Поки алгоритм пошуку (секретний соус) ефективний, це, звісно, ​​дозволить знайти кращий оптимум, ніж ручний пошук.

Коротше кажучи, ані шум ШІ, ані зміїна олія. DSO.ai припускає, що ШІ входить у мейнстрім як надійне інженерне розширення існуючих потоків. Ви можете дізнатися більше з прес-реліз і від цей блог.

Поділитися цим дописом через:

Часова мітка:

Більше від Semiwiki