日記帳だ! with Tux on Libserver

二度目の大改造!! 日記帳…か?を継承し、より柔軟でパワフルなBlogに変身しました。

RSSに対応しています。リンク・コメント・トラックバックは自由にしていただいてほぼ問題ありません。
RSS購読方法、僕のリンク・コメント・トラックバックについての考えを読むことをおすすめします。

静的解析は考え物

プログラムでも論理回路でもそうだけど、ソースコードの静的解析を行って、

静的解析で出てきた指摘事項に対して対応するようにとなっている。

その指摘事項がバグにつながっている場合もあるけど、大半の指摘事項はバグではないのが実情だ。


今は論理回路の設計をしているので、HDLの記述に対する指摘を例に示す。
always @(posedge CLK) begin
  if(SET) begin
    CNT <= 8'd0;
  end
  if(INC) begin
    CNT <= CNT+1;
  end
end

これに対して2つの指摘があった。

1つ目は、1つのalways文の中に2つのif文があるということ。

2つ目は、非同期リセット信号は入っていないこと。


1つ目の指摘は、2つのif文が同時に成立した場合に問題になる。

SET==1 かつ INC==1 の場合、後ろのif文のCNT<=CNT+1 だけが有効で、前の CNT<=8’d0; は無視されるはず。

それが想定通りならよいのだが、普通はこういうのってこう書くよね。

if(SET) begin
  CNT <= 8'd0;
end
else if(INC) begin
  CNT <= CNT+1;
end

こうすると、複数の条件に当てはまるときの優先順位がわかりやすい。

この指摘に対応する中で、本当は SET==1 を優先させないといけなかったとか気づけたという場合もあるだろう。


2つ目の指摘は、通電時のリセットをやらなくて大丈夫? ということ。

通電時のフリップフロップの値は不定とされている。

そこで、通電時にリセット信号を入れて、フリップフロップの値を初期化するということがよく行われる。

このリセット信号は非同期リセットが使われることが通常だ。だから、非同期リセットがない=通電時にリセットしなくていいの という意味だと。

なるほど、確かに非同期リセットしないと、値が不定になって問題だと気づいて修正するとこうなる。

always @(posedge CLK or negedge RSTX) begin
  if(!RSTX) begin
    CNT <= 8'd0;
  end
  else begin
    if(SET) begin //以下略

確かにこれが問題となるケースもあるのだが、常に問題があるわけではない。

SET信号を入力→CNT信号を使う という順序が確立されていれば、通電時のリセットは必須ではない。


指摘事項にはいくつかのランクがあるが、「重要」とか「必須」とかなっているのは、必ず対応するようにというルールになっている。

でも、本当に「重要」とか「必須」の指摘事項って全部対応しないといけないの? とチームリーダーに聞くと、こういう返答だった。

  • 好ましい記述ではないので、バグではないと分かっていても、可能なら修正した方がよい
  • 修正できない・修正しにくい場合、問題ない理由を明確にすればそのままでもよい
  • 既存のソースコードについては、指摘事項が膨大にあるのが実情だが、そこはあえて修正する必要はないだろう

「重要」とか「必須」って言ってる割には、必ず修正するとは限らないんだよね。

特に既存のソースコードは、静的解析結果への対応が十分ではないこともある。

明らかにまずいソースコードもあるのだが、問題を引き起こさないことが明らかなら、あえて修正しないでよいだろうと。


本当にバグにつながる指摘事項というのはさほど多くないのだが、

静的解析がきっかけで、通常のテスト・デバッグでは気づかないような特殊な条件で発生するバグを見つけて直したことがある。

バグではなくても、記述がまずいので、修正しようとなるものはけっこうある。

ただ、これは修正しなくていいだろ、ってなるような指摘事項も少なくはないんだよね。

そういう指摘事項に対して、修正すべきか、理由を示して修正せずに終わらせるのか。

そこら辺の処理がめんどくさいんだよなぁ。静的解析が無意味ではないことは実感しているが、それに伴う手間がなかなか。


Author : Hidemaro
Date : 2018/01/25(Thu) 22:54
コンピュータ・インターネット | Comment | trackback (0)

Tools