２つのクロックドメインがある時の同期リセットの入れ方

今作製しているキャラクタ生成コントローラは、65MHzと150MHzの2つのクロックドメインを持つ。ステートマシンやフリップフロップなどは、同期リセットを使用している。その場合に、リセットは1系統、例えば、スイッチからチャタリング除去回路（無い場合もあるけど）を通って、そのままFFなどのリセットに入れたのでは、本当はまずいのではないだろうか？
今まで、仕事では非同期リセットのみだったので、あまり考えなかったが、リセットをそれぞれのクロックで2段に同期化して、それぞれのクロックドメインのリセット信号としてみようと思う。
CORE Generator で作った同期FIFOはそのクロックドメインのリセット信号を与えれば良いが、非同期FIFOはどうだろうか？早速、Fifo Generator を起動してみてみた。


Enable Reset Synchronization というオプションがあった。これで、それぞれのクロックの同期化しているようだ。これだとリセット端子はRST1本だが、Enable Reset Synchronizationのチェックを外すとWR_RST, RD_RSTの2つに分離する。

WR_RST, RD_RSTの2つに分離した状態で、それぞれのクロックドメインのリセット信号を入れてやってみよう。

FPGA同期リセット変更（PCI-Xテスト・モジュール）

FPGAの非同期リセットと同期リセットの比較は終わって、同期リセットの方がよいということになった。PCI-Xテスト・モジュールも大体完成したので、これを同期リセットに直すことにした。
それで、直したのだが、どうもタイミング制約が満足できない。
まずはADが満足できない。それは、出力バッファのイネーブル制御がIOBのFFに入らなくなってしまったためのようだ。元の（非同期リセットの）ADの宣言や関係している部分を抜き出すと、下のようになる。
ちなみに使っている論理合成ツールはSynplify Pro 8.5, ISEは9.1SP3。

        ad : inout std_logic_vector(63 downto 0); -- アドレスとデータ

signal pcix_dout_ena, master_dout_ena : std_logic;

attribute syn_useioff of pcix_dout_ena : signal is true;

    process(reset, pcix_clk) begin -- ADのイネーブルをIOBに入れる
        if reset='1' then
            pcix_dout_ena <= '0';
        elsif pcix_clk'event and pcix_clk='1' then
            pcix_dout_ena <= target_dout_ena or master_dout_ena;
        end if;
    end process;
    process(pcix_dout, pcix_dout_ena) begin -- PCIX_ADへの出力トライステート・バッファ
        if pcix_dout_ena='1' then
            ad <= pcix_dout;
        else
            ad <= (others => 'Z');
        end if;
    end process;

1行目はADの入出力ポート宣言、2行目はpcix_dout_enaの宣言、3行目はsyn_useioffを宣言して各ADのIOBに出力バッファのイネーブル制御用FFをインスタンシエーションするように指定している。4行目からはVHDLコード。これで各ADのIOBに出力バッファのイネーブル制御用FFをインスタンシエーションすることができている。


Timing Analyzerでみた遅延も規格内に収まっている。

Timing constraint: COMP "pcix_ad(10)" OFFSET = OUT 3.8 ns AFTER COMP "pcix_clk";

 2 items analyzed, 0 timing errors detected.
 Minimum allowable offset is   3.086ns.
--------------------------------------------------------------------------------
Slack:                  0.714ns (requirement - (clock arrival + clock path + data path + uncertainty))
  Source:               pcix_inst/pcix_dout[10] (FF)
  Destination:          pcix_ad(10) (PAD)
  Source Clock:         clk_dcm rising at 0.645ns
  Requirement:          3.800ns
  Data Path Delay:      2.715ns (Levels of Logic = 0)
  Clock Path Delay:     -0.274ns (Levels of Logic = 3)
  Clock Uncertainty:    0.000ns

  Clock Path: pcix_clk to pcix_inst/pcix_dout[10]
    Delay type         Delay(ns)  Logical Resource(s)
    ----------------------------  -------------------
    Tiopi                 0.921   pcix_clk
                                  dcm_pcix_inst/CLKIN_IBUFG_INST
    net (fanout=1)        0.431   dcm_pcix_inst/CLKIN_IBUFG
    Tdcmino              -4.145   dcm_pcix_inst/DCM_INST
    net (fanout=1)        1.185   dcm_pcix_inst/CLK0_BUF
    Tgi0o                 0.057   dcm_pcix_inst/CLK0_BUFG_INST
    net (fanout=681)      1.277   clk_dcm
    ----------------------------  ---------------------------
    Total                -0.274ns (-3.167ns logic, 2.893ns route)

  Data Path: pcix_inst/pcix_dout[10] to pcix_ad(10)
    Delay type         Delay(ns)  Logical Resource(s)
    ----------------------------  -------------------
    Tiockp                2.715   pcix_inst/pcix_dout[10]
                                  pcix_ad_iobuf[10]/OBUFT
                                  pcix_ad(10)
    ----------------------------  ---------------------------
    Total                 2.715ns (2.715ns logic, 0.000ns route)
                                  (100.0% logic, 0.0% route)

これを同期リセットに修正すると、どうもADのイネーブル信号が1つにまとめられてしまうようだ。下のようにpcix_dout_enaをバスにしてみたが、それでもだめなようだ。

signal pcix_dout_ena : std_logic_vector(63 downto 0);

attribute syn_useioff of pcix_dout_ena : signal is true;
attribute syn_keep of pcix_dout_ena : signal is true;

    process(pcix_clk) begin -- ADのイネーブルをIOBに入れる
        if pcix_clk'event and pcix_clk='1' then
            for i in 63 downto 0 loop
                if reset='1' then
                    pcix_dout_ena(i) <= '0';
                else
                    pcix_dout_ena(i) <= target_dout_ena or master_dout_ena;
                end if;
            end loop;
        end if;
    end process;
    process(pcix_dout, pcix_dout_ena) begin -- PCIX_ADへの出力トライステート・バッファ
        for i in 63 downto 0 loop
            if pcix_dout_ena(i)='1' then
                ad(i) <= pcix_dout(i);
            else
                ad(i) <= 'Z';
            end if;
        end loop;
    end process;

Timing Analyzerでの解析結果はこれ。

Timing constraint: COMP "pcix_ad(10)" OFFSET = OUT 3.8 ns AFTER COMP "pcix_clk";

 2 items analyzed, 1 timing error detected.
 Minimum allowable offset is   3.946ns.
--------------------------------------------------------------------------------
Slack:                  -0.146ns (requirement - (clock arrival + clock path + data path + uncertainty))
  Source:               pcix_inst/pcix_dout_ena[0] (FF)
  Destination:          pcix_ad(10) (PAD)
  Source Clock:         clk_dcm rising at 0.645ns
  Requirement:          3.800ns
  Data Path Delay:      3.588ns (Levels of Logic = 1)
  Clock Path Delay:     -0.287ns (Levels of Logic = 3)
  Clock Uncertainty:    0.000ns
  Timing Improvement Wizard
  Clock Path: pcix_clk to pcix_inst/pcix_dout_ena[0]
    Delay type         Delay(ns)  Logical Resource(s)
    ----------------------------  -------------------
    Tiopi                 0.921   pcix_clk
                                  dcm_pcix_inst/CLKIN_IBUFG_INST
    net (fanout=1)        0.431   dcm_pcix_inst/CLKIN_IBUFG
    Tdcmino              -4.145   dcm_pcix_inst/DCM_INST
    net (fanout=1)        1.185   dcm_pcix_inst/CLK0_BUF
    Tgi0o                 0.057   dcm_pcix_inst/CLK0_BUFG_INST
    net (fanout=687)      1.264   clk_dcm
    ----------------------------  ---------------------------
    Total                -0.287ns (-3.167ns logic, 2.880ns route)

  Data Path: pcix_inst/pcix_dout_ena[0] to pcix_ad(10)
    Delay type         Delay(ns)  Logical Resource(s)
    ----------------------------  -------------------
    Tcko                  0.374   pcix_inst/pcix_dout_ena[0]
    net (fanout=64)       0.629   pcix_inst/pcix_dout_ena_1(0)
    Tiotp                 2.585   pcix_ad_iobuf[10]/OBUFT
                                  pcix_ad(10)
    ----------------------------  ---------------------------
    Total                 3.588ns (2.959ns logic, 0.629ns route)
                                  (82.5% logic, 17.5% route)

V2proを使用したPCI-X 133MHzでは、IOBにFFを入れないとタイミングを満足できないので、FFがIOBに入らないのは致命的だ。
Synplify proを使用するときは、とりあえず非同期リセットで行くことにした。

FPGAの非同期リセットと同期リセットの比較（DDR-SDRAMコントローラ）

FPGAの非同期リセットと同期リセットの比較（Verilog）でどたばたしてしまったが、無事にスパルタン３EスタータキットでDR-SDRAMコントローラが非同期リセットと同期リセットでインプリメントできたので、比べてみようと思う。（使用ツールはISE9.2iSP3、使用デバイスはスパルタン３E、xc3s500e-4fg320）
まずは非同期リセットのマップリポートは以下のようになった。

Design Summary
--------------
Number of errors:      0
Number of warnings:    2
Logic Utilization:
  Number of Slice Flip Flops:         575 out of   9,312    6%
  Number of 4 input LUTs:             512 out of   9,312    5%
Logic Distribution:
  Number of occupied Slices:                          582 out of   4,656   12%
    Number of Slices containing only related logic:     582 out of     582  100%
    Number of Slices containing unrelated logic:          0 out of     582    0%
      *See NOTES below for an explanation of the effects of unrelated logic
Total Number of 4 input LUTs:            800 out of   9,312    8%
  Number used as logic:                512
  Number used as a route-thru:          64
  Number used for Dual Port RAMs:      172
    (Two LUTs used per Dual Port RAM)
  Number used for 32x1 RAMs:            52
    (Two LUTs used per 32x1 RAM)
  Number of bonded IOBs:               66 out of     232   28%
    IOB Flip Flops:                    49
  Number of ODDR2s used:               38
    Number of DDR_ALIGNMENT = NONE     38
  Number of Block RAMs:                1 out of      20    5%
  Number of GCLKs:                     6 out of      24   25%
  Number of DCMs:                      3 out of       4   75%

Total equivalent gate count for design:  113,940
Additional JTAG gate count for IOBs:  3,168
Peak Memory Usage:  161 MB
Total REAL time to MAP completion:  20 secs 
Total CPU time to MAP completion:   19 secs 

つぎは同期リセットのマップリポート。

Design Summary
--------------
Number of errors:      0
Number of warnings:    2
Logic Utilization:
  Number of Slice Flip Flops:         576 out of   9,312    6%
  Number of 4 input LUTs:             459 out of   9,312    4%
Logic Distribution:
  Number of occupied Slices:                          576 out of   4,656   12%
    Number of Slices containing only related logic:     576 out of     576  100%
    Number of Slices containing unrelated logic:          0 out of     576    0%
      *See NOTES below for an explanation of the effects of unrelated logic
Total Number of 4 input LUTs:            747 out of   9,312    8%
  Number used as logic:                459
  Number used as a route-thru:          64
  Number used for Dual Port RAMs:      172
    (Two LUTs used per Dual Port RAM)
  Number used for 32x1 RAMs:            52
    (Two LUTs used per 32x1 RAM)
  Number of bonded IOBs:               66 out of     232   28%
    IOB Flip Flops:                    49
  Number of ODDR2s used:               38
    Number of DDR_ALIGNMENT = NONE     38
  Number of Block RAMs:                1 out of      20    5%
  Number of GCLKs:                     6 out of      24   25%
  Number of DCMs:                      3 out of       4   75%

Total equivalent gate count for design:  113,633
Additional JTAG gate count for IOBs:  3,168
Peak Memory Usage:  160 MB
Total REAL time to MAP completion:  20 secs 
Total CPU time to MAP completion:   19 secs 

Number of Slice Flip Flops:は非同期リセットが575に対して、同期リセットが576で１つ多い。
Number of 4 input LUTs: は非同期リセットが512に対して、同期リセットが459で53少ない。
Number of occupied Slices:は非同期リセットは582に対して、同期リセットは576で6少ない。
Number of Slice Flip Flops:が同期リセットの方が1つ増えているが、全体的には同期リセットのほうが使用リソースが低いという結果になった。
なお、ツールのデフォルトから、以下の項目を変更してある。
１．XSTのプロパティのOptimization EffortをHigh
２．MAPのプロパティのOptimization Strategy (Cover Mode)をSpeed
３．Place & RouteのプロパティのPlace & Route Effort Level (Overall)をHigh
４．Place & RouteのプロパティのExtra Effort (Highest PAR level only) をContinue on Impossible

最後に動作周波数の違いを比べてみようと思います。
通常は50MHzの水晶発振器を2倍の100MHzにして使っています。つまりDDR200名わけですが、これを66MHzの水晶発振器をつけたと仮定して、DDR266でいけるかどうかやってみました。
その結果、非同期リセットのP&Rリポートです。

------------------------------------------------------------------------------------------------------
  Constraint                                |  Check  | Worst Case |  Best Case | Timing |   Timing   
                                            |         |    Slack   | Achievable | Errors |    Score   
------------------------------------------------------------------------------------------------------
* TS_ddr_sdram_cont_inst_dcm_module_inst_cl | SETUP   |    -1.741ns|     9.241ns|      88|       60600
  k_node = PERIOD TIMEGRP         "ddr_sdra | HOLD    |     0.902ns|            |       0|           0
  m_cont_inst_dcm_module_inst_clk_node"     |         |            |            |        |            
       TS_dcm100_inst_CLK2X_BUF HIGH 50%    |         |            |            |        |            
------------------------------------------------------------------------------------------------------
* TS_dcm100_inst_CLK0_BUF = PERIOD TIMEGRP  | SETUP   |    -0.017ns|    15.034ns|       1|          17
  "dcm100_inst_CLK0_BUF" TS_clk HIGH        | HOLD    |     0.758ns|            |       0|           0
    50%                                     |         |            |            |        |            
------------------------------------------------------------------------------------------------------
  TS_dcm100_inst_CLK2X_BUF = PERIOD TIMEGRP | SETUP   |     0.056ns|     7.444ns|       0|           0
   "dcm100_inst_CLK2X_BUF" TS_clk / 2       | HOLD    |     1.369ns|            |       0|           0
     HIGH 50%                               |         |            |            |        |            
------------------------------------------------------------------------------------------------------
  TS_ddr_sdram_cont_inst_dcm_module_inst_cl | SETUP   |     0.298ns|     6.904ns|       0|           0
  k90_node = PERIOD TIMEGRP         "ddr_sd | HOLD    |     2.397ns|            |       0|           0
  ram_cont_inst_dcm_module_inst_clk90_node" |         |            |            |        |            
           TS_dcm100_inst_CLK2X_BUF PHASE 1 |         |            |            |        |            
  .875 ns HIGH 50%                          |         |            |            |        |            
------------------------------------------------------------------------------------------------------
  TS_ddr_sdram_cont_inst_clk1_161 = PERIOD  | SETUP   |     0.810ns|     4.952ns|       0|           0
  TIMEGRP         "ddr_sdram_cont_inst_clk1 | HOLD    |     1.431ns|            |       0|           0
  _161" TS_dcm100_inst_CLK2X_BUF * 16 HIGH  |         |            |            |        |            
  50%                                       |         |            |            |        |            

次に同期リセット。

------------------------------------------------------------------------------------------------------
  Constraint                                |  Check  | Worst Case |  Best Case | Timing |   Timing   
                                            |         |    Slack   | Achievable | Errors |    Score   
------------------------------------------------------------------------------------------------------
* TS_ddr_sdram_cont_inst_dcm_module_inst_cl | SETUP   |    -1.248ns|     8.748ns|      76|       41070
  k_node = PERIOD TIMEGRP         "ddr_sdra | HOLD    |     0.926ns|            |       0|           0
  m_cont_inst_dcm_module_inst_clk_node"     |         |            |            |        |            
       TS_dcm100_inst_CLK2X_BUF HIGH 50%    |         |            |            |        |            
------------------------------------------------------------------------------------------------------
* TS_dcm100_inst_CLK0_BUF = PERIOD TIMEGRP  | SETUP   |    -0.434ns|    15.868ns|       1|         434
  "dcm100_inst_CLK0_BUF" TS_clk HIGH        | HOLD    |     0.765ns|            |       0|           0
    50%                                     |         |            |            |        |            
------------------------------------------------------------------------------------------------------
  TS_ddr_sdram_cont_inst_dcm_module_inst_cl | SETUP   |     0.233ns|     7.034ns|       0|           0
  k90_node = PERIOD TIMEGRP         "ddr_sd | HOLD    |     2.449ns|            |       0|           0
  ram_cont_inst_dcm_module_inst_clk90_node" |         |            |            |        |            
           TS_dcm100_inst_CLK2X_BUF PHASE 1 |         |            |            |        |            
  .875 ns HIGH 50%                          |         |            |            |        |            
------------------------------------------------------------------------------------------------------
  TS_dcm100_inst_CLK2X_BUF = PERIOD TIMEGRP | SETUP   |     0.394ns|     7.106ns|       0|           0
   "dcm100_inst_CLK2X_BUF" TS_clk / 2       | HOLD    |     1.421ns|            |       0|           0
     HIGH 50%                               |         |            |            |        |            
------------------------------------------------------------------------------------------------------
  TS_ddr_sdram_cont_inst_clk1_161 = PERIOD  | SETUP   |     0.887ns|     4.959ns|       0|           0
  TIMEGRP         "ddr_sdram_cont_inst_clk1 | HOLD    |     1.382ns|            |       0|           0
  _161" TS_dcm100_inst_CLK2X_BUF * 16 HIGH  |         |            |            |        |            
  50%                                       |         |            |            |        |            

X1つまり66MHzのクリティカルパスは、非同期リセットの方が遅延が少ないが、同期リセットの方がX2つまり133MHｚのクリティカルパスの遅延が少なくなっている。
やはり、LUTが少ないほうが遅延が少ないような気がするが、痛みわけだろうか？いろいろな要因で違ってくると思うし、コストテーブルを変更すると違った結果になるかもしれない。

このような結果と、いろいろ他の方からも同期リセットの方がよいと教えてもらいましたし、今度からは、すべての回路を同期リセットで書くようにしようと思います。

FPGAの非同期リセットと同期リセットの比較（Verilog）

今度はVerilogのDDR-SDRAMコントローラでやってみようと思って、非同期リセットの変えたつもりでやってみたら、使用LUTが変わらない。これはおかしいと思って、FPGA Editorで見てみたら、非同期リセットが使われていた。どうしてだろうか？
ソースコードはこれ。(だけじゃないけど。。。全部同期リセットにしたつもり）（使用ツールはISE9.2iSP3、使用デバイスはスパルタン３E、xc3s500e-4fg320）

    always @(posedge clk) begin
        if (reset) begin
            pre_cnt[PRE_CNT_WIDTH-1 : 1] <= 0;
            pre_cnt[0] <= 1'b1; // 最初に0だとint_cntがダウンカウントするので
        end else begin
            if (int_cnt != 0) // int_cntが0までカウント
                pre_cnt <= pre_cnt + 1;
            else begin
                pre_cnt[PRE_CNT_WIDTH-1 : 1] <= 0;
                pre_cnt[0] <= 1'b1; // 最初に0だとint_cntがダウンカウントするので
            end
        end
    end

Verilogに詳しい方どうでしょうか？　これで同期リセット記述になっていますよね？
ちなみにこれでもだめだった。

    always @(posedge clk) begin
        if (reset) begin
            pre_cnt[PRE_CNT_WIDTH-1 : 1] <= 0;
            pre_cnt[0] <= 1'b1; // 最初に0だとint_cntがダウンカウントするので
        else if (int_cnt != 0) // int_cntが0までカウント
            pre_cnt <= pre_cnt + 1;
        else begin
            pre_cnt[PRE_CNT_WIDTH-1 : 1] <= 0;
            pre_cnt[0] <= 1'b1; // 最初に0だとint_cntがダウンカウントするので
        end
    end

これを論理合成して、"View RTL Schematic"で見るとこうなる。


FDCは非同期リセット付きFFで、FDPは非同期セット付きFFだ。つまりどちらも非同期セット、リセットしている。どうしたら同期セット、リセットになるのだろうか？
ちなみにXSTのプロパティのXilinx Specific Options の Use Synchronous Set と Use Synchronous Reset オプションは両方ともYes になっている。
しょうがないので、XSTのプロパティの HDL Options の Asynchronous To Synchronous オプションをチェックしたら、同期セット、リセットとなった。
これを論理合成して、"View RTL Schematic"で見るとこうなる。


FDRは同期リセット付きFF、FDSは同期セット付きFF。これで思い通りになったが、釈然としない。
Verilogコードが間違っているとか、または、何か他の情報を持っているという方は教えてください。一応、Xilinxのアンサーサーチをあさったのですが、情報がありませんでした。

2007/12/18　追記： sueさんに教えてもらった結果を見て、単純なカウンタをやってみました。これはちゃんと同期リセットになりました。そこでもう一度プロジェクトを作り直したら、FDRとFDSを使うようになりました。何かプロジェクトがおかしかったみたいです。
sueさん、ありがとうございました。

FPGAの非同期リセットと同期リセットの比較（ダイナミック点灯回路）

FPGAの非同期リセットと同期リセットの比較をSpartan3 Starter Kitのダイナミック点灯回路でやってみることにした。
最初にそのまま、インプリメントしてみた。その次に非同期リセットを同期リセットに変更してインプリメントしてみた。
どうやって直したかというと、こういうのを

    process(reset, clk) begin -- Lighting frequency is 1KHz
        if reset='1' then
            lcnt <= (others => '0');
        elsif clk'event and clk='1' then
            if lcnt = conv_std_logic_vector(clk_frequency, 16) then
                lcnt <= (others => '0');
            else
                lcnt <= lcnt + 1;
            end if;
        end if;
    end process;

こうした。

    process(clk) begin -- Lighting frequency is 1KHz
        if clk'event and clk='1' then
            if reset='1' then
                lcnt <= (others => '0');
            elsif lcnt = conv_std_logic_vector(clk_frequency, 16) then
                lcnt <= (others => '0');
            else
                lcnt <= lcnt + 1;
            end if;
        end if;
    end process;

この結果、非同期リセットのMAPの結果は以下の通り。

Design Summary
--------------
Number of errors:      0
Number of warnings:    2
Logic Utilization:
  Number of Slice Flip Flops:          22 out of   3,840    1%
  Number of 4 input LUTs:              72 out of   3,840    1%
Logic Distribution:
  Number of occupied Slices:                           46 out of   1,920    2%
    Number of Slices containing only related logic:      46 out of      46  100%
    Number of Slices containing unrelated logic:          0 out of      46    0%
      *See NOTES below for an explanation of the effects of unrelated logic
Total Number of 4 input LUTs:             87 out of   3,840    2%
  Number used as logic:                 72
  Number used as a route-thru:          15
  Number of bonded IOBs:               19 out of     173   10%
    IOB Flip Flops:                     5
  Number of GCLKs:                     1 out of       8   12%

Total equivalent gate count for design:  750
Additional JTAG gate count for IOBs:  912
Peak Memory Usage:  135 MB
Total REAL time to MAP completion:  10 secs 
Total CPU time to MAP completion:   6 secs 

次に、同期リセットに修正したMAP結果は以下の通り。

Design Summary
--------------
Number of errors:      0
Number of warnings:    2
Logic Utilization:
  Number of Slice Flip Flops:          22 out of   3,840    1%
  Number of 4 input LUTs:              33 out of   3,840    1%
Logic Distribution:
  Number of occupied Slices:                           27 out of   1,920    1%
    Number of Slices containing only related logic:      27 out of      27  100%
    Number of Slices containing unrelated logic:          0 out of      27    0%
      *See NOTES below for an explanation of the effects of unrelated logic
Total Number of 4 input LUTs:             48 out of   3,840    1%
  Number used as logic:                 33
  Number used as a route-thru:          15
  Number of bonded IOBs:               19 out of     173   10%
    IOB Flip Flops:                     5
  Number of GCLKs:                     1 out of       8   12%

Total equivalent gate count for design:  507
Additional JTAG gate count for IOBs:  912
Peak Memory Usage:  135 MB
Total REAL time to MAP completion:  11 secs 
Total CPU time to MAP completion:   7 secs

Number of Slice Flip Flops:は22で同じだけれども、Number of 4 input LUTs: は非同期リセットが72、同期リセットが33で、同期リセットのほうが半分以下になっている。
さらにFloorplanerでも比較してみた。右が非同期リセット、左が同期リセットだ。


やはり、明らかに同期リセットのほうが使用SLICEが少ない。
こんなに違うのは、なんかおかしい気がするが、同期リセットのほうがかなり有利ということになるのだろうか？一応、ちょっとは双方の回路ともシミュレーションしてあるが、実機に入れて確かめてはいない。
もう少し検証してみようと思う。

FPGAの非同期リセットと同期リセットの比較

hypermacさんに教えていただいたXcell Journal Issue 55の”デザインパフォーマンス向上のためのHDL コーディング法”を見ると非同期リセットを使うと論理合成ルールでの推論（SRL16、BRAM）やロジックの最適化を妨げる場合があるとのことだった。
私は、SRL16やBRAMはプリミティブをインスタンシエーションしているので問題ない。しかし、ロジックの最適化は気になるところである。
とりあえず、デザインパフォーマンス向上のためのHDL コーディング法のVerilog Sample #2をSuzakuに載っているVirtex4FXでやってみることにした。Xell Journal のVerilogコードと同一だが、一応、コードを載せておく。

`default_nettype none
`timescale 1ns / 1ps

module reset_test(clk, reset, a, b, c, d, e, q);
    input clk;
    input reset;
    input a;
    input b;
    input c;
    input d;
    input e;
    output q;
    wire clk, reset, a, b, c, d, e;
    reg q;
    
    always @(posedge clk)
        if (reset)
            q <= 1'b0;
        else
            q <= a | (b&c&d&e);
endmodule

論理合成すると下のようになった。


ここでは普通の論理合成結果になった。”デザインパフォーマンス向上のためのHDL コーディング法”の”図2　より柔軟なLUT の推論”とは違っている。これをインプリメントして、FPGA Editorで見るとこうなった。


入力aがFFのREVに入っていて、その他のロジックは1つのLUTですんでいる。よって、”図2　より柔軟なLUT の推論”と同様になった。これはMAPでやっているのだと思う。1つのSLICEのみ使用している。ちなみに、デフォルトのままだとOLOGICのFFを使ってしまうので、IOBのFFを使わないようにUCFに書いた。

INST "q" IOB = FALSE;

比較のために非同期リセットにしてやってみた。Verilogコードのうちのalways@ をこう変更した。

always @(posedge reset, posedge clk)

論理合成の結果は、同期リセットと変化がなかった。その後、インプリメントして、同様にFPGA Editorで見てみた。


同期リセットの時には、１つのLUTとFFのみ使用したが、非同期リセットの時には2つのLUTとFFを使用している。
”デザインパフォーマンス向上のためのHDL コーディング法”で言われているように同期リセットだとロジックと遅延を低減する効果があるようだ。

hypermacさん、教えていただいて、ありがとうございます。SLICE内のFFに同期リセットオプションがあるのを知りませんでした。これだったら、もしクロックが安定しなくて、変なステートに行っても確実にリセットがかけられますね。
もうちょっと複雑な回路を同期リセットと非同期リセットでどうなるか？比べてみようと思います。

FPGAのリセット

hypermacさんからFPGAのリセットの方法についてコメントがあったが、私はリセットについては余り考えていなかった。うちのボードのリセット方法については、”うちのボードのリセット回路とFPGAのコンフィギュレーション”を見てください。
ModelSimでリセットしないと不定になるので、非同期リセットを必ずつけて、シミュレーションしていたし、そのリセットを外部から制御して非同期リセットにしていた。
同期リセットにしない理由のひとつは、水晶発信器も発振開始時間があって、電源ONからすぐに安定して動かないことだ。例えば、使用しているEG-2121CAは10ms だ。この時間は発振が安定する保証はないから、同期リセットをアサートしていても安定するとは限らない。ステートマシンも不正ステートに行っているも知れないので、同期リセットをつけるとすると回路規模が大きくなってしまう。
うちでは、製品じゃないので、リセットしてだめだったら再立ち上げすれば良い。頻繁にだめにならないのだったら、それでOKということで非同期リセットにしている。
一応、リセットの外れるタイミングの違いは気にはしていて、非同期リセットラインの遅延の差をFPGA Editorで確認はしていた。その結果は、V2pro（xc2vp30-6ff896)では大体2.?ns～3.9ns 位の間に収まっているようだ。一度も非同期リセットの関連ではおかしくなったことはない。（気がついてないだけかもしれないけども。。。）おかしくなったら考えようと思っている。
とりあえず、うちはこれで良いと思っている。下はリセットラインのFPGA EditorのWorldの図。



もしやるとしたら、こうするかも？　DFFを2段くらいにしておいて、そのDFFの非同期リセット端子または非同期セット端子に外部からの非同期リセットを入れておく。そのDFFのD入力に外部からの非同期リセットを入れて、2段目のDFFの出力でその他の回路を非同期リセット。非同期リセットのネットには遅延の制約をかけておく。　果たしてうまくいくでしょうか？