Здравствуйте.

Пристал начальник на предмет оформления документации на находящуюся в разработке прошивку для ПЛИС Xilinx.
В качестве образца дается нечто странное.

Ну будут ли так любезны присутствующие подсказать, есть ли какие-то правила оформления документации на это дело.
То есть,
1) промежуточная документация для взаимодействия с программистами и схемотехником
2) окончательная документация на разработанный и отлаженный проект

Есть ли на это какие-то ГОСТы, IEEEEEE, или прочие стандарты?

В проекте есть 1 штука ПЛИС Xilinx Spartan3, в ней система с Microblaze (+ программа на С) и кучка логики, написанной на Verilog.

Всем заранее спасибо .

Вот тут что то было.
В принципе есчё в гостах за 2008 год что то было, только нужно искать в них...

Спасибо .

какую же документацию в конце концов Вы предоставили?

В конце концов, когда я сказал начальнику, что на разработку документации надо столько-то времени, он сказал, что есть более приоритетные задачи .
Так что, предоставление отсрочилось на неопределенное время.

Так и живем...

А если так подумать, какую б документацию на выполненный проект Вы предоставили?
Естественно коды программ на HDL и С для микропроцессора - будут всегда. Кроме них, что?
Чтобы потом так например годика через N открыли, прочитали и все вспомнили что, зачем и как

PS Я спрашиваю из-за того что хотел бы узнать мысли людей по этому поводу.

Мы закладывали прошивку конфигурационных ПЗУ.
Как на обычные ПЗУ-шки. Файл на машинном носителе, лист ИПХ (это для магнитного архива, типа формуляра) и лист утверждения.
Исходники проекта - на совести разработчика и начальника.
Ну а в принципе, чем ПЛИС формально отличается от того же контроллера?
Так же и закладывать, как обычное встраиваемое/прошиваемое ПО.
Исходные тексты, бинарник, листы утверждения, спецификация.


Вы бы ещё сказали, пришёл человек с улицы, прочитал, всё понял и пошёл работать!
Я вот смотрю сейчас на свои проекты 2-летней давности и не могу понять - как я мог ТАКОЕ написать!

но все таки отличия есть... И Вы это прекрасно знаете



Как я понимаю именно для этого же и делается документация
Или нет, так для сбора макулатуры и подставок под чашки чая/кофе в виде CD/DVD

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

Я писал как-то методику тестирования ПЛИС. Там система связи была и проверялось смещение по доплеру и гауссовский шум.
Так вот было полное описание того, как все это тестируется вплоть до структурного описания каждого блока со схемой. В отдельной папке лежали несколько прошивок и готовые проекты под chipscop для разных прошивок, там же была приведена таблица с примерными результатами и графики. Был полностью описан порядок действия человека, который хочет проверить работоспособность системы связи начиная о того как прошить плисину и какие значения ввести в XMD чтоб задать некое соотношение сигнало/шум. Всю эту последовательность действий проводил студент третьего курса, который вообще в этом не разбирался, ну и данной методикой испытания вроде как уже два года пользуются

Это другой вид документации, не проектно-конструкторская, а эксплуатационно-сервисная.

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

Наверно сопроводительная документация, точно не скажу

В ЕСПД есть документ «Описание программы».
Напомню ГОСТ.
Описание программы должно содержать следующие разделы:

• общие сведения;
• функциональное назначение;
• описание логической структуры;
• используемые технические средства;
• вызов и загрузка;
• входные и выходные данные.

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

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


Полагаю так:
1. Служебные записки, извещения, прочие внутренние стандарты документооборота.
2. ЕСКД, ЕСПД.

Отнюдь. Откройте стандарт своего предприятия, и посмотрите на перечень разрабатываемой документации.
В том или ином составе. Это ведь денежку стоит.
Так что инструкция по прожигу ПЗУ. И ничего более.