Я по 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)почерпнуть полезное.


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

Уважаемые коллеги,
извините что не мог на праздники участвовать в дискуссии. Был приятно удивлен
таким участием в моей проблемме.
Несколько месяцев назад делал контроллер под видео сенсор. Уже все работает в железе
Сейчас впихиваем все это в форм фактор.
Там все было гораздо проще. Было пять команд по УАРТу: Reset, Read/Write Memory, Get/Set Register. (типа 001, 010, 011, 100, 101)
Используя http://www.gaisler.com/doc/vhdl2proc.pdf я написал простой командник и очень упрощенный DMA

Теперь мне нужно два сенсора подцепить к одному хосту. У него уже утвержденный список телеграмм (10 штук)
Телеграмма имеет СТАРТ, КОНЕЦ, ДЛИНА, ДАННЫЕ (начинаются с ID), КОНТРОЛЬНАЯ_СУММА. Спец символы дополняются префиксом
Например 04h совпадает с ESC, поэтому заменяется на 040Сh

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

Сделать для этого машину состояний мне уже не очень сложно. (Я начал работать в этой области с полного нуля год назад сразу над реальным проектом, читал гуглил и тут же лабал. Сейчас хочется во второй итерации делать все грамотно)
Поэтому начал читать iosifk статьи, записался на осень на курсы по НИОСУ в ЭФО в Политехе. Накачал варианты МикроБлэйза с ОпенСоурса. Так что месяца через два у меня будет оба варианта - МашинаСостояний и ЦПУ. Отпишусь.
А пока с вашего разрешения буду задавать глупые вопросы в этой теме. Наверное не стоит плодить темы?

Я бы не хотел заниматься написанием статьи по разным причинам.
1. Время. Сейчас мне его адски не хватает, а статья - это серьёзно, много времени потратить нужно.
2. Не считаю себя достаточно компетентным в эттом вопросе, развивать тему влубь - это опять же время, а его сейчас просто нет.
Потратить пару часов на написание небольшого примера - на это я пойти готов. Потратить несколько дней на написание статьи - увы, слишком большая роскошь...

Мне удалось анимировать пример с http://www.echelonembedded.com/fpgaresources/ для платы NEXYS2
на своей плате. Программа ПикоБлэйза работает с УАРТом нормально.
Но адр.шина этого проца 8. То есть, только 256 инструкций?
Или как-то через порты и этот ваш brяm можно увеличить размер программы?

Шина адреса памяти команд у пикоблейза(того который KCPSM3) 10 разрядов, так что 1024 инструкции.

Хорошо!
А если не влезает, то наверное я должен через некий порт переключать банки
и менять РС?

Хочу поделится своими соображениями когда что лутше....
Сначала договоримся, что всё должно быть лицензионное.

Учтём следующее:

1) Процессор требует порядка ~100 флопов + ROM + RAM
Если FSM требует меньше площади - она лутше.
Если разнообразие задач большое, то понадобиться много FSM-мов, а значит и площади.
2) Процессор требует лицензии, компилятора (минимум ASM).
без компилятора - не стоит тратить время (дебаг "не С кода" очень затруднён).
Соотв. "самопальные процессоры" - себе дороже (кто сделает компилятор?).
3) В ASIC вставлять память - создавать проблему с тестированием, масками прошивки, дебагом и т.д.

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

Совершенно согласен.
Тем более, что ПикоБлэйз is free, и о нем достаточно много информации.
Только пережевать ее чтобы, нужно много времени.
Весь день сегодня читаю ug129.pdf но правду о программе более 1024 инструкций так и не нашел

А фиг там: "The license of the cores allows their free use, albeit only on Xilinx devices"
Оно фрии для Xilinx и только. В Альтеру нельзя, ASIC нельзя......

-----------------
Кстати, кто знает конфигурируемый процессор (8-16 бит) с дебагером, бесплатный и с GCC компилятором?

Вот хорошая дискусия по поводу >1024 инструкций
http://forums.xilinx.com/t5/PicoBlaze/Pico...ctions/td-p/710

only on Xilinx devices
наверное потому, что kcpsm3.vhd написан на встроенных компонентах типа LUT4, MUXCY
а не по злоби?

Таки по жлоби....
Вот на Xilinx форуме нашёл (http://forums.xilinx.com/xlnx/board/crawl_...;message.id=665):

Ну и цитата с "Xilinx Reference Design License"

Злоба тут не при чем)) Просто бонус для пользователей их и только их плис. Бизнес.

И по сравнению с ниос Альтеры, не плохой бонус.

32
http://opencores.org/project,zpu

The ZPU has a FreeBSD license for the HDL and GPL for the rest. This allows deployments to implement any version of the ZPU they want without running into commercial problems, but if improvements are done to the architecture as such, then they need to be contributed back.

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


В общем, как это ни банально, читайте вики http://ru.wikipedia.org/wiki/PicoBlaze

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



А Xilinx не возражает против такого клонирования?
Всётаки система команд может быть запатентована....

Это медленный стековый процессор(судя по приведенным спекам): не более 0.1 DMIPS/MHz.

ну в его доке написано:

Т.е. да он не для скоростных вычислений, но как микроконтроллер в mixed signal SoC вполне сойдёт....
Опять-же - все тулзы есть

Вот ответ Xilinx:

т.е. PacoBlase тоже только для Xilinx

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

и не забываем смотреть лицензию под которой идет PacoBlaze

То что PacoBlaze идёт под FreeBSD лицензией не означает что Вы можете его использовать где-то кроме XILINX.
Иначе - получите предъяву от XILINX.

Я не совсем понимаю как можно проконтролировать выполнение подобного ограничения (если даже оно и существует).
Исходники любого коммерческого проекта являются по умолчанию закрытыми, и никто (в том числе и Xilinx) не в праве требовать их открыть.

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

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

Лень самому писать, цитирую :-)
+1
Для того, чтобы запретить использование «совместимых по системе команд» разработанных с нуля ядер, должна быть запатнетована архитектура ядра/система команд с запретом её использования кем-либо где-либо ещё.
Если PacoBlase сделан не как модификация оригинального PicoBlase, сделан не отталкиваясь от этого проекта как от стартовой точки, а просто глядя на страничку с описанием процессора, то я не вижу повода для пресечения использования PacoBlase. А про запатентованность именно архитектуры в приведенной цитате от XILINX ни слова.

Подскажите, пожалуйста, почему как альтернативу процессору рассматривают очень большой конечный автомат? Но ведь скорее для решения сложной задачи будут использоваться много маленьких КА? Которые легко отлаживать и удобно использовать.
Мне кажется, что вопрос выбора ЦП или КА должен решаться с точки зрения быстродействия или экономии ресурсов. Грубо говоря, процессор работает медленно, но и занимает меньше места. Если же не хватает быстродействия, берем КА. Если быстродействия все еще не хватает, "разворачиваем" КА в чистую логику.
Пожалуйста, поправте если я ошибаюсь. Т.к. опыта у меня по этой теме маловато...

Не факт. Надо очень внимательно следить за тупиковыми состояниями и анализировать выход из них.
Когда одни автоматы управляют другими все это значительно усугубляется. В _этом смысле_
предпичтительнее использовать _один_ автомат.

Хотел бы добавить.
Конечные автоматы (КА) бывают с жесткой и гибкой логикой. Последние еще называют микропрограммными автоматами (МПА). Так вот, МПА занимают промежуточное положение между классическим FSM для FPGA и софт-процессорами. МПА имеют широкое слово микрокоманды, состоящее из адресной части и поля микроопераций (совместимых и несовместимых). Микрокоманды МПА можно программировать непосредственно в кодах или написать простейший кодировщик типа микроассемблер, сродни автокоду, где символы микрокоманды с помощью таблиц однозначно раскодируются в коды и вставляются по адресам в соответствующие поля микрокоманд. Там еще узел адресации и переходов, здесь просто простор для фантазий и оптимизаций…
В свое время очень широко использовал для спецвычислителей МПА, доходило до 1000 адресов со словом в 64 бит и менее, и был свой микроассемблер. Были обращения и к микро-подпрограммам, но все равно это был еще не процессор, хотя гарвардская архитектура там однозначно проглядывалась, данные и программа были разделены... Правда, все строилось на логике средней степени интеграции. В самом FPGA идею МПА пока не применял, достачно было NiosII.
Хотя, надо бы попробовать, хватило бы слова микрокоманды менее 32 бит... Это в продолжение поднятой темы... На форуме уже были сообщения о микроассемблерах и прочем для МПА…

Не нужно описывать автоматы "вручную". Средства визуального представления автоматов (например в пакете Mentor HDL Designer) известны со времен картофельного бунта...