パスワードを忘れた? アカウント作成
237398 journal

Qsの日記: CPU作るのは簡単だけど… 3

日記 by Qs

少し前にMieruPCなるものがストーリーに上がっていた。いつもながらに色々考えているとタイミング外してしまうのでこっちに書くことにする。

…ぐだぐだ書いたけど本当にぐだぐだなので消した。要点だけ残しておこう。

それって本当に「見える」の? どなたかのコメントに「バラのTTLで作っていたころはテスターで観測できていた」とあったけど、まさにその通りで、FPGAの中は全然「見えない」

実は教育用CPUやPCで本当に必要なものはそれ自体ではなくて、オンチップのロジアナなんじゃないかと思っている。例えば、コマンドで"ls"を入力したらダイナミックな命令実行のログ、それもパイプラインの動作ロジック波形まで見えるようなレベルのログである。

世にあるPCの後を普通に追っかけても、最初は興味が続くかもしれないけどいずれ飽きる。それが「教育用PC」の役目が終了するところかもしれない。でもその先に進みたい人は何をするだろうか。オレもよくわからんが、もっとシステムの動作を知りたい、さらに独自のCPUなりシステムに拡張したいと思ったならば、必要なのは観測手段なんだよな。

シミュレーションで追いかけられるのは実時間に直すとわずかなものでしかない。でも、バグってのは一時間動かして出たりでなかったり、実際にシステムにしないと出ないものだってあるだろう。

それを見つける手段があったなら、興味が薄れるまでの時間、心が折れるまでの時間をずいぶん稼ぐことができるはずだ。

実際FPGA開発案件で一番苦労するのは実動作デバッグなんだよなぁ。アナログ相手の通信システムだから、ノイズはもちろん信号の位相など入力がいつも異なる中、意図しない動作がでると大変。

まぁ、そのための観測ツールなんてのも内製しているんだけどね。これがかなり役に立つ。

追記:
「だから無意味だ」とか「ばかなことを」といった意図はまったく無い。起業するその熱意には大いに敬意を表している。そしてもっと発展して欲しいと思っている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • >シミュレーションで追いかけられるのは実時間に直すとわずかなものでしかない。でも、バグってのは一時
    >間動かして出たりでなかったり、実際にシステムにしないと出ないものだってあるだろう。

    >それを見つける手段があったなら、興味が薄れるまでの時間、心が折れるまでの時間をずいぶん稼ぐことが
    >できるはずだ。

    カバレッジの観測とかしないんですか?
    勿論カバレッジでバグが見つかるわけでも、コードカバレッジが品質に直結しているというつもりはないのですが。

    最近は、異常動作のパターンを入れるとRTL上でどこが間違っているか教えてくれるツールもあるみたいです。
    http://www.vennsa.com/index.html
    たぶん、その他の条件 - 全部のRAM, FF の値とか、複数のclock があればその前数サイクルの正確な位相関係とか
    、入力データのパターンとか、- を入力するのが大変なんじゃないかと思います。何も制約を与えないと間違って
    いる候補を大量に示されて調べることができない。制約が間違っていると、長時間考えた後で、「そのような異常
    状態にはならない」という..
    • by Qs (1185) on 2010年07月14日 23時14分 (#1795359) 日記
      カバレッジはそれを解析するためのデータ量が多すぎて実動作で
      それを行うのは難しくないですか?

      どうやったら実動作でカバレッジを観測できるのか、実装というか
      アルゴリズムというか方針すら思いつかないです。

      OnPoint、なんだか威勢のよいツールですね。まずはsynopsysやcadenceに
      買収されることからでしょうか。
      親コメント
      • Cのプログラムの実行時トレースとかもできるので、理論的には、FPGAでもできそうですけどね。
          特定行が実行されたかチェックするだけなら、各行か各ブロックで、CoverTrace[__LNE__] <= 1'b1 ;
        っぽいことをやればいいと思います。アドレスの競合が強く起こるので、memoryに書き込むのは
        無理ですが。読み出すのはscan っぽく。
         always @(posedge clk) begin
                    if ( debugscan )
                            coverreg_blk0 <= 1'b1 ;
                    else
                            coverreg_blk0 <= coverreg_blk1 ;
          1つのalways で1つの変数にしか代入しないスタイル対応、assign にはどうするかとか、
        シーケンシャルに読み出されたbit列とソースコードを対応づけて、それからやっとdebugに入るの
        面倒すぎとか問題は多いです。

        でも、そうじゃなく、「問題が見つかる前に、RTLsimを止めたのはなぜか。coverageを観測することで、
        simが充分に行われたかどうか判断できないのか。もしできないのならば、それはなぜなのか?」とい
        うことをお尋ねしたかったのです。あくまでRTLレベルで。

         
        親コメント
typodupeerror

アレゲは一日にしてならず -- アレゲ見習い

読み込み中...