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

[Maverick]

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

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

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

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

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

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

[Maverick]

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

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

[sazh]

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

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

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

[yes]

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

....

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

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

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

[Maverick]

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

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

[sazh]

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

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

[des00]

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

• Файл/документ, содержащий описание всех констант, переменных, сигналов.
• Описание работы функциональной модели (схема, конечный автомат состояний (диаграмма состояний конечного автомата), и временная диаграмма работы (скриншоты с ModelSim).
• TEST BENCH файл/документ с описанием для возможности моделирования работы.

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

• Подробное описание всех входных и выходных сигналов с предъявляемыми к ним требованиями (например потенциальная или импульсная команда(ее длительность)).

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи !!!

[Maverick]

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

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

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

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

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

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

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

Удачи !!!

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

[Doka]

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

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


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

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

[Maverick]

Maverick
дабы не придумывать велосипед и экономить время - можете рекомендовать смотреть 5ю главу RMM: RTL Coding Guidelines (параметры, выбор именования сигналов, написание "прозрачного кода", языковая переносимость, использование бибилиотек, реокмендации по схемам сброса и такта, деление проекта на модули)
а по поводу перечня файлов в комплекте поставки - это параграф 9.1.1 там же (в принципе справедлив и для ПЛИС): Soft Macro Deliverables.

Soft Macro Deliverables
RMM: RTL Coding Guidelines

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

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

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

[WEST128]

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

[des00]

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. вы заказали разработку с покупкой кода и они ведут себя так, то сами виноваты. Спрашивайте манагеров почему подписали договор на таких условиях!!! Это по сути деньги выкинули в трубу, гарантий саппорта никаких, в случае смены платформы, модернизации почти полная переписка.

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

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

Удачи!!!

[Maverick]

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

[Maverick]

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

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

[lex_84]

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

[Doka]

RMM: RTL Coding Guidelines

pub/DOC/Books/SoC/..

[Trainee]

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

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

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

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

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

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

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

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

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

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

[andrew_b]

Принципиальная схема (того что внутри ПЛИС) оформленная по ГОСТу на принципиальные схемы

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

[sazh]

1 Принципиальная схема (того что внутри ПЛИС) оформленная по ГОСТу на принципиальные схемы
Когда работали с Микроном они попросили просто описание на VHDL

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

[Trainee]

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

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

[Maverick]

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

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

[des00]

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

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

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


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

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

[Maverick]

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

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

http://electronix.ru/forum/index.php?showt...18207&st=45
там и с книг многое было взято, по хорошему нужно было все осознать и перевести на русский, но времени как то не хватило

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

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

[sazh]

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

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

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

 WinZip.zip ( 256.53 килобайт ) Кол-во скачиваний: 93

 

[Maverick]

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

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

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

[Maverick]

я чего-то не могу понять то что я переводил и разбирался пишут, что использование комбинационной обратной связи крайне не желательно, а пункт 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

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

[des00]

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

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

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

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

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

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

Удачи!

[Maverick]

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

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

[sazh]

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

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

[Maverick]

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

[sazh]

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

[Maverick]

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

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

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

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

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

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

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

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

 metastability.pdf ( 191.53 килобайт ) Кол-во скачиваний: 510

 

[Maverick]

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

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

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


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

С Уважением Maverick

[des00]

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

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

[Maverick]

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

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

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

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

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

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

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

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

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

[vitan]

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

[Maverick]

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

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

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

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

[клещ]

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

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

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

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

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

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

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

[Maverick]

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


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



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

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

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

[клещ]

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

отправил

[sazh]

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

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

[des00]

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

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

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

[клещ]

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

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

[sazh]

Другое дело - работа с контрольными службами (к примеру с теперь уже называющимся по другому ГосАтомНадзором). Они требуют выпускать объем документации на уровне, который бы достаточным для проведения верификации и валидации (слов-то понапридумывали!) оборудования от момента на всех этапах жизненного цикла оборудования (и начинают, естественно, в первую очередь с нас, разработчиков).

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

[vitan]

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

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

[DW0]

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

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

[tema-electric]

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

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

[vitan]

Если в спецификацию включить прошивку и ПЛИСину, то эту спецификацию можно включить в ПЭ3 как свое изделие.

Нельзя ли как нибудь более понятно? Как это "включить спецификацию в ПЭ3?

это ведет за собой выпуск извещений и коррекция всех изделий куда входит такое изделие.

Вы можете объяснить, как обойтись без извещений при изменении прошивки ПЛИС?

[DW0]

Нельзя ли как нибудь более понятно? Как это "включить спецификацию в ПЭ3?


Вы можете объяснить, как обойтись без извещений при изменении прошивки ПЛИС?

Например создаете документ АБВГ.123456.123 СП с названием типа "Комплект установочный на плату печатную с программируемой логикой"
в нее включаете:

микросхему ПЛИС
Файл прошивки
архив проекта (если надо)

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

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

[Maverick]

Получается ситуация когда разработчик плавно погружается в сопроводителя разработанного оборудования, а процесс разработки и сопровождения это совершенно разные процессы жизненного цикла.

Согласен, но мне кажется по другому нельзя.
Инструкция по программированию, файл прошивки, архив проекта - не решает все вопросы.
На мой взгляд здесь нужно дополнительно к основным:
ГОСТ 2.102-68 ЕСКД. Виды и комплектность конструкторских документов;
ГОСТ 2.114-95 ЕСКД. Технические условии;
ГОСТ 15.101-98 Система разработки и постановки продукции на производство. Порядок выполнения научно – исследовательских работ;
ГОСТ Р 15.201-2000 Система разработки и постановки продукции на производство. Продукция про-изводственно-технического назначения. Порядок разработки и постановки продукции на производство.

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

Что такое техническая поддержка и кто должен ее обеспечивать?
Сейчас это только сам разработчик

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

[DW0]

если мы говорим о АЭС, то органы которые занимаются верификацией, и валидацией и вообще там много нахлебников которые не дают дышать разработчику, проверяют качество жизненного цикла. Так вот процессы жизненного цикла по всем современным веениям и стандартам, должны включать не только разработку и установку оборудования, но и сопровождение, причем для обеспечения качества и диверсификации, необходимо чтобы сопровождением занимались независимые от разработчика организации (отдел, подразделение .....).
Под сопровождением понимается процесс внесения изменений, адаптация существующего оборудования к конкретному объекту, даже тестирование, и там много еще всякого почитайте ГОСТ Р 51904-2002.

но в жизненном цикле есть еще и снятие с эксплуатации, а от поставки до снятия с эксплуатации необходимо обеспечить в поставленный продукт вносить изменение, а это не много не мало 30 лет, так если не создать кучу документов по которым условно говоря отдел сопровождения сможет самостоятельно разобраться с оборудованием и самостоятельно вносить изменения и коррекцию, то это означает что к примеру через лет 10 какой-нибудь "студент" за какое-то время сможет также самостоятельно разобраться и повторить, даже на других технических средствах, данное оборудование. Это есть показатель качественной разработки, а если кто-то разработал оборудование и только он сам может его изготовить(хотя бы знает чем прошить) установить, наладить и внести изменения, то это не разработка, а кустарщина (я не хочу никого этим обидеть, если кто-то расценит это как обиду, то это означает что ничего не понято из вышесказанного. прошу таких людей просто проигнорировать данный пост) и не допустима для АЭС.

[клещ]

Например создаете документ АБВГ.123456.123 СП с названием типа "Комплект установочный на плату печатную с программируемой логикой"
в нее включаете:

микросхему ПЛИС
Файл прошивки
архив проекта (если надо)

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

Простите, не могли бы Вы поподробнее объяснить, как в ПЭ3 (перечень элементов) в качестве элемента забить спецификацию?

Что же касается остального, то как раз никакой проблемы нет - в архиве хранятся ВСЕ изменения. При этом на производстве всегда выпускают изделие с пометками о проведенных изменениях по извещениям. Другое дело, что когда оборудование устанавливают на нескольких объектах, то может возникнуть ситуация, что для одного объекта оборудование выпущено с ПО изм.№2, а на другом объекте - с изм№5, например. Тут только держать на предприятии-разработчике "банк данных", в котором будет собираться подобная информация. Съездил, к примеру, в командировку на 1-й объект, перезалил ПО новой версии (пусть той же №5) - по возвращении внес запись в "банк" о проведенной работе. Только так.

[vetal]

Простите, не могли бы Вы поподробнее объяснить, как в ПЭ3 (перечень элементов) в качестве элемента забить спецификацию?

"Микросхема АБВГ.123456.789"

[Maverick]

но в жизненном цикле есть еще и снятие с эксплуатации, а от поставки до снятия с эксплуатации необходимо обеспечить в поставленный продукт вносить изменение, а это не много не мало 30 лет, так если не создать кучу документов по которым условно говоря отдел сопровождения сможет самостоятельно разобраться с оборудованием и самостоятельно вносить изменения и коррекцию, то это означает что к примеру через лет 10 какой-нибудь "студент" за какое-то время сможет также самостоятельно разобраться и повторить, даже на других технических средствах, данное оборудование. Это есть показатель качественной разработки, а если кто-то разработал оборудование и только он сам может его изготовить(хотя бы знает чем прошить) установить, наладить и внести изменения, то это не разработка, а кустарщина (я не хочу никого этим обидеть, если кто-то расценит это как обиду, то это означает что ничего не понято из вышесказанного. прошу таких людей просто проигнорировать данный пост) и не допустима для АЭС.

на мой взгляд очень хорошие слова - особенно понравилось про студента

[DW0]

Простите, не могли бы Вы поподробнее объяснить, как в ПЭ3 (перечень элементов) в качестве элемента забить спецификацию?

поз. обоз._______________Наименование ____________________________________________________________количество ________ примечание
D11 ____________Комплект установочный на плату печатную с программируемой логикой АБВГ.123456.123 _______ 1

Съездил, к примеру, в командировку на 1-й объект, перезалил ПО новой версии (пусть той же №5) - по возвращении внес запись в "банк" о проведенной работе. Только так.

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

Сообщение отредактировал DW0 - Aug 10 2010, 14:36

[Guest_@Ark_*]

... жизненном цикле есть еще и снятие с эксплуатации, а от поставки до снятия с эксплуатации необходимо обеспечить в поставленный продукт вносить изменение, а это не много не мало 30 лет, так если не создать кучу документов по которым условно говоря отдел сопровождения сможет самостоятельно разобраться с оборудованием и самостоятельно вносить изменения и коррекцию, то это означает что к примеру через лет 10 какой-нибудь "студент" за какое-то время сможет также самостоятельно разобраться и повторить, даже на других технических средствах, данное оборудование. Это есть показатель качественной разработки, а если кто-то разработал оборудование и только он сам может его изготовить(хотя бы знает чем прошить) установить, наладить и внести изменения, то это не разработка, а кустарщина (я не хочу никого этим обидеть, если кто-то расценит это как обиду, то это означает что ничего не понято из вышесказанного. прошу таких людей просто проигнорировать данный пост) и не допустима для АЭС.

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

[DW0]

Интересно, кто, в этом случае, будет отвечать за работу оборудования?

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

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

[клещ]

поз. обоз._______________Наименование ____________________________________________________________количество ________ примечание
D11 ____________Комплект установочный на плату печатную с программируемой логикой АБВГ.123456.123 _______ 1

Я так понимаю, это годится в том случае, если ПЛИС вначале прошивается, а потом уже устанавливается в узел или модуль. А что прикажете делать, если она исходно запаивается в узел, и прошивка осуществляется в составе узла?

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

Ну вообще-то речь шла о заливке ПО, которое уже установлено на партию такого же оборудования, которое размещено на другом объекте, и которое уже прошло все испытания. Программа и отчет по верификации не требуются на каждый экземпляр устанавливаемого ПО. Не спорю, случаи бывают. Если это поставки на разные АЭС - то могут конечно и затребовать. Но если это поставки на разные блоки одной АЭС - примут имеющиеся отчеты, и никуда не денутся.

[Guest_@Ark_*]

а сопровождение будет всю жизнь доводить до совершенства кем-то разработанную продукцию

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

[DW0]

Я так понимаю, это годится в том случае, если ПЛИС вначале прошивается, а потом уже устанавливается в узел или модуль. А что прикажете делать, если она исходно запаивается в узел, и прошивка осуществляется в составе узла?

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

Ну вообще-то речь шла о заливке ПО, которое уже установлено на партию такого же оборудования, которое размещено на другом объекте, и которое уже прошло все испытания. Программа и отчет по верификации не требуются на каждый экземпляр устанавливаемого ПО. Не спорю, случаи бывают. Если это поставки на разные АЭС - то могут конечно и затребовать. Но если это поставки на разные блоки одной АЭС - примут имеющиеся отчеты, и никуда не денутся.

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

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

Еще раз, Мы говорим о атомной энергетики и требования там к разработке сложнее чем к сотовым телефонам. сопровождение в процессе эксплуатации это значит, что если заказчик (АЭС) обнаружила дефицит безопасности, его нужно устранять, так как безопасность ядерно опасного объекта не имеет цены. Сопровождение этого оборудования очень ответственное и внесение изменений для минимизации такого дефицита, также сложны как и разработка. И я вас уверяю этот процесс у нас непрерывный, так как это может быть не только ошибка в поставляемом оборудовании но и технологические изменения свойств оборудования которые(свойства) отличаются от первоначально заданных. И я вас уверяю через 10 лет активной разработки ни один разработчик не будет в состоянии самостоятельно сопроводить в течении 30 лет разработанное оборудование, и самое интересно что документирование должно быть организовано таким образом чтобы даже при похищении разработчика инопланетянами, процесс сопровождения не остановился, так по требованиям стандартам качества ИСО, не должно быть не заменяемых людей, но до нас это очень туго доходит, потому и делаем кустарщину(опять же это не принимать как обиду, да вы и сами понимаете о чем я)

[Guest_@Ark_*]

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

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

[DW0]

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

В данном случае речь идет не о квалификации, а главный акцент на качество документирования.
Документация должна быть сделана таким образом, чтобы можно было повторить разработку без разработчиков. Ну для примера Вы разработали изделие и документацию на него, через 15 лет оно морально устарело и требует частичной или полной реконструкции, по предоставленной разработчиком документацией возможно выполнить или частичное или полное реконструирование системы без участие разработчика. А то что нет квалификации это вопрос кадров, а не обеспечение безопасности. Нет кадров нет лицензии на работу в этой отрасли . Но это в идеале.
Компания которая работает в этой отрасли рано или поздно сама придет к этому и найдет ресурсы на кадры, или сгинет.

[Guest_@Ark_*]

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

Для текущего сопровождения и небольших доработок - это актуально, конечно. А для повторной разработки, как правило, - нет. Тем более, через 15-30 лет. Например, когда переводишь устаревшие изделия на современные МК, то совсем не интересно, как это было сделано когда-то на дискретной логике. Интересуют только конечные технические характеристики изделия...

[DW0]

Для текущего сопровождения и небольших доработок - это актуально, конечно. А для повторной разработки, как правило, - нет. Тем более, через 15-30 лет. Например, когда переводишь устаревшие изделия на современные МК, то совсем не интересно, как это было сделано когда-то на дискретной логике. Интересуют только конечные технические характеристики изделия...

Тут я с Вами не согласен, так как проектные решения при реконструкции очень важны. процентов 60-80, той документации которая будет разработана будет востребована через 10-15 лет при реконструкции, поверьте опыту, довелось реконструировать не одну систему, и схемы принципиальные 70-х годов идут вход, и чертежи, и записки и описания и свидетельства очевидцев и сторожил все идет для выяснения истины. При переходе на новую элементную базу (если МК это микроконтроллер, то это очень малая часть) необходимо получить и временных характеристики и понять суть новых решений, тем более если сегодня коды написаны на HDL, то я думаю их актуальность будет и через 10-15 лет еще актуальна и переносима на более новые ПЛИС.

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

[Guest_@Ark_*]

Тут я с Вами не согласен, так как проектные решения при реконструкции очень важны. процентов 60-80, той документации которая будет разработана будет востребована через 10-15 лет при реконструкции, поверьте опыту, довелось реконструировать не одну систему, и схемы принципиальные 70-х годов идут вход, и чертежи, и записки и описания и свидетельства очевидцев и сторожил все идет для выяснения истины. При переходе на новую элементную базу (если МК это микроконтроллер, то это очень малая часть) необходимо получить и временных характеристики и понять суть новых решений, тем более если сегодня коды написаны на HDL, то я думаю их актуальность будет и через 10-15 лет еще актуальна и переносима на более новые ПЛИС.

Вся эта информация актуальна, когда она представлена в виде ТЗ для разработки - формализована в виде технических требований, условий эксплуатации, обкатанных алгоритмов управления и так далее. Проектные решения 30-летней давности разработчику не нужны. Не так давно занимались переводом аппаратуры управления (примерно в вашей области) на современную элементную базу. Бредовая мысль разбираться в электрической схеме двух шкафов, сделанных в 70-е годы - никому даже не приходила в голову. От сопровождающих требовалось только четко сформулировать ТЗ. Несмотря на то, что аппаратуру они знали "вдоль и поперек" на ряд ключевых вопросов так и не смогли ответить - просто никогда не интересовались этим. Пришлось заниматься исследованиями.
Когда все выяснилось - задача оказалась более чем стандартной. Два шкафа, в итоге, заменили на пару небольших плат. Уже несколько лет прошло - претензий нет, все работает.

[клещ]

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

Эээхх.. Вы даже представить не можете, как я с Вами согласен!!

[DW0]

Вся эта информация актуальна, когда она представлена в виде ТЗ для разработки - формализована в виде технических требований, условий эксплуатации, обкатанных алгоритмов управления и так далее. Проектные решения 30-летней давности разработчику не нужны. Не так давно занимались переводом аппаратуры управления (примерно в вашей области) на современную элементную базу. Бредовая мысль разбираться в электрической схеме двух шкафов, сделанных в 70-е годы - никому даже не приходила в голову.

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

И поверьте, когда есть конфликт и нет однозначного ответа, то и схемы 70-х годов станут находкой, если они будут. Тем более что вам их читать не обязательно, наверняка их сможет читать эксплуатирующая сторона.

От сопровождающих требовалось только четко сформулировать ТЗ. Несмотря на то, что аппаратуру они знали "вдоль и поперек" на ряд ключевых вопросов так и не смогли ответить - просто никогда не интересовались этим. Пришлось заниматься исследованиями.
Когда все выяснилось - задача оказалась более чем стандартной. Два шкафа, в итоге, заменили на пару небольших плат. Уже несколько лет прошло - претензий нет, все работает.

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

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

[Guest_@Ark_*]

для того чтобы написать качественное ТЗ необходимо иметь нормальные исходные данные...

Ну, как формируется ТЗ мне не нужно рассказывать.

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

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

[DW0]

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