Как компании, занимающиеся разработкой интегральных схем, создают свои таблицы данных?

Я работаю на крупного производителя микросхем, и у нас есть отдельный отдел, который занимается генерацией опубликованных версий спецификаций. Этот отдел отвечает за то, чтобы техническое описание имело правильный английский язык, использовало правильную отраслевую и корпоративную терминологию, соответствовало стандартам форматирования компании, не содержало текста, который может иметь негативные юридические последствия для компании, и т. д. Документ основан на XML.

До того, как этот отдел вмешается, инженер, отвечающий за спецификации продукта (обычно называемый «системным инженером» или аналогичный), ведет техническое описание. Первоначальное техническое описание обычно основано на продукте предыдущего поколения, поэтому большая часть информации уже создана. На протяжении всего процесса разработки системный инженер обновляет спецификации на основе данных, полученных от других инженеров-разработчиков (все инженеры-разработчики могут читать документ из центрального репозитория, но только системный инженер может записывать в него). В ходе этих обновлений многие инженеры получают возможность исправить как технические, так и орфографические/грамматические ошибки (поскольку они все равно просматривают техническое описание для своей работы). Эти инженеры также предоставляют системному инженеру данные для добавления в техническое описание (например, г. блок-схемы, принципиальные схемы приложений, захваты области действия и т. д.). Когда приходит время выпуска, инженеры-разработчики проводят окончательную проверку, чтобы убедиться, что все технические данные верны.

В этот момент подключается издательский отдел. Издательский отдел понятия не имеет, верны ли технические детали — их цель состоит в том, чтобы обеспечить правильность форматирования, правописания и т. д. Между издательским отделом и системным инженером происходят некоторые споры, поскольку обе стороны обеспечивают окончательный вариант. черновик технически верен, а также правильно отформатирован.

Резюмируя основные моменты:

• Спецификации основаны на спецификациях продуктов предыдущего поколения (или, по крайней мере, аналогичных продуктов), поэтому они не создаются полностью с нуля.
• Все инженеры в команде разработчиков читают и вносят свой вклад в таблицу данных, но фактическое редактирование таблицы данных контролируется одним инженером (системным инженером).
• Команда разработчиков несет ответственность за обеспечение технической точности технического описания.
• Отдельный отдел занимается форматированием, терминологией и т. д.

Это во многом зависит от корпоративной культуры, как подразумевал The Photon. В некоторых компаниях за техническое описание отвечает дизайнер(ы). В других случаях это инженер по приложениям. Я могу рассказать только о своем личном опыте. Вывод — разработка таблицы данных действительно неформальна.

Для чипов, над которыми я был ведущим инженером, я сам написал техническое описание с помощью Word. Первый черновик технического описания часто является первой частью спецификации микроархитектуры (MAS), которая пишется на ранней стадии процесса проектирования. В крупных компаниях, как сказал Нулл, этим занимается системный инженер. Там, где я работаю, дизайнер обычно несет ответственность (и берет на себя многие роли системного инженера). После того, как дизайн будет доработан, микросхема заклеена, и я жду вафли, я возьму начало МАСа, а затем сверну в предварительный даташит. Весь текст написан, и для всех сюжетов созданы симуляции. Это передается по группе для обратной связи.

Затем чипы возвращаются, и инженер по продукту их поднимает. Инженер-испытатель начинает измерения, и я заменяю все симуляции измеренными данными. Я также заменяю таблицу спецификаций реальными измеренными данными (иногда спецификации меняются после возвращения чипа, знаете ли!).

Затем, когда я считаю его законченным, я отправляю его нашему техническому писателю (у нас их всего несколько там, где я работаю), и он или она приводит его в стандартную форму.

Как сказал The Photon, в процессе проектирования используется множество специальных процедур. Раньше я использовал Excel для отслеживания контактных площадок и сигналов, теперь я использую Google Docs. Однако фактические данные DESIGN хранятся в специализированных базах данных, к которым обращаются дорогие инструменты САПР с контролем версий и так далее.

В местах, где я работал, инженеры передают документы Word во время разработки продукта. Обычно мы называем это «таблицей данных о цели». Затем технический писатель переформатирует все красиво, исправляет грамматику, перерисовывает диаграммы и т. д., чтобы создать документ, готовый для клиента.

Достаточно ли велики эти компании, чтобы они могли позволить себе иметь отделы, которые штампуют заказное программное обеспечение, базы данных и т. д., чтобы помочь им в процессе проектирования?

Хороший технический писатель может многое сделать с помощью Framemaker.

И для отслеживания функций 1000 выводов или 1000 регистров на самом деле не требуется специальная база данных. Такие вещи можно сделать с помощью Excel или даже Word.

Мне очень любопытно, потому что мне очень сложно сохранять единообразие данных/информации/спецификаций на протяжении всего процесса проектирования.

Полезно хранить только одну «основную» копию целевого листа данных. Исторически сложилось так, что в местах, где я работал, технический руководитель проекта держал его на своем рабочем столе. В настоящее время мы используем облачный сайт с инструментами для совместной работы, чтобы любой член команды мог читать или (возможно) редактировать актуальный документ в любое время.