|
|
|
работа в команде, как построить работу в команде fpga/SoC |
|
|
|
Sep 24 2018, 11:34
|
Частый гость
Группа: Свой
Сообщений: 95
Регистрация: 27-07-11
Из: Зеленоград
Пользователь №: 66 439
|
Цитата(Maverick @ Sep 24 2018, 12:05) собственно сабж в теме прошу поделиться опытом - есть один ведущий по проекту, остальные разработчики - на основе ТЗ должны четко определиться что и как делать, разделить ответственность по функциональным блокам. осуждение до тех пор, пока все не станет прозрачно и ясно (стремиться к этому) - четкое определение протоколов / времянок / интерфейсов / сигналов взаимодействия между блоками - работа в разных ветках svn/git, потом слитие в главную ветку. либо работа в одной, но без пересечений - проверка / верификация блоков после написания, перед слитием в главную ветку - должны быть тестовые стенды на каждые функциональные блоки, покрывающие максимальное кол-во возможных режимов работы блоков - крайне желательно, выработать единый стиль написания кодакак то так Цитата(quato_a @ Sep 24 2018, 14:22) ... - на основе ТЗ должны четко определиться что и как делать, разделить ответственность по функциональным блокам. осуждение до тех пор, пока все не станет прозрачно и ясно (стремиться к этому) ... обсуждение хотя осуждение тоже подходит
--------------------
Суббота начинается в понедельник
|
|
|
|
|
Sep 24 2018, 17:09
|
я только учусь...
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839
|
Цитата(quato_a @ Sep 24 2018, 14:34) - есть один ведущий по проекту, остальные разработчики - на основе ТЗ должны четко определиться что и как делать, разделить ответственность по функциональным блокам. осуждение до тех пор, пока все не станет прозрачно и ясно (стремиться к этому) - четкое определение протоколов / времянок / интерфейсов / сигналов взаимодействия между блоками - работа в разных ветках svn/git, потом слитие в главную ветку. либо работа в одной, но без пересечений - проверка / верификация блоков после написания, перед слитием в главную ветку - должны быть тестовые стенды на каждые функциональные блоки, покрывающие максимальное кол-во возможных режимов работы блоков - крайне желательно, выработать единый стиль написания кодакак то так обсуждение хотя осуждение тоже подходит Спасибо,. Жаль что так мало людей деляться опытом...
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
Sep 24 2018, 18:27
|
Профессионал
Группа: Участник
Сообщений: 1 273
Регистрация: 3-03-06
Пользователь №: 14 942
|
Еще бы добавил из книги Reuse Methodology Manual for System-on-a-Chip Designs такую банальность. Использовать стоит стандартные шинные интерфейсы для всех блоков всех участников проекта. Более того, если это, например, Альтера, то лучше прямо их Avalon и использовать. Это сильно упрощает, ускоряет интеграцию и отладку проекта. Совсем непопулярная мысль среди разработчиков, но тем не менее это мое личное мнение, которое никому не навязываю. Не стоит сильно думать, имхо, о переносимости проектов между вендорами. 99,99% таких забот оказываются невостребованными. Наоборот, лучше использовать стандартные процы и корки от производителей ПЛИС. Т.к. бывает текучка кадров, то найти замену, и самому разработчику будет легко въехать в стандартный проц. Поддержки много, вагон информации, примеров, средства отладки и все такое. В общем, пром. стандарт он и есть.
|
|
|
|
|
Sep 26 2018, 10:44
|
Частый гость
Группа: Свой
Сообщений: 118
Регистрация: 25-06-04
Пользователь №: 186
|
quato_a выше уже высказал основную мысль, Четкое разделение по задачам и срокам (стараться их соблюдать, но всегда подразумевается изначальная поправка по срокам). Интерфейсы должны быть однозначно документально и подробно описаны, многие проблемы идут из-за недопонимания друг друга, даже если это кажется прозрачно.
Один никак не потянет бОльшую часть проекта, основная идея может быть, но не все. Денег это не добавит (при нормальном руководстве нет супер звезд, но много профессионалов), только гемор и куча переработки (не всегда оплачиваемой). Поэтому изначально куча документации по дизайну, больше расскажешь - меньше проблем с интерфейсами. Далее стандартная имплементация, если не лезть на другую половину, то сроки можно предсказать.
На какой размер/проект рассчитана команда, в зависимости от задачи размер и специализация тимы/тимов будут различны. Где-то дизайн/тестирование/имплементация это различные тимы, а где-то один человек, все по разному, зависит от уровня работ, величина и периодичность проектов. P.S. я больше по ASIC, с FPGA все немного по другому
|
|
|
|
|
Sep 26 2018, 17:17
|
Участник
Группа: Участник
Сообщений: 21
Регистрация: 18-12-16
Пользователь №: 94 676
|
Цитата(x736C @ Sep 24 2018, 19:27) Совсем непопулярная мысль среди разработчиков, но тем не менее это мое личное мнение, которое никому не навязываю. Странно, что не популярная, Алексей. Мне казалось, что это вполне очевидно для большинства. А чем аргументируют?
|
|
|
|
|
Sep 26 2018, 19:27
|
Группа: Участник
Сообщений: 10
Регистрация: 8-07-18
Пользователь №: 105 782
|
Цитата А чем аргументируют? Содомиты окрестъ, азъ же единъ Добрыня Никитичь есмь! В общем, любят велосипеды изобретать и самых умных из себя строить. при этом, конечно, определённых вполне измеримых преимуществ они достигают, зато, как правило, даже не задумываются над ситуацией, когда хоть что-то пойдёт не так.
|
|
|
|
|
Sep 26 2018, 21:20
|
Профессионал
Группа: Участник
Сообщений: 1 273
Регистрация: 3-03-06
Пользователь №: 14 942
|
Цитата(Viktuar @ Sep 26 2018, 20:17) Странно, что не популярная, Алексей. Мне казалось, что это вполне очевидно для большинства. А чем аргументируют? Вы меня с кем-то перепутали, я не Алексей. Но аргументируют тем, что не хотят привязываться к вендору, есть стремление сделать платформонезависимый проект. Оно и понятно, и логично. И есть проекты, когда так и надо проектировать. Но в большинстве случаев для проектов на ПЛИС (без ASIC перспектив) намного раньше, чем необходимость сменить вендора, случаются иные события. Увольнения, закрытие проекта и т.п. Сегодня основной критерий, через который надо оценивать приемлемость подходов, это время воплощения проекта в жизнь. Причем не только на уровне предприятия или коллектива, но и на своем сугубо личном уровне, исходя из своих шкурных интересов. Все остальное очень сильно вторично. Намного более вторично, чем многие считают. Все выше сказанное всего лишь мое скромное мнение, основанное в том числе на разных «фейлах».
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|