夜中の火事

今日の早朝3時ころ、消防車の音が聞こえ、犬がうるさくほえていたので、外に出てみたら、南西が炎で真っ赤だった。これはすぐそばで、火事になったかと思ったが、実は割と遠くて、直線距離で400m位あった。でも、すぐ近くに見えて、火の粉が飛び散っていて、本当に怖かった。これがすぐそばで燃えていたらパニックになってしまうと思う。火事は本当に怖い。
そのときは、消防車が集まってきたようなので、家に入って寝なおそうと思ったが、眠れない。少し横になったが、すぐに起床した。明るくなってきたころ、自転車で見に行ったが、消防車、パトカー、救急車でいっぱい。とても火元の家まではいけなかった。３軒燃えてしまったようだ。木工所から火が出て、洋品店に延焼、その隣の家にも延焼したようだ。今他の人に聞いたら、火元が逆といっていたので、わからない。明日の新聞で確認してみよう。（確認しみたら、やはり木工所から出火したようだ）
今日は、やはり眠い。

”アサーション事始め”の目次

PS/2キーボードインターフェース用テストベンチ（procedure使用）のアサーションのようなもの（PS/2キーボードインターフェース用テストベンチ（procedure使用）のVHDLで書いたテストベンチにアサーションのようなものを追加して、エラーが出たらシミュレーションがブレークして、エラーメッセージが出るようにした）
PS/2キーボードインターフェース用テストベンチ（task使用）のアサーション（Verilog2001を使用して前のVHDLと同様にアサーションを組み込んでみた。Veritakでの動作例を示した）
PS/2キーボードインターフェース用テストベンチ（task使用）のアサーション($timeformat)（たっくさんに $timeformat を教えてもらったので、エラーの発生した時刻を表示できるようにした。同様にVeritakでの動作例を示した）

VALID制約

きじばと日記のPV4／FPGA回路更新を予告で”ハイビジョンキャプチャカード「PV4」が主に Core 2 Duo 環境で認識されない問題について、FPGA回路更新を計画しているようです。”という記事があった。
これは、インプレスのAKIBA PC Hotline!の記事でもおなじみのカードらしい。
きじばと日記さんの有限会社アースソフトさんのリンクから飛ぶと、リリース番号:02というタイミングレポートがあった。これをみるとPCIバスのパリティ出力回路にバグがあったようだ。
これを精査してみると、いろいろ興味深いのだが、ここでいろいろ書くのはまずいと思われる。ただ、VALID制約を書いたことがなかったので、調べてみた。
その結果、制約ガイドの71ページに良く書いてあった。
それは入力用DDRレジスタを使った例で、RISINGエッジやFALLINGエッジをTIMEGRPでグループ化して制約をかけていた。下のように。（詳しくは制約ガイドを見てください）

TIMEGRP DATA_IN OFFSET = IN 1 VALID 3 BEFORE CLK TIMEGRP FF_RISING;
TIMEGRP DATA_IN OFFSET = IN -4 VALID 3 BEFORE CLK TIMEGRP FF_FALLING;

上がRISINGエッジで、1 nsのセットアップ時間以内に抑えて、データが有効な時間がVALIDの後の3 nsという制約だ。下がFALLINGエッジで、セットアップ時間-クロックサイクル/2 = 1(ns) - 10(ns)/2 = -4 ns がセットアップ時間で、データが有効な時間がVALIDの後の3 nsという制約だ。データが有効な時間が付加されているので、ホールド時間を考慮して、Place & Routeしてくれるのだと思う。ただし、VALID制約が効くのは入力だけだそうだ。

私のPCI-Xモジュールのセットアップ時間の制約も、

NET "pcix_ad(0)" OFFSET = IN 1.2 ns BEFORE "pcix_clk" ;

から、ホールド時間を含めて

NET "pcix_ad(0)" OFFSET = IN 1.2 ns VALID 1.7 ns BEFORE "pcix_clk" ;

に変更した。
インプリメントして、P&Rのレポートを見てみると、下のようになった。あまり変換がないように思えるが、ホールド時間も考慮してくれるのだろう。

Timing constraint: COMP "pcix_ad(0)" OFFSET = IN 1.2 ns VALID 1.7 ns BEFORE COMP "pcix_clk";

1 item analyzed, 0 timing errors detected. (0 setup errors, 0 hold errors)
Minimum allowable offset is 1.175ns.

Xilinxのアンサーデータベースを漁ったら、”8.1i Timing Analyzer/TRACE/制約 - OFFSET/IN 制約で、以前のバージョンでは発生しなかったホールド タイム違反が発生する”が見つかった。
これによると、ホールドタイム違反が出るのを回避するために、指定したオフセットの後にデータが有効である時間を定義するそうだ。逆の発想か！　データが後まで有効ならばホールドタイムも伸びても大丈夫だね。