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

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

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

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

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



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

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

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

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


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

С Уважением Maverick

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

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

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

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

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

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

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


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


Удачи!!!

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

Спасибо des00!

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

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

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

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

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

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

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

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

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


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



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

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

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

отправил

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

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

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