[Maverick_ 15]

собственно сабж в теме

прошу поделиться опытом

[quato_a 3]

собственно сабж в теме

прошу поделиться опытом

 

- есть один ведущий по проекту, остальные разработчики

- на основе ТЗ должны четко определиться что и как делать, разделить ответственность по функциональным блокам. осуждение до тех пор, пока все не станет прозрачно и ясно (стремиться к этому)

- четкое определение протоколов / времянок / интерфейсов / сигналов взаимодействия между блоками

- работа в разных ветках svn/git, потом слитие в главную ветку. либо работа в одной, но без пересечений

- проверка / верификация блоков после написания, перед слитием в главную ветку

- должны быть тестовые стенды на каждые функциональные блоки, покрывающие максимальное кол-во возможных режимов работы блоков

- крайне желательно, выработать единый стиль написания кода

 

как то так :laughing:

 

...

- на основе ТЗ должны четко определиться что и как делать, разделить ответственность по функциональным блокам. осуждение до тех пор, пока все не станет прозрачно и ясно (стремиться к этому)

...

 

обсуждение :biggrin:

хотя осуждение тоже подходит

[Maverick_ 15]

- есть один ведущий по проекту, остальные разработчики

- на основе ТЗ должны четко определиться что и как делать, разделить ответственность по функциональным блокам. осуждение до тех пор, пока все не станет прозрачно и ясно (стремиться к этому)

- четкое определение протоколов / времянок / интерфейсов / сигналов взаимодействия между блоками

- работа в разных ветках svn/git, потом слитие в главную ветку. либо работа в одной, но без пересечений

- проверка / верификация блоков после написания, перед слитием в главную ветку

- должны быть тестовые стенды на каждые функциональные блоки, покрывающие максимальное кол-во возможных режимов работы блоков

- крайне желательно, выработать единый стиль написания кода

 

как то так :laughing:

 

 

 

обсуждение :biggrin:

хотя осуждение тоже подходит

Спасибо,.

Жаль что так мало людей деляться опытом...

[Leka 1]

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

Остальные работают мальчиками на побегушках.

 

 

[eugen_pcad_ru 0]

Да, принцип Покрышкина: один сбивает, другие загоняют )

Иногда проект ведется поэтапно. Одновременная правка проекта приводила к непонятным результатам.

[x736C 0]

Еще бы добавил из книги Reuse Methodology Manual for System-on-a-Chip Designs такую банальность.

Использовать стоит стандартные шинные интерфейсы для всех блоков всех участников проекта.

Более того, если это, например, Альтера, то лучше прямо их Avalon и использовать. Это сильно упрощает, ускоряет интеграцию и отладку проекта.

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

[Koluchiy 0]

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

 

1000 маленьких проектов делаются не так, как один большой.

[lexx 0]

quato_a выше уже высказал основную мысль,

Четкое разделение по задачам и срокам (стараться их соблюдать, но всегда подразумевается изначальная поправка по срокам).

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

 

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

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

 

 

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

P.S. я больше по ASIC, с FPGA все немного по другому

[Viktuar 0]

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

Странно, что не популярная, Алексей. Мне казалось, что это вполне очевидно для большинства. :wacko: :wacko: :wacko:

А чем аргументируют?

[Нивхурил 0]

А чем аргументируют?

Содомиты окрестъ, азъ же единъ Добрыня Никитичь есмь!

 

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

[x736C 0]

Странно, что не популярная, Алексей. Мне казалось, что это вполне очевидно для большинства. :wacko: :wacko: :wacko:

А чем аргументируют?

Вы меня с кем-то перепутали, я не Алексей.

Но аргументируют тем, что не хотят привязываться к вендору, есть стремление сделать платформонезависимый проект. Оно и понятно, и логично. И есть проекты, когда так и надо проектировать.

Но в большинстве случаев для проектов на ПЛИС (без ASIC перспектив) намного раньше, чем необходимость сменить вендора, случаются иные события. Увольнения, закрытие проекта и т.п.

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

Все выше сказанное всего лишь мое скромное мнение, основанное в том числе на разных «фейлах».