Перейти к содержанию
    

Структура проекта

О вкусах и формах не спорят, но поделитесь, какая должна быть "правильная" структура проекта для Altera например на VHDL

Файлы, папки и тп...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

каждая среда разработки сама предлагает структуру папок проекта..

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

а там дальше как кому удобно

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

смотря что понимается под структурой проекта,

варианты:

- расположение файлов и директорий.

- расположение кода в файлах.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

maegg

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Вот по поводу отдельных узлов не знаю, вопрос интересный.

Прояснит кто?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Управление версиями - это, конечно, хорошо и новомодно, но в большом проекте иметь тучу файлов, каждый из которых имеет несколько подверсий, просто неудобно. Хотя мировой рынок производителей ПО обратил внимание на эту проблему (управление HDL-проектами поддерживает, в частности, HDL Companion), но такая методика больше подходит для крупных проектов, в которых участвует не один разрабочик.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Очень удобно все типы и константы (например разрядность внешней шины адреса, внутренние константы и т.п.) писать в package и хранить его в отдельном файле *.vhd (один package на проект) и подключать его в каждый entity как библиотеку. Еще полезно пользоваться атрибутами массивов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Мне подход от опенкорес нравится. Как вллане организации файловой структуры проекта,так и в плане соглашений на стиль проектирования.

Если кому интересно посмотрите у них в CVS в корне документы по соглашениям на оформление проета лежат.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

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

×
×
  • Создать...