КД на проекты с ПЛИС кто как делает?
У нас на предприятии в комплект КД входит только файл sof или pof как таблица прошивки ППЗУ.Но это не обеспечивает возможность модернизации в дальнейшем. Сейчас стали говорить что надо бы оформлять еще тексты программ, алгоритмы и описание программ как на программы. Это конечно правильно для нормальных программ для микроконтроллеров и ПЭВМ, а для ПЛИС помоему затруднительно.
Вот и вопрос кто как оформляет КД на ПЛИС, какие ГОСТы на это существуют?

А не программа это вовсе. А если в графическом редакторе работаете, что описывать будете. И почему это не обеспечивает возможность модернизации. Замените таблицу прожига ПЗУ на другую. (чем например epc1 лучше 556РТ7). Хотите текстовое описание заложить. А что от него толку для того кто будет это разгребать, если придется. (Заложить наверно надо, но без ссылок на документы (Чтобы просто не потерять наработку))
Достаточно стандартного комплекта документов. (Инструкция по прожигу, диск, этикетка и без ссылок на пакет разработки)

Достаточно стандартного комплекта документов. (Инструкция по прожигу, диск, этикетка и без ссылок на пакет разработки)
Мы тоже так думали и делали.
Но при этом предполагается что сам проект хранится у разработчика, а разработчик - лицо безответственное (уволился, комп грохнулся,диск потерялся) и все.Далее для модернизации придется создавать новый проект.

Мы - это кто. Обычно об этом один думает. Остальные ему проекты приносят.
Основная проблема не в безответственных разработчиках. А в отсутствии грамотного руководителя проекта.
А для модернизации все равно новый проект придется создавать.
Например было 4 узла. Один в графическом редакторе на MAX+, другой на ahdl, не проверите третий на vhdl, четвертый на верилоге.
Кака по мне, я б этого руководителя - барабанщика.
Теперь один. все по новой.

Мы-это собственно те кто и делает эти проекты.(Обычно 1-4 человека на проект).

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

Зачем?

1. чтобы отвязались? формально сделать вид, что если кто-то придет "разгребать", то вот оно все есть?

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


2. как облегчить жизнь пришедшему "разгребать".

Лучше всего прикладывать винчестер с полным комплектом программ, от ОС и текстового редактора до place and route. Рядом копию образа всего диска разработчика, например в true image. Вряд ли установится, но может помочь. Подробный текст как и что ставить на голый компьютер, со всеми тонкостями привязки к железу, если есть. Естественно, исходные тексты, констрейны, файлы проектов все, все, все, должны быть в нужных местах дерева файловой системы.
К сожалению, даже такой винчестер не поможет студенту 5-ого курса, успешному web-программисту на perl быстренько портировать проект на новое семейство.



IMHO: Цена возможности быстро что-то поменять в старых проектах высока. Даже в своих собственных. Про них нужно помнить, нужно держать на диске старые версии среды разработки, полистывать исходные тексты. Ведь если случится нужда что-то поменять, то придется все это кому-то загружать в голову. Либо автору вспоминать, либо новичку осваивать.
Думаю, что выгодно либо держать автора изо всех сил и иметь в виду, что уход автора равносилен потере возможности развивать старый проект.
Либо каждый проект после завершения рассматривать как немодифицируемый и не развиваемый. Попытку вмешаться в старый проект следует рассматривать как новый проект, бюджет которого может превысить бюджет первоначального проекта.

Коллеги, что-то вы тут сгущаете краски. Немодифицируемым и не развиваемым является только то, что "слеплено на коленке". Нормально разработанный проект с хорошей документацией еще как модифицируется и развивается!



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

Я сталкивался с этим. Есть ГОСТ на оформление документации на разработки сделаные в электронном виде, т.е программы, схемы и т.д. Номера не помню, но выпуск где-то 2000 или 2001 года. Выходили еще ГОСТЫ в 2006 г. там то же говорилось про электронную документацию. Суть этих ГОСТов сводится к тому, что если исполнитель передает всю документацию в электронном виде (т.е. проект), например на DVD, то ничего оформлять по старому ГОСТУ на листочках в рамочке не надо. Только спецификации и чертежи оформляюются в рамочках по госту. Главное, чтобы был полный проект, используюя который можно было получить тот же результат. Есть специальная форма спецификации для электронных документов. А в спецификации на изделие указывают только файл прошивки. А оформлять тексты кода по старому ГОСТУ уже не надо. Правда, там есть оговорочка, что документация может выполняться в бумажном виде по согласованию сторон. С нас попросили оформить по-старому только спецификации и чертежи схем и описание проекта (описание функционирования). Мы делали описание начинки ПЛИС как описание схемы и функционирование аппаратных контроллеров, а не как описание программы.

Вот это и есть ключевая фраза
А что именно сохранять очень сильно зависит от применяемых tools, пребований к проекту (технических), требований / соглашений с заказчиком, и еще массы факторов

И всё же - куда именно смотреть чтобы подготовить прожект на плиске к сдаче по госту ?

Как я понял здесь документация готовится по договорености сторон. ГОСТа в свое время я не нашел.
Ранее этот вопрос поднимался:

здесь

здесь 1

на основе этих обсуждений(предложений, рекомендаций) я для языка VHDL (так как я на нем программирую) написал рекомендации (требования, правила) на русском языке. Сейчас я пытаюсь сам им следовать. Это по поводу описания самой цифровой схемы схемы в ПЛИС. Конечно не помешает дополнительно
- описание реализуемых алгоритмов (например фильтров и т.д.), устройств (например интерфейсы связи);
- структурно-функциональная схема для всего проекта с описанием (это может быть и файл верхнего уровня (sсhemathic));
- если в описании имеются директивы для синтеза - указать это отдельно (для чего, зачем);
- оговорить отдльно если были использованы IP ядра, как разработчиков фирмы изготовителя программного обеспечения (Altera, Xilinx и т.д.) или стороннего производителя к которому нет VHDL/Verilog описания (имеется только netlist);
- Может быть оговорить граничные частотно-временные характеристики, ограничения проекта

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

Форумчане, может быть все таки попробуем довести до ума вопрос с документацией для FPGA/CPLD? Т.к. вопросы на эту тематику будут все чаще и чаще будут задаваться, а конкретного ГОСТа нет (по крайне мере я его не нашел). Общими силами написать типа "методички"(статьи, правил, требований) по поводу конструкторской документации для разработанных проектов в FPGA/CPLD. На мой взгляд она многим будет полезна.

Так как Вам мое предложение?

ЗЫ Свой труд на эту тему я выложил в предыдущем своем сообщении (см выше)

С уважением Алексей

2 Maverick - а теперь вместе дружно вспомним про 20 с хвостом гигов гостов в закромах родины
Только вот кто возьмётся за их разребание ??

Прочитал. Документ интересный.
Добавлю пару предложений (может, конечно, и бестолковых), но не найденных в документе:
1. Для сигналов входящих/выходящих в/из ПЛИС я использую префиксы IN_xxx, OUT_xxx, IO_xxx. После прохождения однонаправленных сигналов через I/O BUF, префиксы IN_ и OUT_ - отбрасываю. Для IO_ сигналов прошедших IOBUF использую суффиксы xxx_IN, xxx_OUT. (буферы ввода/вывода всегда вставляю в проект)
2. Для различных внутренних сигналов использую ряд однотипных суффиксов:
_UB - UnBuffered (например, для Clock поданного на вход BUFGMX),
_UL - UnLatched (например, для входных сигналов, которые должны быть защелкнуты входным IOB триггером),
_L - Latched (например, для сигналов,)
_FF - Falling front (применяю для выходного сигнала "детектора" фронта)
_RF - Rising front (применяю для выходного сигнала "детектора" фронта)

Ну например как-то так:

Единственная заметная разница моего стиля написания и вышепредложенного в названии инверсных сигналов, я вставляю _n между описанием принадлежности сигнала к группе и основным описателем сигнала: Reset -> nReset, RAM_nOE, PCI_nFrame.
Мне так удобнее - а далее кому как больше нравиться.

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

Сделайте статейку на wiki. Глядишь, и остальные подтянутся.