Здравствуйте! Да, все правильно. К началу июня - просто переложить и показать первичную работоспособность алгоритма на этом железе. Далее будет время на оптимизацию и выжимание хэшрэйта.
Добрый день!
Вот этот:
https://github.com/wolf9466/cpuminer-multi
Здравствуйте!
Прошу прощения, не было возможности сразу ответить.
Постараюсь ответить всем одним сообщением.
Сроки действительно жесткие.
Сформулирую критерий первичного успеха простыми словами: в начале июня изделие должно первично заработать. Без оптимизации, с допустимыми недоработками и пр. Заказчик поедет с платой к инвестору, положит ее на стол и скажет «во чо у меня есть») Если оно при этом будет еще как-то функционировать, то вообще шикарно.
В планировании задачи изначально были допущены ошибки, плюс специфические орг.моменты – поэтому сроки остались вот такие.
В худшем случае будем переносить – головной заказчик вполне вменяемый. Но это всегда нежелательно.
В плате используются в основном схемные узлы, ранее неоднократно отработанные в других изделиях, поэтому с ее запуском больших проблем не должно возникнуть.
По деньгам все обсуждаемо, здесь не будет крохоборства. Но естественно, в разумных пределах. Есть «первый этап» - как-то запустить к июню. Далее – доработки, они тоже оплачиваются. Обычно в таких ситуациях я договариваюсь с разработчиком на примерный срок и помесячную оплату.
Готов рассматривать нескольких разработчиков (команду).
С Уважением,
Алексей
Где-то в интернете есть достоверное графическое представление алгоритма, что более наглядно, с ходу не смог найти.
На первом этапе рассматривали использование vivado hls или чего-то аналогичного.
Все сроки рассчитаны исходя из оптимистического прогноза по плате - если будут задержки из-за железа - это будет объективно восприниматься