Я по uart получаю пакеты данных - некие команды с параметрами.
Задача простая, мне нужно команду разобрать и в зависимости от
команды и ее параметров перенаправить ее туда или туда дальше на другие UARTы.
Может иногда поменяв параметр. Что-то типа роутера.

Из соображений масштабируемости и пр и пр наверное лучше
навернуть небольшой CPU в мой Xilinx. Но тогда понадобится дополнительный
тулчейн и время на осваивание этой технологии.

Другой вариант - просто парсить команды c параметрами CASEом на родном VHDL

Что лучше?

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

picoblaze - time to study is less that a day

Из пушки по воробьям. FPGA/HDL конечно.

Да нет, они для этого и сделаны, самые маленькие встраиваемые процы. Как говорится, "запомни, лучше день потерять потом за 5 минут долететь!"

А в чём собственно разница между CPU и FSM?
Любой процессор в конце концов и есть конечный автомат. Вопрос лишь в том что лучше - написать свою машинку, потом долго и нудно её отлаживать, либо взять готовый маааленький проц, написать для него программу, и потом её долго и нудно отлаживать. Каждый подход имеет свои плюсы минусы. Если спешить особо некуда (UART - штука медленная) и лишних несколько сотен плиток не жалко, то проще взять что-то типа пикоблейза. Но это не избавит вас от процесса отладки.

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

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


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


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


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

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

Что касается моих статей и вашего к ним отношения, то это статистика. Кому-то нравится, кому-то - нет... И эта самая статистика показывает, что таких как вы - мало... Следовательно, этим высказыванием можно пренебречь... Увы!

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

В спор не вмешиваюсь, но хочу отметить что Пикоблейз бесплатный, идет в сорцах, есть VHDL/Verilog версии.

Выскажу свое мнение.
Резких высказываний на форуме становится все больше, что не очень приятно.
Это возможно, если после критики приводятся железо-бетонные аргументы в пользу той или иной
точки зрения, но в подавляющем большинстве случаев этого не происходи.
Мы все таки не коменты постим к новостям на live.ru или тролим друг друга на спортивных сайтах.

Если по теме, то сам стою перед выбором, микро ядро или чисты hdl.
Тут все зависит от решаемой задачи. У топик стартера, на мой субъективный взгляд, "дешевле" будет
все реализовать в логике. Тут какой еще фактор, помимо надежности и способов отладки, не стоит забывать,
наличие микро ядра в проекте подразумевает и соответствующую архитектуру проекта.
Если есть процессор должна быть и системная шина (благо тут тоже есть бесплатные реализации, например wishbone),
сразу появляется необходимость разрабатывать порты hdl модулей к этой шине, если интенсивность поступаемых данных высока и их необходимо
буферизировать в оперативной памяти перед парсигом, то это уже получается и DMA необходимо реализовывать под определенную шину.
Ну и в целом весь алгоритм работы устройства притерпевает изменения.

В этом плане радует какой подход избрал xilinx в своей новой системе разработки Vivado.
Любой дизайн вне зависимости от того есть hard/soft процессор или его нет, строится вокруг шиной архитектуры в их случае AMBA AXI4.
Будут IP packager с помощью, которого можно оборачивать IP от xilinx или других вендоров, а также свои модули в оболочку с портами
к шине. Хорошо это или плохо и любой ли дизайн можно "зацентровать" на шинну архитектуру вопрос дискуссионный.
Но тренд очевиден - абстракция, абстракция, абстракция

если UART на ~4 команд до FSM. Fmax = Highest
если UART на ~50 команд, то picoblaze. Fmax = High, но требуется bram
иначе что то более тяжелое. Fmax = Medium, и не один bram а то и внешние микросхемы памяти.

Ни в коей мере не пытался вас оскорбить, просто имею нехорошую привычку говорить именно то, что думаю, при этом не особо вникая в личность оппонента. Извините, если вас задел лично. Мы сейчас спорим об абстрактных вещах, поэтому спор наш контрпродуктивен. Давайте возьмём реальную задачу и решим её двумя разными способами - тогда можно будет доказать _на _реальном_примере_ какой подход имеет приемущество. Понятно, что не существует универсальных рецептов. Для передачи пары байт по UART достаточно _любого_ процессора (в том числе и вашего, самопального, никто с этим не спорит), тут не нужна гонка за тактами. А вот к примеру для пересылки данных из PCI-E в multiport DDR memory controller неплохо бы не просто иметь весьма эффективный автомат, но и реализовать в нём функции кэша. Иначе всё будет очень медленно и уныло.
В общем, предложение мое очень простое : берём конкретную задачу, к примеру нужно отреагировать на какие-то заданные входные воздействия определённым методом. Далее сравниваем два подхода : с использованием CPU (не важно какого) и FSM. Пусть к примеру ТС полностью обрисует задачу, и мы решим её двумя разными способами. Повторяю - я не хочу доказать истину, заключающуюся в том, что CPU лучше FSM или к примеру CPU от Чапмена лучше CPU от iosifk - это всё лищь спор ни о чём. Мы берём конкретную задачу и решаем её двумя разными способами. Критерий истины = ресурс/количество тактов до реакции. Если вам кажется такой критерий неправильным - приведите свои критерии истины.

Я для себя все это прошел лет 10 назад. И все это описал, как сумел... Потому здесь заниматься этим ради полусотни посетителей и для непонятной цели не буду. Нет времени и сил.
А Вам предлагаю следующее.
Если Вы действительно можете и хотите показать, что Вы что-то способны, то напишите об этом статью, а я, как член редколлегии Кит, помогу Вам ее напечатать. К примеру, свяжите в одну тему CPU в ПЛИС и автоматное программирование от Шалыто... Вот это и будет серьезный подход. И тогда 6 тыс. читателей КиТ Вам скажут спасибо. ТС тоже может поучаствовать, т.к. он может сформулировать конкретную задачу и для нее сделать автомат, например... А я проверю текст и подскажу, что и где надо будет добавить или изменить. Почту и личку мою знаете. Так что предложение Вам сделано и опыт в таких делах у меня есть. Да и "понятые" тоже здесь присутствуют, подтвердят, что предложение реальное...
Думайте.
А все кто хочет присоединиться к статье - милости просим...
Удачи всем...

Вообще-то полезно решать иногда несложные задачи "со стороны": 1)отвлечься, размять мозги, 2)почерпнуть полезное.


Так что пусть ТС приведет прогу на Си, а там видно будет.