реклама на сайте
подробности

 
 
> Подход к проектированию систем на кристалле, Кто как делает?
Mad_max
сообщение May 19 2009, 13:11
Сообщение #1


Местный
***

Группа: Свой
Сообщений: 377
Регистрация: 23-12-06
Из: Зеленоград
Пользователь №: 23 811



Начал заниматься новой для себя тематикой - системами на кристалле.
Соответственно, помимо, чисто технических вопросов, возникли и идеологические проблемы-вопросы.

С fpga работаю давно и реализовывал достаточно не простые проекты. Разработки были в области
цифровой обработкой видео: фильтрация, пороговая обработка, сегментация, всевозможные интерфейсы
как стандартизированные, так и свои собственные. Подход был следующий: работал в Active-HDL, соответственно
начинал с нуля, с разработки общего алгоритма работы схема и далее по порядку, заточенные под конкретные задачи,
шины, автоматы-арбитры, вычислительные блоки и все межблочные механизмы взаимодействия. В общем получалась
схема под выполнение определенной задачи.

В первом ознакомлении с системами на кристалле, натыкаешься на EDK как основной инструмент разработки.
Соответственно, предлагается принять данный подход как истину и дальше от него отталкиваться. Взять в нагрузку
использование предлагаемой архитектуры межблочного взаимодействия CoreConect ( тут хоть есть альтернатива, например,
wishbone, но все же). Принять, что центром в системе является процессор, хотя иногда это не всегда оправдано. Смирится с тем что,
используя предлагаемый в EDK подход подсоединения user logic, не одно действие в системе не происходит без ведома
поцессора (а что если от одного интерфейсного блока до другого мне надо Гбиты данных перекачивать)
и то что свою схему нужно обязательно сжать на PLB (иначе не понятно как ее подтянуть к проекту), да и вообще что нутря проекта максимально
отдаленны от разработчика (это как главный принцип работы винды, максимально защитится от действий юзира) приступить к разработке конечного продукта.

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

Для Active-hdl есть библиотека, где PPC идет прямо отдельным библиотечным элементом. Данный путь разработки полностью своей системы на кристалле будет
конечно тернист и сложен, но зато тут сам себе хозяин. И главный вопрос как тут быть с программированием процессора?

В общем, хотелось бы порассуждать на данную тему, услышать мнение опытных разработчиков и вообще кто что по этому поводу думает.
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов
per_aspera_ad_as...
сообщение Jun 5 2009, 10:20
Сообщение #2


Участник
*

Группа: Участник
Сообщений: 27
Регистрация: 26-01-08
Из: Гусь-Хрустальный - Владимир
Пользователь №: 34 452



Существует два основных подхода это Implement Design in XPS и Implement Design in ISE.

В первом случае вы используете EDK, а что-то внешнее (ваши модули) подключаете как Peripheral к процессору.

Во втором наоборот, вы в свой VHDL/Verilog подключаете процесор как обычный модуль или IP-core, для работы с ним из ISE будет подгружаться EDK. Сигналы которые вы увидите в описании PPC как компонента, это external signal в EDK (все внутренние соединения, такие как память, MPMC, BRAM в ISE будут не видны).

Второй путь во всех документах помечен как - deprecated, но я так понял по вашему посту вас это совсем не смущает, а даже радует :-)

Вообще эта тема достаточно интересная и можно долго по этому поводу спорить. У нас тоже все разработчики только на ISE сидят и никакие маршруты (мировозрения) менять не хотят.

Сообщение отредактировал per_aspera_ad_astra - Jun 5 2009, 10:21


--------------------
За беспокойство не беспокойтесь.
Go to the top of the page
 
+Quote Post
leevv
сообщение Jun 8 2009, 16:30
Сообщение #3


Частый гость
**

Группа: Свой
Сообщений: 100
Регистрация: 4-01-05
Пользователь №: 1 799



Мы используем первый подход - EDK (XPS) as a top.
Я считаю это оправданным особенно для больших проектов.
Основное преймушество как я это вижу - это стандартизация. При всех недостатках MHS файла он служит топ левелом для всего проекта.
И если IP pcore отлажен и работает в системе то он становится относительно легко переносимым в другие проекты.
Более того удобно когда несколько человек независимо работают каждый над своим pcore-ом.

Опять таки при всех недостатках coreconnect bus structure разработкой занимается Xilinx, а мы концентритуемся на своих "проблемах".
Тот кто начинал с ISE 7.1 тот поймет какой прогресс Xilinx EDK сделала, и это вообщем-то бесплатно для пользователей.



Цитата(per_aspera_ad_astra @ Jun 5 2009, 06:20) *
Существует два основных подхода это Implement Design in XPS и Implement Design in ISE.

В первом случае вы используете EDK, а что-то внешнее (ваши модули) подключаете как Peripheral к процессору.

Во втором наоборот, вы в свой VHDL/Verilog подключаете процесор как обычный модуль или IP-core, для работы с ним из ISE будет подгружаться EDK. Сигналы которые вы увидите в описании PPC как компонента, это external signal в EDK (все внутренние соединения, такие как память, MPMC, BRAM в ISE будут не видны).

Второй путь во всех документах помечен как - deprecated, но я так понял по вашему посту вас это совсем не смущает, а даже радует :-)

Вообще эта тема достаточно интересная и можно долго по этому поводу спорить. У нас тоже все разработчики только на ISE сидят и никакие маршруты (мировозрения) менять не хотят.
Go to the top of the page
 
+Quote Post



Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 30th July 2025 - 12:11
Рейтинг@Mail.ru


Страница сгенерированна за 0.03421 секунд с 7
ELECTRONIX ©2004-2016