Aprox, да даже в самый дешевый циклончик можно засунуть три ниоса, и еще немного места останется. Не всегда нужен внешний микроконтроллер, тем более через SPI. Это уже сто раз обсуждалось, и не зачем так навязчиво навязывать свою точку зрения. Нравится отдельный проц - применяйте. Я тоже так делал не раз. Но у проца внутри тоже есть свои плюсы. И иногда они перевешивают. И какой вариант будет выгоднее - решать тому кто будет это реализовывать. Поверьте, проц внутри тоже имеет право на существование.

Не совсем понял зачем кивать на стратиксы, у них своя ниша, для бюджетных проектов - циклоны.
И посмотрите, сколько ячеек есть в самом маленьком 3-м циклоне, найдётся куча ситуаций, когда они будут на половину использованы. Не вижу смысла в такой ситуации использовать внешний проц, если хватает Ниоса. И эта тенденция будет прогрессировать. Ваша позиция имела смысл лет 5 назад, когда микрухи были маленькими по ячейкам.
Поэтому на сегодняшний день вопрос о ненужности таких ядер IMHO не стоит, нужны они.
Вопрос в том, чтоб применить их там, где они проект облегчают по себестоимости или другим параметрам. А тут универсальных советов нет, нади по ситуации смотреть, на то мы и инженеры

Бростье вы это дело, уважаемому форумчанину Aprox объяснять что либо из этой области или спорить с ним бессмыслено. Это приведет к только закрытию темы модератором.

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

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

ваша крупнейшая ошибка в том, что вы не смотрите дальше собственного носа, абсолютно. поясняю:
а) вам кажется, что в вашем проекте невозможно использовать симуляцию, и вы заявляете что симуляция вообще ненужна никогда и никому.
б) вы ведёте проект с единичным тиражом, и лечите тут всех, что необходимо оставлять кучу резерва.
но подумать шире, и понять, что если изделие выпускается партией хотя бы 1000 штук, и устанавливается по всей стране, то никаких наращиваний и модернизаций устройства особо и не предвидится, вы не в состоянии. и что в этом случае резерв выливается в переплату денег, и что заказчик может уйти к более рачительному разработчику вам тоже не видно.

свободные ресурсы FPGA могут быть по одной причине - какой-то другой тип ресурсов занят полностью. например в одном из моих проектов выбор XC3S100 вместо XC3S50 был обусловлен только количеством блочной памяти. а это значит, что LUT`ов свободно было море, и что замена внешнего проца на софт-ядро - это дополнительная экономия денег.

Опять религиозная война начинается?
Если обсуждение не войдёт в нормальное русло тема будет закрыта
С уважением, модератор

Сравниваю "безрегистровую" и регистровую архитектуры мелких софт-процессоров... Пример - работа с памятью:

Сообщение отредактировал Leka - Oct 17 2008, 15:20

Так вам мухи или котлеты? Если делать как вы говорите, то регистровая архитектура(!) выигрывает 5 к 8, т.к. любая команда исполняется за 1 такт тем более в оптимизированном по dataflow ассемблерном коде.
Вот если бы вы затронули тему сохранения контекста, которого нет(или минимален) в предложенном вами варианте (похоже, единственный весомый аргумент) Вот только память - она ведь не только быстрая бывает, но и большая и тут уже надо смотреть от чего проку больше.

"Безрегистровое" ядро может проиграть регистровому не более, чем в 2 раза - по тактам, зато может выиграть в 7 раз - по плотности кода: [code]
//"безрегистровое": 1команда 4такта
*a = *b + *c

//регистровое, "пустой магазин": 7команд, 7 тактов
r1 = b
r1 = *r1
r2 = c
r2 = *r2
r2 += r1
r1 = a
*r1 = r2

Те по минимаксной стратегии "безрегистровое" ядро предпочтительнее.

Шар - вид слева, шар - вид справа...

Последние ваши расчеты мне не понятны.
Предлагаю подитожить немного:
1. С точки зрения кода - предложенный вами вариант является регистровым процессором с вынесенным относительно ядра виртуальным регистровым файлом(со всеми вытекающими плюсами по эффективности использования).
2. С точки зрения быстродействия с внешней памятью ввиду п.1 быстродействие будет более зависимо от типа используемой памяти(Для примера - произвольный доступ к дешевой dram памяти составляет примерно 5-6 тактов)

MSP430:

паритет. либо у MSP кода есть выигрыш в 1 такт (это если jnz за такт, как у меня)
что касается размера кода - четыре 16-ти разрядных слова. что опять же меньше чем три 32-х разрядных.


что-то мне подсказывает, что такая архитектура, если её грамотно реализовать, без проблем заведётся на 100+ MHz. даже в чахлом спартане/циклоне.

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

Так и есть

только при этом:
а) мало полезных действий за такт. то есть особо выигрыша от высокой частоты не получаем
б) дюже разреженный код. из этого вытекает жирный недостаток - если доступ к памяти медленный - проигрываем всем остальным вчистую.

а) Вы хотите за 1 такт что-то большее, чем R3=R1+R2? Это идеология всех современных ядер, начиная от микроблэйзов, ниосов, армов и заканчивая спарками.
б) Память в любой системе - слабое место. Дюже это сколько?

Что делаю:
- фон-неймановская архитектура, 32 разряда команда/данные
- внутренняя 2х-портовая память команд/данных
- трехоперандная система команд
- минимальный набор инструкций (алу: + - & | ^ div2, переходы: < <= == != > >=) - 2..4 такта в зависимости от типа адресации (a,*a,*a[b], proc, *proc).
Примеры:
a = b + c ... *a = *b ^ *c
a += *b[c] ... *a[b] ^= *c
label(a < B ) ... label(*a >= *B )
proc(a) ... *proc(*a) - переход на подпрограмму с передачей аргумента.
Написано и проверено на синтезаторе 3/4 кода, вроде укладывается в ожидаемые <500лут, >75МГц для Спартана. Сначала хотел 16-разрядное АЛУ, но для фон-неймановской архитектуры появляются лишние мультиплексоры(и задержки), поэтому отказался пока от такого варианта.

Сообщение отредактировал Leka - Oct 20 2008, 11:11