КД на проекты с ПЛИС кто как делает?
У нас на предприятии в комплект КД входит только файл 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. Глядишь, и остальные подтянутся.

Смотрел их, к сожалению не нашел Разгребать там нечего - имеется поиск и все уже структурировано.



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



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

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

PS: Wiki похоже глючит Основной скрипт постоянно порт левый подставляет (:1288), и после нажатия на кнопку сохранить изменения страница повисает, но благо сохраняются изменения... но не удобно с ней работать из-за этого...

Мне кажется, что такие требования можно было бы объединить для подобных xHDL.
Практически все, что написано, при желании может иметь отношение к верилог-реализации.

Я пока статью убрал. Так как хотелось бы это сделать как публикацию, которая нужна мне для дисертации. Я в принципе не против если там будет ссылка на автора статьи и/или на первоисточник. Короче чтобы потом можно говорить о том что это я написал данную статью.
ЗЫ Прежде чем выкладывать пожайлуста напишите мне в личку и мы обсудим все детали.

Статья на wiki выложена. Единственная просьба не убирайте и не редактируйте раздел:


PS благодарности nikolascha
PS PS Хотелось бы что-то подобное увидеть для Verilog и/или SystemVerilog от профи

Да уж... Извините, но текст ужасен. А местами напоминает автоматический перевод с английского.

Я не спорю, у меня большого опыта в написании статей нет. Если Вы говорите, что текст ужасен, то предложите более коректное/лучшее написание того или иного предложения или абзаца, параграфа или всего документа.
PS На мой взгляд(и некоторых других людей) статья написана хорошо, но я знаю что я человек и могу ошибаться, поэтому я его и выложил на форум, чтобы общими усилиями добиться идеала.
PS PS Оценить результат работы всегда проще, чем ее сделать.

Сколько людей - столько и мнений.

Но сочинения в школе вы писали?

Да, там нужна суровая редактура.
Короче, переписывать надо чуть менее чем всё.

А вот это
меня вообще убило.

Цифровые схемы -- это сплошная математика. Как вы собираетесь что-то делать без математических операций?

Про "программу на VHDL" я уж и не говорю.

Не нравится не читай и не пользуйся!
Хочешь помочь, то делай это нормально - без надсмешки и унижения.
Насчет "программа" или "описание" на VHDL/Verilog была отдельная ветка и кстати однозначного там ответа не найдено.
Конечно можно использовать, например для подсчета импульсов сумматор вместо счетчика, но нужно ли это?

ПОКАЖИТЕ ПРИМЕР КАК НАДО ПИСАТЬ - НАПИШИТЕ ЛУЧШЕ!!! но я уверен, что кроме громких слов ничего не будет(мое мнение)

PS "Не делай людям добра, не получишь зла". В очередной раз убеждаюсь в правильности этого высказывания.
PS PS des00 мне помог в написании одного из первых вариантов документа. Так он помогал конструктивными замечаниями и давал предложения по исправлению ошибок/некоректностей. Ему за это отдельная БЛАГОДАРНОСТЬ!!! Вот этим человек показал свой профессионализм.

Ну, я так и думал...

Что вы от меня хотите? Чтобы я разобрал статью по предложениям?

Естественно. Я ничего переписывать не буду. Для меня лично статья ничего нового и полезного не несёт.

Я так и думал просто слова и ничего более...
Подумайте может для других людей данная статья, что-то и несет нового и полезного и им(особенно начинающим) стоит помочь. Тем более люди на форуме переодически поднимают данную тематику
PS Без обид.

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

Статья полезная.
Есть ещё огромный раздел - описание конечных автоматов.
Я выкладывал свой стиль описания в теме "Описание конечных автоматов". Получил много интересных ответов.
Может стоит на wiki сделать страничку с формализованными описаниями автоматов ?

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

А по поводу подобное написать для Verilog и/или SystemVerilog как?

ИМХО бессмысленно, соревноваться с гуру в красноречии и вывертах (неплохо пишут о КА SunBurst, Douglas Smith, RMM, Synopsys, Mentor и еще туева хуча документов) смысла не вижу, делать перевод тоже. Для V/SV описание КА идет по тем же правилам что и для VHDL, с небольшими исключениями.

Если уж и делать полезную статью. то имеет смысл взять референсные КА на 20/40/60 состояний, описать их 4мя стилями и нарисовать в 2х распространенных софтах, все отладить. Привести код для оценки стиля описания и результат синтеза для оценки качества. ИМХО это будет наглядно, объективно и по делу.

Вы наверное меня не правильно поняли:
Вопрос был по поводу написания статьи по написанию программ на V/SV. Подобный документ Вы писали только на английском языке(хотелось бы увидеть на русском языке ссылки я давал раньше в этой ветке)

То что Вы предлагаете по поводу КА было бы супер, но вот кто за это возьмется?

Ссылку на документик можно ??

Конечно можно
ссылка

Прошу прощения, но он для VHDL, запамятововал...