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

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

Новизна и ёмкость значима - будут спрашивать и развивать.

Чем мы тут, собственно, и занимаемся.

Сначала ответил тут сам. И только потом задал вопрос GPT o1:

Ответ: Вы подняли важный вопрос о восприятии текста читателями. Действительно, ожидать, что мысли автора будут напрямую и без искажений переданы в сознание читателя, — наивно. У каждого человека свой опыт, свои фильтры восприятия, которые влияют на интерпретацию прочитанного. Иногда стоит пересмотреть подачу материала, добавить примеры или изменить акценты, чтобы донести идею более эффективно. Обмен мнениями и открытая дискуссия помогают увидеть разные точки зрения и обогатить понимание темы. Спасибо за интересную тему для размышления!

Акт 3. Загрузка в GPT для сравнить:

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

Ответ: Если есть что сказать, и есть наработанное - то ожидать поклонников глупо, это будет, скорее, зеркало автора, и показатель его глубины знаний.
Любая инфа, проходя через мозги разных людей, откладывает позитив/негатив, и как результат, подсознательно решается для читателя, это ступенька вверх, или вниз.

Новизна и ёмкость значима - будут спрашивать и развивать.

Чем мы тут, собственно, и занимаемся.

В чём различия Вопроса и Ответа? (далее ответ GPT)

Различия между Вопросом и Ответом:

Фокус на коммуникации vs. отражение автора:

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

Подход к аудитории:

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

Ожидания от результата:

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

Цель взаимодействия:

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

Тон и намерение:

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

P.S. На закате ФИДО был такой дискуссионный местный клуб.
Задавался вопрос ВСЕМ, ответы модератору, не более 20 строк, и через 5 дней мод скидывал все варианты.
Несколько десятков ответов - это было что-то!!!!!!!!!!!!!!!!!!

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

Что ж, побуду чуточку стороной обвинения

ПЛИС и микроконтроллеры решают примерно одни и те же задачи. Но ПЛИС в общем случае, если сравнивать с микроконтроллерами, дороже, тактовая частота ниже, порог входа сильно выше, выбор меньше (2 с половиной производителя, если считать Intel, AMD и Gowin), да и писать под гипотетический процессор в ПЛИС придется, скорее всего, на ассемблере, а не на Си. Так не проще ли взять микроконтроллер?

Вот уже сразу интересно. Интересно еще и тем, что вопрос частый (и я понимаю, что и ответ на него в целом-то понятен).

Что также интересно, в целом и цепочка рассуждений корректна. Вопрос только в исходном посыле - "ПЛИС и микроконтроллеры решают примерно одни и те же задачи". Соответственно, мы от него отказываемся, и все становится немного не так. Почему же вдруг разные задачи?
1. Много параллельно работающих ресурсов.
- Цифровая обработка сигналов на аппаратных блоках DSP.
- Коммуникации (как на трансиверах, так и без).
- Интеграция цифровых интерфейсов, ввиду сотен I/O даже в недорогих семействах.
2. Очень специализированные схемы. Настолько, что на МК их нет, или они там дороги.

Поэтому проект на ПЛИС следует рассматривать не как воспроизведение подходов, известных из мира МК, а как изначальную разработку чего-то необычного... которое на определенном этапе начинает требовать управления, отладки, настройки и т.п. Если в МК элементарно организуется отладочная печать в UART или на подключенный дисплей, на HDL такую печать делать непомерно сложнее, в том числе и потому, что любое изменение уровня "нужен пробел между числами" приводит к перестройке модуля, выводящему в UART, а итерация в САПР ПЛИС существенно дольше, чем компиляция проекта для МК. Аппаратные же отладчики - это полумеры, потому что их тоже надо настраивать, менять там сигналы, глубину просмотра и проч. К слову, ровно из тех же соображений сокращения цикла Edit-Compile-Run в проекте полезен Форт, причем именно потому что это простой в реализации интерпретатор, а не потому что он обладает какими-то потрясающими свойствами с точки зрения языка.

В итоге получается, что процессор в ПЛИС - это:
- внешний программируемый интерфейс к сложным IP_ядрам;
- вообще интерфейс - GUI, консоль, прочая периферия, включая опрос кнопок и переключение по ним чего-то внутри;
- разгрузка центрального процессора, понимая под ним не столько x86 "снаружи", сколько ARM, RISC-V и другие аппаратные или синтезированные ядра, которые уже по каким-то причинам попали в проект. Такой процессор вовсе не должен быть Out Of Order глубоко конвейеризованным RISC с многоуровневым кэшем (чтобы как у всех), а напротив - настолько незаметным, чтобы забирать часть процессов себе, делая работу с ними прозрачной для программиста.

Имел ввиду, что и ПЛИС и микроконтроллер - программируемый черный ящик с лапками, который превращает бездушную плату в нечто "разумное". Т.е. в глобальном смысле их задача в том, чтобы вдохнуть жизнь в изделие. Это с точки зрения стороннего наблюдателя. Понятно, что для одних задач больше подходит ПЛИС, а для других - микроконтроллер. Но это вовсе не означает, что микроконтроллер не может посчитать, например, традиционно удобное для ПЛИС БПФ (вопрос скорости и эффективности такого решения оставляем за скобками). С другой стороны, ПЛИС вполне можно превратить в заурядный микроконтроллер, зашив туда соответствующее IP-ядро и напихав полную панамку нужной и не очень периферии, а потом весело мигать светодиодом.

Я раз проиграл битву Мк vs FPGA, будучи на стороне МК..кончились ноги и ресурсы по расширению..

Про это было сказано тут очень много с пяток лет назад.
А воз и ныне там.
В ПЛИС за $20 можно запихать 4-8 шт (поправьте, если больше) Cortex-M0, и получить независимые решения, а не корячится с многозадачностью, и делением для этого ресурсов.
Памяти внутри вполне может хватить для моих задач, а если ещё и периферию чуть подправить!!!
Не делая упор на специализированость, а только на упрощение решения многих задач - из камня торчат только IO.
Будь такой камень уже готовый - я бы взял сразу в разработку.
Сейчас, "№; - только через различные усложнения такое возможно...

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


Да, вот подходящий пример. БПФ действительно хорошая штука, вот только с точки зрения именно инженера. А специалист, который это БПФ в проекте обосновывает, может нервничать и сомневаться - а хватит ли точек? А может, нужно окно наложить? А какое? А может, придется два окна с перехлестом? А пред- и постобработку? Если эти вопросы не решены вот прямо максимально обстоятельно, с испытаниями, и нужно только сделать серийный образец, тогда задача перетекает в плоскость "как это сделать на этой микросхеме". Но когда нужно пространство для маневра, вроде бы подходящий МК имеет меньше резервов, чем ПЛИС как таковая. Отсюда и постановка вопроса про софт-ядра - чем конкретно они могут помочь. И отсюда конкретные сценарии использования, чтобы они были полезны, а не для декларации сопричастности к бренду. В этой связи интересны "экстремальные" софт-процессоры - маленькое ядро, маленькая команда, или наоборот, с глубокой конвейеризацией, сверхширокой командой, нестандартными связками команд и т.д.

А, кажись, понял. Тема не битве FPGA vs CPU посвящена.
Тут рассматриваются изделия, где на борту уже стоят/планируется либо FPGA и CPU, либо просто FPGA. И утверждается, что FPGA с процессором (процессорами) внутри лучше, чем просто FPGA без оного. Ну и потенциально некоторые (но не все) изделия, у которых FPGA и железный CPU на борту, могут быть упрощены до варианта с одной микросхемой FPGA (+софт-процессор).

Именно!

Видимо, этот аспект стоит отдельно пояснять, "на входе". Сама тема МК vs ПЛИС - действительно отдельная, но она часто возникает при выборе элементной базы. А это все-таки два существенно отличающихся маршрута, со своими сильными и слабыми сторонами. Где-то приводили статистику, что ПЛИС стоят примерно в 15% проектов. Вроде бы не 90, и даже далеко не 50. Но ведь тут такой момент - а представим русскую рулетку, ведь 15% - это примерно "один патрон в барабане из 6". Упустим возможность поставить ПЛИС - упустим правильную стратегию реализации проекта. Да и статистика дело такое - она не утешает того, кому попались именно эти малые вероятности.

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

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

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