требования к документации Опции

[Maverick]

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

P.S. Это как я попытался сформулировать:

Требования к написанию программ и документации для ПЛИС

• Файл/документ, содержащий описание всех констант, переменных, сигналов.
• TEST BENCH файл/документ с описанием для возможности моделирования работы.
• Описание работы функциональной модели (схема, конечный автомат состояний (диаграмма состояний конечного автомата), и временная диаграмма работы (скриншоты с ModelSim).
• В исходном коде программы должны присутствовать комментарии, облегчающие понимание программы.
• Подробное описание всех входных и выходных сигналов с предъявляемыми к ним требованиями (например потенциальная или импульсная команда(ее длительность)).
• По возможности большую программу/схему разбивать на подпрограммы/подсхемы.
• На начальном уровне соединение всех функциональных блоков производить в Schematic Editor (например, Синхрогенератор <=> Модуль связи УПСОС-ПК) (может заменить функциональную/структурную схему).
• При использовании ядер из CoreGenerator описать процесс создания.
• При написании исходного кода программы максимально использовать механизм настраиваемых параметров Generic (например, для разрядности данных, адресов и т. д.).

Но мое начальство говорит, что лучше руководствоваться ГОСТами. Соответственно вопрос есть ли какой то ГОСТ на оформление документации (для программ для ПЛИС).

P.S. Прошу прощения, что может не в тему. Просто здесь чаще бывают люди которые с этим непосредственно связаны

[des00]

как и обещал высказываю свое ИМХО %)

текст и выкладки смотрите в атаче.


Если что не понятно что бы не флудить, стучитесь в аську (ищется через icq.com за 2 минуты или пишите для связи в личку) или на IRC канал #ru_embedded


Удачи!!!

ЗЫ. Если в тексте атача чем обидел приношу свои извинения.

Прикрепленные файлы

 _______.doc ( 69.5 килобайт ) Кол-во скачиваний: 132

 

[Maverick]

Спасибо des00!

[клещ]

Спасибо des00!

Maverick, у меня проблема в чем-то схожа с Вашей.
Если описать кратко - то Заказчику передается аппаратура, включающая в себя узлы, реализованные на базе ПЛИС.
И если с эксплуатационной документацией, передаваемой Заказчику, проблем нет (файлы прожига не поставляются - поставляются узлы как законченное изделие, входящее в ЗИП к аппаратуре, и соответственно на них передаются только Э3 и ПЭ3), то с документацией, которая должна храниться в архиве предприятия-разработчика - форменная беда.

Раньше шло деление таким образом.
Если ПЛИС прожигается отдельно в программаторе - то на нее (микросхему) брался отдельный децимальный номер, например "микросхема Н-0001 АБВГ.431219.001", который и заносился в ПЭ3 на узел. Создавалась инструкция на программирование микросхемы (в тех же терминах АБВГ.431219.001 ИП), на дискету в одну директорию писались файлы проекта ПЛИС, во вторую - файл прожига. Выпускались листы утверждения (АБВГ.431219.001 Д1 ЛУ для файлов проекта и АБВГ.431219.001 Д2 ЛУ - для файла прожига ПЛИС), а так же "Этикетка" для дискеты и "Ведомость документов на магнитном носителе".

Если ПЛИС прожигалась уже в составе узла, то номер на микросхему не брался, инструкция на программирование выпускалась уже для узла (т.е под его децимальным номером - к примеру АБВГ.467746.001 ИП). Так же под децимальным номером узла выпускались листы утверждения. На дискету записывалось следующим образом:
- корневая директория - 467746001_00
то есть децимальный номер узла. Если для узла использовались разные проекты, то на узел бралось исполнение, а
записываемая директория выглядела как 467746001_01 (в данном случае для исполнения ...-01);
- в корневой директории находились 2 поддиректории - ...\D1 и ...\D2 (соответственно для исходных файлов проекта ПЛИС и
файла прожига ПЛИС);
- в каждой поддиректории располагались еще поддиректории - номера ПЛИС по Э3/ПЭ3 на узел (это с расчетом на то, что на
узле не обязательно находится одна ПЛИС). И вот в эти поддиректории уже записывались файлы проекта и файл прожига.
Точно так же выпускались "Этикетка" и "Ведомость", и успешно хранилось в архиве.

Все было так. Именно БЫЛО. Поскольку с недавних пор под новыми веяниями "проработать по-новому" данный вопрос доверили одному "чудаку на букву м". Чудило этот программер, и недолго думая ввел новую систему, от которой мы до сих пор в полном а..у..е.
Короче, по его системе документирования, на ВСЕ микросхемы берется децимальный номер. При этом в состав микросхемы прошивка ПЛИС входит как программное изделие, со своим номером, взятым по ЕСПД.
Естественно, сразу разрастается объем выпускаемой документации - тут тебе и обязательно ТЗ на разработку, и описание прошивки, и методика проверки. И на все до кучи спецификация. Реально пользы не видно, а вред подхода уже хорошо ощутим, так как количество выпускаемой макулатуры выросло в разы.

И самое обидное то, что действительно нет никаких ГОСТов для оформления документации на ПЛИС.

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

[Maverick]

Maverick, у меня проблема в чем-то схожа с Вашей.

И самое обидное то, что действительно нет никаких ГОСТов для оформления документации на ПЛИС.

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

Если не сложно ответьте на следующие вопросы:
у Вас на фирме работают несколько человек с ПЛИС (разрабатывают уст-ва и программируют ПЛИС) или только один?
если несколько человек то пересекаются ли проекты, т.е. один разработал блок, а другой дальше использует этот блок в своем устройстве?
каким образом происходит проектирование на ПЛИС - в основном с помощью схемотехнического редактора или на языках описания аппаратуры?
ЗЫ чтобы более корректнее ответить

[клещ]

Вы не можете брать децимальный номер на микросхему, ибо она не Вашей разработки. Раньше у Вас было неправильно, а сейчас - вдвойне неправильно.

Это отчего же? Если в КД указывать, что сама "болванка" ПЛИС (или ПЗУшки - на них так же делается документация) входит в комплект выпускаемой микросхемы в виде детали - то почему бы и нет?

Раньше у Вас было неправильно, а сейчас - вдвойне неправильно.

Если насчет первого еще поспорил бы, со со вторым согласен на 200%.

Если не сложно ответьте на следующие вопросы:
у Вас на фирме работают несколько человек с ПЛИС (разрабатывают уст-ва и программируют ПЛИС) или только один?
если несколько человек то пересекаются ли проекты, т.е. один разработал блок, а другой дальше использует этот блок в своем устройстве?
каким образом происходит проектирование на ПЛИС - в основном с помощью схемотехнического редактора или на языках описания аппаратуры?

Реально ПЛИСинами занимается 3 человека. Более того, они же и тянут разработку узлов, в которых применяются ПЛИСины. Разработчик проектирует ПЛИС "от и до" - т.е. от ТЗ до проверки узла с записанной прошивкой в ПЛИСины. Сами проектируем, сами шьем, сами настраиваем. Используем Альтеру, МАXII.
Собственно функциональная часть описывается блоками на Verilog, В основном блоке входящие "сшиваются", этот основной блок вставляется в Quartus в виде символьного элемента. В Quartus осуществляем только привязку к пинам, нумерацию пинов - после чего компиляция.
Одно время были благие мысли организовать "банк модулей", чтобы другие разработчики могли бы его использовать. Но так как специфика направления работы у каждого разработчика своя, то и модули эти практически не попадают в чужие проекты. Просто не прижилось. Разве что есть такое применение модулей одного типа в различных разработках "в пределах" одного разработчика. Хотя кто его знает - жизнь штука переменчивая, и если будем работать в одной тематике, то осуществлять обмен модулями сможем без особых проблем.

Собственно мой вопрос сводился к чему - каким образом построить систему документирования, чтобы и по ГОСТ, и полноценно сохранялся проект на ПЛИС. В общем, чтобы аудиторы Заказчиков были довольны, и у нас голова не болела, что хранящаяся в архиве предприятия версия файлов проекта не откомпилируется или откомпилируется "не так".

[Maverick]

Это отчего же? Если в КД указывать, что сама "болванка" ПЛИС (или ПЗУшки - на них так же делается документация) входит в комплект выпускаемой микросхемы в виде детали - то почему бы и нет?


Если насчет первого еще поспорил бы, со со вторым согласен на 200%.



Реально ПЛИСинами занимается 3 человека. Более того, они же и тянут разработку узлов, в которых применяются ПЛИСины. Разработчик проектирует ПЛИС "от и до" - т.е. от ТЗ до проверки узла с записанной прошивкой в ПЛИСины. Сами проектируем, сами шьем, сами настраиваем. Используем Альтеру, МАXII.
Собственно функциональная часть описывается блоками на Verilog, В основном блоке входящие "сшиваются", этот основной блок вставляется в Quartus в виде символьного элемента. В Quartus осуществляем только привязку к пинам, нумерацию пинов - после чего компиляция.
Одно время были благие мысли организовать "банк модулей", чтобы другие разработчики могли бы его использовать. Но так как специфика направления работы у каждого разработчика своя, то и модули эти практически не попадают в чужие проекты. Просто не прижилось. Разве что есть такое применение модулей одного типа в различных разработках "в пределах" одного разработчика. Хотя кто его знает - жизнь штука переменчивая, и если будем работать в одной тематике, то осуществлять обмен модулями сможем без особых проблем.

Собственно мой вопрос сводился к чему - каким образом построить систему документирования, чтобы и по ГОСТ, и полноценно сохранялся проект на ПЛИС. В общем, чтобы аудиторы Заказчиков были довольны, и у нас голова не болела, что хранящаяся в архиве предприятия версия файлов проекта не откомпилируется или откомпилируется "не так".

для общения - вышлите мне в личку свою почту. плиз