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

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

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

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

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

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

Нашел ГОСТ, но он больше относится к программистам под Windows

Взят ГОСТ отсюда
http://doka.info/recommendations/gost

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

Например у Вас был узел на элементах средней степени интеграции. (Документация - Э3, ПЭ3).
Теперь это ПЛИС с загрузочным ПЗУ. С тем же набором документации + файл прожига ПЗУ.
Кому нужны приключения с программным кодом.

посмотрите у синопсиса (synopsys.com) как они оформляют свои IP (там может регистрироваться надо - смотреть designware, star ip),

понятно, что разработка IP (со всей "требухой") и просто написание кода сильно разные задачи, но пример "как принято"

из "свободного" кода считаю удачно (но слышал и другое мнение) сделано у gaisler.com - там VHDL код, набор утилит для сборки/симуляции, доки - не супер, но вполне - все бы субподрядчики так делали, жить было бы легче

С Вами полностью согласен! Хорошо, попытаемся абстрагироваться, если это цифровая схема (не важно как она сделана - описана на VHDL или нарисована в схематике, или распаяна на плате отдельными микросхемами цифровой логики), то к ней как к любой схеме должно идти хоть какое-то описание например: функциональная схема, циклограмма работы, описание входов/выходов и т.д. Для программ под Windows так делается!

Есть ЕСКД. Есть стандарты предприятия. Вы как заказчик сами определяете минимальный состав документации, например на узел. Ведь все денег стоит.
Что касается документации на сам проект. Даже не знаю. Если Вы заказчик IP core, наверно достаточно стандартного описания вне ЕСКД, чтобы использовать его в работе. Обьем такой документации - это наверно предмет трудового соглашения.

если не против, добавлю свои 5 капель



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



В подробном описании не вижу смысла, достаточно краткого описания интерфейса внутреннего модуля. Да и то если модуль тривиальный (мультиплексор, сумматор переносом и т.д.) или код самодокументированый то смысла в этом вообще нет.



ИМХО полный бред, владеть хдл и при этом рисовать ? И это при наличии функциональной схемы ?
Насчет ядер : завернуть ядро в обертку и описать что делает обертка. Этого достаточно.


ИМХО в свое описании вы упускаете цель разработки. Решите что вы покупаете : готовое ядро или разработку с кодом.

Если покупаете ядро, то все что касается его внутренностей вам не важно. Главное что бы работало и соответствовало ТЗ. (при этом разработчик вообще может пропустить код через обфускатор для сокрытия тайны). Примеры документации можете посмотреть в описании коммерческих/открытых IP

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

Но тут все зависит от условий :
1. если вы покупаете готовую разработку то насчет кода поезд уже ушел, можно требовать только
документацию ( и то скорее всего за создание дополнительной документации, нужно будет заплатить)

2. если вы заказываете разработку то тут :

ИМХО нужно в обязательном порядке оговорить соглашение об именах, правилах и принципах проектирования !!!

это позволит заранее оговорить вопросы



и заставить разработчика писать самодокументированый код.

Также требуется тщательная разработка и документирование функциональности и параметров модуля, утверждение плана и методов верификации с описанием тестовых случаев и coner case.

Ну ИМХО вот так в кратце.

Ну и дополнительное пожелание : все вносите на бумагу с подробным описанием. Иначе разрабочик легко отвертится (конечно в будущем ему с вами может быть и не работать, но в текущем бабло получит).

Поэтому не верьте записям в договоре вида "предоставить все документацию, которая использовалась для разработки." Вы думаете что сюда будут входить мини ad-hoc тестбенчи и другая документация об архитектуре подмодулей, а разработчик предоставит функциональную схему высокого уровня абстракции.

Также не рекомендую принимать работу в виде проектов CAD с визуализаторами (HdlDesigner) например. Во первых ваша фирма может не использовать данный софт, будут проблемы переносимости кода между разработчиками которые его не используют ну и по хорошему нужно его лицензировать.

Удачи !!!

Что такое самодокументированый код? поясните пожалуста! И расскажите о "оговорить соглашение об именах, правилах и принципах проектирования !!!" и "Насчет ядер : завернуть ядро в обертку и описать что делает обертка. Этого достаточно.
" поподробнее, плиз

Maverick
дабы не придумывать велосипед и экономить время - можете рекомендовать смотреть 5ю главу RMM: RTL Coding Guidelines (параметры, выбор именования сигналов, написание "прозрачного кода", языковая переносимость, использование бибилиотек, реокмендации по схемам сброса и такта, деление проекта на модули)

а по поводу перечня файлов в комплекте поставки - это параграф 9.1.1 там же (в принципе справедлив и для ПЛИС): Soft Macro Deliverables.


по поводу документирования алгоритмов: как минимум должна быть общая и помодульная функциональная схемы + структурная (RTL) там, где это необходимо (т.е. существуют особенности кодирования при реализации)

мне очень нравится подход Xilinx в описаниях к ЦОС-блокам CoreGen: datasheet - фактически статья-руководство по написанию соответствующего блока, с достаточно хорошим изложением теории работы, функциональными схемами и ссылками на необходимую литературу в конце документа.

Soft Macro Deliverables
RMM: RTL Coding Guidelines

А не могли бы Вы дать ссылку либо эти файл, плиз



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

Все правильно. Разработчики не любят предоставлять сопроводительную документацию, а особенно такую подробную, ведь в этом случае вы фактически берете их наработки, на которых они и живут. Был случай, когда одна контора отказалась от разработки, когда заказчик пожелал увидеть исходники всех используемых ими модулей. Они сказали так: на разработку библиотек мы потратили очень много времени, и их стоимость превышает ваш заказ десятикратно, либо повышайте соответственно стоимость гонорара, или идите "лесом". Может получится так, что внутренную документацию вам не предоставять ни за какие деньги, всегда оговариваете это на этапе ТЗ.

http://disk.tom.ru/qz6ff4b

на фтп лежит, но т.к. он лежит то попробуйте забрать с томского файлообменника




это стиль описания, когда большая часть функционала модуля/библиотеки понята без комментариев, банальным прочтением кода



так называемые naming convention и design rules это простые правила которых нужно придерживаться при создании кода. Примеры для ХДЛ есть на этом форуме, в сети, в книгах Ben Cohen, Janic Bergeron а и т.д. Если придерживаться этих правил тогда смена разработчика будет происходить менее болезненно.



обертка - wrapper, black-box. модуль созданный по принятым соглашениям, в котором ядро вставлено как под-модуль. Облегчает понимание, переход между архитектурами и т.д.




Еще раз повторюсь : если это ваши коллеги то тут поможет только начальство, но краткое руководство пользователя ИМХО быть должно.

Если это ваши аутсорсеры (суб-подрядчики) :
1. вы покупаете у них готовую разработку то полное руководство пользователя и пример использования IP (ad-hoc testbench) быть обязано!!! Спрашивайте манагеров почему купили IP с никакой поддержкой и документацией.

2. вы заказали разработку с покупкой кода и они ведут себя так, то сами виноваты. Спрашивайте манагеров почему подписали договор на таких условиях!!! Это по сути деньги выкинули в трубу, гарантий саппорта никаких, в случае смены платформы, модернизации почти полная переписка.

Рекомендации : с такими командами аутсорсеров не работать.

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

Удачи!!!

Всем спасибо за очень хорошие ответы

Поделитесь, плиз, данной литературой (книги Ben Cohen, Janic Bergeron и как делается обертка - wrapper, black-box), либо дать ссылку на сайты где могу почитать об этом

Soft Macro Deliverables
RMM: RTL Coding Guidelines
Подскажите где лежит эта книга на ФТП. не смог ее найти

pub/DOC/Books/SoC/..

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

С заказчиком вроде договорились
1 Принципиальная схема (того что внутри ПЛИС) оформленная по ГОСТу на принципиальные схемы
2 Файл прошивки ПЛИС
3 Инструкция по настройке.

ГОСТов по оформлению документации действительно на ПЛИС нет. Может быть с переходом на стандарт ISO2000 что -нибудь изменится.

Когда работали с Микроном они попросили просто описание на VHDL

Вы не повеситесь, всё это разрисовывая? Хотя, конечно, от объема зависит...

Это как. RTL распечатаете, или два функционально подобных проекта делаете:
В графическом редакторе и текстовом редакторе?

НЕЕ два функциональных не делаю. Именно для заказчика только схему. Для Микрона VHDL. Но сейчас думаю как уити от этого, типа ПЛИС составная часть изделия ну и не надо ее разрисовывать, типа все структуры внутри ПЛИС конструктив, короче большая микросхема. А файл прошивки для производства. Все равно если чето не так ко мне побегут, а им отвечу типа все по ГОСТУ.

Руководствуясь книгой (System-On-Chip - Design and Test) указанной Dokа я попытался (по требованию моего начальства) соорудить некий переводной документ в котором привожу требования (положения) по написанию "качественных и понятных" программ HDL языке. Во вложенном архиве "1" оригинальный текст (страницы из книг) и распознанный текст в Word. Во вложенном архиве "2" это то что я так сказать "состряпал"(красным выделено то что у меня не получилось коректно перевести). Как ранее говорил про это des00 "ИМХО нужно в обязательном порядке оговорить соглашение об именах, правилах и принципах проектирования !!!"

P.S. Хотелось бы услышать как замечания так и предложения

кхм. могли бы и по форуму порыть

когда то я поднимал тему от 2006 года %)

http://electronix.ru/forum/index.php?showt...18207&st=45


там и с книг многое было взято, по хорошему нужно было все осознать и перевести на русский, но времени как то не хватило

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

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

Да мнений может быть сколько угодно. Например у описанию активного сигнала.
Активный низкий clr_n, высокий просто clr.
Про приоритетное мультиплексирование на два вложения тоже спорно,
А если это многофункциональный счетчик? как тут без приоритетного мультиплексирования.
Главное чтоб по времени уложилось.
Это все надо сертифицированному например vhdl дизайнеру показывать.
У Полякова в книге все классно рассписано.
Вот еще по-русски.

Докуметы, мне понравились будем читать и разбираться. Спасибо!!!

По поводу "Да мнений может быть сколько угодно. Например у описанию активного сигнала.
Активный низкий clr_n, высокий просто clr." тут я с Вами согласен, но можно и так и это - как я пишу об этом просто договариваются в начальной фазе проектирования

я чего-то не могу понять то что я переводил и разбирался пишут, что использование комбинационной обратной связи крайне не желательно, а пункт 4.44 документа des00 рассматриваемого по ветке http://electronix.ru/forum/index.php?showt...18207&st=45 говорит обратное а также это говорит пункт 4.31 в документе des00.

Ссылка на документ des00 http://electronix.ru/forum/index.php?act=A...ost&id=6137

Я кажется чего-то не допонимаю, объясните пожайлуста!

4.44. RTL: All the Entity's outputs should be registered. Combinational outputs can also create combinational feedbacks through the hierarchy.

Хмм может я что то не понял, но тут говорится о том, что крайне желательно что бы выходу модуля были пропущены через регистры.

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

Вот пример : мастер шины, у которого сигнал request формируется комбинационной логикой с сигналом acknowledge. (тогда как более разумно пропустить его через триггер).

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

Удачи!

Спасибо я этого не знал

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

Извините, поспешил! обнаружил некоторые некоректности, выложу документ позже.

5. При объявлении многоразрядных переменных (сигналов), используйте последовательный порядок битов, либо высокий к низкому или низкий к высокому - то есть 7 до 0 для VHDL
///////////////////////////////////////////
По мне нужно указать конкретно
reg [7:0] shift_rg ------- только так 7 старший, 0 младший - как на входе модуля так и на выходе.
[0:7] (старший ноль, 7 младший у нас не прижилось)

Выкладываю документ, все что дали пригодилось и изучил и как по мне взял самое важное (или то что понимаю ), кроме правил форматирования документа (оно для меня не принципиально, но можно и написать). Писал, к сожалению, для VHDL, так как Verilog не знаю.

Спасибо за помощь des00 и sazh

Про метастабильность стоит здесь упоминать или нет, если да то как это красиво сформулировать (материал на русском языке есть во вложении)?

P.S. Только, пожалуйста, сообщайте об не точностях, свои замечания и пожелания.



Согласен, исправил

Извините, за мою настойчивость, но может как-то доведем до разумного конца вопрос с документацией. Ранее это уже конечно обсуждалось , поднимал это des00. Мое предложение написать все это на русском языке и кстати на ветке ранее вопрос перевода поднимался.

http://electronix.ru/forum/index.php?showt...18207&st=15

Я начал это делать и хотел бы это закончить


P.S. Жду Ваших сообщений об не точностях, замечаний и пожеланий.

С Уважением Maverick

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

Без проблем, подождем-с

Нашел у Xilinx такой интересный документ на данную тему.

Особенно информация на страницах:
3-15 "Comparing Signals and Variables (VHDL only)"
3-20 "Comparing If Statement and Case Statement"

по Verilog там тоже какие то рекомендации даются, но в основном VHDL

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

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


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


Удачи!!!

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

Спасибо 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 на узел (это с расчетом на то, что на
узле не обязательно находится одна ПЛИС). И вот в эти поддиректории уже записывались файлы проекта и файл прожига.
Точно так же выпускались "Этикетка" и "Ведомость", и успешно хранилось в архиве.

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

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

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

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

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

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


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



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

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

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

отправил

Тогда уж и квартус используемой версии документируйте. В другой может ведь и не заработать.
Заказчику ваши файлы не нужны. Им нужен комплект документации. А Вам - минимальный.
Все равно эти файлы кроме специалистов никому не нужны. Следовательно для вас - простая архивация вне документации.

Вам шашечки или ехать?

Мы в отделе выбрали второе в итоге у нас SVN репозиторий на серваке и mediawiki для документирования/обсуждения разработок.

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

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

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

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

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

А некоторые ПЛИС вообще не шьются и каждый раз как с чистого листа