[aprox 0]

Память внутренняя, двухпортовая, поэтому прочитать "а" и "б" - один такт.

 

Из 32(36)-разрядной инструкции.

 

Все массивы, структуры и тп доступны только по ссылке через переменные индексов/полей и базовые регистры(скрытые) --> непосредственно адресуемый объем памяти не превышает максимально допустимого числа переменных в одной любой подпрограмме(независимо от вложенности и тп). Устанавливаем, например, максимальное число переменных в подпрограмме(или глобальных в программе) = 127 --> 7-ю разрядами (+ дополнительными служебными) адресуем хоть 4Гб "регистровый файл на памяти" (для 32х-разрядного ядра).

А все-таки, чем вас не удовлетворяют уже готовые крутые кристаллы с ядром ARM-9 на 200 MHz? Или например крутые DSP-процессоры? Все ведь уже сделано, готово, работает и по цене ниже FPGA, на которой изобретаете велосипед. Сакральный вопрос- зачем?

[Mahagam 0]

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

делать много-много мелких регистровых файлов (?), при этом вроде можно получить практически мгновенное переключение контекста.

 

32(36) бит на команду - много кода во внутренней раме не положишь...

 

А все-таки, чем вас не удовлетворяют уже готовые крутые кристаллы с ядром ARM-9 на 200 MHz? Или например крутые DSP-процессоры? Все ведь уже сделано, готово, работает и по цене ниже FPGA, на которой изобретаете велосипед. Сакральный вопрос- зачем?

приведу простой пример - есть пачка телекоммуникационных плат, которые обрабатывают потоки E1. давно теми же буржуями просчитано, что обработка этих потоков на ПЛИС дешевле в десяток раз чем мучить их в DSP. вот стоит на этих платах плисина, крутит эти потоки, и крутит под управлением проца, которых только и делает, что принимает команды с RS232 и переводит их в приятных для плисины вид. в кратце: на проце сделан юзер-интерфейс.

спрашивается, нахрена платить $5 за проц, если можно его упихать в дальний угол FPGA и пусть он там копошится.

а к процу ж идёт свой стабилизатор, обвязка, его ж запаять нужно, прошить, проверить. и всё это далеко не бесплатно.

[aprox 0]

приведу простой пример - есть пачка телекоммуникационных плат, которые обрабатывают потоки E1. давно теми же буржуями просчитано, что обработка этих потоков на ПЛИС дешевле в десяток раз чем мучить их в DSP. вот стоит на этих платах плисина, крутит эти потоки, и крутит под управлением проца, которых только и делает, что принимает команды с RS232 и переводит их в приятных для плисины вид. в кратце: на проце сделан юзер-интерфейс.

спрашивается, нахрена платить $5 за проц, если можно его упихать в дальний угол FPGA и пусть он там копошится. а к процу ж идёт свой стабилизатор, обвязка, его ж запаять нужно, прошить, проверить. и всё это далеко не бесплатно.

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

[Leka 0]

...обычно имеется до десятка переменных обрабатывающих этот буфер (счётчик цикла, регистр для подсчёта контрольной суммы, индекс, размер массива итп), при этом сам буфер явно в регистровый файл ну никак не влезет. получается, что большая часть регистрового файла будет простаивать, а вот доступ до данных буфера будет не таким быстрым. a+=b далеко не за два такта.

И переменные, и буфер в одной физической памяти, декодеру без разницы. Данными буфера можно манипулировать через указатели(*a += *b - за 3 такта), промежуточные переменные (с += b - за 3 такта), и тд.

 

32(36) бит на команду - много кода во внутренней раме не положишь...

Зато эффективнее при интенсивной работе с памятью - за счет отказа от load/store архитектуры.

 

 

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

Софт-процессор будет маленьким.

[vetal 0]

Софт-процессор будет маленьким.

Это вам так кажется. маленький - это когда пара инструкций и примитивные вычисления через аккумулятор(например tiny16 с форума ниос). Если делать еще что-то сверху, то получится не меньше nios2/s по лутоемкости.

[Mahagam 0]

И переменные, и буфер в одной физической памяти, декодеру без разницы. Данными буфера можно манипулировать через указатели(*a += *b - за 3 такта), промежуточные переменные (с += b - за 3 такта), и тд.

эээ. что там с адресацией? буфер в 1.5к для эзернета - это 11 разрядов. sorce/destination - уже 22 разряда в команде на адрес. + разряда по 2 на вид адресации. 2*(11+2) = 26 бит в команде скушано на адресацию источник/приёмник. а как быть с адресацией на большие области памяти? лишний такт на выборку адреса?

 

Зато эффективнее при интенсивной работе с памятью - за счет отказа от load/store архитектуры.

ой берут меня сомнения.

[Builder 1]

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

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

А по поводу софт процессоров я Вам уже писал, но вы проигнорировали ещё такую тенденцию: ёмкость FPGA растёт, и уже самые маленькие FPGA часто не заняты и на 50%, спрашивается, нафиг мне ставить ещё один корпус если я могу загнать тот-же Nios в свободное место.

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

[Leka 0]

Это вам так кажется. маленький - это когда пара инструкций и примитивные вычисления через аккумулятор(например tiny16 с форума ниос). Если делать еще что-то сверху, то получится не меньше nios2/s по лутоемкости.

У меня на Спартане3 ядро с регистровой архитектурой(load/stote) занимает ~~25 лут/разряд, половина из них приходится на 2-портовый 32-регистровый файл с 2-мя асинхронными чтениями и 2-мя записями за такт. Те ~~450 лут на 18-разрядное ядро c командами типа:

a += b; // +, -, &, |, ^, ...

a = b + const; // +, -, &, |, ^, ...

A = b; // i++, i--

a = B; // i++, i--

label(a<b); // <, <=, =, >, >=

...

Для "безрегистрового" варианта выкидывается регистровый файл, взамен добавляется другая логика, ~~100 лут по предварительным оценкам, выходит: ~~300 лут для 16-разрядного и ~~500 лут для 32-разрядного ядра.

 

 

 

эээ. что там с адресацией? буфер в 1.5к для эзернета - это 11 разрядов. sorce/destination - уже 22 разряда в команде на адрес. + разряда по 2 на вид адресации. 2*(11+2) = 26 бит в команде скушано на адресацию источник/приёмник

int i, a, *buf[1500];

a = *buf; //команда адресует a, buf, i, но не *buf.

 

для души

Да. :)

[vetal 0]

У меня на Спартане3 ядро с регистровой архитектурой(load/stote) занимает ~~25 лут/разряд, половина из них приходится на 2-портовый 32-регистровый файл с 2-мя асинхронными чтениями и 2-мя записями за такт. Те ~~450 лут на 18-разрядное ядро c командами типа:

a += b; // +, -, &, |, ^, ...

a = b + const; // +, -, &, |, ^, ...

A = b; // i++, i--

a = B; // i++, i--

label(a<b); // <, <=, =, >, >=

32*18=576, т.е. для альтеры будет 1152 lut?! Это есть больше чем 32 битный nios2/s с полным набором средств разработки :)

[klop 0]

А все-таки, чем вас не удовлетворяют уже готовые крутые кристаллы с ядром ARM-9 на 200 MHz? Или например крутые DSP-процессоры? Все ведь уже сделано, готово, работает и по цене ниже FPGA, на которой изобретаете велосипед. Сакральный вопрос- зачем?

 

A u menya k vam drugoi vopros. Podskajite ARM s "normal'noi" sinhronnoi 32 razryadnoi shinoi chtob k FPGA ceplyat'.

[Leka 0]

32*18=576, т.е. для альтеры будет 1152 lut?! Это есть больше чем 32 битный nios2/s с полным набором средств разработки :)

Не понял арифметики.

У меня ядро - под Xilinx, для Альтеры делал бы совсем по-другому. Ядро бесконвейерное, все команды за 1 цикл(в тч все переходы, вызовы/возвраты из подпрограмм, чтение/запись в памяти), возможны 2 операции за 1 цикл, например:

[a++]=b; b=const //автоинкрементное сохранение в памяти и загрузка константы

a=[b--]; call_subr //автодекрементное чтение и переход на подпрограмму

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

Nios2/s - 5-стадийный конвейер, переходы за 2-4 цикла... - мне не интересно.

 

Имхо, для управляющих программ(внутри FPGA) большая часть кода приходится на if-then-else, вызовы мелких процедур и обмен с памятью, а не на линейные вычисления. Это и стоит оптимизировать.

[vetal 0]

Не понял арифметики.

Это примерная калькуляция - умножаем на 2 и получаем количество лутов затраченных на это в альтере.

 

Nios2/s - 5-стадийный конвейер, переходы за 2-4 цикла... - мне не интересно.

В указанном ядре его нет - любая команда исполняется за 5 тактов + время доступа к шине(памяти, периферии и пр., но это уже не относится к ядру).

 

В "безрегистровой" архитектуре этого не будет, но зато будет большая переносимостьи и проще будет прикрутить ЯВУ(надеюсь)

Вопрос не совсем корректно ставится - а стоит ли "овчинка выделки". Сделать ядро может практически любой, а самой сложной задачей является обеспечить это все нормальными средствами разработки!

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

 

Имхо, для управляющих программ(внутри FPGA) большая часть кода приходится на if-then-else, вызовы мелких процедур и обмен с памятью, а не на линейные вычисления. Это и стоит оптимизировать.

Я бы так не сказал. Вы слишком приземляете задачи.

Например : информацию(результат обработки информации) нужно раздать в 10 комов, каждому потребителю в своем формате и со своим протоколом, в фоновом режиме рисовать на небольшом экранчике небольшой графический user friendly интерфейс.

[Leka 0]

В указанном ядре его нет - любая команда исполняется за 5 тактов + время доступа к шине(памяти, периферии и пр., но это уже не относится к ядру).

Это Nios2/e, 6 тактов.

 

Вопрос не совсем корректно ставится - а стоит ли "овчинка выделки". Сделать ядро может практически любой, а самой сложной задачей является обеспечить это все нормальными средствами разработки!

Конечно!

 

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

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

 

Например : информацию(результат обработки информации) нужно раздать в 10 комов, каждому потребителю в своем формате и со своим протоколом, в фоновом режиме рисовать на небольшом экранчике небольшой графический user friendly интерфейс.

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

[vetal 0]

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

Все уже придумано до вас! В gcc все необходимое для этого есть и портируется он на любой проц, а lcc который я указывал выше - проще и без оптимизации :)

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

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

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

 

По информации из недостоверных источников не помню откуда взятой - профессиональное портирование gcc обойдется примерно в 50k$.

 

 

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

По растактовке - в предложенном вами методе if-then-else имеет минимальное быстродействие по сравнению с прочими оговариваемыми вариантами (рег. файл и стэк). даже простейший вариант:

ld *a; if (a== b ) :

eq *b; если равно пропускаем следующую строку

goto eq1n;

eq1:;then

...

eq1n:;код под else

...

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

Как ни крути - вы все равно сделаете тоже самое, только вверх ногами и под углом :))

[aprox 0]

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

Ну что-ж, дело молодое.

А по поводу софт процессоров я Вам уже писал, но вы проигнорировали ещё такую тенденцию: ёмкость FPGA растёт, и уже самые маленькие FPGA часто не заняты и на 50%, спрашивается, нафиг мне ставить ещё один корпус если я могу загнать тот-же Nios в свободное место.

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

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

 

A u menya k vam drugoi vopros. Podskajite ARM s "normal'noi" sinhronnoi 32 razryadnoi shinoi chtob k FPGA ceplyat'.

Я лично таких не знаю. Но сам цепляю ARM к FPGA через быстрый SPI.