Цитата:
Применяемая, в настоящее время, для проектирования СБИС, методология с использованием языков описания аппаратуры, обладает общепризнанными недостатками, а именно:
Разработка сложных СБИС требует сотни квалифицированных инженеров, несколько лет работы и затрат в миллиарды долларов.
До половины времени разработки, уходит на поиск и устранение ошибок в программной модели проектируемого микропроцессора.
Существенные трудозатраты требуются для достижения высоких характеристик по площади, производительности, энергетической эффективности.
Ну в целом да. Только последние два пункта еще и взаимосвязаны. Изменяя что-то в схеме, разработчики так или иначе изменяют и характеристики СБИС как таковой. Иногда существенно, причем основная причина - неполное понимание особенностей топологических библиотек. Добавить инвертор - ерунда. Сказать "а давайте это будет еще и DSP, поэтому ставим умножение с накоплением" - это огромный по меркам кристалла модуль с приличной задержкой и сложной трассировкой. Энергоэффективность вообще отдельная тема - в ПЛИС компоненты уже выбраны и имеют конкретные характеристики, а при проектировании СБИС один и тот же компонент можно реализовать в вариантах, отличающихся по энергетике и быстродействию на порядок.
Цитата:
Разработка СБИС становится частью инструментария разработчика программного обеспечения.
Каждая компания разработчик ПО, получает возможность разрабатывать СБИС.
Отчасти. Во-первых, опять-таки см. тему про защиту диссертации
Вот это именно часть такой методологии. Почему часть - потому что есть минимум два неправильных пути:
1. От схемы. Нарисовали, никого туда не пустили, получили кремний... пригласили программиста. Программист честно констатировал, что вот это вот все нежизнеспособно, и никакие "интересные изюминки", которые туда заложили схемотехники, на деле никак не работают. Особенно если задача стоит как "скомпилировать программу на С так, чтобы процессор начал ее ускорять теми компонентами, которые мы ему добавили".
2. От программы. По мере продвижения к кремнию (или к ПЛИС) высокоуровневые концепции начинают обретать реальное наполнение. Проблемы могут быть от "не бывает такого"/"электрический конфликт"/"конфликт доступа" до "занимает больше места, чем ожидалось и роняет тактовую частоту".
Поэтому первый пункт в целом верен, а во втором главное слово - "возможность". Например, у каждого человека есть возможность стать чемпионом мира по прыжкам в высоту или боксу.
Возможность.Цитата:
Поднять уровень абстракции при разработке аппаратуры:
a. Использовать языки более высокого уровня, например, C ++ вместо Verilog;
Ну да, или DSL.
Цитата:
Использовать инструменты высокоуровневого синтеза;
HLS, с вариантами C++/SystemC. Проблема в п.2 - реализация "расползается", чрезмерно абстрагированное описание дает возможность посмотреть на результаты выполнения операций, но детали различаются очень существенно. Разработка на HLS - это масса директив (#pragma) и постоянная игра с ними.
Цитата:
Применение методологии AGILE в разработке СБИС:
Ну это уже свое любимое человек вставил. Зависит от множества факторов. Особенно я бы посмотрел на непрерывную интеграцию - оно вполне может выглядеть как-то так:
https://xkcd.ru/303/Зачем вообще абстрагирование? Да как раз затем, чтобы выполнять больше итераций проектирования, не вдаваясь в несущественные на данном этапе детали (например, где конкретно на кристалле расположен сумматор в операции A + B и в каком слое металлизации проведены шины для подачи операндов).
Цитата:
И модульный подход к физическому проектированию СБИС основанный на мелкозернистом глобально асинхронном и локально синхронном (GALS) тактировании.
Да-да, как раз пример того, что на высоком уровне эти проблемы не видны. Нарисовать можно какую угодно большую СБИС, вот только развести тактовый сигнал по всему кристаллу потом не получится. Но это же не проблемы "эффективных и успешных высокоуровневых разработчиков", которые отрапортуют о получении замечательных характеристик и уйдут
портить делать другой проект.
Цитата:
При этом признаётся, что для достижения поставленных, программой IDEA, целей потребуется прорыв в алгоритмах машинного обучения и оптимизации.
Еще бы! Уж делали бы на базе оптимизированных компонентов, пусть с локальными оптимизациями. Но глобально - это даже не выиграть у человека в го. В го доска 19x19, и то не так давно компьютер выиграл у профессионала, а СБИС побольше будет.
Цитата:
обеспечивающих доверие к строительным блокам (IP блокам) аппаратного обеспечения с открытым исходным кодом.
Доверие и открытый код - разные вещи. Open - это не волшебное слово, гарантирующее чуть ли не подключение Мирового Разума к разработке. Собственно, opencores.org - в основном собрание негодных на практике, непроверенных и амбициозно "продвигаемых" проектов и проектиков. Огромные простыни кода никак не помогут осознать заложенную концепцию, архитектуру и проверить реализацию в строгом математическом смысле. Открытость тут видится как просьба "вы там нам дайте уж побольше всего, а то мы не справляемся".
Цитата:
Для широкого распространения также важно, чтобы технология обеспечения доверия на этом уровне требовала от пользователя минимальных (или нулевых) инженерных усилий.
Фантазии. Интеграция IP-блока в СБИС подтверждается физическим моделированием СБИС. Только так можно проверить системные эффекты (например, банальные наводки, локальный перегрев или проседание напряжения на сетке питания - мало ли по каким причинам). Если запуск пластины стоит очень дорого, то "размазанная" по безликому миру open source ответственность ничего хорошего не даст.
Цитата:
При этом не ожидается полное устранение ошибок: «Качество платформы моделирования по своей природе ограничено качеством используемых моделей системы и векторов испытаний, и вполне вероятно, что ряд критических ошибок будет пропущен».
Естественно!
Цитата:
Практика показала, что их текстовое описание не лучший способ представления, потому, в настоящее время, используются схемы алгоритмов, в частности визуальный язык ДРАКОН
Цитата:
В рамках проекта суперкомпьютера «Ангара», под руководством Эйсымонта Л.К., автор участвовал в разработке микропроцессора с массовым параллелизмом, где применялся метод схемного проектирования. Разработка микроархитектуры выполнялась одним человеком, обладавшим большим опытом схемотехнического проектирования. Применение схемного проектирования показало существенно меньшее количество ошибок, допускаемых человеком, при разработке микроархитектуры и схемотехнической реализации функций блоков. При этом, описание уже готовых схем, на языке Verilog, приводило к появлению ошибок, отсутствовавших в схемном описании.
Не суметь описать в RTL схему, представленную в графике - ну это надо больше тренироваться в RTL. Вообще-то RTL-представление в современных синтезаторах - основное. Все эти схемы - дань тому, что не все умеют писать на HDL. Так что "ошибки, отсутствовавшие в схемном описании" - на совести разработчика. Ну и подход Эйсымонта, мягко говоря, спорен. Не мягко не буду уточнять...
Цитата:
В дальнейшем, на основе когнитивно-эргономического подхода, был создан графический язык ДРАКОН. Применение его для создание различных ракетно-космических систем доказало эффективность идей, положенных в его основу
Вариант вредного для практической деятельности затуманивания мозгов читателям. Прежде всего - НИЧЕГО оно не "доказало". Оно просто показало, что конкретно в том проекте работали люди, персонально заинтересованные в таком подходе. Разве была какая-то конкуренция? Да нет, просто проекты такого уровня имеют массу ограничений, прежде всего организационно-бюрократических. Просто так нельзя даже ознакомиться с ходом работ, а уж предложить собственную реализацию - и подавно. Поэтому в космических технологиях (ну и в ядерных тоже, в силу специфики доступа туда) можно встретить результаты, объясняемые тем, что люди порезвились в свое удовольствие, потому что кроме них к проекту никто не был допущен. Что хотят доказать сторонники Дракона? Что для реализации проекта уровня космического корабля нужно освоить Дракон? Да нет, для такого проекта нужно иметь финансирование, коллектив и производственную базу... тогда даже вкрапления личных хобби-проектов ничего сильно не испортят