Управление конфигурацией для проектов FPGA

Question

Какой инструмент управления конфигурацией лучше всего подходит для конструкций ПЛИС, в частности для ПЛИС Xilinx, запрограммированных с VHDL и C для встроенного программного обеспечения (микроблаза)?

Answer 1

Не существует «лучшего», но решения по управлению конфигурацией, которые работают для программного обеспечения, подойдут для ПЛИС - процесс очень похож. Я использую Subversion на работе и git дома, и немного написал о «почему» в моем блоге .

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

Answer 2

Я не думаю, что это имеет большое значение, какой инструмент контроля версий вы используете - все, что вы считаете хорошим в целом, вероятно, будет в порядке здесь. Я лично использую Git для значительного программного проекта Verilog +, и я очень доволен им.

Что будет укусить вас в задницу - независимо от того, какой контроль версий вы используете - так это: инструменты Xilinx обычно не соблюдают четкое разделение между «вводом» и «выводом» или между (отредактировано человеком) » источник "и (непрозрачный)" двоичный файл ". Многие из инструментов любят хранить некоторую информацию о состоянии, например время последнего запуска или значение хеша, в своих «входных» файлах, что означает, что вы получите много ложных изменений. Coregen делает это с файлами .xco, а навигатор проекта (основной графический интерфейс) - с файлами .xise. Кроме того, оба инструмента имеют привычку вставлять или удалять строки для параметров по умолчанию, по-видимому, наугад.

Самая большая проблема, с которой я столкнулся, - это рабочий процесс с Coregen: во многих случаях верно хотя бы одно из следующих:

1. Вам необходимо вручную редактировать файлы HDL, созданные Coregen.
2. Параметры, входящие в Coregen, хранятся где-то, кроме файла .xco (обычно в том, что выглядит как выходной файл).
3. Вы должны скопировать и вставить вывод из Coregen в ваш дизайн верхнего уровня.

Это означает, что не существует единого логического источника / основного местоположения для вашего ввода в процесс генерации ядра. Таким образом, даже если у вас есть файл .xco под управлением версией, нельзя ожидать, что ваш дизайн соответствует ему. Если вы заново сгенерируете «то же самое» ядро ​​из его номинальных входов, вы, вероятно, не получите правильные выходы. И даже не думай о слиянии.

Answer 3

Ранее я использовал Subversion, но перешел на git два года назад. Git обрабатывает файлы дизайна FPGA так же хорошо, как и любой другой текстовый и двоичный файл. Git - это все, что вам нужно для контроля версий ваших файлов и артефактов.

Для построения проектов я рекомендую использовать только один проект ISE, называемый "ise" (расположенный в подкаталоге "ise /"). Вы можете взглянуть на мой (очень скромный) проект с открытым исходным кодом FPGA на github для макета файла. Я не беспокоюсь о сохранении файлов ISE, поскольку их легко восстановить. Единственное, что я сохраняю, это файлы Verilog и некоторые файлы конфигурации ISIM. В других проектах, использующих coregen, я сохраняю файл проекта coregen.cgp и все сценарии * .xco для регенерации ядер. Затем я использую Makefile для фактического запуска coregen для файлов * .xco. Есть несколько других специфичных для Xilinx файлов, которые вы также должны контролировать версиями: * .ucf, * .coe, * .xcf и т. Д.

Я экспериментировал с использованием Makefiles и инструментов командной строки Xilinx, но обнаружил, что ISE намного лучше отслеживал зависимости и вызывал инструменты с правильными аргументами. Только не делайте ошибку, пытаясь управлять версиями файлов ise / project, иначе вы сойдете с ума. Xilinx имеет около 300 различных типов файлов, которые меняются в каждом выпуске. Если вы хотите сохранить файл, вы можете попробовать сам файл проекта ISE с расширением .xise. Все, что трудно воссоздать, например, золотой битовый файл, который, как вы знаете, работает и на его сборку ушло 6 часов, вы можете скопировать это и настроить его для явного управления.

Answer 4

Мы используем Perforce, и это здорово. Вы можете проверить свой код, который живет в Linux-стране, параллельно с вашими Спецификациями и Документами, которые живут в Windows-земле. И вы получаете разветвления, ярлыки и т. Д.

Я видел все, от Clearcase до RCS, и это действительно хорошо для такого рода вещей. Важно получить хороший набор политик регистрации, установленных для вашей группы, и убедиться, что они соблюдаются.

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

Answer 5

Я лично использовал Perforce, Subverion, git и ClearCase для проектов FPGA. Поскольку VHDL и C - это просто текстовые файлы, любой работает нормально. Однако убедитесь, что вы захватили другие файлы проектов и противопоказаний и все библиотеки, которые вы используете.

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

Answer 6

Я видел, как Perforce и Subversion использовались в нескольких компаниях, интенсивно использующих FPGA.

Answer 7

Я предлагаю инструменты CM, которые поддерживают маркировку версий и двоичные файлы. Большинство программных приложений CM хорошо работают с текстовыми файлами ASCII. Они могут просто хранить «разностный» файл, а не весь файл для обновлений.

Мои рекомендации: PVCS, ClearCase и Subversion. НЕ ИСПОЛЬЗУЙТЕ Microsoft SourceSafe. Мне это не нравится, потому что он поддерживает только одну метку на ревизию.