Jump to content

    
Sign in to follow this  
Koluchiy

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

Recommended Posts

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

 

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

В качестве образца дается нечто странное.

 

Ну будут ли так любезны присутствующие подсказать, есть ли какие-то правила оформления документации на это дело.

То есть,

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

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

Так что, предоставление отсрочилось на неопределенное время.

 

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

Share this post


Link to post
Share on other sites
В конце концов, когда я сказал начальнику, что на разработку документации надо столько-то времени, он сказал, что есть более приоритетные задачи :wacko: .

Так что, предоставление отсрочилось на неопределенное время.

 

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

А если так подумать, какую б документацию на выполненный проект Вы предоставили?

Естественно коды программ на HDL и С для микропроцессора - будут всегда. Кроме них, что?

Чтобы потом так например годика через N открыли, прочитали и все вспомнили что, зачем и как

 

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

Share this post


Link to post
Share on other sites
А если так подумать, какую б документацию на выполненный проект Вы предоставили?

Мы закладывали прошивку конфигурационных ПЗУ.

Как на обычные ПЗУ-шки. Файл на машинном носителе, лист ИПХ (это для магнитного архива, типа формуляра) и лист утверждения.

Исходники проекта - на совести разработчика и начальника.

Ну а в принципе, чем ПЛИС формально отличается от того же контроллера?

Так же и закладывать, как обычное встраиваемое/прошиваемое ПО.

Исходные тексты, бинарник, листы утверждения, спецификация.

 

Чтобы потом так например годика через N открыли, прочитали и все вспомнили что, зачем и как

Вы бы ещё сказали, пришёл человек с улицы, прочитал, всё понял и пошёл работать!

Я вот смотрю сейчас на свои проекты 2-летней давности и не могу понять - как я мог ТАКОЕ написать!

Share this post


Link to post
Share on other sites
Ну а в принципе, чем ПЛИС формально отличается от того же контроллера?

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

 

 

Вы бы ещё сказали, пришёл человек с улицы, прочитал, всё понял и пошёл работать!

Как я понимаю именно для этого же и делается документация

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

Share this post


Link to post
Share on other sites
Цитата(MrYuran @ Jun 18 2010, 12:19) *

Вы бы ещё сказали, пришёл человек с улицы, прочитал, всё понял и пошёл работать!

Как я понимаю именно для этого же и делается документация

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

Share this post


Link to post
Share on other sites
А если так подумать, какую б документацию на выполненный проект Вы предоставили?

Естественно коды программ на HDL и С для микропроцессора - будут всегда. Кроме них, что?

Чтобы потом так например годика через N открыли, прочитали и все вспомнили что, зачем и как

 

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

Я писал как-то методику тестирования ПЛИС. Там система связи была и проверялось смещение по доплеру и гауссовский шум.

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

Share this post


Link to post
Share on other sites
Всю эту последовательность действий проводил студент третьего курса, который вообще в этом не разбирался, ну и данной методикой испытания вроде как уже два года пользуются :)

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

 

Share this post


Link to post
Share on other sites
Это другой вид документации, не проектно-конструкторская, а эксплуатационно-сервисная.

Согласен.

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

Share this post


Link to post
Share on other sites
Согласен.

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

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

 

Share this post


Link to post
Share on other sites
А как назвать документ в котором содержится подробное описание проекта со структурными схемами и временными диаграммами, а также подробное описание межблоковых интерфейсов? По идее спецификация, но в спецификации обычно описывается только назначение блоков и портов, то есть только необходимая информация для подключения и использования, без описания внутренней работы.
В ЕСПД есть документ «Описание программы».

Напомню ГОСТ.

Описание программы должно содержать следующие разделы:

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

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

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

ИМХО, все что вы описали можно уложить в Описание.

 

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

 

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

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

Полагаю так:

1. Служебные записки, извещения, прочие внутренние стандарты документооборота.

2. ЕСКД, ЕСПД.

Share this post


Link to post
Share on other sites
Звучит очень категорично.

 

Отнюдь. Откройте стандарт своего предприятия, и посмотрите на перечень разрабатываемой документации.

В том или ином составе. Это ведь денежку стоит.

Так что инструкция по прожигу ПЗУ. И ничего более.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this