Когда я начал с этим разбираться, то MicroBlaze и NIOS показались мне очень привлекательными. Когда нашел платы на Spartan, на которых крутится uClinux, вообще был счастлив.
www.atmark-techno.com/en/product/suzaku.html

Потом вниметельно посмотрел, и понял, что, IMHO, особой перспективы это не имеет.

Нормальный Microblaze с минимальным набором периферии едва-едва влазит в Spartan 3-200 - а большинство склоняется к мысли, что и не влазит, и нужен как минимум 400, а это уже камень совсем другой ценовой категории.

При этом получается довольно скромный камушек:
* !MMU - полноценного Линуха не будет, как ты не uClinux'уй
* DMA нету, а если еще и корку DMA прикрутить - вообще 1000 камень потребуется.

Что понятно - специализированное использование площади кристалла под CPU куда эффективнее. Сила FPGA не в том, что на них можно сделать стандартные вещи, а в том, что на них можно легко делать ___уникальные и специфические___ вещи!

Интересно а почему народ не ходит по другому пути:
* взять что-нибуь типа Sharp LH79520 / LH79524 / LH79525
* поставить тот же 200 спартан, и засунуть туда все, чего не хватает в основном камне.

Тот же Sharp LH79520 http://www.digikey.com 100 штук - $11.7. При это это весьма эффективный проц с 32 битной шиной, одним из самых лучших LCD контроллеров, совершенным DMA и прочая. Мы с ним два года назад работали под uCOS, и уже тогда он был с очень незначительными глюками - Cirrus EP93xx, Atmel AT91RM9200 отдыхают!

Новое поколение LH79524 / LH79525 - вообще песня. LH79520 + Ethernet, USB, I2C & NAND Boot.

Мне известно только одно решение такого класса
http://www.fh-augsburg.de/~hhoegl/proj/comet/index.html
но проект, похоже, загибается.

Что касается скорости, то 77 Мгц + FPGA - это гораздо круче, чем просто 200 Мгц без FPGA. Т.к. весь ввод-вывод можно грамотно сделать, DMA, блочные пересыки, буфера и т.д. - фактически, система не имеет ограничений по расширению при правильном использовании ее ресурсов (посмотрите назад на 10-20 лет, какие проекты делались на 386EX, когда ARMы еще не были распространены.)

Порты линуха на LH79520 / LH79524 / LH79525 наличествуют:

ftp://ftp.buici.com/pub/arm/bsp/bsp-sharplh7-1.1.1.tar.gz
ftp://ftp.buici.com/pub/arm/patch-linux-2.6.12
http://wiki.buici.com/twiki/bin/view/Main/...dSupportPackage

Вопрос: почему так никто не делает?!!!!

Видите, теперь и вы знаете.
Мы так и используем ARM7/9 + FPGA.
очень даже дёшево выходит.

МОЕ ИМХО в ответе на этот вопрос в вашей ветке на сахаре

Не знаю как у Xilinx, а у Altera NiosII(без отладочного интерфейса) помещается в ep1с3(~12$ в партии 1 штука), и работает это чудо до 70-90 MHz.
На ep1c6(6000le,~20$) или на ep2c5(5000le,15$) размещается вполне самодостаточная система, только память внешнюю желательно подключить.

Для нас важнее что-бы микросхем было поменьше, и достичь максимальную гибкость системы(если надо то используем cpu, если нет то можно реализовать достаточно мощную систему управления).
Я чаще сталкиваюсь с проблеммой недостатки io чем с недостатком логики или быстродействия, следовательно чем меньше всего подключено к плис тем лучше.

а как у ниоса с шинами ? так же смотри в мир через небольшую дырку как и микроблейз ?

Надеюсь, не надо будет форму подписывать на допуск к "тайным знаниям"?

Шина Avalon весьма компактная и отлично документирована, проблемм с ней не возникает. Вдобавок имеется хороший sopc builder,который берет на себя задачи конфигурирования системы.

Вот! И в этой ep1с3 ($12) едва ли что останется. А LH79520 в ктц-мк стоит порядка 15 в партии 1 штука, и работать он будет явно шустрее (8к кеша, как ни как, DMA и прочее). Можно взять его, и тот же ep1с3 (мне, кстати, после долгого изучения Альтера тоже больше понравилась) или EPM240 (~$6) и ловить кайф.

Ну что начнем пятничный флейм
Заранее извиняюсь за тон


вообще то uClinux подняли на многих отладочных платах

Потом вниметельно посмотрел, и понял, что, IMHO, особой перспективы это не имеет.


не надо ля-ля и передайте это тому большенству


+5$ (Spartan3-200 ~15$)


Согласен, не фантастика


Лично мне он и не нужен


Опять же "ля-ля", открываем доку по шине OPB, тратим пол месяца на изучение еще пол на ковыряние своих корок и они сами с собой станут говорить.


По моему подобными путями ходят 90% разработчиков имеющих дело с FPGA

А чем вам его дырка не понравилась, через нее ведь танк пролезет ?

Это для меня новость.

Остальное либо согласуется с моим мнением, либо дополняет и расширяет его.

Начет продвинутой шины - тут я слаб. Я пока довольно слабо разбираюсь в *HDL и прочей лабуде. Мыслю пока кетегориями схематики из MAX PLUS II.

Что интересно, встроенный ARM9 (excalibur) альтера бросила, судя по инфе на сайте.

Про шины микроблазе
PLB не рассматриваю - слишком жирная
OPB - 32р. (по моему) до 4 мастеров на шине, минимальный "такт шины" 4 такта процессора
MLB - 32р. без каких либо наворотов, ограничения по числу слейвов (число не помню) может сильно сказаться на возможной частоте работы устройства (2 - 4 - нормально), минимальный "такт шины" 1 такт процессора.

хмм ну через FSL может быть и пролезет, но сидеть на нем может только user defined переферия, а камушек гребет код через OPB .
Да и тех же FSL всего 8 сосок, итого 4 дуплекса, не сахар .

ИМХО минус в том, что для кода и данних ИМХО желательна отдельная быстрая шина, а не OPB. Чтобы шустренько код из озу исполнять.

Хотя может быть я ошибаюсь, поправте

Все так, забыли только кеш упомянуть, который от части разгружает шину.
Я думаю у NIOS-а аналогичная ситуация, vetal поправь если не так.

ни и что что кеш ? кеш нужно чем то забить + кормить ресурсом ФПГА еще и систему контроля заполнености кеша,
ИМХО микроблейз хорош, когда весь его код можно уложить в кеш и практически за кодом во внешнюю память не обращаться.
Но как только начинаем грести код из внешней памяти, то микроблейз отдыхает

Вообще для меня было новостью, что у всех этих софтпроцов шина - довольно проблемная вещь

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

Не уверен на 100% но думаю можно будет чделать чтоб из SDRAM в кеш грузилась сразу страница, тогда издержки на шину станут мизер.
Ну или как вариант садить память на LMB, только специфика появится.

Кэш в NIOS имеется для данных и программ, я ставил только для программ.
Кэш так же имеется в контроллере sdram.

в микроблазе то же два кеша
насчет кеша в sdram, там есть опция доступа к sdram в страничном режиме, как это работает не знаю

ну ведь это же не выход ?
это мы получаем самый тупой вариант кеша,
а хотелось бы асоциативный кеш + систему предсказания ветвлений в таком случае.
А вот под это уйдет много ресурса

кеш в микроблазе не хуже и не лучше чем у других процессоров его роста


ну тогда ставьте себе pentium4 за 15$

Кстати, забыл.
В микроблазе можно память на FSL посадить, тогда шина разгрузится, имеется такая корка для sdram.

[quote=3.14,Aug 5 2005, 07:55]
а хотелось бы асоциативный кеш + систему предсказания ветвлений в таком случае.
А вот под это уйдет много ресурса
[/quote]
ну тогда ставьте себе pentium4 за 15$

[/quote]

Вот тут мы и забываем про тему, я не спорю для задач управления и не сложного расчета микроблейз пойдет, но только в случае если основной код будет иполняться из кеша или BRAM. Как только появляються обращения к памяти, да еше и не большими кусками и по разным адресам то все тушите свет.

ИМХО не стоит ждать чудес от софтовых ядер

хмм а вот это интересно,
а для памяти кода или данных ?

Не правда, niosii/f +sram+sdram=1/2 кристалла, т.е. куча места для периферии.

Вау! Так экономично? А если прикурить кеш, о чем тут народ справедливо поведал?

я уже говорил, если критично ставьте память в LMB. Вам лень -> процессор - кака.

к тому же у микроблаза еще есть "задел" - доступ до кеша 2 такта , не понятно что мешает вложиться в 1 такт.


а их никто и не обещает

Я впечатлися! Я как-то интутивно подозревал, что все эти софт процы годны для того, чтобы реализовать алгоритим, который в терминах HDL сложно описать (или оно займет много ресурсов). А Linux на них маркетологи поставили!

Хмм сдаеться мне что по листингу темы, я первый сказал про исполнение кода из кеша и только из него ))))



Хмм см. самый первый пост темы

очень кстати, у микроблаза на Sparan3-200 = MB+UART+sdram+IO ~60% без кеша

не понял, что вы этим хотели сказать?

< 1 k .
Надо искать компромиссы между обьемом памяти используемой периферией и памятью для процессора.

Если брать cycloneII вместо cyclone, в 2 раза увеличение ресурсов.

Это еще не все, при нужной комбинации галочек, fitter размещает на кристалле 106% от его номинального обьема. В это время происходит весьма мощный ресинтез.

Я заметил одну особенность-примерно после 80-90 Mhz микросхема начинает греться, а на 110 стала греться по страшному, посему решил больше 100 MHz не давать.

микроблейз разводится на 50МГц (итого 25 MIPS при работе из кеша), вернее его можно на 100 развести но с ростом периферии которая садится через шину OPB и весь кайф обламывается . Но все равно, думаю при желании можно эдак на 70МГц развести, у меня просто внешний генератор на 50.

кстати,а у NIOS аппаратное умножение есть?
у микроблейза в4 добавили еще модуль плавающей тосчки.

Я хотел сказать, что по моему вы считате что я хаю микроблейз и вот такой сякой, не разобравшийся сижу в теме.
ИМХО микроблейз можно и нужно пользовать, но с оговорками и не ждать от него производительности того же п4.
Т.к. я больше сижу на вычислительных задачах, то для меня лучше всего использовать микроблейз толкьо выгребая код из кеша и/или исползуя его как большой управляющий/комуникационный автомат.

Если что то сказал не так, просьба сильно не обижаться, конец рабочего дня как никак, и пива под рукой нет

если откровенно, когда я только решился перейти на мкроблейз, меня то же доступ очень огорчал, но как говорится "стерпится - слюбится"

хмм странно у меня на борде стоит v4lx25-10 в реф.дезайне шем микроблейз на 100 МГц. а по отчетам выходило что до 130-150 можно раскочегарить ядро + уарт + модуль ввода вывода.
Правда код я исполнял из BRAM

Умножение присутствует для мсх, у которых есть модули аппаратных умножителей. Для остальных- программное. Деление на сколько помню есть для всех, но оно сильно снижает производительность.
Главное, что бы все навороты с математикой поддерживал компилятор, иначе от них толку мало.

дык то виртекс (у меня Spartan3-200 -4), видимо не зря говорял оптимизировано под ...

Я думаю, что не все из присутствующих работают с микросхемами класса Virtex4/stratixII.

Я к примеру говорю базируясь на cyclone 1.

деление в микроблайзе то же здорово расконвейерено (по моему 48 тактов)
ну а насчет математики и компилятора, все вроде "чики-пуки"

Пиплы, а мы вообще то обсуждали-то??? Тут такое водится

http://www.gaisler.com/products/leon2/leon.html
http://www.mdforster.pwp.blueyonder.co.uk/LeonCyclone.html
http://emsys.denayer.wenk.be/?project=empro&page=cases&id=14

Кто-нибдь что-либо внятное сказать могет? Я как-то в осадок выпал...

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

Согласитесь, что применение того или иного камня в проекте в первую очередь зависит от его доступности (обьем, сроки и график поставок...), а уже только потом от цены и функциональных особенностей (тут почти всегда существуют как минимум два-три варианта от разных производителей). Особенно с этим сложно в ВПК.
В этом смысле выгодно использовать ПЛИС и переносимое функциональное описание системы, (которое в случае чего можно будет портировать на другую ПЛИС, ASIC или БМК в крайнем случае). То есть при гибком software делается гибкий, переносимый hardware.

ЗЫ Только до верхов это никак не доходит: вместо того чтобы сделать линейку отечественных ПЛИС - сплошные окры на стопервый клон 8051. Сейчас ведь сделать качественный российский ПЛИС и паралелльно завод субмикронный построить - все зацветет!

Не понял, а что Вас удивило?

По поводу двух тактов доступа к кешу у микроблейза.
Вчера полазил по исходникам микроблейза, сделал вывод - можно просто тактировать модули кеша от удвоенной тактовой частоты процессора, тогда доступ до кеша должен свестись к одному такту.
Правда чтоб это толком проверить надо лицензию на микроблейз иметь (на исходники), а к EDK7.1 старое лекарство не подходит

В Leon* удивило:
* SPARC V8 - это не микроблейз недопатченный. Это ПРОЦЕССОР. Сертификат от SPARC - это, согласитель, не то же самое по классу, что OPEN32 с опенкоресов.
* SPARC под GPL - это вообще, IMHO, мечта вояк всяческих, наших в частности, и всех, кто "долгоиграющие" системы делает. Описал все на VHDL, и можешь спать спокойно: и через 20 лет возьмешь делателя FPGA/ASIC и запустишь старый софт без проблем.
* камушки для этого леона пока нужны довольно дорогие, но, с учетом Spartan3E / Cyclone II, все это совсем скоро войдет в допустимый диапазон цен для массовых контроллеров.
* а из этого большой филосовский вывод следует - учить *HDL. Ибо скоро, возможно, будет нетриваильная ситуация. Производителям чипов будет выгодно делать "универсальные" чипы типа FPGA, не занимаясь проектированием своих процов. Мелко и среднетиражные конторы будут сами компилировать свои проекты. Ну у монстры, которые сейчас, например, TI OMAP юзают, будут делать кристалы под себя.

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

Типа программеры пишут в некоей абстрактной объектной модели, HDL'щики реализуют эту модель в железе (то бишь в кремнии), кустомеры исправно платят за все это ("Винни, а кто их, свиней, спросит?"). Все при деле . Проиводителям чипов легче выбивать денег на строительство очередной фабрики 0.00000хз сколько микрон.

Еще про Leon'ы. Очередной раз уши Европейского космического агенства торчат. Сколько же они полезного сделали! В космос могут уже и не летать. Один проект http://www.rtai.org/ чего стоит...

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


По моему Вы что то путаете, MicroBlaze никакого отношения к OpenCores не имеет, это родное ядро Xilinx, которое постоянно развивается от версии к версии.
Взглянув на перечень фьючерсов я ничего не нашел в Leon чего бы не было в MicroBlaze.


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

Далее по вашу тексту, примерно к такому выводу я и пришел с пол года назад, поэтому и мучаю микроблейз, а не штурмую ARM.

Есть такое! Я это понимаю. Может, мое прозрение еще впереди, но я стремлюсь, особенно в принципиальных вещах, смотреть с разных точек зрения.

Есть моя точка зрения, далекая от категорий "FPGA мыслящих". В этой ветке я получил массу информации, теперь потихоньку ее перевариваю. Кое на что я уже могу посмотреть за пределами мышления "ARM'о штурмователя". За что премного благодарен народу.