Документация на "прошивку" ПЛИС - что, как? Опции

[Koluchiy]

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

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

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

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

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

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

[Koluchiy]

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

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

[Maverick]

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

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

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

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

[bogaev_roman]

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

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

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

[MrYuran]

Всю эту последовательность действий проводил студент третьего курса, который вообще в этом не разбирался, ну и данной методикой испытания вроде как уже два года пользуются

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

[bogaev_roman]

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

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

[x736C]

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

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

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

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

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

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

1) промежуточная документация для взаимодействия с программистами и схемотехником
2) окончательная документация на разработанный и отлаженный проект

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

[sazh]

Звучит очень категорично.

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

[Oldring]

Откройте стандарт своего предприятия
...
Это ведь денежку стоит.

+1. Кто платит - тот и заказывает музыку. Будь то начальник или непосредственно заказчик.
Вопросы возникают только тогда, когда клиент сам заранее не знает, что хочет получить, и поэтому начинает пытаться менять предпочтения в пределах заранее оговоренного бюджета. Вариантов типов проектов море, есть одноразовые, есть которые должны жить и развиваться десятилетия при разных разработчиках. Долгую жизнь проекта нужно закладывать с самого начала, инвестируя в это соответствующие усилия.

[Maverick]

+1. Кто платит - тот и заказывает музыку. Будь то начальник или непосредственно заказчик.
Вопросы возникают только тогда, когда клиент сам заранее не знает, что хочет получить, и поэтому начинает пытаться менять предпочтения в пределах заранее оговоренного бюджета. Вариантов типов проектов море, есть одноразовые, есть которые должны жить и развиваться десятилетия при разных разработчиках. Долгую жизнь проекта нужно закладывать с самого начала, инвестируя в это соответствующие усилия.

Вы правильно говорите. Здесь как раз я хотел бы рассмотреть эти вопросы, чтобы в дальнейшем избавится от проблем

[Oldring]

Вы правильно говорите. Здесь как раз я хотел бы рассмотреть эти вопросы, чтобы в дальнейшем избавится от проблем

Здесь неподходящее место. Такие вопросы нужно обсуждать с заказчиком или начальством. Чтобы заранее выяснить, хотят ли они заплатить дополнительные деньги за документацию, или сойдет и одноразово даже без обязательств техподдержки через несколько месяцев. Если проект простой и дешевый - нередко дешевле спроектировать с нуля при необходимости внесения изменений. Зачем для такого проекта дополнительная писанина?