Mad_kvmg 0 19 мая, 2009 Опубликовано 19 мая, 2009 · Жалоба Начал заниматься новой для себя тематикой - системами на кристалле. Соответственно, помимо, чисто технических вопросов, возникли и идеологические проблемы-вопросы. С fpga работаю давно и реализовывал достаточно не простые проекты. Разработки были в области цифровой обработкой видео: фильтрация, пороговая обработка, сегментация, всевозможные интерфейсы как стандартизированные, так и свои собственные. Подход был следующий: работал в Active-HDL, соответственно начинал с нуля, с разработки общего алгоритма работы схема и далее по порядку, заточенные под конкретные задачи, шины, автоматы-арбитры, вычислительные блоки и все межблочные механизмы взаимодействия. В общем получалась схема под выполнение определенной задачи. В первом ознакомлении с системами на кристалле, натыкаешься на EDK как основной инструмент разработки. Соответственно, предлагается принять данный подход как истину и дальше от него отталкиваться. Взять в нагрузку использование предлагаемой архитектуры межблочного взаимодействия CoreConect ( тут хоть есть альтернатива, например, wishbone, но все же). Принять, что центром в системе является процессор, хотя иногда это не всегда оправдано. Смирится с тем что, используя предлагаемый в EDK подход подсоединения user logic, не одно действие в системе не происходит без ведома поцессора (а что если от одного интерфейсного блока до другого мне надо Гбиты данных перекачивать) и то что свою схему нужно обязательно сжать на PLB (иначе не понятно как ее подтянуть к проекту), да и вообще что нутря проекта максимально отдаленны от разработчика (это как главный принцип работы винды, максимально защитится от действий юзира) приступить к разработке конечного продукта. Есть конечно и свои преимущества у EDK, например, визарды для подключения к поцу внутренней и внешней памяти, хотя для опытного разработчика, кто делал контроллеры памяти в системах без всяких там PPC, и это не вопрос. Ну и конечно главный плюс это волшебная утилита на входе которой Си и hdl, а на выходе файл конфигурации. Для Active-hdl есть библиотека, где PPC идет прямо отдельным библиотечным элементом. Данный путь разработки полностью своей системы на кристалле будет конечно тернист и сложен, но зато тут сам себе хозяин. И главный вопрос как тут быть с программированием процессора? В общем, хотелось бы порассуждать на данную тему, услышать мнение опытных разработчиков и вообще кто что по этому поводу думает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 20 мая, 2009 Опубликовано 20 мая, 2009 · Жалоба Начал заниматься новой для себя тематикой - системами на кристалле. Соответственно, помимо, чисто технических вопросов, возникли и идеологические проблемы-вопросы. тема поднималась неоднократно, пользуйтесь поиском %) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 5 20 мая, 2009 Опубликовано 20 мая, 2009 · Жалоба почему EDK :) у синплисити(синопсиса) сейчас вышел тул систем дизайнер (btw: кому-нибудь удалось пустить Synplify_vC-2009_03 ? - он там) там платформонезависимая SoC предлагается на LEONe (так по крайней мере обещали синопсисовские парни) можно напрямую скачать у Гейслера библиотеки - никакого "индастри-стандарт стайл" типа EDK там нет - есть tcl/tk-ные менюшки задающие ряд вопросов по конфигурации системы мне вообще больше нравится исходные файлы (HDL) руками править, а не пользоваться генераторами, так как при серьезной работе польза от таких генераторов меньше, чем борьба с глюками кроме EDK у альтеры есть NIOS IDE у латтиса Mico32 IDE, даже у АРМа есть так же выглядящая хрень для быстрой выпечки АЗИКов помоему еще есть платформонезависимые (я их не коллекционирую - написал, то что вспомнилось) для ксайлинса можно взять Mico32 - он в исходных кодах, память нужно заменить - шина вишбон ну или же Leon - там AMBA AHB 2.0 на мой взгляд из-за того что ксайлинс тащит CoreConnect (из-за хард-проца PPC) там генератор (типа EDK) имеет хоть какой-то смысл, шина гемморная, пока разберешься умаешься... а то что все остальные стали копировать такой подход - имхо, один вред. проще может быть взять с опенкореса чистый RTL для вишбона, без всяческих костылей в виде генератора соединений типа EDK|NIOS Leon я бы все-таки рекомендовал использовать с осторожностью - имхо, система тяжелая и не сильно оптимизирована под ПЛИС, хотя есть много плюсов (тот же SMP - это не хухры-мухры) ------------------- главный ответ - с программированием по разному, но идея одинаковая есть железо с отладочным интерфейсом (обычно JTAG, но, например у Leona это может быть еще и уарт, и изернет и юсб и может что-то еще) есть программка, которая коннектится к этому железу и работает на хосте - xdb у ксилинса, grmon у Leona и т.д., эта программка представляет стандартный интерфейс по TCP|IP для gdb (на одном хосте), ну а сверху gdb ставится какой-то IDE (сейчас модно Eclipse) вобщем-то эти программки xdb, grmon .... сами имеют некий командный интерфейс (то есть можно работать и с ними - я например gdb к grmon-у не подключаю, так как мне grmon удобнее), gdb или insight (с окошками) вобщем удобнее, но не все железячные хитрости поддерживает и т.д. так-же есть симулятор и gdb и т.д. можно подключать к симулятору ----------------- ну а компилер - обычно патченый gcc (то есть при желании не только с/с++ но и ada, fortran и т.д. - любой gcc-шный фронтэнд, а по-моему нет такого компилирующегося языка, для которого такого фронтэнда (в некой степени доработанности) не существовало бы) для LEONa наверно можно найти спарковский компилер (я еще застал 32-х битные спарки и вроде утверждалось, что их фирменный компилер рвет gcc как газету), но с тех пор много времени прошло, вряд ли новые сановские компилеры v8 поддерживают операционки - всякие ecos-ы, rtems-ы, если мму есть - то линуксы (для леона есть SMP линукс, чем далеко не всякий 32-х разрядник похвастается - только х86 и в новейших кортексах вроде как бета) ------------------ порассуждал вобщем за двоих :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 20 мая, 2009 Опубликовано 20 мая, 2009 · Жалоба А еще есть некий стандарт IP_XACT, который распространен у короделателей, у того же известного CAST. Только вот я так и не въехал, как при помощи всей этой кучи xml сгенерить то, что мне нужно, хотя synplify этот стандарт поддерживает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
per_aspera_ad_astra 0 5 июня, 2009 Опубликовано 5 июня, 2009 (изменено) · Жалоба Существует два основных подхода это 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 сидят и никакие маршруты (мировозрения) менять не хотят. Изменено 5 июня, 2009 пользователем per_aspera_ad_astra Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
leevv 0 8 июня, 2009 Опубликовано 8 июня, 2009 · Жалоба Мы используем первый подход - EDK (XPS) as a top. Я считаю это оправданным особенно для больших проектов. Основное преймушество как я это вижу - это стандартизация. При всех недостатках MHS файла он служит топ левелом для всего проекта. И если IP pcore отлажен и работает в системе то он становится относительно легко переносимым в другие проекты. Более того удобно когда несколько человек независимо работают каждый над своим pcore-ом. Опять таки при всех недостатках coreconnect bus structure разработкой занимается Xilinx, а мы концентритуемся на своих "проблемах". Тот кто начинал с ISE 7.1 тот поймет какой прогресс Xilinx EDK сделала, и это вообщем-то бесплатно для пользователей. Существует два основных подхода это 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 сидят и никакие маршруты (мировозрения) менять не хотят. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Cont 0 12 июня, 2009 Опубликовано 12 июня, 2009 · Жалоба По-моему все недостатки, которые приводит автор надуманны. Во-первых, ограничение по скорости, не проблема. В ЕДК есть инструменты для передачи больших потоков данных, к тому же система, созданная в ЕДК может быть лишь субмодулем системы более высокого уровня. Вот здесь вопрос к опытным разработчикам, можно ли представить ЕДК-ю систему как параметризируемое ядро (как в ip coregen), чтобы уже на уровне нетлиста передавать другим участникам проекта. Во-вторых, на сегодняшний день разработка периферийных контроллеров( я имею ввиду DDR, Ethernet, USB) самая трудоемкая задача, а EDK это успешно решает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
tolik1 0 17 июня, 2009 Опубликовано 17 июня, 2009 · Жалоба Существует два основных подхода это Implement Design in XPS и Implement Design in ISE. И необходимый маршрут надо выбирать на основе исходных данных проекта(Технические требования, наличие наработок, и тд). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rsv2007 0 17 июня, 2009 Опубликовано 17 июня, 2009 · Жалоба Существует два основных подхода это Implement Design in XPS и Implement Design in ISE. Еще один есть подход (для богатых или ленивых) - использование System Generator for DSP. Там смысл такой: творишь в симулинке некую систему, а потом в нее импортируешь дизайн из XPS. После этого, прямо из симулинка, делаешь Implement Design придуманной тобой в симулинке системы и микропроцессороной системы. Там же описывается как будут общаться процессор и ваше IP ядро, а также генерятся драйвера. В теории выглядит красиво, а на практике, как всегда, встречаются тонкости... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться