2018年02月01日

1月度概況

access1801.jpg1月度の弊社HPへのアクセスは右図の通りで、訪問者数は従来並みですが、ページビューの多い日が増えている様子です。

pv1801.jpgdr-seo.net(comfort.saloon.jpと同じ)へのアクセスは下図の通りで、こちらも多少の増加となっております。一日あたりのページビューで60前後、訪問者数40前後といったところでしょうか。

1月度は、正月休暇を長めに取ったところに、コンサルティング業務が予想以上に難航し、時間に追われる状況となりました。この結果、mhdl関連の開発が全く進まないうえ、ブログもほとんど手が付けられていない状況です。

とはいえ、コンサルティング業務も一通り完了し、2月度からは他の業務も少しづつ進められるのではないかと期待しています。

その他、12月のこのブログでご紹介いたしました、東京ビッグサイトで開催の電気自動車関連の展示会を見学してきました。この展示会は、大昔から開催されておりますプリント基板関連の展示会との併催となっております。

さすがに、今日の我が国、自動車関連業界の強さが目立ちます。自動車関連の展示会は押すな押すなの大混雑ですが、プリント基板関係はそれほどでもない、明暗の目立つ展示会ではありました。

とはいえ、昨今の自動車は、電子機器の塊ですので、電子関連業界にとりましては、さほど嘆かわしい話でもないかもしれません。現に、自動車向けの展示物にあっても、情報電子機器がかなりの割合を占めておりました。要は狙う相手を変えればよい、ということでしょう。
posted by 管理人 at 11:39| Comment(0) | TrackBack(0) | 日記

2018年01月02日

12月度概況

access1712.jpg12月度の弊社HPへのアクセス状況は図のようになりました。こちらは、ほぼ前月並みの安定状態となっております。

pv1712.jpg同様に、私の個人的ブログ“comfort.saloon.jp”へのアクセスは下図のようになっており、こちらも変わらず、といったところです。

12月度は、引き続きコンサルティング業務に注力したこと、その他の個人的所用もいくつか立て込んだことから、mhdl関連の開発業務はほとんど進展しておりません。

その他の特記事項として、comfort.saloon.jpで公開しているブログへの入り口として、新しいURL“dr-seo.net”を取得しております。

このURLを取得した理由は、グーグルアドセンスの宣伝をこのブログに掲載可能とすることと、ブログを発展させることを狙っております。

ブログの発展に関しては、英語版を準備することを第一に考えております。

mhdlの開発環境準備には、かなりのマンアワーが必要であり、コンサルティング業務の合間ではなかなか進展しないという問題があります。

一方で、mhdlの基本コンセプトなどに関しては、弊社HP、本ブログ、および個人ブログでかなりの部分までオープンにしておりますが、反響は今一つとなっております。

個人ブログの英語版を作成すれば、技術アピールの対象が全世界となりますので、より反響も得やすくなることを期待しているのですね。

なお、アピールするネタとしては、以下の三点を考えております。

  • mhdlに代表される、新しい並列演算に関する提案

  • ローレンツ変換vsミンコフスキー空間(虚数時間)

  • 情報処理としての世界把握と三つの世界について


どれかが注目を集めれば、他も注目されるのではなかろうか、と期待しているのですが、さて、いかがなりますでしょうか。
posted by 管理人 at 18:16| Comment(0) | TrackBack(0) | 日記

2017年12月03日

11月度概況

access1711.jpg11月度の弊社HPへのアクセス状況は図のようになりました。昨年6月にブログをこちらに持ってきて以来増加しておりますが、このところのアクセス数は、ほぼ一定水準を維持しております。

pv1711.jpg下のグラフは、そのブログのアクセス状況で、こちらもほぼこれまでの水準と同程度で走っております。本年7月以降にみられる上昇は、Google Analyticsのみにみられる現象で、計測上の変化であって、実際のアクセス増ではないものと思われます。

業務に関しては、コンサルティング業務にほぼ100%の時間を費やしており、mhdl関連の進捗はありません。

その他、先日、東京ビッグサイトで開催された国際ロボット展を見学してまいりました。会場は非常に混雑しており、ロボット関連業界の活況ぶりがよくわかります。弊社が手掛けておりますようなコントローラに関する展示はほとんど行われていないのですが、関連業界でもありますので、喜ばしい話ではあります。

展示会関係では、1月17日から19日まで、同じビッグサイトで電気自動車関連の展示会が開催されるのですが、その併催展の一つが「第一回自動運転EXPO」となっております。これはちょっと気になる展示会ではあります。
posted by 管理人 at 11:11| Comment(0) | TrackBack(0) | 日記

2017年11月02日

10月度概況

access1710.jpg10月度の弊社HPへのアクセス状況は図のようになりました。アクセス数は、ほぼ従来並みです。

pv1710.jpg下のグラフは、comfort.saloon.jpへのアクセスで、こちらもほぼ先月並みの推移となっております。

業務に関しては、先月度問題となっておりました個人的問題はほぼ完了し、ほぼフルタイムでの業務を再開しておりますが、コンサルティング主体であり、ソフト開発は全く進展しておりません。

最近書店を訪れた際、コンピュータ関連書籍の売り場を覗いてみたのですが、Python関連書籍が多く置かれております。この言語、AI関連ということで注目を集めているのですが、斎藤 康毅著「ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装 」を読む限りでは、この言語で使用可能なNumPyライブラリ関数の“dot”、つまりは、行列の乗算が簡単に記述できる点が優れているというだけの話である様子。

こういうことであれば、テンソル記法を導入したmhdlもAI言語として売り出すこともできそうで、しかもこちらは並列演算ですから、高速処理を売りにできそうな気も致します。

AI、ディープラーニング関係は、この先も注目を集めるものと思われ、ビジネスを考える上ではAIへの応用可能性は確実に抑えていく必要があるでしょう。

とはいえ、しばらくの間はコンサルティングを優先せざるを得ず、mhdlの開発が進まないことが問題。現在では、誤差の問題はいったん棚上げとし、テンソル記法を導入したmhdlの新しいバージョンの感性を急ぐのが良いのではないかと考えております。

誤差の問題に関しては、2014年の段階で、シミュレーションによって各信号線に必要なビット幅を決定するアルゴリズムに関して報告済みなのですが、現時点では、AI的処理、すなわち数式を解析して誤差のキャンセルを検出し、誤差のキャンセルが生じない(値の相殺を数式処理で行い演算を排除する)形に式を変形する手法の方が優れているものと考えております。こちらに関しては、アルゴリズムに関して一応の着想はあるのですが、ソフトウエアの形まで追い込むには相当な時間がかかりそうであると考えております。

テンソル記法だけであれば、コンパイラを少々拡張すればよい話。これまでのパチあて的ソースコードを、技術資料も完備した、きちんとした形に書き直すことと合わせて、仕様拡張を行う、これが現在の計画となっております。

これだけであれば1〜2か月も専念できれば完成しそうなものなのですが、その時間が全く取れないのが現在の悩み。締め切りがあるわけでもないですし、コンサルティングも常に入るわけでもないはずなので、さほどあわててもいないのですが、この先どうなりますことか。こればかりは、神のみぞ知る、といったところでしょう。
posted by 管理人 at 17:15| Comment(0) | TrackBack(0) | 日記

2017年10月02日

9月度概況

access1709.jpg弊社HPへの9月度のアクセス状況は図のようになりました。訪問者が400-500/日、PVが1,000/日程度で安定しております。アクセスは昨年6月より増加しておりますが、これはブログ“comfort.saloon.jp”を立ち上げたためです。

pv1709.jpg下がブログ “comfort.saloon.jp”へのアクセス数で、こちらはgoogle analyticsでのデータ収集を開始した本年3月以降の結果を示しています。HPへのアクセスはさくらに備わったアクセス計測システムを用いており、サーチエンジンのボットのアクセスも含めて計数しているのですが、ブログの計数からは、ボットと自分自身のアクセスを除外しております。このアクセス数は、ページビューで60/日、ユニークIDで30/日程度と安定しています。なお、ここ数か月google analyticsの計数が異常となっておりますが、8月の大きな狂いからは、かなり正常に近づいているとも言えるでしょう。

業務関連では、9月度は個人的に時間を大きくとられる事象が発生したため、コンサルティングも一部業務から外していただいており、ソフトウエア開発は全く進展しておりません。この残務は今月度も残るため、しばらくの間は大きな進展は見込めません。

なんとも困ったことですが、避けるわけにもいかない性質のことであり、ここは淡々と処理を進めるしかありません。
posted by 管理人 at 13:37| Comment(0) | TrackBack(0) | 日記

2017年09月01日

8月度概況

access1708.jpg8月度の弊社HPへのアクセス状況は図のようになっております。先月度に引き続き、訪問者は400/日、ページビューは1,000〜1,200/日程度でほぼ安定しております。

pv1708.jpgブログ“comfort.saloon.jp”へのアクセス状況は下の図のようになっております。ユニークユーザが30/日、ページビューが60/日前後となっております。7月中旬よりページビューが増加しているようにも見えたのですが、これはGoogle Analyticsのみが増加しており、何らかの異常が生じていたように思われます。この異常、8月末ごろにいったん収まったようにもみえましたが、8/31のページビューが再び跳ね上がっており、まだ正常に復帰しているようにも思われません。当面は、他の二つのページビューを信じておくのが良さそうです。

今月度はコンサルティング業務が一息つくと期待していたのですが、引き続き多忙を極め、mhdlおよびCodeSqueezer関連では、ほとんど進捗がありません。ただ、リンク関連の仕様とテンソル記法について、簡単なまとめを行っております。これについて、以下簡単にご紹介しておきます。
------
・リンク:論理的な信号線を表し、信号線の束(リンクリスト)もリンクとして扱う。
・リンクのデータ構造
 - 名前
 - 値Valueへのポインタ;リンクリストの場合はnullptr。Valueは整数を表すman, exp, nan, of, ufの5つのWireクラスへのポインタからなる
 - リンクリスト:リンクのリストで、リンクリストでない場合はnullptr
・リンクリストの要素の指定
 - ドット(.)に続けて名前で指定するか、アット(@)に続けて番号を指定する
 - 名前、番号がリスト形式で指定された場合は複数の要素を含むリストで返される
 - ドットの後には定数で番号を指定してもよく、アットの後の番号は式で指定しても良い
・右辺の型が左辺を決めるが、左辺がリンクリストの場合は要素を明示することとする
 - x = (a, b, c)としてx@0 = a, x@1 = b, x@2 = cとすることは認めない
 - これを行いたい場合は、x@(0:2) = (a, b, c)と記述する
・テンソルの添字と定数の宣言
 - #define #k (0;2)、#define #k 0:2のように行い、#を変数の前につける
 - #define #k 2のように、スカラーで定義された場合は、#kは定数として宣言される
 - ?リストの要素番号を定数にしたい場合に、#define @height 2のような宣言も許すか?
・テンソル添字、定数の利用
 - #kが定数でない場合、x#kはテンソルの演算規則に従って解釈される
 - #kが定数の場合、x#kという書き方は許さない。#k番目の要素を指定したければx@#kとする
 - テンソル添字は定数添字と同様に用いられているため、x#2という書き方は許す
 - ならば、#kが定数の場合、x##kという記法が許されることになる。これは認めてもよさそう
------
このあたりは、暇をみながら、ぼちぼちと考えてまいります。
posted by 管理人 at 22:45| Comment(0) | TrackBack(0) | 日記

2017年08月01日

7月度概況

access1707.jpg7月度の弊社HPへのアクセス状況は右図のようになりました。訪問者は400/日、ページビューは1,000〜1,200/日程度でほぼ安定しております。

pv1707.jpgブログ“comfort.saloon.jp”へのアクセス状況を右図に示します。こちらは7月中旬ごろより多少増加し、ユニークユーザが40/日、ページビューが60〜70/日程度となっております。アクセスされているページにつきましては、特に注目されたページもなく、全体に興味をひかれている様子です。良い傾向であるといえるでしょう。

7月度は引き続きコンサルティング業務が入っておりますが、多少の暇を見てmhdl関連の考察を進めております。

mhdlの言語仕様に関しては、かなり発散気味であるため、仕様を限定する必要がありました。7月度の時点では、以下のように考えております。

・dot演算子は、同様の機能がテンソル記法で実現できるため、言語仕様には含めない。このため“'”(シングルコーテーションマーク)が不要となるが、これは予約済みとしておく。

・テンソルの添え字には“#”を使用する。“^”は上付きのテンソル添え字のために予約するが、当面この機能は使用しない。縮約は#相互間でも行うこととする。なお、べき乗演算子には“**”を用いる。

・テンソルの添え字の変動範囲は、コンパイラディレクティブで“#define #k 0:2”のようにおこなう。この場合、テンソル添え字#kは0、1、2と変化する。同じ構文で定数の定義も可能で“#define #x 1.23”などとすることも許す。#が先頭についた名前は、コンパイラ段階で定義済みであることを表している。

・代入文は、右辺の式が左辺の型を決める。リンクリストの構造も、右辺の式が与える。カッコとコンマを用いたリンクリスト形成式を左辺に与えて対応する要素に代入することも許すが、あまり複雑になるとわかりにくくなるという問題がある(極端な場合、リンクリストを使えば、全ての式を単一の代入文で記述することもできる。)これは、ソース記述段階で気を付けることとする。

このところコンサルティング業務が多忙を極めたこともあって、コンサルティング収入は過去最高となっております。一方で、mhdlの開発業務がほとんど進まないという弊害も生じております。

この先は、コンサルティングをある程度絞り込むことも厭わず、mhdlの開発を確実に行うよう注意していきたいと思います。
posted by 管理人 at 09:15| Comment(0) | TrackBack(0) | 日記

2017年07月05日

6月度概況

access1706.jpg6月度の弊社HPへのアクセス状況は図のようになりました。おおよそ、訪問者が450人/日前後、ページビューが1,000/日程度で安定しております。なお、このページビューは、サーチエンジンのボットを含む数であり、実際のページビューはこの半数程度ではなかろうかと推定しております。また、弊社HPへのアクセス数には、次に示します私の個人的ブログ“comfort.saloon.jp”へのアクセス数も含まれております。

pv1706.jpg“comfort.saloon.jp”へのアクセス数は右図の通りとなりました。こちらのアクセス数は、三つの方法で計測しており、グラフが非常に読み難くなっておりますが、一部のデータについて太めの点線で示しております7日移動平均線をみるのがわかりやすいかと思います。

表示されているデータは次の通りです。(ページビューをPV、ユニークユーザ(訪問者とほぼ同義)をUUと略します。)

・SlimStat:WordPressのプラグインで青がPV、水色がUUです。
・アクセス解析研究所:独立したアクセス解析ツールで緑がPV、黄緑がUUです。また、これらの7日移動平均を青と水色の点線で示しています。
・グーグルアナリティクス:赤がPV、ピンクがUUです。これらの移動平均をそれぞれ点線で示しています。

それぞれのデータには多少の違いがありますが、一日あたりでは、ページビューが45〜50程度、ユニークユーザが30付近まで低下しております。図には示していないのですが、今年の正月頃にはこの倍程度の数字をつけておりましたが、これは、特定の話題にアクセスが集中したことと、ページの更新頻度が高かったことによる一時的な現象であった様子です。

comfort.saloon.jpにつきましては、アクセス数をページビューで一日1,000程度まで稼ぐことができれば、アフェリエイトなどでの多少の収益改善も可能と考えていたのですが、この想定の根拠でありました楽天ブログのアクセスカウンタの値に異常がありましたこと、その後のアクセス数の伸びもあまり急激とはならないことから、ビジネスとなる可能性はあまり高いとは思われず、時間もそれほど割かないこととしております。

もちろん、この先、mhdlなりCodeSqueezerなり弊社なりあるいは私に対する世間の注目が高まってこのブログに対するアクセス数も増加する可能性もないわけではなく、アクセス数は引き続き注目しておくことといたします。

業務関係では、引き続きコンサルティングが立て込み、mhdlのコンパイラに関してはほとんど手が付けられておりません。これにつきましては、中途半端に手を付けても、なにをしているかわからないことにもなりかねず、構想的な部分をあれこれ考えるにとどめております。

当面の学会発表を見送った結果、次のタイムリミットはHPCSの論文締め切りであります来年1月となりました。現在計画しております発表内容は、テンソル処理を含むFPGA用の並列処理コンパイラという形のmhdlの新バージョン。具体的な応用分野をディープラーニングのベースになるニューラルネットワークとして、デモなども含めることができれば、注目度も高いのではなかろうかと期待しております。

構想だけはどんどんと進むのですが、具体的な作業に手が付けられません。この先、コンサルティング業務の減少する時期もあるのではなかろうかと期待しているのですが、果たしていかがなりますか、先の見えない話ではあります。
posted by 管理人 at 16:38| Comment(0) | TrackBack(0) | 日記

2017年06月02日

5月度概況

access1705.jpg5月度の弊社HPへのアクセスは図のようになりました。ほぼこれまでと同様と言えそうです、

このアクセス数には、同じさくらのサービスを利用しておりますブログ“comfort.saloon.jp”へのアクセスも含まれております。こちらのアクセス数は図のようになっております。本年1月ごろに急上昇したのですが、その後落ち着き、最近の一日あたりでは、訪問者が30、ページビューが50前後といったところです。pv1705.jpg

comfort.saloon.jpへのアクセス数は、汎用のアクセス解析サービスでありますアクセス解析研究所、WordPressのアクセス解析プラグインであります“SlimStat”、そしてGoogle Analiticsの三つの方法で計数しております。これまで、Google Analiticsのページビューだけ倍程度の値が出ていたのですが、この原因としてカウンタを二度設置してしまったことが考えられるため、今月度よりこのページビューを1/2して集計することとしました。

pv1705d.jpg三つの方法で測りましたcomfort.saloon.jpへの最近のアクセス数を右に示します。各手法の間には、多少の違いはありますが、概ね妥当な動きをしているように思われます。

本業につきましては、5月度もコンサルティング業務が集中したため手つかずとなっております。コンサルティングは、5月でいったん山を越えた形となっており、この先ようやくmhdlやCodeSqueezerの開発などに取り組むことができそうです。
posted by 管理人 at 20:52| Comment(0) | TrackBack(0) | 日記

2017年05月01日

4月度概況

acess1704.jpg4月度の弊社HPへのアクセス状況は図のようになりました。訪問者数は1日400弱で安定しておりますが、ページビューは減少傾向です。これは、下に示した個人的ブログのページビューの減少によるものかもしれません。PV1704.jpg

4月度は、コンサルティング業務が立て込み、mhdlの開発にはまったく手を付けられておりません。先月の時点では、5月には入れば余裕ができると期待していたのですが、新たな業務も加わった結果5月度も引き続きコンサルティング業務で手一杯となりそうです。

開発中の新しいmhdlを発表したいと考えておりましたDAシンポジウム2017は、アブストラクト締め切りが6月9日となっており、これに間に合わせることはかなり難しいものと思われます。ここは、あきらめが肝心と割り切り、当面はコンサルティング業務に集中することといたします。

欲をいえばきりがないのですが、現実的にできることは限られております。致し方ありません。
posted by 管理人 at 14:01| Comment(0) | TrackBack(0) | 日記

2017年04月01日

3月度概況

access1703.jpg3月度までの弊社HPへのアクセス状況は図のようになっております。訪問者が400人/日、PVが600前後で、ほぼ安定しているようです。

pv1703.jpg個人的ブログでありますcomfort.saloon.jpへのアクセス状況は図のようになりました。1月に100/日程度まで増加したPVですが、このところ50-60程度に落ち込んで安定しております。やはり、1月は特定のキーワードがアクセスを集めた結果と言えそうです。

こちらは、すでにメンテを停止しております楽天ブログへのアクセス記録の掲載を中止し、Googleアナリティクスのページビューとユーザ数の記録を開始しました。ユーザ数は他の計数結果とほぼ同様なのですが、PVは他の結果の二倍程度の数字を示しております。原因は不明ですが、当面は双方の結果を記録することといたします。

今月度は、コンサルティング業務が立て込み、ソフトの開発にはまったく手が付けられておりません。4月度も同様な状況が続くと思われ、DAシンポジウムへの発表がかなり苦しい状況となっております。これにつきましては、できればエントリーしますけど、無理はしない方針で臨みます。

なお、DAシンポジウム2017の案内がアップロードされました。開催日は8/31-9/1、場所は加賀の山城温泉、アブストラクトでの応募締め切りが6/9、カメラレディ原稿の締め切りが7/28ということで、かなり余裕のあるスケジュールではあります。

5月にがんばればなんとかなるかもしれません。まだあきらめるのは、早そうです。
posted by 管理人 at 16:15| Comment(0) | TrackBack(0) | 日記

2017年03月01日

2月度状況

access1702.jpg2月度の弊社HPへのアクセスは図のようになっております。1月度よりは多少減少しておりますが、依然高いレベルで推移しています。最近のアクセスの増加は、本来のSignal Process LogicのHPへのアクセスというよりは、昨年7月からこちらに移動した個人的なブログへのアクセスによるものと思われます。

pv1702.jpg右の図は、この個人的ブログ “comfort.saloon.jp”へのアクセス状況ですが、1月度のアクセス急増は一時的現象であった様子で、2月度はトレンドラインに復帰しております。同ブログへのアクセス数は引き続き上昇傾向にあります。これにつきましては、引き続きSEO対策などを施しつつ様子を見守り、ある程度のアクセス数が得られるようになるのをまって、収益化の道を探りたいと考えております。

mhdlコンパイラにつきましても引き続き開発を続行しておりますが、再びコンサルティングの依頼が複数入り、開発に割ける時間が少なくなっております。これにつきましては、ある程度形になりましたところで、改めてご報告いたします。
posted by 管理人 at 16:58| Comment(0) | TrackBack(0) | 日記

2017年02月01日

1月度概況

access1701.jpg1月度の弊社HPへのアクセスは図のようになりました。昨年7月に、ブログをこちらに移動して以来アクセスは急増していたのですが、今年に入ってから更に大きく増加しております。この理由は明らかではありませんが、昨年12月にブログ“comfort.saloon.jp”にSNSボタンを設置したことが奏功しているのかもしれません。

pv1701.jpg下のグラフがcomfort.saloon.jpへのアクセスで、太い点線は過去7日間の移動平均を示しています。これまでも大きな変動はあるのですが、本年1月の上昇は、変動というよりもトレンドの変化のようにみえます。実のところがどうであるかは、もう少し様子を見ないとわからないのですが。

今月度は、コンサルティング業務も一段落し、CodeSqueezerの開発に時間を割くことができました。

現在注力しているのが、リンクリストを全面的に採用した言語mhdlの開発で、1月度はパーサ部分のコーディングをいたしました。

パーサは、数式記述を項(class Term)に変換します。項は、先行する演算子(Ope^ pre_ope)、名前(String^ str)、単項演算子のリスト(List^ unary_opes)、同じ優先順位の演算子で結ばれた下位の項のリスト(List^ flat_expr)からなります。

パーサで処理した結果、名前がブロック配置の場合、flat_exprには引数が置かれます。演算子は全て、ブロック配置に変換されます。また、演算子のレベルやかっこによる演算の優先順位は、flat_exprを用いた項の木構造に変換されます。

新しいmhdlは、複数のリンクを束ねたリンクリストを扱いますが、パーサの段階では、リンクもリンクリストも同等に扱い、これに続くブロックの配置とリンクによる接続の段階でリンクリストを個々のリンクに分解します。

以下、いくつかの演算について、ソースコードとこれをブロック配置に変換した結果を示します。

代入文は、ブロック"_let"の配置に変換されます。
  ソース:x = y
 ブロック:_let ( x , y )

mhdlは複代入文も許されます。_letの引数は、最も右側の引数にのみ式を置くことが許され、その他の引数はリンクでなければいけません。_letは最終的には引数間のリンク接続に変換され、実際のブロックが配置されるわけではありません。

  ソース:x = y = z
 ブロック:_let ( x , y , z )

加減算は_sumというブロックで処理されます。加算と減算を区別するため、二番目以降の引数にはbool invとint selという修飾子が与えられます。これをソースコード上で表示するため、引数の区切り記号として次の6種類を用います。

“,”:inv = false, sel = 0
“-,”:inv = false, sel = -1
“+,”:inv = false, sel = +1
“;”:inv = true, sel = 0
“-;”:inv = true, sel = -1
“+;”:inv = true, sel = +1

加減算は次のように変換されます。

  ソース:x = a + b - c
 ブロック:_let ( x , _sum { a , b ; c } )

_sumブロックの最後の引数“c”は、その前の区切り記号が“;”であるため、逆の演算である減算が施されます。

乗除算は_prodブロックによって行われます。加減算と乗除算を組み合わせた式は次のように変換されます。

  ソース:x = a * b + c / d * e、
 ブロック: _let ( x , _sum { _prod [ a , b ] , _prod [ c ; d , e ] } )

二つ目の_prodブロックの引数“d”は除算であるため、その前の区切り記号が“;”となります。乗除算を一つのブロックで行うメリットは、除算を一つにまとめる最適化をコーダの内部でおこなえる点にあります。

今月度読みました書物に、斎藤 康毅著「ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装 」があるのですが、同書はPythonを用いて、非常に簡素なソースコードでニューラルネットワークを記述しています。(内容はこちらでご紹介しています。)

ここで用いられているのは、ベクトルや行列の演算を記述するNumPyというモジュールのdot演算なのですが、mhdlのリンクリストはベクトルや行列を扱うことができますので、dot演算に相当する演算子をmhdlに導入しておけば、mhdlでも簡素なコードでニューラルネットワークを記述することが可能となります。

Pythonは、通常のコンピュータ上でCPUによりニューラルネットワークを構成しているのですが、mhdlを用いればFPGA上に並列論理の形でニューラルネットワークを実現することができます。AIは最近ホットな話題でもあり、mhdlの応用分野としてニューラルネットワークの記述が簡単にできるとなれば、営業上の意義も大きく、dot演算に相当する機能はmhdlにもぜひ導入したいところです。

mhdlでdot演算を行う方法として、次の二つを計画しました。

一つは、乗除算の演算子の一つとしてdot演算子を導入することで、このための演算子として数式で使用される“・”に近い記号として“ ' ”を用いることを計画しました。“ ' ”は降階演算子およびリストの接合演算に用いられていたのですが、このための演算子を“ ` ”(バッククォート)に変更することとします。

このようにしておけば、dot演算は乗除算をコード化する_prodコーダの内部で処理すれば良いことになります。

もう一つの手法として、テンソルの記述を許すという方法も計画しています。

テンソルは、共変・反変の二種類があるのですが、単に和の規約を用いるだけなら、あえて二種類を区別する必要はありません。ここでは“#”をテンソルの添え字記号に用いることとします。“#”は、番号記号と呼ばれ、番号を表す添え字に合致しますし、コンパイラに対する指示子であるという意味で、他のコンパイラディレクティブの識別に用いていることとの整合性もとられます。

x = y#i * z#i ⇒ x = y@0 * z@0 + y@1 * z@1

x#i = y#j * z#j#i
⇒ x@0 = y@0 * z@0@0 + y@1 * z@1@0,
  x@1 = y@0 * z@0@1 + y@1 * z@1@1

以下同様に、項の内部に同じ添え字が現れた場合、その添え字を該当する次元の大きさだけ振って演算した結果の和をとることを意味します。なお、この式はリンクリスト全体を表しており、左辺の添え字は右辺の添え字との対応関係を示しているということにご注意ください。

物理的には、共変、反変間での縮約をとることにより基底ベクトルの取り方に依存しない値が得られるという意味があるのですが、計算上はどの要素の積を計算するかというだけのことであり、添え字の順番にのみ意味があって、上付き・下付きの区別は不要です。

しかし、べき乗演算子を“**”に変更するなら、テンソルの添え字に“^”を使うことが可能で、こちらを上付きの添え字に用いることもできます。FortranやPythonとの共通性を考えれば、最初からべき乗演算子には“**”を用いることにしておくのが良さそうです。

テンソルの記法に上付き、下付きの双方を許容することの利点は、物理的に意味のない演算がおこなわれた際に警告メッセージを出力することができる点です。あまり警告メッセージが出ることは、これが不要な人には目障りともなりますので、この機能は環境変数などで動作を切り替えられるようにしておくのが良さそうです。

このように修正した結果を反映したパーサの処理結果を以下に示します。式自体には意味がありません。“**”はべき乗演算子と解釈されて_powブロックに、“#”は“@”と同様、修飾演算子と解釈され、_modブロックに割り当てられています。

  ソース:x = a ** b + c@3 + d#k
 ブロック:_let( x, _sum{ _pow[ a, b ], _mod[ c, 3 ], _mod[ d+, k ] } )

  ソース:x#k^j = a#j^k
 ブロック:_let( _mod{ x+, k+; j }, _mod{ a+, j+; k } )

さて、テンソル記法を導入すれば、さしあたりdot演算子は不要になります。テンソル記法は、行列積(dot)に比べてはるかに自由度が高く、ソースコードも読みやすいという長所があります。一方、コンパイラが複雑になることは難点です。

さしあたり、パーサの段階では、“.”や“@”と同じレベルの修飾演算子として“#”および"^"を解釈して“_mod”ブロックを配置する形としています。_modブロックの引数がこれらの演算子のいずれに該当するかの識別は、invとselによって行っており、上記最後のブロック表記のように、これらの値は区切り記号“,”、“;”、“+,”、“+:”によって表示されています。

dot演算子を導入するかテンソル記法を許容するかにつきましては、この先のコンパイラの複雑さを比較検討したうえで決めたいと考えています。

なお、テンソル記法は、通常のコンパイラにも比較的容易に導入することができます。これにつきましては別途議論いたしました。
posted by 管理人 at 09:29| Comment(0) | TrackBack(0) | 日記

2017年01月01日

12月度概況

access1612.jpg12h月度までのアクセス状況は図のようになりました。PVが非常に上がっている日が何日かありますが、これは、管理人の個人的ブログでありますcomfort.saloon.jpの手直しがサーチエンジンのボットを招いたものと推定されます。

pv1612.jpgcomfort.saloon.jpのアクセス状況は図のようになっております。こちらは、自分自身とボットのアクセスを除外したもので、上の図に比べると非常に低い値となっております。こちらは徐々にアクセスが増加しておりますが、まだまだ商売ができるほどのレベルからは程遠い状態です。こちらは当面は、営利を度外視した運用といたします。

今月度は、コンサルティング業務が引き続き入っておりましたが、下旬にはほぼ完了し、CodeSqueezerのコーディング作業を再開しております。おそらく来月には、パーサ関連のコードが動く状態になるのではなかろうかと期待しております。

2017年度のDAシンポジウムの開催スケジュールは、まだ公表されてはおりませんが、例年どおりであれば6月に発表受付を締め切ることとなりますので、それまでに形にしておく必要があります。

それまでに、リンクリスト関連の機能拡張を施したmhdlコンパイラを完成させておくこと、数式変形を含む誤差キャンセル対応技術にめどをつけておくことが目標ですが、後者は、ある程度の技術的見通しができていればそれでよしと致します。

数式変形を含む誤差キャンセルにつきましては、9月度概況に原理を簡単に述べましたが、関数まで処理するとなりますと非常に手間のかかる開発テーマとなります。まずは、いくつかの関数を含む、数式変換アルゴリズムを動かすことが当面の課題となるでしょう。

1月度からは、コンサルティング業務も一段落する見通しで、コーディングにもかなりの時間が割けるものと考えております。当面は、6月のDAシンポジウム発表受け付け締め切りまでに、これらの見通しをきちんとつけることに全力を注ぎたいと考えております。
posted by 管理人 at 15:44| Comment(0) | TrackBack(0) | 日記

2016年12月01日

11月度概況

access1611.jpg11月度の弊社HPへのアクセス状況は図のようになりました。ブログcomfort.saloon.jpをこちらに移してからアクセスが一段高いレベルとなっており、まだ不安定な状況が続いております。

pv1611.jpgcomfort.saloon.jpのアクセス状況はこちらで、ユニークユーザ(緑線)が25/日前後、PV(黄緑線)が40/日前後まで増加しております。

アクセスが増えていることは良いのですが、以前から楽天の管理ページに表示されておりましたアクセス数(数百/日:赤線、この線だけ目盛は右)に比べますと一桁低い値となっております。

ちなみに、楽天ブログ側に入れておりますアクセスカウンタの値が黄色線(PV)と橙色線(UU)で表示されております(縦軸は左)が、こちらは赤線に比べて1/100程度の極端に低い値となっております。

このような大きな差が生じております理由として、楽天のシステムに何らかの問題がある可能性もあるのですが、私が入れておりますアクセスカウンタは、自分自身とサーチエンジンのロボットによるアクセスを除外しており、これらが毎日数百入っている可能性もないではありません。

サーチエンジンが頻繁にチェックしてくださるのは悪いことではないのですが、これは商売に結び付くものでもなく、これを除外したページビューが実力と考えるのが妥当ではないかと思います。ここは、実力でのアクセス数が増加するまで、ネット商売はお預けということにしなくてはいけません。

さて、本業ですが、11月度はコンサルティング業務が立て込み、CodeSqueezer関連の業務は完全にストップしております。

先月度報告しましたように、CodeSqueezerに用いておりますコンパイラに関して、近々学会発表をしたいと考えているのですが、このスケジュールはかなりタイトとなってまいりました。来年1月締め切りのHPCSへの応募は少々困難と思われ、6月締め切りのDAシンポジウムでの発表を目指すのが現実的となってまいりました。

6月までにはまだ余裕があるのですが、だからといってゆっくりやっていては、またコンサルティング業務が多忙になる恐れも多分にあります。ここは、余裕ができた時点で、最短での開発完了を目指したいと思います。

なお、CodeSqueezerの旧バージョンでありますCSEval 1.08は、現在無料公開中ですが、本年末までとなっておりました使用期間を、2020年末までと大幅延長いたしました。ダウンロードはこちらからどうぞ。

このような延長をしております理由は、来年中にはCodeSqueezer2.0へと切り替える予定で、古いバージョンの試用版は価値を失うであろう、との判断によります。当然のことながら、新バージョンにつきましても、試用版をご提供する計画です。こちらにつきましてもご期待ください。
posted by 管理人 at 14:36| Comment(0) | TrackBack(0) | 日記

2016年11月02日

10月度概況

access1610.jpg10月度の弊社HPへのアクセス状況は図のようになりました。ブログを移動して以後、急増しておりましたが、どうやら落ち着いてきた様子です。

今月度は、コンサルティング業務も一段落したことから、CodeSqueezerの開発に注力しております。

先月度述べましたように、まずは誤差キャンセルの問題はいったん棚上げとして、リンクリストの処理を含むコンパイラ部分を先に作ることといたします。

以下、少々入り組んだ話ですので、節に分けて記述します。

0. パイプライン数値演算処理記述言語“mhdl”

CodeSqueezerは、FPGAなどの論理演算デバイスを用いて数値演算をパイプライン処理によりおこなうための論理を自動形成するツールで、その演算仕様を記述するための新言語“mhdl”を開発しています。

mhdlはMeta Hardware Description Languageを略した命名で、Metaの本来の意味は「後の」つまりは「次世代」を意味するのですが、メタフィジックスの「メタ」から「抽象的」との意味合いでも広く使われており、より抽象度の高いハードウエア記述言語という意味も兼ね備えています。

裏話をすれば、将来の標準化を目指して“?hdl.org”というURLを確保しようと考えたのですが、“?”にあたる文字にたまたま“m”が空いていた、というのが実情です。他に“n”も空いており、New Hardware Description Languageにするという手も、ないではありませんでしたが、考えた末に“m”を選んだ次第です。

mhdl.orgは、既にページを作成済みですが、現在のところ放置状態となっております。いずれは、mhdl committeeなどを組織化して、このページを広報に利用できればと考えております。もちろんその前に、きちんとした言語処理系を作るのが先決であることはいうまでもありません。

FPGAで数値演算する論理を記述するためには、Verilog HDLやVHDLなどのハードウエア記述言語が広く用いられていますが、これらは、数値のビット幅やタイミングを設計者が記述する必要があり、複雑な演算を表現することが難しいという問題があります。

一方、C言語で記述されたソースコードをパイプライン化する方法も種々用いられているのですが、Cの言語仕様は、CPUの機能にあわせて設計されており、パイプライン処理の記述にはあまり向かないという問題があります。

パイプライン処理とCPU処理の異なる最大のポイントは、パイプライン処理ではそれぞれの演算に専用の演算器が用いられるということ。演算器ごとに、最適なビット幅(浮動小数点数の場合は、仮数部のビット幅と指数部のビット幅)を独立に設定できるという点があります。

これらの数値型は、きわめて自由度が高いのですが、これをプログラマーが設定するということは、非常に煩雑な作業となります。

mhdlないしCodeSqueezerの着想は、それぞれの演算器に要求されるビット幅は入力(あるいは出力)の仕様が与えられれば自動的に定まるという点にあり、これを利用すれば、型なしの言語仕様が可能となる点にあります。

また、こうして形成される論理は、必要最小限の論理のみを含むため、演算処理全体の論理規模を圧縮することが可能となります。これは、論理規模が大きくなりがちなパイプライン処理論理の開発に際しては大きな利点といえるでしょう。

mhdlの言語仕様を定めるに際しては、パイプライン処理論理の表現であるブロックダイアグラム(多数の演算機能ブロックを配置してこれらの入出力間を信号を伝達するリンクで接続したもの)を念頭においています。配置されるブロックは多入力・多出力が一般的であることから、複数のリンクをまとめて扱う「リンクリスト」という概念を導入しています。

リンクリストの概念を利用すると、複雑で大規模な演算論理も簡単に記述することができます。これが今回の改良の大きな部分です。また、リンクリストの概念を明確に定め、統一された思想にもとづく言語仕様として文書化することも、今回の作業の重要なポイントです。

その他、mhdlの言語仕様では、CPUの機能に即して定められたCの言語仕様から、CPU命令に則して定められたと思われる、ビットごとの演算、インクリメント・デクリメント演算、シフト演算などを除去し、一般に用いられている数式表現に近い形で数式を記述するようにしています。

また、CPUのシーケンシャル処理と、ブロックを配置してダイアグラムを形成するパイプライン処理では、アルゴリズムも異なったものとならざるを得ません。このため、forは、多数の論理を形成するマクロ的な記法に改め、ifやcaseは、制御の切り替えではなく、マルチプレクサの配置であることを明確化する言語仕様といたしました。

その他、現在ではごく普通に用いられているフルスクリーンエディタを前提に、今日ソースコードの論理構造を表すためにごく一般的に行われている段差付けに意味を持たせて、実行文のブロック化を行う記号(Cの場合は“{”と“}”、biginとendを用いるプログラミング言語もある)を排除して、ソースコードの可読性を高め、つまらないエラーが入り込むことを防止しています。

今日のFPGAでの算術演算には固定小数点演算が多く用いられています。固定小数点演算は、確かに高速演算が可能なのですが、有効な情報を落とす恐れがあり、安全な論理変換手続きが存在しないという問題があります。

CPU(マイクロプロセッサやDSP)でも、古くは固定小数点演算が主流でしたが、今日では浮動小数点演算が広く利用されています。FPGAをはじめとするパイプライン演算の世界でも、いずれは浮動小数点演算が主流になるのではなかろうか、と私は考えております。

このような背景により、シグナル・プロセス・ロジック社では、mhdlという新しい言語仕様を策定するという選択をした次第です。

これらの言語仕様の一部は、既にDAシンポジウム2012で発表したほか、リンクリストの概念を強化した新しい仕様につきましても3月度概況4月度概況でご紹介しております。

また、旧版のmhdl処理系を含むCodeSqueezerの評価版はこちらのページからダウンロード可能で、各種マニュアルなどもここに置いてあります。

言語仕様全般につきましては、これらをご参照いただくこととして、以下では、今回改良を試みておりますコンパイラの構成と、特にパーサの構成とアルゴリズムについて解説いたします。

1. コンパイラの構成とパーサの処理内容

mhdlコンパイラは、三つの段階に分けて処理します。

第一段階は、いわゆるパーサで、この部分で次の三つの処理により、ブロックダイアグラムを形成します。

・ ソースコードをブロック定義のツリーに変換し、各ブロック定義に(トークンのリストとして)ブロック定義文とブロック内部の式(代入文)をもたせる処理

・ 式を、かっこや演算子の優先順位に従い、項の木構造に変換する処理

・ リストに対する演算を個々のリンクに対する演算に分解するmhdl言語特有のリスト処理

第二段階は、いわゆる最適化の段階で、ブロックダイアグラムをより効率的な形に変形します。誤差キャンセルへの対応も、この段階で行います。

最後の第三段階で、各ブロックをVerilog HDLで記述されたモジュールに変換します。この処理は、各ブロックに準備された「コーダ」と呼ばれる関数により行います。

標準ブロックのコーダは、入力ポートに接続されたリンクの数値型に基づき、それぞれのブロックの機能を実現するために必要な、最小限の演算論理を形成します。

今月度は、パーサの数式解釈部分の文書化を行いました。本日はこの内容について、簡単にご紹介します。なお、パーサの最初の部分(ソースコードのトークン化とブロック定義ツリーへの割りあて)は、既に3月度概況4月度概況でご紹介しましたので、こちらをご参照ください。

2. class Ope:演算子

ope.jpgmhdlの演算子には、表に示すものがあります(クリックで拡大します。)この表の各項目は、class Opeのメンバーで、演算子の配列static array<Ope^>^ ope_tblを準備して同表の内容を与えておきます。表中、“?”は異常な演算子、“$”は末尾を表す演算子で、これらはコンパイラが内部的に使用するものです。symbol欄は、ソースコード上の文字列であり、ソースコード上に記号が現れた場合は、この文字列に従ってトークンへの切り出しがおこなわれます。このとき、class TokenのメンバーであるOpe^ opeもセットします。

パーサは演算子の優先順位であるint levelを用いて式のツリー化をおこないます。同じ優先順位に複数の演算子が割り当てられるため、これを識別するためにbool invとint selの二つの変数を用います。これらの変数は、歴史的な事情で二つに分けていますが、将来一つにまとめるかもしれません。

ソースコード記述段階でブロック入力ポートにinvとselの情報を与えることができるよう、リスト化演算子には、“,”の他にinvとselの異なる、合計6種類の演算子を割り当てています。これらは標準ブロックをテストするための演算子です。

同じ優先順位の二項演算子は一つの標準ブロック(binary std_block)により一括処理されます。

標準ブロック欄が空白またはかっこ内の演算子は、コンパイラ内部で処理されます。かっこは式解釈の段階で処理され、リスト演算に関わる演算子(“.”、“@”、“'”および“,”など)はリスト処理の段階で処理されます。

3. class Term:項とそのデータ構造

パーサは、最終的に、式を項に変換します。

項(class Term)は、名前(リンク名またはブロック名)もしくは定数に相当する単純項(String^ str)であるか、同じ優先順位の演算子で結ばれた項のリスト(List<Term^>^ flat_expr)のいずれかです。後者は最終的に標準ブロック(binary std_block)配置に変換され、全ての項は単純項となります。

項を先導する演算子(Ope^ pre_ope)と項に続く演算子(Ope^ post_ope)も項のメンバとします。pre_opeは、項に対応するリンクをブロックの入力ポートに接続する際にinvとselを入力ポートに与えるために用いられます。post_opeは、パーサの段階で、項の処理がいかなる演算子により修了したかを呼び出し元に伝えるために用いられます。

さらに項は、単項演算子のリスト(List<Ope^>^ unary_opes)と後置項のリスト(List<Term^>^ post_terms)を持つことができます。後置項には、“@”や“.”に先導されるリストの要素を指定する後置項と、ブロック配置の引数を指定する後置項があります。後置項を先導する記号は、後置項のpre_opeに格納して、後続するリスト処理に伝達します。

4. proc_term:項の形成

Term^ proc_term(int exit_level)はトークンを項に変換する関数です。exit_levelは、処理を終了する条件を示すもので、これ以下のレベルの(優先度の低い)演算子が現れた際に処理を終了します。式全体の処理は、proc_term(LV_END)でおこなわれます。

proc_termは、まず、最初のトークンをチェックして、閉じかっこが現れてそのレベルがexit_level以下である場合、および文末が現れた場合は、これをpost_opeとする空の項を返します。これは、空の式や“()”などの記述に対する処理です。

次いで、ひらきかっこ以外の演算子が現れる限り、これを単項演算子とみなして、unary_opesに追加します。

開きかっこが現れた場合は、そのselを保存して以後をproc_term(LV_BRA)で処理して、閉じかっこまでの項を得ます。また、得られた項のunary_opesを新しく作成する項のunary_opesに追加します。これは“-(-x)”などの記述がされた場合に備えてのものです。

開きかっこでない場合は、名前または定数が現れるはずです。これをString^ strに置きます。

次に現れるものが“@”、“.”、開きかっこである場合は、以降を後置項と見做してproc_termにより項を得、これをpost_termsに追加します。次に現れるものが名前もしくは定数である場合、エラーメッセージを出力し、proc_term(LV_MAX)により演算子を含まない項を得て、これを後置項とします。これは“sin x”などとしてしまった場合の救済処理です。後置項が“@”か“.”に先導される場合は、これらを後置項のpre_opeに置きます。後置項は複数置くことができますので、この処理は“@”、“.”、開きかっこ以外の演算子が現れるまで繰り返し行います。

後置項とみなすことのできない演算子が現れたら、すでに形成された項を処理中の項(resとします)とし、そのpost_opeに現れた演算子を置きます。演算子のレベルがexit_level以下の場合はresを返して処理を終わります。そうでない場合は、“res = proc_expr(res, exit_level)”により式の処理を行い、その結果を返します。

なお、ここで閉じかっこが現れた場合は、警告メッセージを出力してこれを無視します(次の演算子を読んで、処理を継続します。)閉じかっこは、開きかっことの対として処理されているはずですので、ここで現れる閉じかっこは、開きかっこに対応していないことになります。

5. proc_expr:式の形成

Term^ proc_expr(Term^ first_term, int exit_level)は、flat_exprを含む項を形成して返す関数で、引数に与えられた項が第一項となります。また、flat_exprの演算子レベル(first_term->post_ope->levelとして与えられます)をint cur_levelに保持します。

次いで、next_term = proc_term(exit_level)により次の項を読み込み、next_term->post_opeのレベルを参照しながら、以下の処理を繰り返し実行します。

cur_levelに等しい場合は、得られた項にpre_opeをセットしてこれをflat_exprに追加し、次の項をnext_termに読み込み、処理を繰り返します。

cur_levelよりも大きい(優先度の高い)場合は、next_term = proc_expr(next_term, cur_level)によりcur_levelよりも優先度の高い演算が続く限り項をflat_exprの形に変換し、これをnext_termとし、そのpre_opeにfirst_term->post_opeをセットして処理を繰り返します。

cur_levelよりも小さい(優先度が低い)場合は、next_termまでをflat_exprに追加して形成される項を第一項(first_term)とし、cur_levelをfirst_term->post_opeのレベルに変更します。これがexit_level以下の場合は、first_termを返して処理を終わります。そうでない場合は、next_termを読み直して処理を継続します。第一項のpre_opeはセットされません。

6. まとめと今後の計画

前回述べましたように、mhdlソースコードはパーサの第一段階でブロック定義の木構造にまとめられており、それぞれのブロックに内部で定義されたブロックと内部で定義された式(class Expr)のリストを含んでおります。式のリストは、パーサの前段階では、トークンのリストとして保持されているのですが、class ExprにTerm^ termを含めて、この中にパーサの第二段階の結果を置くこととします。

ここまでできていれば、次は、リンクリストを許す形で記述された項を、個々のリンクに分解する処理を記述することとなります。もちろんその前に、上にご紹介したアルゴリズムを実際にコーディングするという作業が残っております。これらが11月以降の作業ということになるのですが、さて、11月はどこまで進みますことか。

HPCSの論文締め切りが来年1月となっておりますことから、あまり残された時間はありません。できることなら、11月中に、リンクへの分解までを終わらせたいところですが、またしても、コンサルティングの業務が入っておりますことから、この先のスケジュールもかなりタイトになると予想しております。

これが1月までにできなければ、次は6月締め切りのDAシンポジウムを目指すだけのことなのですが、、、
posted by 管理人 at 08:22| Comment(0) | TrackBack(0) | 日記

2016年10月01日

9月度概況

access1609.jpg9月度の弊社HPへのアクセス状況は図のようになりました。本年6月に個人的に作成しておりましたブログをこちらに移しましたことから、アクセスが急増していたのですが、徐々に落ち着きつつあります。

blog1609.jpgこちらの図はブログのアクセス状況で、ユニークユーザ数(紺と緑)が開設当初の10/日から20/日程度に増加、ページビュー(水色と黄緑)はその1.5〜2倍程度となっておりますが、楽天ブログ時代に示されておりました500/日からは、はるかに隔たった値となっております。なお、アクセス解析は二つの手法で行っており、青系統はSlinStat、緑系統はアクセス解析研究所による測定結果ですが、双方の値は、ほぼ同等となっております

楽天ブログのアクセス数に関しては、システムが表示する数値(薄赤:目盛はこれだけ右側)とアクセス解析研究所の数値(オレンジがユニークユーザ、黄色がページビュー)と全く乖離した数値を示しており、楽天のシステムに異常があることはほぼ確定的です。

楽天ブログのアクセス数が大きいことから、ネットビジネスも成り立つのでは、と考えたのですが、どうやらこれは当面諦めたほうが良さそうです。とはいえ、この3か月でアクセスが倍増しておりますので、今後、ビジネスとして成り立つ可能性もゼロではなく、当面は、このままのスタイルで運用を続けることといたします。私の個人的ブログは、小難しいことばかり書いておりますので、どの程度一般受けしてくれるか、はなはだ怪しいものではあるのですが、、、

さて、業務の方ですが、コンサルティング業務が今月も立て込み、CodeSqueezer2.0の開発はほとんど進んではおりません。しかしながら、月末ごろには多少の時間もとれるようになりましたので、こちらの開発もいよいよスタートすることといたしました。

CodeSqueezer2.0は、これまでに公開しているCodeSqueezerに対して次のような改善を施すことを計画しております。

(1) 誤差キャンセルにも配慮した、精度の高い演算論理を形成すること

(2) 今後の展開やメンテナンスが容易な見通しの良いコーディングと文書化

(3) リンクリストの概念を拡張した新しいmhdl言語仕様への対応

この内、(2)に関しては、アルゴリズムをきちんと考えて文書化し、これに対応する形でコーディングをおこなうことで、見通しの良いコードが書けると考えております。(3)に関しては、なにをするにしても、コーディングを行う以上は対応する必要があります。

一方、当初から計画しておりました誤差キャンセルへの対応ですが、シミュレーションによって必要な桁数を求める手法は原理を確認済みで既に発表もしているのですが、実際のツールに組み込む際には次のような問題があります。

・すべての入力値の組合せについてシミュレーションをおこなうと非常に時間がかかる

・アルゴリズムを固定して誤差キャンセルに対応しようとすると、非常に大きな無効桁を伝達する必要が生じる場合がある

・これらの問題に対処しようとすると、人手による設定が必要となり、簡便な操作とのツールのコンセプトから外れてしまう

この問題に関しては、以前から頭を悩ませていたのですが、一旦、より完全な手法で構成することを試みたいとの考えに至りました。この手法、以前から考えてはいたのですが、関数などが含まれますと簡単にはいかないという問題があります。でも、これに対する対応策も浮かんでまいりましたので、こちらで検討すべきとの結論に至りました。これにつきまして、以下、簡単にご紹介しておきます。

ます、数式は、誤差キャンセルが含まれない形に変形することができます。数式を変形するソフトウエアとして、リデュースなどのソフトウエアが知られており、微積分や、多項式の因数分解などを式を変形する形で行うことができます。

これと同様の処理により、誤差キャンセルが生じないように式を変形するか、誤差キャンセルが入力値の異なる領域で生じるように式を変形して入力値の組合せに応じて異なる式を用いるように演算論理を組めば、誤差キャンセルの問題は回避することができます。

CodeSqueezerの場合、演算論理は一旦ブロックダイアグラムに変換されますので、この段階で値と誤差の伝達状態をチェックして誤差キャンセルの生じる可能性を判定し、これが問題とならない形にブロックダイアグラムを組みなおせばよいということになります。

簡単な例では、以下のような演算式がある場合

x = a + b
y = x - b

次のような形に式を変形してしまえばよいのですね。

y = (a + b) - b = a

多少ややこしい点は、双方の演算が異なるブロックの内部で行われていた場合ですが、この場合には、下位のブロックを上位のブロック内部に展開してしまう手法もとり得ますし、上の例でxを出力するブロックの代わりにx - bを出力するブロックを作成して、こちらを用いることで誤差のキャンセルを一つのブロック内部に押し込めることができます。

ユーザ定義のブロックであればこのような変形をすることができるのですが、標準関数ではどうするかという点がもう一つの問題となります。これに関しても、例えばsin(x)と、sin(x)±xという関数を用意することで、誤差のキャンセルが生じる場合に、他の関数を用いる形にブロックダイアグラムを変形することで誤差のキャンセルを回避することができます。

一般に、関数を含む演算で誤差のキャンセルが発生するのは、傾きが一致する部分での減算が行われる場合に生じます。したがって、これらを減算する形で新たな関数を定義してやれば、誤差のキャンセルは生じないこととなります。

関数には多々ありますので、それぞれの組合せ関数を作る必要がありますが、全ての関数を表引きで行うこととすれば、必要な関数を自動で形成することも可能であり、さほど難しい作業でもなさそうです。

と、いうわけで、開発の方向はほぼ定まりました。HPCSの論文受け付け締め切りは、昨年と同じであれば来年1月となります。まずはこれを目標にCodeSqueezer2.0の開発を進めることといたします。

誤差キャンセルの問題は、少々時間がかかりそうですので、もしもここまでできない場合は、HPCSでの発表はリンクリストの概念を拡張した新しいmhdl言語仕様までとし、来年6月ごろが締め切りとなるはずのDAシンポジウムでより完成度の高い形での発表を行うことといたします。

いずれにいたしましても、この先もかなり忙しくなりそうです。
posted by 管理人 at 15:12| Comment(0) | TrackBack(0) | 日記

2016年09月01日

8月度概況

access1608.jpg8月度の弊社HPへのアクセス状況は図のようになりました。6月にブログを弊社HP内に移動してからアクセスが急増しておりましたが、徐々に落ち着きつつあります。

今月度は、CodeSqueezer2.0関連業務もかなり進むと期待したのですが、予期せざる新規のコンサルティング業務と決算処理に時間をとられ、あまり本業は進んではおりません。とはいえ、最近コンサルティング業務を多く抱えたこともあり、決算が良好であったことが良いニュースではあります。

今月度行ないましたCodeSqueezer関連のわずかな業務といたしまして、4月度概況でご紹介いたしました、以下の宿題事項(?)に結論を出すことができました。すなわち、以下の課題が残っていたのですね。

リンクリストに対するもう一つの演算子として、降階演算子“'”を準備します(かっこを外す「皮むき」という意味で、ピーラーなりストリッパーと呼んだほうが良いかもしれません)。降階演算子は、リンクリストの後ろに記述し、その前のリンクリストの階数を一つ低下させる作用をします。すなわち、((a, b)’, (c, d)’)は(a, b, c, d)を意味します。

この演算子が意味を持つのは、リンクリスト名を用いる場合で、たとえばdat1.(q, r)とdat2.(q, r)に対して(dat1, dat2)とすれば((dat1.q, dat1.r), (dat2.q, dat2.r))と解釈される一方、(dat1’, dat2’)とすれば(dat1.q, dat1.r, dat2.q, dat2.r)とすることができます。

なお、この部分については、現在検討中であり、(dat1, dat2)と書いただけで(dat1.q, dat1.r, dat2.q, dat2.r)と解釈するのが妥当であるかもしれません。なにぶん、(dat1)が(dat1.q, dat1.r)と解釈されますので。この場合は、((dat1.q, dat1.r), (dat2.q, dat2.r))と解釈させたい場合は((dat1), (dat2))と記述することになり、降階演算子は不要になります。


これに対する解として最初に考えましたことは、「降階演算子“'”は、これに隣接する前後のリストの階数を一つ下げる」というもので、上の引用部では、「降階演算子の前に置かれたリストの階数を一つ下げる」としていたモノを変更して、「降階演算子に隣接して後に置かれたリストの階数も一つ下げる」という機能を追加するという一手です。

具体的には、(a, b)と(c, d)をつなげて(a, b, c, d)としたい場合、((a, b)', (c, d)')とする以外に、((a, b) ' (c, d))とする記法を許します。“'”の後にコンマを設けず“'”自体を区切り記号として用いる場合、降階演算子“'”は前後のリストに作用して、双方の階数を一つ下げます。

別の言い方をすれば、“'”はリストの連接演算子として機能する二項演算子としても使われる、ということもできます。また、単項演算子としての“'”は、前置・後置のいずれも使用できてこれらは同じ意味を持つということでもあります。

あまり使われることもなさそうなケースですが、この考え方を敷衍すれば、原理的には降階演算子を二つ以上用いることも可能です。このような場合、リスト連接演算子と逆の位置に降階演算子を記述することで、双方独立に任意の階数だけ降階することが可能となります。

ところで、これをリストの連接演算子として考えるためには、単項と二項の降階演算子は同じ作用をするわけにはいかず、複数の項を降階二項演算子で接続する場合、降階二項演算子に挟まれた項に対して降階は一回だけ作用するようにしなくてはいけません。

つまり、((a, b) ' (c, d) ' (e, f))を(a, b, c, d, e, f)とするということですね。(c, d)には前後に降階演算子がありますので、これが単項の降階演算子と同じ作用をすると考えれば、二階の降階演算がおこなわれるとしてもおかしくはないのですが、二項の降階演算子をリンクの接続演算子と考えるのであれば、一つの項に降階演算は一回だけ作用すると考えなくてはいけません。

そこで、厳密な定義として、単項の降階演算子と二項の降階演算子を分けて、二項の降階演算子はリンクの接続演算子として機能する、といたしましょう。また、解釈の多様性を防ぐため、単項の降階演算子は、後置のみといたします。

なお、複数の“'”を空白を入れずに並べた演算子は、複数の単独の演算子と解釈します。(a ''' b)は、最初の二つの降階演算子が単項の降階演算子としてaを降階し、 最後の降階演算子は二項演算子としてa''とbを接続します。

ということで、一つの課題は片が付きました。来月度は、コンサルティング業務もかなり入ってはおりますが、もう少し内容の多い形でCodeSqueezer2.0も前に進めたいと考えております。
posted by 管理人 at 18:55| Comment(0) | TrackBack(0) | 日記

2016年08月01日

7月度概況

access1607.jpg7月度の弊社HPへのアクセス状況は図のようになりました。6月度より私のブログをこちらに移動している関係で、アクセス数は6月に大きく伸びたのですが、移動作業が一段落した後は徐々に落ち着いております。

今回のブログ移動のそもそものきっかけは、私が以前から書いておりました楽天ブログの仕様変更に伴うものであったのですが、一日のアクセス数が数百ありますことから、アフェリエイトなどで多少の実入りになることを期待しておりました。制約の多い楽天ブログとは異なり、こちらでやればアマゾンやA8などの収益性の高いアフェリエイトも貼れますので。

ところが、移動後のブログへのアクセス数が思ったほど伸びません。この原因につきましていろいろ調べた結果、どうやら楽天のシステムが表示している「アクセス数」が現実とは大幅に異なる値を示していることが判明いたしました。

access_check.jpg図は、楽天ブログとこちらに移設したブログのアクセス数です。赤線は、楽天のシステムが表示しているアクセス数で、この線だけは右の軸が値を示しています。黄色は、アクセス解析研究所で計測した楽天ブログのPV、オレンジは同じくユニークIPです。双方の値は数十倍の差があり、楽天のシステムが表示するアクセス数は、現実のアクセス数に比べて極めて大きな値となっていることが分かりました。

一方、comfort.saloon.jpのアクセス数は、先月ご報告しましたSlimStatの結果を水色(PV)と青(ユニークIP)で、アクセス解析研究所の結果を黄緑(PV)と緑(ユニークIP)で示しております。これら双方には、多少の差はありますが、ほぼ同程度の値を示しております。

結論といたしまして、comfort.saloon.jpの一日のページビューは、およそ10から20といったところで当初期待した値の数十分の一といったところ。これではとても商売になりそうにはありません。今後様子はウオッチいたしますが、こちらでの営業活動に関しましては一旦ペンディングといたします。

通常業務につきましては、先月度に続き、コンサルティング業務が立て込み、休日返上での処理を余儀なくされております。8月度は多少の余裕もできるはずですので、少しはお休みを頂いたのちに、CodeSqueezer2.0のコーディングにも着手できるのでは、と期待しております。
posted by 管理人 at 09:17| Comment(0) | TrackBack(0) | 日記

2016年07月01日

6月度概況

access1606.jpg図は6月度の弊社HPへのアクセス状況です。縦軸はこれまでのグラフの二倍としております。

今月度のアクセスが急増している理由は、以前から取得しておりましたURL、“comfort.saloon.jp”を用いてブログを立ち上げたことによります。

comfort.saloon.jpは、この管理人日誌の二番目のエントリー"ドメインを取得しました"でご紹介したように、ネットビジネスへの展開を計画して取得したものです。このドメインには、試験運用中のページを貼付けて、エージング(サーチエンジンに歴史あるページと認識させること)をおこなっておりましたが、これをいよいよ活用することとした次第です。

シグナル・プロセス・ロジックの企業目的は、最初のエントリー"SPLJ計画始動"でご紹介したように、最初から信号処理論理とネットビジネスを二本柱にすることを計画しておりました。ネットビジネスとして、情報分析とネット販売を考えており、「情報分析」につきましてはコンサルティング業務としてこれまでも行ってきたのですが、comfort.saloon.jpでおこないますことは、「ネット販売」ということになります。

ネット販売と言いましてもいわゆるアフェリエイトでして、行ないますことはブログを作成・公開して読者を呼び込むことです。私はかなり以前から、個人的にブログを運営しており、そこそこのページビュー(数百/日)を稼いでおりました。これは楽天ブログという、無料のブログサービスを利用していたのですが、当然のことながらアフェリエイトは楽天のみ。あまり難しいことを考える必要がない代わりに自由度も低く、かねてから移動したいと考えておりました。

このブログの運営は、収益を得るというよりは、私が日常考えておりますことを発信することを主目的としており、なるべく多くの記事を読んでいただけるよう、トップページに10件の記事を掲載していたのですが、最近になりましてブログの仕様が変更になった様子で、トップページの記事は1件のみとなってしまいあまり面白くはありません。そこで、これを機会にブログの移動に踏み切ることといたしました。

使いましたブログシステムは"WordPress"です。このシステムはフリーソフトではあるのですが、営業用のシステムにも広く使われている様子です。さくらのレンタルサーバはWordPressが簡単につかえるように配慮されております。また、さくらのレンタルサーバを用いてWordPressを立ち上げ、そして集客するためのテクニックについて紹介された“できる100ワザ WordPress”という書物も出版されております。WordPress、さくらで営業用ブログを開設するには最適なシステムといえそうです。

先月の管理人日誌で述べましたように、今月度は、DAシンポジウムのエントリーをトライする計画でしたが、コンサルティング業務が予想外の負荷となり、月初めの時点で発表資料の作製は困難な見通しとなりました。DAシンポジウムでの発表に早々に見切りをつけることで空いた時間で、ブログの移行作業を実施いたしました。

ブログの移行は月半ばに完了いたしましたが、アクセス状況をみますと、楽天ブログのページビューが依然として多い一方で、comfort.saloon.jpへのアクセスはあまり増加しておりません。最初に掲げたアクセス状況を示すグラフでは、訪問ユーザ数が倍近くに増加しているのですが、WordPressに備わっているアクセス解析ツールを用いて検索エンジンのbotを除外いたしますと、訪問者はさほど増えてはおりません。ブログ移行作業により、多数のページに変更を加えた結果、これがサーチエンジンに感知されてページビューが増加している、というのが実際の所であるように思われます。

現在楽天のブログ記事にいろいろと手を加えて、comfort.saloon.jp側に読者を誘導することを試みております。ブログの移動は、読者の側でも「お気に入り」のリンクを付け替えるなどしませんと、古いブログがアクセスされてしまうという事情もあるでしょう。こちらのブログへのアクセスが増加するまでには、多少の時間がかかりそうです。

その他、WordPressにはGoogleのAdSenseを貼付けられるということで申請をおこなったのですが、comfort.saloon.jpのようなサブドメインは受け付けてくれません。そこで、さしあたり、signal-process-logic.comのHPで申請をおこなっております。右下の空いたスペースにアドセンスの広告が入るようになりました。

当初目的としておりましたWordPressへのアドセンス貼付けにつきましては、独自ドメインを取得すれば可能なのですが、これにはお金がかかります。今回貼付けましたアドセンスの収益状況と、新しいブログへのアクセス状況を勘案して、今後どうするかを決めていきたいと考えております。
posted by 管理人 at 09:50| Comment(0) | TrackBack(0) | 日記

2016年06月01日

5月度概況

access1605.jpg5月度のアクセス状況は、図のように、多少多い日も目立ちますが、まずはこれまでの変動の範囲内です。

今月度も、コンサルティング業務が立て込み、CodeSqueezer2.0関連の業務はなかなか思うように進みません。とはいえ、いくつかの点で前進しておりますので、簡単に書いておきましょう。

今月度検討したのは、リンク関係のデータ構造で、当初はリンク定義部分の構文解析とコード化までを仕上げる予定だったのですが、この部分は来月度に持ち越しとなっております。

リンクは、いずれかのブロック内で定義され、そのブロック内部でのみ参照可能です。class Blockには、内部で定義されたリンクのリスト「links」を用意して、この下にブロック内で定義されたリンクのリストを置くこととします。

コンパイラはトークンを順に読み込んで処理するのですが、名前が現れた時点では、これがリンクであるかリンクリストであるかを区別することができません。そこで、処理を簡単にするため、リンクとリンクリストは同じデータ構造で表現することとします。

このようなことを可能とするためには、class Linkには、リンクを構成する数値情報を格納するためのいくつかのclass Wireへのポインタと、それがリンクリストである場合にその要素であるリンクへのポインタリストchildrenを準備しておきます。コンパイラは、名前が現れた場合、いずれかの親の下にclass Linkを作って名前をセットする、というわけです。

コンパイラの処理を簡単にするため、class Blockに置かれるlinksは、class Linkとしておき、そのchildren部分にブロック内で定義されたリンクのリストを保持するようにいたします。

代入式左辺でリンクが定義された場合は、これをブロック内で定義されたリンクのリストに追加するとともに、代入先のリンクのリストとして別途保持する必要があります。

代入先左辺には、かっこで指定される一時的なリンクリストも記述可能であり、この場合は全体のリンクリストは、代入先リンクリストにのみ保存され、かっこの内部で定義された個々のリンクがブロックのリンクリストに追加されます。

一時的なリンクリストは、class LinkTreeとして、class Linkとは異なるデータ構造とします。class LinkTreeは、リンクを構成するWireに関する情報は持たず、ブロック内で定義されたリンクリストの特定のリンクに対するポインタをもちます。

ここまで決めておけば、あとは文法に従って機械的にデータ構造を形成すればよいはずなのですが、これにはそれなりの時間がかかり、その時間がとれないというのが今月度の問題でした。

DAシンポジウムのアブストラクト締め切りが6月24日となっており、かなり厳しい状況です。6月は比較的時間に余裕がある見通しではあるのですが、あまりいい加減な発表もできませんので、一定の見通しが得られない場合は発表を延期することといたします。

来年度に発表を延期するメリットは、来年度のHPCSも狙えるという点で、これはこれで魅力的でもあります。ここは、あまり深刻に考えず、できる範囲でやることといたします。

その他、今月度は、東京ビッグサイトで開催されました「組込みシステム開発技術展」をみてまいりました。最近はやりのIoT関連ということでかなりの人出ではありましたが、注目すべき展示は特に見当たりませんでした。とはいえ、この業界が活況を呈しているということ自体は、ありがたい話ではあります。
posted by 管理人 at 09:51| Comment(0) | TrackBack(0) | 日記

2016年05月01日

4月度概況

access1604.jpg4月度の弊社HPへのアクセスは図のようになりました。概ね従来通りです。

今月度も引き続きコンサルティング業務が多々入っておりますが、隙間の時間を利用して、mhdlコンパイラに関する考察とコーディングを続行しております。

先月度は、ブロック定義をツリー構造にするアルゴリズムについて述べましたが、今月度は、トークン切り出し部分と組み合わせてコーディングして動作を確認しております。

作成したプログラムは、入力されたソースコードからコメントと空白を除き、閉じかっこ以外の記号で終わる行に次の行を接続しながら、トークンを切り出します。トークンは、コード中に記述された文字列と、種類を示す整数と、ソースコード中の位置情報を含みます。ソースコードの文は、レベルと、ブロック定義文であるか否かを示すフラグ、およびトークンのリストに変換され、次いでブロック定義ツリーに変換されます。

以下のソースコードを処理した例をご紹介します。(段差が正しく表示されるよう、半角ブランク二つを全角ブランク一つに変更しています。)

block1.out(a,b)
  out = block2(a,b)+ //comment
    block3(a,/*comment*/b)
  block2.out(a, b)
    out = a * b
  block3.out(a, b)
    out = a / b
block4.out(a, b)
  out = a - b

“//”から行末までと“/*”と“*/”に挟まれた部分はコメントとして読み飛ばされ、演算子“+”で終わる2行目は3行目に継続して一つの文を形成します。英字に始まる英数字の並びは名前、数字に始まる特定のパターンは定数、記号は一つまたは二つでそれぞれの記号を表し、単一のトークンとはなりえない文字が現れた時点で新たなトークンの始まりとみなされます。ブランクは、トークンを区切りますが、それ自体はトークンとはなりません。

以下が、上のソースコードを変換した結果で、ブロックツリーとして格納されたデータ構造を、今度は字下げで表現しています。“[]”で囲まれたものがそれぞれのトークンです。コメントの削除や継続行の接続も正しく行われ、それぞれ名前や記号に切り分けがなされております。

[root]
  ------ blocks ------
  [block1][.][out][(][a][,][b][)]
    ------ exprs ------
    [out][=][block2][(][a][,][b][)][+][block3][(][a][,][b][)]
    ------ blocks ------
    [block2][.][out][(][a][,][b][)]
      ------ exprs ------
      [out][=][a][*][b]
    [block3][.][out][(][a][,][b][)]
      ------ exprs ------
      [out][=][a][/][b]
  [block4][.][out][(][a][,][b][)]
    ------ exprs ------
    [out][=][a][-][b]

ソースコードとしては許されないのですが、実験的に“out = a <>!==!>< b”なる文字列からトークンを切り出してみました。結果は“[out][=][a][<>][!=][=][!>][<][b]”となります。ここで、“<>”、“!=”および“!>”は2文字からなる演算子として登録しています。最後の“!>”は、普通には見かけない演算子ですが、“<=”と同じ意味としています。
これができますと、次は数式をブロックダイアグラムに変換する処理ということになるのですが、その前に、“リンクリスト”の概念について、改めてまとめておきましょう。

リンクリストが必要になるのは、ブロックの入出力が複数のポートをもつことができるからで、複数の出力ポートをもつブロックを参照する際には、複数の出力信号を参照側で扱う必要があります。このためには、代入文は複数のリンクを扱う機能が必要で、その左辺にも複数のリンクをおく必要が生じます。

複数のリンクをひとまとめにして表現するため、“(link1, link2, ...)”なる形式を用いることとします。この形式は、C言語などでも関数定義や関数呼び出しの引数部にも表れるのですが、mhdlでは、一般の演算においても同様の記述を行うことで複数のリンクを扱えるようにし、これをリンクリストと呼びます。

ブロック定義文は“name.(out1, out2)(in1, in2)”などの形で、ドットに続く最初のリンクリストが出力ポートを、その後のリンクリストが入力ポートを定義します。複数の出力ポートを持つブロックを参照する際には、たとえば次の代入文を用います。

(q, r) = div2(n, d)

ここで、div2は商と余りを返す除算機能ブロックで、この記述により商と余りがそれぞれqとrに入力されます。

代入文左辺やブロック定義文の入出力ポート定義部分に現れるリンクリストは、リンクの並びでなければいけませんが、代入文の右辺では、式の並びをリンクリストとすることも可能です。たとえば次のような記述が許されます。

(sum, dif) = (a + b, a - b)

以上は、これまでのmhdl処理系にも含まれていた機能ですが、これを拡張することで、mhdlにC言語に近い機能を与えることを考えます。これらは現在構想中のもので、当面はこれらの一部のみを実装したサブセット版を作っていく予定ですが、全体を見据えたデータ構造としておく必要があるため、暫定的にフルセット版の仕様を考えておきます。

まず、リンクリストには固有の名前を付けることを可能とします。“dat1.(q, r)”は、二つのリンクqとrからなるリンクリストdat1を定義します。このリンクリストの要素に参照する際には、dat1.qなどのように、リンクリスト名の後にドットを付けてこの後に要素名を記述します。

リンクは信号線に相当し、リンクリストは信号線の束に相当します。それぞれの信号線には名前がついているのですが、信号線の束にも名前を付ければ、異なる束に同じ名前の信号線があっても、これらは別個のものとして識別されます。

名前付きリンクリストの要素は、それが定義されるごとに追加されます。リンクの定義は、ブロック定義文の入力ポート記述部分と代入文の左辺で行われます。たとえば、次の文

x.a = 式1
x.b = 式2

では、最初の文でリンクx.aをもつリンクリストxが形成され、次の文でこれにx.bが追加されます。

リンクリスト名を用いる利点は、複雑なリンクの集合体を一つの名前で扱えることで、xが上のように定義されている場合、“block1(x.a, x.b)”とせずに“block1(x)”のように、リンクリスト名で複数のリンクをポートに接続することを可能とします

リンクリストの要素として、リンク以外に、リンクリストも許すこととします。リンクリストのリストは、名前で定義する場合はx.y.aのようにドットを二回用いて指定します。また、((a, b), (c, d))のように、かっこを二重に用いることでも定義できます。

カッコを何重にも用いれば、リンクリストのリストのリストなども記述することができます。このようなリンクリストをわかり易く表現するため、「リスト」が何回現れるかを「階数」と呼ぶことにします。単純なリンクは階数0のリンクリストであり、リンクリストのリストは階数2のリンクリストです。

リンクリストの要素の定義、参照は、リンクリスト名に続けて“@”と番号を記述することでもできるようにします。一例を以下に示します。この形式で宣言された個々のリンクは名前をもちません。

x@0 = 式0
x@1 = 式1

@はCにおける“[]”と同じ働きをするのですが、あえて別の記号を用いる理由は、式の優先順位を規定するかっことして“()”“{}”“[]”の三種類を使用できるようにするためです。それぞれのかっこは同じように使用できますが、開きかっこと閉じかっこの対応は同種のものに限定されます。これにより、通常の数式と同じ記述を可能とし、かっこの多い式の可読性が改善されます。

@の後にはリスト(右辺では式のリスト、左辺では定数のリスト)を置くことができ、これにより部分的なリンクリストも指定できます。たとえば、x@(2, 3) = div2(n, d)とすると、x@2およびx@3が定義され、これらにdiv2の二つの出力が接続されます。なお、@の後に置くリストの階数は0または1に限定され、階数2以上のリストは置くことができません。

多数のリンクからなるリンクリストを容易に扱えるよう、“:”を使用して範囲指定できるようにしておきます。すなわち、“x@(0, 2:4)”と記述すると“x@(0, 2, 3, 4)”と記述するのと同じ意味を持ちます。

この形式は、定数リンクリストを作るためにも使用可能とします。すなわち、式の右辺に(0:3)と記述すれば(0, 1, 2, 3)と同じ意味となります。また、(3:0)とした場合は、(3, 2, 1, 0)と解釈します。この機能をCのforと同様の機能を持たせるため、二番目の“:”に続けて増分因子を指定できるようにします。すなわち、(0:6:2)は(0, 2, 4, 6)、(6:0:2)は(6, 4, 2, 0)と解釈します。

@を用いて高階数のリンクリストの要素を指定する場合には、“x@3@2”のように記述することで、階数2のリンクリストであるxの3番目のリンクリストの2番目のリンクを参照します。x@(0, 1)@(0, 1) = ((x00, x01), (x10, x11))と定義されているとき、x@0は(x00, x01)を、x@(0:1)@0は(x00, x10)を参照します。

左辺に表れるリンクリストの要素として、リンク名と@形式を混在させることも許します。リンク名は、現れた順にリンクリストに追加されます。同じリンクが複数回左辺に表れてはならないため、@形式のリンク指定を左辺に使用する際には、名前で指定されるリンクよりも後のリンクを指定する必要があります。なお、右辺で参照する際には、名前をもつリンクも@形式で指定することができます。

@を用いたリンクリストのアクセスは、個々のリンクに名前を付ける必要がないという意味がありますが、そのほかにもいろいろな応用が可能です。

第一に、リンクを配列的に扱うことが可能となります。

第二に、if式の拡張版として使用されます。すなわち、mhdlは論理真で1, 偽で0となりますので、“c ? b : a”は“(a, b)@c”と記述することができます。@形式を用いる利点は、選択が二つに限られないことであり、@の後に整数式を置くことにより、マルチプレクサないしcase文と同様の記述が可能になります。言語仕様を簡素にするため、“?”と“:”を用いるif式は仕様から除外いたします。

リンクリストに対する演算は、リンクリストに含まれるそれぞれのリンクに対する演算を並べて記述する形に展開されます。すなわち、(a, b, c) = (p, q, r) + (x, y, z)は、a = p + x, b = q + y, c = r +zと展開して処理されます。リストの途中に複数の出力を持つブロックが現れた場合は、その部分はまとめて処理されます。

ブロックが配設される際に、ブロックの入力として定義されているよりも高い階数のリンクリストが与えられた場合は、複数のブロックを配置したリストが形成され、これらのブロックの入力にはリンクリストの要素が順次与えられます。たとえば、単一のリンク(階数0)を入力として、1クロック遅れた信号を出力するブロックdelay(in)に複数の入力(階数1)が与えられた場合は、複数のdelayブロックが配設されます。すなわち、

moving_ave.out(in)
  x@(0:6) = delay(in, x@(0:5))
  out = sum(in, x@(0:6)) / 8

とすることで、二行目は以下のように展開され、移動平均が算出されます。

x@0 = delay(in)
x@1 = delay(x@0)
x@2 = delay(x@1)
x@3 = delay(x@2)
x@4 = delay(x@3)
x@5 = delay(x@4)
x@6 = delay(x@5)

sumは任意の数の入力に対して和を演算するブロックで、sumの入力ポートが階数1のリンクリストとして定義されていれば、リンクリストの各要素が単一のsumブロックの入力に与えられます。

リンクリストの演算において、リストに含まれるリンクの数が異なる場合は、次の規則に従って処理します。

・左辺のリンク数が少ない場合は、右辺の余分なリンクに対する演算は無視されます
・右辺のリンク数が足りない場合は、直前に表れたリンクがコピーされます

たとえば、左辺がリンク数3の場合、右辺に表れる(a, b)は(a, b, b)と、aは(a, a, a)とみなします。この規約により、ベクトルのスカラー積も自然に書き下すことができます。

同様に、リンクリストの一部が省略された場合は、その前の最後に書かれたリンクが記述されたものとみなします。この規約は、マルチプレクサで複数のセレクタ値が同じ信号を選択する際に有用となります。たとえば、x = (a,, b)@selは、selが0と1の場合にaを、2の場合にbを選択します。

リンクリストに対するもう一つの演算子として、降階演算子“'”を準備します(かっこを外す「皮むき」という意味で、ピーラーなりストリッパーと呼んだほうが良いかもしれません)。降階演算子は、リンクリストの後ろに記述し、その前のリンクリストの階数を一つ低下させる作用をします。すなわち、((a, b)’, (c, d)’)は(a, b, c, d)を意味します。

この演算子が意味を持つのは、リンクリスト名を用いる場合で、たとえばdat1.(q, r)とdat2.(q, r)に対して(dat1, dat2)とすれば((dat1.q, dat1.r), (dat2.q, dat2.r))と解釈される一方、(dat1’, dat2’)とすれば(dat1.q, dat1.r, dat2.q, dat2.r)とすることができます。

なお、この部分については、現在検討中であり、(dat1, dat2)と書いただけで(dat1.q, dat1.r, dat2.q, dat2.r)と解釈するのが妥当であるかもしれません。なにぶん、(dat1)が(dat1.q, dat1.r)と解釈されますので。この場合は、((dat1.q, dat1.r), (dat2.q, dat2.r))と解釈させたい場合は((dat1), (dat2))と記述することになり、降階演算子は不要になります。

実は、(in, x@(0:5))という書き方は、後者の記法にもとづくもので、降階演算子を用いる場合は(in, x@(0:5)')とするのが正しい書き方です。降階演算子を用いれば厳密な記述が可能となるのですが、記述が少々不自然になる点が悩ましいところです。

リンクリストは、元々は複数の出力を持つブロックを扱うために、入力ポートの記述形式と統合する形で導入されたものですが、インデックス参照を可能とする@演算子といくつかの規約を導入することで、次のような機能も実現されます。

・配列的記述
・if式とcase文(マルチプレクサ)
・ベクトル演算(for文に類似した機能)

CPUには、配列に対応するインデックス付アドレッシングや、if・for・whileに対応する条件付きジャンプ命令があるのですが、パイプライン処理装置には機能ブロックとリンクしかありません。あえてCに類似した記述方法とせずに、リンクリストを用いて記述することで、実装との対応をわかり易くし、効率的な論理の記述が可能となると期待しております。
posted by 管理人 at 07:45| Comment(0) | TrackBack(0) | 日記

2016年04月01日

3月度概況

access1603.jpg3月度の弊社HPへのアクセス状況は図のようになりました。3月は、大学などの春休みの影響で、例年多少アクセスが減少するのですが、これを織り込めばほぼ従来通りといったところでしょう。

先月度応募いたしましたHPCS2016ですが、不採録という結果となりました。今回の発表は、従来行ったいくつかの発表を紹介し、これらを総合した形で新しい数値計算の可能性を示すというのが趣旨なのですが、肝心の新しい数値計算の可能性を示す部分の書き込みが少々不足しておりました。

これをきちんと行うには少々時間が足りなかった、というのが本音ではあるのですが、何とかなるであろうと考えたのが判断ミスで、時間の無駄をしてしまいました。ただ、この時点で改めて全体を見直す機会が得られたという意味では、全くの無駄でもなかろうと考えております。

さて、HPCSがだめとなりますと、2年に一度の発表はどうするか、という問題が改めて生じるのですが、当初発表を計画しておりましたDAシンポジウム2016の論文募集が公表されております。論文締め切りはアブストラクトが6月24日、最終論文が8月12日と、かなりの余裕があります。これなら、CodeSqueezer2.0も何とかなるかもしれません。ある程度のバグを許容する形でCode Squeezer2.0のβバージョンを作成して発表するというのが、さしあたりの目標となるでしょう。

と、いうわけで、先送りいたしましたコンサルティング業務が立て込む中、コンパイラを仕上げる作業を開始いたしました。こちらにつきましても、簡単にご紹介いたしましょう。

まず、CodeSqueezerは、「mhdl」と呼ばれる構造化数式記述言語で記述された演算仕様を、演算機能を持つブロックをリンクと呼ばれる信号線で接続した「ブロックダイアグラム」に変換し、外部入力の仕様(ビット幅など)に応じて、それぞれのブロックをVerilogHDLの単純な文に対応するノードをVerilogHDLのWireに対応するワイヤで接続した「ノードグラフ」に変換するという過程を通して、VerilogHDLに変換します。

ブロックダイアグラムをノードグラフに変換するのは、ブロック毎に準備された「コーダ」により行います。mhdlコンパイラがおこなうべき作業は、mhdlで記述された演算仕様をブロックダイアグラムに変換する作業ということになります。

mhdlによる演算仕様の記述はブロック定義の形で行います。ブロックは、名前と入出力ポートを規定するブロック定義文と、そのブロックの演算処理を規定するいくつかの代入文と、ブロック内部でのみ使用するいくつかのブロック定義から成り立っています。ブロック定義の範囲は、字下げによって規定され、ブロック定義文よりも深い字下げが続く範囲の代入文とブロック定義文が、そのブロックに含まれます。

このような処理は、これまでに公開しているCodeSqueezerでも行っているのですが、あまり整理された形でコーディングされているとはいいがたく、きちんとした形に書き改める必要があります。そこで、3月度は、字下げの形で記述されたブロック定義を、ブロック定義の包含関係を規定する「ブロック定義ツリー」の形に変換する部分を記述いたしました。

この部分のアルゴリズムは、以下の通りです。

(0) Blockクラスに、親ブロックへのポインタparentと子ブロックへのポインタのリストchildren、このブロックに含まれる代入文のリストexprsおよびブロック定義のレベルを示す整数をメンバ変数として用意しておきます。
(1) mhdlの文を一つ読み込む関数:行頭のブランクの数(レベル)とブロック本体をIndentクラスとして返します。このクラスには、この文がブロック定義であるか否かのフラグも含めておきます。
(2) 最上位ブロックrootを定義し、この下にすべてのブロック定義を置くものとします。rootのレベルは-1とします。また、現在処理中のブロックを表すcurの初期値をrootとします。
(3) 親ブロックとなりえるブロックへのポインタを格納する親候補スタックを準備します。
(4) curをスタックにプッシュします。(curが親にもなりえるため)
(5) 新しい行を読み込みます。ソースコードの終わりに達したら処理を終えます。
(6) 新しい行が親候補スタック最上段のレベルに等しいか浅い間、親候補スタックをポップします。
(7) 新しい行がブロック定義文なら、ブロックを作成してcurとしてスタック最上段のchildrenに追加します。
(8) 新しい行が代入文なら式に変換し、スタック最上段のexprsに追加します。
(9) (4)に戻ります。

mhdlのソースコードにはコメントや継続行が含まれますが、ブロック定義ツリーに変換する前に、これらは取り除き、文単位にまとめる処理がなされます。エラーが発生した場合には、ソースコードのどの行にエラーがあったかを表示する必要があるのですが、この処理に伴いプログラムの要素が持つ行情報が失われてしまいます。そこで、mhdlの行を読み込む際に、有効な文の要素をトークンとして切り出し、トークンに行情報をもたせるようにします。トークンは、名前、定数、記号などのプログラムを構成する原子的要素で、行情報のほかに文字パターンをもたせてエラーメッセージに反映させるようにします。

以上が、これまでに作成した部分です。後は、以下の作業が残っております。

・トークンへ切り出し:正規表現を用いればすっきりとしたコードでできそうです。
・代入文の処理:複数の代入を可能とするため、リストの形での処理が必要となります。数式処理は、複数の演算子を同時に処理する「スーパーブロック」を用いれば、コンパイラ自体は比較的簡単に記述できそうです。スーパーブロックのコーダが必要になるのですが、最終的にコーダ部分はコンパイラとは別扱いとし、あとでも修正可能な形にしたいと考えております。
・コーダ:各種基本的機能を持つブロックのコーダと、ユーザ定義ブロックのコーダを作成します。

さて、6月までにこれら作業が完了いたしますでしょうか。アブストラクトは見切り発車という手もありますが、あまり好ましいことではありません。コンサルティングもまだ入っておりますので、スケジュール的にはかなりきついのですが、ここは何とかするしかありません。
posted by 管理人 at 14:33| Comment(0) | TrackBack(0) | 日記

2016年03月04日

2月度状況

access1602.jpg2月度のアクセス状況は図のようになりました。ほぼ従来通りで推移しております。

今月度の特記事項は、HPCS2016の論文アップロードを行なったこと。かなり厳しいスケジュールでしたが、無事2月5日の締め切りに間に合いました。あとは、3月下旬に出るはずの結果待ちということになります。

この論文作成のため、コンサルタント業務のかなりの部分が3月にずれ込んでおります。こちらもそれぞれ締め切りがあるため、これに間に合わせなくてはいけません。この業務に追われ、このブログも少々書き込みが遅れてしまいました。楽しみに待っておられた方にはご迷惑をおかけしました。申し訳ありません。

論文の方は結果待ちということで、しばし作業は発生しないのですが、それまでの間にコンサルティング業務を片付けなくてはいけません。そういうわけで、このブログも、今月度はあまり書いてもおられません。論文を書きながらつらつら考えたことも多々あったのですが、またの機会のご紹介とさせていただきます。
posted by 管理人 at 20:30| Comment(0) | TrackBack(0) | 日記

2016年02月01日

1月度概況

access1601.jpg1月度の弊社HPへのアクセスは図のようになりました。このところ多少増加しているような印象も受けますが、まずは従来レベルといえる状況でしょう。

今月度の特記事項は、本年の6月6日から7日にかけて仙台で開催されますHPCS2016(2016年ハイパフォーマンスコンピューティングと計算科学シンポジウム)での発表を申し込んだこと。エントリー締め切りが1月29日、論文アップロード締め切りが2月5日という、かなり厳しいスケジュールとなっております。

本年度の学会発表につきましては、例年8月末に開催されておりますDAシンポジウムで行うことを当初計画したのですが、情報処理学会のカレンダーをみたところ、このシンポジウムの開催はまだアナウンスされておりません。その一方で、HPCS2016の募集案内が目にとまったのですね。

HPCSは「ハイ・パフォーマンス・コンピューティング」をうたっておりまして、FPGAを用いる高速演算装置を発表するにはまさにぴったりの場です。一方のDAシンポジウムは「デザイン・オートメーション」であり、開発環境が主体となります。どちらで発表するのがベストかといえばもちろんHPCS。そこで、厳しいスケジュールをやりくりして、こちらでの発表を目指すこととした次第です。

1月度も、コンサルタントの業務がいくつか入っていたのですが、打ち合わせや今月締め切りのレポート以外は2月6日以降に処理することとして、何とか2週間程度の時間を確保いたしました。論文につきましては、おおよその部分はできておりますが、まだまだ見直しが多々必要です。なんとかこれを2月5日の締め切りに間に合うように完成させなくてはいけません。

2月5日さえ乗り越えれば、発表関係の残る仕事は6月6日の発表までにプレゼン資料を作ることだけ。かなり余裕が出てまいります。もちろん、先送りしておりますコンサルティング業務をそれぞれの締め切りに間に合わせなければなりませんので、2月もかなり大変な月になりそうではあります。

発表内容につきましては、これまでと同様、発表日以降にHPに掲載いたします。ご期待ください。
posted by 管理人 at 15:01| Comment(0) | TrackBack(0) | 日記

2016年01月06日

12月度概況

あけましておめでとうございます。

本年は、正月早々から公私に様々な案件が立て込み、このブログも更新が遅れましたことをお詫びいたします。

access1512.jpg昨年12月度の弊社HPへのアクセスは図のようになりました。ほぼ平常通りといったところです。

昨年から立て込んでおりますコンサルティング業務ですが、ここにきてますます増加し、他の業務がほとんど手を付けられない状況となっております。

コンサルティングはコンサルティングでお金になりますので、たくさん入ることは悪い話でもないですし、CodeSqueezer2.0に締め切りがあるわけでもありませんので、柔軟に対応する考えで取り進めております。

本業につきましては、これまで2年に一度のペースでDAシンポジウムにおきまして技術発表を行っております。これまでのペースで発表すると致しますと、本年が発表の年にあたり、開催日は例年通りであれば8月末ということになります。

当初の予定では、この場でCodeSqueezer2.0の技術内容について説明したいと考えていたのですが、例年どおりですと、論文締め切りが5月の頭、アブストラクトがその1月ほど前となっており、これまでにCodeSqueezer2.0に見通しを付けることはとても難しいと思われます。

一つの考え方として、発表を一年先送りにするという手も考えられるのですが、そろそろ現在やっております研究の外枠を明らかにしても良い頃合いということもあり、こちらの発表を行うという方向で取り進めたいと考えております。

この発表、仮題は「次世代コンピューティングのためのデザイン・オートメーション」、内容はパイプライン演算方式の汎用コンピュータの構成に関わるもので考えております。

このコンピュータの基本構成は、は昨年の本ブログ「5月度進捗」に記載いたしました公開特許(特開2015-091045)に基づくもので、今日でも実現可能な論理規模のFPGAを用いて大規模な数値演算を高速実行するというもの。ハードウエア部分にはさほどの技術的困難さはないと思われるのですが、鍵になるのは論理形成方法、すなわちデザイン・オートメーションであろうと考えております。

これを実現するための個々の技術に関しては、既に隔年のDAシンポジウムの場で発表済みです。2010年にはパイプライン演算に適した浮動小数点表現と有効桁のみを演算する論理の形成方法を発表し、2012年には数式からパイプライン演算論理を作り出すためのコンパイラを発表、2014年には誤差キャンセルが生じる場合にも情報が失われない論理形成手法について発表しております。

今回の報告は、このような汎用のパイプライン演算を行うためのハードウエアの概要と、それぞれの技術がどのように組み合わされるかということ、そしてこのように実現されたパイプライン・コンピュータと現在広く用いられておりますCPUで演算を行うコンピュータとの比較を中心に述べたいと考えております。

デザイン・オートメーションの部分は、過去の発表のまとめであり、ハードウエアに関しても特許の形で公開されてはおりますが、これら個々の独立した発表からはそのつながりはみえてこないでしょう。これらをまとめた形で全貌をご紹介することで、それぞれの技術が持つ本当の意味を分かっていただけるのではないか、と期待しております。

先ほどIPSJのページをのぞいてみたのですが、情報処理学会の2016年の予定は、まだ発表されておりません。間もなく出てくるものと思われますので、予定に後れを生じないよう、この先、チェックしていきたいと考えております。

具体的アクションに関しましては、本ブログで都度ご報告する予定です。ご期待ください。
posted by 管理人 at 10:42| Comment(0) | TrackBack(0) | 日記

2015年12月01日

11月度進捗

access1511.jpg11月度の弊社HPへのアクセス状況は図のようになりました。一言でいえば、変わらず、といったところです。

CodeSqueezer2.0のリリースは本年末を予定しておりましたが、コンサルティング業務に追われて開発が遅れ、本年末のリリースは不可能と判断せざるを得ない状況となりました。現在公開中の旧版は、本年末で使用期限が切れてしまいますので、これを延長したバージョンをHPにアップロードしておきました。

新バージョンにつきましては、その技術的詳細を来年夏に予定されておりますDAシンポジウムで発表したいと考えているのですが、発表申し込み締め切りが来年5月の初旬頃となっており、これまでに見通しを立てることができないと、この発表も1年延期とせざるを得ません。

期限が特にないとは言いましても、あまりずるずると遅らせることも好ましいことではなく、何とか4月末ごろまでには見通しを付けたいところです。

とはいえ、コンサルティング業務も、さらに新規の案件がいくつか入っており、年内はほとんどコーディングに避ける時間が取れそうにありません。こちらはできる限り前倒しで処理して、何とか時間を作るようにしたいと考えております。

その他、今月度は、パシフィコ横浜で開催されました“ET/IoT総合技術展”を見学してまいりました。表題に“Internet on Things”が加わっているのが目新しいところですが、展示内容はさほどの変化もないようです。展示会自体は盛況で、この業界には、まだまだ元気があります。
posted by 管理人 at 15:53| Comment(0) | TrackBack(0) | 日記

2015年11月01日

10月度進捗

access1510.jpg10月度の弊社HPへのアクセス状況は図のようになりました。ほぼ平常通りです。

このところコンサルティング業務を大量に抱え、本日も休日返上でレポートを書いております。

コンサルティングは、基本的に、可能なテーマであればすべて引き受けるようにしているのですが、いよいよキャパシティが足りなくなりそうです。時間不足で不十分なレポートを提出することも避けたいところです。この先は、少し調整することも考える必要がありそうです。

この手の仕事は先方次第ですので、いずれ暇な時もあろうかと考えていたのですが、なかなか暇ができず、CodeSqueezer 2.0の開発が完全に停滞しております。とはいえ、コンサルティング需要の先も読めませんし、CodeSqueezer 2.0の納期が特にあるというわけでもありませんので、当面はこのような形で取り進めたいと考えております。
posted by 管理人 at 11:10| Comment(0) | TrackBack(0) | 日記

2015年10月01日

9月度進捗

access1509.jpg9月度のアクセス状況は図のようになりました。予想通り、夏休みが影響したと思われる8月度の落ち込みから回復しております。

今月度の特記事項といたしまして、つい先日の9/28に、演算論理の自動形成に関わる弊社特許出願が「特開2015-170028」として公開になっております。これは、有効桁のみを処理する数値演算論理を自動形成する手法に関わるもので、誤差キャンセルがある場合にも情報が毀損しない論理を構築する手法に関わるものです。

この手法につきましては既に昨年のDAシンポジウムで発表しておりますが、数値演算論理の自動形成に関する弊社の基本的なコンセプトは、DAシンポジウムでの3回の発表でおよそカバーされた形になっております。これらに関わる情報は、いずれも弊社HPよりアクセス可能となっております。

さて、肝心の業務進捗状況ですが、ここにきてコンサルティング業務が立て続けに入り、CodeSqueezer 2.0開発作業はほとんど進んでおりません。この調子では、年内の評価版公開はかなり難しそうです。

ただ、CodeSqueezer 2.0評価版を年内に公開するという目標はあくまで目標であり、遅れたことによる問題は特に発生いたしません。これに関しましては、できる限りのことをする、という姿勢で臨みたいと考えております。
posted by 管理人 at 15:09| Comment(0) | TrackBack(0) | 日記

2015年09月01日

8月度進捗

access1508.jpg8月度のアクセス状況は図のようになりました。弊社サイトへは大学関係からのアクセスも多いためだと思いますが、例年夏休みの時期にはアクセスが減少しております。本年8月も落ち込みが認められますが、これは例年同様であると考えておくべきでしょう。

8月度は、ソフト開発にかなりの時間をさけると期待していたのですが、新たなコンサルティング業務が舞い込んだこともありまして、ソフト開発はほとんど進展しておりません。

コンサルティングに関しましては、その内容はオープンにできませんが、面白い話が種々あり今後の進展に期待しているところです。いってみれば、先方がやらないのであればこちらでやってしまっても良いかな、などと思わせるような話なのですね。もちろん現時点では先方にボールがあるわけで、こちらは依頼された業務を粛々と進めるだけなのですが。

9月度もまたコンサルティング業務にかなりの時間をとられる見通しで、CodeSqueezer 2.0を本年末までに公開しようという当初のプランには赤信号が灯っております。パイプライン処理に関しては、業界内の動きを思わせるようなニュースが多少は出ているのですが、まだまだ本格的な動きとはなっておりません。つまり、まだまだ時間はあるということで、こちらはこちらで着実に進めればよいと判断しております。
posted by 管理人 at 11:00| Comment(0) | TrackBack(0) | 日記

2015年08月02日

7月度進捗

access1507.jpg7月度のアクセス状況は図のようになりました。例年夏休みになりますと多少の落ち込みがあるのですが、本年はまださほどでもないといったところでしょうか。もちろん夏休みの本番は8月ですので、これからもう少し下がるかもしれませんが。

7月度は、コンサルティング業務のため、ソフト開発はいったん休止しております。とはいえ、この業務は既にほぼ片付いておりますので、8月からはソフト開発にかなりの時間をさける見通しです。

その他につきましても、7月度は新しい情報はありません。夏枯れ、といったところです。
posted by 管理人 at 11:06| Comment(0) | TrackBack(0) | 日記

2015年07月02日

6月度進捗

access1506.jpg6月度の弊社HPへのアクセス状況は図のとおりで、平常の水準で推移しております。

このところコンサルティング業務がかなり入っており、CodeSqueezer2.0の開発は遅れ気味ですが、それでも少しずつ着実に前に進めております。まずはデータ構造をきちんと作ることに注力しております。

以前、標準ブロックをDLLファイルで与える形としてユーザ定義標準ブロックも使えるようにしようと計画しておりましたが、.NETの様々な機能が使えないという問題に遭遇いたしました。.NETでも、おそらくはDLLを利用する方法があろうかと思いますが、前回は開発時間を優先して.NETの機能を使わない形でコーディングいたしました。しかしながら、このような形のコードは可読性に劣り、デバッグに時間がかかるとの問題も生じております。

.NETを使用しないコーディングは、他のOS(たとえばLinuxなど)への移植を考えれば意味があろうと当初は考えていたのですが、DLL化を可能とすれば結局はウィンドウズを前提とするコードとならざるを得ず、DLL化コードが素早く書けるという意味しかありません。

結局のところ、.NETの機能を使わずにDLL化を急ぐという当初方針は、労多くして実り少ないことが分かりました。今回開発いたしますCS2.0は、誤差キャンセルへの対応を主眼としておりますので、さしあたりはユーザ定義標準ブロックは先送りすることとし、.NETの機能を使用してコーディングを進めることといたしました。

DLL化につきましては、今後.NETの機能を使いつつDLL化する手法をマスターして取り進めることとしたいと考えております。

その他、3月度進捗でご紹介したインテルによるアルテラ買収ですが、最終的に買収が決定したとのニュースが6月初めに流れております。インテルのFPGAへの取り組みは、CPUでユーザ定義コマンドを使用可能とするといった話が以前流れており、複雑な数値演算をパイプライン論理で一括処理するという当社の狙いとはかなり異なる可能性もありますが、技術の流れとして同じ方向であることには違いなく、多少は心強いニュースではあります。
posted by 管理人 at 11:21| Comment(0) | TrackBack(0) | 日記

2015年06月01日

5月度進捗

access1505.jpg5月度の弊社HPへのアクセス状況は図のようになりました。連休後は、ほぼ従来並みといえるでしょう。

5月度はふたたびコンサルティングの業務が立て込み、ソフト開発は遅々としております。また、今月度は、組み込みシステム開発技術展とテクフロンティア2015という二つの展示会を見学してまいりました。いずれも盛況、特にテクノフロンティアは、一角に設けられておりましたドローン展に黒山の人だかりでした。首相官邸の一件が大いに宣伝になったようですが、これを喜んでよいやらいけないやら、主催者も複雑な心境ではなかろうか、などと考えながら見てまいりました。

先月末から今月初めにかけて、弊社が出願した特許が二件公開されました。これらはいずれも、弊社のソフトの構成要素ではなく、より一般的な周辺技術に関するものです。

まず、特開2015-091045「プログラマブルロジックデバイスおよびこれを用いたコンピュータ」は、FPGAのRAMをコンピュータのメモリー空間にマッピングすることを特徴とするものです。

こういたしますと、FPGAの論理を決定するRAMをコード領域、データ格納用のRAMをデータ領域とみなすことで、CPUからは通常のCPUソフトにきわめて近い形でFPGAを取り扱うことができます。OS経由で論理と入力データをFPGA内部のRAMにロードしてFPGAのコントロールレジスタにクロック数を書き込むことで、FPGAは所定のクロック数だけ演算処理を行い結果をFPGAの内部RAMに残します。

この発明が狙っているのは、実用的な並列演算装置を安価に提供することです。数値演算を実行する論理は大規模となり、現実的な問題を解くような並列演算装置は非常に高価となるのですが、演算処理をいくつかのステップに分割して、それぞれのステップごとに論理を書き換えて実行すれば、小規模なFPGAでも複雑な演算処理が実行可能です。この場合、論理を規定するRAMを二重に設けて制御信号で使用側を切り替えるようにすれば、時間のかかる論理のロードを演算処理と並行して進めることもでき、高速処理が可能となります。

CPUを用いるコンピュータも、以前はメモリ領域の不足に悩まされたもので、今日ではバーチャルメモリーが一般的なのですが、古くはコード領域やデータ領域のオーバーレイという手法も使われておりました。この場合のオーバーレイとは、実行プログラムを複数のステップに分割し、それぞれのステップの実行コードのみを主記憶にロードして実行する手法です。この発明のデバイスは、論理がメモリーとして扱われますので、主記憶に対するオーバーレイはそのまま論理のオーバーレイとなり、少ない論理で大規模な演算処理が実行できることとなります。

弊社がFPGAを製造することは考えておらず、この発明はいずれかのFPGAメーカに採用していただきたい技術です。特許は他社の行動を制約するものですが、本特許に関しては、むしろ積極的に採用を働きかけたいところです。このようなFPGAが製造されることで、パイプライン処理はより一般的に行うことができるようになるはずですし、弊社のソフトもそれだけ市場が拡大するというものです。この特許の出願は、このような動きを推し進める際に何らかの力を与えてくれることを期待して行っております。

第二の公開特許は、特開2015-082152「誤差評価を伴う数値演算方法およびこのための装置」です。弊社の論理形成ソフトは、論理を簡素化するために有効桁のみを取り扱うことを特徴としておりますが、これにより、演算結果の有効性が保証されるという副次的効果もあります。

この副次的効果は、今日のコンピュータでも実現可能です。すなわち、ソフトで誤差を同時に演算すれば、演算結果の有効性を保証することが可能です。このようなことがなぜ行われていないかは、むしろ不思議なことですらあり、これが可能であることが広く知れ渡りますと、誤差の同時演算が一般的に行われるようになるかもしれません。

ソフトで値と誤差を別々に演算することは演算時間の増加を招くのですが、CPU自体に数値と誤差を同時に演算する機能を持たせれば、速度を落とすことなくこれを実現することができます。さらに、浮動小数点表現に改良を加え、値と誤差の双方を表現する数値型とすれば、プログラムを作成する際に何も考えなくても演算結果の有効性を保証することができます。

今回の出願は、このあたりをカバーするものです。この手の演算を弊社が独占するなどという大それたことを考えているわけではありませんが、誤差評価の重要性と技術的可能性に気づいているということはそれなりの優位性があるわけで、囲碁でいえば離れたところにぽつんと石を置いておくような、先々の展開を有利にとり進めるための一手と考えております。

ぜいたくを言えば、このような浮動小数点型仕様を決める際には、弊社がFPGA内部の数値表現に用いている浮動小数点型との変換が容易になるように配慮していただけると助かります。今日多く使用されているIEEE754浮動小数点フォーマットは、メモリーのビット幅節約を主眼に仕様を決めているようなところがあり、演算処理が複雑で処理に時間がかかるという問題があります。今日では、メモリーの価格は非常に低下しておりますので、メモリーのビット幅の圧縮よりも演算の簡素化を優先すべきところ。新しい浮動小数点型の規格検討が行われると致しますと、浮動小数点仕様自体を今日の技術的要請に合致させる良い機会となるように思われます。
posted by 管理人 at 10:23| Comment(0) | TrackBack(0) | 日記

2015年05月01日

4月度進捗

access1504.jpg4月度のアクセス状況は図のようになりました。多少の落ち込みはあるようですが、変動の範囲内といえるでしょう。

4月度は、これまで集中しておりましたコンサルティング業務が一段落し、久しぶりにCodeSqueezer2.0の開発業務に時間を割くことができました。

今月度は、全体構成を改めて検討したのですが、これまで別個のものとしておりましたファンクションダイアグラムと手続きダイアグラムを統一することといたしました。

手続きは、手続きクラス(class Proc)で定義されたデータ構造で、ソースコードに対応した木構造に配置され、名前などはすべて文字列として扱われております。一方のファンクションはファンクションクラス(class Func)で定義されたデータ構造で、処理の流れに対応したダイアグラムとして扱われます。

同じ手続きは、ソースコード中に一回記述すれば何度でも呼び出すことができます。すなわち手続きは、マクロ定義のような、テンプレート的な性質をもち、呼び出される毎にこれに対応するファンクションが生成されます。ファンクションは処理ごとに生成され同じ処理が複数個所で実行される場合は複数のファンクションが生成されることとなります。このため、従来のmhdlコンパイラではこれらを別のものとして取り扱っておりました。

手続きの木構造からファンクションを生成する手続きは図のように行われます。proc_diagram.jpgユーザ定義の手続きは、ファンクションダイアグラムであるファンクションに変換されます。このとき、手続き名がファンクション名となり、文字列である入出力ポート名のリストがclass Portのリストに変換されます。また、内部に配置される手続き名のリストがclass Funcのリストとなります。ここで基本的に行っていることは、文字列をそれぞれのデータ構造に変換しているだけなのですが、これらのデータ構造には文字列で表された名前をもちますので、最初からデータ構造を用いて手続きを規定しても問題はありません。またこうすることで、変換の手間が一回省けるというものです。

そこで、両者を兼用する新しいクラスとしてclass Blockを用いることといたしました。このクラスは、定義の木構造に対応したポインタをもち、それぞれの構成要素はデータ構造として持つことといたします。Blockという名称は、生成されるものが「ブロックダイアグラム」であることから、これを構成する要素の名称としてはブロックが好ましかろうとの判断によります。

従来「手続き(Proc)」なり、「ファンクション(Func)」なりの名称を用いておりましたのは、既存のプログラム言語との共通性を意識してのものだったのですが、基本的に異なるプログラム言語ですので、他の言語との共通性はあまり重要ではないものと今回判断いたしました。

一つ注意しなくてはいけない点として、手続きは定義ごとに与えられるのに対し、ファンクションは配置ごとに異なるデータ構造を準備する必要があります。

これに対応するため、class Blockには配置済みフラグを設け、配置が行われた際にはこれを立てるようにいたします。新たに配置すべきブロックがすでに配置済みである場合は、このブロックの複製を異なる名前で生成し、これを配置するようにいたします。参照に際しては、常にオリジナルのブロック定義を参照しますので、複製されたブロックは、定義の木構造部分は不要です。また、配置済みフラグも参照されることはないのですが、こちらは配置済みとしておくのが分かりやすそうです。

この共通化を行うことでプログラムの簡素化が可能となりそうです。また、これまでに検討いたしましたシミュレーションその他は、ファンクションダイアグラムに対して行っていたのですが、この部分はブロックダイアグラムと全く変わりませんので、これまでの作業も無駄になることはありません。

その他、ファンクションには、これをコード化する関数、動作をシミュレートする関数、テストする関数などが付属していたのですが、これらを個別の関数とすることはソースコードが複雑となりますので、これらをまとめたclass Methodsをブロックのメンバーとすることといたします。やっておりますことは何の変化もないのですが、様々なサービス関数をクラスに含めることで、ブロックダイアグラムはより抽象度の高い記述が可能となり、将来の変更もより容易になるものと期待しております。

あとは、このデータ構造で実際の処理プログラムを制作するだけなのですが、これが一大作業であることは言うまでもありません。ここは一つずつ着実に作業を進めるしかありません。
posted by 管理人 at 16:15| Comment(0) | TrackBack(0) | 日記

2015年04月01日

3月度進捗状況

access1503.jpg3月度の弊社HPのアクセス状況は図のようになりました。ページビューはここ何か月か比較的高いレベルにあったのですが、先月あたりから旧来のレベルに戻しております。なお、3月は多少大きく落ち込んでおりますが、大学関係の春休みの影響ではなかろうかと考えております。

先月度のこのブログに書きましたように、3月はコンサルティング業務が立て込み、コーディング作業はほとんど手つかずとなっております。業務がひと時に集中するのは大変ではありますが、繁忙期と閑散期がはっきり分かれておりますと、ある時期にはコーディング作業に集中できるというメリットもあります。ここは受けた仕事をきちんきちんと遂行するだけです。

その他、パイプライン処理に関係するかもしれないニュースがいくつかありましたのでご紹介しておきます。

その一つは、「グーグルが半導体の設計者を雇う理由」と題する3月2日付BLOGOSの記事で、従来は汎用のCPUボードとハードディスクの組み合わせで巨大なデータ処理を行っておりましたGoogleが、ここにきて半導体の設計に力を入れ始めたとのこと。Googleもいよいよ、CPUから並列処理へと動き出そうとしているのかもしれません。

もう一つは「インテルがAltera買収で交渉中、過去最大の買収」と題する3月31日付の日経新聞記事です。インテルはCPUのトップメーカで、アルテラはFPGAの第2位のメーカ(首位はザイリンクス)。インテルは独自にFPGAの開発を行っているというニュースは過去に流れておりましたが、ここにきてFPGAへの参入を本気で考えているようです。

3月の最初と最後にありましたこれらのニュースを見ておりますと、CPUからパイプライン処理に機械計算の技術のトレンドが変化する、最初の兆候であるかもしれません。もしそうであると致しますと、弊社の読みは的中ということになるのですが、そうならそうで我々のソフトの製品化も急がなくてはいけないという、痛しかゆしの状況でもあります。

いずれにいたしましても、のんびりとやっておられるような状況ではなさそうです。
posted by 管理人 at 11:38| Comment(0) | TrackBack(0) | 日記

2015年03月01日

2月度進捗状況

access1502.jpg2月度のアクセス状況は図のようになりました。このところ上昇しておりました日ごとのアクセス数は、2月に入ってから急速に低下し、ほぼ従来並みのレベルとなっております。この上昇は、専門家コラムの宣伝効果かと考えておりましたが、どうやらこれが当たっていた様子で、宣伝効果もそろそろ薄れてきた、ということでしょう。これは、喜ぶべきことか、悲しむべきことか、少々判断に迷うところです。

先月度よりCodeSqueezer 2.0のコーディングを再開したのですが、ふたたびコンサルティング業務が立て込むようになり、今月度、来月度はほとんどソフト開発ができない状況です。コンサルティングは相手のある仕事ですから、あまりこちらの予定に合わせて行うわけにもいかないのがつらいところ。コーディング作業に特に締切がないこともあり、要望に応じてコーディング作業を前後する形で取り進めております。

コーディング作業のスケジュールですが、これまでに行ってまいりましたCodeSqueezer関連の外部発表は、2年に一度、8月末に開催されますDAシンポジウムで行っております。もっとも新しい発表は昨年に行っておりますので、次回は来年の8月に発表するのが順当なスケジュールということになります。そのように考えますと、CodeSqueezer 2.0の完成もさほど急ぐ必要はなく、本年末あたりを目標に行えばよいということになります。

ただしこれがデッドラインで、その先には応用例としてのFFTコード自動作成ソフトを作成して、学会発表の形を整えなくてはいけません。かなりタイトなスケジュールであるともいえそうです。

いずれにいたしましても、コンサルティングはコンサルティングできちんと行い、ソフトもきちんと作ること、これを基本に今後も作業を続けて行きたいと考えております。CodeSqueezer 2.0を期待している方がもしおられましたら、今しばらくお待ちいただきますよう、よろしくお願いいたします。
posted by 管理人 at 22:14| Comment(0) | TrackBack(0) | 日記

2015年02月01日

1月度進捗

access1501.jpg1月度の弊社HPへのアクセスは図のようになりました。1月に入ってアクセスが多少増加しているようにもみえます。これは、従来からの変動がたまたま多少高い側に出ただけであるのかもしれませんが、先月ご報告いたしました専門家コラムの影響であると致しますと、良い兆候であるのかもしれません。

1月度はまたしてもコンサルティング業務が立て込んで、CodeSqueezerのコーディングはあまりはかどってはおりません。とはいえ、クラス定義のtemplate化につきましては一応完了いたしましたので、多少の進捗はあったともいえます。

コンサルティング業務の一環で、某社よりフーリエ変換に関する相談を受けております。FFTはパイプライン処理の一つの大きな応用分野であるともいえます。今回は、コードの提供を行ったわけではないのですが、種々のFFTコードを自動的に吐き出すプログラムを作成すると、人々に喜ばれるかもしれません。

現在考えております作戦は、mhdl言語で記述されたソースコードを出力するFFT自動形成ソフトを作ろうというもの。

CodeSqueezerに演算仕様を与えるためのアルゴリズム記述言語mhdlにつきましては、2012年度のDAシンポジウムで発表しておりますが、その際に「具体的な応用例を紹介したらよいのではないか」とのコメントを頂いております(詳細は2012年8月度進捗報告に記しました)。いずれCodeSqueezer 2.0が完成した暁には、改めてDAシンポジウムでの発表を考えているのですが、自動FFTコード形成ツールと絡めて発表すれば興味をひいていただけるのではないかと思います。

これを使うためには、mhdlコンパイラが必要である、という商売っ気もないではないのですが、、、
posted by 管理人 at 15:15| Comment(0) | TrackBack(0) | 日記

2015年01月01日

12月度進捗

access1412.jpg12月度のアクセス状況は図のようになりました。このところのアクセス数は、やや増加気味ですが、変動の範囲内であるともいえます。また、12月度は月末にアクセス数が減少しておりますが、大学等の冬休みの影響ではないかと思われます。

今月度は先月度に続きCodeSqueezer2.0の移植作業を行っております。移植の機会にデータ構造などの見直しを行っていること、開発環境のバージョンアップに伴って変更が必要となる個所がいくつかあり、対処方法のよくわからない種々のエラーメッセージが出るなど、作業は遅れ気味となっております。

当初は、12月中にでも新バージョンを公開する予定で、従来の評価版の使用期限を昨年12月末としておりましたが、新しいソフトの開発が遅れておりますことから、従来の評価版の使用期限を本年12月末まで延長いたしました。ダウンロードはこちらからどうぞ。

コンサルティングを行っておりますIBLCから依頼されて同社が公開しております専門家コラムに寄稿いたしました。通常はコンサルティングの顧客に関しては情報を出さないこととしているのですが、本件に関しましては、顧客サイドで情報を公開しておりますので、こちらにもご紹介いたします。正月らしい話題ということで、スケールの大きな夢のある(と自分では考えた)話を書いております。お時間があればこちらもお読みください。

最後になりましたが、明けましておめでとうございます。本年もご愛顧のほど、よろしくお願いいたします。
posted by 管理人 at 12:26| Comment(0) | TrackBack(0) | 日記

2014年12月01日

11月度概況

access1411.jpg11月度の弊社HPへのアクセス状況は図のようになっております。少々増加したようにも見えますが、変動の範囲内でしょう。

今月度は、CodeSqueezerのコーディング作業を大いに進める予定でしたが、種々の事情であまり前には進みません。

今月発生した大問題は、プログラム開発に用いておりましたPCが起動不能に陥ったこと。これでは何もできませんので、直ちに秋葉に走りPCを新調してまいりました。当然のことながら、OSはWIndows 8.1となり、この結果Visual Studioも2013への変更を迫られてしまいました。2013は2008と多くの点で異なっており、これが使いこなせるようになるまで、まだまだ苦労しそうです。

その後いろいろとトライした結果、既存のPCも何とか動くようになりましたが、いつなんどき再びトラブルを発生しないとも限らず、これをプログラム開発に使い続けるわけにもいきません。業務に関しては、新PCに完全移行するしかありません。

PCの移行に関しては、悪いことばかりでもありません。Windowsが8.1になる時代に、いつまでもVistaベースでソフト開発を続けるのも問題であるとは、常々感じておりました。ある意味では、よい機会であったともいえそうです。

今月度は、コンサルティング業務も再び増加しております。これがPCトラブルの影響もあって、かなりの負担となってしまいました。本年末にもCodeSqueezer 2.0のデモ版を公開したいと考えておりましたが、ここにきてかなり困難な見通しとなっております。

その他、今月度はエンベデッド・テクノロジー展を見学してまいりました。最近の景気回復の影響もあってか、かなりの盛況となっておりました。注目しておりますのが、弊社競合企業の登場なのですが、これに関しましてはまだまだ安心できそうな状況です。
posted by 管理人 at 18:58| Comment(0) | TrackBack(0) | 日記

2014年11月01日

10月度概況

access1410.jpg10月度の弊社HPへのアクセスは図のようになりました。ここにきてアクセス数は多少上振れしているようにもみえます。8月末に学会発表をしており、この効果が現れているのであれば嬉しいのですが、変動の範囲ともいえそうです。

10月度は、引き続きコンサルティング業務が入っているのですが、プログラミングに割ける時間もある程度は確保され、CodeSqueezer 2.0のコーディング作業も進めることができました。こちらは、ある程度の評価に耐えるものができた段階でご紹介することと致します。完成目標は年内(12/E)ですが、この段階でお出しできるのは機能のデモにとどまり、テストまで済ませた製品版の完成は現在の進捗状況からは来年にずれ込む見通しです。

現在行っておりますのは、プログラム全体で共通に使用する、いわゆるサービスルーチンの作成で、あまり表には見えない部分です。このあたりをしっかり作りこんでおきませんと、あとで混乱の原因になります。時間に追われて手を抜いたり致しますと、あとで後悔する羽目になりますので、ここは時間を気にせずにじっくり取り組むしかありません。

11月度は、展示会などもありますが、さほど多忙にもならないと考えており、コーディング作業は大いに進むものと期待しております。
posted by 管理人 at 09:41| Comment(0) | TrackBack(0) | 日記

2014年10月01日

9月度概況

access1409.jpg9月度の弊社HPへのアクセス状況は図のようになりました。変動はあるものの、ほぼこれまでと同様のレベルで推移しております。

先月末に学会発表も無事終わりましたことから、9月度よりCodeSqueezer2.0の作成を再開しております。仕切りなおしということで、まずはデータ構造の見直しを行っております。

プログラミングというもの、締め切りに追われたりいたしますと、その場仕事でデータ構造を定義してしまうのですが、似たクラスがいくつもできてしまったり、処理の統一性が失われて後からみたときに良くわからないプログラムとなってしまいます。

そこで、似た定義のクラスについてはtemplate宣言を行って一つに纏めること、可能な限り継承を利用することで、全体の処理の統一性を確保するようにしたいと考えております。ひとたび全体の枠組みができれば、この先はそうそうごちゃごちゃにもならないはずで、まずは最初が肝心というものです。

今月度は、コンサルティング業務が立て込んだことから、プログラミングに割ける時間はあまりなかったのですが、相手のあることですのでいたし方ありません。細切れの時間を効率的に利用して、一歩ずつでも先に進めるしかありません。
posted by 管理人 at 15:00| Comment(0) | TrackBack(0) | 日記

2014年09月01日

8月度概況

access1408.jpg8月度の弊社HPアクセス状況は図のようになりました。8月前半に多少の落ち込みがありますが、ほぼ例月並みとなっております。

今月度の特記事項は、28-29日に下呂温泉で開催されましたDAシンポジウム2014で「要因別誤差追跡に基づく安全な数値演算論理の自動設計」と題する発表を行ったことです。各種資料につきましてはこちらのページに置きました。また、このページはHPからも参照できるよう設定いたしました。

今月度は税金の申告期限でもあり、かなりバタバタした一ヶ月ではありました。ここは多少の休養の後、心機一転、ソフト開発に取り組むことといたします。おおよその目処といたしまして、年内に誤差キャンセル検出機能を含むCodeSqueezer 2.0を完成させたいと考えております。

他の業務との関係で、なかなかスケジュールどおりに進まないのが悩みの種ですが、これはこれでいたし方ありません。ここはがんばって各種業務の両立を目指すしかありません。
posted by 管理人 at 10:57| Comment(0) | TrackBack(0) | 日記

2014年08月01日

7月度概況

access1407.jpg7月度の弊社HPへのアクセスは図のようになりました。年初の落込みからは完全に回復して、従来と同程度のレベルに戻しております。

先月度ご報告したように、8月の28-29日に下呂温泉で開催されますDAシンポジウムへの発表がアクセプトされ、7月度はこのためのプレプリントを作成いたしました。これが無事終わりましたところで、夏休みとばかりに小旅行をしたり、プールで泳いだりしております。

もちろん、プレプリントができたからといってシンポジウムの準備が終わったわけではなく、プレゼン資料を作らないといけませんし、シミュレーション結果など、プレプリントよりは詳しい情報を盛り込みたいとも考えております。また、このシンポジウムは口頭発表のほかにポスターセッションもあり、ポスターセッションの方が突っ込んだ議論ができますことから、こちらも申し込んでおりまして、その準備も必要となります。

と、いうわけで、多少入っておりますコンサルティングの業務もこなしながら、発表準備とシミュレーション検討を並行して行っております。資料につきましては、例によりましてシンポジウム終了後に弊社HPに掲載する予定です。ご期待ください。
posted by 管理人 at 17:12| Comment(0) | TrackBack(0) | 日記

2014年07月01日

6月度概況

access1406.jpg6月の弊社HPへのアクセス状況は図のようになりました。アクセス数は3月頃の落込みから完全に回復して、従来同様のレベルに戻っております。

先月ご報告いたしましたように、弊社は8月28〜29日に下呂温泉で開催されますDAシンポジウムでの発表を申し込んでおりましたが、無事アクセプトされました。プログラムはこちらです。私の発表は、2日目朝一番のセッション“5B: 高位設計”の中で、“(5B-2)要因別誤差追跡に基づく安全な数値演算論理の自動設計”と題して行います。

発表内容は、本年3月の情報処理学会全国大会で行った内容を深化させたもので、誤差キャンセルを自動的に検出し、精度確保に必要な処置を行うというもの。これは、FPGAで数値演算を行う論理を容易に設計するツールの一部で、有効桁に応じて必要最小限の論理規模で数値演算器を構成する際に必要となる手法です。なにぶん、誤差のキャンセルがある場合は、無効桁にも有用な情報が含まれるため、単純に有効桁のみを扱ったのでは有用な情報が失われてしまいますので。

本発表に関しては、プレプリントの締め切りが7月18日必着となっており、当面はこれを最優先で作成することとなります。骨子はすでにできているのですが、プレプリントに許された枚数が3倍ほどあること、全国大会での発表の際の反応をフィードバックすることなどを織り込もうといたしますと、かなりの作業量になります。

その他、6月度は機械要素技術展を見学してまいりました。安倍政権の第三の矢にものづくりの復権が含まれておりますようで、会場入り口には安倍総理のメッセージが掲げられており、政治家用の受付を準備するなど、政治とのかかわりが目立った展示会でした。この効果があったのでしょうか、かなりの人が見学に訪れており、会場を歩くのも人ごみを掻き分けなくてはいけない状況でした。

内容的には3Dプリンタと3D計測装置が注目を集めておりました。3Dの世界は、2Dに比べて(分解能が同等であれば)データ量が飛躍的に増加いたしますので、弊社の技術分野でありますような、高速演算のニーズも高まるものと期待しております。
posted by 管理人 at 10:27| Comment(0) | TrackBack(0) | 日記

2014年06月01日

5月度概況

access1405.jpg5月度の弊社HPへのアクセス状況は図のようになりました。3月から4月にかけての落込みからは回復している様子です。

今月度は予定通り、8月28〜29日開催のDAシンポジウムの発表申し込みをいたしました。前回もそうだったのですが、受付番号1番ということで、おそらく発表申し込みの一番乗りです。発表するかしないかは、6/13までに来ることとなっております採否通知次第でして、ゴーサインが出ますと予稿の作成ということになります。

発表を予定しております数値演算論理形成ツールでありますCodeSqueezer 2.0は、現在作成中で、シンポジウムまでにデモンストレーションのできる状態にすることを目標としております。5月度はコンサルティング業務に時間をとられてソフト開発は遅れ気味なのですが、何とかがんばって間に合わせるようにしたいと考えております。

展示会関係では、今月度は「組み込みシステム開発技術展」を見てまいりました。展示会自体は盛況なのですが、今回はこれといった出展はありませんでした。来月度はプリント基板工業会の展示会がありますので、これも一応チェックする予定です。ニュースがないのはよいニュース。驚くような新技術が現れていないということも、これはこれで一つの情報ではあります。
posted by 管理人 at 17:59| Comment(0) | TrackBack(0) | 日記

2014年05月01日

4月度概況

access1404.jpg4月度のアクセス状況は図のようになりました。多少低下気味ですが変動の範囲内であるともいえそうです。

4月度は、いよいよCodeSqueezer 2.0に向けての作業を開始しております。CodeSqueezerは、数式を与えることで数値演算を行う論理を自動形成する論理開発ツールでして、誤差の解析により必要なビット幅の論理を形成することを特徴としております。新しいバージョン(2.0)では、3月に学会発表いたしましたアルゴリズムにより、誤差のキャンセルを検出して必要な箇所に自動的に無効桁を追加することを特徴としております。

このため、CodeSqueezer 2.0は、コード形成に先立って誤差のシミュレーションを行い、必要な無効桁を自動的に設定して、それぞれの信号線のビット幅を決定いたします。4月度は新規の追加となりますシミュレーション部分を作成してこの部分の動作を確認しております。

下の図に示しましたのは全国大会プレゼン資料の12ページにあります二次方程式(x2 - 2 b x + c = 0)の解(x = b - √(b2 - c))を求める演算論理回路の平方根の内部(r3 = b2 - c)に要求される無効桁数を等高線表示したもので、bの仮数部は1,000に、cの仮数部は1,000,000に固定し、それぞれの指数部を0から10まで振った結果です。s.jpg

等高線はエクセルの作図機能を用いたために、少々おかしな図形となっております。右下の紺の広い領域は解が虚数となる領域で、この部分の計算は行わず、値を-9として欠側値であることを表現いたしました。その左上の紫の領域が無効桁必要数0の部分で、欠側値を-9としたためにこの間に等高線の密な領域が表示されておりますが、この部分は無視されるようにお願いいたします。

必要な無効桁数は、左上に行くに従って1ずつ増加し、左上隅で10桁となっております。これは、bの指数部が10でcの指数部が0の場合であり、無効桁を10桁追加することで双方の大きさが同程度となることに対応しております。また、等高線の傾きが1/2であることは、cそのものとbの自乗の間で減算が行われていることによると考えられ、ほぼ妥当な結果であるといえます。

この図はエクセルによる簡便な作図であり、そのまま学会発表に使えるものではありませんが、シンポジウムの際にはもう少しきれいな図で発表したいと考えております。なお、シンポジウムでは、シミュレーションのほかに、コード化までを含む一連の自動設計について発表することを計画しております。

その他、3月の全国大会では、計算機アーキテクチャのセクションで発表したため、これにあわせて幅広い応用を念頭に発表資料を作成したのですが、そのために焦点がぼけてしまったと反省しております。DAシンポジウムは論理回路の自動設計にフォーカスしたシンポジウムですので、数値演算論理の自動設計に絞って発表することが可能であり、2倍の発表時間と3倍の予稿が許されておりますことから、はるかに詳しい発表ができると期待しております。

これにつきましては5月23日までにアブストラクトを提出して発表可否の審査を受けることとなっております。アブストラクトはほぼ出来上がっておりますが、今後のソフト開発で気づいた点があればこれを追加修正した上で、期限に近いところで提出しようと考えております。

発表を認めていただければよろしいのですが、、、

その他、5月は引き続きCodeSqueezer 2.0の開発を続ける計画で、シンポジウムまでには何らかの形でデモできるようにしたいと考えております。
posted by 管理人 at 13:42| Comment(0) | TrackBack(0) | 日記

2014年04月01日

3月度概況

access1403.jpg3月度の弊社HPへのアクセス状況は図のようになりました。3月後半で落ち込んでおりますが、これは春休みの影響と考えております。

以前からご案内しておりましたように、3月11日に開催されました情報処理学会の全国大会で「誤差情報を含む浮動小数点表現とこれを用いた数値演算論理」と題する報告を行いました。詳細につきましては弊社HPをご覧ください。今回発表いたしましたのは、昨年10月度の進捗に述べました誤差の取り扱い手法を更に改良した手法で、最大の特徴は誤差のキャンセルが生じた場合の有効桁の毀損防止が可能となることです。

誤差キャンセルの問題はDAシンポジウム2010での報告でも指摘したように、早い段階から把握しておりました。当初は、設計者がアルゴリズムをチェックして回避するとしておりましたが、今回の手法はこれを機械的に行うことを可能とするものです。誤差キャンセルの問題に目処が付きましたことで、2012年のDAシンポジウムで発表いたしました“仕様記述言語mhdl”と併せまして、2010年のシンポジウムで指摘した課題は全て解決されたこととなります。

と、いうわけで次の課題はこの技術を応用したCodeSqueezer2.0を制作することとなります。また、締め切りに間に合えば、今年の夏に開催されますDAシンポジウムで、もう少し詳細な技術発表を行いたいと考えております。

この技術につきましては3月11日に既に発表しているのですが、プレプリントも2ページという制約があり、発表時間も短いことから、あまり詳細な内容に立ち入ることができませんでした。次回のDAシンポジウムでは、この技術の詳細と応用につきましてご紹介したいと考えております。夏までにはまだ時間がありますことから、おそらくはこの技術を組み込んだCodeSqueezer2.0もある程度動く状態に仕上げて、その動作状況もご紹介できるのではなかろうかと考えております。

DAシンポジウム2014のスケジュールは、アブストラクト締め切りが5月23日、採否通知が6月13日、原稿締め切りが7月18日、シンポジウム開催日が8月28〜29日となっております。アブストラクトの査読がありますことから、ある程度の結果を5月中旬までに出しておく必要があり、最低でも原理実証に必要な機能のみを実装したCodeSqueezer2.0のデモ版はそれまでに作り上げたいところです。

かなりタイトなスケジュールではありますが、いずれにせよCodeSqueezer2.0は制作する予定ですので、これらの作業はなんら無駄にはなりません。ここは気合を入れてやらなければいけないところです。
posted by 管理人 at 10:27| Comment(0) | TrackBack(0) | 日記

2014年03月01日

2月度概況

access1402.jpg2月までのアクセス状況は図のとおりです。2月後半は多少減少気味であるようにもみえますが、おおむね従来同様といえるでしょう。

今月度は学会発表の準備にほとんどの時間を費やしております。発表内容は、学会発表までは伏せておく方針ですので、今回は特に書くことはありません。

学会発表の内容につきましては、学会終了後に弊社HPにアップロードいたします。それまでの間、少々お待ちいただきますようお願いいたします。
posted by 管理人 at 15:46| Comment(0) | TrackBack(0) | 日記

2014年02月02日

1月度概況

access1401.jpg1月度の弊社HPへのアクセス状況です。冬休みの期間を含んでおりますが、ほぼ従来並のアクセスが続いております。

1月度は、前月に引き続き学会発表の準備とコンサルティング業務に忙殺され、ソフト開発はほとんど進展しておりません。ただ、予稿は無事期限内にアップロードいたしましたし、コンサルティング業務もひと段落しております。

学会関係で残る作業は、3月11日の発表までにプレゼン資料を作るだけです。資料の作成自体は3月に入ってからでも十分間に合いますので、2月中はCodeSqueezer2.0を見据えたシミュレーションソフトの開発にあてることといたします。久々に本来の業務が前に進みそうです。

学会発表の内容につきましては、発表前にオープンすることは避けるべきと思われますので、全国大会終了後にプレプリントとプレゼン資料をHPにアップロードする予定です。ご期待ください。
posted by 管理人 at 11:54| Comment(0) | TrackBack(0) | 日記

2014年01月01日

12月度状況

access1312.jpg12月度のアクセス状況は図のようになりました。多少レベルが上がっているようにもみえますが、変動の範囲内かもしれません。

弊社が発表を予定しております情報処理学会全国大会ですが、プログラムが公開されました。最初から3番目の1A-3が私の発表です。

この発表内容につきましてはいろいろと計画をしていたのですが、12月に入ってから別途行っておりますコンサルタント業務が立て続けに舞い込み、予稿執筆にあまり時間が割けない状況となりました。また、予稿の草稿を書いておりますと説明の必要な事項が数多くあることも判明し、2ページという制限ではシミュレーション結果まで書けそうにありません。そこで、予稿段階ではシミュレーション結果には触れず、シミュレーション結果に関しては発表の際に絵をさらりとご紹介する程度に止めておくことといたしました。

今回の発表の主眼は、あくまでも原理部分にありまして、発表を聞かれる方にはこの部分をしっかりとご理解いただくようにしたいと考えております。

予稿につきましては、既に情報処理学会に送信済みですが、1/14の締め切りまでには何度でも修正ができるということで、あと1回程度、文言の修正を行って最終版にしたいと考えております。

その他、この日記のタイトルを変更いたしました。この日記は会社設立以前から始めており、さくらのアカウントを取った直後から記述しておりました。その時点では会社名も決まっておらずURLも取得していなかったために、さくらのデフォルトURLをタイトルとしておりました。

このタイトル、本来は会社設立直後に変更すべきところ、今日まで忘れていたのはまったく間の抜けた話でした。まあ、遅きに失したとはいえ、今回修正いたしましたことは一つの進歩である、と前向きに考えておくことといたしましょう。

あ、そうそう、本日は正月元旦、あけましておめでとうございます。本年もご愛読のほど、宜しくお願いいたします。
posted by 管理人 at 12:51| Comment(0) | TrackBack(0) | 日記

2013年12月01日

11月度概況

1311.jpg11月のアクセス状況は図のようになりました。

弊社HPの利用のされ方は、演算論理を解説するCodeBookへのアクセスが多く、その中でも特に除算論理を調べる目的でのアクセスが多くなっております。除算論理につきましては、今ではもっと詳しい解説も可能なのですが、他の業務が立て込んでおり、なかなか古い文書の改定にまで手が回りません。いずれ時間ができました折には、まず、除算論理の解説から改定するようにしたいと思います。CodeBookへのアクセスは直接の商売にはつながらないのですが、宣伝という意味では十分に役割を果たしていると考えております。

今月度の業務といたしまして、学会発表の準備を優先して取り進めております。いろいろと面白い内容は含んでいるのですが、学会発表となりますと、わかりやすい例を取り上げて定量的評価を含む形でプレゼンするのが一般的で、シミュレーションプログラムを一つ作成して評価するという形を取らざるを得ません。

シミュレーションプログラムの作成には結構な時間がかかるのですが、アルゴリズムを事前に評価するという意味もあり、先々のCodeSqueezerのコーディングが効率的になることも期待でき、ここはきちんとした形で取り進めようと考えております。

一つの問題は、CodeSqueezer2.0は、演算論理を作成する関数をユーザに開放する計画で、この部分をDLLにする形でコーディングを進めておりました。一方シミュレーションソフトは、コーディング効率を上げるため、.NET Frameworkを全面的に使用して記述しております。こうして作成したアルゴリズムをCodeSqueezer2.0で使用する際に、果たしてDLL化が容易にできるかどうか、少々疑問です。

と、言いますのは、以前いろいろとトライした結果、.NET Frameworkを使用したクラスはDLLでは使用できない様子で、関連する部分を全て標準C++に書き直しております。これがどの程度の手間を要するかが問題で、最悪の場合はDLL化を行わないバージョンを先行して出す形を取りたいと考えております。

その他、今月度はパシフィコ横浜で同時開催されましたET(組み込み総合技術展)とEDSFairを見学してまいりました。弊社のやっておりますような製品はまだどこからも出てくる気配がないことで一安心です。また、アベノミクスの効果でしょうか、人出は過去に比較して非常に良好でした。組み込み分野も景気が回復している様子です。
posted by 管理人 at 14:15| Comment(0) | TrackBack(0) | 日記

2013年11月01日

10月度進捗状況

access1310.jpg今月度の弊社HPへのアクセス状況は図の通りで、ほぼフラットな状況が継続しております。

10月度は前月に引き続き、誤差の取り扱いに関する検討を進めております。

前月は、誤差を定数(error_ratio)で扱う手法についてご報告いたしましたが、これで扱っているのは誤差の下限であり、演算結果に実際に含まれる誤差はこれよりも大きな値となります。

演算論理を形成する際には、入力された値のいかんに関わらず有効な情報を失わないようにする必要があり、誤差の下限を用いてビット幅などを決めていくのは正しい考え方ではあります。しかしながら、数値を論理値に変換する際には、有効桁がゼロであるかどうかを判断基準としており、誤差の下限を用いる手法は厳密な意味では正しくはありません。

制御などに利用される論理回路であれば、誤差部分の厳密な取り扱いができることよりも、より小さな回路規模で装置を実現する方が優先されるはずで、厳密な取り扱いがどの程度要求されるかは疑問であることも事実です。しかし、演算結果に実際に含まれる誤差というのも有用な情報であり、特にパイプライン処理を用いた数値演算装置を科学技術計算に利用するようなケースを考えますと、結果とこれに含まれる誤差が同時に算出される手法も、それなりに需要があるようにも思われます。

CodeSqueezer2.0の設計思想の一つは、広い応用分野をカバーできるように自由度をもたせることであり、それぞれの信号に含まれる実際の誤差を正しく演算する機能も、基本仕様に含めておくべきでしょう。そういうわけで、今月度は、誤差を変数として、信号の値と並行して演算する手法について検討を進めております。

誤差の指標として、先月度ご紹介したerror_ratioは誤差の標準偏差に相当する値ですが、誤差を演算する際にはこれを自乗した誤差分散(Veとします)で取り扱うのが簡便です。種々の基本演算の結果に含まれる誤差分散は次のように計算されます。ここで、入力値をa, b、これらに含まれる誤差の分散をVa, Vbとします。
  加減算:Ve = Va + Vb
   乗算:Ve = Va * b^2 + Vb * a^2
   除算:Ve = Va / b^2 + Vb * a^2 / b^4
  平方根:Ve = Va / (4 * a)

浮動小数点で表される値に対しては、誤差分散も浮動小数点で扱う必要がありますが、その指数部は値の指数部の二倍とすることで論理が簡素化されます。この場合は誤差分散の仮数部は値の仮数部の最小桁を単位として誤差分散を表示していることになります。

無効桁の切捨ては、誤差分散の演算結果が最低保証値の4倍未満となるように行います。一桁の切捨てを行う場合には、指数部に1を加算し、値の仮数部をi bit右シフトし、誤差分散の仮数部を2 bit右シフトします。

誤差分散が1以上4未満となるように常に無効桁の切捨てを行うなら、誤差分散は狭い範囲で取り扱うことが可能となり、これを扱うための演算器や信号線は簡素なもので実現可能です。すなわち、誤差分散の仮数部は、最低2 bitあればよく、これを固定小数点数として小数点以下を扱うとしても、4〜8 bit程度で十分でしょう。

この手法につきましては、いろいろと面白い内容を含んでおりますので、来年3/11〜13に開催されます情報処理学会全国大会での発表を申し込んでおきました。発表内容などにつきましては、発表後にHPに掲載いたします。

そのようなわけで、CodeSqueezer2.0の開発はなかなか前に進みません。でも、その内容は非常に充実してきているわけで、無駄なことをしているわけでもありません。スピードよりも完全性、というのもこの開発思想の一つではありました。とは言いましても、できれば学会開催までには、最初のバージョンをアップロードすべく、開発の方も加速したいと考えております。

今後ともお付き合い、よろしくお願いいたします。
posted by 管理人 at 10:45| Comment(0) | TrackBack(0) | 日記

2013年10月01日

9月度概況

access1309.jpg9月度の弊社HPへのアクセス状況は図のようになりました。夏休みによると思われる先月度の落ち込みから回復し、以前と同じ水準に落ち着いている様子です。

CodeSqueezer2.0につきましては、引き続き開発に注力しております。無償公開中のCodeSqueezer評価版は、これまでの使用期限が9月末までとなっておりましたので、来年3月末までに使用期限を延長したバージョンを作成し、アップロードしております。引き続きご利用になりたい方はこちらをダウンロードしてお使いください。

今月度も引き続き、基本仕様の部分の見直しを行っております。今回行いましたのは演算誤差の取り扱い方法です。

CodeSqueezerに含まれておりますパイプライン処理記述言語MHDL処理系の特徴は、誤差を含む信号に対して有効桁のみを後段に伝達する論理を自動形成することを特徴としております。パイプライン処理は多数の演算器を用いる必要があるため、個々の演算器のビット長を最適化することにより、生成される論理の規模を最小にすることができます。

浮動小数点演算においては、有効桁以下にもわずかながら情報が含まれ、誤差を含む桁も2 bit程度は伝達することで情報を最大限に利用できるとされております。このため、これまでのCodeSqueezerも環境変数“noise_bits”を準備して、有効桁以下もnoise_bitsで与えられた数のビットだけは後段に伝達するようにしておりました。

noise_bitsに対するもう一つの理解として、AD変換機などから得られるデータにはノイズの影響により下位の数ビットはデータが安定しないことから、そのビット幅はゼロ判定から除外しなければならない、との考えがありました。

従来は、この二つの問題を同じnoise_bitsで扱っていたのですが、前者は演算に関わるポリシーの問題であり、後者は個々の信号線に含まれるノイズ(あるいは誤差)の問題であり、これらは独立に扱うことが妥当と考えられます。

また、個々の演算論理を作成する際に、有用な情報が失われることを防ぐ観点から有効桁を決定しているため、演算段数が増加するにしたがって誤差が増加するという問題がありました。従来のCodeSqueezerでは、ユーザ側で有効桁数を減じる標準手続き“reduce”を適宜挿入することで誤差の増加を抑制するようにしていたのですが、これは自動化されてしかるべき処理であるように思われます。

そこで今回、個々の信号に含まれる誤差の大きさを表す“error_ratio”と、後段に伝達する有効桁以下のビット幅である“shaky_bits”を個別に扱い、誤差の増加にあわせて自動的にビット幅を縮小するよう改善を図っております。

error_ratioは、それぞれの信号線に含まれる誤差の幅がLSBの何倍であるかを示す信号線の属性で、演算論理を形成する際に入力信号のerror_ratioから出力信号のerror_ratioを算出して出力信号線の属性とします。error_ratioは、統計的には標準偏差に該当する量で、複数の信号線の和のerror_ratioは、入力信号線のerror_ratioを二乗したものの和の平方根で与えられます。

shaky_bitsは、これまでnoise_bitsと称していたものと同じ概念で、伝達される信号線の有効桁以下のビット幅を指定する環境変数です。

信号線に含まれる誤差はLSBの2shaky_bits倍以上を確保するようにいたします。error_ratioがこの値の2倍以上ある場合は、信号線の桁数を1 bit削除することが可能となります。(4倍以上ある場合は2 bitの削除が可能、一般に2k倍以上の場合にk bitの削除が可能です。)演算論理の形成に際して、このアルゴリズムを適用することで、余剰ビットの自動削除が可能となります。

今月度検討したもう一つが、丸めの手法です。無効なビットを削除する際、従来は単純な切捨てを行っておりましたが、切捨てが多数回行われますと、その結果は本来あるべき値から大幅にずれてしまう危険性があります。

あるべき値に近い状態を維持するためには、切捨てではなく、四捨五入を行う必要があります。二進法における四捨五入は、削除される部分の最上位が1である場合に切り上げを行い、0である場合に切捨てを行うのが最も簡単なのですが、削除される部分が正確に1/2である場合に切り上げを行うと、多数回の四捨五入の結果が元の値から大きくずれてしまう可能性があります。たとえば、二進表記で0.001の小数部分を最下位から順に四捨五入で取り除く場合、このような単純な手法を用いたのでは、0.001→0.01→0.1→1となってしまいます。

JISは四捨五入を、削除される部分が正確に1/2である場合には、残った部分が偶数となるように切り上げもしくは切捨てを行うこととしております。このようにすれば切り上げの連鎖は生じることなく、四捨五入を繰り返しても元々の値から大きくずれるという問題を回避することができます。

これらのより正確な手法は、それぞれに論理を複雑にします。演算論理回路を形成する際、それぞれの目的に即して、回路の単純さと値の正確さに対する必要性が異なることは十分にありえます。そこで、CodeSqueezer2.0では、どの手法を選ぶかを環境変数“round_mode”で指定するようにいたします。

round_modeの意味、及びxの下位cut_bitsを削除してyに代入するVerilogコードは以下のとおりです。

round_mode == 0の場合は、ビット幅の縮小を単純な切捨てで行います。コードは、

      y = x[msb:cut_bits]

round_mode == 1の場合は、切捨て部分の最上位のみによる単純な四捨五入を行います。コードは次のようになります。

      y = x[msb:cut_bits] + x[cut_bits - 1]

round_mode == 2の場合は、切捨て部分が正確に1/2の場合に偶数となるように切り上げ切捨て処理を行うJIS法に従って四捨五入を行います。

cut_bits == 1の場合のコードは次のようになります。

      y = x[msb:cut_bits] + (x[cut_bits - 1] & x[cut_bits])

cut_bits > 1の場合のコードは次のようになります。

      y = x[msb:cut_bits] + (x[cut_bits - 1] & (|x[cut_bits-2:0] | x[cut_bits]))

上記手法が精度の維持にどの程度有効であるかに関しましては現在検討を進めております。結果につきましては次の機会にご紹介することといたします。
posted by 管理人 at 17:48| Comment(0) | TrackBack(0) | 日記

2013年09月01日

8月度概況

Access1308.jpgまず、8月度の弊社HPへのアクセス状況は図のようになりました。このところ安定しているアクセス数からは多少の落ち込みとなっておりますが、例年夏休みにはアクセスが減少するのが常ですから、従来と変わらずと考えて良いでしょう。

8月度も引き続きCodeSqueezer2.0の開発を続行しております。それぞれの演算手続きをVerilogソースコードに変換するコーダの開発と並行して、全体の開発環境とコーダの記述を容易にするためのサービス関数の整備も実施しております。CodeSqueezer 2.0は、ユーザによるコーダの記述も可能とするよう計画しておりますので、サービス関数もユーザに利用しやすいよう配慮が必要です。

8月度は全体に関係する仕様変更を二つ行っております。

一つは単項演算子をそれぞれのコーダ内部で処理するようにしたことで、こうすることでより高度な最適化が可能となります。これを可能とするため、ファンクションの入力ポートに与える情報として、従来与えておりました接続リンクと演算の種別に追加して、その入力に施される単項演算子を与えるようにいたしました。

単項演算子の種類は、なし、否定(!)、及び論理化(!!)の三種類にそれぞれマイナス(-)の有り無しを含む、計6種類といたします。論理化はゼロでないといえる場合に真(1)とし、否定は同じ場合にのみ偽(0)とします。マイナスの単項演算子は最後に施し、論理値の場合は真が-1、偽が0となります。

複数の単項演算子が連続して与えられた際は、パーサがこれら6種類のいずれかに簡素化します。これは、否定または論理化の演算子が左から作用した場合、マイナスは除去され、既に否定・論理化演算子がある場合には新たに作用する論理化演算子は無視され、新たに作用する否定演算子は既に存在する否定と論理化を入れ替えます。また、マイナス演算子が重ねて与えられた際にはこれを除去する形で行われます。

Verilog HDLの右辺式には、部分ビット列や接続演算を使用したビット拡張を記述することができます。また、マイナス、ビット反転、リダクション演算子などを作用させることができます。これらを扱うため、CodeSqueezerでは修飾ワイヤという考え方を用いています。

修飾ワイヤは、右辺の演算式に与える変数をワイヤに各種修飾を施した形で与えようという考え方で、修飾には負号反転、ビット反転、リダクション演算子、上位と下位へのビットの拡張、縮小幅を準備します。また、定数の場合はワイヤを与えず、負号反転修飾のみを有効といたします。

コーダの作成に際しては、演算の種別と右辺の各変数を修飾ワイヤの形式で与えることで、Verilog HDLコードが自動的に形成されるようサービス関数を準備しています。こうすることで見通しの良いコーダの記述が可能となります。単項演算子も、基本的に、ワイヤへの修飾に変換されることとなります。

修飾ワイヤという技法は従来から用いておりましたが、論理化の単項演算子を扱うようにいたしました機会に、ゼロ判定コードの生成も修飾を用いて行うようにいたしました。

一般には信号線(ワイヤ)の全てのビットがゼロである場合にゼロと判定されます。この例外的ケースは有効桁以外のビットも伝達する場合で、有効桁よりも下位のビットが1であってもそれは信号としては意味を成しませんので、有効桁のビットが全てゼロである場合にゼロと判定することになります。

下位の無効ビット数をnbとするとき、符号なし数xのゼロ判定は次のVerilogコードで表現されます。ここでmsbは最上位のビット番号です。
    zero = ~|x[msb:nb]

符号がある場合は、以下のように書きたいところです。
    zero = ~|x[msb:nb] | &x[msb:nb]
しかしながらこれでは正と負で非対称になります。たとえばnbが1の場合、上の書式では、0とみなされるのは-2, -1, 0, 1の4通りの場合で、+2がゼロとされない一方で-2はゼロとされてしまいます。

この一つの解決は、符号付数に対しては絶対値化してからゼロの判定を行うことです。この信号の絶対値が他にも使用されるなら、これをゼロ判定に用いることは合理的でしょう。

ゼロ判定する信号の絶対値が他で必要とされていない場合は、別途論理回路で生成した方が遅れの少ない回路が形成できそうです。このための論理式は、たとえば次のようになります。
    zero = ~|x[msb:nb] | (&x[msb:nb] & |x[nb-1:0])

ゼロ判定は、比較的頻繁に現れる処理と考えられ、一つのモジュール内で同じワイヤに対して複数のゼロ判定が行われることもありそうです。そこで、ゼロ判定コードを形成した際には、その結果を格納するワイヤをワイヤのメンバー(Wire* zero)として保持することといたしました。

ゼロ判定が必要な場合は、モジュールのメンバ関数“zero(wire)”を呼び出すことで判定結果を格納したワイヤを得ます。関数zeroはワイヤwireのメンバzero_wireが既にセットされている場合はこれを返し、そうでない場合はゼロ判定を行うコードを形成し、結果を格納するワイヤをワイヤのメンバzero_wireにセットした上で、これを返します。

同様な手法は、ワイヤの定数成分を除去する場合、およびワイヤの値を絶対値化する場合にも用いています。

その他、上で使用いたしましたリダクション演算に関しても、従来のCodeSqueezerでは単純にリダクション演算を行っていたのですが、FPGAの論理エレメントは一般に入力数が限られておりますことから、ビット数の多いリダクション演算はビット数に上限を設けて複数の演算に分割することが妥当ではないかと思われます。つまり、~|x[msb:nb]とするのではなく、適切な分割位置cbを用いて次のような形に演算を分離すべきと考えられます。以下は2分割の例を示しましたが、xのビット幅が大きい場合はさらに多くの分割を行うこととなります。
    tmp_1 = |x[msb:cb+1]
    tmp_2 = |x[cb:nb]
    zero = ~(tmp_1 | tmp_2)

全体に関わる変更は、影響する範囲が広いため、できる限り、個々のコーダを書き上げる前に定めておく必要があります。あとで大規模な手直しの必要に迫られませんように、ここは注意深く仕様を定めていきたいと考えております。
posted by 管理人 at 16:01| Comment(0) | TrackBack(0) | 日記

2013年08月01日

7月度概況

access1307.jpg7月度までの弊社HPへのアクセス状況は図のようになりました。これまでのところ、ほぼフラットに推移しております。

今月度の特記事項といたしまして、トップページ記載のように、CodeSqueezer製品版の販売を一旦停止することにいたしました。こういたしました理由は、CodeSqueezer 2.0の開発に注力するためです。新バージョンの発売を目前として旧バージョンの販売を停止するという理由もないことはないのですが、現在のところ新バージョン発売のめどが立っておらず、こちらはあまり理由にはなりません。

CodeSqueezer 2.0は、加減算や乗除算などの基本的な演算論理のコード化関数(コーダ)を利用者が改良できるようにすることを目指しております。これは、Rubyを開発したまつもとゆきひろ氏の、世界に広まるためにはユーザを巻き込む形を作り上げることが重要とのことばにヒントを得てのことですが、そのような形に作り上げることは実はかなり大変なことであることが、次第にわかってまいりました。

コーダ作成をユーザに開放するということは、インターフェース部分をきちんとしなければならないということ、この部分は後で変更することが難しくなるということです。このため、将来の拡張にも配慮して自由度の高い形に規格を定める必要が生じます。このための大きな変更点は、加算と減算のように同じ優先順位の演算は任意の項数を処理できる単一のコーダで処理するようにしたことで、このために入力ポートへの接続情報に接続先を表すリンク以外に逆演算フラグと演算種別を表す整数値を与えるようにしております。

変更を行った結果、CodeSqueezer 2.0の開発は、旧バージョンの部分的変更では済まず全面的な書き換えが必要となり、予想を大幅に超える作業量となってしまいました。CodeSqueezer 2.0につきましては、早くできるに越したことがないのは当然ですが、遅れたからといって大きな問題が生じるわけでもありません。ここは開発スピードよりも製品の完成度の高さを第一優先として、じっくりと開発に取り組みたいと考えております。

その他、今月度はテクノフロンティア展を見学してまいりました。

CodeSqueezerをデモする際に具体的な応用事例を示したらどうかとの助言をいただいているのですが、この一つの候補がエンコーダ信号を高精度化するための信号処理アルゴリズムです。実は、私はこのテーマで20年以上にわたって研究してきたのですが、いまだ究極のアルゴリズムには至っておりません。でも長年取り組んできた問題ですから、これまでに行われた無数の試みとその結果が知識としてあり、可能な道がどの辺りにあるかもおおよその見当は付いております。このテーマは、CodeSqueezer2.0の開発が一段落した段階で、ぜひとも取り組みたいと考えております。

で、テクノフロンティア展ですが、たまたまニコンの方がエンコーダに関する講演を行っておりましたので聴講してまいりました。前半部分は相当に初歩的な話で、これは失敗したかとも思ったのですが、後半は多少高度な議論にも踏み込んでおり、聞いて損ではありません。エンコーダでの計測精度を上げることは、今日でもこの分野での大きなテーマの一つとのことで、改めて意を強くしたしだいです。
posted by 管理人 at 11:18| Comment(0) | TrackBack(0) | 日記

2013年07月01日

6月度概況

access1306.jpg6月度のアクセス状況は図のようになりました。変動はありますが、昨年からほぼ一定のアクセス数となっております。

ページビューを稼いでおりますのがVerilog Code Book、つまり数値演算を行う論理をVerilog HDLで記述する方法を解説したページでして、直ちに商売に結びつくというわけではないのですが、弊社の存在を多くの技術者や学生さんに知っていただくという意味で、当初の狙い通りとなっております。

このVerilog Code Bookはかなり昔に作成した文書で、今日ではもっと気の利いた文書にしたいところです。しかし、CodeSqueezer 2.0が完成しない状況下では、文書の改定などをやってはおれません。これに関しましては、今後の課題ということにいたします。

6月の話題といたしまして、JPCAの展示会を見学してまいりました。特記事項は多層プリント基板の内部の層をくりぬいて部品を埋め込む「部品内蔵基板」でして、多数の報告やデモが行われておりました。

プリント基板に部品を内蔵することのメリットは、小型・薄型になること、信頼性が高まることでして、おそらくはコストも低下するのではなかろうかと思われます。内蔵される部品の一つが集積回路でして、シリコンチップをモールドしたりせずに裸のまま搭載している様子です。確かにこういたしますと、大幅な小型化・薄型化が可能となります。

我々が対象としておりますFPGAは一般に端子数が非常に多く、多層基板に実装するのが一般的ですが、その内部にFPGAのチップを埋め込むことができますと、小さな基板に多数のFPGAを実装することもできそうです。このような技術を使いますと、いずれは、大規模な論理を低コストで実現することもできるようになりそうです。
posted by 管理人 at 15:42| Comment(0) | TrackBack(0) | 日記

2013年06月02日

5月度状況

access1305.jpg5月度までの弊社HPへのアクセス状況は図のようになりました。従来同様、ほぼ一定のアクセス数が続いております。

5月度の特記事項ですが、まず、5月8日に東京ビッグサイトで開催されました「組み込みシステム開発技術展」を見学してまいりました。スマホのおかげでしょうか、特に超小型の部品では長足の進歩を遂げておりますが、お目当てのFPGA関連では収穫はゼロ。とはいいましても、いつなにがでてくるかわかりませんから、チェックは続けないわけにもまいりません。6月にはプリント基板関連の展示会がありますので、これもチェックする予定です。

次に、4月にアルテラ社の講習会に参加した旨は先月度のこのブログに書いたのですが、そのときQuartusIIが相当に進歩していることを知りました。たまたまアルテラのメールサービスでQuartusIIのVer13がダウンロード可能となったことを知りましたので、早速ダウンロードいたしましたが、このインストール中にアンチウィルスソフトがトロイの木馬ウィルスを検出いたしました。同じ操作を二度行って二度とも検出されておりますので、配布パッケージに原因があるものと思われます。

これにつきましては、事後に送られてきましたアルテラの使用感アンケートで報告し、先方の担当者と何度かメールをやり取りしたのですが、結局原因はわからずじまいとなっております。なお、ウィルスにつきましてはアンチウィルスソフトが自動的に削除いたしましたので問題はないものと思われます。また、QuartusIIの新バージョンもこれまでのところでは問題なく走っております。

その他、以前PCの不調についてこのブログに書いたのですが、外付けのHDDに問題があると判明いたしましたので、別途USB接続のHDDを購入して対処いたしました。それにしても1TBのHDDを普通に扱うような時代が来ようとは、かつてこの業界に関わっていた頃には思いもしませんでした。
posted by 管理人 at 22:20| Comment(0) | TrackBack(0) | 日記

2013年05月01日

4月度概況

access1304.jpg4月度の弊社HPへのアクセス数は図のようになりました。ここ数ヶ月、ほぼフラットなアクセス数となっております。

CodeSqueezer 2.0は、引き続き開発を進めておりますが、種々のトラブルにより難航中です。これにつきましては、完全な形での公開を目指し、拙速は避けたいと考えております。CodeSqueezerをご利用になりたい方は、現在の評価版を本年9月末まで使用可能としておりますので、こちらをご利用ください。

今月度の特記事項といたしまして、アルテラ社のCyclone Vの講習会に参加してまいりました。私が現在コード確認に使用しております評価ボードはCyclone IVを搭載したもので、その次の世代のデバイスということになります。

Cyclone Vは、集積度や消費電力が改善されていることはもちろんですが、ロジックエレメントをStratixと同じ構造にしたということで、これがもし本当であれば、ロジックエレメントを加算減算切り替え可能な形にプログラミングできるはずで、特に除算論理を構成する上で有用であるように思われます。

このような論理に展開されることをより確実にするためには、論理合成に与えるソースリスト上でも、加減算切り替え演算を一つの式で記述したほうが良いように思われ、このためには以下のようなノードも扱えるようにする必要がありそうです。

  out = cond ? (a + b) : (a - b)

その他、Cyclone Vの特徴は、DDR3メモリやPCI Expressバスのアクセス機能をハードで持たせたこと。これらのインターフェースを利用する際にも複雑なインターフェース仕様に頭を悩ませなくてもすみそうです。
posted by 管理人 at 18:32| Comment(0) | TrackBack(0) | 日記

2013年04月06日

3月度概況

access1303.jpg3月度のアクセス状況は図のようになりました。多少の増減はありますが、ほぼフラットといったところでしょう。

先月度問題の発生したパソコンは、その後異常もなく稼動しております。多少の不安はありますが、当面このまま走ることといたしました。

最近ウィンドウズの走るタブレットの新製品が各種出ており、興味を惹かれるのですが、あまり新しいものにチャレンジすると思わぬ時間をとられることにもなりかねません。ここは製品が安定して世評の固まるまで待つのが正解であるような気もします。

CodeSqueezer 2.0の開発につきましては依然として遅れ気味です。現在公開しております評価版“CodeSqueezerのVersion 1.08”はこの3月末で使用可能期間が切れてしまいましたので、9月末まで使用可能なバージョン(1.08C:ダウンロード)をアップロードいたしました。引き続き評価されたい方はこちらをお使いください。

posted by 管理人 at 23:30| Comment(0) | TrackBack(0) | 日記

2013年03月10日

2月度概況

遅くなりましたが2月度の状況について報告いたします。

access1302.jpgまず、アクセスは図のようになりました。先月度まではトレンドラインを一本の直線で表示していましたが、データを良くみれば昨年あたりからアクセス数はほぼフラットとなっておりますので、二本の矢印で表示してみました。現在のところ、増減はありますが、ページビューで200〜300/日付近で推移しております。新バージョン完成後の増加に期待したいところです。

その新バージョンのCodeSqueezer 2.0ですが、種々のバグへの対応で開発が遅れ気味であったのに加え、パソコンのハードウエア異常という新たな問題も発生しております。この問題は現在のところ、一部のディスク領域が使用不能との表示が出るだけで、動作自体は正常に行われているのですが、危険な状態であることには変わりなく、何らかの対応が必要と考えております。

ハードウエア異常に対する対処は新しいパソコンを購入するのが最も簡単です。そうなりますとOSもWindows 8ということになりますが、これに伴ってコードの修正が必要になる可能性もあり、スケジュール面での遅延要因がまた一つ増えてしまいます。

とはいえ、現在のソフト開発はWindows Vistaをベースに行っており、Windows 7との互換性は基本的に確保されているものの、この先はWindows 8への対応も当然必要になりますので、この機会にOSのバージョンアップを行うことは悪いことではありません。CodeSqueezerのバージョンも2.0になるわけですから、ちょうど良い機会であるともいえるでしょう。CodeSqueezer 2.0は、製品発表時期を早くすることよりも、製品の完成度をあげること優先して開発を進めておりますので、多少発表時期を先送りして最新のOSに対応するのが妥当ではなかろうかと考えております。

この問題につきましては、もう少し検討いたします。当面は、PCの調査を進める一方で、バックアップを入念に取りながら、現在のマシンでの検討も並行して取り進めてまいります。結論がでましたところで、改めてご報告いたします。
posted by 管理人 at 17:12| Comment(0) | TrackBack(0) | 日記

2013年02月01日

1月度概況

access1301.jpg1月度のアクセス状況は図のとおりで、停滞ぎみよなっております。

CodeSqueezer 2.0に関しては、先月ご報告したように開発スケジュールを見直し、新たな体制で取り組んでおります。こちらにつきましては、3月末に改めてご報告することといたします。なお、所用のため、2月のレポートは3月中旬にずれ込む見込みです。いろいろなことがありますが、ソフトの開発も着実に進んでおりますので、しばしお待ちいただきますよう、よろしくお願いいたします。
posted by 管理人 at 11:13| Comment(0) | TrackBack(0) | 日記

2013年01月02日

12月度の状況

access1212.jpg12月度のアクセス状況は図のようになりました。新しい情報がほとんど出ていないのですが、アクセス数はほぼトレンドラインに乗っております。

問題は、CodeSqueezer 2.0の開発ですが、これが大幅に遅れております。これに対応するため、現在ご評価いただいているCSEvalのVer1.08の使用期限が12月末となっておりましたものを本年の3月末までに延長しておきました。引き続きご使用になる場合は評価版のページから最新版を改めてロードしてご利用ください。

CS2.0の開発が遅れている原因は、DLL化に伴い記憶領域の扱いが複雑になり、これに関連した修正項目が多岐にわたり、予想以上に作業量が増加したことです。

ソフト開発が予定通り進まないことは珍しいことではないのですが、今回は、作業量そのものが当初見積もりよりもはるかに膨大であったことが判明しており、多少のスケジュール変更では済みそうにありません。そこで今回、完了目標を3ヶ月延長し、この間に完全な形にソフトを仕上げることといたしました。

新バージョンに期待されている方々にはご迷惑をおかけいたしますが、今しばらくの間お待ちいただけますよう、よろしくお願いいたします。
posted by 管理人 at 10:21| Comment(0) | TrackBack(0) | 日記

2012年12月01日

11月度の状況

access1211.jpg11月度のアクセス状況は図のようになりました。このところCodeSqueezer 2.0の作成に追われページに新味がないのですが、それでもアクセス数はトレンドラインまで回復しております。

そのCodeSqueezer 2.0ですが、11月度は論理ブロックをVerilog HDLに変換する“コーダ”の作成に入っております。CodeSqueezer 2.0は、最も最初の計画では11月中に作成を完了する予定だったのですが、その後の仕様変更により計画は大幅に遅れております。

11月度に着手したコーダは、ファンクションダイアグラムの処理、代入式の処理、および加減式の処理の3つで、現時点ではこれらのデバッグを行っている状況です。コーダだけでも、このほかに乗除式、論理演算、比較演算、条件式などなどが残っており、技術面でもいくつかの新しいアイデアを盛り込んでおります。果たして12月末で完了するかどうか疑わしいのが実情です。

スケジュールの遅れは大変心苦しいのですが、中途半端な製品を出すわけにもいきません。スケジュールより製品の品質を優先し、きちんとした製品に仕上げてから発表したいと考えております。今しばらくお待ちいただくよう、よろしくお願いいたします。

11/14-16には横浜みなとみらいのパシフィコ横浜でEDSFとET2012が開催されました。弊社はこれまでEDSFに出展していたのですが、本年は8月末に学会発表をいたしましたこともあり出展は見送り、見学だけしてまいりました。見ての感じは「盛況」の一言に尽きます。電機業界の不振を尻目に、この業界はまだまだ活況を呈しているようです。

ちなみに、弊社が行っているような製品分野は、現時点では他社からは現れておりません。少々寂しい感じもいたしますが、あまり似たような製品が出てきてしまっては商売に差し障ります。いずれにいたしましても、なるべく早い時期に次の製品を仕上げて、出していくしかありません。
posted by 管理人 at 15:17| Comment(0) | TrackBack(0) | 日記

2012年11月01日

10月度の状況

access1210.jpg10月度のアクセス状況は図のようになりました。アクセス数は夏休みの落ち込みから回復してトレンドラインまで戻しております。ただこの先、特にイベントは予定されておりませんので、このままアクセス数が増加することは期待薄と考えております。ここは、CodeSqueezer 2.0の公開が待たれるところです。

そのCodeSqueezer 2.0ですが、開発は少々遅れ気味で、アップロードは12月にずれ込みそうです。そこで、CodeSqueezer V1.08評価版の使用可能期限が10月末となっておりましたものを、本年の12月末まで期間を延長しておきました。引き続きご利用される方は、改めてダウンロードをお願いいたします。

CodeSqueezer 2.0の最大の特徴は、標準手続きをユーザも作成できるようにすることで、具体的には標準手続きのコード化関数(コーダ)をDLLの形で与えるようにしたことです。先月のこの日誌でもご紹介いたしましたように、これに伴って、標準Cに依拠する形にクラスライブラリを全面的に変更しております。

変更に際しては、アルゴリズムも見直して簡素化を図るとともに、将来の拡張の余地も残すようにしております。このような改良は、当然おこなわれてしかるべきではあるのですが、これが少々大規模な変更となりましたことが開発スケジュールの遅れを招いております。これにつきましては、基幹部分の見直しを後で行うことも難しいことから、やむを得ないと考えております。

少々技術的に深入りいたしますが、その変更につきまして、簡単にご紹介しておきます。

compile.jpgまず、DAシンポジウムでもご紹介いたしましたように、CodeSqueezerはmhdl言語形式で記述された演算仕様を図のような流れでVerilog HDLに変換しておりました。この中で緑と茶色で書かれております「式の木構造」と「手続き配置リスト」を一体化した、というのが今回の変更です。

式の木構造は、「同じ優先度の演算子で結ばれた」を「」(代入式、加減式、乗除式、比較式、等など)とし、の種類の一つにを含めることで木構造を形成するものです。パーサはソースコードの式をいったん木構造に変換し、これをバイナリーツリーの形に変換して二項演算を行う手続き呼び出しに変換する、というのが従来のパーサの流れです。

mhdlは「有効桁のみを演算する論理を形成する」ことを特徴としております。しかしながら、たとえば乗除式のそれぞれの演算に要求される精度は式中の有効桁数が最も小さな項によって決まるのですが、有効桁の決定を行うコーダが二項演算を対象としておりますとこのような最適化をうまく行うことができません。そこで、コーダが多項演算を対象とするよう見直しを行いました。

具体的には、加減算を行うファンクションを、任意の入力数を処理できる“_add_sub”に一本化し、乗除算を行うファンクションも同様に“_mul_div”に一本化することとしました。また、ある入力が加算であるのか減算であるのかを識別するため、入力ポートには逆演算フラグinvを与え、これがtrueであるポートに対しては減算なり除算なりを行うことといたします。_add_subなどは手続きとしても定義されますので、invフラグを項にも与えることにより、手続き呼び出しの形で式を表現することが可能になります。これにより、式の木構造と手続き配置リストが統合されます。

クラスの統合は、ソフトウエアの大幅な簡素化を可能とします。式の木構造と手続き配置はclass Termのみで表現されます。class Termは名前とTermのリストをもち、名前のみが与えられた場合は定数もしくは変数、Termのリストが与えられた場合は手続き呼び出しであることを示します。式は手続き呼び出しで表現されますし、単項演算子も手続き呼び出しに置き換えることができますから、class Termだけで式に関わるすべてのデータ構造を表現することができるようになりました。

一般の手続き呼び出しに際してもinvフラグを操作できるよう、コンマ式においても逆演算を指定できるようにいたします。コンマ式とは演算子“,”で接続される項からなる式で、手続き呼び出しの引数(手続きへの入力)の指定にも用いられます。コンマ式に逆演算を指定するための演算子として“;”を用いることといたしました。これを用いますと、たとえば“a + b - c”は“_add_sub(a, b; c)”と記述することができます。invフラグをどう扱うかはファンクション(手続き)毎に規定され、処理はコーダに委ねられます。このため“func(a;0, b;1)”のような形で、aに対してパラメータ0を、bに対してパラメータ1を与えるような使い方も可能です。

同じ優先順位の式を単一の手続き呼び出しに統合したことにあわせて、比較演算も全て手続き_compを呼び出す形といたしました。比較演算は種類が多いことから、invフラグの他にint selを与えることといたします。比較演算のためだけに余分なメンバ変数を追加することは躊躇されるのですが、これにより、コーダの書き方次第で“a <= b < c”等の式も予期される通り“(a <= b) & (b < c)”と解釈させることもできるようになります。

と、いうわけで、コンパイラが簡素化される一方でそのためのソフト開発は煩雑になり、スケジュールが遅れ気味となってしまいました。しかし、この遅れによるロスは、その結果なされる改善に比べれば充分に小さいものと考えております。この先、コーダも、任意数の入力を可能としたりinvフラグを追加するため、少々複雑になることが予想されます。仕事量は増えるばかりなのですが、ぼやいていても仕方ありません。ここは、一日も早く理想的なコンパイラができるよう、頑張るしかありません。
posted by 管理人 at 10:49| Comment(0) | TrackBack(0) | 日記

2012年10月01日

9月度の状況

access1209.jpg9月度の状況ですが、まず、弊社HPへのアクセス状況は図のようになりました。8月の落ち込みから回復しておりますが、トレンドラインに乗せるまでには至っておりません。この先は特にイベントの予定もなく、今後しばらくはアクセスの低迷が続きそうです。

今月の特記事項は、CodeSqueezer 2.0の開発を開始したことです。

CodeSqueezer 2.0の最大の特徴は、先月のブログでもご紹介しましたように、ユーザやサードベンダも標準手続きを作成できるようにすることです。

mhdlから呼び出される標準手続きは、コーダと呼ばれる関数によりVerilog HDLに変換されます。ユーザが標準手続きを作成するという意味は、ユーザがC言語を用いてコーダを記述するという意味であり、このためには、種々のクラスを定義したヘッダファイルやこれを扱うためのライブラリを公開する必要があります。

これまで、CodeSqueezerは.NET Frameworkを用いて記述してまいりました。この理由は、第一にWindowsで画面制御するためには、いずれにせよ、マイクロソフトの提供するサービスルーチンを呼び出す必要があり、今日ではWin32APIよりは.NETが主流になりつつあると考えられたこと、第二に.NETの提供する各種クラスが備える自動ガベージコレクション機能が便利であったことによります。

しかし、.NETはWindowsの世界でのみ有効であり、これを用いたソフトウエアは他のOSへの移植が困難になります。先月度のブログでご紹介いたしましたまつもと氏の講演でも、Ruby普及の一つの鍵がANSI Cでソースコードを記述したことである、とも語られておりました。

CodeSqueezerは、当面Windows上で動かすことを前提といたしますので、画面制御のためのサービスルーチンとして.NETを使用することは妥当であると考えられます。しかしながら、ユーザに開放する標準関数の記述については、.NETの使用を前提とすることは好ましいことであるとも思われず、標準Cの仕様の範囲内でソースコードを記述できるように配慮すべきでしょう。

これらから、CodeSqueezer 2.0は次のような方針で作成することといたしました。

・標準的なクラス定義“CSLib.h”はソースコードの公開を前提として作成する。
・CSLib.hで定義されるクラスのデータを取り扱うための共通関数“CSLib.lib”を配布物に含める。
・画面制御を含むユーザインターフェースモジュールを独立させ、この内部でのみ.NETを使用することとし、それ以外の部分は標準Cに従ってコードを記述する。
・mhdlの標準手続きをVerilog HDLに変換するコーダは、全てDLLモジュールとして記述し、実行中に動的にリンクさせる。

こうなりますと、当然のことながら、クラスライブラリが全面改定となり、全てのコードも書き直す必要があります。これは大変な作業となるのですが、ソースコードを見直すにはよい機会であるともいえます。そこで、言語仕様や技術文書との対応をチェックしながら、全てのコードを書き直すことといたしました。

今月度はクラスライブラリを作成し、パーサのコードを作成しております。この先、コンパイラを作成し、コーダの作成に取り掛かる計画です。現在の見通しでは、全てが完了するにはあと2月程度は必要で、CodeSqueezer 2.0の公開は12月ごろとなりそうです。

気の長い話であるとは思いますが、今しばしお待ちいただきますよう、よろしくお願いいたします。
posted by 管理人 at 11:58| Comment(0) | TrackBack(0) | 日記

2012年09月01日

8月度の状況

access1208.jpg8月度のアクセス状況は図のようになりました。アクセス数はトレンドラインからかなり下がっておりますが、例年夏休みにはアクセスが低下する現象が認められており、9月からの回復に期待しております。

8月度のトピックスといたしまして、まず第一にあげられますことはCodeSqueezer Ver.1.08をアップロードしたことです。こちらにつきましては既にご紹介しておりますので、詳細は省略いたします。

第二のトピックスは、8/29-30に岐阜県下呂温泉で開催されました“DAシンポジウム2012”で発表したことです。今回のテーマは、CodeSqueezerに演算仕様を与えるための言語“mhdl”のご紹介です。こちらの関連資料は弊社HPのDA2012のページにアップロードいたしました。

会場では種々のご助言を頂きました。その一つは、C言語との変換機能を準備したらよいのではないか、という点でして、これにつきましてはいずれやりたいと考えているとお応えいたしました。なお、その際にはmhdlの機能拡張も併せて行い、Cの機能の大部分をmhdlで記述できるようにしたいと考えているのですが、会場からの反応は、そこまでやる必要はないのでは、というものでした。さて、どうしたものでしょうか、、、

もう一つのご助言は、具体的な応用例についてmhdlの開発事例として紹介したらよいのでは、というもの。これはかなり大掛かりな仕事になることが予想されまして二の足を踏んでいるのですが、いずれはやりたいと考えているテーマもあり、目先の課題が片付いた後にはぜひ取り上げたいと考えております。

このテーマとは、位置信号の誤差補正でして、実はCodeSqueezerのようなツールを開発せんと考えましたのは、私が長年位置信号の誤差補正に関わる研究開発に従事して、そこで必要となる演算論理を手早く作成したいと考えたからなのでした。

位置信号の誤差補正に関しましては、これまでの研究開発の過程で、いろいろな面白いことがわかってまいりました。ただし、これらの研究は会社勤めの過程でなされたものであり、私の一存でその内容を公開するわけにもいきません。また、個々の技術に関しては特許出願を行っており、仮に公開したところで、読者のお役にはたたない可能性が高いと思われます。

しかしながら、企業に勤務する中で行いました位置信号の誤差補正に関わる研究は、私自身が考えるところでは、いまだ不十分なものであり、どうすればよいかという道筋もおおよそのところではみえております。また、長年これらの研究開発に関わってまいりましたおかげで、各社の特許がどのようにこの領域をカバーしているかという知識も私の頭の中には入っております。つまり、各社の特許に抵触しない形で、これらをはるかに凌駕する技術を作り上げることもできそうであると考えているわけです。

と、いうわけで、直近のテーマであります“CodeSqueezer 2.0”の次のテーマといたしまして、位置信号の誤差補正技術を一つものにして、mhdlの応用例という形でオープンにしていきたいと考えております。こういう形であれば、情報処理学会以外に、電子情報通信学会でも発表ができそうで、FPGAの新しい応用分野の開拓にもつながる良い宣伝の場ともなりそうです。

DAシンポジウムでは、発表するだけでなくいろいろな方の発表も聴講させていただいたのですが、その中でも特筆すべきはRubyの開発者、まつもとゆきひろ氏の“世界に通用する技術者になるためには”という講演でした。まつもと氏、もちろん有名人ではあるのですが、興味深いことにはmhdl同様の言語でありますRubyの開発者でして、新しい言語を世界に広めるためにはどうすればよいか、というヒントが得られるかと期待してのことです。

Rubyはオープンソースで作成されており、世界に広まるきっかけは、Web用のアプリケーション開発に利用されたことからと。これを、商用ソフトという形で出しておりますmhdlにそのまま応用することは難しいと思われますが、ユーザを巻き込む形を作り上げるということは一つのポイントである様子で、CodeSqueezer 2.0公開の次の次あたりにリリースする予定の、Function Developer's Kit(標準ファンクションをユーザが定義するためのキット)の出し方が一つの鍵となりそうな予感がいたします。

その他、まつもと氏は「少しばかりの英語」という表現で、英語によるコミュニケーションの重要性を強調しておられました。CodeSqueezerの英語版やホームページの言語切り替え機能(日本語/英語)が必要であることは以前より認識しておりましたが手つかずとなっております。これにつきましても、なるべく早い機会に取り組んでいきたいと思います。

と、いうわけで、やるべきテーマは山のようにあるのですが、一つづつ片付けていかないといけません。まずはCodeSqueezer 2.0をなるべく早くものにすべく、これからも張り切ってまいりたいと考えております。
posted by 管理人 at 14:20| Comment(0) | TrackBack(0) | 日記

2012年08月06日

CodeSqueezer Ver1.08をアップロードしました

長らくお待たせしておりましたが、CodeSqueezerの最新版、Ver.1.08の製品版と評価版をアップロードいたしました。

今回のバージョンの特徴は冪乗演算子“^”を追加したことで、たとえば“x^(1/2)”等とすることで平方根の演算もできるようになりました。なお、冪乗演算を不用意に行いますと、非常に大きな値を形成いたします。CodeSqueezerでは64 bitで表現可能な範囲の信号しか取り扱うことができませんので、この範囲を超えないようご注意ください。これは、FPGAでの信号処理に際しては、これほど大きな桁数を扱うこともなかろうとの判断によります。

評価版は10月末まで使用可能です。問題点などを発見された際、またご要望などありましたら、弊社までご連絡下さい。いただきました情報は、今後の製品改良に役立てていきたいと考えております。よろしくお願いいたします。
posted by 管理人 at 19:23| Comment(0) | TrackBack(0) | 日記

2012年08月01日

7月度の状況

access1207.jpg7月度の弊社HPのアクセス状況は図のようになりました。例年夏休みは停滞気味なのですが、このところの落ち込みは少々長引いております。かねてからアナウンスしておりますVer.1.08のアップロードですが、冪乗演算部分に種々のバグが発見され作業が遅れております。これがアクセス落ち込みの一つの原因とも考えられます。いずれにせよ、DAシンポジウムまでにはきちんとした形で公開したいと考えており、デバッグ作業に集中しております。今しばらくお待ちください。

今月度のトピックスといたしまして、アルテラのセミナーに参加してまいりました。

弊社の販売しておりますCodeSqueezerは浮動小数点を含むことが一つの特徴なのですが、アルテラはかねてよりFPGAで浮動小数点数を扱う技術を公開しており、アルテラがどのような考え方でこれに取り組んでいるか気になっておりました。セミナーを聴講しての印象は、浮動小数点を扱う理由はシミュレーションとの対応をとるためであって、使用している浮動小数点形式もIEEE754フォーマットに準拠しております。実際に使用する際には、固定小数点数にする方式を中心に考えておられる様子です。

まだまだ弊社の方式は独自の方式と考えて良さそうです。学会発表を控えているという面では、これは良いことではあるのですが、時代のトレンドにマッチしていないという意味では少々問題であるともいえます。つまり、商売上はまだまだ苦労しそうであるというのが問題です。とはいえ我々の元々の考えが、時代の流れについていくのではなく、時代の流れを作り出すこと。商売上の苦労は致し方ないことでありまして、いかに我々の技術をアピールしていくかが課題であると言えるでしょう。

さしあたりは、新製品の公開と学会発表に注力するしかありません。

その他の情報といたしまして、アルテラが2032 年の FPGA: 20年後の FPGA の未来像と題する文書を公開しております。20年後とは少々気の長い話なのですが、デバイスの高密度化が進むと欠陥を許容せざるを得ず、論理デバイスのプログラマブル化が進むであろう、とされております。

ハードディスクなどの記録媒体では、かなり以前から、媒体の欠陥を許容する技術が使われております。これは、あらかじめ媒体を検査して欠陥のあるセクター番号を媒体の一部に記録しておきます。情報を書き込む際には、いずれにせよ、空いているセクターを探す必要がありますので、その際に欠陥部分を使用しないようにすれば、簡単に欠陥セクターをスキップすることが可能です。

同様の考え方はメモリーでも可能ですし、FPGAにも同様の手法が使えそうです。つまり、論理をデバイス上の論理エレメントに割り当てる際に、まだ使用されていない論理エレメントを探す必要がありますので、その際に欠陥部分を避けるようにすればよいわけです。欠陥のある論理エレメントの情報は、出荷の際に検査を行い、デバイス上のPROMに記録しておくことになります。

論理デバイスが皆FPGAになるなら、パイプライン処理も幅広く使われるようになるでしょうし、FPGAでの浮動小数点演算も一般的になるでしょう。我々の技術の未来は明るい、といえそうな情報ではあります。それが20年後というのでは少々困りますが、さほど遠くない時点で何らかの流れがみえてくるのではなかろうか、と期待しております。
posted by 管理人 at 10:02| Comment(0) | TrackBack(0) | 日記

2012年07月02日

6月度の状況

access1206.jpg6月度のアクセス状況は図のようになりました。少々停滞気味です。

DAシンポジウムのプログラムも公開になり、6月末締め切りのプレプリント作成に追われる一月となりました。この内容に関しましては、8月末のシンポジウム開催以降に、他の資料と併せてHPに公開する予定です。

今月はCodeSqueezer Ver1.08の評価版をアップロードする予定だったのですが、種々のトラブルがあったことと、シンポジウム原稿を優先したことにより遅れております。

Ver1.08では、除算部分を手直しして多少の高速化を図っているのですが、条件によってはこの部分が正しく動作しないケースがある様子です。四則演算論理におきまして除算は難しい部分であり、差別化できる部分でもあります。ここは、対症療法的な小手先の対応をするのではなく、論理をきちんと再検討する必要があるのではなかろうか、と考えております。

いずれにせよ、シンポジウムまでには結果を出さなくてはなりません。それに製品のバージョンアップを早くしませんと商売にも差し障ります。まだまだ忙しい日々が続きそうではあります。
posted by 管理人 at 09:48| Comment(0) | TrackBack(0) | 日記

2012年06月01日

5月度の状況

access1205.jpg5月度のアクセス状況は図のようになりました。先月からアクセス数が伸び悩んでおりますが、いよいよVer.1.08もアップロードいたしましたので、今後の伸びに期待したいと思います。

そのCodeSqueezer Ver.1.08ですが、最大の売りは冪乗演算を言語仕様に含めたことです。冪乗演算は一般的な数式表現ではありふれた演算ですが、Cの言語仕様に冪乗演算子は含まれておらず、関数を呼び出す形で冪乗演算を行います。この理由を私は、Cの言語仕様が一般的なCPUのインストラクションセットに対応する形で定められていることによるのではなかろうか、と憶測しています。

すなわち、Cの言語仕様に含まれる演算子には、シフトやビットごとの論理演算、インクリメンタル、デクリメンタル演算子など、CPUのインストラクションセットに対応する演算子が含まれています。Cの言語仕様にはそのほかにも、複合代入文や配列の仕様、ポインタの存在など、CPUの機能・構成に即して言語仕様が定められていると思しき部分が多々あります。これらは一般的な数式表現には使用されないものの、これらの演算子を用いて式を簡素に記述することにより、CPUが効率的に演算できるマシンコードが形成されます。

冪乗演算は、FortranやBASICの言語仕様には演算子が定義されているのですがCには存在しません。私はその理由を、CPUのインストラクションセットに冪乗演算は含まれないからである、と考えているわけです。そういうことであれば、パイプライン演算論理を形成するCodeSqueezerは、CPUのインストラクションセットとは無縁の存在であり、むしろ数式を抽象的に取り扱うためには、一般的な数式に用いられる演算機能を積極的に言語仕様にも取り込むべきでしょう。

このような考えの元に冪乗演算を導入したVer.1.08を作成した次第ですが、いろいろと操作をしている段階でこれまでの演算処理にも少々問題があることに気付きました。

これは、冪乗演算はオーバーフローを招きやすいという点でして、冪乗演算が本質的に大きな数値を形成し易いというのがその一つの理由であって、これだけなら致し方ないのですが、特に除算の処理過程で必要以上のビット幅を使用しておりました。冪乗演算というオーバーフローし易い機能を追加したがゆえに、従来機能の欠点が明るみに出てしまいました。

そこで、除算演算を論理化する部分につきましても今回見直しを行いました。除算論理の形成はかなり複雑な処理を含みますので、このためにかなりの時間をとられてしまいました。これがVer.1.08公開が遅れた主な理由です。

Ver.1.08につきましては、昨日デモ版をアップロードし、さらに検証作業を行った後に評価版と製品版をアップロードいたします。不具合がなければ、これらの作業自体はさほど時間は要しないのですが、、、

その他、mhdl言語の仕様と実装に関する技術内容をこの夏(8/29-30)のDAシンポジウムで発表することが決まりました。このための準備もあり、6月はいろいろと忙しい月になりそうです。
posted by 管理人 at 11:05| Comment(0) | TrackBack(0) | 日記

2012年05月01日

4月度の状況

access1204.jpg4月度の弊社HPへのアクセス状況は、図のように少々停滞気味です。これを改善する手立てといたしまして、当面これといったイベントもなく、新バージョンのアップロードに期待するしかなさそうです。

その新バージョンですが、冪乗演算を追加したV1.08を準備中です。

この公開は4月中にもできるのではとみておりましたが、種々の見直しを行ったために予定が遅れ気味です。内容等につきましては完成後にまとめてご紹介いたします。
posted by 管理人 at 09:59| Comment(0) | TrackBack(0) | 日記

2012年04月01日

3月度の状況

access1203.jpg3月度のアクセス状況は図のようになりました。若干停滞気味ではありますが、上昇トレンドから大きく外れてはいないように思われます。

3月度は、初旬に平方根演算論理の形成機能を追加したVer.1.06をアップロードし、下旬にVerilogソースコードを簡素化したVer1.07をアップロードしております。それぞれ、アップロード後に不具合個所が見出されたため、多少の手直しを行っております。

mhdlの式の仕様には冪乗演算子を含める計画で、演算アルゴリズムにもよりますが、指数関数を用いずに直接演算する方式では、指数に小数部がある場合に平方根演算が必要となります。今回行いました平方根演算論理形成機能はこのための第一歩です。

冪乗演算子の導入につきましては現在鋭意作業中で、恐らくは4月中にもアップロード可能ではないかと考えております。ご期待ください。
posted by 管理人 at 20:49| Comment(0) | TrackBack(0) | 日記

2012年03月08日

CodeSqueezer Ver.1.06公開のお知らせ

遅くなりましたがCodeSqueezer Ver.1.06を弊社HPに公開しました。評価版は評価版のページからダウンロードできます。

新バージョンの最大の特徴は平方根を計算する論理の形成を可能としたことです。

ご注意頂きたい点は、平方根演算の特性上、演算結果は誤差を含む可能性があることで、演算結果の有効桁数を入力の桁数から決めております。すなわち、誤差なしの信号が入力された場合にも誤差ありの信号として扱われます。

演算結果の精度を高めたい場合には、“to_fix”を使用して仮数部の桁数を増加させてください。この具体的な方法につきましては、添付ファイル“opes.mhdl”にサンプルを記述いたしました。

製品版もバージョンアップしております。ガードキーをお持ちの方は、製品版のページから最新版をダウンロードすることで、追加の費用負担なくご利用いただけます。新規にご購入される場合の定価は、従来同様39,800円です。ご愛顧のほどよろしくお願いいたします。
posted by 管理人 at 18:42| Comment(0) | TrackBack(0) | 日記

2012年03月01日

2月度の状況

access1202.jpg2月度の弊社HPへのアクセス状況は図のようになりました。先月度までに比べて多少伸び悩みの傾向は認められるものの、長期にわたって上昇トレンドが継続中であると言えるでしょう。

CodeSqueezerの新バージョン(V1.06)につきましては、月初にも公開を予定していたのですが、検証の過程でバグが発見され修正と再検証に時間をとられたため、予定が大幅に遅れております。

現時点では、バグは全て修正済みなのですが、現在行っている再検証の過程で新たなバグが発見されないとも限らず、公開日のアナウンスは躊躇されます。しかし、大きな問題が生じない限り、数日中に公開できると考えております。

新バージョンにご期待されている方々にはご迷惑をおかけいたしますが、今しばらくお待ちいただきますよう、よろしくお願いいたします。
posted by 管理人 at 09:55| Comment(0) | TrackBack(0) | 日記

2012年02月01日

1月度の状況

access1201.jpg1月のアクセス状況は図のようになりました。ゆっくりとしたペースではありますが、順調に増加が続いております。

1月中のアップロードを予定しておりましたCodeSqueezer Ver.1.06の開発は少々遅れております。

今回の目玉であります平方根処理の部分は既に出来上がっているのですが、全般的な処理の簡素化を試みた結果、影響が広範囲に及ぶこととなり、検証作業に時間をとられております。

とはいえ、さほどの大問題が発生しているわけでもなく、Ver.1.06は近々アップロードできるものと考えております。遅延につきましてお詫びするとともに、引き続きご期待いただきますようお願いいたします。

posted by 管理人 at 09:47| Comment(0) | TrackBack(0) | 日記

2012年01月01日

12月度の状況

access1112.jpg12月度のアクセス状況は図のようになりました。年末の落ち込みを除き、高いレベルが維持されております。

11月末よりGoogle AdWordsに登録し、Googleで製品に関連するキーワード検索がなされた際にテキスト広告が入るようにしております。これがアクセスが上昇した一つの理由であるのかもしれません。

ただ、Google AdWordsは、このような専門性の高いツールの宣伝にはあまり適していないように思われます。AdWordsには、まずキーワードの設定が必要なのですが、幅の広いキーワードを用いると「キーワードと内容との関連性が悪い」と言われてしまいますし、絞り込んだキーワードを用いると「表示回数が極めて低い」と言われてしまいます。

結局のところGoogle AdWordsは、多くの人が興味を持つ分野に効果的な宣伝手段であり、少数の人しか興味をもたない、専門性の高い分野ではあまり有効な手段ではないのかもしれません。

とはいえ、アクセスも増えていることでありますし、この宣伝はもう少しの間続け、より洗練されたキーワードを用いるなどの改善努力も続けていきたいと考えております。

CodeSqueezer評価版につきましては、Ver.1.05の評価期間が12月末で完了し、次のバージョンの評価版をアップロードするまでに多少の期間が開く形となりました。

これまで常に評価版を使用可能とするよう、評価期間が過ぎる前に次のバージョンをアップロードしており、これが間に合わない場合には使用可能期間を延長しておりました。これは、この技術をより多くの人に知っていただくための措置でして、評価版が使用できることで製品版が売れなくなる可能性については目をつむっていたわけです。

しかしながら、そろそろ技術も一定の域に達し、営業に注力する時期となりましたので、評価版を常に使用可能とするやり方は終わりにしなければなりません。そういうわけで今後は、評価版が使用不能となる期間は普通に生じることとなります。

とは言いましても、バージョンアップの作業は今後も継続し、新しいバージョンが完成するごとに評価版も改めて使用できるようにいたします。ご興味のある方は時々弊社HPをチェックされるようお願いいたします。

現在計画中のVer.1.06はいくつかの改良を施しておりますが、その最大のポイントは平方根演算を含めたことです。これは、冪乗演算も仕様に含めようとの試みの第一歩でして、まずは独立した関数として平方根を提供したいと考えております。

その他の改良点は、形成されるコードをよりシンプルな形とすること、変換ソフトウエアをより統一性の高い、見通しの良い形にするというもので、後者につきましては外部からは改善効果がみえないのですが、ソフトウエアの保守の上からは重要な改善ではあります。

Ver.1.06は1月中の公開を目指して現在作業を進めているところです。公開の暁には引き続きご評価いただきますよう、よろしくお願いいたします。
posted by 管理人 at 11:21| Comment(0) | TrackBack(0) | 日記

2011年12月01日

11月度の状況

access1111.jpg11月度の弊社HPへのアクセスは図の通りで、トレンドラインを上回るアクセス数となっております。

11月度の特記事項は、まずEDS Fair 2011 Nov.に出展したこと。弊社ブースに来られた技術者の方々からは非常に好意的な反応を頂いております。

EDS Fairの中日には、CodeSqueezerで使用しております技術に関わる特許が公開となりました。ちょうど良いタイミングでしたのでEDS Fairのプレスリリースに流しましたが、さてこれはどうでしょうか。翌日の会場で何らかの反応があるかと期待したのですが、これは空振りに終わっております。

EDS Fair開催の翌週11/21には、当初のスケジュール通り、CodeSqueezerを発売いたしました。これに合わせて、製品版のページをリニューアルし、このページへのリンクを含むバナーをトップページやCodeBookの各ページに表示するようにいたしました。また、CodeSqueezerの旧バージョンに相当するCodeSqueezer Floatingは、上位互換で同価格の新製品が出ましたことから、販売を終了しております。

技術面では、先月末にアップロードいたしましたCodeSqueezerのデモ版のバージョンアップ(バグの修正)を3回実施し、安定したと思われるVer.1.04から評価版・製品版への格上げを行っております。なお、その後Ver.1.05へのバージョンアップも行っておりますが、これはチェッカのテスト条件を細かく設定できるようにする改善であり、前のバージョンに問題があったというわけではありません。

その他、製品版ページにより多くの潜在顧客を誘導すべくGoogle AdWordsへの登録も行いました。これは、弊社製品に関するキーワードで検索が行われた際に表示されるページに弊社製品版ページへのリンクを含む宣伝を入れるものです。これがどの程度の効果を発揮するかわかりませんが、しばらくは試験的な運用を続ける計画です。

目先の課題は完了いたしましたので、今後は中長期的な課題、すなわち“CodeSqueezer 2.0”の開発に取り組むことといたします。その内容は、いろいろと考えてはいるのですが、どのようにとり進めるかはまだ決まっておりません。当面は、いろいろなテストを行い、実現可能性を探っていきたいと考えております。
posted by 管理人 at 10:15| Comment(0) | TrackBack(0) | 日記

2011年11月01日

10月度の概況

access1110.jpgまず、10月度の弊社ホームページのアクセスは図のようになりました。9月の多少の落ち込みから回復し、ほぼトレンドラインに戻しております。

今月の特記事項は、新製品であります“CodeSqueezer”のデモ版をアップロードしたこと。これに合わせてトップページのデザインを変更しております。

これまでにもこのブログでご紹介してまいりましたように、“CodeSqueezer”は数式(代入文)をVerilog HDLに直接変換することを最大の特徴としております。技術的には、従来から公開しております“CodeSqueezer Floating”とさして変わるものではなく、数式を関数呼び出しに変換する処理を付け加えただけともいえるのですが、使う側から見れば相当に改善されていると言えるのではないかと思います。

弊社は、11/16〜18の3日間、横浜みなとみらいのパシフィコで開催されますEDS Fairに出展いたしますが、今回の新製品をこの目玉とする計画です。ニュースリリースもアップロードいたしました。さてこれがどの程度市場に受け入れられるものか、それが最大の問題です。

“CodeSqueezer”は、これまで出しておりました“CodeSqueezer Floating”の上位互換版であり、四則演算論理を簡単に生成できることから“CodeSqueezer Basic”の機能も兼ね備えていると言えるでしょう。

そこで、今後は販売する製品を“CodeSqueezer”一本に絞ることといたします。この具体的な作業の第一として“CodeSqueezer Basic”の販売を中止し、“CodeSqueezer Floating”の評価版提供も一時停止することといたしました。今後これらの機能を必要とする際には“CodeSqueezer”をご利用いただきたいと考えております。

“CodeSqueezer”の発売は11/21と、すでにアナウンスいたしております。今回公開いたしましたデモ版の段階でバグはないことを確認しているのですが、Floatingに対して完全な上位コンパチとするためには多少の手を加える必要があり、わずかですが作業を残す形となっております。

今月度は、展示会に新製品発売と、忙しい日々が続きそうですが、なにはともあれ新製品が形になってまいりましたことは誠に喜ばしいことである、と考えております。

posted by 管理人 at 13:18| Comment(0) | TrackBack(0) | 日記

2011年10月01日

9月度状況

access1109.jpg弊社HPへの9月度のアクセス状況は図のようになりました。夏休みの落ち込みからの回復が多少弱めであるようにも見えますが、通常の変動の範囲内ではあります。

今月度は、11月の展示会に出します新製品“CodeSqueezer”のシェープアップをしております。

この新製品の最大の特徴は数式記述を可能としたことで、たとえば“x = a + b * c”といった記述を、入力a, b, cに対して数式で指定された演算を施して得られた結果をxに出力するVerilog HDLソースコードに変換します。

コード変換技術そのものは“CodeSqueezer Floating”と同じで、単に数式を解釈する部分が追加されただけなのですが、利用する側から見ればすべてを関数呼び出しで記述するのと数式で記述するのとでは相当に異なる印象を与えるはずで、従来製品から大幅に進歩した新製品と言えるのではないかと考えております。

新製品CodeSqueezerの主要部分は8月中にほぼ完成しており、2カ月かけて検証をすればよいかと考えていたのですが、9月度はエラーメッセージを出力する部分にかなりの時間をとられてしまいました。

詳細につきましては評価版を10月中にもアップロードする予定ですのでその際にご紹介いたしますが、なにぶんエラーのあるソースコードというものはどのような記述がなされるか予想がつかず、これを確実にキャッチしてどの部分に誤りがあるかを正しく表示するというのはなかなかに困難な作業となりました。

先月度の課題でありました複数の出力をもつファンクションの記述につきましては、「代入文のみを許す」ということにして処理の簡素化を図ることといたしました。式の記述にベクトルを許すという道もあったのですが、ベクトルの次は行列あるいはテンソルと、この手の仕様拡張はきりがないという事情もあり、数式はスカラーのみという割り切りをした次第です。

その他、「別ウィンドウでの数式入力」機能、すなわちmhdl言語形式ではなく数式のみを記述したテキストをVerilog HDLに変換する機能ですが、これにつきましてはmhdlの言語仕様に多少の変更を加えることで、特別なウィンドウを設けることなく同等の機能を実現するようにいたしました。

mhdlの言語仕様に対する変更というのは、「レベル0の代入文はレベル-1のファンクションの代入文とみなす」という点です。

ここで「レベル」とは、行頭のブランクの数で、次のような約束があります。

・ファンクション宣言の範囲は、宣言文よりもレベルの低い(ブランク数の多い)文が続く限りとする
・ファンクション名の通用範囲は、それが宣言されたファンクション宣言の範囲内とする
・リンク名の通用範囲は、それが宣言された直上のファンクション内部とする
・コンパイルの対象となるのは、最上位レベルのファンクションとする

記述不可能でありますレベル‐1のファンクション宣言文は、レベル0の代入文の内容から自動的に形成されるようにいたしました。

こうすれば、数式のみを記述したソースファイルは、自動的にファンクション宣言文が形成されてレベル-1のファンクションとなり、これがコンパイル単位となります。

この方式は別ウィンドウで数式を入力する方式に比べて、ユーザインターフェースが単純であるという利点に加え、数式以外にファンクション宣言を記述することも可能で、これを数式から呼び出すこともできるという長所もあります。

現在作成中のバージョンは既にこれらの機能も含まれております。この評価版を今月中に公開する計画ですのでご期待ください。
posted by 管理人 at 11:45| Comment(0) | TrackBack(0) | 日記

2011年09月01日

8月度の状況

access1108.jpg8月度の弊社HPへのアクセス状況は図のようになりました。例年7月から8月にかけては夏休みの影響で若干アクセス数が下がる傾向があることを考えますと、ゆっくりとではありますが着実にアクセス数を伸ばす傾向にあるということは言えるでしょう。

先月は、新たにアップロードしたCodeSqueezer Floatingのバグ対策に追われたのですが、今月上旬にもこの作業が尾を引いております。あまり頻繁な修正版のアップロードは見苦しいことから、多少の期間をおいて修正版をアップロードするということも考えたのですが、バグのあるソフトを放置することも問題と考え、バグが発見されてコードが修正されるごとに修正版をアップロードする従来のやり方を踏襲することといたしました。

ベストなやり方は充分な検証を行った後にアップロードするというあたり前の道です。それができなかった以上は少々みっともないことでもせざるを得ないということでしょう。

今月度は、mhdl言語仕様をソースコードへの数式記述を許す形に拡張する検討を行っております。

言語仕様ですから、数式記述の方式につきましてもよく考えておかなければなりません。演算子の取り扱いに関する現在の考え方は以下の通りです。

まず、なにを演算子とするかという基本思想ですが、C言語ではCPUのインストラクションセットとしてあり得る演算を網羅的に演算子としているように見受けられますが、mhdlはVerilogの抽象化であることから、ハードウエアに依存しない抽象性の高い演算を演算子に割り当てるようにいたします。

この基本に忠実に、二進法を前提としておりますビットごとの演算とシフト演算を演算子仕様から排除することといたしました。これらの演算が必要な場合は、ファンクション呼び出しの形で記述するか、あるいはこの部分のコードをVerilog HDLで記述していただくことといたします。

この結果、論理演算は論理値(0か、それ以外か)に対する演算のみとなります。C言語では論理値に対する演算子を“&&”や“||”のように文字を二つ連ねており、より単純な“&”や“|”をビットごとの演算に割り当てておりますが、ビットごとの論理演算がないのであれば、これらの単純な演算子を論理値に対する演算子として使用することができます。

排他論理和は、実はCでは論理値に対する演算子を定義しておらず、ビットごとの演算子“^”のみが準備されています。これに準じてmhdlの仕様から排他論理和を外すことも一つの考え方です。しかし、排他論理和は論理和や論理積と同列の演算子であり、論理値に対する排他論理和を準備しておいても悪くはありません。

必要がないなら使わなければよいだけのことですから、mhdlには論理値に対する排他論理和を準備しておくこととし、優先順位を(Cのビットごとの演算子の優先順位と同様)論理和と論理積の中間に位置付けることといたします。(論理積と論理和の優先順位に関して先月のブログ記事に誤りがありました。正しくは、論理積、排他論理和、論理和の順に高い優先度をもちます。)

排他論理和の演算子は“^”ではなく“!”を用いることといたします。こうする理由は、演算子“^”を冪乗の演算子としてリザーブしておくためです。排他論理和は論理値が等しくないことを意味する演算であり、値が等しくないことを表す演算子“!=”との関連性から“!”を使用することも妥当と考えました。

この考え方をさらに推し進めれば「排他論理和は比較演算の一種である」とみなすこともできるのですが、さすがにこれはいきすぎと考え、前述の通り排他論理和演算を論理積と論理和の中間に位置付けることといたします。

その他、先月度ご報告したところからの変化ですが、否定型の論理演算子(“~&”、“~^”および“~|”)を仕様から外しました。これは、否定型とそうでない演算子の扱いが異なる(否定型の論理演算は2項演算に限られる)こと、否定型の論理演算が必要ならば括弧で括って単項演算子“!”で論理を反転すれば実現できることなどの理由によります。Cの仕様に否定型の論理演算が含まれていないことからも、このやり方は妥当ではないかと考えております。

なお、否定の単項演算子は、先月度のブログでは“~”としておりましたが、論理値の否定であることからC言語に合わせて“!”を用いることにいたしました。

以上の諸点につきましてはほぼ方針を固め、既にコーディングも完了しているのですが、複数のリンクを返すファンクションの扱いにつきましては現在検討している段階です。このような処理は数式処理とは別枠に扱い、代入文のみを許容するのが簡単なのですが、統一的な処理方法がないものかと頭を悩ませております。

その他、弊社は本年11月にパシフィコ横浜で開催されますEDS Fairに出展することとし、準備を開始しております。8月には出展社データを入力した程度ですが、9月には展示説明会が開催されるなど、いよいよ作業も本格化いたします。

ちなみに弊社が今回出展を計画している製品は、現在作成中の[新製品:CodeSqueezer]でして、数式入力も可能であることを最大の特徴としております。これを出展社データに含めてを入力いたしましたので、このソフトは何が何でも完成させるしかありません。

ソフトの主要部分はすでに動いておりますし、展示会まではまだ2カ月以上もありますことから、今回は大丈夫であるとは思いますが、ここは完全な形で製品発表ができますよう、気を引き締めてまいりたいと考えている次第です。
posted by 管理人 at 11:49| Comment(0) | TrackBack(0) | 日記

2011年08月01日

7月度状況

access1107.jpg7月度の弊社HPへのアクセス状況は、図のように、概ね漸増が続いております。7月20日以降は多少減り気味ですが、これは例年同様で、夏休みの影響が表れているものと思われます。

遅れておりましたCodeSqueezer Floatingのバージョンアップですが、7月15日にバージョン1.05をアップロードすることができました。しかしながらその後続々とバグが見つかり、この対応に追われております。これら新たに発見されたバグの大部分は定数演算に関わる部分で、この部分の検証が十分でなかったことが問題であったと反省しております。

発見されたバグにつきましては対応を急ぐべきとの考えから、バグが発見されるたびに修正版をアップロードしていったのですが、結果的には短期間で5回のバージョンアップと、見苦しい形となってしまいました。今後のバグ修正の方法については改めて考える必要がありそうです。

その他、今月度は仕様を数式で記述する手法について検討しております。

最終的には、mhdlソースコード中に数式が記述できるようにする計画ですが、とりあえずは別ウィンドウに記述した数式を従来仕様のmhdlソースコードに変換する形で数式処理のテストを行っております。

テストプログラムを試してみたい方はここをクリックしてください。ダウンロードが始まります。なお、本プログラムは検証を完了しておらず、動作の状況をみるためのデモとご理解ください(8/2: テストプログラムを修正しました。8/8:再修正しました。)

数式入力ウィンドウはexitボタンの左側にあるformulaボタンを押すことで開きます。数式のサンプルはファイル“sample1.form”として添付しましたので、openボタンを押して開いてみてください。compileボタンを押すと入力ポートの数値型を与えるウィンドウが開き、型を与えてウィンドウを閉じることでコンパイルが始まります。

数式入力ウィンドウでできるその他の操作は、newボタンによるウィンドウのクリアと、saveボタンでの数式のファイルセーブで、テキストボックスに任意の数式を入力すればユーザ独自の数式をコンパイルすることもできます。

許される演算子と優先順位はC言語とほぼ同様ですが、パイプライン処理では右辺と左辺に同じ信号線を記述できないことから、+=などの複合代入演算子やインクリメント、デクリメント演算子(++, --)は使用することはできません。また、抽象記述を目指すため、二進法も前提としておらず、シフト演算とビットごとの論理演算も仕様には含まれていません。

使用できる演算子は(優先度の高い順に)以下の通りです。括弧内は許容される他の記述法です。

      乗除算:*, /
      加減算:+, -
      比較演算:>, >=(=>, !<), <, <=(=<, !>), ==, !=(<>, ><)
      論理和:|, ~|
      排他論理和:^, ~^
      論理積:&, ~&
      条件式:? :

乗除算、加減算、および否定でない論理演算は任意の項数とすることができます。パーサは最短遅れで解が得られるよう、これらをバイナリーツリーの形に変換します。また、除算は論理が複雑になることから、乗除算に関しては乗算により分母と分子を形成して最後に1回だけ除算を行うよう論理を形成します。

比較演算と否定型の論理演算は2項演算に限定されます。また、条件式は3項限定です。

単項演算子(符号“+, -”および否定“~”)は他の演算に優先して右側から演算されます。これは、単項とその左の単項演算子をあわせて単項として扱うとの規則によります。括弧“()”で括られた式は括弧内が優先して演算され、演算結果を格納するリンクが単項として扱われます。単項には定数の記述も可能で書式はmhdlの仕様に準拠します。

ファンクション呼び出しも単項として扱われます。ファンクションを呼び出す際の引数部には単項を記述します。すなわちこの部分には、他のファンクション呼び出しや()で括った式を記述することも可能です。

今回のプログラムはあくまでテストであり、実際にはmhdlのソースコード中に式の記述を可能とする計画です。ただし別ウィンドウでの数式入力はなかなか便利な機能であり、最終的なバージョンにも同種の機能は残したいと考えております。

数式入力を含む新バージョン“CodeSqueezer”は、本年11月に開催されますEDS Fairで発表する予定です。CodeSqueezerは実質CodeSqueezer Floatingのバージョンアップですが、数式入力が可能であることから、四則演算論理を作成するツールでありますCodeSqueezer Basicとの統合版という性格もあり、今後はシンプルに“CodeSqueezer”と呼ぶことにいたします。

なお、CodeSqueezer Floatingをお買い上げのお客様にはCodeSqueezerへの無償バージョンアップも致します。機能強化版が出るまで買い控える必要はございませんので念のため。

posted by 管理人 at 22:25| Comment(0) | TrackBack(0) | 日記

2011年07月01日

6月度の状況他

access1106.jpg弊社HPの先月のアクセス状況は図のようになりました。東日本大震災後の落ち込みから完全に回復し、漸増傾向が続いております。5月に続き6月もページビューで500を超す日が現れております。多数のアクセスがあることは歓迎すべきことなのですが、なぜかいずれも13日、不吉な感じがしないでもありません。

6月度はCodeSqueezer Floating(CSF)の改良作業に集中いたしました。仕様上の主な変更点は異常フラグの取り扱い方法に利用者の自由度を増したことですが、異常フラグの見直しにともなってすべての処理を書き換えることから、ソフト全体の見直しも同時に行いコードの簡素化を図ることといたしました。

この作業は6月中旬にも完了する計画で始めたのですが、当初の見通しが甘く現時点でも完了には至っておりません。ご期待された方には大変ご迷惑をおかけいたしますが、このバージョンをCSFの最終版としたいとの思惑もあり、なるべく完全な形での公開をしたいと考えております。もう少々お待ちいただくよう、よろしくお願い申し上げます。

なお、これまでアップロードしておりましたCSF104評価版の実行可能期間は6月末で終了してしまいます。新版への切り替えが遅延いたしましたことから、新たに7月末まで実行可能な評価版CSF104aをアップロードいたしました。引き続き評価される方は、当面このバージョンでご評価ください。

その他の特記事項といたしまして、11月16日から3日間の予定で横浜みなとみらいにあります“パシフィコ横浜”で開催されますEDS Fairへの出展申込をいたしました。

この展示会は従来1月末に開催されていたのですが、本年度より開催時期が11月に変更になり、組込総合技術展との同時開催となりました。

昨年12月のこのブログに書きましたように、この組込総合技術展への出展も検討しておりました。しかし、同場所で同時開催となりますと双方に出展する意味はありません。出展するにいたしましても、いずれかということになります。

組込総合技術展への出展をいたしますと新顔として多少注目されることもあるかもしれません。こちらへの出展を検討した背景にはこの効果への期待もありました。一方、EDS Fairならこれまで二度も出展しており、出展作業が容易に進むうえ、同じ展示会に3回連続で出展することでお客様の信頼も向上することが期待できます。

これらを総合的に判断したうえで、本年はEDS Fairに出展することといたしました。こうすることで、来年度に組込総合技術展に切り替えて新顔効果を期待するという道も残されております。

出展を計画しております新製品は“CodeSqueezer”。その機能は従来の製品に数式の記述を可能とした程度で、技術的には現行製品からさほど進歩してはおりません。ただし営業的には相当の変化になるものと考えております。

CodeSqueezer Floatingの最大の技術的特徴は内部に浮動小数点処理を含めた点にあり、であるがゆえに製品名に“Floating”を含めたのですが、この言葉があるがゆえに、浮動小数点処理を必要としている顧客にしかこの製品は注目されないという問題を生じてしまいます。

CodeSqueezerの本来の特徴は演算を含む論理を簡単に記述する点にあり、整数も、固定小数点数も、浮動小数点数も扱うことが可能です。浮動小数点処理を内部に含めた理由は乗算結果のビット幅を削減するためであり、浮動小数点の利用はこのための技術的手段にすぎません。

そこで、今後は浮動小数点を前面に出すのではなく、演算処理論理を簡単に作成するツールという本来の機能を前面に押し出しての営業活動を展開することといたしました。

“CodeSqueezer”の“CodeSqueezer Floating”からの変更点は、誤差なし整数をデフォルトとすること、演算記号を用いた数式の記述を可能とすること程度で、技術的な進歩はあまりないのですが、見栄えはかなり改善されるでしょう。その他、フラグの扱いの多様化、内部処理の見直しによる出力コードの簡素化など、現在進めております改良の結果も反映されたものとなります。

さて、11月の営業攻勢、いかがなりますでしょうか。もちろんその前にソフトを完成させるという一大作業も残っております。まだまだ忙しい日々が続きそうです。
posted by 管理人 at 11:12| Comment(0) | TrackBack(0) | 日記

2011年06月01日

5月度の状況

access1105.jpgまず、5月度のHPアクセス状況は図のようになりました。東日本大震災発生以降の落ち込んでおりましたアクセス数は、従来の漸増傾向線のレベルまで回復してまいりました。その理由といたしまして、世情の回復もあるのでしょうが、CodeSqueezer Floating(CSF)の新しいバージョンをアップロードしていることもアクセス回復を後押ししているのではないかと考えています。

今月度は、CSFのバージョンアップに多少の時間をとられたほかは、異常フラグ処理の改良作業を続けております。現在計画している改良点は以下の通りです。

・数値化不能異常の表示に独立信号線の使用もできるようにすること(現在はオーバーフローフラグとアンダーフローフラグを共に立てる形で表示している)

・入力信号にnanがあるため結果が定まらない論理演算結果を真とするか、偽とするか、nanとするかを選択可能とすること

これらをいずれか一つに限定してしまえばソフトは簡素化されるのですが、いずれの方法を用いるかはユーザであります論理設計者の思想にも依存することであり、ソフトの側で一律強制することは好ましくなかろうと考えたことによります。

ただ、異常フラグはすべての論理に関係するだけに、すべてのコード化関数を見直す必要が生じ、この改造にはかなりの時間がかかっております。

また、今回の全コード化関数の見直しを良い機会として、内部処理の共通化、簡素化も同時に計画いたしました。内部の処理をすっきりした形にすることで、出力も多少は簡素化されるでしょうし、生成された論理も高速化・簡素化されるのではなかろうかと期待しております。

CodeSqueezer Floatingの新しいバージョンは6月中旬にもご提供できるのではないかと考えております。機能的にはさほど進化したものでもないのですが、とりあえず、ご期待ください。
posted by 管理人 at 11:08| Comment(0) | TrackBack(0) | 日記

2011年05月10日

CodeSqueezer Floatingを発売しました

先日のアナウンス通り、CodeSqueezer Floatingの製品版が完成し、昨日より販売を開始いたしました。

製品版と評価版は、プロテクト部分を除いて同一内容です。プロテクト部分に関しては、評価版は有効期間を設ける一方で、製品版は有効期限がない代わりに動作に際してはガードキーが必要であるという違いがあります。

評価版の有効期限は今回は7/1とし、約2ヵ月間は評価可能としております。期限が切れますと評価版は実行できなくなるのですが、毎月1回程度はバージョンアップをすることとなるものと予想しており、それぞれのバージョンで1〜2カ月程度の利用可能期間を設定することで、常時評価可能な形を維持したいと考えております。

製品版をお買い求めのお客様につきましては、ある程度のバージョンアップがなされるごとに最新版をお届けする予定です。なお、重大な欠陥が発見された場合は、バグフィックス版ができ次第お送りいたします。このようなことはないにこしたことはないのですが、、、

製品化に際しまして仕様変更は一旦停止しておりましたが、製品も無事発売できましたことから、仕様の改良に取り掛かりたいと考えております。現時点で検討対象としているのは次のような機能です。これらにつきましては効果と問題点を再度検討し、順次新機能として取り込んでいく予定です。

・論理演算結果がnan(真偽不明)となる場合の処理(nanとするか、真とするか、偽とするか):デフォルトの処理を環境変数によって選択できるようにするとともに、それぞれの結果を与える関数(たとえばand_nan, and_tol, and_intol)を準備しておく。

・信号線幅に余裕がある場合の誤差を含む桁数の伝達方法を環境変数で指定できるようにすること

・仮数の範囲にゼロが含まれない場合のオーバーフローを非ゼロとみなすか否かを選択可能にすること

・nan信号線を独立に設けるかof & ufで表現するかの選択を可能とすること

その他、処理内容をもう少しすっきりさせ、生成コードの冗長な部分を可能な限り排除する必要もあろうかと考えております。

とはいえ、これらは追加的な機能であり、バグが発見された場合はその対処が最優先であることは言うまでもありません。

その他ご要望などありましたら、この日記にコメントを付けるか、cs@signal-process-logic.comあてのメールでご連絡ください。よろしくお願いいたします。
posted by 管理人 at 14:05| Comment(0) | TrackBack(0) | 日記

2011年05月04日

4月度状況、その他

access1104.jpg少々遅くなってしまいましたが、先月度の状況を報告いたします。

まず、ホームページへのアクセス状況は図のようになりました。地震と停電のためと思われます3月の落ち込みのあと、アクセスは徐々に回復してまいりましたが、まだ元通りとは言い難い水準です。これにつきましては世情の安定を待つしかなさそうです。

今月度の特記事項は、CodeSqueezer Floatingのデバッグ作業が完了し、評価版を(先ほど)アップロードしたことです。あとはこれにガードキープロテクト部分を追加して製品版を発表するだけとなりました。

CodeSqueezer Floatingは、1月のEDS Fairでの発売予告からかなり遅れてしまいましたが、期日を一度先送りしただけで、なんとかお約束の連休明けに製品版の発表を間に合わせることができそうです。

デモ版と製品版の大きな違いは、オーバーフロー、アンダーフロー、数値化不能異常という異常フラグの処理を追加したことです。これが予想よりも相当に複雑であり、開発前に定めた仕様に一部不備な点があったことも重なり作業量が増大してしまいました。

MHDLでは(C言語でも同じですが)「論理の真偽」と「数値が0かそれ以外か」を同等に扱います。

第一に、浮動小数点の0をどのように判定するかが微妙な点となります。MHDLは信号の誤差の有無を分けて扱います。このため、誤差のない信号であれば、仮数部の全ビットが0である場合に論理「偽」を対応させ、誤差のある信号であれば環境変数で定めた誤差とみなすビット以外の部分がゼロである場合に論理「偽」を対応させれば良いことになります。

そのほか、信号線には異常フラグを伴う場合があり、これをどう扱うかも問題となります。

まず最初の問題は、オーバーフロー、アンダーフローが生じていてもゼロである可能性が残っている場合にどうするかという点です。これに関しては、オーバーフローが生じている以上、実際の信号値は非常に大きいと考え、0ではないものといたします。

つまり、信号の範囲が10〜100と規定されている場合、10以下はアンダーフローとなりますので、アンダーフローであっても値が0となる可能性があります。しかし、実際の信号値は負の値である可能性が高いことからゼロではない、「真」であるとみなします。

これは、おかしな扱いであると言えばそう言えなくもありませんが、実用上異常を正しく検出するためには、このような仕様とするしかありません。このあいまいさを防ぐためには、論理化される信号線に関しては、数値の正常な範囲に常に0が含まれるようにすべきでしょう。

もう一つの問題は、数値化不能異常(nan)をどのように扱うかという点です。nanを含む入力があった場合の論理演算結果はnanとするのが一つの合理的な考え方でしょう。もう一つの考え方は、「xxであると言える場合に結果を真とする」という判断基準を用いるもので、この場合の論理演算の結果は「真か偽か」の二通りとなります。つまり、後者の方法では演算結果にはnanは現れません。

ただしこの方法では、nandはandの否定とはなりません。つまり、入力にnanが含まれて演算結果が定まらない場合は、andもnandも出力は0(偽)となります。

このあたりはどちらの扱いが妥当か、簡単には結論が出るとも思えません。しかし、何らかの基準を定めないとソフトを作ることができません。そこで今回は、後者、第二の手法に基づいてコーディングすることとした次第です。これに関しては、絶対的な自信があるわけでもなく、皆様のお声によっては将来見直す可能性もある、とご理解ください。

と、いうわけで評価版の公開にこぎつけました。あとは、ガードキープロテクト部分を追加して製品版を完成させるだけです。これにはさほどの時間はかからないものとみております。もう少々お待ちください。
posted by 管理人 at 15:52| Comment(0) | TrackBack(0) | 日記

2011年04月01日

3月度の進捗状況

ホームページの開設以来のアクセス状況は図のようになりました。赤がページビュー(縦軸左)、青が訪問者数(縦軸右)で、ページビューは訪問者数の二倍程度となっております。3月中旬以降のアクセスが低下しているのは震災の影響でしょうか。access1103.jpg

CodeSqueezer Floatingの製品版につきましては、3月中の発売を目指して取り組んでまいりましたが、作業に相当の遅れが生じ発売を延期せざるを得ない状況となりました。製品版をご期待いただきました方々には大変申し訳ありません。

遅延が生じた理由は、仕様を見直した際に予想した以上に付帯作業が発生したこと、およびバグの対処に時間をとられたことなどが重なったためです。計画停電にも悩まされましたが、これがなくても製品版の3月末発売は難しかったものと思われます。

Demo 2.0から今回追加・変更した部分は以下の通りです。

・定数乗除算を高速アルゴリズムに変更したこと
・信号線名を記述する部分に定数の記述を可能としたこと(たとえば、out = mul(in1, 3)などの形)
・誤差のない信号どうしの除算を仮数部の整数除算とし、余りも出力するようにしたこと
・演算結果の有効ビット長が小さい場合、誤差部分も後段に伝達するようにしたこと

これに伴い、乗除算のコードは全面的に書き直し、あわせて異常フラグの演算簡素化も行いました。

新版のアップロードを見越してDemo2.0の使用期限を3月末としておりましたが、これを連休明けまでに延長した修正版をHPにアップロードいたしました。

今後の予定といたしましては、4月上旬に上記修正部分を含むDemo3.0(未検証版)をアップロードし、遅くとも連休明けには製品版の発売にこぎつけたいと考えております。


posted by 管理人 at 20:21| Comment(0) | TrackBack(0) | 日記

2011年03月01日

2月度の状況

2月のアクセス数は図のようになりました。データ数が増えたためかエクセルのグラフ表示ができないため、元の画像でご紹介しております。現在のところ、1日あたりのページビューは平日で300前後と、ほぼ安定しております。access1102.jpg

2月度は、CodeSqueezer Floatingの新バージョンをアップロードすべく作業を進めてまいりました。前回アップロードしたデモ版(EDS Fairで配布したCDに含まれているものも同じです)の使用期限が3/1で切れるためす。

デモ版の使用期限は、常に最新のバージョンを使っていただくよう、当初予定した新バージョンのアップロード時期に多少の余裕を見込んで設定しているのですが、作業が予定通り進まない場合には少々困ったことになります。そこで、前回アップロードしたデモ版の使用期限を1カ月延長した新バージョンをアップロードいたしました。

予定が大幅に遅れております主要な原因は、前回のブログでもご紹介いたしました仕様変更を行ったことです。

仕様変更の目的は、シフト演算省く代わりに定数乗除算を効率化することでして、定数乗算につきましては前回のブログでご紹介したように、一応の作業を完了いたしました。定数除算も逆数を乗算する形で比較的簡単に実現することができました。しかしながら、これに合わせて行いました乗除算全般の見直しにかなりの時間がかかることとなってしまいました。

CodeSqueezer Floatingは、誤差を含む演算に際して、有効な桁のみを扱うことで最小の論理資源で論理を形成することを特徴としています。その際の「有効な桁のみを扱う」方法には、実は、二種類の考え方があります。

「有効な桁のみを扱う」には、最長の有効桁を後段に伝達できるよう論理を形成しなければなりません。これにつきましてはどちらの考え方でも同じです。

第一の考え方は、「有効な信号のみを後段に伝達する」という考え方であり、第二の考え方は「伝達可能な最大の桁数を後段に伝達する」という考え方です。

たとえば16 bitどうしの乗算の場合、演算結果の最長有効桁は17 bitですので17本の出力信号線が形成されます。この演算器の双方の入力にビット幅8の信号が入力されると、第一の考え方に従えば有効桁数である9 bitを次段に伝達し、第二の考え方に従えば伝達可能な16 bitをすべて次段に伝達します。

第一の考え方は原理原則に忠実な考え方であり、これまでのデモ版はこの考え方に従って論理を形成していました。一方第二の考え方に従えば、生成される論理規模が多少小さくなり、伝達される余分なビットも誤差のキャンセルには有効に働くなど、実用性に優れる方式であると言えます。第二の手法を採用した際の問題点はゼロ付近であるか否かの判定が不完全になることですが、第一の方法でも、程度の差はありますが完全とは言い難く、第二の手法を否定する根拠にはならないでしょう。

CodeSqueezer Floatingをどのように考えるかは難しいところですが、これを商品として販売する以上、学術的なソフトウエアというよりは、実用的な論理を形成するために使用することを前提としなければならないでしょう。そうなりますと、第二の考え方に沿って論理を形成するべきであるということになります。

このような事情から、乗除算の論理形成部分を大幅に見直すこととなり、このために多大な時間を消費することになってしまった、というのが現状です。とはいえ、このような基本的部分を後になってから直すことも大変ですので、現時点で見直しを行うのは正しいことであろうとも考えております。

製品版を期待されている方々には大変申し訳ありませんが、もうしばらくお待ちいただけますよう、よろしくお願いいたします。

posted by 管理人 at 13:12| Comment(0) | TrackBack(0) | 日記

2011年02月15日

定数乗算について

以前のこの日記に定数乗算の最適化は非常に困難である旨を書きましたが、結局これにトライする羽目になりました。で、一応できましたのがこのプログラム。ダウンロードはこちらです。

EDS Fairも無事終わり、現在はCodeSqueezer Floatingの製品化に向けて鋭意作業中です。その過程で、仕様につきましても多少の見直しを行いました。その結果、定数も扱えるようにしようということになりました。

現在公開しているデモ版でも定数を扱うことができます。つまり、入力信号線のビット幅をゼロにしてバイアス部分のみを設定すれば定数として処理されます。しかしながら、複雑な演算モジュールで、定数とする信号線をすべて外部入力に引き出すことは煩雑です。そこで、リンク名を書く場所に定数を書くことで直接定数を指定できるよう、仕様を変更することといたしました。

検討をしたけれど仕様に含めなかった機能としてシフト演算があります。CodeSqueezer Floatingの標準ファンクションは、基本的にはC言語の式に記述できる演算子を網羅することを目標としていますが、一方でMHDLは抽象的な記述を可能とすること、すなわちハードウエアに依存する部分は排除することとしています。

C言語の演算子のうち、ビットごとの演算子はハードウエア依存性が高く、最初から論外としたのですが、実はシフト演算もハードウエアに依存いたします。つまり、二進法が前提となるのですね。そこで、ビットごとの演算だけでなくシフト演算もMHDLの標準ファンクションからは除外することにしました。

シフト演算がなくても定数乗除算により同じ機能を実現することができます。しかしこれを乗算論理で演算していたのでは、シフト演算に比べて論理が複雑になってしまいます。そこで、定数乗算を最も単純なシフト演算と加減算で構成することとした、というのが今回の試みの発端です。

このような問題はNP完全問題と呼ばれる、解を得るのに非常に時間のかかる問題として知られております。論理開発ツールがあまり演算時間がかかることは好ましくなく、適当なところで折り合いをつけなければなりません。

今回開発したアルゴリズムは、最適化を行うビット幅に制限を加え、これよりも長いビット幅の定数は桁をいくつかに区切ってそれぞれの部分について最適化を行うこととしました。極端な場合として、ビット幅を1に限定すれば立っているビットについて加算を行う、通常の定数乗算アルゴリズムとなります。

作成したソフトは種々の高速化を試みましたが、実用的な演算時間で最適化可能なビット幅は20ビット少々と考えられます。また、ビット幅の制限を種々変化させて加算回数の変化をみてみましたが、このあたりで少々ビット幅を増加させてもさほどの効果はみられません。そこで、デフォルトのビット幅を16としてさしあたりはソフトを組むことといたしました。

この手の回り道をしておりますとなかなか本題が先に進みません。製品発表は3月中とアナウンスしておりますが、デモ版の使用可能期間が2月末で終わってしまいますので、それまでにはデモ版なり評価版なりの形で、新しいバージョンをアップロードしたいところです。あと2週間は忙しい日々が続きそうです。

その他、ウィルスにつきましては先日、最強と評判の高いカスペルスキーでテストしましたが、問題は発見されておりません。これとても100%の検出ができるわけではなく、絶対確実とは言い難いのですが、ひとまず安心してもよいのではなかろうか、と考えております。

前回の問題は、機能が貧弱なノートパソコンでVistaを動かしているところに問題があった可能性が濃厚ではなかろうか、と考えている次第です。

posted by 管理人 at 18:07| Comment(0) | TrackBack(0) | 日記

2011年02月01日

1月度の状況

access1101.jpg1月のアクセス状況は図のようになりました。訪問者数、ページビューとも高いレベルを維持しております。

1月の特記事項は、27-28の両日にパシフィコ横浜で開催されましたEDS Fairに出展したこと。1月はこの準備にかなりの時間をとられましたが、展示会での反応は良好で、今回の出展は成功であったということができるでしょう。

今回の展示テーマは以前からご紹介しております“CodeSqueezer Floating”でして、複雑な演算論理が簡単に作成できる安価(予定価格39,800円)なツールにはかなりの需要があると確信できましたことが今回の展示会での大いなる収穫です。

当初の予定では、展示会に合わせて製品版を発売する予定だったのですが、予期しないバグが見つかったり機能の追加などを行ったことなどから現時点での製品化は困難と判断、展示会ではデモ版でのご紹介となりました。

ソフトウエアの開発当初は見通しの良い構造を心がけるのですが、途中段階で機能を追加したり、論理的な問題に対処したりしておりますと、当初の仕様を逸脱する部分が生じ、これが将来のトラブルの元となるケースが多々あります。特に今回のように展示会を控えた限られた時間の中でのソフト開発は種々の危険をはらんでいると考えるべきでしょう。

そこで、製品版を作成する前に、一旦全体のフローを見直し、すっきりとした形に再構成することといたしました。この時点で余分な作業はしたくないところですが、先々を考えればいずれかの時点階できちんとした形にしなくてはいけません。なお、大多数の処理はデモ版の機能をそのまま使用しますので、再構成自体はさほどの時間もかからないと考えています。

と、いうわけで、展示会場でもアナウンスいたしましたが、製品版の販売開始は3月中ということとし、それまでの約2カ月弱の間に再構成、若干の機能の追加および検証作業を行う計画です。製品版の発売に先立ちまして無償ダウンロード可能な評価版も公開したいと考えております。これらにつきましてはHPでご紹介いたしますので、ご興味のおありの方はチェックをよろしくお願いいたします。

その他、展示会で配布したCDに収録したデモソフトのインストーラが正しく生成されていなかった様子で特定のPCでは動作不良となるという問題が起こりました。PCやOSによって動作が異なる原因の一つに自動変数の初期値が関係していることがままあり、原因は不明ながらもすべての変数の値を初期設定するようにソフトを変更してインストーラを再度作成したところこの問題は解消しております。

原因がわからないというのは困ったことです。問題を起こしたPCが以前から不調であったことからPC自体の問題であったのかもしれません。また、ウィルスのチェックは行っているのですが、一般的なウィルス検出率は98%程度と、これらのソフトを使用したところでウィルスを完全に検出できるわけでもありません。ウィルスの問題につきましては、今後他のウィルス対策ソフトも使用してチェックを行う予定ですが、いずれにせよ困った問題ではあります。
posted by 管理人 at 15:11| Comment(0) | TrackBack(0) | 日記

2011年01月01日

12月度の状況

access1012.jpg12月のアクセス状況は図のようになりました。年末にかけてアクセス数が減少しておりますがこれを除けば、平日で300弱のページビューとなっております。ホームページのアクセス状況に関しましては、まずは順調といったところです。

次に今月の進捗状況ですが、12月には、オーバーフローフラグの処理を追加したほか、各演算ファンクションの検証を行っております。

CodeSqueezer Floatingでのオーバーフローフラグの取り扱いは、オーバーフローとアンダーフローを生じる可能性があるリンクについて、これらが発生したことを示すための二つの信号線を設け、これらが単独でHである場合にはオーバーフローないしアンダーフロー、双方がHの場合は数値化不能を表すこととしております。

この仕様は、加減算の異常処理を簡単に行うことを念頭に決めたものです。つまり、入力の一方が異常であれば出力も異常となりますし、オーバーフローとアンダーフローを加算した結果は不明となりますので、演算結果に対応するそれぞれの異常フラグは、入力のそれぞれのフラグの論理和により形成することができます。

この仕様を決めた時には、乗除算も加減算で構成されるのでフラグも簡単に演算できるだろうと考えていたのですが、実際にやってみますとそんな簡単な話ではありません。

たとえばゼロとの乗算にしても、誤差なしのゼロとの積はいかなる値であっても(オーバーフローしていようとも)ゼロなのですが、誤差のあるゼロとの積は符号不明の小さな値との積ですので、相手がオーバーフローしている場合には数値化不能ということになります。

結局のところ、乗除算の異常表示フラグの演算は、入力の状態(正の正常値、負の正常値、誤差なしゼロ、誤差ありゼロ、オーバーフロー、アンダーフロー、数値化不能)の組合せに対してそれぞれ決めてやる必要があり、かなりの処理内容となってしまいました。

当初、今月中に評価版を公開することを目標に作業を進めていたのですが、これらのフラグ処理に時間を取られた結果、検証作業が完了しておらず、評価版公開は延期の止む無きに至りました。しかし一方で、1月の27日には展示会が控えておりますので、それ以前に何らかの形にいたしませんと展示のネタがなくなってしまいます。

そこで当面の目標といたしましては1月中旬までの間に検証作業を進め、信頼性が満足すべきレベルに到達したことが確認できれば評価版を公開することといたします。不幸にして信頼性が十分であるとは言えない状態であった場合には、デモ版2.0の形で公開することといたします。

評価版、ないしデモ版2.0は、これまで公開しているデモ版に対して次の点が改善されています。

・除算ファンクションと論理による乗算ファンクションを追加したこと(デモ版ではVerilog HDLの乗算コードを出力するのみで、除算ファンクションは全く準備されていませんでした)。また、乗算ファンクションの出力ビット幅が長すぎるという問題点を修正しました。
・異常フラグの処理が正しく行えるようにしたこと。(デモ版ではフラグを無視していました)
・チェッカとパーサのバグ(複数の出力をもつファンクションを利用した場合の異常など)をfixしました。

これ以外にもこの先、比較演算や論理演算等の追加も必要であると考えています。これらはさほどの負荷にはならずに実施できるはずです。

1月の大きなイベントは27〜28日のEDS Fairでして、弊社はこれへの出展を予定しております。今月はこのための種々の材料を準備しなければいけません。それやこれやで、正月返上の作業を余儀なくされております。

その他、1/13にはFPGA Conferenceというのが秋葉原で開催され、チップベンダ各社の最新情報のプレゼンが行われます。この聴講もエントリーしておきました。面白い話が聞けたら来月度にご報告することといたします。

展示会関係では、12月の初旬にはセミコンジャパンが幕張で開催されましたので見学してまいりました。今回のセミコンジャパンの特記事項は露光機(ステッパ)の展示がなかったこと。例年であれば、ニコンやキヤノンが大々的な展示を行っていたのですが、本年は非常に地味な展示となりました。

展示会の客足自体は悪くはないのですが、展示会の規模は縮小しており、対象分野も幅広いことから、弊社が出展すべき展示会ではなさそうだとの印象を受けました。

と、いうわけで、来年度弊社が出展する展示会は、EDS Fairか、あるいは秋のエンベデッドテクノロジ(組込機器)展ではなかろうか、というのが現時点での印象です。エンベデッドテクノロジ展は5月にも開催されますので、これについては要チェック、ということになります。
posted by 管理人 at 14:29| Comment(0) | TrackBack(0) | 日記

2010年12月01日

11月度の状況

access1011.jpg11月度のアクセス状況は図のようになりました。アクセスは急増し、平日のページビューが300近くまで増加しております。ホームページのリニューアルやCodeSqueezer Floatingデモ版のアップロードのためでしょうか。

今月度は、月初めにデモ版をアップロードしたのに続き、製品版の作成に取り組んでおります。製品版は基本的部分はデモ版と同じですが、論理による乗除算機能を追加することとしております。特に除算の論理を自動形成する部分は少々複雑であり、このために今月の時間の大部分を取られてしまいました。

とはいえ、一応動作する除算モジュール自動形成関数は出来上がり、現在は検証作業を行っている段階です。ある程度の動作が確認されましたら、評価版の形で公開したいと考えております。

弊社は来年1月末に開催されるEDS Fairへの出展を計画しているのですが、12月の上旬にこれのニュースサイトが開設されます。ここにニュースを出しますと多少は注目してもらえるのですが、ニュースのネタがありませんとニュースを出すこともできません。

CodeSqueezer Floating評価版の公開は一応のニュースネタとなりますので、これは大事に使わなくてはいけません。と、いうわけで、評価版の公開はニュースサイト開設後に行いたいと思います

その他、本日は“エンベデッド・テクノロジー展”を見学してきました。この展示会は組込システムの展示会で、マイコン関係が多いようでしたが、FPGA関係も展示されております。客足は良好で、ひょっとすると宣伝効果も高いかもしれません。小さなブースを出している会社もちらほらとあり、来年はこちらへの出展も要検討というところでしょう。

その他、本日から幕張メッセでセミコン・ジャパンが開催されております。こちらも関係がないわけではありませんので、明日か明後日時間を都合してみてこようかと考えております。幕張は遠いのですが、情報収集も大切ですから、致し方ありません。
posted by 管理人 at 18:19| Comment(0) | TrackBack(0) | 日記

2010年11月04日

ホームページをリニューアルしました

先日お約束の通り、CodeSqueezer Floatingの専用ページを作成し、デモ版をアップロードいたしました。これに合わせて、ホームページをすっきりとした形に変更しました。

この時点でホームページの大改造に踏み切りました理由は、CodeSqueezer Floatingが技術的にめどがつき、デモ版も公開して一段落したということ、およびEDS Fairに向けていよいよ本命製品のマーケティングに乗り出そうという時点で、かねてからの懸案でありましたホームページを改善しようという、その二点にあります。

これまでのホームページは、会社設立の際にWebデザインの書籍を参考につくったもので、およそ書籍に書かれていた実例に近い形を狙って作成したものです。

しかしながら、お手本となりましたのがどちらかといえば大会社向けのホームページで、ひょっとすると株式を公開しているような会社を念頭に例がつくられていたような気がいたします。これは、我々のような弱小会社がまねをするのも少々おこがましい気がいたします。

もう一つの問題は、書籍ですからさまざまなテクニックを駆使したページを例に書かれているのですが、中途半端に策を弄しますとブラウザによっては正しく表示されないという問題があります。特に、広く使われていると思われるMSIEが、他のブラウザとの互換性が悪く(というよりもMSIEの動作が標準から外れているようで)ページが乱れて表示されてしまいます。この問題は以前から気付いており、なんとかしなければいけないと考えていたのですが、なかなか手が出せずに今に至ってしまいました。

もちろん、その後に作成した製品紹介のページではこのような問題が発生しないよう、複雑なタグの使用は極力避けて、文字をセンタリングしたり背景イメージなどを使用して、ブラウザが変わろうが表示サイズが変わろうが、それなりにちゃんと表示されるようにしておりました。

今回行いました大改造は、同様のテクニックをホームページにも応用したものです。ブラウザとしてMSIE、Fire Fox、Chromeの三種類を使い、画面サイズを大きくしたり小さくしたり、文字サイズをいろいろと変えたりしてテストを行いましたが、おおむね正常に表示できるようです。

高解像度で全画面表示をした場合には少々バランスが悪い感じも致しますが、ドット数の小さな画面で支障なく表示できるようにするためには、この程度は我慢しようという判断です。

あとはVerilog HDL CodeBookの目次ページを何とかすればホームページの方は一応カタが付くのですが、こちらはCodeSqueezerのマーケティングとは別のお話ですのでさほど急ぐ必要はないものと判断しております。それよりも、CodeSqueezer Floatingの評価版と製品版の制作を急がなければいけませんし、何よりも完全な形で製品化しなくてはなりません。優先すべきはこちら、というわけです。
posted by 管理人 at 23:15| Comment(0) | TrackBack(0) | 日記

2010年11月01日

10月度進捗状況

access1010.jpg10月のアクセスは図のようになりました。アクセスは回復傾向にあるとも言えそうですが、変動の範囲であるのかもしれません。

先月までは毎月のアクセスをまとめてご紹介していたのですが、さくらのシステム変更のためか、なぜかエクセルにアクセス記録を取り込むことができません。この先もう少しトライして、できれば来月分にはまとめの記録をご紹介できるようにしたいと思います。(11/10追記:まとめの図ができましたので追加します)

さて今月の状況ですが、まず、“CodeSqueezer Floating”のデモ版はほぼ出来上がり、今週中にはアップロードできる見通しです。(11/2 追記:アップロードしました。こちらのページをご覧ください。)

これは、浮動小数点演算を含む複数の演算機能を相互に接続した信号処理論理を簡単に作成することができるソフトで、動作の雰囲気を味わうためのデモ版を間もなくアップロードするのに続き、年内には評価版を、そして来年早々には製品版を出したいと考えております。

既にアップロードしております“CodeSqueezer Basic”は、製品版とまったく同じ機能をもつ評価版を無期限に使用可能な形で無償ダウンロードできるようにしており、著作権上の縛りを設けてはいたのですが、評価版の存在が製品の販売には相当にマイナスとなっていたのではないか、と反省しております。

そこで、この先で無償配布するデモ版・評価版には使用可能期間を設け、評価に十分と思われる時間が経過した後は使用不能にしたいと考えております。お早めにご評価いただけますよう、よろしくお願いいたします。

その他の近況ですが、まず、10月早々にCEATECを見学してまいりました。この展示会はマスコミでも大きく取り上げられており、相当に盛況ではないかと期待して出かけたのですが、人が集まっていたのは3Dテレビの前だけで、その他の場所は閑散としております。

特に今年から新設された“CEATEC Suites”は、展示期間も短く料金も安く設定ということで期待したのですが、客足はほとんどない状況で、これでは出すだけ無駄との印象を受けました。出展社の方に費用をうかがったのですが、それほど安くもない様子で、ここに出展する意味はない、というのが今回見学しての結論です。

展示会に関しては、来年1月27〜28日開催のEDS Fairへの出展を計画しており、今月は説明会に行ってまいりました。CEATECがあの調子では、こちらの展示会もあまりお客が来ないのではなかろうかという気も致しますが、今からそんなことを言っていても始まりません。やることはきちんとやろう、というのが現在の方針ではあります。

というわけで、当面の課題はEDS Fairに合わせた“CodeSqueezer Floating”の製品化でして、まずは近々にデモ版をアップロードすること、12月初旬のEDS Fair出展社のプレスリリース機能が使えるようになる頃合いに評価版を発表すること、そして展示会に合わせて製品版を発表するという段取りがベストであると考えております。

評価版は製品版とほとんど同じに致しますが、デモ版と評価版の間には機能的にもかなりの開きがあり、デモ版の発表から評価版の発表までの間が技術屋的には大仕事ということになります。

計画は万全と自負しておりますが、さて実行の方が予定通りまいりますかどうか、これからが正念場です。
posted by 管理人 at 13:48| Comment(0) | TrackBack(0) | 日記

2010年10月04日

9月度進捗状況

access1009.jpgホームページのアクセス状況は図のようになりました。夏休みで落ち込んでおりました先月のアクセス数ですが、9月に入ってもあまり回復はしておりません。DAシンポジウム発表予告の効果で7月までのアクセス数が異常に多かったのかもしれません。

学会発表も無事終わり、次のイベントは来年1月のEDS Fairです。ここでは新製品“CodeSqueezer Floating”(以下CSFと書きます)の販売開始をアナウンスする計画であり、それまでに製品を完成させることが当面の重要課題となります。

CSFのデモ版はDAシンポジウムでもお披露目いたしました。当初はデモ版のバグを取り除いて製品版とする計画だったのですが、いくつかの方針変更を行った結果、全面的に作り直す羽目となっております。とはいえ、一旦作成したソフトですから、9月末の時点でデモ版に近いレベルまでは完成しております。

デモ版(学会発表内容)からの仕様変更点は次の通りです。

・誤差を含まない数値の扱いが、デモ版では整数に限定されていたものを、全ての数値表現形式に拡大したこと:これは、既に発売しているCodeSqueezer Basicに対する上位互換性をもたせるための処置です。

・生成コードの検証機能を設けたこと:入力信号範囲からテストベクターを自動生成し、生成コードに1対1に対応する中間形式コードを解釈実行することで、生成コードの正当性をチェックします。

・論理仕様定義に使用する言語(MHDL)仕様に、ファンクション名の通用範囲(スコープ)規定を追加したこと:名前の衝突を防ぎ、階層的プログラミングを容易にするための配慮です。

CSF発売後は、販売中のCodeSqueezer Basic(CSB)を廃版として、CSFに一本化したいと考えています。

CSFはCSBに対して上位互換性があるため、この一本化によって大きな問題は生じないと考えておりますが、同一の論理仕様を与えた場合にも生成されるコードには多少の差があるため、いきなり製品版を廃版とすると問題を生じるかもしれません。このため、製品切り替えの事前アナウンスを近々に行いたいと考えております。
 
サポートを一元化するため、CSBを既にお使いのお客様に対してCSFへのバージョンアップを無償でおこなうことが最低限必要であろうと考えています。CSFの定価はCSBに多少の上乗せすることを計画しており、購入時期の異なるお客様には不公平な扱いとなってしまいますが、業務効率化のためのやむを得ない処置であることをご理解いただきたいと思います。

その他の話題をいくつか。

今月はCEATECが幕張メッセで開催されます。CEATECは来場者も多く、宣伝の場としてはEDS Fairよりも有効なのですが、5日間開催で経費もかかることから出展には二の足を踏んでおりました。しかし本年からはCEATEC Suiteという3日限定で出展料も安価なコースが新設されたとのこと。来年度はこちらに出展することも検討したいと思います。いずれにせよ、今週の後半に見学してまいります。

電子情報通信学会誌ではここ数カ月にわたってFPGAに関する連載記事を載せておりました。今月号は最終回で、FPGAの基本構成に関する特許と開発の流れを解説しております。よくまとまっておりますので、この分野にご興味のある方はご一読ください。
posted by 管理人 at 11:23| Comment(0) | TrackBack(0) | 日記

2010年09月03日

8月度状況

acess1008.jpg8月のアクセス結果は図のようになりました。8月は夏休みということもあり、アクセス数は少々下がっております。夏休み明けの動向が気になるところです。

9/2-3に豊橋で開催されましたDAシンポジウムに発表したため、このブログの記述が少々遅れる形となりました。DAシンポジウムでの発表内容につきましては間もなく弊社ホームページからアクセスできるようにいたします。

DAシンポジウムでの反響は今一つといったところ。DAとは「デザイン・オートメーション」の略で、論理設計支援を対象とするシンポジウムなのですが、環境としてのツールというよりも、デザインオートメーションを構成するための個々の技術の詳細に関する議論(たとえば、省電力構成にするための手法など)が中心で、今回の私の発表とは少々色合いが異なります。また、発表者、聴講者とも学生さんが中心で、直接の商売には結び付きそうにないのが難点です。

とはいえ、シンポジウムのプログラムはWebからも参照できますし、立派な論文集に私のプレプリントが収録されておりますので、より多くの人がこの技術や会社を知る上では有益であると言えるでしょう。学会というのはそういうものであると割り切って考えるのが正しそうです。

この学会でデモするため、8月は“CodeSqueezer Floating”のデモ版ソフトの制作に注力しました。もちろんデモ版とはいえ内部で行っている処理は製品版と同様であり、この作業は製品版をつくる一つのステップでもあります。デモ版ソフトは、機能も限定的であり、まだかなりのバグがあるのですが、製品版の動作イメージがつかめるものとなりました。デモ版の操作方法と画面表示につきましても、後ほどホームページからアクセスできるようにいたします。

さて、あとは製品版をつくるのが当面の目標となります。製品版発売予定が来年1月であることは今回の学会発表でもアナウンスしており、来年1月のEDS Fairにもエントリーしたこともあり、このスケジュールはなんとしてでも守りたいところです。年内は製品版の開発に注力するしかありません。
posted by 管理人 at 17:40| Comment(0) | TrackBack(0) | 日記

2010年08月01日

7月のアクセスその他

access_1007.jpg7月度のアクセスは図のようになりました。夏休みのためか、20日以降は多少減少していますが、順調にアクセス数は増加しています。

今月は、DAシンポジウムのための準備を行ったほか、決算処理を行っています。

DAシンポジウムの報告内容につきましては、発表後HPに掲載します。また、決算につきましては、税務署への届けを行い訂正が入らないことを確認したうえでHPに置く予定です。

というわけで、7月も忙しい月ではあったのですが、ご報告できることはあまりないのが実情です。
posted by 管理人 at 18:14| Comment(0) | TrackBack(0) | 日記

2010年07月01日

2010年6月度進捗状況

access_all.jpg6月のアクセス結果は図のようになりました。先月までは一月分だけを表示していましたが、全体的な流れがわかりやすいよう、この図では昨年6月からの推移を示しています。休日のアクセスが周期的に落ち込むことから、土曜日と日曜日の結果は除外してプロットしています。

平日のアクセスでもかなりの波があります。正月休み、夏休み、ゴールデンウィークなどで落ち込みを示す半面、EDS Fair出展前後で盛り上がりを示しています。また、ページをリニューアルしたり、ソフトウエアをアップロードしたりするとアクセスが増加する傾向があります。その他、昨年の6月にはspammerが毎日50前後アクセスしておりましたが、spammerは除外して考えないといけません。

これらの波を無視いたしますと、昨年6月の平日のページビューが150程度であったものが、先月は250程度まで増加していることが分かります。ページビューの目標は一日1000程度と考えているのですが、まだまだ道のりは遠いようです。

今月の特記事項は9月に開催されますDAシンポジウムへのエントリーが認められたことです。プログラムも既に公開されております。2A-1の“浮動小数点処理を含む論理設計支援システム”と題するものが私の発表です。ポスターセッションにも参加いたしますので、ご興味のある方は是非どうぞ。

プレプリントはすでに作成して送ってあるのですが、先月書きましたように発表日まではその内容は伏せておくことにし、発表日以降にホームページからリンクを張るようにいたします。その際は、発表の際のスライドやデモソフトなども参照できるようにしたいと考えております。

その内容ですが、詳細をお話しすることはできないのですが、題名とこれまでの日誌からおおよそ想像されますように、“CodeSqueezer Floating”の技術内容のご紹介ということになります。この製品は、“CodeSqueezer Basic”の次世代製品で、前回製品と同様の演算モジュールを自動生成するソフトなのですが、機能的には浮動小数点処理を含めたことと複数の演算モジュールの接続を可能としたところが大きく進歩しています。

複数の演算モジュールを接続するということは、信号処理論理を全て記述することもできるということで、単品の演算モジュール作成とは質的に異なる製品となります。低価格路線は継続する計画で、前回製品の倍程度の価格設定とすることを計画しています。

問題はこれのデモ版ソフトの製作でして、ある程度見栄えのするサンプルをDAシンポジウムまでに完成させて、ポスターセッションでデモをしたいところです。なにぶん、DAシンポジウムには潜在顧客の方々が大勢みえられるはずですので、、、

その他、今月はEDS Fairの説明会にも参加してきました。EDS Fairは来年1月の開催予定となっております。これまでに“CodeSqueezer Floating”の検証作業を終え、展示会に合わせて製品版を発表する、というのが現時点でのスケジュールとなっております。
posted by 管理人 at 11:44| Comment(0) | TrackBack(0) | 日記

2010年06月01日

2010年5月度進捗状況

access1005.jpg5月のアクセス結果は図のようになりました。多少アクセスが増加しているような感じもしますが、およそのところ平日のアクセスは訪問者が100、ページビューが200前後というこれまでのレベルとほぼ同様です。

access_year.jpgsignal-process-logic.comのサイトは昨年5月に立ち上げております。これから1年を経過いたしましたので、この1年間の訪問者とページビューの推移をまとめてみました。

アクセスは、夏休み期間や正月に落ち込みがありますが、これら以外の期間ではおよそ訪問者100、ページビュー200の前後で安定しています。贔屓目には漸増と言えなくもないかもしれませんが。

2010年1月末に増加がみられますのはEDS Fairへの出展効果であると思われます。この展示会へは来年も出展する計画で、この6月には説明会がありますので話を聞きに行く予定です。

業務の方は順調に進展中です。

先月ご報告いたしましたように、次期製品のターゲットを浮動小数点処理処理に絞って製品開発を進めております。開発の過程で少々面白い着想が得られましたのですが、これにつきましては学会で発表することとし、それまでは具体的内容は伏せておくようにしたいと思います。

なにぶん、学会発表には多少のサプライズがないといけませんし、ここに書いてしまいますと同じようなアイデアを誰かが発表してしまうかもしれません。今回得られた着想がどの程度業界受けするかは定かではありませんが、これが多少なりとも話題になってくれますと宣伝効果もあるでしょうし、ページビューも増えることが期待できますので、ここはしっかりと作戦を練らなければいけないところです。

と、いうわけで浮動小数点処理につきましては学会発表後に詳細をご紹介することといたします。

次期製品のに含めたい機能といたしまして、複数の演算機能の相互接続ということを先々月のこのブログに書いていたのですが、こちらに関しても検討を進めております。

list.jpgここに示しました図は、リスト形式で複数機能を入力する画面です。上部の“Add”と書かれたボックスで種々の機能を選択しますとこれが画面下側の大きなリストボックス(メインボックス)に挿入されます。ここに表示された機能パーツの未接続入力ポートは左上の小さなリストボックスに表示され、この任意の行を選択した状態でメインボックスの出力ポート行をダブルクリックすることでこれら相互が接続されるという仕掛けです。

メインボックスの行頭のマークはこの行をダブルクリックしたときに生じる効果を示すもので、“-”は縮小(機能名のみを表示してポート情報を隠す)、“+”は展開、“!”は詳細設定ウィンドウを開く動作が行われます。また、各行でマウスを右クリックすることでポップアップメニューが開き、接続解除や機能パーツの削除などを行うことができます。

右上のラジオボタン“func”と“node”はメインボックスの表示を切り替えるもので、これを“node”にするとVerilogのソースコードに類似した展開結果が表示されます。また、“sort”ボタンを押すと、メインボックスの表示を信号の流れに従う形にソートします。

このソフトは製品化を目的に開発したものではあったのですが、実際にこれで多数の機能パーツを組み合わせた論理を作ろうといたしますと、作業が煩雑で全体像が見えにくいという問題が明らかになりました。このため、一旦この方向での製品開発はペンディングとし、浮動小数点処理に開発目標を絞ったというのが先月時点での状況でした。しかし、実用性を考えますと複数パーツを接続する機能はほしい所であり、これをどのように製品化するかという点につきましても検討を進めております。

現時点で得られております方向は、“言語による仕様表現”というものでして、機能パーツを相互に接続して複雑な論理機能を規定するための言語を新たに開発するというのがその解ということになります。

ここで言語と云いましてもそうそう複雑なものではなく、現在考えておりますのは以下のような仕様の言語です。

・機能パーツは関数で、接続線は名前(コンピュータ言語でいう変数名)で表す。
・プログラムの要素は代入文のみで、以下のいずれか。(信号線が単一である場合はかっこは省略可能)

  (出力信号線、出力信号線、、、) = 関数(入力信号線、入力信号線、、、)
  (出力信号線、出力信号線、、、) = (入力信号線、入力信号線、、、)
  
・右辺に現れる信号名はそれ以前の行の左辺に現れていなければならない。例外はforward関数。
・右辺には式も許す。式は処理の開始時点で関数呼び出しに変換される。
・仕様の階層的記述も許す。それぞれの仕様の先頭は、名称.(出力ポート名、、、)(入力ポート名)
・仕様記述の範囲は字下げで表現する。

この言語仕様につきましては詳細がまとまりました段階で報告いたします。言語ですから標準化、普及活動も必要であり、このためのサイト“MHDL.org”を立ち上げました。現在は工事中ですが、この言語に関するアナウンスや議論はこちらのページで行い、ゆくゆくは本言語の仕様管理を中立組織“MHDL.org”に委ねたいと考えております。

あ、そうそうMHDLはminimized hardware description languageの略で、並列処理論理を形成することからHDL、生成される論理も仕様記述も最小化することからminimizedとしております。

MHDLという名前は、実はすでにいくつか発表されております。しかもHDL部分は同じでして、Mの部分がmimicであったりmicrowaveであったりいたします。ただ、mhdl.orgというurlは未だ獲得されておりませんでしたので、これらの言語は本気で標準化を目指したりはしていないものと判断いたしました。urlは早い者勝ちですから、これは私たちが頂き、というわけです。

というわけで、学会発表、製品開発、言語仕様の制定と、いろいろとやらなければならないことが増えてまいりましたが、面白いものができそうな感じもいたしております。それぞれのテーマにつきましてはまとまり次第ご報告いたします。今後ともよろしくお願いいたします。



posted by 管理人 at 10:13| Comment(0) | TrackBack(0) | 日記

2010年05月01日

4月のアクセス結果、その他

access4.jpg4月のアクセス結果は図のようになりました。HPへのアクセスはほぼ変わらず、平日の訪問者が100前後、ページビューが200前後となっております。

先月来頭を悩ましておりました次世代製品ですが、結局最初から取り上げたいと考えておりました、浮動小数点処理にチャレンジすることといたしました。

FPGAを用いた信号処理の場合、浮動小数点処理はあまり一般的ではなく、固定小数点表現を用いる例が多いのが実情です。これは、浮動小数点処理に際しては、演算の前後で左右にシフトする処理が必要であり、このためのバレルシフタに論理資源が多く消費されてしまうことによります。

とはいえ、浮動小数点処理が全く行われていないわけでもなく、学会発表レベルでは2〜3年ごとに報告が散見されますし、応用例も少ないながらもないわけではありません。浮動小数点処理は、確かに論理規模が大きくなるという欠点はあるのですが、扱う数値のダイナミックレンジが広く、オーバーフローの危険が少なくて小さな数値も正確に扱えるという利点もあります。

浮動小数点処理を要求する市場規模がどの程度あるか、という点は問題ですが、技術的な特徴はあるが市場規模は小さい分野は、実はこれこそがベンチャービジネスが狙うべき分野なのでして、市場規模が小さいが故に大手ベンダーは手掛けにくく、小さな会社でも資源を集中すれば充分に競争に勝てる分野であるわけです。

ベンチャービジネスにとっての問題は、市場の小ささよりもむしろ将来性なのですが、浮動小数点処理が特性に優れるにもかかわらず論理規模の増大が普及の障害となっているということであれば、その将来性は大いにあると考えてもよさそうです。なにぶん、時の流れに従って、この手の機器への要求はどんどん高度になる一方、半導体はどんどん複雑なものが安価に手に入るようになるはずですから。

と、いうわけで、浮動小数点処理のための各種モジュールを提供する、という作戦はなかなか筋が良さそうです。

次の問題は、商品コンセプトということになるのですが、浮動小数点の標準規格としてIEEE754規格があり、これを処理するモジュール群はすでに各社が提供しております。そうなりますと、いまさら同じものを出しても話にならないわけで、何らかの特徴が必要ということになります。

IEEE754が定める浮動小数点規格は、非常によくできたものではあるのですが、なにぶんタイプが少ししかなく、異常状態の表現などは手が込み過ぎており、論理に落とす際に複雑なものとなってしまいます。これをより簡単なものにして、必要最小限の論理で実現できるようにする、というのが第一の狙い目でしょう。

第二には、CodeSqueezer Basicで行いましたような、コーディングの手間を省く様々な機能がウリになりえるはずで、これと形成される論理の小ささをアピールすれば、そこそこ売れる製品となりそうです。

と、いうわけで方向は定まりました。これを具体化するアイデアもいくつかあり、今月は各種のテスト版を作って検討を始めております。まだ内容をご紹介できる状態ではないのですが、いろいろと面白い可能性も開けております。

浮動小数点処理は複雑になる、ということは論理開発もそれなりに複雑となります。また、浮動小数点用の評価環境も改めて準備しなくてはなりません。そういう背景もあり、評価版をアップロードできるのは8月ごろになりそうです。もちろんこれ以前でも、ある程度形になったた段階で概要を発表するようにしたいと考えております。
posted by 管理人 at 15:25| Comment(0) | TrackBack(0) | 日記

2010年04月01日

3月の結果

access1003.jpgまず、3月度のウェブページのアクセス状況は右図のようになりました。アクセス数は従来とほぼ同様の結果となっております。



CodeSqueezer Basicの次世代バージョンの準備ということで、グラフィックユーザインターフェースの改善を行いました。ただしこれは、準備をしたというだけのことで、製品として完成したものとはしておりません。

basicII.jpgBasicIIの画面を右の図に示します。画面にはパーツとその入出力ワイヤが表示されており、機能が選択されると、その内容がパーツ部分に表示されます。入出力ワイヤの図上にマウスカーソルを置くとワイヤの色が変化し、マウスを左クリックすることで入出力の定義を行う画面が開きます。

以前の画面よりは随分とスマートな形にはなりましたが、機能的にはさほど変化しておらず、現段階で改めてバージョンアップする必要もなかろうと判断している次第です。今後は、売れ行き状況や客先からの要望をみて、BasicIIバージョンの製品化を検討したいと考えています。

と、いうわけで現行製品の改良にめどがつきましたので、機能面を強化した次世代製品についての検討を開始いたしました。

ひとつのテーマは、複数のパーツの組合せを可能とするというものです。しかしながら、表形式でこれを行うことはさほど難しくはないのですが、CADソフトのように、グラフィック画面でパーツを配置して結線するというソフトとなりますと相当な開発工数が必要となります。

第二のテーマは、演算対象を浮動小数点数値に拡張しようというものす。こちらの問題は論理規模が大きくなるという点で、実用性を考えれば小さな論理で浮動小数点演算を実現することができるかどうかが問題となります。

これらにつきましては、まだ時間もありますことから、いろいろやって様子を見ようと考えております。

その他、FPGAに備わっている乗算器やRAMの利用がかねてよりの懸案だったのですが、これにつきましては一応のめどがつきました。

まず、乗算器はVerilogコード中に乗算演算を含めれば、コンパイラが自動的にハードウエア乗算器を割り当ててくれます。このテクニックはアルテラの技術資料に紹介されているものですが、ザイリンクスの資料にも同様の記述があり、一般的に可能な方法であるように思われます。

この技術資料にはRAM、ROMの利用方法も記述されています。レジスタファイルを記述すればRAMが割り当てられ、定数代入文のみを含むcase文を記述すればROMが割り当てられるというのですね。

なるほどこれは悪いやり方ではありません。と言いますのは、ハードウエアのRAMが利用できない場合にも、このように記述すればVerilogの処理系が目的とする動作を自動的に実現してくれるはずですから。

ちなみに、式中に除算(a / b)を記入すると自動的に除算論理が形成されます。ただしこの除算器は論理遅延が非常に大きく、余り実用的であるようには思われません。

と、いうわけで、業務の方は着々と前進中です。現在は、製品を出したばかりということもあり、ここは次の製品開発を急ぐというよりは、技術的な基礎固めをしっかりと行い、製品コンセプトの部分で間違いがないようにとり進めていきたいと考えています。

しばしは具体的な製品イメージがはっきりといたしませんが、これにつきましてはもう少し明確になりました段階で改めてご紹介することといたします。
posted by 管理人 at 13:31| Comment(0) | TrackBack(0) | 日記
Powered by さくらのブログ