Не дурят ли нашего брата?, О целесообразности всяких ниосов в FPGA. Опции

[Aprox]

Я конечно могу жутко ошибаться, но покумекав на предмет применения процессорных ядер а матрице пришел к выводу, что не стоит овчинка выделки. С одной стороны создается монстр, с внешней шиной DDR2 и FLASH , а с другой он работает не лучше и не быстрее напичканных периферией ARM9. Спрашивается- нафига козе баян? Не проще ли использовать какой-нибудь готовый чип с ядром ARM? Чем хороша FPGA, где она вне конкуренции? На мой взгляд там, где нужно вести несколько тредов параллельно на аппаратном уровне. И какой смысл в данном случае опускать FPGA до конечного автомата последовательного действия - я не понимаю. Короче, для себя принял стратегию использовать FPGA только в связке с микроконтроллером со встроенным Flash. Много проблем, включая загрузку и защиту проекта сразу решаются автоматом. А ниосы пусть отдыхают в сторонке. Рекламные трюки на нас не действуют!

[LeonY]

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

[CaPpuCcino]

А нафига писать, если Вам и так все ясно? Или не ясно?

мне вот не ясно. прошу высказываться уважаемых форумчан, что им дало применение софтовых процессорных ядер.
очень было бы мило придерживаться некоторого плана ответа включающего пункты: какая техническая задача стояла, примерная конфигурация платы (какие каналы данных заводились в ПЛИС), какие алтернативы ПЛИС-архитектуры рассматривались и чем они не подошли (если что пропустил, плз, дополните).
ЗЫ: я чесное слово понимаю что идея сконфигурировать процессор последовательной интерпритации инструкций на ПЛИС - это круто. но так ли это эффективно по сравнению с полностью задача-оптимизированной системой на кристалле?

[Postoroniy_V]

мне вот не ясно. прошу высказываться уважаемых форумчан, что им дало применение софтовых процессорных ядер.
очень было бы мило придерживаться некоторого плана ответа включающего пункты: какая техническая задача стояла, примерная конфигурация платы (какие каналы данных заводились в ПЛИС), какие алтернативы ПЛИС-архитектуры рассматривались и чем они не подошли (если что пропустил, плз, дополните).
ЗЫ: я чесное слово понимаю что идея сконфигурировать процессор последовательной интерпритации инструкций на ПЛИС - это круто. но так ли это эффективно по сравнению с полностью задача-оптимизированной системой на кристалле?

1) Примение софт ядер имхо даёт
так как юзаем 1 чип вместо 2-х
- больше пространство на плате
- лучшее сигнал интегрити
- зависимость только от одного поставщика(плисов)
- заточка внутренностей под свои хотелки
- софт для разработки под софт проц и под плис типа родственники, что есть гуд
2)технические задачи стояли и стоят такие как - разработка под телеком нужды

3)не подошли внешний проц+плис потомучто имеется п.1

[des00]

А ниосы пусть отдыхают в сторонке. Рекламные трюки на нас не действуют!

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

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

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

может доживу когда потребуется ниос )

[slog]

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

[Aprox]

1) Примение софт ядер имхо даёт
так как юзаем 1 чип вместо 2-х
- больше пространство на плате

А отдельный чип загрузки FPGA почему не считаете? Тоже ведь денег и места на плате требует. Конструкция FPGA+внешний проц мне представляется эквивалентной по п.1.

[Kuzmi4]

2 Aprox - отдельный чип загрузки не сильно много места занимает

[Aprox]

.... какая техническая задача стояла, примерная конфигурация платы (какие каналы данных заводились в ПЛИС), какие алтернативы ПЛИС-архитектуры рассматривались и чем они не подошли

Применял FPGA в задачах ввода быстрых аналоговых сигналов(полоса до 20 MГц) , сжатия поступающей информации и передача ее в PC. Одновременно, устройства должны были "управляться" со стороны PC и вручную, через переднюю панель прибора. Решил, что управляемостью прибора должен заведовать отдельный микроконтроллер потому, что он для этого и заточен со всей своей встроенной периферией. А FPGA пусть будет по-минимуму цены и сложности, заниматься только быстрыми задачами, которые не по зубам микроконтроллеру. Очень удобно оказалось использовать избыток FLASH микроконтроллера для загрузки FPGA.

Сейчас встала задача управления прибором, который должен запускать IP-пакеты с данными в сеть со скоростью до 200 Mbps. Речь идет о 1G Ethernet. Микроконтроллеров со встроенным MAC на такие скорости не найти. Поэтому эту часть работы отдаем FPGA, а отдельному микроконтроллеру, как и раньше - управление прибором в целом.

[vadimuzzz]

А отдельный чип загрузки FPGA почему не считаете? Тоже ведь денег и места на плате требует. Конструкция FPGA+внешний проц мне представляется эквивалентной по п.1.

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

[Волощенко]

Главное в применении связки FPGA + MCU - условия задачи. Рискну высказать свое мнение.
NiosII хорош, но очень сложен, а обучать Альтера хочет за деньги... К сожалению, в горах документации найти зерно истины - все равно, что добывать уран из гранита. Но когда NiosII освоен, пользоваться им очень приятно, т.е. создан как бы барьер для непосвященных... Зачем только, не понятно.
Мое применение - цивильная прибрежная радиолокация, первичная обработка, без FPGA здесь не обойтись. АЦП 25 МГц и всякие мудрые алгоритмы. Здесь NiosII применен пока для управления и передач по Ethernet 100 на уровень вторичной обработки. Очень нравится мне идеология "пользовательской переферии" со спец.операциями в том числе, а также внутренняя память в FPGA, когда можно делать большую ширину слова с данными... Сигнальные процессоры с такими алгоритмами не справляются, к сожалению. Так что испытываю глубокое уважение к создателям софт-процессоров от Альтеры, сколько это надо иметь пядей во лбу, чтобы изобрести такое!
Но опять же, все определяется условиями задачи..

[arexol]

Я конечно могу жутко ошибаться, но покумекав на предмет применения процессорных ядер а матрице пришел к выводу, что не стоит овчинка выделки. С одной стороны создается монстр, с внешней шиной DDR2 и FLASH , а с другой он работает не лучше и не быстрее напичканных периферией ARM9. Спрашивается- нафига козе баян? Не проще ли использовать какой-нибудь готовый чип с ядром ARM? Чем хороша FPGA, где она вне конкуренции? На мой взгляд там, где нужно вести несколько тредов параллельно на аппаратном уровне. И какой смысл в данном случае опускать FPGA до конечного автомата последовательного действия - я не понимаю. Короче, для себя принял стратегию использовать FPGA только в связке с микроконтроллером со встроенным Flash. Много проблем, включая загрузку и защиту проекта сразу решаются автоматом. А ниосы пусть отдыхают в сторонке. Рекламные трюки на нас не действуют!

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

Я разрабатываю на проекты на ниосе достаточно давно и могу сказать следующее.
В первую очередь все зависит от задачи - никто не сомневается что ARM9 или BLACKFIN ядра по вычислительной производительности уделывают ниос2.
Но ведь вычислительная производительность ядра не всегда нужна.
К примеру нужно сделать систему с таким набором периферии где есть 10 уартов, которые работают на скорости 115200 а то и больше , + ещё что-нибудь .
И при всём при этом вам необходимо с SD карточки выводить на экран картинку с разрешением 1280х1024 х16
да ещё и анимацию крутить с нормальной скоростью.

Вот и получается что - решить такую задачу уже на каком-нибудь процессоре не выйдет даже если у него 600 Mhz тактовая (периферии то такой нет на борту) - надо городить фпга да схему связки с процессором на который надо замыкать весь поток данных, а если уже есть фпга, то гораздо логичнее поставить ядро НИОС2 - будет и дешевле и проще.

В моём текущем проекте к примеру не 1 монитор а 2 - и всё на ниосе и тут уж точно использование внешнего процессора, как по мне нецелесообразно вообще.

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


Вот к стати что парни недавно сделали на Ниосе
http://www.tesbv.com/index.php?site=TES_EN_1_dave
Так что Ниос вещь очень хорошая, если правильно понимать как им пользоваться.


p.s.
В идеале на мой взгляд это решения где есть CPU HardCore ядро, которое находиться внутри фпга.
но к сожалению на данный момент это редкость, да и дорого стоит.

[Postoroniy_V]

А отдельный чип загрузки FPGA почему не считаете? Тоже ведь денег и места на плате требует. Конструкция FPGA+внешний проц мне представляется эквивалентной по п.1.

он почему-то требует поменьше места и денег
но всё очень и очень зависит от внешнего проца
он конечно же может быть и pic12

Главное в применении связки FPGA + MCU - условия задачи. Рискну высказать свое мнение.
NiosII хорош, но очень сложен, а обучать Альтера хочет за деньги... К сожалению, в горах документации найти зерно истины - все равно, что добывать уран из гранита. Но когда NiosII освоен, пользоваться им очень приятно, т.е. создан как бы барьер для непосвященных... Зачем только, не понятно.
..............

ну...началось...
не умение читать доки это не минус софт проца

[LeonY]

А отдельный чип загрузки FPGA почему не считаете? Тоже ведь денег и места на плате требует. Конструкция FPGA+внешний проц мне представляется эквивалентной по п.1.

Ну если не говорить конкретно о NIOS, а вообще о softCPU, то кто мешает использовать Actel продукты. Там, например, на Fusion можно добиться действительно Single Chip Solution. А все остальное представляемое как Single Chip Solution - маркетинговое фуфло: нужны еще кристалл, пару-тройку Voltage Regs. Так что на фоне всего этого SO8 SPI загрузочная память и по цене и по размерам - below noise. Хотя никому не посоветую использовать Actel - но это персональное, не люблю я их, хотя вынужден работать.

[EvgenyNik]

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

[zltigo]

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

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

[Postoroniy_V]

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

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

[Aprox]

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

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

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

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

[Nixon]

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

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

[zltigo]

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

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

[Волощенко]

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

В 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]

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]

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

Встроенный софт процессор может:
1. Сэкономить выводы ПЛИС.
2. Сократить номенклатуру.
3. Уменьшить трудоемкость сборки.
4. Уменьшить вероятность возникновения ошибок при сборке и соотв. время их устранения.

[CaPpuCcino]

1. Сэкономить выводы ПЛИС.
2. Сократить номенклатуру.
3. Уменьшить трудоемкость сборки.
4. Уменьшить вероятность возникновения ошибок при сборке и соотв. время их устранения.

это имеет какое-нибудь отношение к эффективности реализации целевого алгоритма?
1. сэкономить выводы ПЛИС относительно чего(какого решения /можно реализовывать алгоритм вообще без участия процессора/)?
2. сократить номенклатуру относительно чего(какого решения)?
3. это безусловно (использование любого reusable IP со стандартными интерфейсами уменьшает трудоёмкость сборки, но стандартизованные интерфейсы не всегда эффективны в целевой системе, и стандартные интерфейсы бывают и у других типов IP)
4. это не безусловно, потому как софт-процессор не является единственным вариантом reusable IP

[zltigo]

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

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

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

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

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

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

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

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

[faa]

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

IMHO конкуренцию составят очень серьёзную. И, возможно, очень скоро.
Лед тронулся STM уже объявили:
средняя модель - SPEAr BASIC ARM 926, 300Kgates , LFBGA289 package
старшая - SPEAr Plus600 Dual ARM 926, 600Kgates, PBGA420 package

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

[CaPpuCcino]

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

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

[Postoroniy_V]

Нет. На данный момент это практически объективная реальность. Стоимость и размеры 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]

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

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

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]

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

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

[Postoroniy_V]

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

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

[blackfin]

ыыы....как бы это...а где тут место для плис то???

Для плис тут место - MJPEG сжатие катринки..

[Postoroniy_V]

Для плис тут место - MJPEG сжатие катринки..

извините я не в курсе - проц "имени вас" сдается здесь?

[blackfin]

извините я не в курсе - проц "имени вас" сдается здесь?

Смотря "что" и "как" сжимать: Performance Metrics
А если нужно "N-мегапикселей"?

[des00]

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

фраза вырвана из контекста, ну если уж холиварить, да еще и в пятницу :

скажите что вы вкладываете в понятие математика ? FIR, IIR, DCT и все ?

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

И опять же не ждал бы чуда от софт проца, который работает на 80-100 МГц, с 5 ти стайдийным конвейером, без нормальной системы предсказания ветвлений и малым кешем.

Как уже было сказано выше, все зависит от задачи.

Для плис тут место - MJPEG сжатие катринки..

странно, почему бы не жать mjpeg на проце, вроде не самый сложный алгоритм. или у вас 4К видео ? Почему бы не положить его на дсп бошку от давинчи. а на второй бошке обрабатывать хттп.

2 Postoroniy_V

про здравый смысл все забывают

+1

[blackfin]

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

Так именно в этом и дело! Причем, параллельная обработка тут весьма затруднительна, т.к. лексемм много, они могут иметь разную длину и встречаться в разных местах запроса HTTP в зависимости от структуры самого запроса..

И опять же не ждал бы чуда от софт проца, который работает на 80-100 МГц, с 5 ти стайдийным конвейером, без нормальной системы предсказания ветвлений и малым кешем.

Как раз "крутизна" процессора значения не имеет.. Важна именно частота на которой он работает и объем кэша..

[des00]

..
Важна именно частота на которой он работает и объем кэша..

так это очевидно, к чему тогда был ваш пост

Что Вы, например, можете сказать в оправдание

если ответ заранее очевиден и известен ?

[blackfin]

так это очевидно, к чему тогда был ваш пост
если ответ заранее очевиден и известен ?

Не только известен, но и озвучен: "Как уже было сказано выше, все зависит от задачи. "

[zltigo]

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

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

в РФ были циклоны 1-2, шас стратиксы2.
вообщем всё написаное мной имхо и логично-нелогично...вообщем будем считать что меня надурили, и я использую софт проц внутри по глупости

Устойте опрос сколько людей на данном форуме используют вторые стратиксы и узнаете количество людей использующих или задумывающихся об использовании софтпроцессоров

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

Не вижу такого.

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

Про память потребную контроллерам не помянули из забывчивости и про относительную мощу младших софтконтроллеров тоже . Говоря о ресурсах не стоит сбрасывать со счетов и то, что кроме ядрышка железныеконтроллеры еще содержат нужные во многих случаях периферийные вещички начиная с банальных UART и кончая контроллерами памяти, MACами...Они ведь тоже при софтизации ресурсов потребуют, причем немалых.

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

Ну а то, что процессор из "~500 плиток" во многих случаях просто ни нафиг не сдался Вы мысль не допускаете ? Кроме того, та-же Altera начала работать с ARM Cortex ядром.... И ничего особо монстрального в этом уже нет.

[Postoroniy_V]

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

Устойте опрос сколько людей на данном форуме используют вторые стратиксы и узнаете количество людей использующих или задумывающихся об использовании софтпроцессоров
Не вижу такого.
....

в который раз вижу что "вам всё известно заранее"
циклоны1-2 в той форме до сих пор юзают и до сих пор применяют ниос. ниша - телеком.
категоричность взята из названия треда

[des00]

Про память потребную контроллерам не помянули из забывчивости и про относительную мощу младших софтконтроллеров тоже . Говоря о ресурсах не стоит сбрасывать со счетов и то, что кроме ядрышка железныеконтроллеры еще содержат нужные во многих случаях периферийные вещички начиная с банальных UART и кончая контроллерами памяти, MACами...Они ведь тоже при софтизации ресурсов потребуют, причем немалых.

ндя разговор глухого с немым.

нет не забыл, младший кулон2 содержит 13 килобайт встроенной памяти, для размещения загрузчика и небольшого кеша более чем. Кроме того я видел рабочие проекты где весь код проекта умещался в 8 килобайт и все крутилось во внутренней памяти.

Повторюсь еще раз. все зависит от задачи. Ставить фпга только что бы запустить на ней проц, бессмысленно, готовый проц порвет ее как тузик грелку. (с) dxp.

кстати дайте ответ на вопрос arexol указанный выше :

К примеру нужно сделать систему с таким набором периферии где есть 10 уартов, которые работают на скорости 115200 а то и больше , + ещё что-нибудь .
И при всём при этом вам необходимо с SD карточки выводить на экран картинку с разрешением 1280х1024 х16

покажите такой процессор ?

Ну а то, что процессор из "~500 плиток" во многих случаях просто ни нафиг не сдался Вы мысль не допускаете ? Кроме того, та-же Altera начала работать с ARM Cortex ядром.... И ничего особо монстрального в этом уже нет.

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

средний ниос, кстати вполне серьезный процессор и весит порядка 900-1000 плиток,
топовый ниос порядка ~1500 - 1700 (вроде такую цифру читал в доках).

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

а если учесть что этот софт арм весит как 2-3 ниоса, и то что их арм основан на AMBA AHB, а не на AXI , то в системе ниосы порвут его как тузик грелку.

[Aprox]

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

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

Большая часть из описанного прекрасно ложится на готовые современные мультимедийные чипы с ARM9 на борту. За исключением 8-ми UART-ов (их там как правило не более 4-х), и 4 sdram (как правило один). Hу, так и надо все недостающее отдать FPGA. И она оказалась бы совсем не таким монстром, как если все описанное реализовать в SoPC с ниосом.

[zltigo]

покажите такой процессор ?

Покажите облась применения такого "франкенштейна" c двумя LCD и всего остального по 4, по 8 , его серийность... Тогда можно будет и порассуждать о том на чем его делать. Кроме того, здесь идет речь не о замене FPGA контроллерами - исключительно об их сочетании. C учетом того, что те-же ARM9 с приличными набортным LCD, SD и прочими контроллерами баксов за 10-15 продаются то и вариант с прицепить к нему "10 UART" в самой копеечной FPGA отнюдь не безумен.

[yes]

Смотря "что" и "как" сжимать:
А если нужно "N-мегапикселей"?

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

поэтому использование ПЛИС для этого неоправдано

-----------------------------

а по поводу дурят или нет - в коммерческих проектах софтпроцессоры на ПЛИС не использовал (да и не было у меня реальных проектов на ПЛИС - это всегда прототипирование - и соответственно не ниос и не блейз).
собственно для прототипирования альтера, наверно, и делает Cortex

а для заточенных под архитектуру ПЛИС NIOS/BLAZE и соответственно систем и софта для них (тип EDK), более сложная задача, имхо, компилер написать и весь софт/тулы (ну или комплексно, и компилер и архитектуру такую, чтоб по производительности не уступал), чем ксайлинс и альтера успешно занимаются, и наверно, получают прибыль
то есть - раз усилия фирмы прикладывают - значит, какую-то прибыль с софтпроцессоров получают (причем альтера прикрыла ПЛИС с хардпроцессором)

в дополнение к сказаному:
я вижу следующие применения
1) когда DSP приложение вертится на встроеных умножителях, а фабрик используется мало - почему бы туда не засунуть софтпроцессор для управления, всяко проще, чем снаружи контроллер ставить

2) когда мелкая логика (какой-нибудь коммутатор, хитрая glue logic и т.п.) - в мелкой ПЛИСине : стоимость ПЛИС ксайлинкс довел до 2$ в партиях, в розницу реально за 10$, вставить туда пикоблейз или что-то подобное - дешевле, чем снаружи 1$ пик повесить (тем более, что у ПИКов с пинами плохо - нужно какие-то SPI и т.п. - то есть что-то в ПЛИС отожрать на декодирование)

возможно и для средних ПЛИС апроксимировать

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

[zltigo]

насчет кортекс ядра вы думаете что альтеровцы начали с ним работать потому что он лучше ?

Потому, что оно совсем неплохое и поддерживается многими средствами разработки, и позволяет проще производить миграцию FPGA+ARM -> большой FPGA c софтпроцессором.

[Aprox]

ыыы....как бы это...а где тут место для плис то???
поставьте 1 проц "имени вас" и усё... и веб и дсп обработка с камеры. :-)

Так, именно про это и спич, что реализовать такое на FPGA -умопомрачительно и никому не нужно. И тем не менее, Альтера дает ссылки на реализацию TCP стека на Си через ниос! Скажете. не дурят нашего брата бессовестные промоутеры?

[zltigo]

Кроме того я видел рабочие проекты где весь код проекта умещался в 8 килобайт и все крутилось во внутренней памяти.

А лично в повседневной жизни пользую проекты в которых затраты памяти ну никак меньше 60-70K (средние под 200K) не опускаюся. Ну и что мне прикажете делать с голыми FPGA? Использовать старшие стратиксы c десятком мегабит на борту и соответствуюющей им стоимостью вместо 5-6 баксового ARM + 10-30 баксового FPGA?? А оно мне сегодня надо???

И тем не менее, Альтера дает ссылки на реализацию TCP стека на Си через ниос! Скажете. не дурят нашего брата бессовестные промоутеры?

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

[yes]

Потому, что оно совсем неплохое и поддерживается многими средствами разработки, и позволяет проще производить миграцию FPFA+ARM -> большой FPGA c софтпроцессором.

к слову - миграцию и на ниос/блейз с арма или чего-угодно - не проблема : компилятор есть, ОС правильно брать с открытым кодом (NIOS, если я не ошибаюсь, даже имеет ММУ и порт Линукса)

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

имхо, Cortex они хотят для привлечения прототипистов и еще раз "обдурить нашего брата" на предмет, что АРМ компатибле софтпроцессор уж однозначна стоит использовать

[blackfin]

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

Что, конкретно, подразумевается под "... входного и выходного канала"? PPI? Ethernet? SDRAM? В BF, например, невозможно впихнуть поток HDTV, а в FPGA - можно.

...поэтому использование ПЛИС для этого неоправдано

Ну, Вы это вот этим товарищам объясните: Andrey Filippov, 4dsp. Или сожмите на BF533 MJPEG со скоростью 500 frames/s или в 2048 x 2048 пикселей.

[yes]

Что, конкретно, подразумевается под "... входного и выходного канала"? PPI? Ethernet? SDRAM? В BF, например, невозможно впихнуть поток HDTV, а в FPGA - можно.

Ну, Вы это вот этим товарищам объясните: Andrey Filippov, 4dsp. Или сожмите на BF533 MJPEG со скоростью 500 frames/s или в 2048 x 2048 пикселей.

потоки, типа HDTV, как-то несерьезно обрабатывать без межкадровой корреляции, предказания движения и т.п.

проект Andrey Filippov-а никак не просто MJPEG

ну а кор разных наделать - не проблема, помоему в корегене есть JPEG (может отдельно DCT и HUFFMAN)
я пытался с некой "общетехнической целесообразности" посмотреть на вопрос

[avesat]

Фухх, осилил четыре страницы текста Интересное обсуждение, люди которые применяют софт процессоры пытаются доказать людям которые "Короче, для себя приняли стратегию использовать FPGA только в связке с микроконтроллером со встроенным Flash" что s-p не так уж плохи.
Всегда ставлю MicroBlaze от ксайлинкса, если плис без PPC внутри, нравится мне этот процессор, очень удобно реализовывать верхний уровень именно на нем. А уже несколько PPC могут и посчитать кое-чего и не простенькое . Для сети конечно отдельный процессор идет, для плавучки TMS. В общем как много раз уже говорили все зависит от ваших задач. Но думаю когда ПЛИС подешевеют (еще больше), а софт процессоры возмужают, некоторые изменят свое мнение

[CaPpuCcino]

что по вашему "полноценное процессорное ядро".
И что вы от него ждете.

ядро с униврсализированной ISA (instruction set architecture). немного поясню "униврсализированность ISA": в большинстве задач встроенных систем набор требуемых инструкций (как яркий пример - арифметических) стабилен и ограничен (кому-то не нужно деление, кому-то арифметический сдвиг). ISAрхитектуры процессоров как правило стараются сделать универсальными для большого класса задач и часто избыточными.
в реализации целевых "вычислительных" алгоритмов я от них в ПЛИС ничего не жду, в обработке сетевых протоколов жду многого. собственно об этом я и написал. дискуссии устраивать тут особо нет повода. основной вопрос темы был о целесообразности использования софт-процессоров. я обозначил в посте области где их использование целесообразно и где нецелесообразно. ваши примеры лишь ещё раз утверждают мои высказывания.
так что никакого холивор не предвидится, извините

скажите что вы вкладываете в понятие математика ? FIR, IIR, DCT и все ?

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

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

[blackfin]

..скажите что вы вкладываете в понятие математика ? FIR, IIR, DCT и все ?

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

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

[Aprox]

И тем не менее, Альтера дает ссылки на реализацию TCP стека на Си через ниос! Скажете. не дурят нашего брата бессовестные промоутеры?

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

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

[slog]

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

Процессор лезет даже в самую маленькую FPGA, оставляя большинство ресурсов не занятыми. Если уже есть FPGA в которой осталось лишнее место, то почему бы не засунуть в неё и процессор?

[gab]

Хотя никому не посоветую использовать Actel - но это персональное, не люблю я их, хотя вынужден работать.

Можно узнать почему? Тоже вынужден с ними начать работать (делаем прибор для космока. Ядро - LEON3).

[CaPpuCcino]

Если уже есть FPGA в которой осталось лишнее место, то почему бы не засунуть в неё и процессор?

(мечтательно) ах, если бы были такие проекты, при реализации в ПЛИС которых оставалось бы лишнее место

[gab]

(мечтательно) ах, если бы были такие проекты, при реализации в ПЛИС которых оставалось бы лишнее место

Полностью поддерживаю. Xc2VP50 - 40% -- обвязка powerpc .

[CaPpuCcino]

Полностью поддерживаю. Xc2VP50 - 40% -- обвязка powerpc .

а у меня V2Pro100 90% и хочется ещё больше, потому как и сейчас уже приходится искать компромисы по реализации алгоритма, а он ещё и масштабируется хорошо - с удовольствием бы пересел на V5-330

[gab]

а у меня V2Pro100 90% и хочется ещё больше, потому как и сейчас уже приходится искать компромисы по реализации алгоритма, а он ещё и масштабируется хорошо - с удовольствием бы пересел на V5-330

Мы тоже хотим на v5 пересесть, но нам его не продают пока .

[Aprox]

Если уже есть FPGA в которой осталось лишнее место, то почему бы не засунуть в неё и процессор?

А лишние слоты времени в шине доступа, например к DDR2, тоже остались? Представляете, сколько сразу проблем возникнет, чтобы вклиниться софтпроцессору к внешней памяти, если она уже используется для основной деятельности FPGA. Я просто не понимаю, зачем искать лишние приключения?

[Postoroniy_V]

А лишние слоты времени в шине доступа, например к DDR2, тоже остались? Представляете, сколько сразу проблем возникнет, чтобы вклиниться софтпроцессору к внешней памяти, если она уже используется для основной деятельности FPGA. Я просто не понимаю, зачем искать лишние приключения?

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

[Aprox]

А лишние слоты времени в шине доступа, например к DDR2, тоже остались?

да остались

Значит, FPGA выбрана неэффективно, с большой переплатой.

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

не представляю(у авалон свич фабрик путь болит голова)

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

[Postoroniy_V]

да остались

Значит, FPGA выбрана неэффективно, с большой переплатой.

не представляю(у авалон свич фабрик путь болит голова)

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

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

[des00]

Значит, FPGA выбрана неэффективно, с большой переплатой.

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

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

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

И не рекомендую так узко оценивать круг задач решаемых на фпга и возможные пути их решения.

2 CaPpuCcino

ваши примеры лишь ещё раз утверждают мои высказывания.

с позиции здравой логики это очевидно %)

2 zltigo

А лично в повседневной жизни пользую проекты в которых затраты памяти ну никак меньше 60-70K (средние под 200K) не опускаюся. Ну и что мне прикажете делать с голыми FPGA? Использовать старшие стратиксы c десятком мегабит на борту и соответствуюющей им стоимостью вместо 5-6 баксового ARM + 10-30 баксового FPGA?? А оно мне сегодня надо???

Мамы разные нужны, мамы разные важны (с) С.Михалков

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

Вы гуру, вам все виднее, не обращайте внимания на наши ковыряния в песочнице софт процов. %)

[CaPpuCcino]

интересно, скоро дойдёт до вызывов на дуэль...

[zltigo]

Никто не предлагал вам выкинуть свои армы и поставить вместо них софт ядра..

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

Вам этого не надо, забудьте и не возвращайтесь...

меня куда-то?

[Aprox]

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

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

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

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

Мамы разные нужны, мамы разные важны (с) С.Михалков

Пусть сияют тысячи солнц! Пусть цветут тысячи цветов! (с)- Мао.

[des00]

2 CaPpuCcino

интересно, скоро дойдёт до вызывов на дуэль

не вижу причин, идет обычный флуд, отчасти по делу.

2 zltigo

читаем внимательно до конца.

Вам этого не надо, забудьте и не возвращайтесь к этой теме

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

2 Aprox

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

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

опускание FPGA до уровня автомата последовательного действия

не верно.

Hо догадываюсь, что вы потратили массу времени и сил на освоение софтядер,

время на это тратиться не много, 3-4 обзорных статьи с альтеры вам будет достаточно что бы въехать в курс дела.

и вопросы эффективности теперь сводятся к пословице: "лучшее- враг хорошего"

скажу честно, было время когда я думал как вы, но многоуважаемый Bill снял с меня розовые очки, сказав аналогичную фразу.

ИМХО работать надо по принципу "проект укладывается в ТЗ ? все баста карапузики, идем дальше : доводим функциональность до ТЗ"


Удачи !!!

[CaPpuCcino]

В ваших проектах этого не требуется и если это очевидно, тогда зачем концентрироваться на этой теме ? %)

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

[zltigo]

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

Да, и не думать не мог, что Вам трудно даже название топика прочитать, прежде, чем в него писать . Так вот, топик называется "О целесообразности всяких ниосов в FPGA", а не так, как Вам показалось/захотелось. Мне позволительно было в рамках названной темы высказать свое мнение?

[CaPpuCcino]

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

ну раз флуд, давайте, я это дело лю:
прикольная новая классификация! ну ветвь понятно - у нас домохозяет это называется поток (thread), функций тож понятно - параллелизм задач(task), комманд дано полагать это параллелизм инструкций (ILP как в VLIW), ещё забыт паралеллизм операций (OLP как в любом конвеере), но вот что скрывается под параллелизмом объектов? (в смысле трудно представить как они могут существовать непараллельно?)

[blackfin]

... но вот что скрывается под параллелизмом объектов? (в смысле трудно представить как они могут существовать непараллельно?)

Так если их (объекты) в FIFO затолкать (не спрашивайте зачем, - не знаю..), то будут "существовать непараллельно"..

...перечислить проекты где применялись софт процы...

Я, лично, вопрос понял так же, а выводы каждый желающий должен был сделать для себя сам..

Хм.. Правда, это был уже другой участник:

прошу высказываться уважаемых форумчан, что им дало применение софтовых процессорных ядер.
очень было бы мило придерживаться некоторого плана ответа включающего пункты: какая техническая задача стояла, примерная конфигурация платы (какие каналы данных заводились в ПЛИС), какие алтернативы ПЛИС-архитектуры рассматривались и чем они не подошли (если что пропустил, плз, дополните).
ЗЫ: я чесное слово понимаю что идея сконфигурировать процессор последовательной интерпритации инструкций на ПЛИС - это круто. но так ли это эффективно по сравнению с полностью задача-оптимизированной системой на кристалле?

Сообщение отредактировал blackfin - Jul 30 2008, 15:21

[CaPpuCcino]

Так если их (объекты) в FIFO затолкать (не спрашивайте зачем, - не знаю..), то будут "существовать непараллельно"..

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

[Aprox]

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

Тут, по-моему, очень хорошо получается остаться в топике. Отбросим игры в красивые термины, а попросту возьмем простейший пример- реализация FIR-фильтра в FPGA. По-существу, это длинный сдвиговый регистр, много умножителей и один сумматор. Умножения и суммирование здесь производятся одновременно, за один цикл поступления данных. Что здесь существует параллельно, данные или операции,- неважно. Важно, что на софтпроцессоре последовательного действия такой же скорострельности фильтра никогда не достичь. Это один из тех примеров, когда ниосы не нужны и даже вредны. Более того, глядя на задачи скоростной обработки данных, я рискну заявить, что софтпроцессорам там тоже нет места. Потому, что проект в конечном счете приходит к некоторому разветвленному конвееру, каждый узел которого работает одновременно с остальными. Софтпроцессор такое принципиально не может. Поэтому, дело даже не в эффективности, не в стоимости, а именно в принципиальной невозможности применить софпроцессор в быстродействующей конвеерной обработке данных. И этот тезис очень сильно расходится с залихвасткой рекламой, например Альтеры, мол "ниосы могут все!"

[des00]

ну раз флуд, давайте, я это дело лю:
прикольная новая классификация! ну ветвь понятно - у нас домохозяет это называется поток (thread), функций тож понятно - параллелизм задач(task), комманд дано полагать это параллелизм инструкций (ILP как в VLIW), ещё забыт паралеллизм операций (OLP как в любом конвеере), но вот что скрывается под параллелизмом объектов? (в смысле трудно представить как они могут существовать непараллельно?)

мы читаем с вами разную литературу, я использую терминологию почерпнутую в сссровской книге про распараллеливание вычислений (книга 1986 го года вроде). Гуру у которого я консультировался порекомендовал мне ее покурить.

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

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

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

Господа участники, мне одному кажется что автор сделал конкретный проект и рассматривает применение софт ядра только в нем, причем совершенно не правильным образом, забывая про здравый смысл и совершенно не анализируя поступающую к нему от участников информацию ?

2 Aprox

ИМХО вам использовать софт ядра не имеет смысла, хотя решать вам. Удачи!!!

[Aprox]

будте так добры приведите ссылки на альтеру где сказано что "ниосы могут все!"

Буквально эту фразу я конечно не укажу в материалах Альтеры. Hо принцип, которым руководствуется маркетинговая служба этой фирмы именно таков. В каждый кит идет в нагрузку ниос. А к нему и тулзы разработки программ. Естественно и DDR2 память и флэш, без которых ниос не имеет смысла. Происходит приучение начинающих юзеров к использованию именно софтпроцессоров. Примерно в той же манере посадки на иглу, как Билл Гейтс приучает детишек в школе к виндам.

на то как именно применялись или применяются софт процы в реальных проектах, вы похоже просто закрываете глаза, как впрочем и на здравый смысл. Дело ваше

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

[EvgenyNik]

Aprox, Вы перегибаете палку. Одно только совместное расположение в одном корпусе CPU+FPGA ресурсов это уже большой плюс в плане технологичности (здесь и моделирование, и временные характеристики обмена, и гибкость периферии, даже банальная площадь на плате). Не во всех же задачах надо выжать 200-400 MIPS, зато в диапазоне 50 MIPSов и спец требованиях к периферии и т.п. это самое то.
Да, конечно, процессор специального назначения при прочих равных уделает софтовый по скорости, но это не лишает софт-ядро своих прелестей. Вы же не будете отрицать полезность ноутбука, который всегда при Вас, и строить всю работу только на настольнике только потому, что он производительнее, а ноутбуки это малоэффективное и дорогостоящее "дурение нашего брата" со стороны производителей ПК.
Я на НИОСе делаю то, что можно было бы сделать и типичными средствами для ПЛИС - VHDL, Verilog и (совершенно верно) даже бы быстрее работало, но скорость мне больше, чем есть, не нужна. Исходники на С прозрачнее для понимания, переносимее, приемственнее.
Всё зависит от конкретной задачи.

[des00]

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

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

Hо принцип, которым руководствуется маркетинговая служба этой фирмы именно таков. В каждый кит идет в нагрузку ниос. А к нему и тулзы разработки программ.

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

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

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

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

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

И не понятно чьи мучения вы видите. В топике было сказано достаточно аргументов за и против, приведены примеры. ИМХО но основе внимательного прочтения топика можно сформировать свое мнение о применимости софт ядер.

Я не закрываю глаза, а очень внимательно пытаюсь найти здравое зерно в аргументах за софтпроцессоры.

Вот только ищете не там, о чем вам уже неоднократно говорили в данном топике, но по непонятным причинам смотрите только на свой узкий случай.

Отбросим игры в красивые термины, а попросту возьмем простейший пример- реализация FIR-фильтра в FPGA

думал сами поймете что написали глупость, ну да ладно поясню свое ИМХО:

вы не указали производительность своего фильтра и его параметры, без этого разговор о том что лучше теряет смысл.
может быть вам нужен цикл вычислений 1 раз в секунду и фильтр у вас не сложный, тогда способ реализации фильтра не принципиален, а может быть у вас отсчеты идут на частоте 350 МГц тогда способ реализации очевиден.

положим теперь что ваш FIR стоит в вычислительной системе, данные которые он обрабатывает ложаться во внешнюю память, потом в случайном порядке забираются и передаются по сети. При этом сама система управляется тоже по сети. Вы все это тоже будет описывать ручками и на КА ?

Неужели вы никогда не делали КА ? Процессор это тот же КА, только более продвинутый и более медленный.

Кстати почитайте статьи Ken Chapmen а с xilinx.com, очень интересно пишет про микропрограммное управление и микропрограммные автоматы.

Удачи.

[zltigo]

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

Moderator:
Для начала выводы сделал я - скрыл в этом топике Ваши схоластические толкования названия темы.
Уже стало чище.

[CaPpuCcino]

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

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

захотите поспорить, если будет время, может флудить в чате или аське %))

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

[Aprox]

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

Конечно я не вижу необходимости в FPGA на низких и средних скоростях поступления данных. Для этого существуют готовые сигнальные процессоры. И соревноваться с ними в эффективности на средних скоростях выглядит просто неразумно. Пустая трата сил.

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

Извините за вульгаризм, а нафига это "Hellо World"? Оно что, сразу делает юзера и его начальство счастливыми человеками?

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

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

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

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

И не понятно чьи мучения вы видите. В топике было сказано достаточно аргументов за и против, приведены примеры. ИМХО но основе внимательного прочтения топика можно сформировать свое мнение о применимости софт ядер.

Может, я что-то и проглядел, но слышу в ответ только абстрактные заклинания типа: "Все зависит от задачи." По-делу видел заявления о возможности самому создавать свою периферию, не знаю правда зачем. Что еще... "подносить дрова" к конвееру обработки данных, как я понимаю, ввод извне и задание параметров в регистрах. Hазвать это софтпроцесором, извините, не могу. Тратить на такое ресурсы- тоже.

Вот только ищете не там, о чем вам уже неоднократно говорили в данном топике, но по непонятным причинам смотрите только на свой узкий случай.

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

вы не указали производительность своего фильтра и его параметры, без этого разговор о том что лучше теряет смысл.
может быть вам нужен цикл вычислений 1 раз в секунду и фильтр у вас не сложный, тогда способ реализации фильтра не принципиален, а может быть у вас отсчеты идут на частоте 350 МГц тогда способ реализации очевиден.

Очень верное замечание! Только сразу вопрос, если скорость так мала, то нафига вообще FPGA? Берем готовый DSP чип, и вперед. Hа порядок дешевле и быстрее выйдет.

положим теперь что ваш FIR стоит в вычислительной системе, данные которые он обрабатывает ложаться во внешнюю память, потом в случайном порядке забираются и передаются по сети. При этом сама система управляется тоже по сети. Вы все это тоже будет описывать ручками и на КА ?

Я не знаю, что такое "КА". И представляете- горжусь этим! А сетевой задачей на FPGA занимаюсь как раз в настоящее время. Софтядрам там места точно нет. Не вытянут они 1G и выше Ethernet.

[blackfin]

Я не знаю, что такое "КА".

"КА" - Конечный Автомат. Он же - State Machine.

[des00]

Конечно я не вижу необходимости в FPGA на низких и средних скоростях поступления данных. Для этого существуют готовые сигнальные процессоры. И соревноваться с ними в эффективности на средних скоростях выглядит просто неразумно. Пустая трата сил.

Очень верное замечание! Только сразу вопрос, если скорость так мала, то нафига вообще FPGA? Берем готовый DSP чип, и вперед. Hа порядок дешевле и быстрее выйдет.

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

Могу подкинуть еще одну, над которой работаю : модем РРЛ, QAM16, Reed Solomon, непрерывный режим работы, HDB3 2/4/8 мегабита. У меня все работает на детской частоте в 34.816 МГц, занимает 70% с35. На каком дсп вы такое сделаете ?

Извините за вульгаризм, а нафига это "Hellо World"? Оно что, сразу делает юзера и его начальство счастливыми человеками?

Нет для того что бы быстро собрать ту же систему с 10ю уартами, силами инженера слабой/средней подготовки. Без долгого моделирования, переразводок, танцами с бубном и т.д.

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

Великий гуру zltigo, говорил немного не так, не перегибайте палку. Он говорил именно про задачи которые стоят перед ним, и для его задач внутренней памяти не хватает.

Ну что же, экономьте на спичках. Значит многие мои коллеги и я не разумно используем ресурс фпга, отдавая 1-8 блоков памяти под хранение микропрограммы, которую кстати можно заменить без переразводки проекта.

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

еще вопрос, экономия на кристалле 30 баков, или дополнительный труд разработчика в течении 3-х месяцев с зарплатой в 2-3 килобака. Хотя конечно если у вас серия больше 10000 штук, то тут вы возможно правы.

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

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

из рабочих проектов: как стоял с35 так и стоит. что то делаю не так ?

По-делу видел заявления о возможности самому создавать свою периферию, не знаю правда зачем. Что еще... "подносить дрова" к конвееру обработки данных, как я понимаю, ввод извне и задание параметров в регистрах. Hазвать это софтпроцесором, извините, не могу. Тратить на такое ресурсы- тоже.

Займитесь кодированием видео, аудио. узнаете много интересного про "патроны" и свою переферию, рекомендую почитать выпуск Xcell Journal, посвященный софт-ядрам (там приведены рабочие проекты).

Я не знаю, что такое "КА". И представляете- горжусь этим! А сетевой задачей на FPGA занимаюсь как раз в настоящее время. Софтядрам там места точно нет. Не вытянут они 1G и выше Ethernet.

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



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

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

[zltigo]

...zltigo, говорил немного не так, не перегибайте палку. Он говорил именно про задачи которые стоят перед ним, и для его задач внутренней памяти не хватает.

Так, но тем не менее не так узко-конкретно - "стоят только передомной" . К моему величайшему сожалению внутренней памяти не хватает для очень и очень многих задач. Я не буду сейчас распинаться перечисляя задачи, и уж тем более мне надоело выслушивать в ответ - а для моих хватает... Давайте просто посмотрим на существующие массовые, подчеркиваю, массовые микроконтроллеры - это уже сейчас до 32..64K RAM и 128..512K Flash и единицы баксов цены. Если такие контроллеры, с такими ресурсами выпускаются, значит массовые задачи под них существуют. Вот такая совершенно объективная реальность. Причем это действительно массовые, мелкие, дешовые контроллеры отнюдь не в BGA. FPGA c хотя-бы прибижающимися к ним "лишними" ресурсами это железяка другого класса и совсем другой цены. Не реально просто "не сэкономить 30 баксов" и получить за эти деньги в не BGA корпусе upgrade столь-же массового 10-20-30 баксового FPGA эти дополнительные ресурсы. Посему, очень и очень не выгодно если это даже не "серия больше 10000 штук" . Как я уже неоднократно писал все меняется к лучшему и нашего брата не дурят подсовывая "всякие ниосы" - уже завтра это будет совершенно оправданным решением во много-много большем количестве применений.

[Aprox]

....Посему, очень и очень не выгодно если это даже не "серия больше 10000 штук" . Как я уже неоднократно писал все меняется к лучшему и нашего брата не дурят подсовывая "всякие ниосы" - уже завтра это будет совершенно оправданным решением во много-много большем количестве применений.

Если не затруднит, то можно подробнее- что именно на ваш взгляд меняется к лучшему?

[iosifk]

Читаю несколько дней эту переписку и жду, когда же "зачинатель" этого топика начнет "крыть" мои высказывания о софт-процессорах. А ведь я довольно подробно расписал мою точку зрения на этот вопрос, или говоря его словами - "дурю головы"... И делаю это уже много лет...
Вот и делаю вывод, что он даже не потрудился поискать по сети, что и где сказано по этому поводу....
И еще... Конечно, если в голове только одна любимая Альтера, а Кен Чепман пишет на сайте Ксайлинкса, то он тоже не "указ" и тоже, наверное, "дурит"... Но про него пока ни слова не сказано...
Ну и давайте теперь спросим автора топика: почему же существуют как минимум 3 версии Ниоса, да еще секвенсер у Альтеры?
Почему у Ксайлинкса есть 2 процессора - большей и меньшей производительности? Почему Актел имеет 8-ми битник и АРМ.... Почему все они так настойчиво "дурят" автора топика?
Судя по топикам, для него автомат на пару сотен состояний - любимое дело... Или, или у него их там вовсе нет?

Вообще обсуждение похоже на известную басню о том, как слепые ощупывали слона.
Каждое суждение необходимо соотносить с конкретной задачей... Тут я только могу ему порекомендовать прочесть про "Гайку М3"...
Иначе, все высказывания можно свести к лозунгам.
Ну а по сути, все что ему написали в ответ - практически полностью совпадает с моими взглядами.
удачи всем господа!

P.S. Я, как и Денис, скорее всего, останусь при своем мнении. А оно Вам известно.
Пойду делать топик про новую микросхему KSZ8851. Это для жизни будет полезней...

[Aprox]

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

Существуют чипы MCU, в которых 4штуки UART-ов. Пара таких чипов будет дешевле и быстрее в реализации. чем 10 уартов плюс софтпроцессор в FPGA.

Могу подкинуть еще одну, над которой работаю : модем РРЛ, QAM16, Reed Solomon, непрерывный режим работы, HDB3 2/4/8 мегабита. У меня все работает на детской частоте в 34.816 МГц, занимает 70% с35. На каком дсп вы такое сделаете ?

Как коллега коллеге по модемам, скажу: кодирование/декодирование QAM16 и Reed Solomon вы точно делаете не софтпроцессором. Чем же он в вашем проекте занят?

Ну что же, экономьте на спичках. Значит многие мои коллеги и я не разумно используем ресурс фпга, отдавая 1-8 блоков памяти под хранение микропрограммы, которую кстати можно заменить без переразводки проекта.

Не замечал никаких проблем с переразводкой. Зачем ее избегать?

Займитесь кодированием видео, аудио. узнаете много интересного про "патроны" и свою переферию, рекомендую почитать выпуск Xcell Journal, посвященный софт-ядрам (там приведены рабочие проекты).
Никто и не обещал вам вытягивание гигабита с ниоса. Насколько я понимаю вы работаете на уровне сырых данных и в сети ваша машина работать не будет. Пример этот был референсный, который вы опять же отмапили на свой конкретный случай.

Да, начинал работу с RAW-пакетов. Но перешел на стандартное UDP именно для работы в сети без проблем. Поэтому не совсем понимаю, в чем ущербность моего примера.

[zltigo]

Если не затруднит, то можно подробнее- что именно на ваш взгляд меняется к лучшему?

1. Главное. Цены на приличные FPGA падают на глазах
2. На контроллеры падают заметно медленее - собственно падать им особо уже и некуда. Да и собственно микроконтроллерная ветка достаточно тупиковая из-за сочетания такой весьма и весьма гибкой штуки как процессор и жестко ограниченного набора периферии. Плохое сочетание . Да естественно есть устоявшиеся майнстримовые джентельменские наборы периферии и при попадании в потребности конкретного проекта все просто изумительно по эфффективности. Но шаг в сторону и ... и появляется/добавляется FPGA. Мне, напимер, собственно контроллерная периферия практически нужна минимальнейшая.
3. Производства все меньше и меньше пугают BGA и многослойные платы, да и цены на них тоже снижаются по мере нарастания их доли в общем объме производства.
4. Выбор софтядер расширяется и они развиваются.

[blackfin]

Чисто из любопытства..
Кто-нибудь может указать серийно выпускаемую модель сотового телефона в котором коррелятор и пр. кодеки реализованы в FPGA и в ней же, на оставшихся LE, синтезирован софт-процессор? Желательно, что-нибудь известное, а не поделки из китайского склепа в единичных экземплярах.. ИМХО, сотовые телефоны вполне подпадают под категорию "массовый продукт" и, следовательно, лишними мегабаксами никто разбрасываться не станет.. Про DSP, - вроде как их там вполне успешно применяют..

[zltigo]

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

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

[Alex77]

Между CPU+FPGA и SOFT_FPGA есть одно большой различие. Цикл разработки, внедрения, сопровождения может оказаться больше, чем время жизни конкретно выбранного CPU. В результате придётся изучать новый CPU (замену снятому с производства). А у каждой новой модели CPU всегда найдутся отличия: первоначальное конфигурирование, другой набор перефирии, другой тип корпуса, новые особенности чипа (глюки) итд. Преимущество SOFT_FPGA в большем времени жизни, как микросхемы. Можно привести ещё много аналогичных доводов.
PS: НО у каждой конкретной разработке свои требования (специфика) и это определяет выбор CPU+FPGA или SOFT_FPGA.

[zltigo]

Преимущество SOFT_FPGA в большем времени жизни, как микросхемы.

Увы, все совсем не так, я не совсем в курсе не алтеровских чипов, но алтеровские старые чипы дорожают столь стремительно, после выхода новых семейств, что при сколь-нибудь серийном выпуске переделки и переразводки просто неизбежны . Вот лежит железяка пяти-шести давности стоимость чипа зашкаливает за 200 баксов. По нынешним временам это делается за 5-7 баксов.

Можно привести ещё много аналогичных доводов.

"Аналогичных" - не надо

[Aprox]

Между CPU+FPGA и SOFT_FPGA есть одно большой различие. Цикл разработки, внедрения, сопровождения может оказаться больше, чем время жизни конкретно выбранного CPU. В результате придётся изучать новый CPU (замену снятому с производства). А у каждой новой модели CPU всегда найдутся отличия: первоначальное конфигурирование, другой набор перефирии, другой тип корпуса, новые особенности чипа (глюки) итд. Преимущество SOFT_FPGA в большем времени жизни, как микросхемы. Можно привести ещё много аналогичных доводов.

На мой взгляд время жизни модели FPGA меньше, чем время жизни модели MCU. Достаточно взглянуть на скорость, с какой, например, Альтера выпускает C1, C2, C3. И каждый новый вариант новаций требует значительной перетряски проекта и пакета разработки. Т.е. ситуация ровным счетом наоборот, нежели вы представили.

[Stewart Little]

На мой взгляд время жизни модели FPGA меньше, чем время жизни модели MCU.

Ну и что?
При разработке львиную долю времени съедает софтописание.
И перекомпилировать FPGA'шный проект для нового семейства FPGA (абсолютно не трогая при этом исполняемого кода soft-ядра) будет гораздо быстрее и проще, чем переписать код под новый MCU.
И никакой значительной перетряски проекта, а уж тем более пакета, при этом не требуется.
Я переносил один и тот же проект по всей линейке циклонов, и его же переносил на стратиксы - ну нечего там перетрясать абсолютно!

[Aprox]

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

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

И еще... Конечно, если в голове только одна любимая Альтера, а Кен Чепман пишет на сайте Ксайлинкса, то он тоже не "указ" и тоже, наверное, "дурит"... Но про него пока ни слова не сказано...

Извините, но у меня нет ни времени, ни желания на академические изыскания.

Ну и давайте теперь спросим автора топика: почему же существуют как минимум 3 версии Ниоса, да еще секвенсер у Альтеры?
Почему у Ксайлинкса есть 2 процессора - большей и меньшей производительности? Почему Актел имеет 8-ми битник и АРМ.... Почему все они так настойчиво "дурят" автора топика?

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

Судя по топикам, для него автомат на пару сотен состояний - любимое дело... Или, или у него их там вовсе нет?

Да, с воображением у вас все в порядке. Настоящий литератор! Жаль только, так увлеклись праведным гневом, что совсем не заметили моих тезисов о здоровой инженерной алтернативе софпроцессорам в FPGA.

[Postoroniy_V]

Чисто из любопытства..
Кто-нибудь может указать серийно выпускаемую модель сотового телефона в котором коррелятор и пр. кодеки реализованы в FPGA и в ней же, на оставшихся LE, синтезирован софт-процессор? Желательно, что-нибудь известное, а не поделки из китайского склепа в единичных экземплярах.. ИМХО, сотовые телефоны вполне подпадают под категорию "массовый продукт" и, следовательно, лишними мегабаксами никто разбрасываться не станет.. Про DSP, - вроде как их там вполне успешно применяют..

про мобилы не скажу, но знаю что там арм9(в каких то телефонах), в каком виде присутствует не знаю
скорей всего SOC, хард ядро.
а вот про BTS легко. есть место и для dsp и для fpga с софт ядром... но мне кажется это не аргумент ни для вас ни для гуру

з.ы. речь про самсунг

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

Извините, но у меня нет ни времени, ни желания на академические изыскания.

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

Да, с воображением у вас все в порядке. Настоящий литератор! Жаль только, так увлеклись праведным гневом, что совсем не заметили моих тезисов о здоровой инженерной алтернативе софпроцессорам в FPGA.

2 модератор флуд?

Ну и что?
При разработке львиную долю времени съедает софтописание.
И перекомпилировать FPGA'шный проект для нового семейства FPGA (абсолютно не трогая при этом исполняемого кода soft-ядра) будет гораздо быстрее и проще, чем переписать код под новый MCU.
И никакой значительной перетряски проекта, а уж тем более пакета, при этом не требуется.
Я переносил один и тот же проект по всей линейке циклонов, и его же переносил на стратиксы - ну нечего там перетрясать абсолютно!

Роман, для товарищей это не аргумент!
Цена их пугает! причем в первую очередь! Я про стратиксы, а то что циклоны дешевле вам скажут что зачем туда софт проц пихать? если можно снаружи навесить арм. ну и так по кругу.....

[Aprox]

При разработке львиную долю времени съедает софтописание.

Hет, львиную долю времени съедает тестирование и отладка

И перекомпилировать FPGA'шный проект для нового семейства FPGA (абсолютно не трогая при этом исполняемого кода soft-ядра) будет гораздо быстрее и проще, чем переписать код под новый MCU.

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

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

Вам виднее. Я лично избегаю переносить работающие проекты в новые чипы, поскольку известно- лучшее враг хорошего. Как запустил семь лет назад на ACEX-е PCI-плату радарного экстрактора морских целей, так и продолжаю сопровождать ее на ACEX и MAX-II. Hесмотря на то, что это все старье и ACEX нынче стоит очень неслабо. Зато новый проект начинаю на современной основе, причем с запасом и совместимостью вверх, чтобы потом не пришлось скакать по моделям FPGA.

[Postoroniy_V]

.....

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

Вам виднее. Я лично избегаю переносить работающие проекты в новые чипы, поскольку известно- лучшее враг хорошего. Как запустил семь лет назад на ACEX-е PCI-плату радарного экстрактора морских целей, так и продолжаю сопровождать ее на ACEX и MAX-II. Hесмотря на то, что это все старье и ACEX нынче стоит очень неслабо. Зато новый проект начинаю на современной основе, причем с запасом и совместимостью вверх, чтобы потом не пришлось скакать по моделям FPGA.

1) в случае с софт ядром не понадобится переписывать софт и отлаживать его, тут вы согласны?
2)я был не прав, цены вас не пугают, вас пугает неизвестность
3) извините, но как так случилось что вы используете ACEX но и в то же время MAX-II? циклон1 в то время уже был ведь. да дешевле был ведь....

[Stewart Little]

To All :

Предлагаю прикрыть эту тему.
Каждый все равно остается при своем мнении, а стиль аргументов типа "сам дурак" и переход на личности никого не красит.
Мне, к сожалению, результат этого обсуждения напоминает старый анекдот : "тебе не кажется, что мы забесплатно дерьма наелись?"

Модератор со мной согласен?