Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: A FPGA based Forth microprocessor |
 |
|
KPG писал(а): Может в этом варианте будет эффективнее сразу переложить выполнение части кусков кода программы, например, при возникновении прерываний на дополнительный контроллер. В самую точку! Это одна из объективных и существенных проблем сегодня. Для программиста вообще очень неудобно, что в критическом куске кода может внезапно возникнуть прерывание. Запретить - может возникнуть проблема с периферией, которую не обработают. А уж понятие "шторм прерываний" попросту показывает, что проблема получила собственное название. Добавление независимых процессоров для работы с такими критичными кусками кода, или же просто для облегчения работы программиста - вполне перспективное направление. Если работа с собственным процессором не воспринимается как что-то запредельно сложное, жизнь внезапно облегчается. Программисту не нужно думать, хватит ли ему производительности. Ему не нужно думать, не нарушит ли добавляемый в основной цикл вызов функции нормальную работу предыдущих кусков проекта. Ему не нужно думать, что делать, когда прерывания перекрываются (а также как это проверить и хотя бы воспроизвести для тестирования). Вобщем, сплошные плюсы  Из минусов цена.... но это цена одного компонента, и важно это будет разве что для пресловутого массового производства, до которого еще нужно добраться. А на сегодня +10-20 $ к спецификации далеко не всегда непреодолимая проблема. Тем более если это ускоряет выпуск нормально работающего изделия. Кстати, kf732 был разработан именно с целью влезть в ПЛИС подешевле. Там-то как раз была серия.
[quote="KPG"] Может в этом варианте будет эффективнее сразу переложить выполнение части кусков кода программы, например, при возникновении прерываний на дополнительный контроллер.[/quote] В самую точку! Это одна из объективных и существенных проблем сегодня. Для программиста вообще очень неудобно, что в критическом куске кода может внезапно возникнуть прерывание. Запретить - может возникнуть проблема с периферией, которую не обработают. А уж понятие "шторм прерываний" попросту показывает, что проблема получила собственное название.
Добавление независимых процессоров для работы с такими критичными кусками кода, или же просто для облегчения работы программиста - вполне перспективное направление. Если работа с собственным процессором не воспринимается как что-то запредельно сложное, жизнь внезапно облегчается. Программисту не нужно думать, хватит ли ему производительности. Ему не нужно думать, не нарушит ли добавляемый в основной цикл вызов функции нормальную работу предыдущих кусков проекта. Ему не нужно думать, что делать, когда прерывания перекрываются (а также как это проверить и хотя бы воспроизвести для тестирования). Вобщем, сплошные плюсы :) Из минусов цена.... но это цена одного компонента, и важно это будет разве что для пресловутого массового производства, до которого еще нужно добраться. А на сегодня +10-20 $ к спецификации далеко не всегда непреодолимая проблема. Тем более если это ускоряет выпуск нормально работающего изделия.
Кстати, kf732 был разработан именно с целью влезть в ПЛИС подешевле. Там-то как раз была серия.
|
|
|
 |
Добавлено: Чт дек 10, 2020 23:25 |
|
|
 |
|
|
Заголовок сообщения: |
Re: A FPGA based Forth microprocessor |
 |
|
Hishnik писал(а): В принципе мысль технически реализуема, но вопросы начнутся потом.. Спасибо за развёрнутый ответ. Думаю да, если не попробовать такой вариант сделать или смоделировать, то нет полной ясности. К, тому же, например у части контроллеров есть интерфейс к памяти расширения поддержанный аппаратно и он быстрее чем IO через порты. P.S. Может в этом варианте будет эффективнее сразу переложить выполнение части кусков кода программы, например, при возникновении прерываний на дополнительный контроллер. Кстати, интересно, что на AVR в ассемблере есть реализованные проекты микропроцессора 6502. 
[quote="Hishnik"]В принципе мысль технически реализуема, но вопросы начнутся потом..[/quote] Спасибо за развёрнутый ответ. Думаю да, если не попробовать такой вариант сделать или смоделировать, то нет полной ясности. К, тому же, например у части контроллеров есть интерфейс к памяти расширения поддержанный аппаратно и он быстрее чем IO через порты. P.S. Может в этом варианте будет эффективнее сразу переложить выполнение части кусков кода программы, например, при возникновении прерываний на дополнительный контроллер.
Кстати, интересно, что на AVR в ассемблере есть реализованные проекты микропроцессора 6502. :)
|
|
|
 |
Добавлено: Чт дек 10, 2020 22:53 |
|
|
 |
|
|
Заголовок сообщения: |
Re: A FPGA based Forth microprocessor |
 |
|
KPG писал(а): Знаю, что, например на микроконтроллере делали в одном проекте микросхему памяти, но в подобном применении можно сделать FIFO/LIFO а также возможно и возможность выполнения стековой арифметики или сразу или по мере необходимости (как то, наверное, можно и этим управлять - как быстро нужен, если нужен результат стековой арифметики следующим тактом или позже) какой нибудь и AVR может для этого сгодится. (часть стэка разместить в регистрах микроконтроллера) В принципе мысль технически реализуема, но вопросы начнутся потом. Сама по себе связка МК+ПЛИС очень хороша и жизнеспособна. Эти микросхемы друг друга хорошо дополняют, потому что в МК обычно больше периферии, ну и стартовать проще именно оттуда, а в ПЛИС реализовать как раз недостающее по цифровой части. Это обычно или параллельное DSP, или коммутатор цифровой периферии, или какая-то схема, которой нет в МК - вот как раз вариант со стеком. Связать можно довольно просто через GPIO у МК. Да, он получит стек данных и команды по вкусу. Первое наблюдение будет состоять в том, что постоянный обмен со стеком через порты МК будет медленным. В ПЛИС-то он будет быстрым, а вот МК придется постоянно забрасывать числа на стек, инициировать команды и забирать данные. Да, оно будет выполнять стековые операции за один такт внутри ПЛИС, но вот сколько тактов понадобится на обмен? Второе - такое ускорение стека, возможно, будет и быстрее, чем эмуляция стека в МК. Но будет ли она быстрее, чем просто программа для МК, написанная с учетом его архитектуры? Это уже очень неоднозначный вопрос. Скорее всего, нет - код на Си/ассемблере будет быстрее, чем код на Форте в связке МК+ускоритель стека. Для форт-процессоров в ПЛИС смысл в основном в том, что они имеют компактный код. С учетом дефицита памяти на кристалле ПЛИС (сколько бы ни было, всегда не хватает, потому что от большой ПЛИС хочется и решения более серьезных задач). Сравнение с "официальными" софт-процессорами, конечно же, проводилось. Для реальных проектов упрямство не прокатывает  Но оказалось, что аналогичный по функциям код имеет размер в 2-3 раза больше, если создается с помощью gcc. Это еще данные для kf332, у которого команда 18-битная. А уж kf532 делает такие вещи, что страшно с ARM-подобными ядрами сравнивать. Второй важный момент - тесное сопряжение с периферией. 1 0 OUTPORT на форт-процессоре - это 3 такта. Если литералы получаются больше, то больше. Но многие МК на такой обмен с устройствами на шине тратят гораздо больше. Плюс добавляются игры с кэшем (если есть), прерываниями и прочими радостями... и получается, что очень удобно работать с каким-то собственным ядром, которое занимается одним процессом в системе, а на другие процессы при необходимости ставятся другие ядра. К примеру, kf732 - это прямой ответ на такую потребность, у него 8 аппаратных потоков, запускаемых по очереди (в произвольном порядке). Так что в целом, форт-процессоры - это не про "очень быстро". Это скорее "очень удобно по совокупности свойств и маршруту разработки".
[quote="KPG"]Знаю, что, например на микроконтроллере делали в одном проекте микросхему памяти, но в подобном применении можно сделать FIFO/LIFO а также возможно и возможность выполнения стековой арифметики или сразу или по мере необходимости (как то, наверное, можно и этим управлять - как быстро нужен, если нужен результат стековой арифметики следующим тактом или позже) какой нибудь и AVR может для этого сгодится. (часть стэка разместить в регистрах микроконтроллера)[/quote] В принципе мысль технически реализуема, но вопросы начнутся потом.
Сама по себе связка МК+ПЛИС очень хороша и жизнеспособна. Эти микросхемы друг друга хорошо дополняют, потому что в МК обычно больше периферии, ну и стартовать проще именно оттуда, а в ПЛИС реализовать как раз недостающее по цифровой части. Это обычно или параллельное DSP, или коммутатор цифровой периферии, или какая-то схема, которой нет в МК - вот как раз вариант со стеком. Связать можно довольно просто через GPIO у МК. Да, он получит стек данных и команды по вкусу.
Первое наблюдение будет состоять в том, что постоянный обмен со стеком через порты МК будет медленным. В ПЛИС-то он будет быстрым, а вот МК придется постоянно забрасывать числа на стек, инициировать команды и забирать данные. Да, оно будет выполнять стековые операции за один такт[b] внутри ПЛИС[/b], но вот сколько тактов понадобится на обмен? Второе - такое ускорение стека, возможно, будет и быстрее, чем эмуляция стека в МК. Но будет ли она быстрее, чем просто программа для МК, написанная с учетом его архитектуры? Это уже очень неоднозначный вопрос. Скорее всего, нет - код на Си/ассемблере будет быстрее, чем код на Форте в связке МК+ускоритель стека.
Для форт-процессоров в ПЛИС смысл в основном в том, что они имеют компактный код. С учетом дефицита памяти на кристалле ПЛИС (сколько бы ни было, всегда не хватает, потому что от большой ПЛИС хочется и решения более серьезных задач). Сравнение с "официальными" софт-процессорами, конечно же, проводилось. Для реальных проектов упрямство не прокатывает :) Но оказалось, что аналогичный по функциям код имеет размер в 2-3 раза больше, если создается с помощью gcc. Это еще данные для kf332, у которого команда 18-битная. А уж kf532 делает такие вещи, что страшно с ARM-подобными ядрами сравнивать.
Второй важный момент - тесное сопряжение с периферией. 1 0 OUTPORT на форт-процессоре - это 3 такта. Если литералы получаются больше, то больше. Но многие МК на такой обмен с устройствами на шине тратят гораздо больше. Плюс добавляются игры с кэшем (если есть), прерываниями и прочими радостями... и получается, что очень удобно работать с каким-то собственным ядром, которое занимается одним процессом в системе, а на другие процессы при необходимости ставятся другие ядра. К примеру, kf732 - это прямой ответ на такую потребность, у него 8 аппаратных потоков, запускаемых по очереди (в произвольном порядке).
Так что в целом, форт-процессоры - это не про "очень быстро". Это скорее "очень удобно по совокупности свойств и маршруту разработки".
|
|
|
 |
Добавлено: Чт дек 10, 2020 22:24 |
|
|
 |
|
|
Заголовок сообщения: |
Re: A FPGA based Forth microprocessor |
 |
|
Появилась такая мысль. Знаю, что, например на микроконтроллере делали в одном проекте микросхему памяти, но в подобном применении можно сделать FIFO/LIFO а также возможно и возможность выполнения стековой арифметики или сразу или по мере необходимости (как то, наверное, можно и этим управлять - как быстро нужен, если нужен результат стековой арифметики следующим тактом или позже) какой нибудь и AVR может для этого сгодится. (часть стэка разместить в регистрах микроконтроллера) А, если вместо МК использовать FPGA для подобной идеи например в дополнении такой памяти к МК общего применеия через управление по портам, то получится ли регистровый МК общего применения сделать более эффективным к выполнению поддержки Форт кода? P.S. Насколько жизнеспособна такая идея? (типа дополнительная микросхема к МК, как небольшой стековый "сопроцессор" управляемый из вне) Выпускаются или выпускались, конечно, микросхемы памяти LIFO/FIFO https://www.digchip.com/datasheets/part ... 0P-pdf.php(M66250P, M66252P может и ещё есть, но они только для организации стэковой памяти)
Появилась такая мысль.
Знаю, что, например на микроконтроллере делали в одном проекте микросхему памяти, но в подобном применении можно сделать FIFO/LIFO а также возможно и возможность выполнения стековой арифметики или сразу или по мере необходимости (как то, наверное, можно и этим управлять - как быстро нужен, если нужен результат стековой арифметики следующим тактом или позже) какой нибудь и AVR может для этого сгодится. (часть стэка разместить в регистрах микроконтроллера)
А, если вместо МК использовать FPGA для подобной идеи например в дополнении такой памяти к МК общего применеия через управление по портам, то получится ли регистровый МК общего применения сделать более эффективным к выполнению поддержки Форт кода?
P.S. Насколько жизнеспособна такая идея? (типа дополнительная микросхема к МК, как небольшой стековый "сопроцессор" управляемый из вне) Выпускаются или выпускались, конечно, микросхемы памяти LIFO/FIFO https://www.digchip.com/datasheets/parts/datasheet/305/M66250P-pdf.php (M66250P, M66252P может и ещё есть, но они только для организации стэковой памяти)
|
|
|
 |
Добавлено: Чт дек 10, 2020 21:42 |
|
|
 |
|
|
Заголовок сообщения: |
Re: A FPGA based Forth microprocessor |
 |
|
KPG писал(а): А, были ли какие то замеры улучшения характеристик Форт ядер от версии к версии.
Примерно вот так. Размер в ресурсах ПЛИС зависит от параметризации.
Вложения: |

ForthCPU.png [ 40.91 Кб | Просмотров: 1567 ]
|
[quote="KPG"]А, были ли какие то замеры улучшения характеристик Форт ядер от версии к версии. [/quote] Примерно вот так. Размер в ресурсах ПЛИС зависит от параметризации.
|
|
|
 |
Добавлено: Ср дек 09, 2020 23:22 |
|
|
 |
|
|
Заголовок сообщения: |
Re: A FPGA based Forth microprocessor |
 |
|
Hishnik писал(а): 2012 года. Оно уже устарело окончательно, даже kf532 редко применяем. А, были ли какие то замеры улучшения характеристик Форт ядер от версии к версии.
[quote="Hishnik"]2012 года. Оно уже устарело окончательно, даже kf532 редко применяем.[/quote] А, были ли какие то замеры улучшения характеристик Форт ядер от версии к версии.
|
|
|
 |
Добавлено: Ср дек 09, 2020 22:07 |
|
|
 |
|
|
Заголовок сообщения: |
Re: A FPGA based Forth microprocessor |
 |
|
2012 года. Оно уже устарело окончательно, даже kf532 редко применяем.
2012 года. Оно уже устарело окончательно, даже kf532 редко применяем.
|
|
|
 |
Добавлено: Чт ноя 26, 2020 00:08 |
|
|
 |
|
|
Заголовок сообщения: |
Re: A FPGA based Forth microprocessor |
 |
|
KF 332 - конфигурируемое процессорное ядро https://msyst.ru/index.php/activities/forth/114-kf-3xxP.S. Картинки на странице пропали.  и нет обновления новостей.
KF 332 - конфигурируемое процессорное ядро
https://msyst.ru/index.php/activities/forth/114-kf-3xx
P.S. Картинки на странице пропали. :) и нет обновления новостей.
|
|
|
 |
Добавлено: Ср ноя 25, 2020 13:33 |
|
|
 |
|
|
Заголовок сообщения: |
Re: A FPGA based Forth microprocessor |
 |
|
|
|
 |
Добавлено: Вс ноя 15, 2020 14:00 |
|
|
 |
|
|
Заголовок сообщения: |
Re: A FPGA based Forth microprocessor |
 |
|
KPG писал(а): Eщё один Форт-процессор оригинального дизайна на Github. 1. 16 бит, low-end. В современные low-end лезет и 32, и 64. Внутри полно команд для двойной длины. Отсюда вопрос - а зачем было сразу себя ограничивать? 2. Понятия "назначение", "целевые задачи" опять проигнорированы. Получилось упражнение по расстановке полей команды. 3. "Верификация еще не начиналась"  То есть оно еще, возможно, и не работает? 
[quote="KPG"]Eщё один Форт-процессор оригинального дизайна на Github.[/quote] 1. 16 бит, low-end. В современные low-end лезет и 32, и 64. Внутри полно команд для двойной длины. Отсюда вопрос - а зачем было сразу себя ограничивать? 2. Понятия "назначение", "целевые задачи" опять проигнорированы. Получилось упражнение по расстановке полей команды. 3. "Верификация еще не начиналась" :) То есть оно еще, возможно, и не работает? :)
|
|
|
 |
Добавлено: Пт июл 24, 2020 10:21 |
|
|
 |
|
|
Заголовок сообщения: |
Re: A FPGA based Forth microprocessor |
 |
|
Eщё один Форт-процессор оригинального дизайна на Github. N1 on Github ( N1_manual.pdf) P.S. Нашёлся при поисковом запросе Forth Cpu.
Eщё один Форт-процессор оригинального дизайна на Github. [url=https://github.com/hotwolf/N1]N1 on Github[/url] ([url=https://github.com/hotwolf/N1/blob/master/doc/N1_manual.pdf]N1_manual.pdf[/url])
P.S. Нашёлся при поисковом запросе Forth Cpu.
|
|
|
 |
Добавлено: Пт июл 24, 2020 09:28 |
|
|
 |
|
|
Заголовок сообщения: |
Re: A FPGA based Forth microprocessor |
 |
|
Spartan-3A. Снят с производства. Ячейки другие, непрограммируемые ресурсы другие. Под современные FPGA надо корректировать.
Spartan-3A. Снят с производства. Ячейки другие, непрограммируемые ресурсы другие. Под современные FPGA надо корректировать.
|
|
|
 |
Добавлено: Пн фев 25, 2019 19:36 |
|
|
 |
|
|
Заголовок сообщения: |
Re: A FPGA based Forth microprocessor |
 |
|
FORTH processor with Java compiler MyForthProcessor (Download репозитория порядка 200Мб)
FORTH processor with Java compiler [url=https://github.com/freecores/myforthprocessor]MyForthProcessor[/url] (Download репозитория порядка 200Мб)
|
|
|
 |
Добавлено: Пн фев 25, 2019 12:25 |
|
|
 |
|
|
Заголовок сообщения: |
Re: A FPGA based Forth microprocessor |
 |
|
KPG писал(а): Насколько формат подобной упаковки процессорных Форт команд позволяет проводить локальные действия по ускорению кода? Однозначного ответа тут нет. Формат команды тесно связан с микроархитектурой процессора. Можно ведь такого накрутить, что схема станет медленнее просто из-за необходимости разобраться в сложной команде с разной ролью одних и тех же битов в разных случаях.
[quote="KPG"]Насколько формат подобной упаковки процессорных Форт команд позволяет проводить локальные действия по ускорению кода?[/quote] Однозначного ответа тут нет. Формат команды тесно связан с микроархитектурой процессора. Можно ведь такого накрутить, что схема станет медленнее просто из-за необходимости разобраться в сложной команде с разной ролью одних и тех же битов в разных случаях.
|
|
|
 |
Добавлено: Вс июн 24, 2018 21:22 |
|
|
 |
|
|
Заголовок сообщения: |
Re: A FPGA based Forth microprocessor |
 |
|
QUARK QUARK is a simple dual-stack CPU instruction set architecture (ISA) that can be extended. QUARK uses Head-and-tail instruction format, described in Hedi01.pdfНасколько формат подобной упаковки процессорных Форт команд позволяет проводить локальные действия по ускорению кода?
[url=https://github.com/drom/quark]QUARK[/url]
QUARK is a simple dual-stack CPU instruction set architecture (ISA) that can be extended. QUARK uses Head-and-tail instruction format, described in [url=http://www.cs.berkeley.edu/%7Ekrste/papers/hat-cases2001.pdf]Hedi01.pdf[/url]
Насколько формат подобной упаковки процессорных Форт команд позволяет проводить локальные действия по ускорению кода?
|
|
|
 |
Добавлено: Вс июн 24, 2018 14:36 |
|
|
 |
|