Порекомендуйте какое-нибудь softcore, Для Altera Опции

[slog]

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

[Postoroniy_V]

Нужен небольшой софт процессор для обслуживания юзер-интерфейса. Большая производительность не нужна, хватило бы и 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

[zltigo]

Направьте пожалуйста на путь истинный...

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

[des00]

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

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

[vetal]

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

[608]

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

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

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

Сообщение отредактировал 608 - Sep 2 2008, 08:54

[slog]

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

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

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

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

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

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

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

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

Какая выгода в освоении этого нового, при дефиците времени?

[vetal]

А тему еще одну создал потому что лень разбираться в этих десятках существующих процов.

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

[Postoroniy_V]

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

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

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

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

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

Какая выгода в освоении этого нового, при дефиците времени?

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

[slog]

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

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

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

[Postoroniy_V]

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

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

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

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

[Builder]

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

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

[klop]

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

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

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

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

[maior]

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

[Postoroniy_V]

Могу дать два взаимоисключающих совета:
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

[Stas]

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

[Doka]

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

[makc]

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

[Stas]

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

[Doka]

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

[alexf]

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

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

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

[Aprox]

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

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

[slog]

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

[Aprox]

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

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

[slog]

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

[Aprox]

.... Но бывает и так что можно использовать только softcore. Поэтому и появилась эта тема.

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

[Leka]

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

[Stewart Little]

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

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

[slog]

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

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

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

[Aprox]

Причина 1
Есть готовый девайс. Внешних процессоров там нет а есть большая FPGA. Надо сделать User Interface.

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

[Postoroniy_V]

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

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

Есть готовый девайс. Внешних процессоров там нет а есть большая FPGA. Надо сделать User Interface

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

[Aprox]

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

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

[Postoroniy_V]

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

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

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

[Omen_13]

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

[Leka]

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

[Aprox]

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

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

Если же использовать софт-процессор - достаточно развести ПЛИС на 4Гбайт/сек. А ставить на последовательный интерфейс медленный внешний микроконтроллер - бессмысленно в таких задачах.

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

[Builder]

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

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

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

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

Сообщение отредактировал Builder - Sep 30 2008, 09:05

[608]

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

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

[Omen_13]

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

Сообщение отредактировал Omen_13 - Sep 30 2008, 09:33

[Leka]

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

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

[Aprox]

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

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

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

[Leka]

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

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

Сообщение отредактировал Leka - Sep 30 2008, 13:38

[Aprox]

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

Консенсус!

[Leka]

Консенсус!

Ok!

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

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

[Mahagam]

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

[Leka]

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

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

[Mahagam]

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

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

[Builder]

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

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

[Mahagam]

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

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

[Leka]

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

Код

loop: ...
  ...
  loop(i<imax); i++

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

Код

loop: ...
  ...
  INC i
  CMP i, imax
  JGE loop

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

[ReAl]

Скорости сопоставимые, и напрашиваются софт-ядра, ориентированные на исполнение инструкций из SPI flash...

Спасибо, об этом как-то не подумалось.

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

А об этом уже думалось - для задач индикации/неторопливого управления/общения с внешним миром выжимать "100МГц одна команда за такт и ради этого RISC" как-то не очень нужно. Многотактовость команды позволяет разменять скорость на компактность (~ "не торопясь объехать все колдобины") и сделать имеющий бОльшую плотность кода CISC. В свете чтения кода непосредственно из SPI FLASH увеличение плотности кода несколько повысит эффективную скорость работы из этой SPI FLASH (а лимитирующей становится именно она).

[Mahagam]

А об этом уже думалось - для задач индикации/неторопливого управления/общения с внешним миром выжимать "100МГц одна команда за такт и ради этого RISC" как-то не очень нужно. Многотактовость команды позволяет разменять скорость на компактность (~ "не торопясь объехать все колдобины") и сделать имеющий бОльшую плотность кода CISC. В свете чтения кода непосредственно из SPI FLASH увеличение плотности кода несколько повысит эффективную скорость работы из этой SPI FLASH (а лимитирующей становится именно она).

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

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

простейший оптимизатор в виде "поточное чтение без подачи адреса если команды читаются по подряд идущим адресам" даст на частоте SPI в 16MHz для 16-ти разрядного ядра ~1MIPS. пусть в среднем из-за переходов и данных скорость падает до 0.7MIPS, да такую же производительность имел Z80 в своё время. и какие игрушки на нём при этом летали. (спектрум все видели? ага )

[Leka]

Попалось: PB8051 - эмуляция 8051 на PicoBlaze.
http://www.roman-jones.com/PB8051Microcontroller.htm

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

Для picoblaze сам Xilinx дает только ассемблер.

[ReAl]

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

простейший оптимизатор в виде "поточное чтение без подачи адреса если команды читаются по подряд идущим адресам" даст на частоте SPI в 16MHz для 16-ти разрядного ядра ~1MIPS. пусть в среднем из-за переходов и данных скорость падает до 0.7MIPS, да такую же производительность имел Z80 в своё время. и какие игрушки на нём при этом летали. (спектрум все видели? ага )

При чём тут "монстра"? Я имел ввиду только то, что если уж всё равно нечто многотактовое (минимум 8 тактов на команду, если команды могут быть однобайтовые, при двухбайтовой гранулярности имеем аж 16 тактов), то лучше сделать микропрограммно что-то со сложными командами, грубо

Код

L:
   mov (R2)+, (R1)+
   sob R0, L

это четрые байта во флешке, а

Код

L:
    ld R0, X+
    st Y+, R0
    dec R16
    brne L

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

[Mahagam]

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

а ваш пример экономии - это всего лишь развитая система адресации. что есть у PDP-11. и это одна из мелких причин, почему я отписал своё ядро MSP430.

[ReAl]

в любом случае - универсал, который сменой микропрограмм эмулирует почти любое ядро - утопия, а ваш пример экономии - это всего лишь развитая система адресации. что есть у PDP-11. и это одна из мелких причин, почему я отписал своё ядро MSP430.

Я не говорю про такого универсала. И операционный блок, и набор микрокоманд - делается с ориентацией на конкретную архитектуру, "нельзя объять необъятное" да и места меньше займёт, быстрее напишется/отладится.
Наличие заведомо большого числа тактов на каждую команду даёт возможность не экономить на методах адресации (которых у PDP11 всё же больше, чем у MSP430), и каких-то других усложнениях ядра, которые при подходе "тактовая повыше, по возможности в потоке один такт на команду" лежат поперёк дороги.

Я сам MSP430 независимо от метода реализации считаю более правильным ядром для впихивания, чем AVR. В том числе потому, что 8 или 16 бит ядро - мало меняет число ячеек, занимаемое проектом, но програма покороче будет. Да и набор команд поортогональнее, должен приятнее реализовываться.
Когда недавно с товарищем обсуждали вопрос "если пихать, то что?", как раз 430-ый и вспоминался.
Если вдруг Ваше ядро будет доступно для свободного использования - с удовольствием поковыряюсь и приму участие в развитии.

[Leka]

Может, с другой стороны подойти к этой задаче - сначала подобрать подходящую виртуальную стековую машину для имплементации в FPGA? Тогда меньше проблем будет с ЯВУ. Поковырялся с Pascal-S - что-то ни одна реализация у меня не заработала...

[Mahagam]

Да и набор команд поортогональнее, должен приятнее реализовываться.

как мне показалось - совсем наоборот. например регистр PC. он же - R0. в нормальных ядрах его изменяет выделенная команда джамп, и автоинкремент. и обычно хрен его прочтёшь. в итоге регистр с такими ограничениями реализовывать проще. а у MSP430 каждый xor умеет использовать его и как источник, и как приёмник. в итоге логика управления этим регистром - страшная и непонятная.

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

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

[Leka]

Пришел к выводу, что имеет смысл делать софт-процессор под псевдокод какого-либо компилятора ЯВУ, в моем случае это подмножество Паскаля. Исходники компилятора и интерпретатора виртуальной машины Pascal-S открыты(1..2К строк), можно приспособить к своим нуждам(изменить набор/интерпретацию псевдокодов, реализуемое подмножество языка, и тд и тп).

[vetal]

Пришел к выводу, что имеет смысл делать софт-процессор под псевдокод какого-либо компилятора ЯВУ,

Все примерно так и делают Большинство софт ядер явно или косвенно соответствуют языку C.

[Leka]

Все примерно так и делают Большинство софт ядер явно или косвенно соответствуют языку C.

Можно пример _простой_ виртуальной машины Си с открытыми исходниками? Ява отпадает в силу громоздкости полной системы(по сравнению с Pascal-S).

[vetal]

Можно пример _простой_ виртуальной машины Си с открытыми исходниками? Ява отпадает в силу громоздкости полной системы(по сравнению с Pascal-S).

Nios, niosii, microblase, xr16 и много других - у всех в основе лежат базовые операции регистровых машин(с можно по большому счету отнести к регистровым языкам). Сделать неоптимизирующий компилятор С на базе lcc не составляет проблем.

[Leka]

http://www.246.dk/pascals3.html
Менее 1000 строк кода для компилятора с интерпретатором - аналогичное для Си - ???.

[Mahagam]

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

с момента рождения i4004 прошло 37 лет. за это время родились сотни архитектур, большая часть которых банально вымерла. но посмотрите какой список поддерживается GCC? может, проще всего выбрать наиболее простое и мелкое ядро поддерживаемое GCC и реализовать его? как мне кажется - одно из наиболее оптимальных - PDP-11. но вот незадача - неудобно отладку вести. вот с такими вот соображениями я и выбрал MSP430 для реализации.

[Leka]

а зачем изобретать велосипед?

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

смысл совместной заточки компилятора под ядро и ядра под компилятор?

Не совсем так, подбирается псевдокод, под который легко заточить и компилятор, и ядро - чтобы можно было независимо менять/оптимизировать и софт, и железо. Что касается заточки компиляторов, вместо цепочки: код на ЯВУ --> оптимизирующий компилятор --> код на ассемблере --> компилятор --> машинные коды, предпочел бы видеть: код на ЯВУ --> оптимизирующий препроцессор --> код на ЯВУ --> компилятор --> псевдокодкод --> оптимизирующий ассемблер --> машинные коды.

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

[Mahagam]

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

да бог ты мой, если действительно захотеть что-то прикрутить - то на выбор есть пикоблейз, микроблейз в порезанной версии, ниос-2 в порезанной версии. зулин-цпу есть с GCC. это всё готовое со всеми сервисами и удобствами. но в любом случае - хоть какой-то манульчик читать придётся.

Не совсем так, подбирается псевдокод, под который легко заточить и компилятор, и ядро - чтобы можно было независимо менять/оптимизировать и софт, и железо. Что касается заточки компиляторов, вместо цепочки: код на ЯВУ --> оптимизирующий компилятор --> код на ассемблере --> компилятор --> машинные коды, предпочел бы видеть: код на ЯВУ --> оптимизирующий препроцессор --> код на ЯВУ --> компилятор --> псевдокодкод --> оптимизирующий ассемблер --> машинные коды.

над первой цепочкой трудится куча программеров уже. и вчера. над вашей - трудится только вам и прочим фанатам.

[Leka]

над первой цепочкой трудится куча программеров уже. и вчера.

Понятно, что лучше продать 100 неуниверсальных оптимизирующих компиляторов Си-->асм под 100 конкретных архитектур, чем 10 универсальных Си-->Си.

[Mahagam]

Понятно, что лучше продать 100 неуниверсальных оптимизирующих компиляторов Си-->асм под 100 конкретных архитектур, чем 10 универсальных Си-->Си.

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

[Leka]

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

[Mahagam]

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

эээ. ооо. то есть переменные цикла - в раме?

[Leka]

эээ. ооо. то есть переменные цикла - в раме?

Да. Два 10нсек такта на a+=b в раме - не устроит, что-ли?

[des00]

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

%)) у дураков мысли сходятся

есть проект, в который просто идеально встает свое небольшое ядрышко с CISC командами и двумя Wishbone интерфейсами, комманд на 100.

Начал делать наброски. В этот раз буду делать кодогенератор на питоне, благо опыт и наработки имеются %)

[Mahagam]

Да. Два 10нсек такта на a+=b в раме - не устроит, что-ли?

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

а адрес этих а и бэ где берётся? как их отличить от цэ и дэ ?

а как адресовать много памяти? что-то я идеи не понимаю...

[des00]

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

а адрес этих а и бэ где берётся? как их отличить от цэ и дэ ?

а как адресовать много памяти? что-то я идеи не понимаю...

ну вообще это можно и за 1 такт сделать %) прочитать a и b, сложить и записать в память. Но для этого нужна асинхронная/квази асинхронная память, а за 2 такта так на обычной делается. a,b прочитать и результат записать.

думаю что уважаемый Leka во фразе

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

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

[Leka]

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

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

а адрес этих а и бэ где берётся? как их отличить от цэ и дэ ?

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

а как адресовать много памяти? что-то я идеи не понимаю...

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

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

[Aprox]

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

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

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

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

[Mahagam]

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

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

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

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

[Aprox]

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

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

[Leka]

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

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

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

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

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

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

[vetal]

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

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

[Mahagam]

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

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

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

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

[Builder]

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

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

[Leka]

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

У меня на Спартане3 ядро с регистровой архитектурой(load/stote) занимает ~~25 лут/разряд, половина из них приходится на 2-портовый 32-регистровый файл с 2-мя асинхронными чтениями и 2-мя записями за такт. Те ~~450 лут на 18-разрядное ядро c командами типа:
a += b; // +, -, &, |, ^, ...
a = b + const; // +, -, &, |, ^, ...
A[i] = b; // i++, i--
a = B[i]; // 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[i]; //команда адресует a, buf, i, но не *buf.

для души

Да.

[vetal]

У меня на Спартане3 ядро с регистровой архитектурой(load/stote) занимает ~~25 лут/разряд, половина из них приходится на 2-портовый 32-регистровый файл с 2-мя асинхронными чтениями и 2-мя записями за такт. Те ~~450 лут на 18-разрядное ядро c командами типа:
a += b; // +, -, &, |, ^, ...
a = b + const; // +, -, &, |, ^, ...
A[i] = b; // i++, i--
a = B[i]; // i++, i--
label(a<b); // <, <=, =, >, >=

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

[klop]

А все-таки, чем вас не удовлетворяют уже готовые крутые кристаллы с ядром 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]

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]

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

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

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

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

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

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

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

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

[Leka]

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

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

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

Конечно!

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

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

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

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

[vetal]

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

Все уже придумано до вас! В 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]

По поводу 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.

[slog]

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

[Builder]

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

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

[des00]

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

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

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

[Aprox]

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

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

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

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

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

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

[Mahagam]

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

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

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

[Omen_13]

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

[Leka]

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

Код

  
//копирование массива
//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

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

[vetal]

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

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

[Leka]

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

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

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

[vetal]

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

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

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