Честно говоря я не очень верил в эти ИИ до недавнего времени. Пока не попробовал попросить github Copilot сделать мне тестбенч к модулю, ну чисто для эксперимента. Очень впечатляет. Даже написал про это статью
А вот яндексовый sourcecraft.dev с этой же задачей не справился, как я его не просил.
Правда на другой задаче (создать на логике быстрый умножитель) и у яндекса получилось вполне хорошо. Плюсом sourcecraft.dev что он сразу создает репозиторию для запроса и все правки туда идут, видно как проект меняется от запроса к запросу:
Самая главная фищка PicoRV32, как мне кажется в его примерах с использованием внешней последовательной флеш памяти для программ. Здесь то я поставил 32К статической памяти для теста, но picorv32 не для этого делался. Я думаю производитель подразумевал ему поставить условно говоря 1К памяти, как scratchpad над памятью внешнего флэш чипа. И тогда память программы может быть очень большой и разработчик почти не ограничен её размером.
Попробовал сейчас закомментировать `define SCR1_DBG_EN и кажется размер не сильно уменьшился на 31 логический элемент и 4 регистра? Что-то странное. Может я где-то что-то не так делаю.
Но есть еще один момент, который меня смущает. В конфигурации EC / MIN посчитано CyclesPerInstruction 1,540, а в конфигурации IM / MAX посчитано CyclesPerInstruction 1,742 Кажется какая-то ерунда, что MAX даже медленнее и тратит больше циклов на инструкцию? При этом конфигурация MAX явно выигрывает бенчмарк.
Я для себя объясняю это тем, что в конфигурации MIN исполняется больше простых инструкций и в целом программа видимо длиннее. А в конфигурации MAX программа короче, но появляются более сложные инструкции требующие более одного такта.
То можно посмотреть сколько же инструкций выполнялось за тест.
В моем случае я вижу:
EC/MIN: 152525
IM/MAX: 130033
То есть да, для IM компилятор создает код который при исполнении получился короче. Но инструкции видимо появились и более сложные требующие больше одного такта.
При этом вторая странность - в конфигурации MAX сегмент .text при всём при этом оказывается большего размера.
Для ядра SCR1 в конфигурации SCR1_CFG_RV32IMC_MAX так же определяется `define SCR1_FAST_MUL
Но не могу с уверенностью сказать что эти определения дадут одно-тактный или двух-тактный умножитель. При желании можно это выяснить рассматривая waveforms или внимательно смотреть исходники.
Там у процессора были только аккумулятор и регистры X и Y. Остальное все в памяти, все переменные. У меня координаты мяча были в двух байтах и экран текстовый.
Пока мяч летит вперед выполняем команду inc [ptr] а чтобы лететь назад меняем эту команду на dec [ptr]. Как-то так.
Да, конечно, дом не обогреть одним компьютером однозначно. А комнату обогреть можно.
Так странность момента заключатся в том, что тепловентиляторы как изделие и продаются и покупаются населением. В то же самое время они уже есть дома в виде доп. функции компьютера. При этом использование железного асика как в примере этой статьи я считаю весьма трудным - с него трудно забрать тепло в том виде как делает это автор. Слишком сложная техническая задача.
К слову конкретно Монеро не майнится на видеокартах, майнится на CPU.
Но да, не нагружайте уж сильно сильно. Цель же не заработать, а обогреть? Заработать и обогреть это так-то разные цели. Если майнить на 90% мощности, то по температуре процессора это будет его штатный режим, а добываемое тепло получится практически "бесплатным".
PS: к слову сказать я не являюсь как бы это сказать ярым энтузиастом криптовалют и майнинга в целом. Считаю, что человечество могло бы эту энергию применить с гораздо большей пользой. Но тут такое дело - в жизни вообще довольно мало рационального. К примеру, человечество тратит уйму ресурсов на распри и войны. А могло бы тратить эти ресурсы на поиск новых лекарств или на борьбу с нищетой в Африке. Ну вот на этом фоне обогрев майнингом эта частичка безумия доступная простому обывателю. Если весь мир сумасшедший и это не исправить, то почему бы и нам не стать его частью.
Это если он у вас уже оказался купленным по каким-то причинам. Например вы купили его поиграть. Когда играете он и так греет, а когда не играете можете включить на обогрев путем майнинга.
Уголь как привезут сперва нужно в сарай перенести, это два три дня тяжелой работы. В процессе переноса окажется, что часть угля слишком мелкая - пыль, а другая часть слишком крупные куски. Брали кувалду дробили. Каждый день золу из печи выгребать, печь растапливать. Помню.
За отопление тепловым насосом тоже надо платить, хоть его использование выгоднее чем просто эл нагреватель. А обогрев майнингом практически бесплатный (если не считать стоимость оборудования).
ИИ он такой.
Честно говоря я не очень верил в эти ИИ до недавнего времени. Пока не попробовал попросить github Copilot сделать мне тестбенч к модулю, ну чисто для эксперимента. Очень впечатляет. Даже написал про это статью
https://marsohod.org/459-github-copilot-for-fpga
А вот яндексовый sourcecraft.dev с этой же задачей не справился, как я его не просил.
Правда на другой задаче (создать на логике быстрый умножитель) и у яндекса получилось вполне хорошо. Плюсом sourcecraft.dev что он сразу создает репозиторию для запроса и все правки туда идут, видно как проект меняется от запроса к запросу:
https://sourcecraft.dev/organization-marsohod-org/fast-8-bit-multiplier-verilog
Я не очень понимаю, как они это делают, ведь Verilog не очень популярный язык, как они могли ИИ натренировать?
В общем да.
На самом деле мы у себя в проекте используем SCR1 больше из-за JTAG gdb отладчика. Ну а picorv32 он популярность получает из-за отладочных плат Gowin.
Самая главная фищка PicoRV32, как мне кажется в его примерах с использованием внешней последовательной флеш памяти для программ. Здесь то я поставил 32К статической памяти для теста, но picorv32 не для этого делался. Я думаю производитель подразумевал ему поставить условно говоря 1К памяти, как scratchpad над памятью внешнего флэш чипа. И тогда память программы может быть очень большой и разработчик почти не ограничен её размером.
Попробовал сейчас закомментировать `define SCR1_DBG_EN и кажется размер не сильно уменьшился на 31 логический элемент и 4 регистра? Что-то странное. Может я где-то что-то не так делаю.
Наверное вы правы.
Но есть еще один момент, который меня смущает. В конфигурации EC / MIN посчитано CyclesPerInstruction 1,540, а в конфигурации IM / MAX посчитано CyclesPerInstruction 1,742 Кажется какая-то ерунда, что MAX даже медленнее и тратит больше циклов на инструкцию? При этом конфигурация MAX явно выигрывает бенчмарк.
Я для себя объясняю это тем, что в конфигурации MIN исполняется больше простых инструкций и в целом программа видимо длиннее. А в конфигурации MAX программа короче, но появляются более сложные инструкции требующие более одного такта.
Если добавить в dhry_1.c строку
User_Insn = End_Insn - Begin_Insn; sc_printf(“Insn begin: %ld end: %ld Num %ld\n”, Begin_Insn, End_Insn, User_Insn);То можно посмотреть сколько же инструкций выполнялось за тест.
В моем случае я вижу:
EC/MIN: 152525
IM/MAX: 130033
То есть да, для IM компилятор создает код который при исполнении получился короче. Но инструкции видимо появились и более сложные требующие больше одного такта.
При этом вторая странность - в конфигурации MAX сегмент .text при всём при этом оказывается большего размера.
Есть над чем задуматься.
Для ядра picorv32 я поставил параметры
localparam ENABLEMUL = 1;
localparam ENABLEFAST_MUL = 1;
Для ядра SCR1 в конфигурации SCR1_CFG_RV32IMC_MAX так же определяется
`define SCR1_FAST_MUL
Но не могу с уверенностью сказать что эти определения дадут одно-тактный или двух-тактный умножитель. При желании можно это выяснить рассматривая waveforms или внимательно смотреть исходники.
Нужен
Мне кажется, что сделали странный вывод.
30 лет назад на асме почти все так делали.
Помню писал игру теннис на Правец 8а
Там у процессора были только аккумулятор и регистры X и Y. Остальное все в памяти, все переменные. У меня координаты мяча были в двух байтах и экран текстовый.
Пока мяч летит вперед выполняем команду inc [ptr] а чтобы лететь назад меняем эту команду на dec [ptr]. Как-то так.
Это как раз туда Майкрософт и идет семимильными шагами - в облака.
Не знаю, какой чип использует автор, но я бы для такого проекта брал китайскую FPGA Gowin. Типа такого, как в плате Tang-Nano или Марсоход3GW2.
В чипе уже есть встроенная память PSRAM 8 мегабайт.
Да и HDMI вполне работает на таком чипе при невысоких разрешениях типа 1280x720.
И процессор picoRV (RISC-V) тут еже работает.
Формально вы правы.
Но в этой статье по существу исследуется только одна функция
sha256_transform()Для вычисления полного хэша надо в конце еще делать вызов функции sha256_final()Спасибо!
Сейчас для работы мини-дрону требуется достаточно сильное магнитное поле от электромагнитной катушки.
По видимому нужно не просто магнитное поле, но вращающееся магнитное поле. А иначе как заставить вращаться лопасти этого робота?
Смотря какая комната. Мою комнату в 15квадратов 350 ватт вполне согревают.
Да, конечно, дом не обогреть одним компьютером однозначно. А комнату обогреть можно.
Так странность момента заключатся в том, что тепловентиляторы как изделие и продаются и покупаются населением. В то же самое время они уже есть дома в виде доп. функции компьютера. При этом использование железного асика как в примере этой статьи я считаю весьма трудным - с него трудно забрать тепло в том виде как делает это автор. Слишком сложная техническая задача.
К слову конкретно Монеро не майнится на видеокартах, майнится на CPU.
Но да, не нагружайте уж сильно сильно. Цель же не заработать, а обогреть? Заработать и обогреть это так-то разные цели. Если майнить на 90% мощности, то по температуре процессора это будет его штатный режим, а добываемое тепло получится практически "бесплатным".
PS: к слову сказать я не являюсь как бы это сказать ярым энтузиастом криптовалют и майнинга в целом. Считаю, что человечество могло бы эту энергию применить с гораздо большей пользой. Но тут такое дело - в жизни вообще довольно мало рационального. К примеру, человечество тратит уйму ресурсов на распри и войны. А могло бы тратить эти ресурсы на поиск новых лекарств или на борьбу с нищетой в Африке. Ну вот на этом фоне обогрев майнингом эта частичка безумия доступная простому обывателю. Если весь мир сумасшедший и это не исправить, то почему бы и нам не стать его частью.
Это если он у вас уже оказался купленным по каким-то причинам. Например вы купили его поиграть. Когда играете он и так греет, а когда не играете можете включить на обогрев путем майнинга.
С детства помню угольное отопление.
Уголь как привезут сперва нужно в сарай перенести, это два три дня тяжелой работы. В процессе переноса окажется, что часть угля слишком мелкая - пыль, а другая часть слишком крупные куски. Брали кувалду дробили. Каждый день золу из печи выгребать, печь растапливать. Помню.
За отопление тепловым насосом тоже надо платить, хоть его использование выгоднее чем просто эл нагреватель. А обогрев майнингом практически бесплатный (если не считать стоимость оборудования).