このページは、 timingに関する一連のページに属しています。前のページでは、 timing 計算の背後にある理論を説明し、 clock period constraintについて説明し、 timing closureの原理を示しました。 timing constraintsの技術的な詳細から始めましょう。
create_clock の Tcl commandとしての意味
これまでのページはすべて、この timing constraintを中心に展開されています。
create_clock -period 4 -name clk [get_ports clk]
これまで、この行の構文については意図的に説明していませんでした。それでは、これが実際に何を意味するのかを説明する時が来ました。
この timing constraint は、 timing constraintsの最も一般的な形式である SDC (Synopsys Design Constraints) 形式で記述されています。 Vivado と Quartus は、この形式と、他のいくつかの FPGA toolsを使用します。
SDC ファイルは、本質的には Tclで記述された script です。したがって、 SDC ファイルの内容は短いコンピュータ プログラムであり、単なる情報の集まりではありません。ただし、 script としての SDC ファイルの機能は、 constraintsの書き込みを目的とした commandsの小さなサブセットに限定されています。 Tcl script で許可されているすべてのことを SDC ファイルで実行できるわけではありません。
create_clock command は timing constraintを定義するために使用されます。しかし実際には、この command は FPGA tools に新しい clock objectを作成するように指示します。そして、「object」という単語は、ソフトウェア エンジニアリングの用語で通常意味するものです。したがって、新しい clock object は、独自の propertiesを持つ object として Tcl interpreterのメモリに保存されるものです。
たとえば、 create_clock command の「-name clk」という部分は、「name」と呼ばれる property に「clk」という値を与えます。前のページの 1 つで、この名前が timing reportsで使用されていたことを思い出してください。 「clk」という名前は、この constraint のために計算された timing paths (より正確には、この clock objectのために計算されたもの) とともに登場しました。
後で、 clk_out1_clk_wiz_1 や clk_out2_clk_wiz_1など、 clocksの別の名前があることがわかりました。これらは実際には、ツールによって自動的に作成された他の clock objectsの名前でした。
すべての clocksをリストするための Tcl command があります: get_clocks.したがって、前のページの 2 つの clocks の例では、これは Vivadoの Tcl consoleでのセッションです。
> get_clocks clk clkfbout_clk_wiz_1 clk_out1_clk_wiz_1 clk_out2_clk_wiz_1
get_clocks および類似の commands については、次のページでさらに詳しく説明します。
これらの objectsの properties を表示することも可能です。これらの propertiesのすべてを理解する必要はありません。 clock が objectであることを強調するために、これを示しています。個人的には、 objectの property を直接操作する必要はありませんでした。
> report_property [get_clocks clk] Property Type Read-only Value CLASS string true clock INPUT_JITTER double true 0.040 IS_GENERATED bool true 0 IS_PROPAGATED bool true 1 IS_USER_GENERATED bool true 0 IS_VIRTUAL bool true 0 NAME string true clk PERIOD double true 4.000 SOURCE_PINS string* true clk SYSTEM_JITTER double true 0.050 WAVEFORM double* true 0.000 2.000 > report_property [get_clocks clk_out1_clk_wiz_1] Property Type Read-only Value CLASS string true clock EDGES int* true 1 2 3 EDGE_SHIFT double* true 0.000 2.000 4.000 INPUT_JITTER double true 0.000 IS_GENERATED bool true 1 IS_INVERTED bool true 0 IS_PROPAGATED bool true 1 IS_RENAMED bool true 0 IS_USER_GENERATED bool true 0 IS_VIRTUAL bool true 0 MASTER_CLOCK clock true clk NAME string true clk_out1_clk_wiz_1 PERIOD double true 8.000 SOURCE pin true pll_i/inst/mmcme3_adv_inst/CLKIN1 SOURCE_PINS string* true pll_i/inst/mmcme3_adv_inst/CLKOUT0 SYSTEM_JITTER double true 0.050 WAVEFORM double* true 0.000 4.000
重要なのは、 create_clock は単に objectを作成するだけであるということです。この command の parameters は、この objectの propertiesをどのように設定するかを決定するだけです。たとえば、「-period 4」という部分 (繰り返し示した timing constraint 内) は、「PERIOD」と呼ばれる特定の propertyが値 4を持つ必要があることを意味します。
これらの Tcl commands を自分で試してみたい場合は、 FPGA toolsとの間に違いがあることに注意してください。
Vivadoでは、これらの commands は Implemented Designを開いた後にのみ使用できます。
Quartusでは、まず TimeQuest Timing Analyzerを開き、次に Create Timing Netlist、 Read SDC File 、 Update Timing Netlistをクリックします。次に、 Tcl consoleで commands を試します。例:
> join [ query_collection -all [ get_clocks ] ] "\n" > get_clock_info -waveform [get_clocks clk]
「clock」という言葉の意味
FPGA tools が「clock」という単語を使用する場合、それは通常、 clock objectを意味し、 FPGA内の物理的な signal を意味するものではありません。これは特に timing reportsに当てはまります。
前のページで「理論上の clocks」という用語を数回使用したことを思い出してください。これらは実際には clock objectsです。これらは timing reportでは「clocks」と呼ばれますが、 timing analysis での使用は、それらが単なる情報のコンテナーであることを示しています。
では、これらの clock objects と実際の signalsの関係は何でしょうか? timing analysisで clock objects の名前をすでに見てきました。これらはすべてどのように連携するのでしょうか?
ツールが designの static timing analysis を実行すると、すべての paths が検査されます。 path が flip-flopで始まる場合、ツールは flip-flopの clock inputに接続されている signal (つまり net) を調べます。 この signalと関連する clock object はありますか? たとえば、 signal が @clkの場合、関連する clock object は、 create_clock commandとともに「clk」という名前が付けられたものです。関連する clock objectを見つけた後、ツールはこの objectの propertiesから必要な情報を取得できます。
pathの最後にある flip-flop でも同じことが起こります。そのため、ツールには pathに対応する 2 つの clock objects があります。これらの objectsからの情報を使用して、ツールは timing analysisを実行します。
そしてもちろん、同じ手順が flip-flopsだけでなく、すべての sequential elementに適用されます。
これを理解することがなぜ重要なのでしょうか。とりわけ、 clockのない registers があると言う timing report の中に error message がある場合があるためです。通常、これは clock inputに何も接続されていない flip-flop があるという意味ではありません。むしろ、これはツールがこの clock inputに関連する clock object を見つけられなかったことを意味します。つまり、ツールはこの flip-flopの clock inputに関する情報を見つけられませんでした。そのため、問題は通常 logic designにはありませんが、 timing constraint がありません (または間違って記述されています)。
これをもう一度言う価値があります： timing reportで「clock」と表示されている場合、それは logic designにその名前の signal があることを意味するのではなく、その名前で clock object が作成されたことを意味します。どの signalかはどのようにしてわかりますか?それが次のトピックです。
これは誰の clock ですか?
timing report が読みにくくなる原因の 1 つは、 clocksの名前です。 logic design 内の clock signals のほとんどは PLLによって作成されており、 timing report に表示される名前が役に立たない可能性があることはすでに説明しました。ほとんどの FPGA tools では、 SDC ファイルにコマンドを追加することで clock objects の名前を変更できますが、ほとんどのプロジェクトではこれが行われません。そして、黄金律 #4は、プロジェクトに特有のものを控えることです。
clock のソースが IP block (例えば Gigabit transceiver、 PCIe block または on-chip processor core) である場合、名前の問題はさらに難しくなります。この場合、 clock の名前は、多くの場合、それがどこから来たのか、何に関連しているのかについてほとんど語っていません。
では、この問題はどのように解決されるのでしょうか? まず、 clockの名前が、独自の SDC ファイル内の create_clock command から取得されるという最も単純な状況から始めましょう。これは、再び同じ timing constraint です。
create_clock -period 4 -name clk [get_ports clk]
この command の最後の部分は「[get_ports clk]」です。 Tcl 言語では、角括弧は括弧の内容を Tcl commandとして実行し、この command の結果をこれらの括弧の代わりに使用することを意味します。
get_ports command は、「clk」という名前の I/O port を見つけます。この command の結果は、この portを表す object です。したがって、上記の create_clock command では、この object はこの commandの argument です。このようにして、 create_clock は clock object と実際の signalを結び付けます。
port の名前と object の名前は両方とも「clk」であることに注意してください。これらが同じである必要はありませんが、同じにすることをお勧めします。 objectの名前は timing reportsに表示されます。したがって、通常は port の名前が最適です。
signalの識別子として net objects と pin objects を使用することもできます。これは、 IP blocksに代わって自動的に生成される timing constraints で一般的です。ただし、自分の constraintsでこれを行う必要があると感じた場合は、何か間違ったことをしている可能性が高くなります。
したがって、 SDC ファイルで create_clock command が使用された場合、 clock object がどの signal に関連しているかは簡単にわかります。しかし、ツールによって自動的に作成された clock objects はどうでしょうか。
この場合、 clock を認識する最善の方法は、 timing reportを見ることです。たとえば、前のページの例の @pll_clk_8 に関連する clock object はどれですか?確認する簡単な方法は、 timing reportで text search を実行することです。そこで「pll_clk_8」で検索すると、以下の部分が見つかりました。
Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
-------------------------------------------------------------- -------------------
(clock clk_out1_clk_wiz_1 rise edge)
16.000 16.000
AG12 0.000 16.000 clk (IN)
net (fo=0) 0.000 16.000 pll_i/inst/clkin1_ibuf/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.738 16.738 pll_i/inst/clkin1_ibuf/INBUF_INST/O
net (fo=1, routed) 0.105 16.843 pll_i/inst/clkin1_ibuf/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.049 16.892 pll_i/inst/clkin1_ibuf/IBUFCTRL_INST/O
net (fo=1, routed) 0.975 17.867 pll_i/inst/clk_in1_clk_wiz_1
MMCME3_ADV_X1Y0 MMCME3_ADV (Prop_MMCME3_ADV_CLKIN1_CLKOUT0)
-4.438 13.429 pll_i/inst/mmcme3_adv_inst/CLKOUT0
net (fo=1, routed) 0.501 13.930 pll_i/inst/clk_out1_clk_wiz_1
BUFGCE_X1Y1 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.101 14.031 pll_i/inst/clkout1_buf/O
X2Y0 (CLOCK_ROOT) net (fo=1, routed) 1.369 15.400 pll_clk_8
SLICE_X49Y58 FDRE foo_reg_reg/C
これは clk_out1_clk_wiz_1の Source Clock Path であり、質問に対する答えがあります。
もう 1 つの方法は、 Tcl commandを使用して情報を取得することです。これを行う方法は、 FPGA tool ごとに異なります。 Vivadoでは、 Implemented Designを開いた後、次のような command を使用できます。
> get_clocks -of_objects [ get_nets pll_clk_8 ] clk_out1_clk_wiz_1
この方法では、 netの名前を知っている必要があります。この例のように簡単な場合もありますが、この netの名前を見つける必要がある場合もあります。 FPGA tools では通常、 GUIを使用してこれを行う方法を提供しています。この目的で Tcl commands を使用することもできます。
実際、 Tcl を使ったいくつかの例で、 Tcl を適切に扱う方法を知ることの重要性を理解していただけたでしょうか。それが次のページです。
get_portを使う意義
上記の例では、 create_clock command は get_port を利用して clock object と物理 input pin間の接続を確立します。前述のように、この接続は、どの logic elements がこの clock (またはそこから生成された clocks ) に接続されているかを知るために必要です。
しかし、 get_port を使用することが唯一の可能性ではありません。たとえば、 global clock bufferの output pin を参照することもできます。このようなもの：
create_clock -name clk -period 4 [get_pins my_BUFG_inst/O]
違いは、ツールが global clock bufferの output pin を clockの起源と見なすことです。つまり、 clock pathsの計算はこの位置から始まります。この原点での最初の clock edge は 0 nsで発生するため、この output pin が時間基準になります。
これは合法的な timing constraintですが、2 つの重要な欠点があります。
- 他のすべての clocksに関して、この clock をunrelated clockと見なすようにツールを要求する必要があります。これは、同じ PLLで生成された clocks にも当てはまります。その理由は、ツールが output pin を時間基準と見なすためです。したがって、 clock path delays に関する clocks 間の違いに対する補償はありません (つまり、 clock skews は考慮されません)。
- FPGAの外部に表示される clock に関連するI/O timing constraintsを定義することは不可能 (または非常に困難) です。これは、そのような constraints が時間基準として clock object に依存しているためです。しかし、繰り返しになりますが、時間基準は global clock bufferの output pinです。外部 clock から global clock buffer への clock skew は不明です (たとえば、温度によって変化します)。
したがって、可能な場合は常に get_port を使用する必要があります。それ以外の場合、 clockの timing は、それ自体以外は不明であると見なされます。
このページでは、 Tcl commands が多数紹介されましたが、十分な説明がありませんでした。次のページでそのギャップを埋めます。