[kaktus 0]

Что из вспомогательного софта можно применить для упорядочения процесса разработки прошивки одной FPGA несколькими :cheers: людьми? Сейчас в осном используется тупо ISE 7.1.

 

/литературное отступление: начало/

...Раньше архитектура проекта представляла несколько блоков, за каждый из которых отвечал отдельный человек, блоки ощались по шине, все было нормально. Теперь с появлением "толстых" и дешевых FPGA выгоднее паковать несколько блоков в один кристалл. Но тут на поверхность вылезают организационные проблемы. Несколько человек на своих компах ваяют отдельные части проекта. Возникает путаница где последние версии какого из блоков. Каждый начинает собирать у себя весь проект из кусков разных версий чтобы оттестировать свою часть. В итоге хаос :cranky: , грозящий в будущем не приятными неожиданностями, а вполне ожиданными неприятностями...

/литературное отступление: конец/

 

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

[Gate 0]

Поставьте и поиграйтесь mentor hdldesigner - если продеретесь через начальные трудности и сумеете освоить, а документации там навалом, то описанные проблемы исчезнут.

[oval 0]

Поставьте и поиграйтесь mentor hdldesigner - если продеретесь через начальные трудности и сумеете освоить, а документации там навалом, то описанные проблемы исчезнут.

 

+1

 

и "поднять" контроль версий

[aat_81 0]

Что из вспомогательного софта можно применить для упорядочения процесса разработки прошивки одной FPGA несколькими :cheers: людьми? Сейчас в осном используется тупо ISE 7.1.

 

/литературное отступление: начало/

...Раньше архитектура проекта представляла несколько блоков, за каждый из которых отвечал отдельный человек, блоки ощались по шине, все было нормально. Теперь с появлением "толстых" и дешевых FPGA выгоднее паковать несколько блоков в один кристалл. Но тут на поверхность вылезают организационные проблемы. Несколько человек на своих компах ваяют отдельные части проекта. Возникает путаница где последние версии какого из блоков. Каждый начинает собирать у себя весь проект из кусков разных версий чтобы оттестировать свою часть. В итоге хаос :cranky: , грозящий в будущем не приятными неожиданностями, а вполне ожиданными неприятностями...

/литературное отступление: конец/

 

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

 

SVN или SVS и проблемы с версиями будут окончательно решены, сможете даже удаленно работать над проектом))))

[3.14 0]

2 kaktus

У Xilinx Для этих целей modular design задуман. С контролем версий прийдется самим разбираться а вот синтезить каждый сможет в чем заблагорассудится.

[LeonY 0]

Для разработки "толстой" FPGA никто шин не отменял. По ним (шинам) могут и должны общаться не только и, даже, не столько отдельные кристаллы, но и отдельные модули внутри кристалла. Если этого правила не придерживаться - проблемы обеспечены. Внутри-кристальных шин разных довольно много (на вскидку - Wishbone, Avalon, AMBA,...) и инфу по ним не слишком сложно надыбать. Она есть и на местном форуме и на www.opencores.org и на Altera сайте.

 

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

 

Абсолютно другая сторона проблемы - version control. Эта проблема также обсуждалась здесь, высказывались различные мнения, предпочтения - советую почитать. Имплементировать нормальный version control в пределах одной организации и/или одной географической зоны при наличии локальной сети не так уж и сложно и это является имхо совершенно необходимым. Масса технических и организационных проблем возникает когда завязаны разработчики в 5-6 районах Земного Шара. Эта техническая проблема. А к организационным можно отнести такие вещи как, например, требования секретности, доступ к закрытой локалке извне и т.д. Кстати - эта проблема решается хуже всего, тут уж руководителю проекта приходится вертеться как ужу на сковородке, часто конфликтовать со всеми с кем только можно и нельзя.

[aat_81 0]

Масса технических и организационных проблем возникает когда завязаны разработчики в 5-6 районах Земного Шара. Эта техническая проблема.

 

 

Я не понимаю в чем проблема то интернет еще никто не отменял, другое дело что аппаратные проблемы таким образом решить не все получится

[LV26 0]

Ну раз у Вас каждый делает что хочет - то это не проблема софта,

а плохое управление проектом и софт тут не поможет. А сборку проекта вообще моделировать должен

отдельный человек

[LeonY 0]

Я не понимаю в чем проблема то интернет еще никто не отменял, другое дело что аппаратные проблемы таким образом решить не все получится

Интернет не отменяли, но тут и возникают проблемы - security, скорость доступа, хостинг, locking,...

 

Что имеется в виду под "аппаратные проблемы"???