現場の仕事がバリバリ進むソフトウェアテスト手法

現場の仕事がバリバリ進むソフトウェアテスト手法

私はソフト屋でもテスト屋でもありませんが
あまり堅苦しくないので読み流すにはいいかなと。

テスト管理者向けの本ですね。

でも、開発側の人がテスト側の仕事を知るにも
ちょうどいいくらいの本だと思います。

ところどころに出てくる「開発者はドキュメントを書かない」は痛いところ。
開発者も品質のことを考えないとね。

著者はMicrosoftに勤めていた経験があるそうでその話も良く出てきます。
Microsoftでそうだったんなら、そうなんだろうなぁ。

最後にはテスト担当者を採用する際の面接などについても書かれています。

他でも読んだことがありますが、Microsoftの面接で

「富士山をどうやって動かしますか？」

って聞かれるのは本当なんですかね。
有名な話みたいですが。

なぜ富士山が選ばれたか？ということのほうが気になるけど。

有限狀態機的都會傳奇

タイトルが中国語なのは気まぐれです。
一応、『ステートマシンの都市伝説』と書いたつもりですがあってるかな？

さて、ステートマシンのエンコーディング方法について
それぞれ長所短所があって云々などといったことを
読んだり聞いたりしたことがあると思います。

実際のところどうなんでしょう？

FPGAをターゲットとして、ISEでちょっと実験してみました。

まずテストのコードはこれ。

module StateTestA (/*AUTOARG*/
// Outputs
DAT_O,
// Inputs
CLK_I, RST_I, DAT_I
);

input CLK_I;
input RST_I;

input [7:0] DAT_I;
output [7:0] DAT_O;

reg [7:0] DAT_O;

parameter [3:0]
STATE_A = 4'hA,
STATE_B = 4'hB,
STATE_C = 4'hC,
STATE_D = 4'hD,
STATE_E = 4'hE,
STATE_F = 4'hF;

reg [3:0] state_r;
reg [3:0] nxState;

reg [7:0] dataOut;

always @(posedge CLK_I or posedge RST_I) begin
if (RST_I)
state_r <= STATE_A;
else
state_r <= nxState;
end

always @* begin
nxState = state_r;
dataOut = 8'h00;
case (state_r)

STATE_A: begin
dataOut = 8'h00;
if (DAT_I==8'h03)
nxState = STATE_B;
end

STATE_B: begin
dataOut = 8'h05;
if (DAT_I==8'h0F)
nxState = STATE_C;
end

STATE_C: begin
dataOut = 8'h0A;
if (DAT_I==8'h3F)
nxState = STATE_D;
end

STATE_D: begin
dataOut = 8'h50;
if (DAT_I==8'hFF)
nxState = STATE_E;
end

STATE_E: begin
dataOut = 8'hA0;
if (DAT_I==8'hFC)
nxState = STATE_F;
end

STATE_F: begin
dataOut = 8'hFF;
if (DAT_I==8'hF0)
nxState = STATE_A;
end

default:; // No recovery

endcase
end

always @(posedge CLK_I)
DAT_O <= dataOut;

endmodule



６つのステートを作り、それをぐるっと１周させる単純なものです。
ステートのエンコーディングは適当。

まずは合成のプロパティの HDL Options で FSM Encoding Algorithm を One-Hot に設定。



合成結果のステートマシンの部分を View RTL Schematic で確認するとこんな感じ。



細かいところは見えないと思いますが、FFがステート数分の6つできていることは確認できると思います。

続いて、設定を Gray に変更してみると次のように変わりました。



こちらはFFの数は３つです。
回路の印象もずいぶん違うように見えます。

では次に、合成のレポートを見てみましょう。
主要な部分のみ抜粋します。

まずはワンホット。


[One-hot]

Optimizing FSM on signal with one-hot encoding.
-------------------
State | Encoding
-------------------
1010 | 000001
1011 | 000010
1100 | 000100
1101 | 001000
1110 | 010000
1111 | 100000
-------------------

Device utilization summary:
---------------------------

Selected Device : 3s500efg320-5

Number of Slices: 11 out of 4656 0%
Number of Slice Flip Flops: 10 out of 9312 0%
Number of 4 input LUTs: 21 out of 9312 0%
Number of IOs: 18
Number of bonded IOBs: 18 out of 232 7%
Number of GCLKs: 1 out of 24 4%

Timing Summary:
---------------
Speed Grade: -5

Minimum period: 3.012ns (Maximum Frequency: 331.956MHz)
Minimum input arrival time before clock: 6.108ns
Maximum output required time after clock: 4.063ns
Maximum combinational path delay: No path found



続いてグレイコード。


[Gray]

Optimizing FSM on signal with gray encoding.
-------------------
State | Encoding
-------------------
1010 | 000
1011 | 001
1100 | 011
1101 | 010
1110 | 110
1111 | 111
-------------------

Device utilization summary:
---------------------------

Selected Device : 3s500efg320-5

Number of Slices: 12 out of 4656 0%
Number of Slice Flip Flops: 7 out of 9312 0%
Number of 4 input LUTs: 21 out of 9312 0%
Number of IOs: 18
Number of bonded IOBs: 18 out of 232 7%
Number of GCLKs: 1 out of 24 4%

Timing Summary:
---------------
Speed Grade: -5

Minimum period: 3.078ns (Maximum Frequency: 324.839MHz)
Minimum input arrival time before clock: 6.843ns
Maximum output required time after clock: 4.063ns
Maximum combinational path delay: No path found



どうですか？
あなたのイメージと一致しているでしょうか？

ちなみにVHDLで似たようなことをやっているものを見つけたので紹介しておきます。
State machine encoding (Gray, Binary and One-hot)

他もいくつか試してみましたのでその結果も載せておきます。

ユーザーエンコードそのまま。


[User]

Optimizing FSM on signal with user encoding.
-------------------
State | Encoding
-------------------
1010 | 1010
1011 | 1011
1100 | 1100
1101 | 1101
1110 | 1110
1111 | 1111
-------------------

Device utilization summary:
---------------------------

Selected Device : 3s500efg320-5

Number of Slices: 16 out of 4656 0%
Number of Slice Flip Flops: 7 out of 9312 0%
Number of 4 input LUTs: 29 out of 9312 0%
Number of IOs: 18
Number of bonded IOBs: 18 out of 232 7%
Number of GCLKs: 1 out of 24 4%

Timing Summary:
---------------
Speed Grade: -5

Minimum period: 3.904ns (Maximum Frequency: 256.144MHz)
Minimum input arrival time before clock: 6.834ns
Maximum output required time after clock: 4.063ns
Maximum combinational path delay: No path found



ジョンソン。


[Johnson]

Optimizing FSM on signal with johnson encoding.
-------------------
State | Encoding
-------------------
1010 | 000
1011 | 001
1100 | 011
1101 | 111
1110 | 110
1111 | 100
-------------------

Device utilization summary:
---------------------------

Selected Device : 3s500efg320-5

Number of Slices: 11 out of 4656 0%
Number of Slice Flip Flops: 7 out of 9312 0%
Number of 4 input LUTs: 21 out of 9312 0%
Number of IOs: 18
Number of bonded IOBs: 18 out of 232 7%
Number of GCLKs: 1 out of 24 4%

Timing Summary:
---------------
Speed Grade: -5

Minimum period: 3.012ns (Maximum Frequency: 331.956MHz)
Minimum input arrival time before clock: 6.467ns
Maximum output required time after clock: 4.063ns
Maximum combinational path delay: No path found



オート。


[Auto]

Optimizing FSM on signal with sequential encoding.
-------------------
State | Encoding
-------------------
1010 | 000
1011 | 001
1100 | 010
1101 | 011
1110 | 100
1111 | 101
-------------------

Device utilization summary:
---------------------------

Selected Device : 3s500efg320-5

Number of Slices: 13 out of 4656 0%
Number of Slice Flip Flops: 7 out of 9312 0%
Number of 4 input LUTs: 24 out of 9312 0%
Number of IOs: 18
Number of bonded IOBs: 18 out of 232 7%
Number of GCLKs: 1 out of 24 4%

Timing Summary:
---------------
Speed Grade: -5

Minimum period: 4.038ns (Maximum Frequency: 247.620MHz)
Minimum input arrival time before clock: 6.441ns
Maximum output required time after clock: 4.063ns
Maximum combinational path delay: No path found



適当（いい加減）なエンコーディングをしているので
ユーザーエンコーディングそのままのものが結果が悪いのは予想がつきますが
なぜかAutoの場合もそれほど良くないですね。

Autoではバイナリエンコーディングされているようですが
FPGAの場合、グレイとバイナリではそれほど変わらないと思っていたのですが意外でした。

まあでも、この結果は今回たまたまで、他のオプションを変えたりもっと複雑なステート遷移のものだとまた違った結果が得られるかもしれません。

この結果が大きいと
感じるか感じないかはあなた次第です。

verilog-modeでenum

Verification Engineerの戯言から

enumを使えば、、

SystemVerilogやVHDLならば列挙型が使えるので、
シミュレーション結果を波形で見るときASCIIで見れて便利だねというお話。

残念ながら普通のVerilogだと列挙型は使えない。

そこで、verilog-modeの/*AUTOASCIIENUM*/を使うという方法があります。
↓こんな感じ。

//== State enumeration
parameter [1:0] // synopsys enum state_info
ST_DoorClose = 2'b00,
ST_Opening = 2'b01,
ST_DoorOpen = 2'b10,
ST_Closing = 2'b11;
//== State variables
reg [1:0] /* synopsys enum state_info */
state; /* synopsys state_vector state_r */
//== ASCII state decoding
/*AUTOASCIIENUM("state", "_state__ascii", "ST_")*/


ここまで書いておいて、C-c C-aとタイプすると次の記述が自動で追加されます。

// Beginning of automatic ASCII enum decoding
reg [71:0] _state__ascii; // Decode of state
always @(state) begin
case ({state})
ST_DoorClose: _state__ascii = "doorclose";
ST_Opening: _state__ascii = "opening ";
ST_DoorOpen: _state__ascii = "dooropen ";
ST_Closing: _state__ascii = "closing ";
default: _state__ascii = "%Error ";
endcase
end
// End of automatics


こうしておくと、シミュレーション時の波形確認の際にステートをASCIIで見ることができます。
結果はこのとおり。


ステート表示に使う変数は回路で使用されるわけではないのでそのままでも問題はないと思いますが、論理合成ツールの警告が気になる場合は`ifdefなどでシミュレーション時のみ記述が有効となるようにすればよいでしょう。

詳しい使い方は↓こちらを参照してください。
Verilog-Mode: Reducing the Veri-Tedium
2.10 State Machines

code*

ブログにソースコードを貼り付けるのに苦労していたのですが
↓次のサイトを利用させていただくことで便利な方法が見つかりました。

code*（コードなにがし）

こちらにコードを登録することで履歴管理や（反応してもらえれば）フィードバックを受けれます。

さらに↓こちらで提供されている『コードなにがしガジェット』使えば

コードなにがしがなにげに便利かも

このようにソースコードをブログに組み込めちゃう！



ちょっと感動しちゃいました。

ちなみにコードの色分けは google-code-prettify というものを使われているようで
これ自体はverilogに対応しているわけではないのですが、
verilogがCの文法に近いのである程度色分けをしてくれているみたいです。

便利なツールどうもありがとうございます。

秋の夜長に

もう９月ですね。

年をとるごとに時が経つのがはやくなるというのはどうやら本当のよう。

さて、今回はゲームの紹介。

ニンテンドウDSのソフト

レイトン教授と不思議な町

最近やってみたのですが結構はまってました。

いくつか意地悪な問題もありますが、基本的には論理パズルがメインです。

「天秤とコイン」や「川渡りのパズル」、「Nクイーン問題」などの有名なものもあって
結構、論理的思考のトレーニングになります。

多分、脳トレよりも効く。

こういうのって、デバッグしているときの思考に似ていると思うのは私だけでしょうか？
可能性を１つづつ潰していって、最後に目標にたどり着くみたいな。

あと特筆すべきは、低解像度の画面なのにそれを感じさせないこと。
調べてみるとDSって１画面192×256ピクセルなんですね。
携帯よりも解像度が低いとは知らなかった。

自分なんか解像度が低いことを簡単に言い訳にしてしまいそうですが
ゲーム業界で画面を作ってる人たちってスゴイですね。

既に次回作の発売も決定しているようです。

仕事で行き詰ってるときに
こういうので気分転換してみるといいかも。

Applied Hardware Verification

Applied Hardware Verification

オレゴン健康科学大学（？）の講義のシラバスのようです。

まだ細かいところは読んでいませんが、
表題のとおり実用的なハードウェア検証の講義。

講義のスライドがPDFで閲覧可能で
これを読むだけでも結構勉強になりそう。

もちろん英語ですけど。

PSLなんかについても書いてありますね。

私は学生時代は物理をやっていたので日本の大学の
情報系の講義がどんなものかは知らないのですが
最近はこういう内容をやっているんですかね？

少なくとも日本語のサイトでこれほど丁寧な資料はお目にかかったことはありません。

ネットが普及するにつれて英語の苦手な日本のエンジニアは
どんどんおいてきぼりを食ってしまうような気がする。

それとも自分が勝手にそう思っているだけなのかなぁ。
ウェブで見かけるエンジニアの方々は普通に英語使ってそうだし。

某S社の人と話したときは「この規格は英語版のものしか読んでない」という人もいたし
その関連会社の別の人は逆に「英語の資料はほとんど読んだ事がない」という人もいたし。

この業界の英語力ってどんなもんなんだろう？

私はというと、やっぱり日本語のほうが楽です。