FC2カウンター FPGAの部屋 CQセミナに行ってきました
FC2ブログ

FPGAやCPLDの話題やFPGA用のツールの話題などです。 マニアックです。 日記も書きます。

FPGAの部屋

FPGAの部屋の有用と思われるコンテンツのまとめサイトを作りました。Xilinx ISEの初心者の方には、FPGAリテラシーおよびチュートリアルのページをお勧めいたします。

CQセミナに行ってきました

今日は東京の巣鴨に行って、”高性能デジタル回路設計の基礎と最新動向”というセミナを受けてきました。このセミナは、13,000円で安いです。CQ出版社のセミナは良心的だと思います。講師は”HDLによる高性能ディジタル回路設計”などを書かれているNEC研究所の森岡澄夫さんでした。
高度なことを聞けるのかな?と期待して行ったのですが、メインの対象はソフトウェア技術者でハードウェアを始めたい方のようです。回路の動作、Verilog記述、回路の構造が関連付けられるようにするという感じでした。
後半は回路は並列化できるとか、レイテンシやスループットの話、クリティカルパス、フォールスパス、マルチサイクルパスや、マルチクロックのメタステーブルなどでした。興味深い話も聞けたのですが、全体的に初級者用かな?という内容で、少しがっかりしました。もちろん、HDL初級者の人が聞けば、素晴らしい講義だったと思いますが、私には、少し物足りない内容でした。ただ、森岡さんの講義は面白かったです。もう少し突っ込んだ内容が聞きたかったです。
もっと、上流のモジュール分割の方法やコンセプト、注意する点など、(少しはそういう話もありました)を専門的に聞きたかったです。
なかなか、そういうセミナはなさそうですね。今のところ、メインの仕事では、モジュールが自立して動作して、データパスはクロスバーとなっていますが、Readの時はコマンドを投げて、データを出すモジュールがマスタとなるように作っています。(PCI-Xのスプリットトランザクションに似ています)結構、複雑な構造になっているのですが、他の方はそのような実装をどのように仕様を決定して、作っているのか知りたいと思っています。もしかすると、全部スクラッチから作っている方は少ないのかもしれませんね。

最後に今日の昼ごはんの一部。リトルマーメードのパンです。最初はマカダミアナッツ塩パン。マカダミアナッツの風味がとてもよかったです。(私はナッツが好きです)
LM_pan_1_090821.jpg

次はカマンベールチーズのパン。上の焦げが香ばしくておいしいです。
LM_pan_2_090821.jpg

しかし、巣鴨はいろいろお蕎麦屋さんや食堂、パン屋さん、コンビニとかそろっていて、本当にいいですね。新宿や新横浜より昼食が選べますね。下町の感じで、私には心地よいです。
  1. 2009年08月21日 20:43 |
  2. その他のFPGAの話題
  3. | トラックバック:0
  4. | コメント:9

コメント

CQ出版社のセミナは良心的ですよね。
比較的、どのコースも初級→中級少し手前レベルの人が聞くと
良いんだろうな・・・という内容だと思います。

marseeさんのレベルまで行くと、
どんなセミナーでも物足りなくなりそうです。


>ソフトウェア技術者でハードウェアを始めたい方

最近、HDLや動作合成ツール関係でこの手の話が
多いですよね。今月のインターフェイスか何かの特集も
この手の話でしたね。
ソフトウェアでも、ハードの近い所の仕事をしていると、
ハードウェアのありがたみが解りますが、
上位のOS等のフレームワークの上で
仕事をしているアプリケーションエンジニアの人は、
どんどん抽象化していこうとしていますので、
ベクトルが少し違いますね。
  1. 2009/08/21(金) 21:35:13 |
  2. URL |
  3. ぽっぽさん #rJwIuDc6
  4. [ 編集 ]

 こんばんわ。

>なかなか、そういうセミナはなさそうですね。今のところ、メインの仕事では、モジュールが自立して動作して、データパスはクロスバーとなっていますが、Readの時はコマンドを投げて、データを出すモジュールがマスタとなるように作っています。

 そんな、ご要望、CQのセミナーで応じられる訳がございましぇーん^^;)。各モジュールが独立に動いて、要求に応じて互いにデータを投げ合うのを、下手すりゃ数十GByte/secレベルでやろうって話ですよねー^^;;)。まあ、NECとかは結構まともなこともやってますが、他のF社とかDQNじゃないかと思うほど、レベル低いですからねー。日本で探しても、そんなセミナーないかも(じゃなくて、ないでしょう)。

 それは兎も角、パン、おいしそうですねー。やっぱ、東京は旨い物が集まるようですねー。私の町では、腕の良いシェフがレストラン開いても、周りに味の分かるやつがいなくって、すぐ潰れてしまいます。レベルの高いところにはレベルの高い者(物)が集まり、その逆は・・・、ってことでしょうねー。
  1. 2009/08/22(土) 02:07:55 |
  2. URL |
  3. くり #mQop/nM.
  4. [ 編集 ]

ぽっぽさん、くりさん、コメントありがとうございます。

ぽっぽさん
>marseeさんのレベルまで行くと、 どんなセミナーでも物足りなくなりそうです。
セミナは初級者の物が多いですから、物足りないことが多いんですが、必ず1つはなるほどと思うことがあります。タイトルで期待していくと期待外れということがありますね。それはセミナが悪いのではなく、対象とするクラスが違ったということですね。

ファームウェアをやっている方はハードが必要だし、協調設計が必要でしょうが、アプリの方はハードは抽象化されていますから、ハードは関係ないですね。いまはアプリしかやったことない人が多いでしょうから、ファームを教えるときはアドレスマップから教える必要がありますね。


くりさん
別に、そのものずばりを教えてもらいたいのではなくて、仕様策定方法とか動作モデルのシミュレーションのやり方とかを聞きたかったんです。今作っているのは、当然ながら全体仕様書を作って、個別のモジュールの仕様書を作りながらやっているのですが、個別モジュールの細かい仕様書を作っていると、他のモジュールの仕様が把握できなくなってしまうんです。全部覚えきれないといいますか、そんな感じです。(戻りが多くなってしまいます) 全体として、レイテンシを最小に、スループットを最大にする必要があるので、レジスタ間のクリティカルパスを可能な限り動作周波数の周期に近づけるように配慮して作っています。他の方はどんな仕様書を書いて、うまくやっているのかな?と思いまして。。。レイテンシやスループットを犠牲にするのならば、汎用バスを用いたりして、あまり悩まずにできるとは思うのですが。。。まあ年のせいもあるとは思っています。もう少し若いころはもう少しましでしたし。。。
もしかすると、ソフトウェアのUMLなどの講座に通った方が良いかもしれませんね。仕様書も一部UMLのシーケンス図を使っています。

パンは美味しかったです。リトルマーメードはつくばにもありました。チェーン店だと思います。くりさんのお住まいの町にもあるのではないか?と思います。家では朝は奥さんの手作りパンです。出来が良いときと悪いときがあります。パン焼き機で作るのですが、夏は出来が悪いときが多いです。夏は氷を入れると出来が良くなります。それに、パンが焼けたらすぐに取り出さないと縮むんでしまうんですよ。それが面倒です。ご飯のように出来たらほっておけないんです。
  1. 2009/08/22(土) 05:42:08 |
  2. URL |
  3. marsee #f1oWVgn2
  4. [ 編集 ]

こんにちは。

>別に、そのものずばりを教えてもらいたいのではなくて、仕様策定方法とか動作モデルのシミュレーションのやり方とかを聞きたかったんです。

 うーん、それは、もっと難しい話と言いましょうか、個別の案件によって変わってくる話ですから。並みの案件に対しては、並みのやり方で良いでしょうが、特別な案件には、特別なやり方を持ち込むしかないかもしれませんから。

>個別モジュールの細かい仕様書を作っていると、他のモジュールの仕様が把握できなくなってしまうんです。全部覚えきれないといいますか

 あるモジュールの内部を作っているときに、どこまで別モジュールの内部事情を考慮しなければならないかは、悩ましい問題ですが、悩ましさを断ち切るには、各モジュールの独立性を高める=他のモジュールのハラワタを考慮しなくて済むようにする、ってことが一番でしょうね。で、モジュール間のインターフェイスは、統一的な仕様にして、各モジュールは、その外部に対して、インターフェイスの仕様に合わせることだけを考えれば良いと。ただし、その分、無駄が入り込みやすいですが。

>全体として、レイテンシを最小に、スループットを最大にする必要があるので、レジスタ間のクリティカルパスを可能な限り動作周波数の周期に近づけるように配慮して作っています。

 使うFPGAの性能と、クロスバー・スイッチの構造、通信路の本数、通信ノードの数、クロスバーの管理方法、など々、が絡む問題ですから、そう々、一筋縄では行かない問題だと思います。具体的な設計に入る前に、色々、テスト・ケースなどを作成して、見積もりを出す必要があると思います。で、最終的な期待性能は見積もりの6~7掛けくらいで^^)。最初に目標性能を決めちゃってから、設計に入ると苦しいです。

>レイテンシやスループットを犠牲にするのならば、汎用バスを用いたりして、あまり悩まずにできるとは思うのですが

 汎用バスでは、期待している性能は、まず無理です。ただし、クロスバー以外の方法も検討されるのは、色々アイデアを整理する上でも、有用かと思います。例えば、トークン・リングとか・・・。

>くりさんのお住まいの町にもあるのではないか?

 あるにはあるようですが、随分、辺鄙な場所に・・・^^;)。

>パン焼き機で作るのですが、夏は出来が悪いときが多いです。夏は氷を入れると出来が良くなります。

 イーストは生き物ですから、それなりに環境を整えてやらないと上手くいかないです。うちの女房は、発酵促進のために、電子レンジに放り込むという残酷なことをしますが^^;)。まあ、どうせ焼き○すんだから一緒か?

>ご飯のように出来たらほっておけないんです。

 いやー、ご飯だって適当な蒸らし時間を置いたら、パッとふたを開けて間髪を入れず、おしゃもじで返して、ほぐしてやらないと、縮んでふっくらとは行かないですよ~。私には、ふたを開けた瞬間、ご飯が縮んで行くのが見えます!って、FPGAとは全然関係のない薀蓄が・・・。
  1. 2009/08/22(土) 12:37:08 |
  2. URL |
  3. くり #mQop/nM.
  4. [ 編集 ]

くりさん、こんにちは。

>うーん、それは、もっと難しい話と言いましょうか、個別の案件によって変わってくる話ですから。
一般的な話で良いから聞いてみたいです。

>悩ましさを断ち切るには、各モジュールの独立性を高める=他のモジュールのハラワタを考慮しなくて済むようにする、ってことが一番でしょうね。
これはコマンドで駆動される(する)自立モジュールにすることで、独立性は高めているんですが(そうでないと頭が飽和してしまいます)、いろいろイレギュラーなバスとかがあって、ラッパーをかませているとレイテンシが上がりますし。。。ということで、あまり詳しくなるとまずいかもしれないので、この辺で。。。

>色々、テスト・ケースなどを作成して、見積もりを出す必要があると思います。
そうなんですよね。これはやりたいのですが、ほとんど1人でやっているので、なかなか手が回りません。

>最初に目標性能を決めちゃってから、設計に入ると苦しいです。
まったくもってそうなんですが、最初に性能が決まっているので、それに合わせてということになります。それもあって、家に帰ってからもブログに書きながらツールやデバイスの使い方を探っているわけです。もう一声というときに伝家の宝刀が抜けるかもしれませんし。。。(笑)(いろいろ脱線もしていますが。。。)

>汎用バスでは、期待している性能は、まず無理です。ただし、クロスバー以外の方法も検討されるのは、色々アイデアを整理する上でも、有用かと思います。
今使っているのは、FIFO付きの双方向バスなんですが、結構、通信の接続の制約があるのでクロスバーでも大して変わらないのでは?と考えています。トークン・リングだとスループットが落ちるので、たぶん2重ですね。

>ちの女房は、発酵促進のために、電子レンジに放り込むという残酷なことをしますが^^;)。まあ、どうせ焼き○すんだから一緒か?
これは、電子レンジの発酵モードをお使いなのではないでしょうか?37度くらいで発酵させるモードがあると思います。となると、パンも完全手作りですね。うちでも前はやっていましたが、今は完全に手抜きで機械任せです。私も実はバターロールを作ってみたことがあります。発酵させすぎで、少し臭くなってしまいました。

>いやー、ご飯だって適当な蒸らし時間を置いたら、パッとふたを開けて間髪を入れず、おしゃもじで返して、ほぐしてやらないと、縮んでふっくらとは行かないですよ~。私には、ふたを開けた瞬間、ご飯が縮んで行くのが見えます!って、
確かにそうですね。うちの奥さんの実家に行くと、ガス釜で炊いて、電子ジャーに移していました。ガスで炊いた方がおいしいそうです。うちでは手抜きで炊きっぱなしですけど。。。
  1. 2009/08/22(土) 18:40:11 |
  2. URL |
  3. marsee #f1oWVgn2
  4. [ 編集 ]

 こんばんは。

>今使っているのは、FIFO付きの双方向バスなんですが、結構、通信の接続の制約があるのでクロスバーでも大して変わらないのでは?と考えています。トークン・リングだとスループットが落ちるので、たぶん2重ですね。

 トークン・リングの利点は、各ノードが考えなければならない通信相手が、隣り合うノードのみであること、物理的にコリッジョンがないこと、トークンに通信相手を識別するデータを乗せるので、面倒なハンドシェイクを考えなくて済むこと、一つのリングに複数のトークンを同時に走らせることができること、など々ですね。まあ、「渋谷で降ろして下さい」て札、子どもの首にぶら下げて、山手線でやってきた満員でない電車に放り込むイメージです。欠点は、目的のノードに達するまで、固定された経路上のノードを通過しないとなりませんから、レーテンシが大きくなることです。まあ、FPGA内部であれば、内回りに外回り、中央線によるショートカットなど、色々線路を引くことができると思いますから、そこで経路制御して、ある程度レーテンシを小さくすることも可能とは思いますが。

>これは、電子レンジの発酵モードをお使いなのではないでしょうか?

 これです。電子レンジ発酵パン。

http://www.murakami-s.com/

こねません。混ぜるだけ。レンジで30秒程チン。発酵します。不思議です。イーストって、GHz帯の電磁波食べるんでしょうか^^?
  1. 2009/08/22(土) 21:41:18 |
  2. URL |
  3. くり #mQop/nM.
  4. [ 編集 ]

>トークン・リングの利点は、各ノードが考えなければならない通信相手が...
データパスは対向で2つ以上欲しいので、1つのトークンリングだと2倍のデータ幅が必要になります。2つにするとアービトレーションをする必要が出てきますね。クロスバーでのアービトレーションクロックサイクルとトークンリングの1回りのクロックサイクルがあまり違わなければトークンリングも良いかもしれませんね。大体クロスバーの部分は出来ています。いまさらトークンリングに変えられませんが、利点と欠点を考察してみたいと思います。ありがとうございました。

>これです。電子レンジ発酵パン。
凄い。30秒で発酵ですか?
アマゾンで45分で電子レンジパンという本を購入しました。やってみたいと思います。
  1. 2009/08/23(日) 05:24:15 |
  2. URL |
  3. marsee #f1oWVgn2
  4. [ 編集 ]

こんにちは。
 一つ二つ、書き忘れたんですが、

>まったくもってそうなんですが、最初に性能が決まっているので、

 性能を決めたのは、多分、上の人間ということでしょうが、こういうお話を聞くたびに、脊髄反射的に次のような話を思い出してしまいます。

http://www.belbel.or.jp/~takatsukasa/air/reppu.htm

まあ、飛行機の性能を上げるには、まずその動力であるエンジンの性能がまともでなければならないのに、公称の7掛け行ってたかどうか怪しくて、でも、それを言っても上の方は「出てるはずだ」と聞く耳持たなくて、さらに基本を理解せずに無謀な追加要求してきたりして・・・。
 この場合、性能を決定づけるのは、クロスバー・スイッチの性能ということになると思いますが、フル・カスタムでクロスバーを設計できるならいざ知らず、FPGAの構造を借りて実現ということですからねー。おのずと性能がそこでかなりの制約を受けてしまいます。他社製の出力詐称エンジンで「何とかしろ」と言われた堀越二郎に、状況が似ている気がしますが^^)。技術者たるもの、時として「そんなの無理!」と言う勇気も必要だと思いますよ。もちろん、堀越二郎にそんな勇気はありませんでしたが^^)。

>もしかすると、ソフトウェアのUMLなどの講座に通った方が良いかもしれませんね。仕様書も一部UMLのシーケンス図を使っています。

 もし、目的のハードウェアにUMLのシーケンス図が必要なほど、シーケンスが複雑であるならば、おそらくそれはスループットを最大限上げるといった本来の目的からは、誤った設計だと思います。複雑なシーケンスを実現するには、複雑なハードウェアが必要になってくるのが一般的ですから。
 複雑な事項を解決するのに、何か新しい方法がないかどうか模索するのは結構なことなんですが、見出した新しい手法が、何か直感的ではない複雑な手順を含んでるとすれば、その手法の何処かに、大幅な自動化の工程が含まれない限り、複雑さの解決にはなりません。平たく言うと「複雑さの解決に複雑さを持ち込むのは妥当か?」ということです。「UMLが複雑さを解決する手段になっているか」と聞かれたら、私は「現状ではNo」と思います。また、URLから自動生成、自動検証云々がない限りは、ただのポンチ図と同じです。
 これはハードウェアも同じで、何か複雑なハードウェアを持ち込めば、そこにある複雑さが、すべて明快に解決されるのであれば、持ち込むべきでしょうが、そのときには持ち込むハードウェアの複雑さは解決されている必要があります。
 我々、日本人は職人気質が強いというか、常に精緻なもの、複雑なものに目を奪われがちですが、アレクサンダー大王は「ゴルディオスの結び目」を、チマ々弄らずに、(これを解けばアジアの支配者になれる?→支配するためには武力が必要(悲しいことに、今でもこれは本質)だろう?→武力の象徴=この時代は剣→ということで)剣で一気にぶった切りましたが、同様な気概はハードウェア技術者が常に持つべきものだと思いますよ。「より単純なもの(本質)でぶった切れないか?」って。
  1. 2009/08/23(日) 16:54:06 |
  2. URL |
  3. くり #mQop/nM.
  4. [ 編集 ]

>技術者たるもの、時として「そんなの無理!」と言う勇気も必要だと思いますよ。もちろん、堀越二郎にそんな勇気はありませんでしたが^^)。
絶対無理だったら無理と言っていると思います。たぶんクロスバーがネックではなく、FPGA内部の通信プロトコルがうまく動くかどうかだと思っています。

>同様な気概はハードウェア技術者が常に持つべきものだと思いますよ。「より単純なもの(本質)でぶった切れないか?」って。
そうですね。一度考えたものを新たな視点でもう一度見つめなおしてみようと思います。いろいろなレイテンシを考えると、いろいろなデータパスが必要になるのですが、そうでない方法を考えるのもよいのではないかと思います。もっともUMLを導入しようというのもそのプロジェクト専業ではないからというのもあります。メインは別にありまして、合間にやっているという形です。年も行っていますし、前に決めた仕様を忘れてしまったりします。仕様書もページ数が多くなると、再起動するのにいちいち読んでいられません。図を見てすぐに思い出せれば良いなということです。
  1. 2009/08/23(日) 17:28:30 |
  2. URL |
  3. marsee #f1oWVgn2
  4. [ 編集 ]

コメントの投稿


管理者にだけ表示を許可する

トラックバック URL
https://marsee101.blog.fc2.com/tb.php/1209-698cbdec
この記事にトラックバックする(FC2ブログユーザー)