CPU или конечный автомат, что лучше Опции

[anatolich]

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

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

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

Что лучше?

[Bad0512]

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

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

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

Что лучше?

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

[iosifk]

А в чём собственно разница между CPU и FSM?
.... Но это не избавит вас от процесса отладки.

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

[Bad0512]

Как я уже писал в статьях есть небольшая разница. Процессор отлаживается "как железо" только один раз. И потом, при модификации программ он, "как железо" всегда работает...

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

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

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

Мне было легче сделать программный симулятор и ассемблер, чем заниматься отладкой автомата в пару сотен состояний...
И, кстати, если делать свой простенький процессор, то его система команд выбирается так, что таких команд надо в 2-4 раза меньше, чем у стандартного...

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

Читайте, все об этом написано...
удачи!

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

[iosifk]

А вот тут чушь полную пишите....

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

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

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