Skip to main content

Как сделать ферму майнинга коинов на ASICах и не обанкротиться

Первый вариант заголовка: Bitmine & InnoSilicon: История об одном неудавшемся чипмейкерстве; но порывшись в сети и найдя ответное открытое письмо InnoSilicon, нельзя утверждать, что всё так однозначно в этой истории.

Жил-был такой зарегистрированный в Швейцарии стартап, звался он BITMINE AG, занимался разработкой СБИС для майнинга биткоинов и производством майнеров на базе собственной же СБИС, но что-то не задалось у этого стартапа с бизнесом и в 2015г он объявил себя банкротом (после чего против компании были поданы многочисленные иски), опубликовав на своём сайте  https://bitmine.ch/ открытое письмо и указав на основные причины этого, которые заслуживают рассмотрения на мой взгляд. Итак что же или кого же винит BITMINE в собственных неудачах?

Причины банкротства

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

Изменение стоимости биткоина и увеличение сложности добычи

 Из-за быстрого увеличения стоимости майнинга и падения стоимости BTC (2014-2015гг) более половины клиентов отменили свои заказы. Компания осознавала эти риски, но слепо верила в силу биткоина и оправдывает свой провал тем, что многие конкуренты так же обанкротились идя на поводу у общей истерии первой криптовалюты.

InnoSilicon

 Это основной пункт «оправдательного» письма. InnoSilicon — китайский дизайн-центр; подрядчик и впоследствии партнёр, который отлично подошёл на роль главного козла отпущения. Утверждается, что InnoSilicon на условиях подрядчика занималась разработкой ASIC «под ключ» по технологии 28нм (включая создание топологии, масок, изготовление чипов и корпусирование), используя ноу-хау, предоставленные BITMINE AG. Контракт подряда предусматривал эксклюзивное право Bitmine на продажу чипов А1 сроком на 1 год. Однако, со слов Bitmine, InnoSilicon начала продавать их А1 с самого начала производства на сторону, притом по отпускной цене, ниже, чем они доставались самой Bitmine, которой партии чипов были отгружены с различными задержками, вопреки контракту. Также утверждается, что поскольку большиснтво отгруженных чипов было бракованными, это заставило Bitmine заказывать дополнительные партии чтобы выполнить обязательства перед клиентами, и в итоге InnoSilicon сумело выкачать подобным образом из Bitmine в общей сумме около 8ми миллионов франков (!). Также утверждается, что китайские законы таковы, что Bitmine никогда не смог бы выиграть суд против InnoSilicon.

«Непредвиденные» инженерные сложности

 При разработке источников питания для СБИС был допущен просчёт из-за чего возникла необходимость нанять более квалифицированных инженеров и запуска дополнительных (незапланированных) итераций дизайна. Утверждается, что даже новые, более квалифицированные инженеры слишком поздно решили проблему. Вторая часть проблемы — острый дефицит и задержка поставки ключевых компонентов системы питания майнера: контроллеры DC/DC-преобразовтелей, танталовые конденсаторы, MOSFETы, из-за чего серийные изделия не вышли в срок или не вышли вовсе.

 

Взгляд глазами InnoSilicon

Innosilicon Inc в ответном открытом письме утверждает, что она является действующим и единственным обладателем прав на A1 BTC ASIC и A2 LTC ASIC. Единственными причинами неудачам Bitmine является инженерная некомпетентность и безрассудный бизнес-риск.

1. A1 ASIC вышел вовремя и работоспособным, с типовым для техпроцесса 28нм выходом годных. На момент получения Bitmine чипов А1, рынок ВТС был весьма горячим, но Bitmine не смогли в приемлемые сроки выпустить майнеры на базе чипа А1. Причиной, по которой Bitmine не смогли в срок выпустить майнеры на базе А1, является инженерная некомпетентность и ошибки в проектировании системы питания чипов и многочисленные ошибки в дизайне печатных плат,  которые требовали новых итераций и перевыпуска PCB.

2. Начиная с октября 2013 г проект А1 был продолжен на партнерских условиях, из-за неспособности Bitmine в дальнейшем финансировать проект. Тогда же были внесены поправки в контракт, позволяющие Innosilicon продавать чипы А1 на правах, равных с правами Bitmine.

3. Innosilicon единолично разработал и владеет 100% интеллектуальной собственности, использованной в чипе А1. Innosilicon — известный и уважаемый во всём мире дизайн-центр с хорошей репутацией среди заказчиков и превосходным портфолио выполненных проектов. После успеха А1 BTC, Innosilicon разработал и вывел на рынок А2 LTC, а в последствии и А4 LTC, которые быстро стали номер 1 на рынке майнинга. Bitmine — компания, состоящая из двух человек с нулевым опытом в области микроэлектроники и цифрового дизайна. Согласно контракта, любой проектный взнос компании принадлежит компании, сделавшей его. Фактический взнос Bitmine — это файлы тестовых векторов для валидации СБИС.

4. Bitmine использовал деньги своих клиентов из предзаказов, чтобы приобрести себе сторонние фермы майнинга и проводил рискованные операции с биткоинами, на чём и погорел. Реальной проблемой Bitmine являлся посредственный риск-менеджмент и отсутствующая компетенция в технических вопросах на высококонкурентном рынке. У Bitmine было достаточное окно возможности, чтобы разработать дизайн майнера на базе А1, до прихода чипа с фабрики, но они эпично профакапили эту возможность. Даже после выхода майнера на А1 от Bitmine, у него наблюдались проблемы со стабильностью работы, что подтвержлают многочисленные жалобы немногочисленных клиентов. 

Выводы для начинающих чипмейкеров

Если правдивы заявления Bitmine

1. IP: Необходимо принимать меры по защите своей интеллектуальной собственности, и я говорю не об юридических гарантиях защиты: требуется предотвратить риск и максимально снизить привлекательность использования вашего продукта без вашего ведома — на сегодня чип без документации по программированию, даташитов с режимами работы и характеристиками, информационных протоколов обмена малопривлекателен для производства в третью смену и отгрузку на сторону (а конечному пользователю, обычно, эти данные не нужны).  Концентрируйте на своей стороне контроль за работой чипа, вплоть до параноидальной встройки блока с UID (e-Fuse), который по процедуре инициализации рабочего режима аутентифицируется  вашим сервером в интернете (главное не перестараться и соблюсти tradeoff между удобством для клиента и защитой реализованных в кремнии ноу-хау).

2. Аналогичен пп.2 ниже.

Если правдивы заявления Innosilicon

1. Время — деньги: на эти грабли не наступали лишь единицы. собственными глазами был очевидцем нескольких схожих ситуаций. Типичная: торопливость в желании скорого TapeOut оборачивается тем, что сама работа начинается только по приходу чипа (тут был место правда СнК — программисты без малого 2 года возились оживляя кристалл, работая на пополнении Silicon Errata и написании драйверов), хотя идеологически и методологически должна была быть выполнена до отдачи проекта на фабрику. Или другой пример: чип пришёл раньше запланированного срока (есть такая профессия — глотатели чипов), а с ним нельзя начать работы — не готовы PCB, либо ошибки в дизайне и необходима еще одна итерация (перевыпуск) дизайна — а ведь большинство ошибок дизайна можно найти без установки чипа (нам очень повезло что мы живем в эпоху экстремальной доступности измерительного и диагностического оборудования): необходимо только изготовить и смонтировать PCB, чтобы начать отлаживать дизайн в железе (типично, самые частые ошибки как раз в системе питания СБИС). 

2. Не продешевите: войско «студентов-ардуинщиков» врядли в принципе в адекватное время и затраты материальных ресурсов решит подводные камни, которые всплывут при процедуре bring-up первых пришедших с фабрики чипов. Необходимо сразу закладывать бюджет на матерого разработчика, лучше по рекомендациям знакомых/коллег по цеху. Да и в целом в руководстве компании стояли гуманитарии менеджеры, рассудочность технических решений которых под большим вопросом, в таких глобальных по финансам проектах как чипмейкерство среди лиц принимающих решение (и/или соучредитель) должен быть как минимум один сильный технический лидер, который понимает технические риски проекта и знает что с ними делать: как на этапах планирования проекта, когда происходит разделение ролей — что оставить у себя, а что можно отдать на подряд, так и на более поздних этапах, при срабатывании триггеров рисков.

3. Риск-менеджмент: как было сказано выше, докучи необходимо учитывать еще и технические риски. Помимо этого стоит отдавать себе отчет в насколько высококонкурентной сфере вы решаете испытать удачу: промедление в выходе на рынок эквивалентно банкротству предприятия (время — деньги) и при задержке в каких-то 2 месяца ваш продукт уже может быть никому не интересен. Также стоит упомянуть, что необходимо отдавать себе отчёт в том, насколько дорогостоящее само по себе занятие чипмейкерством. Bitmine молодцы, что полностью переложили риски по разработке и изготовлению чипа на Innosilicon, а Innosilicon молодцы, что профессионалы своего дела и не облажались. Однако при желании защитить свою интеллектуальную собственность и взять на себя часть технических рисков — будьте готовы иметь соразмерную отрасли подушку безопасности чтобы изыскать возможность перевыпустить маски в случае если первый блин чип будет комом.

 

читать...

Установка и использование Icarus Verilog в линукс на примере CentOS 7

Установка iVerilog

С последним икарусом пришлось немного попотеть, как обычно бывает, в репах дистрибутива древняя как еда мамонта версия, а сборка из исходников падает из-за старого gcc, если вкратце — надо установить последний devtoolset и и зависимости в лице gperf:

 Теперь  можем собирать икарус с верилогом, особенности, после клонирования переключаемся на метку версии v10_1, при сборке передаём компиляторы опции, позволяющие оптимизировать код под инструкции конкретного процессора, на котором идёт сборка, ну и затем собираем сборку в четыре потока:

Установка просмотрщика дампа GTKwave 

 iVerilog установлен. Докучи поставим GTKwave для просмотра дампов, гененируемых iVerilog’ом, тут всё просто — ставим из репо EPEL:

Использование iVerilog

Соорудим конфиг файл, которым будем настраивать окружение CLI на запуск и работу с iverilog:

Настраиваем окружение командой (обратите внимание на пробел после точки):

Компилируем исходники (здесь и далее — куски из мейкфайла), указывая в конце командной строки список из RTL & TB:

  • -g2005-sv — указываем какой версии верилога соответствуют исходники
  •  -Irtl — перечисляем инклюд-директории
  •  -D$(DEFINE) — передаем дефайны
  • -s tb — указываем имя топ-модуля
  • -o $(PROJECT).vvp — задаём путь и имя выходного файла

Запускаем моделирование (lxt2 — рекомендованный формат записи дампа, он прогрессивный и со сжатием):

Работа с дампом

Открываем записанный дамп в GTKwave:

gtkw — это формат txt-подобного конфига для GTKwave (SaveFile в терминах GTKwave), его первичный вид можно получить открыв дамп и настроив GTKwave по своему вкусу, а потом дав команду «Write Save File» из меню.

Пример открытого дампа с преднастроенным файлом gtkw:

GOST-R34.12-2015 L-stage

 

Пример файла gtkw:

Также GTKwave поддерживает tcl-подобные скрипты, но нормальных гайдов по нему не попадалось, а жаль — думаю там более вменяемый синтаксис (памятуя о tcl-скриптах для модельсима).

читать...

[WiP] Работа с iPhone|iPad|iPod в Линукс

Подготовка

Что из пакетов есть:

Устанавливаем только необходимое:

!Если собирать из свежего среза заявлена совместимость up to iOS 10!

(далее…)

читать...

Работа со шрифтами в CentOS 7

Установка шрифтов в CentOS 7

Установка GUI-оболочки над fontconfig’ом (можно будет назначать произвольные шрифты в качестве дефолтных системных):

Установка майкрософтовских шрифтов из репо: 

Поиск нужных шрифтов в репо:

Установка сторонних шрифтов

Если  нужных шрифтов нету в репо, их можно добавить в систему сладующим образом:

1. скачать и помесить в папку ~/.fonts/:

2. дать команду на обновление (пересборку кэша) шрифтов:

или если надо, чтобы не только на текущего пользователя распространялись устанавливаемые шрифты:

Также полезной будет добавить опцию -f для того чтобы зафорсить перезачитывание каталога шрифтов.

Манипуляции с установленными шрифтами

Вывести списком все установленные шрифты:

либо только названия установленных шрифтов:

либо только имена файлов (с путями) установленных шрифтов:

либо доступные стили установленных шрифтов:

 

Можно сделать сортировку выведя только доступные шрифты с кириллическим набором символов:

либо более сложную сортировку:

 

Также полезным будет просмотр какие шрифты в системе установлены как дефолтные:

Свободные шрифты

Ниже — каталог свободных шрифтов,  которые удалось собрать по крупицам:

Font Awesome (также доступен к установке через yum): https://fortawesome.github.io/Font-Awesome/ (также доступен из репа)

 Кириллические шрифты

Отдельная радость — свободные кириллические шрифты, которые очень прижились при оформлении технической документации в корпоративном стиле. Семейство PT от Paratype — в фаворитах по сей день.

Paratype PT Sans и PT Mono: http://www.paratype.ru/public/

PT Mono Bold: http://www.fontstock.com/public/PTMono.zip

PT Astra Sans и PT Astra Serif: http://astralinux.com/fonts.html

ROSA Arion и ROSA Verde:  http://www.rosatype.ru/

Шрифт «Берёзки» с  кириллическим алфавитом: http://mishapanfilov.ru/font_beryozki.html

Бесплатные кириллические шрифты: http://russianfonts.ru/fonts/gora/goratypeface.html

Ссылки

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Desktop_Migration_and_Administration_Guide/configure-fonts.html

читать...

[CV]: Резюме эмбеддер-инженера: специфика составления и продвижения

Как и везде, резюме в зависимости от того как оно оформлено может создать дополнительные возможности либо наоборот закрыть возможности имеющиеся. Если отмести такое частое явление, как трудоустройство по рекомендации (через «цеховое братство») , то резюме — чуть ли не единственный способ заявить о себе и добиться приглашение на собеседование.

Итак, каким же должно быть «идеальное» резюме цифрового дизайнера? Ниже представлены опробованные на практике советы (из личной копилки или копилки коллег-единомышленников).

Очевидные вещи

Начну с таких неспецифичных для отрасли и очевидных вещей как то:

  • Имя кандидата должно быть написано крупно, как и должность, на которую он претендует
  • Указывайте опыт работы и работодателей в порядке от нового к старому
  • Лучший формат файла для CV — это PDF со встроенными шрифтами, иначе все ваши красивости и форматирования улетят в тар-тарары

Краткость — сестра таланта, но не в CV

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

Также не стоит пытаться замаскировать опыт и навыки, врядли потенциальный наймодатель — сертифицированный чтец между строк. Опыт и навыки — это те вещи, которые должны быть написаны явно и ясно, а не подразумеваться и вытекать из списка предыдущих наймодателей и должностей. «Обладает ли соискатель конкретными навыками и опытом?» — этот вопрос меньше всего хочет задавать себе наймодатель.

Но и перебарщивать тоже не стоит — весь непрофильный опыт должен быть выжжен калёным железом: о том, что вы в студенчестве работали разносчиком пиццы/барменом или ваши замечательные навыки работы с офисным ПО врядли будут интересны для потенциального наймодателя.

Проекты

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

  • В качестве разработчика ПЛИС реализовал:
    • СФ-блок интерфейса CAN
    • СФ-блок интерфейса LIN
  • В качестве верификатора написал комлект тестов для проверки:
    • СФ-блока UART
      • в т.ч. в режиме работы LIN-master & LIN-slave
    • СФ-блока WDT
    • а также освоил методологию UVM
  • В качестве сетевого инженера занимался:
    • Поддержанием бесперебойной работы серверной инфраструктуры
    • Администрированием хранилища git
    • Балансировкой нагрузки серверов

В начале карьеры при отсутствии опыта можно на волонтерских началах поучавствовать в опенсорцном проекте или даже организовать свой DYI-проект формата «сделай сам» (нелишним будет перечислить выполненные стадии проекта и извлеченные уроки), а еще круче — принести на собеседование объект творчества и рассказать о процессе создания. При прочих равных предпочтение в найме отдаётся самомотивированным и увлеченным кандидатам.

Помимо проектов строго обязательным является список с перечислением навыков (опять же — избегайте принуждения наймодателя читать между строк и выводить формулу ваших навыков на основе опыта работы). В этот же раздел полезно отнести навыки работы с конкретным типом измерительного оборудования, известные архитектуры процессоров/семейства ПЛИС, коммуникационные интерфейсы/протоколы, владение EDA/CAD-тулами, скриптовые и языки программирования (таки-удержался, чтобы дописать сюда же — фреймворки 😉 ).

Позиционирование

Чётко определите для себя область, в которой хотите работать и профессионально развиваться и исходя из этого подавайте себя. Не стоит писать: «по чётным дням разработчик, по нечётным — верификатор«, или «в тёплое время года готов писать драйвера устройств,  для которых разрабатывал PCB«. Дайте прежде всего сами себе честный ответ на вопрос в чём вы сильны и в чём хотите развиваться дальше — быть может это будут два разных ответа, не критично. Критично что ваше резюме должно быть пронизано духом развиваться и заниматься интересной вам сферой деятельности. Вычистите резюме от белого шума, слабо коррелирующего с этим стремлением.

Заключение

В заключении хочется дать совет, ценность которого легко недооценить: полезно обновлять резюме раз в несколько месяцев, установите себе конкретные даты в календаре, когда будете делать это; например, ежеквартально — хорошая частота для того чтобы сесть и обновить резюме новыми проектами и навыками. Редкие обновления обычно приводят к пробелам в информации или её искажению из-за забывания того, что было сделано. Помните: самое худшее время для обновления резюме — это когда Вы ищете работу. 

читать...

asciidoc: полезные дополнения

Парсер ASCII-art рисунков с сохранением в SVG

Скрипт установки asciitosvg-install.sh:

Использование:

где -s масштаб сетки в пикселях. Хорошо дополняет этот конвертер онлайн-рисовалка ASCIIART’a http://asciiflow.com

(далее…)

читать...

Коллекция советов и подсказок по работе с Xilinx Vivado в командной строке TCL

Советы

Note!: Все команды вводятся в интерпретаторе TCL в интерактивном или пакетном режимах.

Включение мультипроцессорности

можно задавать значение от 1 до 8 ядер.

Справка по командам выбранной категории

Справка по командам

Мониторинг параметров среды

Изменение подробности вывода лога/выключение лога 

 Note!: делаем осторожно — важное не выключаем!

— установка глобального лимита сообщений по умолчанию

— в данном случае полностью выключается вывод информационного сообщения с ID типа «INFO: [Synth 8-5544]«

— в данном случае вывод информационного сообщения с ID типа «INFO: [Synth 8-3331]» ограничивается выводом первых 10-ти сообщений

— для интерпретации проверки на DRC c ID «LUTLP-1» как предупреждения, вместо критического предупреждения (позволяет получить битстрим, если вы действительно уверены, что в дизайне необходимы комбинационные петли)

Выключение некоторых DRC-проверок

В некоторых ситуациях необходимо выключить определенные типы DRC-проверок, сделать это можно следующим образом:

вот мой полный список отключенных проверок:

Добавление временной метки в битстрим 

 — для добавления таймштампа в примитив USR_ACCESS 

Использование внешних переменных среды в TCL

— обращение к переменной $USER в shell

— проверка существования переменной $USER в shell

 Вызов одного скрипта из другого

Выполнение shell-команды из скрипта

— копировать с перезаписью, если файл уже существует

 

 

читать...