ジュラシックワールド観て来た（最高）

ジュラシックパークのまともな続編が出ないとお嘆きの諸兄。
あれもこれものリメイクラッシュの中、なぜジュラシックパークがリメイクされないのかとうち震えている諸兄。
3D 映画を結構制作しているのになぜジュラシックパークを 3D 化しないのかと憤懣やるかたない諸兄。

新作、ジュラシックワールドは諸兄らが待ちに待ったそれ、正にそれだということをまずお知らせしたい。
このような最高の続編を観られる幸福に乾杯。

いえ、慧眼なる諸兄らにあらせましては、予告編を見終えた瞬間に、椅子をガタと言わせて立ち上がったことでしょう。
これまでの続編がまぁ、ファンとしてはクソだとゴミだとは言い難いのですけれど、控えめにいって大変ガッカリな出来だったことは認めます。
次もきっとそうであろう、と思いながら予告編が始まるのを目にし、咄嗟に 「またやるのか。懲りないな」「もしかするとジョークムービーなんじゃないか」と思ってしまったほどであります。
ですがどうでしょう。
舞台はあのコスタリカ、イスラ・ヌブラ島。
二十年後、オープンした人気リゾード「ジュラシックワールド」。

来た。
来るべき時が。

スピルバーグは「シリーズとして継続可能な脚本が書けた者に続編を任せる」と言いました。
けれど、皆解っていたはずです。我々が本当に求めていたのはそうじゃない。
サイト B や、キャラクターは名優揃いで惜しいけど、昔の恋人とかそんな掘り下げは全然求めてない。

考えてもみてくださいよ。例えば一作目が素晴らしいメジャーリーグベースボールの話だったのに、出てきた続編がなぜかスポーツのための先進トレーニング研究所の話だったとか、監督の娘が体操の選手になって鉄棒で 160km/h のストレートを蹴り上げたとか、カーブが来たら必ずホームランを打つ強力な打者がマイナーリーグから来たけど誰もカーブを投げないとか、そんな話だったらどうします？

えっ、ナニコレ、外伝ですか？テレビシリーズですか？

ってそうなりますよね。
まぁ、日本の原作付き実写版とか、そういうポカを毎回のようにやってますけど、ハリウッドでもやるんだな〜よっぽど強いビジョンがないとこうなっちゃうんだな〜という学びはありますね。

皆解っていたはずです。
我々が本当に求めていたものは、

イスラ・ヌブラ、
そして恐竜のテーマパークなのです。

いわば念願にして唯一の正当続編、それがジュラシックワールドです。
夢のあるパークのプロップ、わくわくする設備の数々、明るいところで恐竜と戯れ、ジャングルを彷徨い、海岸線の絶壁、丘陵地帯のブロントサウルス……。
恐竜は登場人物の一部であり、 パークと島はもはや主役といっていいものです。
それらが 3D と最新の技術で、凄まじい実在感を持って目の前に展開します。

まず本作を未見の方には、観ようかどうか迷っている暇があったら観に行くべきだということと、シリーズ前作までを知らない方にはこんなものを読むよりさっさと劇場に行ってスクリーンの全てに集中したほうが有意義だということ、そして 3D で観るかどうしようか迷っている人には 3D で観るべきだということを強く推奨します。
字幕かどうかについては、そんなにシビアな演技はないから、タレントの吹き替えでない限りどちらでもよいと思います。より絵に集中できる吹き替えも検討できます。
前作までを観てからにすべきかどうかについては、初代のオマージュがとても多いので観ておいたほうがより楽しめると言えます。が、単なるオマージュではなく、現実の時間の流れに意味があるので、初代をリアルタイムで観ていることが重要です。
だから、リアルタイムで観ていないのなら、わざわざ復習してから劇場に行く必要はないでしょう。本作だけでも完成されたエンターテインメントなのですから。
というか、まず本作を観よう。それから初代を観て、また本作を観たらいいのです。
重要なのは二十年の時間の流れ。それがないなら多少順番が前後したところでどうってことありません。

しかし憂慮されるのは、いかんせん微妙な続編をこれまで続けてしまったことでトレイラーや宣伝の、たとえば「新種」であるとか、キャンセルされた「ジュラシックパーク4」のプロットであるとか、そういう部分が鼻について期待が薄れてしまい、まぁ時間があったら観てみよう、くらいになってしまうことです。ファンであるが故に、というわけですね。

そんなファン諸氏に対して、安心したまえ、これは俺達の求めていたジュラシックパークだよ、ということがこの記事の目的であります。
以下、ネタバレがないように気をつけつつ、シリーズ四作目「ジュラシックワールド」の見所の一部を紹介します。
一方で、初代、二作目、三作目のネタバレには全然気をつけてないのでよろしく。
気をつけるとはいってもトレイラーや CM で解るくらいのことは書いちゃってますし、できれば何にも前提知識なく観てもらいたいなと思っております。




コスタリカ沖の霧の島イスラヌブラに建設中だったジュラシックパークの惨劇の後、インジェン社の経営は悪化しマスラニ傘下に組み入れられており、ハモンドはパークの技術とウー博士、そして経営権をマスラニに譲っていました。
マスラニはパークの経営権だけでなく（映画版の）ハモンドの思想も受け継いでいるようで、ただの成金経営者ではなくて中々好人物のようです。
ただしこのへんは完全に映画オリジナルの流れで、二作目（ロストワールド）、三作目（ジュラシックパーク4)を観てないとわからないところです。原作のハモンドは基本金の亡者でしたしそもそもロストワールドの軍人同様、川で小さい恐竜（たしかコンプソグナトゥス）に食われて死んでいます。
一方ウー博士は生き残り、出世しておりましたが、顔は初代からあまり変わっていませんね。

二十年後、マスラニはイスラヌブラ島に「ジュラシックワールド」として遺伝子から復刻した恐竜のテーマパークを開園し、一日二万人にも上る集客を誇るまでに成功させていました。
ランクルではなくモノレールとハイテクのジャイロやカヤックを使った遊覧ルートとモダンになり、ビジターセンターも T-Rex の骨格模型ではなくディロフォサウルスなど色々な恐竜の立体映像に。なんと Mr.DNA の展示も健在！
そして前回の失敗から、恐竜は逃げるもの、トラブルは起きるもの、進化には勝てないという哲学をスタッフの末端にまで叩き込んでおり、 パークは格段に安全で快適になっておりました。
しかし映像を観ると……二万人くらいでちょっと混雑しすぎじゃね？と思いますね。島全体を使ったパークですが立ち入り可能なエリアは南部の僅か。 大部分は恐竜の飼育と研究のためのエリアのようです。
イスラヌブラ島はダイヤモンドのような形状をしており、西部と北部に肉食竜の飼育施設、中部に翼竜ドーム、南部の一部がアトラクションになっているようです。観客は南端の入り江へフェリーでやってきます。

更に、その後の研究でジュラシックワールドでは新たな知見が得られておりました。
一つは遺伝子の掛け合わせで新種を作り出して集客力を高められるということと、ラプトルほどの知能があれば飼い馴らすこともできるということ、そして隔離して飼育した生物にはある傾向がある、ということです。
設備も、恐竜も、（かなり無茶しているようだけど）資金、スタッフも全てがパワーアップ！それがジュラシックワールド！
そのスタッフの二人が主人公です。
一人は海軍からラプトルの管理に雇われたオーウェン(Mr. グレイディ)。初代でいう飲んだくれマルドゥーンと同じ仕事をしていますが、彼は恐竜をよく知って愛しており、その接し方はかのグラント博士よりも手慣れております。
専門はラプトルで、グラント博士のような子供っぽさはないけれど、草食竜との絡みはグラント博士よりも一段深い恐竜への愛情を感じさせます。
子供とも機械とも上手く付き合ってゆける中々の世渡り上手。
なぜ海軍をやめたのか語られませんが、会話の端々からするとどうやら海軍内での競争についていけなくなったようです。

そしてもう一人の主人公は広告マーケティングの責任者クレア。
彼女は恐竜のことを殆ど知らず、パークの研究からも蚊帳の外に置かれ、ただただ集客のために忙殺されている現場の人。
字幕では出てないけどかなり早い段階で「あなたのラプトル」という言い方をしていることからも、その辺りの事情についてだけはオーウェンから聞いていたようです。
クレアは姉（しかも離婚調停中）の子供、つまり甥っ子の兄弟、ザックとグレイをゲストとして預かることになりますが、忙しさのため秘書のザハに預けきりにしてしまいます。
グレイは恐竜好きで詳しいが子供、ザックは高校生にもなって反抗期真っ盛り。
この辺はハモンドと二人の孫、レックスとティムをそのまんまなぞる形になっています。
これに限らず、本作の登場人物は概ね初代の誰かの立場を踏襲する形で配置されています。なのでそれぞれの役割が解りやすいです。
もっともザックは IRIX よりは Android 派、ましてハッカーでもなんでもない普通の高校生ですが……。

叔母であり経営陣であるクレアは、甥っ子にも嫌われ、姉にも嫌味を言われ、目先の利益ばかり追求し行く先々で総スカンを食らうのですが彼女は決して鼻持ちならない人物ではないです。
ドジッ子全開ですが途中からサトラー博士の服を真似をしたりかなりお茶目です。

クレアの目線から描かれるパークの内情は決して単純ではないようですね。
エキセントリックな CEO, 遺伝子操作に反感を持つスタッフ、でもそれをしなければただの動物園になってしまうというジレンマ。
他にも……まぁ、色々な問題があるようなのですが、こうした複雑になりがちなところが面倒にならない程度にストレートに解りやすく話に組み込まれているので、鑑賞する上で邪魔になることはありません。

そして一番の問題は、遺伝子組み替えで作られ、三週間後にお披露目を控えた新種「インドミナス・レックス」の存在。
新種とか（話の出来的に）もう悪い予感しかしませんよね。僕は「また余計なもの入れやがって」と心配していました。
ところがどっこい、この新種は、凄く使える奴でした。
何をしても映える。凄い絵になる。
CGI で描かれたでっかいトカゲが、こんなに恐ろしい演技を見せてくれるなんて想像できませんでした。迫力は、勿論映画館の音響っていうのも大きいのでしょうが、その怖さは、例えるならダークナイトのジョーカーにも近いものを感じます。
噛み方一つとっても、いい意味でいちいち恐竜らしくない。
知能も破格だが、それが荒唐無稽にならない程、登場の仕方が様になっている。
T-Rex の前足の弱さのような脆さもなく、動くものしか見えない視力といった弱点も持たない。

恐竜の種類といえばシリーズ中、ちょっとずつ増えてきて、その度ちょっと上滑りしている感じがあったけれど、今回は描かれ方もとてもよいです。
初代ではたとえば、トリケラよりもトリケラと戯れるサム・ニールを主体にしていた印象がありますが、 本作ではずっとはっきりと恐竜を捉えています。
ガリミムスの群れやブラキオサウルス、例えばプテラノドンにいじめられるトリケラトプスの子供とかすごく可愛い。
そしておなじみのラプトル同士の掛け合いなど。ラプトルの鉤爪があまりフィーチャーされなかったのは何か理由があるのでしょうか。新しい学説で実は爪は大したことなかったかも知れないとか、そういう。本作では新しい学説に基づいて変更が加えられているようで、登場しなくなった恐竜などはその兼ね合いが大きそうです。
元々初代からラプトルはかなり愛嬌のある描かれ方をしていたけれど、今作では表情まで伝わってきそうな気迫がありますね。
彼女らの狩りの仕方について、初代からずっと御都合主義過ぎるんじゃないかという批判もありますが、集団の狩りをする計算高い生き物ということは作中でも繰り返し語られるところでして、不合理はありません。
三作目に華々しく登場し、あまり活躍しなかったプテラノドンなどの翼竜もちょっとやり過ぎなんじゃねってくらい大活躍します。
ただうざいだけでなく、遠くからでも絶望感があってスピーディー。彼女らの性質がとても生かされていました。
特筆すべきは新登場のモササウルスです。
途轍もなくでかい、クジラのような水棲の恐竜。
これはトレイラーで観て「あーまた使えなさそうなの出るなぁ」くらいにしか思わなかったんですけど、これが実にとんでもない。
よく考えたなぁ、こんなの。今作のスタッフは、恐竜が好きで好きでたまらないんだな。

初代以外はずっとホラーのような暗い場面でのショッキングな襲撃ばかりでしたが、今作は明るい、成功した恐竜パークとしてもずっとしっかり描かれています。
恐竜ばかりではありません。ヘリのシーンが何度も登場しますので、あの入り江や、ランドマークになった滝や、懐かしの雄大な尾根からの丘陵地帯も 3D で堪能することができます。風景どころか空気感だけでも懐かしさがあります。真っ暗な中で施設や車の照明が灯っているカットだけでもちゃんと「ジュラシックパークっぽい！」となるんだから不思議なものです。
初代だと、変電所の入り口でラプトルとサトラーが追い掛けっこするシーンなんか霧が濃過ぎてちょっと安っぽいというか、セット狭いんじゃね？という感じがあったのですけど、今作はそういうこともなく空間と空気が描ききられています。
加えて、人間に対する暴力も容赦がなくなっています。
いえそもそも狩りで手加減などしてくれないので、その意味じゃ元々容赦ないんですが、描き方の話です。
初代などは人間の捕食シーンもどちらかというとコミカルにぼかしていたし、アーノルドのように腕だけになって登場したり、そもそも死んだのかどうかさえ解らない人物さえいました。
そういうところはかなり減って、グロくはないものの比較的苛烈になりました。

今作は、初代の朝のブラキオサウルスやハモンドのノミのサーカスの話のような、しんみりするシーンは殆どないけれど、これでもかとオマージュが詰め込まれた上、素晴らしい恐竜パークとその熾烈なパニックが実在感をもって詰め込まれた最高傑作です。
恐竜はただの猛獣ではなく、個性的で物語の担い手として完璧に組み込まれています。
昼も夜も広々と描かれた島は空気感まで伝わってくるようです。
全部見所ですが、こうしたところに注目するとより楽しく観られるのではないでしょうか。
あ、そうそう、これは完全に余談ですが、もう一つ書いておくと松本そっくりの浜田でちょっと笑いました。

ARM SoC ボード Helio で SDRAM アクセスが遅い問題の解決

もう二ヶ月くらい経ってしまいましたが、 Helio の SDRAM アクセスがやったら遅い問題は解決しておりました。
まとめる時間がなく今もないので軽く書き置きしておきます。

まずは Avalon 経由でアクセスしている FIFO 付き SDRAM インターフェイスですが、これに入れているクロック 50MHz がまずかったようです。
これはそのまま SDRAM のクロックとなるようですが、それ以外にも重要だったようで、これを 100MHz にしないとパフォーマンスが出ませんでした。
「いや、スループットが二倍になっても全然足りねーじゃん」と思ったのですが、これを 100MHz にしたところ 2 倍どころか 8 倍くらいになり、かなり納得のいくパフォーマンスになりました。
（ちょっと具体的なデータが今すぐ見られませんが）

以下の helio_ghrd_top モジュールに与えられている二種類のクロックのうち

input  wire        fpga_clk_50,
input  wire        fpga_clk_100

fpga_clk_100 のほうを、 export してあるインターフェイス（前回作った memwrite_master) を経由してコントローラに供給しましょう。

 memwrite_master m0(.clk(fpga_clk_100),


ただしこれでも理論値には微妙に届きません。
今は一回のストアに 4 ステートほどを経由する必要があり( Avalon MM の先のオービターで更にどれくらいのオーバーヘッドがあるかわかりませんが、少なくとも……）、このままでは理論値には届きません。
可能な限りコントローラの介入を避けられるよう、これ以上はバーストモードを使いましょう。

バーストモードでは最大 255 * 512bit のストアが可能です。
Avalon のインターフェイスには burstcount が出ています。ぱっと見、これを使えば簡単そうなのですが反面データシートの記述とは一致しないため不安があります。

実際やってみるとこれはまたハマりました。
詳しいことはまた後ほどまとめたいと思いますが、やっぱり Avalon のインターフェイスがデータシートと一致していないのが敗因で、バースト転送の開始を示す信号は、 burstlength の変化をトリガーにして暗黙に生成されているようでした。
つまり毎回同じ burstcount だからといって定数を出していると、他の信号を変化させてもたった一度しかストアが行われません。
また転送終了のシグナルも出ていないので、これの捕捉にも癖があり苦戦したように思います。

結果、 1 クロック余計なステートが増えましたが無事バーストアクセスできるようになり、（バースト長にもよりますが）理論値と比較してそれほど遜色のないパフォーマンスがでるようになりましたとさ。

ヘッドフォンを買う

えーと……なんでだっけ。なんで買おうと思ったんだっけ。
そうだ、思い出した。蛍光灯が壊れたからだ。
リビングが真っ暗になっちゃいましてね。
なくてもいいかなと思ったのですが暗いと以外と何もやる気出ない。条件反射のようにもう寝るしかねーかな見たいな気分になってしまって。
これはいかんなと思って照明を買いに行ったわけですが、11-2 畳くらいで使えるシーリングライトとなると、これが結構バカにならない値段がしてた記憶があるわけです。7万か8万か……安くてもそれくらい。
それまで使ってたシーリングライトも、あんまり高いので 10 畳くらいのやつを 5 万くらいで買って使っていたので微妙に暗かった。

あーもう急な出費がーと覚悟をキメてヨドバシ行ったらですね、ないんですよ。蛍光灯が。
全部 LED だけになってまして。
LED かー、あんまりいい印象ないなーとしぶしぶながら見てみると、これが安い。 3 万もしない。
12 畳用でさえ 2 万しないくらいからある。

パナの二色を調光できるタイプのやつを二万三千円くらいで買いました。

予想よりだいぶ安上がりについたな〜と帰ろうとしたとき、ふと足が止まったわけですよ。そこがヘッドフォン売り場でした。
怖いですね。
金色の四角の真ん中に HI-RES とか書いてあるんですよ。黒い文字で。
怖いめう。

買ってました。
そういやプレイヤーがハイレゾ対応になっていたのに対応のヘッドフォンもイヤフォンも持ってないから放置してたのですよ。

二万六千円くらい。
シーリングライトより高くついたじゃん。

MDR-1A というやつを買いました。
……これは！ MDR-EX90 を越える自然さじゃないか！大人し過ぎてもっとドンシャリじゃないと物足りない感じもあります。イコライザーでカバーしましょう。
MDR-10R 系も試聴したのですけど、ドンシャリの派手さは好きだけど籠もりがひどくって 1A の魅力にはかないませんでした。安いけど、籠り方だけ聞くと 9000 円くらいのやつとあんまりかわらない感じするし、むしろ割高かも。

せっかくなのでハイレゾ用の音源も買いました。
mora であっという間にダウンロードできたので、「でかいと思ってたけど大したことねーな」と四曲くらい買ったところデータ転送しすぎ警告が来ました。
転送量見てみたら mora だけで 800MB 以上使ってました。一曲あたり 200MB 以上。
うわーでけぇ！　怖い！！

同じ曲のハイレゾ版と AAC 版を聞き比べてみるとまるで別の音源なのですけど、冷静に考えるとこれはそもそも別の音源であって、比較のしようがない。

もちろん AAC だって、いいんですよ。
ハイレゾ版はなんていうか、アレだ、スタジオで聞いてる音だ。ヘッドフォンから鳴ってる音じゃない。

ああ、これはいい買い物した。
ハイレゾ音源でなくとも、 MDR-EX90 くらいの仕事は余裕でこなしてくれます。
なんだかんだ文句いいつつ XBA-40 を気に入って使っていたわけですが、これが XBA-40と同じくらいの値段ですよ。
家用にもうひとつ欲しい。

Altera SoC Helio で SDRAM の HPS/FPGA 共有(作業編)

前回の記事で詳細には踏み込んでいないものの、ほぼ必要な情報が揃っているはずです。
実際の作業を始めましょう。
でもまず、作業を始めるのにあたって必要なものが欠けています。
Helio として最低限動作可能な FPGA 側のリファレンス実装です。

作業編

リファレンスデザインの入手

Helio は GSRD (Golden System Reference Design) というものに則って設計/実装/提供されています。
生憎こちら、GSRD という枠組みについては詳しくなく、どこからどこまでが GSRD なのかはよくわからないのですが説明によると, Altera か Xilinx かにはよらず

FPGA(GHRD) + ARM SoC + Linux 環境  = GSRD

ということのようです。
Altera だろうとそうでなかろうと GSRD に従った設計がなされているものについてはある程度似たような環境が用意されているということですね。
ここで重要なのは、主に FPGA 側の設計のリファレンスデザインである GHRD (Golden Hardware Reference Design) のほうですね。

Getting Start Guide に従ってサンプルを動かした人ならば既に手元にあるはずです。
しかしながらドキュメントに従って cv_soc_devkit_ghrd.tar.gz をゲットしてしまった人は残念。理由はわかりませんがこれは Helio では動かず、　Helio には以下から専用のものを入手しましょう。
helio_ghrd_5csxc4_v14.*.zip が正解です(Quartus II のバージョンに合わせて選んでください)。

http://www.rocketboards.org/foswiki/Documentation/HelioResourcesForRev14

に一通りあります (ボードの Revision が 14 用。 Quartus のバージョンと紛らわしいですが、今はたまたまどっちも 14 です)。
間違えると回路が正しくても Linux がブートしなくなります。
なんというハメでしょうね。僕はこれにハマって二三日悩みました。(.sof イメージは焼いても電源を切ると揮発するので、復旧自体は簡単です)

GHRD の中身は全て Quartus II のプロジェクト及び Qsys で扱う IP とサンプルの　helio_ghrd_top.v です。
自分でビルドしない限り、一切のビルド物は含まれていません。

helio_ghrd_top.v を開くと、殆どの信号は soc_system という下位回路に結線されているのがわかります。
その soc_system が GHRD の本体であり、 HPS のインターフェイスを実装した（あるいはこれから実装する）回路であります。

ところが soc_system の実装自体は .v としては付属しません。
soc_system は全て IP として提供されており、 soc_system.qsys から Qsys で生成して入手します。
このへんの手順は Getting Start Guide でも一通り説明されていますので、僕のような noob でも脳細胞が Hi-Z になったり X になったりすることなく進めました。

これからの作業は殆ど Qsys と普通のエディタで行います。 Quartus II はビルド（Analysis & Synthesis, Place & Route, Fitting) と死んで再起動くらいしかしません。

なぜここで GHRD を必要とするかはここまででお解りと思います。
このリファレンスデザインを Qsys でカスタマイズしたり、外部に設計した回路に繋げることでシステムを実装していくわけです。
どれを IP にしてくっつけるか、どれを外部に引き出すかは任意です。

SDRAM Controller のインターフェイスを取り出す

soc_system の hps_0 というインスタンスに結線されている f2h_sdram_data というのが SDRAM Controller のインターフェイスです。
これは信号の種類を見れば解る通り Avalon MM Slave のインターフェイスの形をしております。
hps_0 というインスタンス（下位回路への結線）は、ソフト的にいうと複数のインターフェイスを多重継承したようなイメージですね。
飽くまでこれはイメージで、実際には各信号ごとに wire が結線されております。

Qsys を使ってリファレンスデザインをカスタマイズしていくと書きましたが、 IP を変更すると毎回 "Generate HDL" を実行せねばならず、そこそこ時間がかかってしまいます。
ここはこのインターフェイスを外部に引き出して、 IP の外にある helio_ghrd_top.v で回路を実装したほうがよいでしょう。

helio_ghrd_top.v からは hps_0 の上位回路である soc_system しか見えません。
まずは hps_0 の f2h_sdram_data を soc_system に引き出さねばなりません。
普通の FPGA であればピンに出ているのですが、 SoC では外部といっても内部です。 ピンが出ているとは限りません。
このへんは Qsys を使い慣れていなければわからないので、身近なハード屋さんに助けてもらいました。
引き出したいインターフェイスを右クリックして "Export as" を選べばオッケーのようです。

Export できた！

hps_0 の上のほう、 f2h_sdram0_data の左側がタグのようになっています。これが外部に引き出せた状況です。
各カラムは左から Name, Description, Export name, Associate Clock となっております。
Export の column にある名前で上位回路に自動的に結線されます。
典型的には、

(接続先インスタンス名)_(信号名) 

という名前になるようですね。

バス幅の決定と HDL の再生成

それから hps_0 を右クリックして "Edit" を選ぶと、プロパティシートから細かい設定を変更できます。
デフォルトは f2h_sdram_data のバス幅として 256bit が設定されています。
メモリのデータバスは 16+16bit で 32bit なので、まずはデータバスに合わせておこうと32 に変更します。
そして Generate HDL を再度行います。
この場合はこうなりました。

        input  wire [29:0]  hps_0_f2h_sdram0_data_address,
        input  wire [7:0]   hps_0_f2h_sdram0_data_burstcount,
        output wire         hps_0_f2h_sdram0_data_waitrequest,
        output wire [31:0] hps_0_f2h_sdram0_data_readdata,
        output wire         hps_0_f2h_sdram0_data_readdatavalid,
        input  wire         hps_0_f2h_sdram0_data_read,
        input  wire [31:0] hps_0_f2h_sdram0_data_writedata,
        input  wire [3:0]  hps_0_f2h_sdram0_data_byteenable,
        input  wire         hps_0_f2h_sdram0_data_write,

あとはこれに対して Master となる回路を書けばメモリのアクセスが可能になります。

ところで、元々 f2h_sdram0_data はどこに繋がっているのでしょうか。
Export すればこのインターフェイスを外から使えるようになりますが、それだけでは元々ここに繋がっていた回路は使えなくなってしまいます。
f2sdram_only_master に繋がっているのは Qsys 上でも確認できますが、この副作用を看過できるかどうかは f2sdram_only_master の先を注意深く調べる必要があります。
調べてみたところ、これは幾つかの FIFO を経由して JTAG に繋がっていました。
JTAG からのリクエストを非同期で処理するための回路のようです。
SDRAM Controller はこれを調停可能なはずですが、今回は華麗にカットしました。

Master の回路を書く

Avalon MM の仕様書より、タイミングチャートを調べて実装します。
メモリアクセスの方法は、基本的な同期 RW 以外にもパイプラインリード、バースト転送などがありますが、今回はまず基本的なライトだけを実装します。

Figure 3-3: Read and Write Transfers with Waitrequest の右半分がそれです。

言葉で説明すると、

a. (Master が)パラメータを設定して Write を立てると
b. ビジー状態を示す WaitRequest が(Slave によって) 1 にドライブされ、
c. 書き込みが完了すると (Slave によって) WaitRequest が 0 にドライブされるので、
d. (Master は)パラメータは次のクロックの立ち上がりまでは保持し続けること

ということです。
今度は W と R がゲシュタルト崩壊しそうなので WaitRequest は Busy と読み替えたほうがいいかも知れません。
Write を立てるときには WaitRequest は(あと当然 Write も) 0 でなければいけません。
書き込みのパラメータはアドレス、書き込みマスク(byteenable)、書き込むデータの三つです。
これらパラメータが設定されるのは Write と同時かそれ以前で、クロック同期である必要はありません。（書き込みデータだけは WaitRequest が立つ瞬間まで遅延できるようです）
今回はバーストライトではないので burstcount は 1 のままにします。

byteenable はかなり使い手のあるパラメータで、実際に書き込むバイトを自由に設定できます。バイト同士が連続である必要も、popcount が 2^n でなければならないといった制約もありません。

1 ワードのデータを書き込むだけならただの組み合わせ回路でもできるのですが、やはり沢山書いてみたいので少し凝りましょう。
WaitRequest と書き込み信号をイベントとしたクロック同期する FSM を中心に構成しましょう。
そうしておくことで、連続したリクエストに対しても d の制約を満たすことができます。

メモリレイアウトを考える

回路の構成には関係ありませんが FPGA と HPS で物理アドレスを配分しなければいけません。
しなくてもいいのですが、現時点でバッティングしてよいことは何もありませんのでとりあえず 512MB ずつ半分にして HPS には 0x000000000-0x1fffffff, FPGA には 0x20000000-0x3fffffff としておきましょう。
これは完全に自由にできるわけではありません。FPGA 側がハイアドレスを使うことは決まっていますし、アドレス空間の最上位 1GB の空間は予約されています。
詳細は Device Handbook Volume 3: 9-11 Boot ROM Mapping をご覧ください。
そんなに情熱を注ぐところでもないです。

HPS 側で物理メモリを制限するためには、 Linux の boot に UART で割り込んで抑制し、 代わりに上がってくる SOPC shell 上で editenv コマンドを使って mmcboot 環境変数に書き込めばよいです。
言葉で書くとなんか大変そうに見えますが EFI shell とか EPROM shell みたいなもんです。
こちらの blog の JTAG を使って DDR3 をシェアする記事が大変大変参考になります。

出来上がった回路はこうなりました。
なんか色々怪しいですが。

https://github.com/roentgen/sdram_helio/blob/master/helio_ghrd_top.v

CPU 向けのインターフェイスを用意する

起動したらずっとメモリに書き込み続ける回路ならば不要なのですが、それはちょっと熱や消費電力（それから精神衛生面）に優しくないので、 ARM 上で動くプログラムからメモリの書き込みと停止をコントロールできるようにしましょう。

CPU とのインターフェイスは、今や SDRAM さえ使用可能ですが、最もお気楽な方法としては MemoryMapped-IO があります(以下 MMIO)。
今回はハードウェアらしく MMIO を使います。

MMIO は、CPU からコントロールレジスタが見えないようなデバイスを扱うのにとても歴史がある方法で、個人的にも古い友人のような感慨があります。
この方法では物理アドレスの一部を予約し、そこに対する CPU からのアクセスを（メモリではなく）外部バスにリダイレクトするのです。
リダイレクト先は（典型的には） FPGA のレジスタになります。

……と、理論上は簡単なのですが、 Altera SoC におけるここの実装は相当に複雑です。
Device Handbook Volume3: 8-3 HPS-FPGA Bridges Block Diagram and System Integration の Figure 8-1 をご覧くださいませ。
HPS->FPGA と FPGA->HPS 二つのブリッジがあるのはわかるのですが、その間に Lightweight HPS-to-FPGA Bridge なるものが介在しています。
これらは AHB/AXI なのですが、にも関わらず soc_system の IP 上見えているのは AvalonMM Slave です。
32bit アクセスだけは lightweight を通って、64bit はネイティブにそれぞれのブリッジ上を通る。 128bit はブリッジ上の FIFO で分割される……という風に読めますがそれにしては AHB の Master/Slave が逆のようにも思いますし、よくわからないです。

よくわからないものの、使い方は非常に簡単です。
一つだけ注意することがありましたが、それだけです。
GHRD にはとてもよいサンプルとして sysid_qsys と led_pio という二つの IP が組み込まれています。

これな

MMIO の物理アドレス 0x10000 からとなっていますが、実際は FGPA ペリフェラルの物理アドレス空間は 0xff200000 からなのでここからのオフセットです。
物理アドレス 0xff210000 がこのレジスタです。
コードも簡単で、ここへのアクセスに対し定数を readdata に突っ込むだけのコードになっています。
インターフェイスは Avalon-MM Slave になります。

ただし、前述した HPS-to-FPGA Peripheral のよくわからないことの一つでよくわからないままなのですが、どうやら注意しなければいけないことがあります。
IP を設計するときは Avalon-MM Slave と思っておいていいのですが Qsys で繋ぐときに h2f_lw_axi_master とも接続しないとこの単純な回路さえ値が見えません。

（実際 sysid_qsys は接続されています）

sysid_qsys を見てみると fpga_only_master の Avalon MM Master に繋ぐだけでなく、 hps0 の h2f_lw_axi_master とも接続されています。
インターフェイスには出て来ない AXI を接続しなければいけないとは、記述的にはまったく想像がつかないです。
ですがたしかに HPS-to-FPGA Peripheral のブロック図からすると、ここのブリッジは AXI でのみ繋がっているはずで Avalon ではないはずです。
つまり、バスが AXI であっても Avalon に見せる魔術があるのだろうとは予想されますが、今回枝葉なのであまり詳しくみてません。「へー、なるほどねー」くらいのことです。

lw (Lightweight)なのは MMIO の幅が 32bit だからなのでしょうか。64bit か 128bit のときは別のマスタと接続する必要があるのかも知れませんが、オービターがうまいことやってくれるような気もします。

一方、書き込むほうは led_pio を参考にしたほうがよいでしょう。
有意な writedata があるときだけライトストローブが有効になるようにします。

   assign wr_strobe = chipselect && write;

この wr_strobe を見て内部のレジスタを変更するようにすればよいです。
state_splat は 1bit reg, wd は 8bit reg です。 その他、サイクルカウンタに使ったレジスタなどが見えますが、重要なのは state_splat だけです。

   always @(posedge clk or posedge rst) begin
       if (rst == 1) begin
           state_splat = 0;
           wd = 0;
      end
      else if (clk) begin
          if (wr_strobe) begin
              state_splat <= writedata ? 1 : 0;
              wd <= writedata[7:0];
          end
      end
   end
  
   assign readdata[31] = reset_n;
   assign readdata[30] = mem_rst;
   assign readdata[29] = state_splat;
   assign readdata[28:8] = regcc[31:11];
   assign readdata[7:0] = wd;

これを module に仕立て上げ IP として Qsys に追加しましょう。
コードはこちら。
https://github.com/roentgen/sdram_helio/blob/master/mem_sdram_interface.v

具体的な手順は……スクリーンショットを保存しておらずですね……再びこちらの記事がとてもとても参考になります。ありがとうございます。

Qsys は任意の .v を検証し、インターフェイスを明示的に選ばせることで IP として使用可能にします。
(.v はそのまま soc_system/synthesis/submodules/ 以下にコピーされる)
IP として登録するのに clock, reset が超重要です。
これは module の信号リストの順番が結構センシティブですので、信号リスト先頭から clock, reset の順番にしておいたほうが無難のようです。
reset は正論理か負論理かも設定できます(IP をインスタンス化するときにケアされます)。
 
正しく設定しておくと色々ご利益がありそうですが、よくわからんので今回は雑に設定しました。
名前はどうしてこんな長い名前にしてしまったのかと後悔しつつも mem_sdram_interface とし MMIO のベースアドレスは 0x10010 としました。

ちなみに qsys の検証は、簡単なシンタックスチェックが入るだけで合成はしません。
ですのでエラーがあると HDL を生成してからあとで Quartus II で発覚することになります。事前にチェックしときましょうね。面倒だからといって submodules 以下のファイルを直接いじったりしてはいけませんよ（実証済み）。

出来上がりの確認

MMIO で非ゼロを受けて memwrite_master を駆動するシステムができました。
MMIO でゼロが書き込まれるまで、 memwrite_master はアドレスからアドレスまで定数を書き込み続けます。

Qsys ではこうなります。

全体像

一番下の mem_sdram_interface が MMIO の Slave です。
いくつかよぶんな信号線が生えていますが、これは後述するサイクルカウンタの値を設定するためのものです。
memwrite_master は IP にしてないのでここには出ません。

CPU 側のプログラム

とりあえず動かしてみるために、ちょっとしたプログラムを書いて回路をキックします。
MMIO の物理アドレスを指定して mmap し、仮想アドレスに対して 32bit データを書き込むだけです。
1 を書き込むと memwrite_master が動きだし 0 を書くと止まります。
memwrite_master は動き続ける限りあるアドレスの範囲に書き込み続けます。

https://github.com/roentgen/sdram_helio/blob/master/addrmap.cpp

このプログラムは単純に、物理アドレス指定してコントロールレジスタのマップされてる領域と、実際に書き込みが行われる DDR3 上の領域を mmap し、ダンプします。
/dev/mem を open しますので、その権限が必要ですが、全てユーザーランドからコントロールできておりドライバは不要です。
(実際もっとページ属性を細かくコントロールしてやろうとか、カーネルモードでしか触れないレジスタを触ろうとか、 マルチプロセスに対応してやろうとかなるとドライバやカーネルモジュールを作る必要がでてきますが……)

open() システムコールのフラグに O_SYNC を指定しています。
最近のカーネルではこれを立てて /dev/mem を open すると uncached になるらしいです。
(kernel が STRICT_DEVMEM 付きでビルドされてないといけないようですが、たぶんそうなってるでしょう)

サイクルカウンタを実装してパフォーマンスを測定する

これは後付けですが、パフォーマンスを測定するためのサイクルカウンタを実装して、メモリの fill が終わったら fin を上げて自律的にリセットしてサイクルカウンタを MMIO のレジスタに書き込み、 CPU からサイクル数を計測できるようにもしましょう。


この場合のリセットの方法はいろいろあると思いますが、ハードリセットほどは単純でなく自律的にやるのは結構苦労しました。
簡単そうに見えたのですがね、リセット解除しないと次の実行を始められないので。
リセット解除は FSM を別に作るかそもそもワンショットパルスにするべきかはたまた CPU からやったほうがいいのかも知れませんが、この辺はノウハウを溜めないといけないな〜。

ともあれ、満身創痍ですがサイクルの測定はできました。
実行してみると物理アドレス 0x20000000 から 0x2000 * 32bytes の領域に書き込めています。
fin が立ったあと mem_sdram_interface の WE  に間に合わないのかサイクルカウンタが終了時にリセットされてないように見えますが、開始時にリセットされているのでよしとしましょう。

結果

master 側の fpga_clock50 は 50MHz です。
なんと 0x10000 回の 32bit ライトアクセスで 500ms もかかった計算になります。
遅い！！
500KB/s しか出てないじゃないか！
一回のライトリクエストごとに 390 サイクル (7us@50MHz) かかったことになります。
大体 40-50 サイクルじゃないかな〜と思っていたのに……これはちょっと遅過ぎます。

メモリは 200MHz 駆動だけどもコントローラは 50MHz だし、 SDRAM Controller がボトルネックになっているようです。
確かめてみるためにデータレートを上げてみます。

Qsys で HPS のプロパティシートを開き f2sdram0_data のビット幅を 256 に変更します。(32bit にしていた)
デフォルト 256 ですがメモリのデータバスが 32bit だし 256 は厳しかろうと思っていたのですが、メモリバンドネックではなさそうなので 256 で試します。
memwrite_master の wire 幅にも影響があるのでそっちも修正して試してみると……。

結果はトータル 0x061a << 3 カウント。 1 トランザクションあたりのサイクル数は 390 で同じでした。
ただしトランザクション回数が 1/8 になったぶんバスバンドはリニアに向上し 4MB/s 程度出ます。かかった時間も 60msec 程度と大人しめ。
Avalon MM の Master/Slave 間にブリッジが存在しないのであれば、 Multiport SDRAM  Controller のクロックが低過ぎるか、スマートすぎて DDR3 の帯域を生かせないということです。

ただしまだ結論は出せません。
だってメモリコントローラがバスネックになるのじゃ ARM から見ても DDR3 の帯域がでないはずで、じゃあ DDR3 を積む必要なんかないじゃないかということになります。
SDRAM Controller Subsystem の説明ではコントローラへのアクセスは AXI だったはず。

ならば現時点の仮説は

1. Avalon が悪い。 AXI を使え
2. メモリコントローラの実力だ。 バーストモードか DMA を使え
3. GHRD が悪い。 クロックを上げろ

の組み合わせということになります。

なぜ遅いかはまだ解らないにしても、ひとまず実験の結果は出ました。
まとめましょう。

• FPGA と HPS で SDRAM を共有することは（解ってしまえば）簡単だ
• Avalon MM 同期 Write を使ったメモリの書き込み@50MHz ではメモリの帯域が出せない(256bit でも 2MB/s が上限)
• ライトトランザクションにはデータ幅によらず 390 サイクル, 7us@50MHz かかる

以上となりました。

Altera SoC 開発ボード Helio

一時期、なんか上司氏と顔を合わせるたびに「VHDL 書ける？」と聞かれていたのですよ。月刊インターフェイスの読者であった僕は勿論それがどういうものかは大体知っているけど上司に向かって「書けます」というのは純粋な嘘になるので

「知りません、書けません」

と逃げ回っていたのです。
ところが最近身近で FPGA ブームが起きていまして、 DE1 を買って来たのです。
DE1 は低価格で Sound DAC や DSUB を備えた楽しいボードなのですが、気軽に使える IO はプッシュボタンと 7SEG と LED くらいなので LED 光らせる(いわゆる L チカ)などラボの講義を終えたくらいで止まっておりました。
(だっていきなり音とか出したら耳ぶっ壊れそうだし、 DSUB のモニターなんかもうないよ……)
ところが最近よいものが DE1 の価格帯で売っていると聞きました。



Altera SoC Cyclone V の評価ボード Helio です。
CycloneV はデュアルコア ARM SoC に FPGA fabric をオンダイに搭載したものです。
FPGA として見ても、 DE1 の Cyclone II から見ればとても豪華なものです。
Helio ボード上には UART, JTAG, USB Blaster, Ethernet, DDR3, USB(OTG), MMC が実装されており、すぐ MMC で Linux をブートして LAN 上に見ることができます。

Ethernet, DDR3 は説明不要でしょう. UART はシリアルポート, JTAG はデバッグインターフェイス, USB Blaster は FPGA の再構成デバイス, USB(OTG) は Host にもなれる USB コントローラー、 MMC はマルチメディアカードです。
どれも実績と人気のあるパーツでまとまっております。
HDMI や DVI がないくらいです。

Helio のメインコンポネント

さて、ところが FPGA fabric を搭載した ARM なんて使ったことがありません。
例えば ARM はメモリを混成しておらず、ボード上の DDR3 を使いますが、 FPGA から DDR3 を使えるのでしょうか。
FPGA からはどのバスで DDR3 を叩くのがベストな方法でしょうか。

ここでは FPGA から DDR3 に書き込んで ARM から読むのを目標に、 Cyclone V のアーキテクチャを見ていこうと思います。

準備編

Linux の起動

とりあえず Helio ボード上で Linux くらい起動していなければ話になりません。
Helio の開発元である rocketboards のサイトに丁寧な Getting Start Guide がありますのでそれを見て行ってください。
Helio には SD カードが付属していますが漢のブランクであります。
ラズベリなんかだとちょっとお金を払うだけで u-boots で起動する Linux のイメージを焼いたものが付属しますが、イメージは rocketboards に各種ありますので好きなものをダウンロードして dd で焼きます。
一番シンプルなものでも httpd,sshd くらいは動いてくれます。これで充分でしょう。
起動すると DHCP で勝手に IP アドレスを取得します。

UART は Linux の起動に割り込むのに必要ですので常時繋いでおきます。
FPGA の再構成に使うケーブルも繋いでおいたほうがいいので、二本は必要ですね。
なくても Linux のブートくらいはできますが(ありがちな話ですが) UART は IP アドレスを確認するのにも必要です。

Helio では、何かがバグっているものか起動するたびに MAC アドレスが変わってしまいます。
このためルーターで IP を指定することもできません。会社で使うにはトラブルの元でしょう。
しかもブロードキャストに応答しないので、真っ先に static にしておきましょう。

開発環境

ソフトの人向けに、まず開発環境とワークフローについて書いておきます。
Parallels9 for Mac + Ubuntu13.04 の環境に Quartus II 14.1 web edition  を入れて使っています。
Quartus II は Altera によるいわゆる IDE で論理合成、配置配線といったソフトでいうところのビルドを行います。
Cyclone II などの古い FPGA は Quartus II 14.0 以降サポートを切られていますが、 Cyclone V では Quartus II 14.1 を使いましょう。
v14 以降は　64bit サポートもしています。(シミュレータである ModelSim は 64bit 対応ですがインストーラが 32bit というクソです)
詳しくは後述しますが Quartus II よりはその付属の Qsys というツールをよく使います。

Qsys はかつて SoC Builder と呼ばれていたソフトで、ハードウェアの情報から IP (ソフトでいうライブラリみたいなもの）をカスタムした一つの大きな回路とそのインターフェイスを生成するものです。
cmake みたいなもの……といえばいいでしょうか。
IP というと「高そう」とか思ってしまいますが、後述する GHRD というリファレンスデザインが既に IP として提供されています。

シミュレーションには敢えて ModelSim を使わず GHDL や icarus verilog を使っています。
GHDL は幸せでしたがこれは VHDL 用ですんで icarus verilog にしました。

ARM コア用にはツールチェインが提供されていますが、普通に arm-eabi 用の gcc を使うことにします。
(VM で clang ビルドしたら三日四日かかってもリンクが終わらなかったのでいったん諦めました)

ちなみに Quartus II は安定しているときは安定していますが、死ぬときは 10 分で死にます。
調べてみると Talkback を OFF にしていても定期的に CDN に https で何かのリクエストを送っており、これがタイムアウトすると割り込みハンドラの中で死んでいます。
場合によってこのリクエストは一度も発行されない状態で起動することもあるので、その場合は安定します。二度と終了しないでください。
あとアメリカが寝ている、日本時間の昼間には安定しています。
会社から帰って来て夜中に起動すると大体時間を無駄にすることになるので、「なるべく昼間にやる」「安定したら二度と終了しない」ルールで運用しています。

さてフローは、 Quartus II で .sof などのネットリストのファイルを生成し、 Programer という何とも漠然とした名前のツールでそれを FPGA に焼き、ボードの動きを確認することが目的になります。ボードには WARM/COLD のリセットボタンが付いていますが、これはどうやら HPS 側であって FPGA 側は焼いた時にリセットが走っているっぽいので、やらなくてもいいです。
（HPS 側をリセットしても FPGA 側のリセット信号は動きません。よくできている）
.sof は揮発性なので電源スイッチでハードオフすると飛んじゃいます。開発時には便利です。

Programmer は onboard USB Blaster を使って FPGA を再構成します。
Parallels9 for Mac ではゲスト OS の Ubuntu 側で USB Blaster の認識が安定しませんでした。(20 回に一回くらい？)
しかし VM の設定で USB3.0 サポートを切るとすんなり認識するようになりました。
Altera のドキュメント通り udev だけ設定しておけばドライバは不要です。
UART も伝統の FTDI 互換ですので(Linux では)ドライバ不要です。 Mac OSX でも marverics なら不要のはず。うちのは違うので知りませんが Arduino はドライバ不要でいけたのにこれはちょっとダメそうでした。

Quartus II でコンパイル(正確には論理合成)するソースは好きなエディタで書いてかまいませんが、 Qsys が生成する HDL は再度上書きされる可能性があります(標準では soc_system ディレクトリ以下に生成される)。
このへんは Qsys を使うときにまた詳しく書きます。
回路の HDL を書いたら(シミュレーション用のテストベンチも書いて)シミュレータで波形を見ましょう。
僕は icarus verilog と GHDL, gtkwave を使っています。
これらのシミュレータは論理合成をしてくれません。従って、シミュレータでは動いても、論理合成不可能な回路を書いている可能性があります。
その場合 Quartus II でエラーが発見されるので TAT が長くつらいです。

icarus verilog 0.9 では -S を付けてコンパイルすると論理合成を試します。この機能は開発中のようですが、シミュレーションできるが論理合成できない記述を発見するには大変役立ちました。

HPS

HPS とは Hard Processor System (再プログラム不可能なプロセッサとそのシステム)のことで、おそらくはこれは Altera の言葉と思います(Soft Processor ありきの言葉なのでね)。
ここでは、要するに ARM 側のシステムのことです。 ARM の MPU コア以外にも L3 インターコネクトや AXI が含まれます。
Altera が決めてないことは全部 HPS だと思っていいのではないでしょうか。 ARM を主体に見ると軒先を貸して母屋に変な名前を付けられたように見えるかもですが、 ARM はそもそも IP で売ってるものですし、土地は元々 FPGA のものだっりします(今回 HPS の家屋を造り直すことはできませんが)。
これはドキュメントじゅうに現れる言葉ですので、何が何でも最初に覚えておかねばなりません。

本記事で主に扱うのは FPGA 側と ARM 側のやりとりの方法でありますから、これは即ち HPS Subsystem の使い方であるわけです。

HPS SDRAM Controller Subsystem

Cyclone V のマニュアル(の一部. Book3)より https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cyclone-v/cv_5v4.pdf "HPS SDRAM Controller Subsystem" の章、 Figure.11 がまさしく求める情報です。

Altera SoC Cyclone V の全容

右側の赤丸を付けたコンポネント、これがメモリコントローラです。
L2 キャッシュを経由せずに L3 インターコネクトから接続されていますので、ほぼ全コンポネントからこのメモリコントローラにアクセスすることができます。
FPGA fabric から直接このコントローラを叩くには FPGA-to-HPS SDRAM というのがヒントになるようです。

当然ながら——このレベルの混同はないと思いますが念のため断っておくと、ここでいうメモリコントローラは飽くまでメモリモジュールを制御するコントローラで、 MMU は含みません。
ARM の、ちょっと特殊な MMU はコア側に実装されております。つまり、物理アドレスが必要です。

FPGA-to-HPS SDRAM のインターフェイスについて更に調べていきます。
Figure.11-1 SDRAM Controller Subsystem High-Level Block Diagram によるとこの部分についての詳細が記述されています。

32-256bit の AXI か Avalon-MM を使って SDRAM Controller を制御できそうです。（ちなみに、 External Memory へ繋がる DDR PHY から HPS I/O Pins というバスは FPGA を経由しておりまして、メモリを好きなようにできそうです。ただそれをやってしまうと ARM 側が困ってしまうので、やりません）

AXI は ARM の定義する AMBA 第三世代か第四世代のバスアーキテクチャだったはず(うろ覚え)ですが、 Avalon-MM というのはあまり耳馴染みがありません。
Avalon, Altera, ARM, AXI, AMBA, AHB …… A から始まる用語がゲシュタルト崩壊しそうです。電話帳かよ！！
これは Altera が定義するインターフェイスのようで、使い方は簡単です。

仕様はこちらにございました。
https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/manual/mnl_avalon_spec.pdf

シンプルな Master/Slave のアーキテクチャで、実際のバスアーキテクチャは任意に選ぶことができる……というようなものだった気がします。
SDRAM Controller に関しては直接繋がってるようなのであまり気にしませんでした。
データのリードライトを要求する側が Master で、物理的なレジスタやメモリにアクセスしてデータを提供するのが Slave です。

従って、この Avalon MM の Master を実装するのが今回の目的です。
実際の作業を始めましょう。

……ところがここまでで非常に長くなってしまったので、作業編は次の記事に回します。
つづく。

すごい erlang のすごさがチョットワカルくらいまで学ぶ。できればゆかいに。

昨日、というか今朝方書き上がったエントリで大枠程度は書けたと思うのですが、バイナリのマッチまでメモって力つきており、あまり実用的な機能に触れられていませんでした。
もう少し学んだところをメモっておかねば消化不良です。

ビット操作

ビット列の生成とマッチングまでは前回メモってあるけども、それだけではパーサーは（大体）書けません。

バイナリの生成いろいろ

バイナリの生成について細かい規則は、公式のここにかなりしっかり書かれているので迷うところは実際少なかったです。
唯一迷ったのは "The Erlang Type Language"  という章に書かれた、バイナリの一般式は <<_:M, _:_*N>> であり他のは省略系だとあったところです。
これが頭の片隅に残っていたので試したところ、 <<1:8, 0:32*8>> などと食わすと無情なシンタックスエラーであります。
他に合わせて << SegList >> とか書けばいいのに……と思ったのですが、これは　Erlang の組み込み型を定義する上での記法の記法であり、 Erlang の文法ではありません。

バイナリかビット列か

組み込み型 bitstring は 1 ビットの列です。
 <<1:3>> は 2 進でいう 001です、
組み込み型 binary は 8bits 境界に並んだビット列です。生成時、 <<1>> とビット幅を指定しなければこれは /binary になります。ビット列でいうと　<<1:8>> です。
両者は、組み込み型としては別ですが、前項で確認したように組み込み型はあくまで erlang にとっては（ユーザープログラムよりも）事前定義された型に過ぎず、ユーザー定義型と違いはありません。

ならばビット列を使って、わざと 8bits 境界にマッチするようなバイナリを作ったら、それは bitstring と binary のどちらにマッチするのでしょうか。

bytes(<<B/binary>>)->
    io:fwrite("binary B:~w\n", [B]);
bytes(<<B/bitstring>>)->
    io:fwrite("bitstring B:~w\n", [B]).

321> test:bytes(<<0>>).
binary B:<<0>>

322> test:bytes(<<0:7, 0:2>>).
bitstring B:<<0,0:1>>

324> test:bytes(<<0:9>>).
bitstring B:<<0,0:1>>

326> test:bytes(<<0:8>>).
binary B:<<0>>

327> test:bytes(<<1:1, 1:7>>).
binary B:<<129>>

328> test:bytes(<<1:1, 1:7, 1:1>>).
bitstring B:<<129,1:1>>

329> test:bytes(<<0, 0>>).
binary B:<<0,0>>

330> test:bytes(<<0, 1:1, 1:7>>).
binary B:<<0,129>>

332> test:bytes(<<0:4, 0:5, 1:6, 1:1>>).
binary B:<<0,3>>

全体の長さが  8bits アラインであれば、各セグメントのアラインがどうであっても、 binary にマッチするようです。

ビットの展開

バイナリ内からマッチした部分で引数に拘束される値はどうなるでしょうか。
上位 7bit を取り出してみます。

rst(<<R:7, _:1>>)->
    io:fwrite("R:~w\n", [R]).

341> test:rst(<<128>>).
R:64
ok
342> test:rst(<<255>>).
R:127
ok

なるほど。ビット列からそのまま射影されるのでなく、論理右シフトされるのですね。
算術シフトではありませんから符号には注意が要りそうです。
ん……本当？ 型修飾には signed/unsigned を書けたはず。そう思って試してみると……

rst(<<R:7/signed, _:1>>)->
    io:fwrite("R:~w\n", [R]).

344> test:rst(<<255>>).
R:-1
ok
345> test:rst(<<128>>).
R:-64
ok

おー、算術シフトになった！
ちなみにデフォルトは unsigned だと仕様にも書かれておりました。
型修飾リストにはエンディアンも書けるようです（デフォルト:big）。
すげえ！！

バイナリのトラバース

公式のドキュメントを参考に、ビット列全体の処理の取り扱いについて調べました。
4.7 Appending to a Binary です。このセクションではごく短い例を挙げています。

繰り返し処理

このコンテキストで書くのも急というか、本来昨日のエントリに書いておいて然るべき内容でありますので、ここでは簡単にしか触れませんが、実のところ erlang にはループがありません。
再帰を使いましょう。昔の Lisp なんかの関数型や、テンプレートメタプログラミングと一緒です。
与えられたリストの中から最下位ビットだけを取り出して、第二引数の binary に追加したものを構築する append_bin() を考えます。

[] はリストです。 car/cdr といったリスト操作を明示的に呼び出す代わりにパターンマッチ [CAR|CDR] を使用します。これは variadic template と同じですね。
この場合は、再帰の終端は append_bin([], Acc) -> Acc. であり、 CDR が空になるとこちらにマッチするので Acc がそのまま返ります。
末尾再帰ですので、この場合は C++ 同様に暗黙にループによる最適化が期待できそうです。

lsb_of(<<_:7, LSB:1>>) -> LSB.

append_bin([CAR|CDR], Acc) ->
    LSB = lsb_of(<<CAR>>),
    append_bin(CDR, <<Acc/binary, LSB>>);
append_bin([], Acc) ->
    Acc.

Acc というのは再帰ステップを通じて与えられる任意の変数ですが、 erlang においてはアキュムレータという名前で親しまれているようです。

379> test:append_bin([1, 2, 3, 4, 5], <<>>).
<<1,0,1,0,1>>

奇数,偶数,奇数,... なのでこれで大丈夫のようです。
結果はバイナリ binary であります。 bitstring に詰め込む場合はもっと簡単で、

append_bin([CAR|CDR], Acc) ->
    append_bin(CDR, <<Acc/bitstring, CAR:1>>);
append_bin([], Acc) ->
    Acc.

だけでよく、 LSB を取り出す操作を関数にする必要さえありません。
ドキュメントによると、最近のバージョン(R12B)から再帰ステップ間の Acc はコピーされなくなっていて効率的になったとあります。意図的に参照を用いる必要はないようです。素晴らしいですね。

非常に美しく書けましたが、不満はあります。
ビット列のトラバースがしたかったのに、いつの間にかリストのトラバースの話になっていた！
再帰の話が混じったので一度リストにしましたが、バイナリを受けるバージョンはもっと簡単になります。

append_bin(<<CAR:8, CDR/binary>>, Acc) ->
    append_bin(CDR, <<Acc/bitstring, CAR:1>>);
append_bin(<<>>, Acc) ->
    Acc.

406> test:append_bin(<<1, 2, 3, 4, 5>>, <<>>).
<<21:5>>

うーん、良い……。

チャンクの扱い

erlang で扱うバイナリはかなり良いことが解ってきましたが、さすがにこれで何百 MB もあるバイナリを扱ってよいかどうか気になります。
上の例では末尾再帰に出来ましたが、そうでない場合はスタックが延々と伸びて行ってしまいます。
できれば適当なチャンクに区切って処理したい。
そういうときは標準ライブラリ (stdlib ではなく kernel) を使いましょう。
file:open() して開いた FD に対してシーク位置を指定した file:pread() すればいいっぽいですが、パフォーマンスについては Performance のセクションにかなり長めの警告が書かれています。
これは言い換えれば、 read()/write() には恐らくライブラリレベルのバッファが存在しないようで、アプリケーションが自分でバッファを作る必要がある。
ストリームリードならさほど気にしなくていい場合が多いでしょうが、この辺はケースバイケースです。
他にも open 時に指定出来る mode によって、遅延書き込みや先読みを有効にさせてシステムコールの削減、スループット向上を期待できそうです。
一通り似たライブラリがありながらも C/C++ の標準ライブラリとはかなり思想が違うなという印象です。

データ構造

erlang のデータはリスト、タプル、マップと人気のあるものは一通り揃えている感じがあって素敵ですが、馴染みのある構造体も使いたいです。
バイナリをパースしたらそれを馴染みのある構造体に入れて取り回したいというのは自然な欲求なのではないでしょうか。
タプルでもいいけどオブジェクトに名前が欲しい……。タプルでもリストでも、 {X=0, Y=1, Z=2} という風に各要素に名前を付けられるけど、同じ構造のタプルを複数扱うとき大変。
レコードを使えばよいようです。

-record(Name, {Field1 [= Value1],
               ...
               FieldN [= ValueN]}).

レコードの定義はやや仰々しく、 -record ディレクティブを使ってコンパイラに示す必要があります。

インスタンス化

#Name{Field1=Expr1,...,FieldK=ExprK}

T = #rec{x, y, z}.

などとして使います。名前付きタプルという感じでしょうか。

アクセス

Expr#Name.Field

Expr はインスタンスで Name はレコード型名、 Field はメンバ名です。
やや気持ちが悪い。オブジェクトの名前を使って各要素にアクセスしたいだけなのにちょっと大袈裟ですね。 erlan shell からアクセスしずらいのも難です。
もっといい方法があるのかも知れませんが……。

まとめ

というわけで、ここ二日で学んだところは概ね以上です。
僕の必要な知識は大体手に入れたのでよしとしましょう。
 

すごい erlang のすごさがわからないくらいまで学ぶ。できればゆかいに。

昨日急に Erlang のコードをいじらなければならなくなりまして。
別にがっつり開発するとかメンテするとか大袈裟な話じゃなく、ちょっと弄ってちょっとの間動かせればいいのです。
目的もバイト列のパーサーだから Erlang らしいスレッドモデルは使わない。
それくらいを目標に、他言語話者が Erlang を学んだところをメモっておきます。

ランタイムや開発環境は brew install erlang で一発です。
パッケージ内には emacs の erlang-mode も入ってますので、

((setq load-path (cons "/usr/local/opt/erlang/lib/erlang/lib/tools-2.6.15/emacs/" load-path))
(setq erlang-root-dir "/usr/local/opt/erlang/")
(setq exec-path (cons "/usr/local/opt/erlang/bin/" exec-path))
(require 'erlang-start))

と書いたら ok.
C-c C-k でコンパイル、 erlang シェルの起動まで一発であります。
らくちんらくちん。

文法

Erlang は結構古い言語で 86 年登場だそうなので C++ と同世代くらいでしょうか。
しかしながら文法はかなりモダンな機能が多く、かと思えば全然モダンじゃないところもあってアクセルを踏んだりエンストするような感じもあり、乗り物酔いしそうです。

他の言語であれば、一つの文は 式; でブロックは { 文 ... } で……みたいな大枠から説明できるのですが、 Erlang の文は文脈依存の構文が多く、なんとも一言では説明できません。
もっとも原始的な文を

Expr.

と言うことはできるですが、多くの手続き型言語がこれの列挙をする文法なのに対し、 Erlang はこれだけ解ってもどうにもならない文法だと思います。
……といってもなかなか伝わらないと思うので、僕の見た厄介な例に目線を合わせる意味で、こんな例を書いておきます。

-module(test).
-export([func/2]).

func({A, B, C, _} = Tuple, A) when A > 1,
            B > 1;
            C > 1 ->
    io:fwrite("func({A,B,C,_}, A)\n"),
    case A of 2 when B > 2 ->
        io:fwrite("Tuple = ~w\n", [Tuple])
    end;
func({A, B, C, _}, _) ->
    io:fwrite("func({A,B,C, _}, _)\n").

手続き型か、いや関数型プログラミング言語か……というよりどことなく BNF 記法による構文解析を思い出します。
なんとなく見てわかるところと、解らないところがあると思います。

解るところは:

• test モジュールと関数 func が定義されている
• 関数は複数定義され、　template の特殊化のように動くようだ
• 特殊化は when 条件式によっても細かく制御できるようだ
• {} は何らかの無名構造体を構成するようだ
• io:fwrite() は printf() のようなものだ

C++11 の variadic template はお気に入りの機能で、記述が冗長なことを除けばこれを（大枠では）すんなり理解できると思います。
パッと見、疑問に思うところは

• 文末の記号があったりなかったり、複数の種類があるのは何なの？
• . (dot) が文末なのに、本体のコードではたった一回しか登場しないじゃん
• -> と ; の厳密な定義は何？
• ; の定義によっては二つ目の func は一つ目の func の中に定義されているようにも見えそうだけど、どうなるの？
• 一つ目の func({A, B, C, _} = Tuple, A) は特殊バージョンにとしては二つ目の func とあまり違わないように見えるが、パターンマッチが動くのだろうか？
• when の条件式が複数あるけどこれはどう評価されるの？
• case も when も条件分岐だと思うけど、二つあるのは何なの？
• if じゃダメなの？
• = は何なの？

ということでしょうか。
これらの疑問には、個別の解説を読むより公式のドキュメントが一番わかりやすく答えてくれました。

関数の宣言は関数節の集合

公式ドキュメントによる仕様をみてみましょう。

• 関数宣言はセミコロンに区切られた関数節からなり、 .(dot) で終端する
• 関数節は節頭と節本体を -> で繋いだもの
• 関数節本体は一つ以上のカンマで区切られた式からなる

と書かれています。
つまり、下記は全体で一つの関数 Name の宣言であると言えます。
一つ一つが関数節であり、下線部は各関数節の頭です。関数節はそれぞれセミコロンで区切られ、.(dot) で終端します。
下の構文は公式ドキュメントのものですが、関数節が一つの場合はセミコロンで終端しそうに見えますが、 関数宣言は . で終端すると定義されているのでまぁ、文章で書かれた定義のほうに従うようです。

Name(Pattern11,...,Pattern1N) [when GuardSeq1] ->
    Body1;
...;
Name(PatternK1,...,PatternKN) [when GuardSeqK] ->
    BodyK.

各節は構文解析器のノードと一緒です。全ての引数についてパターンがマッチし when 節が還元すれば、その関数が還元します。呼ばれるわけです。
variadic なテンプレート引数展開や特殊化はまず汎用版を宣言してから特殊バージョンを宣言しますが、この場合は逆であり、節ごとに緩くしていきます。
when シークエンスからなる（ガード節というらしい）は省略可能です。
関数節頭の () 内は、仮引数リストというよりパターンであることは予想通りですが、仮引数リストのようにも機能します。
引数の数をアリティと呼び、アリティが違えば別の関数とされるのは他の言語と一緒です。
上の、 func 関数の場合は引数は 2 個で、フルネームは test:func/2 であります。
パターンとは項ですが、未拘束変数が許されています。
詳しくは後述しますが、ここでは C++ の人に解りやすいパターンの例をあげておきます。
func/2 は未拘束変数 A を持ち、第二引数の値によって特殊化……のように動きます。

func(A, 0) -> io:fwrite("zero\n");

func(A, 1) -> io:fwrite("one\n");
func(A, 2) -> io:fwrite("two\n");
func(A, _) -> io:fwrite("other\n").

when 節

続いて when 節を見てみましょう。
ここでいう when 節とは when GuardSeq で表現される節です。
ここはドキュメントで明示されるまでは信じられないような仕様でありまして、

• カンマで区切られたガード式の集合がガードである

• セミコロンで区切られたガードの集合がガードシーケンスである

とされています。
いやまぁ、　C/C++ だってカンマ演算子を使ってギョッとするようなコードを書くことはできますが、仕様でこう書かれてしまうと「アアア……」となってしまいます。

違いは、ガードは全部評価され全部が true にならなければなりません。ガードシーケンスは順番に評価されて true になればシーケンス全体が還元します。  

ガード式とは、 Erlang の式ですが、全部使えるわけではなく、副作用のあるようなことはできません。
引数リストはパターンでなければならないので、 式は書けません。
仕様では"a subset of the set of valid Erlang expressions" と表現されております。
副作用がないのだから、ガードシーケンスやガードの残りの式は評価されない(will not)ようです。
大体 C++ の条件式の評価と同じですが、この辺は評価が決まっている C++ とは違いますね。

ちなみに、ある解説によるとセミコロンは orelse 演算子の意味とありましたので、ガード節においてはセミコロンは演算子であると考えたほうが意味的には合っていると思います。しかし文法上はセミコロンで区切られていると明示されているので、演算子であるという理解だと無理があるように思います。
僕はそっちの解説を先に読んでしまったので激しく混乱しましたが……。

以上のことを頭に入れて when 節をもう一度よーく見てみましょう。
さっきも書きましたが、引数リストはパターンしか書けません。ガードには式が書けます。

func({A, B, C, _} = Tuple, A) when A > 1,
            B > 1;
            C > 1 ->

これは要するに (A > 1 && B > 1) || C > 1 と解釈できます。
これが true ならこの関数が呼ばれます。

パターンとマッチとパターンマッチと式

さて、 Erlang に特徴的なことのうち、難しい文法の話も大詰めでります。
ここまでナアナアにしていた関数の引数リストを理解しなければなりません。
ちなみに、 {} はタプルの宣言で、変数は大文字で始まらなければなりません。

({A, B, C, _} = Tuple, A)

引数リストはパターンの列挙だということを理解しても尚、上の例には首を捻るところがあります。

• タプル中の A と第二引数 A の関係は？
• = は式なのではないのか？

仕様では、パターンは項と同じように表現される構造体であるが、未拘束の名前を使ってもよいとあります。
すなわち、 A とか B といった名前が宣言なしでそこに登場することは問題ありません。
引数は {A, B, C, _} などに拘束されるわけです。（_ は無名オブジェクト）
{A, B, C, _} = Tuple のほうも同様で = はマッチ演算子とされますが、パターン中に現れることを許されております。

マッチ演算子を使って評価を行うことをパターンマッチングと呼びますが、パターンマッチングに成功すると右辺の項を左辺のパターンに拘束します。例えばこうです。

X = 1.
1 = X.

X を 1 に拘束します。一度拘束してしまえば、 1 = X も同じです。右辺が評価可能な項であり、 1 もパターンであるからです。
X=1 は何度も評価できますが、一度拘束してしまえば X=2 は拘束できなくなります。
(erlang shell においては f(X). とすれば X は未拘束になり、再度拘束できるようになります）
これは X が const になってしまうのではなく、エラーメッセージによると「X と 2 はマッチしません」という、要するに X=n. というのは正確には、マッチを使って拘束していた、ということになります。
この仕組みで、引数リストはマッチをしつつ未拘束変数に実引数を拘束している、と思われます。
通常、パターンマッチでは右辺は項でなければならず、未拘束変数は項とはならないっぽいです（本当？）が、パターンであれば未拘束変数が許されます（これは本当）。
関数頭の宣言は (Patterns...) とありますので、パターンであることが明白なので、マッチの右辺も常にパターンであると見做され、右辺に未拘束変数が来ることを許されているのかなぁと思いますが……書いてて全然信じられませんね。自分でも何言ってんだろうこの人と思います。
実際、引数リストに = (マッチ演算子)を使ってマッチしつつ拘束を行う場合、 {} = Tuple と Tuple = {} は等価であります。それどころか Tuple = ({} = Tuple1) とかでもいけます。
なぜ解り難いほうを使って例にしたのかというと、公式ドキュメントの例ではこの順番だったからです。僕の見ていたソースでも全部 {} = Tuple のほうでした。

パターンマッチングでは基本は Pattern = Term です。
引数リストにおいてはなぜか Pattern = Pattern です。
右辺はパターンでない限り、未拘束変数はエラーになってしまいます。その代わり、右辺の評価を使って関数呼び出しなどができます。

Ret = func().

という、ごくありふれたあれですね。


さて、パターンマッチングを使って引数を拘束することは解りました。
この関数が呼ばれたということは、全てのパターンマッチングが成功したということですので、全変数が拘束済みであります。

ここまでで大体明確になったと思いますが変数 A はたった一度拘束されるので、関数呼び出しの時に何度評価されても、矛盾がおきればマッチングは失敗し、その関数は呼ばれなくなります。
erlang のタプルは無名で、オブジェクトの名前をつけないでアクセスするので、タプル中の A と第二引数の A は同じ名前でアクセスされます。
従って、タプルの A と第二引数の A は同じでなければマッチングは失敗します。

erlang shell で実際に確かめてみます。
emacs で C-c C-k でコンパイルすると、 erlang shell にモジュールがロードされるっぽいので実行は簡単です。

187> test:func({2, 3, 3, 0}, 2).
func({A,B,C,_}, A)
Tuple = {2,3,3,0}
ok

188> test:func({2, 3, 3, 0}, 5).
func({A,B,C, _}, _)
ok

ちなみにタプルが {A, B, C} がタプルの名前を使わず A, B, C としてアクセスされるなら Tuple という名前は何なのかと思いましたが、タプル全体にアクセスするのにこの名前を使用します。サンプルでは io:fwrite() の引数に使っています。
これは全体にアクセスしたいとき、同じオブジェクトを再構築するのを避けるためのシンタックスシュガーであると仕様にはあります。
更にちなみに、名前付きの、所謂構造体を使う場合は record を使います。
R = #Type { MemberList } で構築されます。アクセスするには R#Type.member という、二日したら多分もう覚えていないであろう変態的文法のようです。型推論あるんだから頼むよ！

case of

大方疑問は解消しましたが、文末の問題についてはまだ一つ気持ち悪いところがあります。
case が -> を還元したあとの終端規則です。予約語 end がいきなり登場してますが、いいんでしょうか。

case Expr of
    Pattern1 [when GuardSeq1] ->
        Body1;
    ...;
    PatternN [when GuardSeqN] ->
        BodyN
end

仕様によると、いいんです。

ああ、何なのこの煩わしい曖昧な書き方は。Pattern が一個しかないときはセミコロン要るの？要らないの？
関数宣言のときもそうだったでしょう。あっちは自然言語で定義が書かれてたけど。
この書き方を素直に解釈するとダメそうに見えるんですけど、試した限り Pattern が一個しかないときはセミコロンあるとダメっぽいです。

パターンにはパターンか定数式しか書けないので、 when ガード節を取ることができます。
待てよ？パターンということは未拘束変数も書けるのだろうか？と試したところ、仕様通り書けました。
しかし未拘束変数とのマッチは失敗するはずだと思いきや、なぜかマッチは成功してしまいました。

foo(A) ->
    case A of UnboundX ->
     io:fwrite("matched to unbound\n");
    0 ->
     io:fwrite("matched to zero")
    end.

212> test:foo(0).
matched to unbound
ok

ok じゃねえよ！！
C++ の default ラベルみたいなことができるように無名オブジェクトを使って _ -> ignored が動くようにしてあるのかなぁ。
それともバグかなぁ。バグだとしてももうこれを直したら死人が出ると思うし、直せないよなぁ。

if 文もありますが if 文との最大の違いは、 case はいずれかのパターンにマッチしなければランタイムエラーとなります。

サンプルで動きを確かめる

上にあげたサンプルは、特に意味はありませんが文法のいやらしい所を満載しており、 erlang shell 上で引数を変えて呼び出すといやらしい動きをします。 

C>1 が false でも A>1, B>1 ならば特殊バージョンが呼ばれる

190> test:func({2, 3, 0, 0}, 2).
func({A,B,C,_}, A)
Tuple = {2,3,0,0}

C>1 も A>1 も false なら特殊バージョンは呼ばれない

231> test:func({0, 2, 0, 0}, 0).
func({A,B,C, _}, _)
ok

そもそもタプルの構造が違えば _ であってもマッチしない

235> test:func({2, 3, 2}, 2).
** exception error: no function clause matching test:func({2,3,2},2)

特殊バージョンが呼ばれる。しかし case Expr of Pattern にマッチしないのでエラー

193> test:func({3, 3, 3, 0}, 3).
func({A,B,C,_}, A)
** exception error: no case clause matching 3

特殊バージョンが呼ばれる。しかし case のガードにマッチしないのでエラー

227> test:func({2, 2, 3, 0}, 2).
func({A,B,C,_}, A)
** exception error: no case clause matching 2

バイナリの扱い

例外や悪夢のような -spec の文法、多彩なライブラリや組み込みデータ型についてはスルーします。
まぁ、大体の文法は解りました。
一番興味があるのは erlang の強力なマッチングはバイナリでどうなるかということです。
もう一晩これを書いてるので、簡単なメモを書いて寝たいです。

バイナリは Bin = <<SegList>> で表現されます。
Bin = <<1:1, 0:7>> ならば 0x80 になります。
Bin = <<1:8>> は 0x01 です。 0xff ではありません。
では Bin = <<1:4, 0:4>> ならば 0x10 ですね。
カンマで区切られたゼロ個以上の各要素を、セグメントと呼びます。
セグメントの完全な表記は Value:Size/Type となっています。

ちなみにサイズの合計は 8 bits の境界に揃っている必要はありませんが、他の型と変換する場合など、当然ながら必要となるシーンはあります。

バイナリのマッチング

MSB というか、 8bit 以上の任意の長さのビット列の一番左のビットにマッチし、続く 7bit を取得し、残りは気にしないという関数 bin を考えます。

bin(<<1:1, R:7, _/bitstring>>)->
    io:fwrite("MSB 1 (rest:~w)\n", [R]);
bin(<<0:1, R:7, _/bitstring>>) ->
    io:fwrite("MSB 0 (rest:~w)\n", [R]);
bin(<<_/bitstring>>) ->
    io:fwrite("unmatched <<_>>\n").

/bitstring という型の指定は重要です。
この例では、8bit 以上の任意の長さのビット列を扱いたいので、ビット列のセグメントがどのように作られたかに依存したくはありません。マッチの場合は、これがないとセグメントの数や長さに依存するようになってしまい、 <<1:1, 0:7, 0:*>> などとして生成されたバイナリにしかマッチしなくなってしまいます。
/bitstring は一つのセグメントについてあればよいようです。

最後の bin(<<_/bitstring>>) は、ビット列の長さが 7bits 以下の場合にここに還元します。

では実際の動きを見てみましょう。

MSB=1 のビット列の場合

273> test:bin(<<128:8>>).
MSB 1 (rest:0)
ok

MSB=0 のビット列の場合

274> test:bin(<<127:8>>).
MSB 0 (rest:127)
ok

セグメントを明示して作ったビット列

268> test:bin(<<1:1, 5:7>>).
MSB 1 (rest:5)
ok

/binary を指定しているので、生成時のセグメントには依存しません。

267> test:bin(<<129:8, 0:128>>).
MSB 1 (rest:1)
ok
271> test:bin(<<129>>).
MSB 1 (rest:1)
ok

まとめ

強力なライブラリと list, map などのデータ構造……。興味は尽きないのですが、取り急ぎ、自分が必要とするところだけを駆け足で見てみました。
なかでもバイナリマッチングは強力で、パフォーマンスまではわかりませんが、かなり面白いです。
なんでこんなに俺得仕様なのかといえば、 Erlang は元々携帯電話の基地局などで使われていたと聞きます。当然何層ものパケットを解析してディスパッチ先を決め、割り込みにも高速に応答しなければなりません。そのせいでしょうか。
現在はスケールしやすさが買われているようです。
実際に動かしてみると、仮想マシン上のシステムにしてはなかなか IO の応答性がよくてときめきました。
携帯電話の基地局といえば、かつて WindRiver の VxWorks で動いているシステムを見たことがありますが、ああした環境の小さな OS で動けば、かなり使い手のある言語/環境だと思います。