MAX10ボードできた [FPGA]

前回のエントリで発注したMAX10基板(SODALITE)ができあがってきたので早速実装してテスト。
DSC_0333.JPG

小型の基板で、かつ両サイドに貫通部品の穴が開いてるので、マスキングテープでケント紙に固定してハンダ付け。
DSC_0334.JPG

実装完了。
DSC_0335.JPG

サイズはこんな感じで実にコンパクト。
DSC_0340.JPG

MILピッチコネクタで外部にI/Oを引きだしているので、ユニバーサル基板で組めます。
DSC_0341_1.JPG

早速HDMIで表示させてみた。
MAX10 evalボードではテストしてなかった720p解像度(1レーン742.5Mbps)を出してみたところ。シリアライザは372MHzで動作している。CycloneIV EのC8グレードではこのスピードをLVDSで作ると弾かれるんだけども、MAX10のC8グレードは問題ないようだ。
DSC_0342.JPG

こないだあれだけ苦労したSDRAMも何ら問題無く動作して、これでようやく1ヶ月前の評価をし直せる状態に戻った。これから消費電力とか温度特性とか調べていきます。

教訓:新しいデバイスやメモリバスは信頼できるボードを先に買え

MAX10デバイスを使ってみていろいろ分かってきたことは次回のエントリで
 → MAX10デバイスを使う場合の注意まとめ(その1)

新MAX10ボード製作中 [FPGA]

MAX10_evalボードの限界が見えてしまったので(特にSDRAM接続まわりで)、新ボードを起こすことにした。
似たようなコンセプトのボードがマクニカから出ることは知っていたので、こちらはまぁテスト用にぐらいの気持ちでいたら、SDRAMが載ってないことがわかり、手持ちのリソースでなんとかしないといけない羽目に。

そんなわけで、久々の鉱物シリーズ基板(コードネームが鉱物の基板)を企画。
sodalite_pcb.png

主な特徴は
  • 1100mil幅40ピンDIP基板(基板サイズ53.4mm×30.5mm)
  • 10M08SAE144C8N搭載
  • 256Mbit SDRAM(x16幅,最大143MHz)搭載
  • 周波数切り替え可能なOSC(50.0MHz/24.576MHz/74.25MHz)搭載
  • PIO最大34本(アナログ6チャネル、LVDS 8チャネル)
  • 3.3V単一電源駆動
  • ADC用VREFおよびIO_VCCの外部入力可能


  • ブロック図
    sodalite_block.png

    10M08SAE144のピン割り振り
    sodalite_pins.png

    そんなわけでアートワーク開始。

    まずはおおまかに配置を決める。
    celestine1.png
    今回は面積最優先なのと、ほとんどがピン-ピンの接続であること、相手がMAX10だと電源とJTAGとコンフィグピンさえ間違わなければ、あとからいくらでもリカバリ可能なことから、回路図レスでいきなりアートワークから始めてる。当然ながら素人にも玄人にもおすすめできない。

    SDRAMまわりの配線を追い込む。
    celestine2.png

    このへんからで電源の配線との戦い。
    celestine3.png
    2層基板の場合では、電源と配線のプレーンが満足に取れないので、とれぐらいましな構成にできるかがアートワークの善し悪しになる。
    ちなみに、FPGAみたいにほとんどが汎用信号ピンにできるデバイスでは、部品面を配線にしてハンダ面をベタGNDにしていくのが一番マシなアートワークにできる。
    電源ピンは多少引き回してもパスコンの配置で逃げようがあるが、GNDピンはそういう手段がとれないので、とにかく裏面を可能な限りベタにして「入り江」や「島」を作らないことを第一に考えてる。

    そんなわけでアートワーク完成\(^o^)/
    celestine4.png

    配線チェック(拡大印刷とカラーマーカーの出番)してシルクを入れ、基板屋さんに発注。
    sodalite.png
    ちなみに今回はドリルのアニュラリングとラインスペースをギリギリまで削ってるので、格安基板は使わず安心のP板.com
    デザインルールは当然確認しているが、工場の特性をきちんと把握しているところで最終チェックをしてもらわないと、乗っかる部品が高価なだけにあとで泣きをみる。

    到着までに部品も発注。

    MAX10ボードがそろそろ限界 [FPGA]

    いろいろといじくり倒したMAX10ボードだけども、そろそろ限界が見えてきた感じ。
    Bz2o0gnCYAAeC8Q.jpg

    表はあんまりいじってないけど、裏側はこんな状態
    Bz2nzUTCMAAEOxz.jpg

    micoSDカードスロットとSDRAMを余ってるピンに配置したのだけども、NiosIIの時にキャッシュが上手く動かなかったのはどうやらSDRAMのデータ線の信号品質がギリギリアウトの領域に入ってた模様。
    オシロでクロックラインとDQを見てみるが‥‥
    TEK00000.PNG
    TEK00001.PNG

    100MHzの信号は帯域200MHzのオシロじゃ分からん!ヽ(`口´)ノ

    VGAの出力が綺麗に出ていること、NiosII/eではmicroSDカードの読み出しがきちんと動作すること、NiosII/sや/fにするとデータキャッシュが無くても途中でハングアップすること、などから察するに、おそらく書き込み方向のバーストアクセスが問題だろうと予想している。
    バースト読み出しが問題ならVGAの表示がおかしくなるはずだし、書き込みが全部問題ならNiosII/eでも問題が出てるはずだ。VGAやNiosII/eに無くて、NiosII/sや/fが持っている特徴といえば、全段パイプラインによるメモリへのバーストアクセスだからだ。

    というわけで、MAX10ボードでできることはそろそろ限界になりつつある。ボード起こそう。
    DMM.make AKIBAで測定とか実装とかできませんかね?

    Bz2UGHbCMAAoXzY.jpg

    MAX10でファミマチャイム [FPGA]

    作業の合間にちょろっと作ってみた


    Githubのリポジトリはこちら
     → https://github.com/osafune/max10_famimachime


    ちなみに和音やエンベローブもすべてロジックで計算している。フルロジックで使用リソースは255LEしか使ってないので、ロジックの片隅に入れておくチャイムとしては使い道があるかも。
    全体のブロック図がこれ
    ファミマチャイムのブロック図.png
    2個の音源(矩形波+エンベローブ)に対して、音譜テーブルでノートを発行している。
    それより後は、矩形波のみ2ポリフォニックの音源の構成で、実は音源コアの基本中の基本構成。
    この波形生成部分のデューティー比を調整できるようにしたのがPSG音源で、波形のパターンを選べるようになったのがSSG音源。さらに、ごく短い波形をループ再生するようにしたのがWSG音源というわけ。

    いろいろ改造してみるといいかも。

    MAX10でNiosII動かしてみた(追記あり) [FPGA]

    連休中は台風19号接近のため、予定していた九州慰安旅行がキャンセルになってしまいました。
    なので、ずっとMAX10ボードをいじっていたわけですが。

    前回で書き込みファイルはできるようになったので、今回はNiosIIをMAX10で動かしてみます。
    QuartusIIでプロジェクトを作成してQsysでコンポーネントを追加するのはそのままですが、MAX10では旧来のNiosIIはサポートされていないので、Gen2をインスタンスする必要があります。
    max10nios2_00.png

    NiosII Gen2では、コアの種別が/eコアと/fコアの2種類になりました。
    max10nios2_01.png

    これまでの/sコアはどうなったのかというと、/fコアのカスタマイズで/sコア相当のものが作れるようになっています。
    逆にこれまでできなかった、/sコアにあとデータキャッシュだけ欲しい、という細かい設定が可能になりました。
    /fコア自体も、ECCメモリによるエラー保護や高速割り込みに対応したシャドウレジスタ機能など、細かいアップデートが施されています。

    また、Gen2ではメモリタイプのペリフェラルに紐付けされていたベクタアドレスを、絶対値アドレスで設定できるようになりました。
    max10nios2_02.png

    Qsysでは生成したコンポーネントをさらにQsysで再利用できますが、これまでNiosIIを内蔵したコンポーネントではペリフェラル名のオフセットでベクタが指定されてしまうため、プログラムを外部に置くようなシステムコンポーネントが作りづらかったのが、独立したMPUとしても扱えるようになりました。

    (追記) >‥‥と書いててなんですが、どうもNiosII Gen2 /fコアのデータキャッシュを使うと、IORD/IOWRによるマクロが上手く動作しないようです。特にIORDでのレジスタポーリングが致命的で、コンパイラはldwio命令を生成しているものの、挙動を見る限りデータキャッシュがバイパスされていない模様です。
    どうやら基板裏に実装したSDRAMのバーストアクセスでごくまれにリードミスを起こしている模様。ロジックのせいではないようです。 → MAX10ボードがそろそろ限界(2014-11-01)


    そんなNiosII Gen2ですが、実際の使い勝手は旧来のNiosIIとまったく同じです。
    いつもの通り、100MHzのシステムクロックと、40MHzのペリフェラルクロックを生成して、NiosIIコアと内蔵メモリとペリフェラルを生成します。

    ペリフェラルはいつもの通り、sysid、timer、jtag-uart、それからLEDとDIPスイッチを読むIN/OUTのPIOと、MAX10 EVKボード上のArduinoシールドコネクタピンに直結しているBidir-PIOをつけました。

    ペリフェラルアクセスにはクロックドメインを跨ぐ必要がありますが、Avalon-MM Pipeline Bridge でまとめてペリフェラルクロックへドメインをまとめます(ちなみに Avalon-MM Clock Crossing Bridge を使わないのは、ペリフェラル側はバーストアクセス不要なのでLEをケチるため)。


    途中いろいろすっ飛ばしてLチカをしてみたのがこちら


    さらに途中をすっ飛ばして、SDRAMコントローラとVGAコンポーネントを追加してHDMIに絵を出してみたのがこちら


    MAX10ボード使ってみた [FPGA]

    MAX10ボードが到着したので早速いろいろ試してみた。
    QuartusII 14.0 Update2は、まだ即席対応で、とってつけた感が否めない。
    前回エントリのRAM初期値オプションもさることながら、14.0 Update2ではまだPOFが自動生成されない。
    なので、スタンドアロンで動かす場合はPOFを手作業で作成する必要がある。

    MAX10では単体コンフィグのシングルコンフィギュレーションと、2つのコンフィグデータを格納するデュアルコンフィギュレーションの2つのコンフィグモードを使うことができるが、今回はシングルコンフィギュレーション用のデータを作成する。

    まずQuartusIIでMAX10用のプロジェクトをコンパイルする。
    次に、File→Convert Programming files...を選択して、コンバートツールを起動する。

    Modeプルダウンメニューから「Internal configuration」を選択。
    convpof01.png

    File nameで出力先のファイル名を指定する。
    convpof02.png

    Input files to convertのSOF Dataを選択して、Add File..をクリック。
    convpof03.png

    QuartusIIで生成したsofファイルを選択。
    convpof04.png

    読み込まれたsofを選択して、Propertiesをクリック。
    convpof05.png

    CompressionにチェックをいれてOKをクリック。
    convpof06.png

    Generateをクリックするとpofファイルが生成される。
    convpof07.png

    Closeでコンバートツールを終了させて、次にQuartusII Programmerを呼び出す。
    ボードにUSB-Blasterを接続してAuto Detectをクリックする。
    convpof08.png

    「10M08SAES」を選択してOKをクリック。
    convpof09.png

    デバイスを選択して、Change File...をクリック。
    convpof10.png

    先ほど生成したpofファイルを選択。
    convpof11.png

    Program/Configureの一番上のチェックボックスにチェックを入れるとCFMとUFMにもチェックが入る。
    convpof12.png

    StartをクリックするとMAX10デバイスにコンフィグレーションデータを書き込む。
    convpof13.png

    結構時間がかかる。
    convpof14.png


    プログレスバーが100%まで伸びてSuccessfulの表示が出たら書き込み完了。
    ボード上のnCONFIGキー(SW2)を押すか、電源を入れ直すとMAX10が再コンフィグする。

    さくっとHDMIコアをいれてテストパターンを表示させてみた。


    NiosIIでLチカしてみた。


    MAX10ボードがもうすぐ到着 [FPGA]

    昨日MAX10シリーズが発表になり、即日出荷が始まっています。

    アルテラ、次世代の不揮発性 MAX 10 FPGA、およびMAX 10 FPGA 評価キットの提供開始を発表

    EVAボードはALTERAを初め、Arrowやマクニカから4種類が発表され、DigikeyやMouserで取り扱いが始まりました。
    早速、ALTERAのEK-10M08E144ES/Pを注文してみました。
    max_10_eval_board.JPG


    さて、それと平行してMAX10の実デバイス向けにコンフィグレーションデータを用意します。
    MAX10はコンフィグレーションROMが内蔵されているため、外部コンフィグはMAX II/VのようにJTAGのみです。
    コンパイルはQuartusII 14.0にMAX10用ライブラリを追加するUpdate2を導入します。

    ダウンロード・センター Quartus II ウェブ エディション
    update2.png


    QuartusプロジェクトはCycloneIIIやCycloneIV Eのものがほぼそのまま流用できます。
    EPCSペリフェラルを使っているものはSPI Flash扱いになりますが、リモートアップデートペリフェラルはMAX10の内蔵ROMと競合してしまうので修正が必要になります。
    また、MAX10では256ピン以下のパッケージのデバイスではPLLが1個しか使えないため、PLLを2個以上使っているデザインはそのまま流用できません。CycloneIII/IV EではE144パッケージでも2個または4個のPLLが使えたので、ここは要注意です。
    Qsysで新しくデザインをする時は、旧来のNiosIIでは生成することができず、新しくNiosII Gen2のコンポーネントに差し替える必要があります。


    QuartusII 14.0 Update2では、後付けでMAX10のライブラリを追加してコンフィグレーションデータを生成するようにしたため、本来は自動で設定されるであろう項目をマニュアルで設定しなければなりません。
    このうち、特にクリティカルなのがM9kメモリマクロの設定です。

    Settings→Analysys&Synthesis→More Settings で追加設定を開き、その中のEnable ERAM PreloadをOff→Onにします。
    max10_m9k_option.png


    どうやらMAX10ではコンフィグレーションデータ圧縮のためにメモリマクロの初期化を変更しているようで、この設定をしないと初期値データ(.mifや.hex)があるM9kメモリがコンパイルエラーになります。

    また、14.0 Update2では合成結果がsofまでしか生成されません。
    MAX10デバイスに書き込むpofファイルを生成するには、File→Convert Programming file でsofをpofに変換します。UFMに書き込むユーザーデータやDualコンフィグレーションのsofもここで一緒にpofにまとめます。

    MAX 10 FPGA Configuration User Guideに詳しい手順が書いてありますが、14.0 Update2と一部食い違う部分があり、現状はあくまで暫定環境という扱いだと思います。
    QuartusII 14.1ではこのあたりの面倒くさい手順もすっきりすると思います。

    PERIDOT先行頒布開始! [FPGA]

    あれやこれや右往左往してたPERIDOTですが、ようやく大垣MiniMakerFaireで先行頒布を開始しました。

    BvxD2gXCEAA7p99.jpg

    PERIDOTとはなんぞや?という人はコチラへ
     → 'PERIDOT' - Simple & Compact FPGA board

    OMMF後、余ったスターターセットの通販などを受け付けてましたが、来月には一般販売を開始する見込みです。

    Bu4A6rBCAAAN0Tg.jpg

    絶賛量産中

    Internal Oscillator を評価してみる [FPGA]

    過日QuartusII 14.0がリリースされ、予告通りCycloneIIIがライブラリ落ちしたわけですが、それ以外にもいろいろと変更が入っています。
    見た目で一番大きく変わったのは、長らくIP生成のメインだったMegafunction Wizardが無くなり、QsysベースのIP Catalogに変更されました。細かい話ですがSchema EditorのコンポーネントウィンドウからもMegaWizardのボタンが無くなってます。

    さてそのIP Catalogですが、14.0からInternal Oscillatorという見慣れないコンポーネントが追加されています。

    internalosc.png

    内蔵OSCといえばMAX II/Vシリーズのコンポーネントでしたが、このInternal OscillatorコンポーネントはFPGAでサポートされているのが特徴です。
    ためしにCycloneIV Eでコンポーネントを生成してみると、最大周波数は80MHzとだけ表示され、それ以外の設定項目がありません。

    internalosc2.png

    そこでEP4CE6E22C8Nが載っているPERIDOTボードに実装して、このInernal Oscillatorが何者なのか調べてみました。

    結論から言うと、Internal Oscillatorの正体は、ActiveSerialコンフィグレーションモードで使われる内蔵の発振器を流用していると推測できます。
    理由は

     (1)Internal Oscillatorは1つのデバイスに1つしかインスタンスできない
     (2)最大周波数80MHzはEPCSクロックの最大周波数40MHzのちょうど倍

    です。ここから、ActiveSerialのクロックはデータシート上で最低20MHz、最高40MHz、標準30MHzと規定されているので、Internal Oscillatorのクロックはおおよそ60MHz前後だと推測ができます。

    というわけでさっくり実装して測定してみたのがこちら

    Br8silyCAAEYJoa.jpg

    プローブのGNDが遠くて波形はヒドイ形状になっているものの、周波数は推測どおり60MHz近辺でした。

    さて次はこのOSCがどれぐらいの安定度を持っているかです。
    しばらく放置してばらつきの統計をとってみたところ‥‥

    scope_11.png

    中央値と平均値がきれいに揃ったガウス分布(正規分布)が得られました。
    中央値64.54MHzに対して標準偏差139.65kHzです。

    周波数の保証はなくジッタも±3σにはぎりぎり収まらない程度ですが、周波数が偏っているわけでもなく、かなり安定したクロック源として使えそうです。
    周波数精度としてはかなり悪いですが、ジッタが綺麗に正規分布になっているので、外部からの精度の良いクロックで内蔵OSCのジッタをカウントすれば、ガウス分布の乱数発生器を作ることができます。

    また、このOSCはFPGAの内部回路のみで動作するので、電源が入って正しくコンフィグレーションできれば、ピンアサインやボード状態によらず当てにすることが出来るクロック源になります。
    これはボードの初期デバッグ時などのセルフチェックで特に有用です。


    ‥‥で、あと一つ問題なのが、これはどのFPGAまで使えるのかという点です。
    CycloneIV Eは基本的にCycloneIIIのシュリンクなので、この仕掛けはCycloneIIIで既に実装されていたのでは?と思ってRTL Viewerで見てみると、案の定cycloneiii_oscillatorというプリミティブのインスタンスが確認できました。

    ついでにQuartusII 13.1がインストールされているところにQuartusII 14.0をインストールすると、13.1のMegaWiazardでにもInernal Oscillator(表示名はALTINT_OSC)が出現します。

    internalosc3.png

    CycloneIIIでもしれっと使える模様。

    マイニングマシンの予備研究(その2) [FPGA]

    前回のエントリではBitcoinの概要と、マイニングのメイン処理になるSHA-256処理部について書いた。
    今回はその続きとして、実際の採掘の処理部をどう設計したものか思索してみる。

    まず、前回OpenCoresから持ってきたSHA-256コアの続きから。
    結論から言えばこのコアは実装に問題がありすぎたので全部作り直した。ただし、大元のテストベンチとテストデータの入手元としては非常に有用だったのでそこは誤解無きよう。ゴールが明確であるというのはとても重要なことなのだ。

    その中で仕様を変更した点が大きく3つ。

     ・ラウンド関数の入出力をレジスタードに変更
     ・メッセージ入力を256ビットパラレルから32ビット単位のシリアルへ変更
     ・制御信号を丸ごと変更

    この結果、ハッシュ演算結果が出るのに1クロック余分にかかるようになったが、各モジュール間できっちりパイプライン化されたので配置配線で有利になっている。
    またデータ入力を32ビットのメッセージワード単位にすることで、メモリバスマスタやプロセッサからのデータ転送の手間を軽減している。内部メモリマクロを活用する場合でも32ビット単位は都合が良い。
    そして制御信号を丸ごと変更。これは単に、これまで自分がやってきたAvalonMMモジュールに組み込む場合のスタイルに合わせたためであんまり深い意味はない。

    で、シミュレーション結果がこれ。
    BeJgkySCMAEQTTV.png

    ステートマシンを定数Kのアドレスカウンタを流用するようにしたので、クロック数が分かりやすくなっている。
    この状態でQuartusIIでコンパイルしてみた。
    sha256_qii.png

    元の状態では1900LE+2M9Ks必要だったものが、1100LE+3M9Ksになった。これはパイプライン化したので中間ワード生成ブロックの巨大なシフトレジスタがメモリマクロにマッピングされたのが効いている。
    このようにQuartusIIは使えるリソースからマッピングを選択してくれるので、ツール推奨の記述やレジスタ構造にしておくというのは、使い回しの点でとても意味がある。

    前回は規模の見積もりでざっくりと2000LEとしたが、書き直してロジック量が6割ぐらいになった。ということはFPGAに実装できる数がそれだけ増えたことになる。
    グルーロジックを含めて1200LE+3M9ks、全体制御で1000~2000LEとすると、EP4CE6に2基しか実装できなかったハッシュ演算コアを4基にできる。ついでに動作速度も2~3割ぐらい上げられるはずだ。
    そうすると10MH/sを超える。これは最新のCore i7でAVX命令を駆使してカリカリにチューニングした場合の値に匹敵する。特化バンザイ(2回目)

    作り直したSHA-256コアのVHDLソースはGithubに上げておいたので自由に使って頂いて構わない。
     → Github :: sha256_core


    さて今回の本題はここから。

    キモの処理であるSHA-256はできた。次は実際にBitcoinがどのような手順でマイニング処理を行うか。
    Bitcoinはマイニングをブロックの単位で行う。まずP2Pネットワークから一番長いブロックチェーンと、最後のブロック生成から現時点までの全ての取引情報を持ってきて、それをブロックヘッダに格納する。
    次にブロックヘッダを2回SHA-256に通してハッシュ値を得る。この時のハッシュ値の最上位に特定の数のゼロが並んだものが新しいブロックとして登録することができる。
    sha256-1.png

    これについてはBitcoin Wikiにある程度詳しい概要が載っている。
     → Block hashing algorithm(Bitcoin wiki)
    いくつゼロが並ぶかを決めるのにDifficultyというパラメータが使われ、ゼロ並びのデータを引き出すためにnonceというパラメータを変えながらブロックヘッダのハッシュ演算をひたすら繰り返す。ここに猛烈な計算量を投入しているわけだ。

    これをハードウェアに実装することを考えてみる。

    ブロックヘッダのうちハッシュ演算毎に変更されるのはnonseの4バイトだけで、それ以外は固定値と考えられる。
    ブロックヘッダは80バイトだが、SHA-256演算は64バイト単位なので48バイトのパディングメッセージが付いて32ビット幅×32ワード=128バイトある。
    ハッシュ演算を2回行う。ハッシュ値は256ビット(32バイト)なので、1回目のハッシュ値に32バイトのパディングメッセージをつけて64バイトにする。

    真っ先にSHA-256コアを2個カスケード接続することを思いつくが、ちょっと考えれば前段と後段は同時には動かないことが分かる。
    またコアへの入力について、グルーロジックが増えるのも動作クロックに影響するので、ハッシュ値の書き戻しに余分なクロックが発生することには目を瞑り、実装ロジック数を優先する。

    同様に、ブロックヘッダのハッシュ計算中に変化しない値については全て演算ブロックの外で初期値として用意する。
    入出力についてはメモリマクロを使う。これはインターフェースのクロックドメインと処理ブロックのクロックドメインを分離するため。こうしておくとインターフェース側のクロックに引きずられることなく、処理ブロックをぎりぎりまで高速動作させることができる。

    というわけでざっとこんな感じになる。
    ブロック演算.png

    ホスト側からブロックヘッダ+パディングの128バイト分を入出力メモリに書き込む。またnonceと図中にはないがサイクル数、それからハッシュ値のゼロ個数を指示してステートをキックする。
    処理ブロックはブロックヘッダのnonceメンバの部分だけを内部レジスタの値に読み替えてハッシュを計算し、パディングを付けて一端入出力メモリに書き戻す。
    次に、今度は書き戻されたハッシュ値をもう一度計算し、結果のハッシュ値の上位にいくつゼロが並んだがを判定する。これを終了条件に合致するまでnonceをインクリメントして演算しまくる。
    ハッシュ値を発見したらホストは入出力メモリに格納されたハッシュ値とnonce値を読み出す。

    これでざっと見積もると、ロジック規模が1400~1600LE+4M9ks、1サイクルあたりのクロック数は160クロックぐらいだ。
    仮に120MHzで動作させると、1秒間にブロックヘッダの計算を75万回試行できる。
    あとはこれを入るだけ並列化すればいい。


    ‥‥で、儲かるの? という幻想については「もはや儲からない」と答える。

    というのも、実際にこれがどれぐらいの採掘能力かを量ってみればわかる。Bitcoin Wikiにあるブロックヘッダ例のnonse値は2504433986で、これはつまり25億回の試行をしたということだ。
    単純にこの回数を75万回/秒でやったとすると55分40秒かかる。マイニングは10分毎に更新だから、発見した頃には既に新しいブロックが5個繋がっている。

    つまり、こんな速度ではまったく儲からない。
    最新のプロセッサと同等の速度でこれだから。

    何度でも言う、儲からない。夢見るのはやめとけ。


    それでも夢を見たい人は採掘ASICとか買えばいいと思うよ!知らんけど!


    BitcoinのそしてBitcoinのサービスへの初心者向けガイド

    BitcoinのそしてBitcoinのサービスへの初心者向けガイド

    • 出版社/メーカー: Premier Ark LLC
    • 発売日: 2013/06/19
    • メディア: Kindle版



    ビットコイン Bitcoin 採掘USB ASICMiner USB 330MH/s

    ビットコイン Bitcoin 採掘USB ASICMiner USB 330MH/s

    • 出版社/メーカー: Bitfountain
    • メディア: エレクトロニクス






    ビットコインBitcoinマイナー(採掘)2.7Ghz/s ASIC USB 日本語マニュアル付き!

    ビットコインBitcoinマイナー(採掘)2.7Ghz/s ASIC USB 日本語マニュアル付き!

    • 出版社/メーカー: bit fury
    • メディア: エレクトロニクス



    ビットコイン あたらしいネットビジネスの教科書

    ビットコイン あたらしいネットビジネスの教科書

    • 出版社/メーカー: アイオフィス
    • 発売日: 2013/12/18
    • メディア: Kindle版