Нужен небольшой софт процессор для обслуживания юзер-интерфейса. Большая производительность не нужна, хватило бы и 8-ми разрядного. Основные требования - нормальные крос-тулзы для программирования на Си, небольшой размер, бесплатность. NIOS бы отлично подошёл, но он требует лицензии. В некоторы странах это важно. Предпочтительно бы стандартное ядро типа AVR или 51-х. На opencores много всякого - но что-то всё не то. Не знаю что выбрать. Направьте пожалуйста на путь истинный...

от латиса взять
MICO8
или
MICO32
и под себя заточить

вот ещё
ZPU ?
правда он не 8-и битный
Features

* Small size: 442 LUT @ 95 MHz after P&R w/32 bit datapath Xilinx XC3S400
* Wishbone
* Code size 80% of ARM Thumb
* GCC toolchain(GDB, newlib, libstdc+)
* eCos embedded operating system support

В каком чипе собираетесь его разместить? Какие ресурсы предполагаете ему отдать?

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

Тема неоднократно поднималась! Пользуйтесь поиском.
PS: tiny16, OpenUp...

Хорошо бы узнать ответы.

И еще пара вопросов:
- кто-то реально применял в FPGA от Альтеры какие-либо софт-процессоры отличные от Ниосов? Какие реальные результаты и впечатления?
- чем лучше все отличное от Ниоса, если такие софт-процы имеется? Какая выгода в освоении этого нового, при дефиците времени?

Эх, "точить" то вот нет желания.

Чип то хоть и жирный весьма - EP2C35, но процу много не отдам. Жадный я. Больше всего жалко внутренней памяти. Если серьёзно - можно конечно и отдать несколько тысяч LUT, есть пока лишние, но я не вижу смысла тратить много ресурсов на такую задачу. Надо реагировать на кнопки, переключать режимы работы логики, делать калибровку, связь с компом и прочие мелочи.

Что-то на этот xsoc16 в гугле всего одна ссылка на www.fpgacpu.org Чего он такой не популярный?

Да я тут уже почти всё перечитал. Много всяких софтпроцов есть. Разбираться со всеми нет никакого желания и времени. Мне хочется взять один да и пользоваться, и чтоб побыстрее освоить. Пока понятнее всего дела обстоят с NIOS-ом. И документации куча, и софт и всё что хочешь. Если бы не лицензия...
А тему еще одну создал потому что лень разбираться в этих десятках существующих процов.
И еще потому что вот вопрос:

На то она и халява, что на блюдечке не подают! Хотите дешевле - разбирайтесь, не хотите разбираться - покупайте.

и вот ещё
http://electronix.ru/forum/index.php?showtopic=40408
и

никакой выгоды.
не хотите точить - платите бабки и наоборот, вообщем vetal уже всё сказал

А есть тут люди которые разбирались с AVR_core c opencores.org ?
Вот оно http://www.opencores.org/projects.cgi/web/avr_core/overview

Стоит ли на него "подсесть"? Или есть более правильные варианты.

PS. пардон за назойливость. мой опыт в softcore никакой, поэтому времени на разборки придётся потратить не мало. жалко тратить в пустую.

хм...как то хохмы ради собирал оттуда pavr...заняло поболее ниоса 3-4 тыщи...и это без возможности отладки и т.д.и т.п.
авр от BSACPLD весит 2400-2600 во втором и третьем циклоне
кто из них более правильный х.з...

По мне, так если Вам принципиально подходит NIOS, то берите его, не такие он и большие деньги стоит, зато все средства отладки и разработки получаете сразу.

Если это то что я думаю то неплохой вариант. Правда ета штука более подходит для ASIC чем для FPGA. Второй недостаток - JTAG OCD там не бесплатный. Люди ваявшие на етом ядре ASICи платили деньги именно за него. Лучше всего просто связаться с автором и все прояснить.

Могу дать два взаимоисключающих совета:
1. Отладку софта через джей-таг может обеспечить только Альтера - поэтому Найос - вне конкуренции.
Лично я бы никогда не взялся городить какой-либо опен-софт-кор без обеспечения возможности отладки последующих программ - пусть даже и простых: в конце-концов себе (и вашему предприятию!) дороже станет.
2. Если все-таки денег на Найос нет - то я смотрел бы в сторону резидентных ЮАРТ отладчиков-мониторов, которыми пользовались все у кого не было денег на внутрисхемные эмуляторы в эпоху до появления джей-тагов. Такие мониторы были, например, для 80С188 или для 8051. Достаточно взять любой из 8051 коров, приделать к нему ЮАРТ, небольшую отладочную память (прямо в плисе) и использовать (приспособить) готовый такой монитор так, как будто у вас стоит обычный внешний 8051. Думаю, что сами мониторы можно найти в сети.
И еще: вариант отладки софта через хардварный симулятор (Моделсим) рекомендую даже не рассматривать - сплошной геморрой, я, например, это уже проехал. Сначала это выглядело красиво, а потом обрыдло! (Другое дело отлаживать хард через софт встроенного в плис просессора, если он уже присутствует в системе и работоспособен).

если речь идёт о том что - взял ядро и начал работать-отлаживать, то я согласен с вами.
тоесть без лишнего гемора только с ниос можно возиться
только вот у альтере есть такая штука как virtual jtag
описание тут
http://www.altera.com/literature/ug/ug_virtualjtag.pdf
а вот тут идёт обсуждение оного(leon3+virtual jtag)
http://electronix.ru/forum/index.php?showtopic=26941

У кого есть регистрация на www.opencores.org пожалуйста залейте на ftp папку с ZPU и папку с FPU (FPU100). Спасибо.

Stas
а что там уже за регистрацию деньги требуют????

Заливается в /pub/FPGA/_IPcores_/SoftCores
Добавление: Залил.

2 Doka: Пытался получить пароль в течении недели - не дождался.
2 Makc: Большое спасибо.

Stas
значит проверку на _не_робот_ не прошли, судя по тому что мне в течении суток выслали - имхо, там всёже человек сидит валидирует: проверяет осмысленность введённых данных.

Еще один вариант. Altium Designer включает несколко корок с очень хорошими
отладочными средствами, если конечно пользоваться их тулзами. Есть е частности
51 а так же z80 которым я пользоввался и пользуюсь. Там же неплохой С компилятор
для них.

А вот когда все (программа) отлажено, можно подменить CPU на одноименный с opencores.
Т80 например очень неплохо работает.

Советую посмотреть здесь тред "Не дурят ли нашего брата". Там был предложен наиболее эффективный по затратам ресурсов и времени вариант- разместить небольшой ARM микроконтроллер вне FPGA и связать их между собой, например по SPI. Если совсем уж грамотно делать, то на этот-же микроконтроллер возложить хранение конфигурации и начальную загрузку FPGA. Для вашего случая клавиатур, дисплея и связи с компом- это идеальное решение. Плюс, получаете неплохую защиту от сдира проекта.

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

Если раньше не имели опыта с микроконтроллерами, то конечно будет нелегко в освоении. Но, мне кажется, в этом случае(отсутствие опыта с микроконтроллерами) осваивать софтпроцессоры FPGA будет еще трудозатратнее.

Мой опыт с микроконтроллерами в разы больше чем с FPGA. Там все налаженно-накатано. И я прекрасно представляю как просто работается со стандартными контроллерами. Куча компиляторов, отладчиков, документации и готовых наработанных библиотек. Но бывает и так что можно использовать только softcore. Поэтому и появилась эта тема.

Если не секрет, то какие практические обстоятельства жизни принуждают только к софткору? Я очень интересуюсь этим вопросом и так до конца его и не выяснил.

http://electronix.ru/forum/index.php?showt...mp;#entry438521

К примеру, защита проекта от супостата с использованием SHA-1.

Причина 1
Есть готовый девайс. Внешних процессоров там нет а есть большая FPGA. Надо сделать User Interface.
Есть другой девайс с самой маленькой FPGA EP2C5 и в ней 4/5 места свободно, и для удобства реализации протокола в неё бы мелкий проц всунуть было бы удобно. Зачем тут внеший?

Еще можно придумать много причин для разных случаев, но одной этой достаточно.
И это уже было в теме "не дурят ли нашего брата" да и в других тоже периодически вспыхивают религиозные войны.

Железный аргумент. Подозреваю, что он единственный в поддержку софтпроцессора в FPGA.

видимо не судьба вам понять

и если бы вы сходили по ссылке которую вам дал slog
то вы бы наверное/может быть/скорей всего поняли о чём вам "талдычат", но вам как и всегда просто нас...ть на аргументы/доказательство и прочее...
вообщем да... увы и ах...
а про тему не восприятия верилога это ваще песня

По ссылке, которую выдал Leka я ходил, смотрел и понял, что речь идет о готовом в железе изделии, внутрь, которого пытаются влезть через софт. Хард переделке не подлежит. Hикакого отношения данная ситуация к вопросу об эффективности софтпроцессоров в разработках на FPGA не имеет.

тоесть ваша логика в данном случае такова
1) Обана! есть готовый девайс! Хорошо!
2) Опа! а где же Z80 снаружи? не эффективно! без него нельзя GUI сделать!
3) Паём снаружи Z80! Ура! Вот так эффективно!

вообщем..желаю вам того же что и des00 - Удачного заката солнца в ручную!

Рекомендую прекратить флуд
С уважением, модератор

Пример: 2 канала АЦП дают 2Гбайт/сек, не меньшую пропускную способность должна иметь подсистема памяти, в сумме - не менее 4Гбайт/сек --> ПЛИС в БГА корпусе. Чтобы не тормозить быстрый внешний процессор, нужна дополнительная параллельная шина, это потенциальный 2Гбайт/сек канал, выбрасываемый на ветер: разводим ПЛИС на 6Гбайт/сек, а используем только 4Гбайт/сек. Если же использовать софт-процессор - достаточно развести ПЛИС на 4Гбайт/сек. А ставить на последовательный интерфейс медленный внешний микроконтроллер - бессмысленно в таких задачах.

Вы не ошиблись с порядком цифр производительности? Во-вторых, речь изначально шла о применении софтпроцессора для целей управления и мониторинга процессов внутри FPGA, когда никаких гигабайтов в секунду вовсе не требуется.
Мне представляется, ставить софтпроцессор на перекачку данных столь высокой производительности - бесперспективная затея. Его программа вся будет состоять из двух инструкций в цикле. И никаких других действий в него уже не втиснуть, никаких дополнительных устройств. Hу, и зачем тогда нужны, все эти навороты с софтпроцессором, когда достаточно простенькой state_maсhine?
Я по-прежнему считаю, что единственным неубиваемым аргументом в пользу софтпроцессоров является случай модификации готового и неизменного HW с FPGA.

Вы забываете, что самые маленькие FPGA стали большими и не всегда на 100% заполненными.
Скажите, нафига тогда козе баян, если я могу использовать свободные ресурсы для организации всего внутри?
И вообще, Вы пользуетесь не верными логическими выводами, Вы придумываете частный случай когда что-то нельзя, не эффективно или не удобно сделать и распространяете это на общую ситуацию.
А это не есть верно исходно.
Надо быть пластичнее и подходить к задаче с позиции: а как решить данную задачу максимально эффективно с заданными исходными? И от этого уже плясать.
А то устроили тут крестовый поход на xHDL и софт процессоры. Софт процессоры это не понацея, а одтн из вариантов решения задачи.


По теме беседы, к автору: а что, купить NIOS не дешевле выйдет (если нужна лиц. чистота), чем маятся с ядрами, которые требуют адаптации? Тем более что стандартные ядра (AVR или 51-х) места будут занимать не меньше Ниоса, а маленькие не будут иметь того набота средств разработки и отладка как Ниос. Или я что-то не понимаю?

Это один из аргументов, но единственный, есть и другие. Они вытекают из концепции построения систем на кристалле (SOPC), с ее громадными возможностями.
Может быть, проблема в отсутствии ясных методик построения SOPC.
Софт процессоры это отдельная тема, достаточно многообразная. Вы их уже использовали, какие?

Последнее предупреждение участникам, прекращайте флуд!
Дальше буду использовать карательные меры - выпишу пилюли и закрою тему.
Aprox кандидат №1 на пилюлю если не прекратит флудить
С уважением, модератор

Это и имел в виду, поэтому написал: "потенциальный 2Гбайт/сек канал, выбрасываемый на ветер", те пустая трата ресурсов чипа и печатной платы - только для того, чтобы вынести наружу относительно медленную обработку. Удельная стоимость БГА пина(даже без учета платы и монтажа) очень высока, например: FPGA кристалл в FG320 стоит столько же, сколько вдвое больший кристалл в FG256 --> с софт-процессором получается дешевле.

Спрошу не флуда ради, а уразумения для- зачем нужен 2Гбайт/сек канал связи с медленным внешним процессором? Разве не сгодится обыкновенный 4-х проводный SPI интерфейс? Четыре любых свободных пина BGA- это действительно так напряжно? И внутри FPGA никакого софтпроцессора не потребуется. Достаточно будет встроить в проект столько сдвиговых регистров, сколько требуется по задаче.

Если хватает SPI - скорее всего придется выбирать между 8-разрядными решениями(например: AVR и софт-ядро уровня PicoBlaze), а не 32-разрядными(например: ARM и NIOS). Если есть куча кнопок, ключей, светодиодов и тп - имеет смысл отдать все это хозяйство внешнему 8-разрядному микроконтроллеру. Если надо слить дамп системной памяти - проще будет софт-процессор. Так что оправданным м/б одновременное применение и софт-процессора, и внешнего микроконтроллера, и связать их по SPI.

Консенсус!

Ok!

2ALL
Мысли вслух... примерные оценки скорости случайного доступа по SPI:
1) внешним AVR к 16-разрядным внутренним ресурсам FPGA: 10МГц(клок)/32бита(адрес+данные)=0,3МГц;
2) внутренним софт-ядром к 32-разрядной памяти программ на конфигурационной флешке: 50МГц(клок)/64бита(инструкция+адрес+данные)=0,7МГц.
Скорости сопоставимые, и напрашиваются софт-ядра, ориентированные на исполнение инструкций из SPI flash...

про возможности кеширования не забывай. и выборку данных из флешки по подряд идущим адресам быструю...

Это понятно, задумался о другом - микропрограммной эмуляции стандартных микроконтроллеров. Например, при 50МГц тактовой имеем более 50 микрокоманд на каждую эмулируемую команду - можно неторопясь объехать все колдобины(неудобные для FPGA особенности архитектуры МК). В идеале - для эмуляции разных МК меняем только микропрограмму в блочной памяти FPGA. От "подносчика патронов" большая скорострельность не требуется.

эээ. то есть получить аналог х51 машинки? по 50 тактов на команду? но зато эмулируем любой камень? а смысл?

з.ы. дописываю мсп430 ядро. осталось только INT/RETI пару дописать. как допишу - стану оптимизировать, а может и жтаг попробую слепить.

А какой смысл в этом (з.ы. дописываю мсп430 ядро.)?
Для души или есть необходимость по совместимости бинарно?

а какой смысл делать несовместимым? у меня как-то нет желания корячить GCC для новой системы команд, или писать свой компилятор асма.

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

Свой настраиваемый ассемблер желателен, имхо, если от софт-процессора требуется компактность и быстродействие - стандартные архитектуры плохо ложатся на FPGA. У меня тоже хобби - кучу архитектур перепробовал, пока не надоело. Остановился на той, которая позволяет хоть как-то приблизить синтаксис ассемблера к синтаксису ЯВУ. Например,

вместо стандартного:

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