[slog 0]

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

[Builder 1]

Да, тенденция наращивания ресурсов FPGA безусловно заметна. Hо, одновременно, заметна и тенденция возрастания стоимости таких монстров. Так например, я считаю, что стратиксы от Altera недоступны по цене для мелкого разработчика. И сколько еще потребуется времени ждать, пока они подешевеют до разумных цен- неизвестно. Таким образом, тендеция наращивния ресурсов на самом деле торпедируется тенденцией увеличения стоимости. А пока, гораздо выгоднее использовать какой-нибудь простенький циклончик в комбинации с внешним микроконтроллером, тоже за копейки. Причем, одновременно получаешь такие выгоды, которые недостижимы в системах на одном кристалле.

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

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

Поэтому на сегодняшний день вопрос о ненужности таких ядер IMHO не стоит, нужны они.

Вопрос в том, чтоб применить их там, где они проект облегчают по себестоимости или другим параметрам. А тут универсальных советов нет, нади по ситуации смотреть, на то мы и инженеры :)

[des00 25]

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

 

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

 

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

[aprox 0]

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

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

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

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

Поэтому на сегодняшний день вопрос о ненужности таких ядер IMHO не стоит, нужны они.

Вопрос в том, чтоб применить их там, где они проект облегчают по себестоимости или другим параметрам. А тут универсальных советов нет, нади по ситуации смотреть, на то мы и инженеры :)

Здесь консенсус. Ситуацию действительно надо оценивать трезво.

[Mahagam 0]

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

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

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

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

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

 

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

[Omen_13 0]

Опять религиозная война начинается?

Если обсуждение не войдёт в нормальное русло тема будет закрыта

С уважением, модератор

[Leka 1]

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

  
//копирование массива
//while(src <= pmax) *dst++ = *src++;

//"безрегистровая" архитектура
//цикл: 3команды, 8тактов
//ofs = dst - src
loop: *src[ofs] = *src //4такта
src++ //2
loop(src <= pmax) //2

//регистровая архитектура - Nios2/e
//цикл: 5команд, 30тактов
loop: c = *src  //6тактов
src++  //6
*dst = c  //6
dst++  //6
loop(src <= pmax)  //6

Изменено 17 октября, 2008 пользователем Leka

[vetal 0]

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

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

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

[Leka 1]

"Безрегистровое" ядро может проиграть регистровому не более, чем в 2 раза - по тактам, зато может выиграть в 7 раз - по плотности кода:

//"безрегистровое": 1команда 4такта

*a = *b + *c

 

//регистровое, "пустой магазин": 7команд, 7 тактов

r1 = b

r1 = *r1

r2 = c

r2 = *r2

r2 += r1

r1 = a

*r1 = r2

 

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

[vetal 0]

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

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

 

Последние ваши расчеты мне не понятны.

Предлагаю подитожить немного:

1. С точки зрения кода - предложенный вами вариант является регистровым процессором с вынесенным относительно ядра виртуальным регистровым файлом(со всеми вытекающими плюсами по эффективности использования).

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

[Mahagam 0]

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

  
//копирование массива
//while(src <= pmax) *dst++ = *src++;

//"безрегистровая" архитектура
//цикл: 3команды, 8тактов
//ofs = dst - src
loop: *src[ofs] = *src //4такта
src++ //2
loop(src <= pmax) //2

MSP430:

loop1:    mov.w    @R12+, offset(R12) // 5 тактов, один из которых именно для
                              // mov можно исключить (зазря читается регистр
                              // назначения, так как mov выполняется так же как и
                              // add, sub, or, and, etc.)
                              // разве что размер ядра увеличится и частота упадёт
        cmp.w    R12, R13          // 1 такт
        jnz        loop1              // 2 такта, но в моей реализации - 1.

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

что касается размера кода - четыре 16-ти разрядных слова. что опять же меньше чем три 32-х разрядных.

 

//регистровое, "пустой магазин": 7команд, 7 тактов

r1 = b

r1 = *r1

r2 = c

r2 = *r2

r2 += r1

r1 = a

*r1 = r2

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

 

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

[vetal 0]

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

Так и есть :)

[Mahagam 0]

Так и есть :)

только при этом:

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

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

[vetal 0]

только при этом:

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

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

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

б) Память в любой системе - слабое место. Дюже это сколько?

[Leka 1]

Что делаю:

- фон-неймановская архитектура, 32 разряда команда/данные

- внутренняя 2х-портовая память команд/данных

- трехоперандная система команд

- минимальный набор инструкций (алу: + - & | ^ div2, переходы: < <= == != > >=) - 2..4 такта в зависимости от типа адресации (a,*a,*a, proc, *proc).

Примеры:

a = b + c ... *a = *b ^ *c

a += *b[c] ... *a ^= *c

label(a < B ) ... label(*a >= *B )

proc(a) ... *proc(*a) - переход на подпрограмму с передачей аргумента.

Написано и проверено на синтезаторе 3/4 кода, вроде укладывается в ожидаемые <500лут, >75МГц для Спартана. Сначала хотел 16-разрядное АЛУ, но для фон-неймановской архитектуры появляются лишние мультиплексоры(и задержки), поэтому отказался пока от такого варианта.

Изменено 20 октября, 2008 пользователем Leka