非同期信号を扱うための危ういVerilogライブラリ のバックアップソース(No.7)
更新- バックアップ一覧
- 差分 を表示
- 現在との差分 を表示
- バックアップ を表示
- 電気回路/HDL/非同期信号を扱うための危ういVerilogライブラリ へ行く。
[[公開メモ]] #contents * ご注意 [#f663e998] &color(red,white){&size(25){※ 以下は練習のために書いてみた回路です。};};~ &color(red,white){&size(15){しっかりしたテストを経ていないので、鵜呑みにしないで下さい。};};~ &color(red,white){&size(15){あまり役に立たない個人的なメモになってしまっていてすみません。};}; * クロックに同期していない信号を扱う際の注意点 [#t82a0ca1] デジタル回路設計で、クロックに同期していない信号を扱う必要があるときには、 十分な注意を払わないと、予想しない結果が生じて慌てることになります(なるそうです・・・)。 では何に注意すればよいかというと、 - メタステーブル状態の伝搬を考慮する です。 ** メタステーブル状態 [#s241da25] メタステーブル状態とは、簡単に言うと あるラッチあるいはフリップフロップ(FF)の出力が1つの値に定まらず、 ふらついている状況を表す言葉です。 どうしてそんなことが起きるのか。 ** セットアップ時間とホールド時間 [#be2ee529] 例えばDフリップフロップ(D−FF)は、 クロックの立ち上がりエッジ(あるいは立ち下がりエッジ)に 同期して入力信号を読み取り、次のエッジが来るまでその値を保持します。 理想的には、エッジの「直前の一瞬」の値を読み取って、 エッジの「直後」から正しい値を出力するのですが・・・。 実際のFFは「一瞬」で値を読み取れるわけではないため、 エッジの前後の短い時間の間に入力信号が変化してしまうと、 正しい値を読み取れず、出力が不定になってしまいます。 そこで、FFを正しく使うためにはクロックエッジ前後のある一定期間に 入力信号が変化しないよう回路を組みます。 FFは、その一定期間に入力信号が変化しないときに限って動作が保証されています。 FFが正しく動作するために、~ クロックエッジの「直前」に設けられた入力信号の変化禁止時間を最小セットアップ時間、~ クロックエッジの「直後」に設けられた入力信号の変化禁止時間を最小ホールド時間、~ とそれぞれ呼びます。 入力信号がこれらの最小値よりも大きなセットアップ・ホールド時間を持つときにのみ FFが正しく動作する、と言い換えてもOKです。 ** FFに同期信号が入力される場合 [#sf4b3381] 下図で説明します。 &attachref(metastable.png); 上段部分はFFに入力されるクロック信号です。 中段はクロックの立ち上がりで動作する D−FF に、 クロックに同期した信号 (sync) が入力される状況を表しています。 入力信号はクロックの立ち上がりに同期して直前のラッチから出力されますが、 いくつかのゲートや配線を通るため、無視できない量の遅延時間の後にFFの入力に到達します。 この遅延時間は、信号経路に含まれる(複数の)ゲートを通過するのに掛かる時間と、 それらを繋ぐ配線を通過するのに掛かる時間の和になります。 クロック周期から遅延時間を引き算したものがセットアップ時間になります。 回路が複雑になり、あるいは信号経路が長くなりすぎて、遅延時間が大きくなると、 直後のFFのセットアップ時間が短くなり、もし最小セットアップ時間を下回ると、 素子の動作がおかしくなります。 一方でホールド時間については、入力が同期信号で限り通常あまり考慮する必要はありません。 というのも、ラッチの出力はクロックエッジと同時に変化する訳では無く、 内部に有限のゲート遅延を持つためです。FFに規定される最小ホールド時間は非常に短いため、 大抵FFの出力遅延だけでホールド時間の制約を満たしてしまいます。 ** FFに非同期信号が入力される場合 [#q3209427] 上図の下段はクロックに同期しない信号が入力される場合です。 この場合、入力信号はクロックタイミングとは無関係に変化します。 したがって、最小セットアップ時間あるいは最小ホールド時間の規定に違反して、 クロックエッジ付近で値が変化する状況が起きてしまいます。 セットアップ時間やホールド時間が守られず、エッジ付近で入力信号が変化すると、 FFが不安定な状況に陥り、出力信号の値が比較的長い時間(数 ns 程度)に渡り、 ばたばたと振動してしまうことがあります。 図では黄色の矢印の時刻にセットアップ時間の違反が起きており、 そのせいで次クロックの出力値が長い間発信しています。 この振動は数 ns の時間を掛けて徐々に 0 に収まっていきます。 このように出力信号がふらついている間に別のラッチがこの信号を読もうとすると、 その結果が1と読まれるか0と読まれるか定まらないことになります。 この状態が、悪名高い(?)メタステーブル状態です。 ** メタステーブル状態の引き起こす問題 [#bbd694d2] 一見すると、 「そもそも0と1とを切り替わる最中に値を読んだのだから、 結果としてどちらに解釈されたって大きな差は無いじゃん」 という結論になってしまいそうな所です。 しかし、実際にはメタステーブル状態は2つの意味で問題を引き起こします。 - 後段に複数のFFがあると、それぞれが異なる値となる場合がある - 後段のFFにもメタステーブル状態が伝播する場合がある *** 後段に複数のFFがある場合 [#q947c6df] &attachref(selector.png); 例えばこの回路は、外部からの入力を1段のFFで受けて、 その出力で4ビットのレジスタAとBのどちらの値を出力するかを選ぶものです。 外部からの入力が非同期の場合、初段のFFでメタステーブル状態が発生する可能性があります。 初段FFがメタステーブル状態になると、4つのセレクタは同じ素子に繋がれているにもかかわらず、 配線遅延の微小な差違により、入力を1と読むものと0と読むものの両方が出現する可能性があります。 すると出力はAでもBでもなく、ビット単位でAとBとを混ぜ合わせた値となってしまいます。 この例から分かるように、下流に繋がれた複数の素子が繋がれた場合、 本来一斉に入力値が変化することを期待して設計された素子に それぞれ別の値が入力されたかのように振る舞い、 論理が破綻してしまう危険性があります。 *** 後段のFFにメタステーブル状態が伝播する [#d9952f33] メタステーブル状態になりうるFFに1つの素子しか繋がっていなければ、 前項のような問題は起きません。しかし、次のFFまでの遅延が大きいとき、 後段のFFにまでメタステーブル状態が伝播する危険性があります。 あるFFがメタステーブル状態になったとしても、 その状態は比較的速やかに1か0の値に収束し、定常状態に戻ります。 しかし後段のFFから見ると、実際にメタステーブル状態が治まってから、 さらに経路の遅延時間が経過しないと入力が定まらないため、 結果として最小ホールド時間違反が置き、 メタステーブル状態が伝播してしまう可能性が生じるのです。 * 非同期信号をFFで受ける [#te90b3d6] 上記のような問題を克服するには定石があって、 非同期信号を入力するときはFFを2つ繋いでおけばよいそうです。 &attachref(double-ff.png); LANG:verilog module double_ff( (* IOB="FALSE", TIG="TRUE" *) input idata, input oclk, output odata ); (* IOB="FALSE", RLOC="X0Y0", ASYNC_REG="TRUE" *) reg temp1; (* IOB="FALSE", RLOC="X0Y0" *) reg temp2; always @(posedge oclk) begin temp1 <= idata; temp2 <= temp1; end assign odata = temp2; endmodule 図にもあるように、1つ目のFFでメタステーブルが発生することはどうやっても防げませんが、 2つ目のFFを繋ぐ信号線を十分に短く、遅延時間を少なくしておけば、 2つ目のFFのセットアップ時間までにはメタステーブル状態が治まり、 入力値が定まっていることが期待できます。 この2段FFの形は非同期信号を受け渡す時の定石として様々な回路に現れます。 ** 注意点 [#pedba739] 忘れてはいけないのは、2つのFF間の配線が長い場合、 この回路はメタステーブルを取り除く役には立たないという点です。 遅延時間が長ければ、1つ目のFFのメタステーブルが2つ目に伝播して、 2つ目もメタステーブルになってしまう可能性が高くなります。 「2重FF回路では、2つのFFを可能な限り近くに配置する」 を鉄則として覚えておかなければなりませんん。 このために入れてあるのが、上記コードの IOB 制約と RLOC 制約です。 2つのFFが必ず同じスライスに入るように設定しています。 ISE の Language Templates にあるコードでは RLOC の代わりに HBLKNM で配置制約を掛けようとしているのですが、実際にやってみると WARNING:ConstraintSystem:119 が出てうまく行きません。 http://japan.xilinx.com/support/answers/34088.htm によれば、 「HBLKNM をネットに設定すると、パッドにしか伝搬されません」 とのことなので、ここでは HBLKNM ではなく RLOC で指定しています。 ASYNC_REG は、シミュレーション方法を規定するための制約です。 通常、シミュレーション中にセットアップ・ホールド時間違反が起きた場合、 FFの出力は不定値 X になります。その結果、多くの場合に下流の回路は X だらけとなり、以降のシミュレーションができなくなってしまいます。 ASYNC_REG が付いていると、セットアップ・ホールド時間違反が起きた場合、 書き込み前の値が保持されるため、シミュレーションに支障をきたしません。 (ただし、セットアップ・ホールド時間違反が起きたこと自体に対する警告は ASYNC_REG のあるなしにかかわらずログに残るようです) ** 重要な指針 [#cd725725] これまでの考察で、以下の重要な指針を得ました。 + 非同期信号をそのまま使うな + 非同期信号を1段FFに通しただけの信号は後段のつなぎ方に気をつけろ -- 複数のラッチを繋ぐような使い方はNG -- 1つだけFFを繋ぐなら問題ない -- 1つだけFFを繋ぐときも遅延が長いとNG + 非同期信号を2段FFに通せば十分安定 ** 複数の信号を一度に入力する場合 [#jaf5ebfe] 上記回路を次のように複数信号に拡張しても良いことはありません。 LANG:verilog module double_ff #( // この回路はバグの元 parameter DATA_BITS = 8 ) ( input clk, input [DATA_BITS-1:0] idata, output [DATA_BITS-1:0] reg odata ); reg [DATA_BITS-1:0] temp; always @(clk) begin temp <= idata; odata <= temp; end endmodule 外部からの信号が最小セットアップ・ホールド時間に違反するタイミングで切り替わると、 個々のビットがそれぞれ少しだけ異なるタイミングで読まれるため、 全体として意味のある値を読み取ることができないのです。 このように複数の信号線を一括して受け渡すために、次の回路があります。 * 異なるクロック間で複数の信号線を受け渡す [#m28494e7] 異なるクロック間で複数の信号線を受け渡すには、 ハンドシェイクと呼ばれる手法を用います。 方針は「値を読み取る間だけ書き込みをストップしておく」 という単純な話なのですが、「いつ書き込んで、いつ書き込みを止めるか」 をうまく制御するための機構が「ハンドシェーク」と呼ばれる 手旗信号のようなやりとりです。 最も基本的な手順は以下の通りです。 + 出力側で送信要求 (req) を挙げる + 入力側は req を2段FFで受取る + 入力側は req に従い temp の値を更新する + 入力側で送信応答 (ack) を挙げる + 出力側は ack を2段FFで受取る + 出力側は ack を見て temp から値を読み取る + 出力側は req を下ろす(読み取り終了通知となる) + 入力側は req を2段FFで受取る + 入力側は req が下りたら ack を下ろす(次に備える) + 出力側は ack を2段FFで受取る + 出力側は ack が下りたら 1. へ戻る 実際の回路は、7. 以降の req や ack を下ろすところでもう1つデータを送受信するため、 単純なハンドシェークに比べてデータ更新の頻度が2倍に上がっています。 ** 動作タイミング図 [#oece2ebd] &attachref(synchronize.png,,50%); - req -> req1 -> req2 の2段FFは req2 が確定信号なので、これを元に temp を更新する - temp 更新と同じタイミングで ack を立てる - ack -> ack1 -> ack2 の2段FFは ack2 が確定信号なので、これを元に odata を更新する - odata 更新と同じタイミングで req を下げる - req -> req1 -> req2 の2段FFは req2 が確定信号なので、これを元に temp を更新する - temp 更新と同じタイミングで ack を下げる - ack -> ack1 -> ack2 の2段FFは ack2 が確定信号なので、これを元に odata を更新する - odata 更新と同じタイミングで req を上げる の繰り返しです。 iclk の3周期と oclk の3周期を足した程度の頻度に一回、 入力側から出力側へ値が渡されます。 ** Verilog コード [#m77b9d4a] インスタンシエーション時にパラメータでバス幅を変えられるので、 いろんな用途に使えると思います。 LANG:verilog module synchronize #( parameter DATA_BITS = 8 ) ( input rst, input iclk, (* TIG="TRUE" *) input [DATA_BITS-1:0] idata, input oclk, output reg [DATA_BITS-1:0] odata ); (* TIG="TRUE" *) reg [DATA_BITS-1:0] temp; reg req; reg ack; wire oclk_ack; double_ff ack_ff ( .idata(ack), .oclk(oclk), .odata(oclk_ack) ); always @(posedge oclk) if (rst) begin req <= 1; end else begin if ( req == oclk_ack ) begin req <= !req; odata <= temp; // interclock signal "temp" end end wire iclk_req; double_ff req_ff ( .idata(req), .oclk(iclk), .odata(iclk_req) ); always @(posedge iclk) if (rst) begin ack <= 0; end else begin if ( ack != iclk_req ) begin ack <= !ack; temp <= idata; end end endmodule * トリガ信号の伝達 [#hb75dbc2] クロックを越えて、トリガ信号を確実に伝えるためのモジュールです。 itrig に iclk に同期した正論理のトリガが入ると、~ otrig に oclk に同期した1クロック幅のトリガを生じます。 クロックドメイン境界の向こう側にあるステートマシンを起動する用途に使います。 ** 動作タイミング図 [#xfaa5dec] &attachref(interclock_trig.png); やりたいことの単純さから考えると、かなり重たい動作になってます。 もっと手軽な方法がありそうな予感・・・ ** Verilog コード [#ra58aed2] LANG:verilog module interclock_trig( input iclk, input itrig, input oclk, output otrig ); (* RLOC="X0Y0" *) reg itrig_ex; (* TIG="TRUE" *) wire itrig_ex2; double_ff req_ff ( .idata(itrig_ex), .oclk(oclk), .odata(itrig_ex2) ); (* RLOC="X0Y0", ASYNC_REG="TRUE" *) reg itrig_ex3; always @(posedge iclk) itrig_ex3 <= itrig_ex2; always @(posedge iclk) if (itrig) itrig_ex <= 1; else if(itrig_ex3) itrig_ex <= 0; reg otrig1, otrig2; always @(posedge oclk) begin otrig1 <= itrig_ex2; otrig2 <= itrig_ex2 & !otrig1; end assign otrig = otrig2; endmodule itrig_ex2 -> itrig_ex3 -> itrig_ex も2段FFの役割を果たしているので、 制約を加えて itrig_ex3 と itrig_ex とが近くに配置されるようにしています。 A -> B -> C の2段FFでは、A に TIG、B と C とに配置制約、 と覚えてしまうのが良さそうですね。 ** 気になるところ [#u890f727] ただ気になるのは、上記のように itrig_ex2 に TIG を付けてしまうと、 itrig_ex2 -> itrig_ex3 だけでなく、itrig_ex2 -> otrig1 や、 itrig_ex2 -> otrig2 のパスも遅延時間解析が無視されてしまいます。 どうにかして itrig_ex2 -> itrig_ex3 のパスのみに TIG を付けたいのですが、 やり方が分からず困っています。。。 * クロックを越えてステートマシンを起動し、終了も検知 [#q32f132f] 1つ上の方法でトリガ信号を送ることができますが、 そのトリガで開始したタスクが終了したことも分かるようにしたいです。 ** 動作タイミング図 [#yb0eea15] &attachref(interclock_execute.png); のようにして、制御側への busy 信号は busy0 と busy5 との論理和で与えれば・・・ と、考えていたのですが、interclock_trig を2個使っちゃえば楽ですね。 ** Verilog コード [#v23f60b7] ということで、start 信号の伝達と、done 信号の伝達とに、 それぞれ interclock_trig を使えばいいので、コードは無しです。 * 非同期 FIFO [#b9208ec0] 2つのクロックドメイン間で連続するデータを次々と受け渡すのに使います。 通常の同期 FIFO と同様にリングバッファのようなものを作るのですが、 Full や Empty 信号を生成するのに書き込み・読み出しカウンタを クロックドメイン間で受け渡す必要があり、その部分の実装が大変だとのことです。 http://marsee101.blog19.fc2.com/?no=1085 で marsee さんが書かれているのと (恐らく)ほぼ同じ方針で作りました。 すなわち、 - 通常の書き込み・読み出しはバイナリカウンタを使う - クロックドメイン間でのカウンタの受け渡しのためにカウンタのグレイコード表現も持っておく - グレイコード表現を2段FFで受け渡す - グレイコード表現をバイナリ表現に戻す - もう一方のカウンタと比較することで、empty / full 信号を生成する という具合です。 グレイコードとバイナリコードの相互変換アルゴリズムは:~ http://blog.livedoor.jp/k_yon/archives/51619205.html ~ を参考にさせていただきました。 ** Verilog コード [#eb7fa693] カウンタ比較をバイナリで行っているので、almost full や almost empty なども簡単に追加できます。 full / empty の出力はFFから直なので遅延が小さくなっています。~ 代わりに we や re へのセットアップ時間が多少きつめかもしれません。 LANG:verilog module async_fifo #( parameter DATA_BITS = 8, parameter DEPTH_BITS = 11 ) ( input rst, input iclk, input [DATA_BITS-1:0] idata, input we, output reg full, input oclk, output reg [DATA_BITS-1:0] odata, input re, output reg empty ); // バイナリコード・グレイコードの相互変換 function [DEPTH_BITS:0] binary2gray; input [DEPTH_BITS:0] binary; binary2gray = { binary[DEPTH_BITS], binary[DEPTH_BITS-1:0] ^ binary[DEPTH_BITS:1] }; endfunction function [DEPTH_BITS:0] gray2binary; input [DEPTH_BITS:0] gray; reg [DEPTH_BITS:0] temp, result; begin temp = gray; result = gray; while (|temp) begin temp = temp >> 1; result = result ^ temp; end gray2binary = result; end endfunction // メモリ reg [DATA_BITS-1:0] mem [0:2**DEPTH_BITS-1]; // ポインタ変数 // 深さを 2**DEPTH_BITS-1 ではなく 2**DEPTH_BITS とするために // 最上位ビットをフラグとして使っている。 // epmty : rp == wp // full : rp == wp ^ ( 1 << DEPTH_BITS ) reg [DEPTH_BITS:0] rp0; // 現在値 reg [DEPTH_BITS:0] rp1; // +1 reg [DEPTH_BITS:0] rpg; // グレイコード reg [DEPTH_BITS:0] wp0; // 現在値 reg [DEPTH_BITS:0] wp1; // +1 reg [DEPTH_BITS:0] wpg; // グレイコード // ビット幅を指定した 0 と 1 wire [DEPTH_BITS:0] zero = {DEPTH_BITS{1'b0}}; wire [DEPTH_BITS:0] one = { {DEPTH_BITS-1{1'b0}}, 1'b1 }; // メモリの読み書き // full / empty のチェックは外部回路で行う always @(posedge iclk) if (!rst & we) mem[wp0[DEPTH_BITS-1:0]] <= idata; wire mem_ce; always @(posedge oclk) if (mem_ce) // empty 時に読み出すと書き込みとかぶるので回避する odata <= mem[re ? rp1[DEPTH_BITS-1:0] : rp0[DEPTH_BITS-1:0]]; // カウンタ操作 always @(posedge iclk) if (rst) begin wp0 <= zero; wp1 <= one; wpg <= binary2gray(zero); end else if (we) begin wp0 <= wp1; wp1 <= wp1 + one; wpg <= binary2gray(wp1); end always @(posedge oclk) if (rst) begin rp0 <= zero; rp1 <= one; rpg <= binary2gray(zero); end else if (re) begin rp0 <= rp1; rp1 <= rp1 + one; rpg <= binary2gray(rp1); end // 2段FFによるポインタの受け渡し // 各FFに配置制約を付けるためビット毎に操作している wire [DEPTH_BITS:0] iclk_rpg; genvar rpg_i; generate for (rpg_i=0; rpg_i<=DEPTH_BITS; rpg_i=rpg_i+1) begin: rpg_for double_ff rpg_ff( .idata(rpg[rpg_i]), .oclk(iclk), .odata(iclk_rpg[rpg_i]) ); end endgenerate wire [DEPTH_BITS:0] oclk_wpg; genvar wpg_i; generate for (wpg_i=0; wpg_i<=DEPTH_BITS; wpg_i=wpg_i+1) begin: wpg_for double_ff wpg_ff( .idata(wpg[wpg_i]), .oclk(oclk), .odata(oclk_wpg[wpg_i]) ); end endgenerate // グレイコードをバイナリコードに変換 reg [DEPTH_BITS:0] iclk_rp0; always @(posedge iclk) iclk_rp0 <= gray2binary(iclk_rpg); reg [DEPTH_BITS:0] oclk_wp0; always @(posedge oclk) oclk_wp0 <= gray2binary(oclk_wpg); // 次クロックのための full / empty 信号を計算 wire [DEPTH_BITS:0] mask = ( one << DEPTH_BITS ); wire next_full = we ? ( ( iclk_rp0 ^ mask ) == wp1[WDEPTH_BITS:WDEPTH_BITS-SMALLER_DEPTH_BITS] ) : ( ( iclk_rp0 ^ mask ) == wp0[WDEPTH_BITS:WDEPTH_BITS-SMALLER_DEPTH_BITS] ) ; always @(posedge iclk) if (rst) full <= 1'b0; else full <= next_full; wire next_empty = re ? ( rp1[WDEPTH_BITS:WDEPTH_BITS-SMALLER_DEPTH_BITS] == oclk_wp0 ) : ( rp0[WDEPTH_BITS:WDEPTH_BITS-SMALLER_DEPTH_BITS] == oclk_wp0 ) ; always @(posedge oclk) if (rst) empty <= 1'b1; else empty <= next_empty; // empty 時に読み出すと書き込みとかぶるので回避する assign mem_ce = !next_empty; endmodule ** テストベンチ [#s4576197] LANG:verilog module async_fifo_test; integer delay = 1.5; // 信号書き込みディレイ reg error; // エラー表示用信号 // Inputs reg rst; reg iclk; reg [7:0] idata; reg we; reg oclk; reg re; // Outputs wire full; wire [7:0] odata; wire empty; // Instantiate the Unit Under Test (UUT) async_fifo uut ( .rst(rst), .iclk(iclk), .idata(idata), .we(we), .full(full), .oclk(oclk), .odata(odata), .re(re), .empty(empty) ); integer CLKA = 10; integer CLKB = 10; initial begin // Initialize Inputs rst = 1; iclk = 0; idata = 0; we = 0; oclk = 0; re = 0; // Wait 100 ns for global reset to finish #100; // Add stimulus here #500; // 初期化時間 // タイミングを測ってリセットを下ろす wait (iclk==1 && oclk==1) rst = 0; // いくつかのクロックの組み合わせに対してシミュレート CLKA = 10; CLKB = 10; #1000000; CLKA = 10; CLKB = 10.1; #1000000; CLKA = 8; CLKB = 10.3; #1000000; CLKA = 10; CLKB = 30.1; #1000000; CLKA = 30; CLKB = 10.1; #1000000; $stop; end // クロック生成 always #CLKA iclk = !iclk; always #CLKB oclk = !oclk; // ランダムなタイミングで書き込み reg we_rand; always @(posedge iclk) we_rand <= #delay ($random & 1)==1; always @(*) we = #delay !rst & !full & we_rand; integer i = 1; always @(posedge iclk) if ( we ) begin idata <= #delay i; i <= i + 1; end // ランダムなタイミングで読み出し reg re_rand; always @(posedge oclk) re_rand <= #delay ($random & 1)==1; always @(*) re = #delay ( !rst & !empty & re_rand ); integer j = 0; always @(posedge oclk) begin error = 0; if ( re ) begin // 書き込んだデータが正しく読み出せているかをチェック if ( (j & 'hff) != odata) begin error = 1; $display("odata @ %d : %d expected but %d found", $time, j & 'hff, odata); end j <= j + 1; end end endmodule ** 疑問 [#uc0c5b5e] 上記回路を Post Map や Post Place & Route でシミュレーションすると、 ASYNC_REG 制約を付けているにもかかわらず double_ff の temp1 に setup / hold time 違反の警告が多数表示されます。 制約を付けない場合にはシミュレーション結果自体が不定値 X だらけになってしまうので、制約に意味があるのは確かだとしても、 このままだと他の重要な警告を探しにくくなってしまうので、 警告自体も消せると助かるのですが。。。 って、あれ?出なくなった。さっきは出てたんだけど・・・ * コメント [#kd328739] #comment_kcaptcha
Counter: 164266 (from 2010/06/03),
today: 24,
yesterday: 0