[Leka 0]

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

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

 

 

[topor_topor 0]

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

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

1-10 DMIPS depending configuration and memory subsystem.

The ZPU is for light administrative tasks.

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

Опять-же - все тулзы есть

[topor_topor 0]

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

Вот ответ Xilinx:

Note that ‘clones’ of PicoBlaze are often made by users that want to modify the original PicoBlaze or use it in a different design flow BUT STILL TO TARGET A XILINX DEVICE. The Reference Design License Agreement covers this use....

"The success of any designs you complete using the Designs as a starting point is wholly dependent on your design efforts."

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

 

[des00 25]

Вот ответ Xilinx:

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

 

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

[topor_topor 0]

переведите на русский ...

Учтите, что клоны PicoBlaze сделаны пользователями которые хотят модифицировать исходный PicoBlaze НО ВСЁ ЕСЧЁ С ЦЕЛЬЮ ИСПОЛЬЗОВАНИЯ В XILINX.

Лицензионное соглашение включает этот случай....

 

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

Иначе - получите предъяву от XILINX.

 

[Bad0512 2]

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

Иначе - получите предъяву от XILINX.

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

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

 

[alexadmin 0]

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

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

 

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

[Bad0512 2]

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

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

Презумпцию невиновности ещё никто не отменял.

 

[ReAl 0]

Вот ответ Xilinx:

Note that ‘clones’ of PicoBlaze are often made by users that want to modify the original PicoBlaze or use it in a different design flow BUT STILL TO TARGET A XILINX DEVICE. The Reference Design License Agreement covers this use....

"The success of any designs you complete using the Designs as a starting point is wholly dependent on your design efforts."

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

Лень самому писать, цитирую :-)

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

+1

Для того, чтобы запретить использование «совместимых по системе команд» разработанных с нуля ядер, должна быть запатнетована архитектура ядра/система команд с запретом её использования кем-либо где-либо ещё.

Если PacoBlase сделан не как модификация оригинального PicoBlase, сделан не отталкиваясь от этого проекта как от стартовой точки, а просто глядя на страничку с описанием процессора, то я не вижу повода для пресечения использования PacoBlase. А про запатентованность именно архитектуры в приведенной цитате от XILINX ни слова.

[SpyBot 0]

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

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

Пожалуйста, поправте если я ошибаюсь. Т.к. опыта у меня по этой теме маловато...

 

[LV26 0]

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

 

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

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

предпичтительнее использовать _один_ автомат.

[Serhiy_UA 1]

Хотел бы добавить.

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

В свое время очень широко использовал для спецвычислителей МПА, доходило до 1000 адресов со словом в 64 бит и менее, и был свой микроассемблер. Были обращения и к микро-подпрограммам, но все равно это был еще не процессор, хотя гарвардская архитектура там однозначно проглядывалась, данные и программа были разделены... Правда, все строилось на логике средней степени интеграции. В самом FPGA идею МПА пока не применял, достачно было NiosII.

Хотя, надо бы попробовать, хватило бы слова микрокоманды менее 32 бит... Это в продолжение поднятой темы... На форуме уже были сообщения о микроассемблерах и прочем для МПА…

[Джеймс 3]

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

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