[SM 0]

+ голова, каранадаш и стопка бумаги.

И, как говорят у нас, "без пол-литры не разберешься". Так что еще пол-литра, плюс-минус :)

 

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

 

Допросом автора с пристрастием...

Если он уволен...

Ну тут, как бы... Не надо портить отношения с коллегами. Уволен он начальством, или сам ушел, но это, обычно, не мешает поддерживать связь с коллегами и консультировать. Периодически пересекаясь по интересующим вопросам, например, в заведениях общепита. Сам по себе знаю - уходил (лет так 10 назад), оставлял кучу исходников (причем не только HDL, а еще и многие сотни кило ассемблера DSP, что гораздо хуже), и до сих пор готов помочь, если что там не понятно тем, кто сейчас работает. Вообще, IMHO, вопрос о вникании в чужой код возникает не в таких случаях, когда Вам передают код от уходящего коллеги, а когда код выдергивается откуда-то, из совсем чужих IP, и его надо модифицировать под себя не совсем официально.

[sherr 0]

Есть вот veriloghgl.org - может что-то даст... VTС строит блочки и связи между ними... Не могу сказать, что "это наше все", но хоть что-то..

Разрешите чуть поправить ссылку VTC2012

Изменено 19 июля, 2014 пользователем sherr

[egorman44 0]

огогого сколько всего ! выражаю огромную признательность и благодарность всем ответившим ! респект и уважуха так сказать

 

Для пунктов 2 и 3 мог бы пригодиться doxigen. Это хоть как-то автоматизирует процесс в части струкутрного описания.

Для пункта 4 использовать LEC, чтобы избежать глупых ошибок.

 

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

 

doxigen актуален для verilog? зашел на main page читаю:

 

but it also supports other popular programming languages such as C, Objective-C, C#, PHP, Java, Python, IDL (Corba, Microsoft, and UNO/OpenOffice flavors), Fortran, VHDL, Tcl, and to some extent D.

 

можно поподробнее, что же такое LEC ?

и извините , может быть за наивный вопрос, но в аббревиатурах не силач , что значит ЯОА, а то даже мой старый знакомый Гугл мне отказывается помочь :smile3046:

 

Менеджерам на заметку...

А почему-бы и не научится документировать то что разрабатывается?

Деньги разработчику уплочены - значит и комплектность результатлов работы должна соответствовать - т.е. проект должен иметь документацию.

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

 

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

 

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

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

Ответ разработчика был простой - не умею их (тестбенчи) писать и проверяю все осцилографом....

Наличие тестбенчей естественно ускоряет понимание чужого проекта/описания...

 

Насколько я успел разобраться тестбенчи тоже на проект не писались.

 

[Golikov 0]

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

 

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

 

Из требований последних работодателей было так:

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

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

Отдельно описание всех глобальных переменных, зачем нужны, что делают, где используются

Отдельное описание всех используемых прерываний

Описание всех входных и выходных сигналов схемы в целом (для процов писали порты и куда идут как используются)

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

Каждая строчка кода имеет комментарий, реально каждая, то есть

int i = 0; //переменная для цикла это для процов
input main_clk; //основной входной клок схемы это для ПЛИС

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

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

 

 

Это было очень муторно, с выкручиванием рук, убеганием от рисования блок схем и так далее... Даже был специальный человек которыйвсе это потом правил, верстал, поправлял... Потом схемы печатались, раздавались нескольким, скажем так менеджерам, они их смотрели читали, задавали вопросы, правили. Времени уходило больше чем на реализацию. Но я заметил такую вещь, так как блок схемы и описание алгоритма делалось до программной реализации, то большая часть затыков решалась на этом этапе, то есть когда доходило до писанины кода, это уже была без творческая механическая писанина понятного сформированного алгоритма. Ну и как сами понимаете когда вам дают прошивку с таким комплектом, то прочитав его вы знаете все... даже не надо глупых вопросов задавать типа а еще остался свободный таймер? Как то так... тепло их вспоминаю :)...

 

 

 

 

 

 

 

 

[ASN 0]

egorman44

Знакомая ситуация :(. Долго, муторно и, зачастую, бессмысленно. Но вариантов нет.

Вам привели хороший пример про ручку и карандаш, и про то, то нужно время.

IMHO, необходимо (последовательно):

- выделить ВСЕ сигналы и процессы в таблицу;

- в таблицу внести столбики куда сигналы входят, откуда и куда идут с кратким описанием Вашего понимания их назначения;

- нарисовать блок-схему устройства и перенести (физически скопировать в квадратики) на неё код (как САПР);

- нарисовать машины состояний;

- нарисовать диаграммы изменения сигналов;

- нарисовать временные диаграммы сигналов;

- написать тест-бенч и проверить правильность работы RTL;

- создать контрольные примеры;

- скорее всего, местами переписать код - если нет тестового окружения, то писал его либо гений, либо разгильдяй. Второе наиболее вероятно.

После постараться дать "пинка под зад" руководителю, поскольку если проект не документирован и без контрольных векторов, то это не руководитель. Совсем.

 

P.S.

Golikov A.

IMHO, для ПЛИС больше подходит ЕСПД.

[SM 0]

- скорее всего, местами переписать код - если нет тестового окружения, то писал его либо гений, либо разгильдяй. Второе наиболее вероятно.

 

в дополнение:

 

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

[khach 33]

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

[Maverick_ 15]

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

это возможно, если в одном городе, а если в разных городах ...

да тогда скайп в помощь, но все равно уже не то ...

[SM 0]

это возможно, если в одном городе, а если в разных городах...

Тоже возможно, зависит от степени заинтересованности, мотивированности и необходимости.

[FatRobot 0]

http://lmgtfy.com/?q=doxygen+verilog

http://lmgtfy.com/?q=RTL+LEC

http://yandex.ru/yandsearch?lr=213&tex...%8F%D0%BE%D0%B0

 

doxigen актуален для verilog?

можно поподробнее, что же такое LEC ?

что значит ЯОА,

 

Это хорошая демонстрация моего совета:

 

Предварительно следует оценить "кредит глупых вопросов".

 

Пожелаю вам успехов.

[Golikov 0]

IMHO, для ПЛИС больше подходит ЕСПД

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

[egorman44 0]

http://lmgtfy.com/?q=doxygen+verilog

http://lmgtfy.com/?q=RTL+LEC

http://yandex.ru/yandsearch?lr=213&tex...%8F%D0%BE%D0%B0

 

ахахаха спасибо за let me google that for you, я не те запросы вбивал в поисковике

 

Пожелаю вам успехов.

 

благодарю!

[aabmail 0]

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

А если нет комментариев? Да это получше всяких ребусов, загадок и т.д. и т.п. Уж тем более, если нет связи с разработчиком.

А если код глюченый? Как же все-таки приятно найти чужой косяк, увидеть, что вот тут разработчик проявил прилежность, а тут смалодушничал (в т.ч. examples от Xilinx из coregen'a). Словом - код отражает характер автора.

 

Простите за offtop.

 

 

 

[Amurak 0]

Всякий ли сможет заставить себя прочитать умные книжки по программированию?

И много есть книжек по VHDL? Таких, чтобы не перепечатка стандарта с описанием синтаксиса и парой примеров, а в которых описываются реальные устройства?

[Golikov 0]

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