KiCadで多ピンICのライブラリを作成する際、コンポーネントエディタで1本ずつピンを配置しても良いのですが、 ピンの入出力などの設定をいちいちマウスの右クリック->編集で行うのは面倒です。

そのような多ピンのICの場合にどうしたら効率よくライブラリを作成できるのか、試行錯誤しましたが、 次のような方法が私にはしっくりきました。

1. Quick KICAD Library Component Builderにて、ひな形を作成する。
2. ダウンロードしたひな形をコンポーネントエディタで編集する。

まずは、Quick KICAD Library Component Builderにて、 必要なピン数などを選択します。ここで大切なのは、 最初の画面のComponent Features > Parts Countにコンポーネントの分割数を指定することです。 ここで指定した数のユニットに分割されたコンポーネントとしてICが作成できます。

次の画面では、画面上でピンをずらーっと一覧でき、シンボル上のピンの向きや、 どのパートにピンが所属するか、ということも設定できます。

これが必要なのは、多ピンICになると、回路図を書く際に、例えば複数の電源ピンを1つのブロックとして、 データ信号は別のブロックで、というように、ピンの機能ごとに異なるブロックになっていたほうが、 すっきりとして理解しやすい回路図が書けるためです。

(公式ドキュメントだと、Pythonでパートの番号などを入れ替えるスクリプトが示されていますが、私には最初の作成時から上記Webアプリで作成してしまったほうが楽だと感じました。)

最後に、“Build Library Component"を押すと、指定したコンポーネントが含まれるライブラリがダウンロードできます。

次に、ダウンロードしたlibファイルに含まれるコンポーネントを、コンポーネントエディタで編集します。 例えば、データバスが32本ある場合、ビット並び順に上から下へ、というように並べ替えます。 ただ、ここでも注意点があります。次の図にあるように、画面右上にある、 “パーツ/ボディ形状ごとのピンの編集"というのを押した状態にして作業する、ということです。

これが押されていないと、ユニットAでピンを動かすと、ほかのユニットの同じ場所にあるピンも動いてしまいます。 これがなかなかわからなくて、「KiCadはこんなこともできないのか!!」と私は小一時間以上悩みました。

後はピンを自分の気に入るように移動すれば完成です。

前回、FPGA基板を探していると書きましたが、早速注文してしまいました。 結局、Z-turn Board (MYS-7Z020-C-S, 7020の方)にしました。$119と送料$25で合計$144でした。 日本の税関を通すあたりでまたいくらか取られるのかもしれません。

あと、さらに調べて分かったのは、こちらのボードはJTAGケーブルは別途必要だということです。仕方ないので、これは別途調達しようかと思います。

注文はPayPalで決済されるのですが、私は初めて利用しました。レートなどが気になったので調べてみたら、 どうやらPayPalは手数料が高いらしいです。このあたりを参考にして、 クレジットカード側にてレートが決まるように設定しました。あとはこれが日本円でいくらになるのか？ですね (2017/3/28追記 144USD=16437円でした。1USD=114.146円です。2/7のレートは111.6-112.4円/USDあたりでしたので、 それほど手数料はかかっていないと思います)。

なかなか時間が取れないですが、少しずつ進展させていきたいと思います。

**追記：**早速注文しました。@marsee101さんに教えていただいた、 JTAG-HS3です。でも、こちらのJTAGはコネクタのピッチが2.0mmなのに対して、 Z-turn Boardはおそらく2.54mmピッチのようです。変換ケーブルも発注しなければ。

**さらに追記：**変換ケーブルも調べてみたら、なかなか工作不要の2mmピッチ(オス)<->2.54mmピッチ(メス)は見つかりませんでした。 2mmピンヘッダを買って工作すれば2.54に変換できまずが、できるだけやりたくないので、 やはりAmazonのやつを買おうかと思います。これは商品の写真にもあるように、何種類かのピッチに変換する コネクタが付属しているようです。これがあるだけでも1,000円だけ高いのは自分としては十分許容されます。

現在、安価で良さそうなFPGAの評価ボードを探しています。 Zynqの乗ったZyboは既に所有しているのですが、 今の興味からして、単にFPGAアクセラレータを作って遊びたいのではなくて、IOで遊びたいと思っています。 その観点からすると、ZyboはPMODコネクタしかないし、LVDSもありません(差動はあるけどなぜかバンクの電圧が3.3V。おいおい)。

希望としては、自作基板をコネクタで接続し、LVDS, 高速トランシーバあたりが使えるとベストです。

Z-Turn Boardというのは、基板の裏に80ピンのコネクタが2つも ついているので、なかなか良さそうでした。ただし、搭載Zynqにはそもそも高速トランシーバはありません。 また、使用されているコネクタの型名が回路図にも記載されていなかったので、嵌合相手がちょっとわかりません。 ケースの無いオス型1.27mmピッチであれば基本問題なさそうですが。 それと、これらのコネクタ間の距離も記載されていなかったので、両方のコネクタを使用する基板を作ろうとした 場合、ちゃんとコネクタ間の距離を計測しないと痛い目に遭います。非常に惜しい… もちろん、1つのコネクタを殺して80ピンだけ使うという方法もありますが、基板はやりだすと、 いろいろ載せたくなって欲が出てくるので、ちょっとピン数が不安です。

今のところ、FPGAとしてはCyclone V GXスタータ開発キットなるものが割と要望にマッチしていそうだと思いました。 旧Alteraですが… 私も昔(CycloneIIIくらいまで)はAlteraを使っていましたが、ZynqあたりからXilinx一辺倒になっています。 デバイスとしても、Xilinxの方が色々と細かいところの使い勝手が良くて高機能のように感じます(昔のISEは個人的には最悪でしたね。あの頃はQuartusの方が良かった)。

しばらくAlteraはご無沙汰していましたが、高速トランシーバも一応使えるコネクタがあるので、ちょっと魅力があります。でも最高速が3Gbps程度なので、Xilinxと比べてしまうと見劣りするんですよね。 しかもSDRAMはLPDDR2で最速300MHz(多分600Mbpsでしょう)と、これまた少し見劣りします。まぁ、とりあえずLVDSが使えれば良いですが…

ゆくゆくは高速ADCとUSB3.0を搭載した基板を作りたいと目論んでいます。これだけなら(JESD204B使わなければ、)トランシーバはいりませんけどね…

ちょっと検索してみたら、Cyclone V GXボードのHSMCコネクタ(ASP-122952-01)はなかなか見つからないではないですか。digikeyでも買えない。困った。

なんで、これに相当するような安価なXilinxのボードがないのでしょうね?? せめてLVDSだけでも使えれば… 自分の中では今更Altera?というのがあるのですよ。

もう少し検討してみたいと思います。

もし上記のような要望を満たした安価な評価ボード(できればXilinx)があれば、twitterで教えてください!

以前、NetlifyとGitLabの組み合わせを推奨しましたが、 今日はGitLabが死んだというニュースが話題になってしまいました。

So, what happened yesterday? Here's what went wrong and what we're doing to fix it: https://t.co/vWqs0TmrkL

— GitLab (@gitlab) 2017年2月1日

復旧まで待っても良いのですが、Netlifyだとこのような時でもサクッとBitBucketとの連携で解決できます。 今回、新しくBitBucketにリポジトリを作成し、そちらに記事データをgit pushするようにしました。 Netlifyの設定画面で"Link to Git"を編集してBitBucketの当該リポジトリを指定すれば、 そちらからfetch & buildしてくれます。

うーん、素敵です。

TwitterのTLを眺めていたら、ちょっと面白いニュースが目に入りました。

Aquantia Announces the Industry’s First FPGA-Programmable Multi-Gigabit Ethernet PHY Devicehttps://t.co/Ah6aCFS13E pic.twitter.com/kfejB4vKQB

— Aquantia Team (@10GEinsights) 2017年1月30日

AquantiaというイーサネットのPHYメーカが、自社のPHYにFPGA(XilinxのKintex7)を統合したデバイスを発表したようです。 プレスリリースはこちら。 私はPHYを使うことは少ないのですが、最近このAquantiaというメーカーのPHYはいろいろなところで話題になっている気がします。 Xilinxもほかのメーカーとこのような形で協業したデバイスを発表するというのは、あまり聞いたことがありません。

果たして、どのような形で統合されているのか気になります。個人的には、それぞれのダイをインタポーザのようなもので統合して1チップにした、 いわゆる2.5Dタイプではないかと予想します。

統合の利点として思いつくこととしては：

• 2つのICを別々に置いて配線するのに対して、実装面積が縮小される。
• 専用の接続を用いることで、レイテンシが削減されている。でも単にダイを2.5Dで統合しただけだと、 通常ならPCB上での配線遅延があるところが削減されるだけなので、それほどレイテンシ削減には意味がないと思われます。 それよりは、IOに必要な消費電力が削減される、ということの方が大きいかもしれません。

といったあたりでしょうか。他にもあるのかもしれませんが、プレスリリースからは読み解くことができませんでした。

2017/2/1追記：

• こちらにもう少し詳しい情報がありました。 “Space saving, one socket solution"と書いてあるので、その程度のメリットなのかもしれません。
• Aquantia公式情報

今日もいつものようにだらだらとネットでニュースをみていたら、 「nuroモバイル」が新サービスを発表　「5分かけ放題」「5時間プラン」「パケットギフト」を2月1日から提供というのが目に留まりました。

気になったのは、新しい"5時間プラン"というもの。一日のうち5時間は最高速度で通信を提供するというもののようです。 具体的に時間の計測に用いられる閾値は公開されていないので、 あっという間に5時間になってしまうという懸念もないわけではないですが、このあたりが適切に調整されているのであれば、 かなり自分には理想的なプランかもしれない、と思いました。

今の自分のネット環境

現在は、携帯はHuaweiのSIMフリー機にIIJ mioの音声付き3GBプランのSIMを刺して使っています。 また、自宅のインターネット回線は楽天でWiMAX2+を契約しています。ざっくり基本料金で1700円と3000円で、 合計4700円かかっている計算です。しかも、WiMAXについては2年契約なので、 それ以降そのまま契約を続けてしまうと、月に1000円位は増えてしまいます。 もっとも、2年のタイミングで解約し、新規契約を行うのであれば、 (値上げが起きなければ)合計額は変わらずに使い続けることはできるでしょう。

速度的には、WiMAXでもそれなりの速度が出ているので、今のところ不満はありません。 2/2以降は3日間で3GBから10GBになるそうですし。

これが新しいnuroの5時間プランだと、音声付きでも3200円です(多分税別なので3456円か)。 というわけで、この5時間プランだけで自宅回線としても十分使えるようだと、 月に1200円程度は浮かせることができるかも、と皮算用しました。

今のWiMAX契約が終了するときには、試してみるかもしれません。

今日は夕方に、友人と町田にあるLuceというお店で 食事をしました。友人はパスタを食べて、私はピザを食べました。シェアしてみたところ、 パスタ(トマトクリーム)は、確かに麺はもちもちしていておいしかったですが、自分の好みからすると、 少し薄味だった気がします。

一方、ピザ(ジモトーネ。町田市の食材を使ったものだそうです)の方は、生地がとてもおいしく感じました。 味付けは、面白いことに、味噌が効いているという未経験のものでした。これはこれで美味かった。

調子に乗って雑穀米のチーズリゾットも頼んでみました。これも味付け用として、味噌が別途 出されます。うん、確かにこれも味は悪くない。でも、イタリアで食べたリゾットの、あの 米の食感までは再現できていなかったかな。 日本の米と、ヨーロッパのコメとは本質的に違うのでしょう。単に炊き方をまねしただけででは、 本当のリゾットの食感は出せないのだと思いました。それと、気になったのは、 注文してからやたらと早く提供されたこと。 本当ならリゾットは米にスープを少しずつ加えて染み込ませて炊くように作ると思うのですが、 そうやって作ると、それなりに時間はかかるはず。なんでこんなに早いの？と思いました。

お酒も飲まなかったため、二人で5000円程度で済みました。全体としては、 ちょっと美味しいものを食べたいな、という時には、リーズナブルで悪くはないと思いました。

おわり。

Windows環境でアプリケーション(Webアプリではなく、Formsアプリ)を作る場合、 最近ではC#を使うのが典型的となっているのではないかと思います。 必要に応じてC++やCで開発したDLLを呼び出したり、あるいはC#から直接DLLを呼び出すかもしれません。 マニアックな方であれば、C#ではなくてF#を使ったりするかもしれません。

業務上作成するアプリケーションはできる限りのパフォーマンスが欲しい、という要求が生じることがあります。 そうなると、現状ではC++/CLIでアプリケーションを作るのが最も良いのではないかと思います。

C++/CLIで実装すれば、WindowsのFormもグラフィカルデザイナーで作成できますし、 必要であれば.NETコードではなくてネイティブコードを生成するようコンパイラオプションで設定することもできます。 しかも.NETとネイティブコードとのデータのやり取りは、関数呼び出しで行う限りほぼ暗黙的に実行できます。

C++であればOpenMPもC++ AMPも自由自在です。そのため、GPGPUやマルチスレッドプログラムの作成も (APIを呼び出すことなく)比較的簡便に行うことができます。

個人的にはC++なんて醜悪言語は使いたくないですが、パフォーマンスのためには背に腹は代えられません。

前回、 前々回とGitLab Pagesでのサイト作成について記載しましたが、 SSL証明書の設定で躓きました。色々調べているうちに、Netlifyというサービスを 使っても、静的サイトジェネレータ+カスタムドメイン+SSL証明書が実現できるということが分かりましたので、 その方法を簡単に説明したいと思います。

概要

今回も、サイトのソースはGitLabで管理します。NetlifyはCI, 証明書, ページのホスティング, の役割を担当してもらいます。

サイトのビルド時間もGitLab Pagesで回すより高速なように思われます。 (2017/2/1追記：サイトのビルド時間は明らかにGitLabよりも高速です。GitLabでは日本時間の夜の時間だと数時間かかってしまうこともありますが、 同じ時間帯でもNetlifyだと数十秒で完了しています。) ただ、生成物の最大サイズについては記述が見当たりませんでした。GitLab Pagesは1GBという制限がありましたが、 Netlifyではどうなのでしょう? もっと制限が緩いのか、きついのか。

Netlifyにログインしたら、GitLabのボタンを押して、GitLabとの連携を行います (アカウント作成時にGitLabのアカウントで行った場合は、最初から連携しているはずです)。 それから、Netlify側でホストしたいプロジェクトを選択します。

NetlifyでのCI

NetifyでCIをする際は、すでにHugoはインストール済みです。公式ドキュメントの Continuous Deploymentに記載があります。 そのため、プロジェクトの設定で、Build Cmd: hugo, Public folder: public と設定するだけで、 指定ブランチにpushすると、Hugoにてビルドされ、publicディレクトリがサイトとして設定されます。

GitLab Pages側でのビルドが不要であれば、.gitlab-ci.ymlは削除してしまいましょう。

ドメインの設定

プロジェクトのページで、Domain:欄に、カスタムドメイン名を入力します。apexドメインは非推奨なので、 www.などのサブドメインを付けたほうが良いようです。そしてDNSの設定で、カスタムドメイン名にCNAMEレコードとして (Name:欄に記載されている内容).netlify.com を設定します。

HTTPSの設定

これもNetlifyの秀逸なところです。プロジェクト > HTTPS のタブからボタンを押すだけで、 自動的にLet’s Encryptから証明書を取得し、設定してくれます。しかも、証明書の自動更新もしてくれるようです。 もちろん、DNSの設定は先に行っておく必要があります。

参考ドキュメント：

• Netlify builds, deploys, and hosts your front end.
• 高機能ホスティングサービスNetlifyについて調べて使ってみた

前回の記事で、無料で個人サイトを作成するという 観点からGitLab Pagesがかなりイケてるサービスであるということを書きましたが、今回はもう少し具体的な方法を説明したいと思います。

2017/1/21追記: 下記では、最後のLet’s Encryptでの証明書が上手く設定できていません。 GitLabのシステムの問題では無いと思うのですが、下記"カスタムドメインの設定"、“証明書の設定"は 「こうすればできるはず」という意味での記載になります。 結局、Netlifyを使用することで所望の機能が実現できましたので、 そちらを記事にしています。–追記終わり–

前提

次のようなセットアップを考えます。

• 静的サイトジェネレータとしてHugoを使用する。
• GitLab Pagesにソースファイルをpushすると、CIでHugoを実行し、サイトを生成する。
• DNSレジストラで取得したドメイン名をGitLab Pagesのページに結び付ける。
• Let’s Encryptで取得した証明書をドメイン名に結び付ける。

ざっくりとした流れ

上記の構成をするための大まかな流れは次のようになります。

• まずは https://username.gitlab.io/project/ のようなURLで所望のサイトが表示されるところまで持っていく。

• GitLab上でアカウントを取得、Pagesプロジェクトを作成する。
• ローカル環境にHugoをインストールし、サイトが所望のように生成されることを確認する。
• PagesプロジェクトでのCIの設定を行い、上記URLでのサイト確認を行う。

• カスタムドメインの設定と証明書の設定

• お名前.comなどのレジストラにてドメイン名を取得する。
• DNSのCNAMEレコード(www.domain.comでアクセスするような場合)、 あるいはAレコード(domain.comでアクセスするような場合)の設定を行う。
• Let’s Encryptから証明書を取得する。
• 証明書をPagesのプロジェクト設定にて追加し、HTTPSでアクセスできることを確認する。

Hugoについて

まずは公式サイトからHugoを手元のマシンにインストールしましょう。 最後はCIでHTMLはGitLab Pages上で生成するとしても、手元で結果を確認することは必須でしょう。

配布されているHugoバイナリは依存ライブラリを必要としないので、手元の環境と対応した バイナリを展開すればインストール完了です。

Hugo Quickstart Guideなどを参考にして お好みに合わせたページが生成されるところまで持っていきます。

CIの設定

プロジェクトのルートディレクトリに.gitlab-ci.ymlという名前でファイルをgitで追加します。 私の場合、概ね次のような内容で動作しています。

image: alpine:3.4

before_script:
  - apk update && apk add openssl
  - wget https://github.com/spf13/hugo/releases/download/v0.18.1/hugo_0.18.1_Linux-64bit.tar.gz
  - tar xf hugo_0.18.1_Linux-64bit.tar.gz && cp ./hugo_0.18.1_linux_amd64/hugo_0.18.1_linux_amd64 /usr/bin/hugo
  - hugo version

pages:
  script:
  - hugo
  artifacts:
    paths:
    - public
  only:
  - master

簡単な説明