[zltigo 2]

1) Примение софт ядер имхо даёт

Все нижепречисленное для случая, когда процессор занимает несколько процентов, ну пару десятков процентов в FPGA. Что на данный момент времени встречается в очень больших и дорогих проектах на толстых FPGA, или при достаточности уж совсем мелкого вырожденного контроллерного ядра. Для мелко-средних массовых FPGA использование хоть cколь-нибудь приличного пороцессорного ядра тянет за собой использование явно избыточных FPGA и обвеска их, как минимум памятью. Это получается и громозче, и дороже использования массового ( но достаточно мощного хотя и несколько баксового) контроллера с Flash/RAM на борту. FPGA естественно толстеют и дешевеют и ситуация меняется на глазах, но на данный момент для большинства применений CPU+FPGA оптимальнее.

[Postoroniy_V 0]

Все нижепречисленное для случая, когда процессор занимает несколько процентов, ну пару десятков процентов в FPGA. Что на данный момент времени встречается в очень больших и дорогих проектах на толстых FPGA, или при достаточности уж совсем мелкого вырожденного контроллерного ядра. Для мелко-средних массовых FPGA использование хоть cколь-нибудь приличного пороцессорного ядра тянет за собой использование явно избыточных FPGA и обвеска их, как минимум памятью. Это получается и громозче, и дороже использования массового ( но достаточно мощного хотя и несколько баксового) контроллера с Flash/RAM на борту. FPGA естественно толстеют и дешевеют и ситуация меняется на глазах, но на данный момент для большинства применений CPU+FPGA оптимальнее.

Имхо, вы забыли вставить ИМХО в начале

[aprox 0]

Основное преимущество soft-CPU, для меня в частности, в гибкости и скорости окружающей периферии.

Не исключаю, что если бы в процессора с ядрами ARM внедряли полноценную FPGA, а не просто программируемую логику аппаратных прерываний и дешифраторов адреса, то они бы составили серьёзную конкуренцию ПЛИСам с soft-ядрами.

 

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

 

 

Вот нравятся мне такие категоричные заявления :) Типа "вы там все дураки, один я умный". А нафига писать, если Вам и так все ясно? Или не ясно? Тогда может форму послания изменить? Contradiction имеет место быть...

Прошу извинить за невольные обиды. Хотел выяснить другое: почему, например Альтера, с такой настойчивостью продвигает Soft-процессоры в FPGA, когда преимущества их в реальных конструкциях устройств совершенно неочевидны, и даже вредят основной идее FPGA- настоящая ПАРАЛЛЕЛЬНОСТЬ выполнения задач. Я ни разу не встретился с жестокой необходимостью вставлять какой либо Soft-процессор в FPGA. И. собственно, хотел узнать от других про задачи, в которых без ниосов никак не обойтись.

[Nixon 4]

Пастернака я не читал, но осуждаю :)

 

arexol же вам примерную задачу описал - 4 sdram контроллера, 2 видеоконтроллера с кучей фишек, 8 uart, ethernet, sd (в режиме sd), spi, i2c, 64 пина io, и т.п. Все описаное необходимо. Назовите мне примерную конфигурацию, выполненную на микроконтроллере.

[zltigo 2]

Имхо, вы забыли вставить ИМХО в начале

Нет. На данный момент это практически объективная реальность. Стоимость и размеры FPGA в которой можно собрать 5-10 баксовый контролер в разы превосходит стоимость такого контроллера. Посему запихивать в FPGA контроллер в 95% случав логично, когда ресурсы FPGA используется более, чем на 90% для других целей и контроллер в "уголке" этой FPGA получается "бесплатный". Вы каких размеров FPGA пользуете? Лично я пока уровня циклон2-3 - своего железа наворотить уже можно в нем очень и очень много, а собирать там, например, дохленький ARM со сколь-нибудь памятью - совершенно расточительно. Если навешать внешнюю память, то вроде и не смертельно по остальным ресурсам, но нафига, если вместо памяти можно настоящий копеечный ARM навесить....

[Voloshchenko 0]

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

В NiosII есть три метода ускорения для математики (см. Embedded Design Handbook, edh_ed_handbook.pdf, стр.20):

1. C2H accelerated software, аппаратное выполнение функций, очень мощно.

2. Custom instructions, дополнительные инструкции, любые!.

3. Custom peripherals, это еще более сверх-вешь.

И всем этим можно пользоваться без ограничений. По моему, универсальные CPU и MCU такими свойствами не обладают, Даже если вокруг них поставить несколько FPGA, то все равно возникнут проблемы с узостью интерфейсов между CPU и FPGA. В NiosII этих ограничений нет.

Да, в моей FPGA на NiosII (Fast) ушло 7% ресурсов, это тоже значимо.

Опять же, все определяется условиями задачи.

[CaPpuCcino 0]

1) Примение софт ядер имхо даёт

так как юзаем 1 чип вместо 2-х

- больше пространство на плате

- лучшее сигнал интегрити

- зависимость только от одного поставщика(плисов)

- заточка внутренностей под свои хотелки

- софт для разработки под софт проц и под плис типа родственники, что есть гуд

2)технические задачи стояли и стоят такие как - разработка под телеком нужды

п.1. - это теория. мы сами писали теоретические ворчалки с доказательствами подобных замечательных выгод и даже более того скажу о необозримых горизонтах открывающихся при применении концепции Application Specific Instruction Set, но на счёт последнего задача автоматизации ASIS оказалась сравнима с задачей поведеньческого синтеза (по трудоресурсам) и нам её поднять по финансовым причинам не выдится возможным.

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

 

рекомендую почитать.

ок. поищу

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

вот видите-ли, в этом то и загвоздка. я не вижу надобности в полноценных процессорных ядрах(архитектурах) на ФПГА. по моим ощущениям (мнение которое здесь также было высказано) последовательные интерпретаторы (в просонародии процессоры) необходимы только для интерфейсов к другим частям системы (пользовательский интерфейс, если это плата расширения, телекоммуникационный интерфейс, если сетевой коммутатор, и т.п.) есть другая точка зрения? (видел ссылку на использования ниоса в графике, но на мой взгляд жёсткая логика могла бы быть эффективнее, а использование проца даёт только лишь скорость развёртывания системы на кристалле)

я маленькие "процессоры" сам использую в алгоритмах, но это именно самописные задача-ориентированные процы последовательной интерпритации (в моём случае в основном стековой архитектуры). процессоры со своей ISA в моих задачах я не могу назвать эффективными совсем (именнов алгоритмической части, а не интерфейсной)

 

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

вот у меня тоже абсолютно подобное ощущение

 

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

Но опять же, все определяется условиями задачи..

это совсем и далеко не их идея и даже концепция. например см. разработки HP labs. (PICO program-in chip-out), Tensilica (например Xtensa), и т.д. (мы пытались продвинуть сходный по принципу с PICO подход)

[dvladim 0]

Свои 5 копеек вставлю. IMHO

 

Встроенный софт процессор может:

1. Сэкономить выводы ПЛИС.

2. Сократить номенклатуру.

3. Уменьшить трудоемкость сборки.

4. Уменьшить вероятность возникновения ошибок при сборке и соотв. время их устранения.

[CaPpuCcino 0]

1. Сэкономить выводы ПЛИС.

2. Сократить номенклатуру.

3. Уменьшить трудоемкость сборки.

4. Уменьшить вероятность возникновения ошибок при сборке и соотв. время их устранения.

это имеет какое-нибудь отношение к эффективности реализации целевого алгоритма?

1. сэкономить выводы ПЛИС относительно чего(какого решения /можно реализовывать алгоритм вообще без участия процессора/)?

2. сократить номенклатуру относительно чего(какого решения)?

3. это безусловно (использование любого reusable IP со стандартными интерфейсами уменьшает трудоёмкость сборки, но стандартизованные интерфейсы не всегда эффективны в целевой системе, и стандартные интерфейсы бывают и у других типов IP)

4. это не безусловно, потому как софт-процессор не является единственным вариантом reusable IP

[zltigo 2]

1. Сэкономить выводы ПЛИС.

Ага, для навешивания, например, внешней 32bit памяти :) потребной этому софтпроцессору :( а без такой "мелочи" либо получится микроскопический процессор, либо он обойдется достаточно дорого.

2. Сократить номенклатуру.

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

3. Уменьшить трудоемкость сборки.

Или увеличить :( ибо размер внутренних ресурсы к сожалению сильно коррелирует с корпусом и улететь на много более здоровый корпус и дополнительные слои в печати можно очень легко..

4. Уменьшить вероятность возникновения ошибок при сборке и соотв. время их устранения.

См. п 3. А устранение ошибок при "хорошем" BGA со хорошей стоимостью вообще-то совсем не рентабельно. А локализация через Boundary Scan достаточно эффективна при любом количестве чипов.

[faa 4]

Не исключаю, что если бы в процессора с ядрами ARM внедряли полноценную FPGA, а не просто программируемую логику аппаратных прерываний и дешифраторов адреса, то они бы составили серьёзную конкуренцию ПЛИСам с soft-ядрами.

IMHO конкуренцию составят очень серьёзную. И, возможно, очень скоро.

Лед тронулся :) STM уже объявили:

средняя модель - SPEAr BASIC ARM 926, 300Kgates , LFBGA289 package

старшая - SPEAr Plus600 Dual ARM 926, 600Kgates, PBGA420 package

 

ЗЫ: Только вот куда по ним сообщения постить - в FPGA или в ARM? ;)

[CaPpuCcino 0]

ЗЫ: Только вот куда по ним сообщения постить - в FPGA или в ARM? ;)

строго говоря PSoC на рынке уже пару лет присутствуют см. например http://electronix.ru/forum/index.php?showtopic=33095&hl= (микроконтроллер + hard-cores сетевая переферия + ПЛИС обвязка). когда к таким изделиям будет интерес, думаю будем открывать отдельную смежную ветку, либо обсуждать вопросы касающиеся конфигурабельной части таких систем здесь

[Postoroniy_V 0]

Нет. На данный момент это практически объективная реальность. Стоимость и размеры FPGA в которой можно собрать 5-10 баксовый контролер в разы превосходит стоимость такого контроллера. Посему запихивать в FPGA контроллер в 95% случав логично, когда ресурсы FPGA используется более, чем на 90% для других целей и контроллер в "уголке" этой FPGA получается "бесплатный". Вы каких размеров FPGA пользуете? Лично я пока уровня циклон2-3 - своего железа наворотить уже можно в нем очень и очень много, а собирать там, например, дохленький ARM со сколь-нибудь памятью - совершенно расточительно. Если навешать внешнюю память, то вроде и не смертельно по остальным ресурсам, но нафига, если вместо памяти можно настоящий копеечный ARM навесить....

 

Практически реальность это у вас :) , у меня другая реальность потому я скромно упомянул имхо

в РФ были циклоны 1-2, шас стратиксы2.

вообщем всё написаное мной имхо и логично-нелогично...вообщем будем считать что меня надурили, и я использую софт проц внутри по глупости :)

 

п.1. - это теория. мы сами писали теоретические ворчалки с доказательствами подобных замечательных выгод и даже более того скажу о необозримых горизонтах открывающихся при применении концепции Application Specific Instruction Set, но на счёт последнего задача автоматизации ASIS оказалась сравнима с задачей поведеньческого синтеза (по трудоресурсам) и нам её поднять по финансовым причинам не выдится возможным.

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

.................

 

1)Речь шла, насколько смог понять, про софт ядра, а имено ниос.

зависимость от 2-х поставщиков это не теория, это практика.

2) всего 1 ниос, основная задача поддержка snmp, конфигурировния, администрирование

 

 

Вообщем наблюдаю два лагеря "дурят" и "не дурят"

Предлагаю провести голосование

[des00 25]

Ну блин так и чувствовал что начнется холивар (как раз пятница кстати).

 

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

 

2 zltigo

 

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

 

младший ниос ~500 плиток, средний ниос занимает ~800 плиток, младший кулон2 c5 содержит 4608, что то не так в консерватории.

 

Лично я пока уровня циклон2-3 - своего железа наворотить уже можно в нем очень и очень много, а собирать там, например, дохленький ARM со сколь-нибудь памятью - совершенно расточительно.

 

ИМХО вы мыслите другими категориями. Смысла собирать ядро класса АРМ (впрочем как и других готовых процессорных ядер) НЕТ никакого и ждать от него чуда НЕ ИМЕЕТ никакого СМЫСЛА.

 

Т.к. трассировочные ресурсы и логика сожрет всю производительность и будет либо калека на 20-40МГЦ, либо бегун на 200МГц, но оччень тормозной.

 

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

 

2 CaPpuCcino

 

вот видите-ли, в этом то и загвоздка. я не вижу надобности в полноценных процессорных ядрах(архитектурах) на ФПГА. по моим ощущениям (мнение которое здесь также было высказано) последовательные интерпретаторы (в просонародии процессоры) необходимы только для интерфейсов к другим частям системы (пользовательский интерфейс, если это плата расширения, телекоммуникационный интерфейс, если сетевой коммутатор, и т.п.) есть другая точка зрения? (видел ссылку на использования ниоса в графике, но на мой взгляд жёсткая логика могла бы быть эффективнее, а использование проца даёт только лишь скорость развёртывания системы на кристалле)

я маленькие "процессоры" сам использую в алгоритмах, но это именно самописные задача-ориентированные процы последовательной интерпритации (в моём случае в основном стековой архитектуры). процессоры со своей ISA в моих задачах я не могу назвать эффективными совсем (именнов алгоритмической части, а не интерфейсной)

 

Что бы не уйти во флуд, тогда уж дайте определение что по вашему "полноценное процессорное ядро".

И что вы от него ждете.

 

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

 

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

 

"ссылку на использования ниоса в графике, но на мой взгляд жёсткая логика могла бы быть эффективнее" - очень сильно подозреваю что там ниос всего лишь "подносит патроны". А Avalon Switch Fabric используется как системная шина, т.к. она уже готова, гарантировано рабочая и легко конфигурируемая.

 

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

 

Какой смысл делать вот это на конечном автомате, тут производительность нужна очень маленькая. Это легко реализуется на проце, который вычисляет адреса и заряжает Scather - Gather DMA контроллеры.

 

Другой пример ну нужно вам 20 UART каналов, положить в память, объединить и плюнуть ну например в USB. Можно сделать все на логике, но не проще ли (и быстрее) поставить ниос, 20 уарт блоков и приделать интерфейс к усб ?

 

Сколько времени вы потратите на отладку и разработку первой системы и второй ?

 

Postoroniy_V привел кста хороший пример "основная задача поддержка snmp, конфигурировния, администрирование"

 

Еще пример для ленивых : на сайте хилых есть апнота на Пикоблейзе разруливают i2c мастер/слейв. Все просто 96 плиток проц и маленькая прога : готовый мастер без проблем, логику работы которого можно менять на лету.

прикручиваем к нему готовый уарт, вот вам диагностический мост i2c-UART, используемый например при отладке проекта.

 

 

ИМХО Софт ядра создавались прежде всего для ленивых, но и профессионалы быстро оценили их достоинства при грамотном их позиционировании. Нужно всего то посмотреть на это с другой стороны.

[blackfin 32]

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

Жизнь, конечно, одной лишь математикой не ограничивается.. :laughing:

Что Вы, например, можете сказать в оправдание использования софт-процессоров в задачах парсинга запросов HTTP? Текстовые поля в заголовках HTTP могут быть довольно длинными (несколько КБайт), особенно, если требуется поддержка SSL. Самих заголовков тоже может быть много, а если помножить все это на количество одновременно подсоединенных клиентов (например 100), то вообще - мрак.

Как пример - обычная Web-камера с Web-интерфейсом. Можно, конечно, распараллелить задачу, синтезировав несколько процессоров так, чтобы каждый проц, работал со своими клиентами, но где хранить методы/заголовки HTTP? Где, опять же, хранить страницы HTML? В общей для всех процессоров внешней памяти? Тогда какую мы получим скорость обработки HTTP запросов клиентов?