Vivadoのサンプルデザインの使用方法
開発中の1GADCで、JESD204Bの初期化シーケンス(ILAS)の読み出しに成功しました。
4つのGTPのチャネルで以下のような情報になっていました。
GTP0: 7C 1C 9C 00 00 03 07 01 08 01 0D 2F 23 00 00 00 35 00 7C
GTP1: 7C 1C 9C 00 00 02 07 01 08 01 0D 2F 23 00 00 00 34 00 7C
GTP2: 7C 1C 9C 00 00 00 07 01 08 01 0D 2F 23 00 00 00 32 00 7C
GTP3: 7C 1C 9C 00 00 01 07 01 08 01 0D 2F 23 00 00 00 33 00 7C
注目すべき点は0Dというところです。これはADCの分解能を示します。10進数で13ですが、+1されて14bitということになるのですが、ADS54J60は16bitのADCのはずです。
ADS54J60の下位2bitはサブADCのキャリブレーションに使われているので、ジャンクなデータしか出てきません。したがって、14bitの性能しかもっていないのですが、その意味で14bitを示しているのかもしれません。
さて、このようなGTPの回路をどうやって作ったかということですが、GTPやGTXはリセット信号がたくさんあって、その順序などを守らないとうまく動いてくれませんでした。
ですが、最近のVivadoで作ったコアには、どうやらちょっとだけ簡単にしてくれる仕掛けがあるようなのです。
GTPのコアを作る際に、Include Shared Logic in example designにチェックを入れ、次のページでProtocolをJESD204に選びます。
確信は持てませんが、おそらくOpen IP Example Designをして、
次のダイアログで、サンプルが展開されるディレクトリを指定します。
すると、そのディレクトリにVivadoのサンプルデザインのプロジェクトが生成されるというようです。
このプロジェクトのトップデザインファイルは、gtwizard_0_ex.srcs\sources_1\imports\example_designの中にあるgtwizard_0_exdes.vhdというファイルなのですが、これの内容を注意深く自分のプロジェクトにコピペしてきます。
gtwizard_0_exdes.vhdがトップで、その下にgtwizard_0_support.vhdというファイルがあります。gtwizard_0_support.vhdはリセット信号などをいろいろやってくれるもののようです。
気になる点としては、soft_resetという信号がすべて'0'に固定されていてリセットを使っていない点でした。コードを読んでいくうちに、どうやらリセット信号をユーザが動かす必要はないことがわかりました。
port map ( soft_reset_tx_in => soft_reset_i, soft_reset_rx_in => soft_reset_i, DONT_RESET_ON_DATA_ERROR_IN => tied_to_ground_i, Q0_CLK1_GTREFCLK_PAD_N_IN => Q0_CLK1_GTREFCLK_PAD_N_IN, Q0_CLK1_GTREFCLK_PAD_P_IN => Q0_CLK1_GTREFCLK_PAD_P_IN, GT0_DATA_VALID_IN => gt0_track_data_i, GT1_DATA_VALID_IN => gt1_track_data_i, GT2_DATA_VALID_IN => gt2_track_data_i, GT3_DATA_VALID_IN => gt3_track_data_i,
というポートがあるのですが、
DONT_RESET_ON_DATA_ERROR_IN => tied_to_ground_i,
となっていて、GNDに固定されていることがわかります。この信号がLだと、データエラーのときにリセットしないことをしないので、つまりデータがエラーのときにリセットがかかるようになるようです。
そして、GT0_DATA_VALID_IN～GT3_DATA_VALID_INという信号がLならばエラーが発生していることを示すようです。これらの信号をL→Hと動かせばリセットがかかります。
前置きが長くなりましたが、Vivadoのexampleプロジェクトを使えば受信回路は自然に正しくリセットがかかるようです。
なお、GT0_DATA_VALID_INなどに与えられるgt0_track_data_iという信号は、gtwizard_0_GT_FRAME_CHECKというモジュールで作られています。これは、JESD204のフレームをチェックして、正しいかどうかを判断してくれるものなのでしょう。
ただ、フレームチェックモジュールの詳しい動作はわからいので、私はこれを使わずにJTAG経由でDATA_VALIDをH/Lできるようにしています。
さて、逆に、自分でRESETやUSERRDYを動かそうとしても、うまくリセットがかかりませんでした。
そこで、サンプルデザインを解読してみたのですが、奥のほうにあるgtwizard_0_init.vhdの中で、以下のような処理をしていました。
chipscope : if EXAMPLE_USE_CHIPSCOPE = 1 generate gt0_gttxreset_i <= GT0_GTTXRESET_IN or gt_gttxreset_t; gt0_gtrxreset_i <= GT0_GTRXRESET_IN or gt_gtrxreset_t; gt0_txuserrdy_i <= GT0_TXUSERRDY_IN and gt_txuserrdy_t; gt0_rxuserrdy_i <= GT0_RXUSERRDY_IN and gt_rxuserrdy_t; gt1_gttxreset_i <= GT1_GTTXRESET_IN or gt_gttxreset_t; gt1_gtrxreset_i <= GT1_GTRXRESET_IN or gt_gtrxreset_t; gt1_txuserrdy_i <= GT1_TXUSERRDY_IN and gt_txuserrdy_t; gt1_rxuserrdy_i <= GT1_RXUSERRDY_IN and gt_rxuserrdy_t; gt2_gttxreset_i <= GT2_GTTXRESET_IN or gt_gttxreset_t; gt2_gtrxreset_i <= GT2_GTRXRESET_IN or gt_gtrxreset_t; gt2_txuserrdy_i <= GT2_TXUSERRDY_IN and gt_txuserrdy_t; gt2_rxuserrdy_i <= GT2_RXUSERRDY_IN and gt_rxuserrdy_t; gt3_gttxreset_i <= GT3_GTTXRESET_IN or gt_gttxreset_t; gt3_gtrxreset_i <= GT3_GTRXRESET_IN or gt_gtrxreset_t; gt3_txuserrdy_i <= GT3_TXUSERRDY_IN and gt_txuserrdy_t; gt3_rxuserrdy_i <= GT3_RXUSERRDY_IN and gt_rxuserrdy_t; end generate chipscope; no_chipscope : if EXAMPLE_USE_CHIPSCOPE = 0 generate gt0_gttxreset_i <= gt_gttxreset_t; gt0_gtrxreset_i <= gt_gtrxreset_t; gt0_txuserrdy_i <= gt_txuserrdy_t; gt0_rxuserrdy_i <= gt_rxuserrdy_t; gt1_gttxreset_i <= gt_gttxreset_t; gt1_gtrxreset_i <= gt_gtrxreset_t; gt1_txuserrdy_i <= gt_txuserrdy_t; gt1_rxuserrdy_i <= gt_rxuserrdy_t; gt2_gttxreset_i <= gt_gttxreset_t; gt2_gtrxreset_i <= gt_gtrxreset_t; gt2_txuserrdy_i <= gt_txuserrdy_t; gt2_rxuserrdy_i <= gt_rxuserrdy_t; gt3_gttxreset_i <= gt_gttxreset_t; gt3_gtrxreset_i <= gt_gtrxreset_t; gt3_txuserrdy_i <= gt_txuserrdy_t; gt3_rxuserrdy_i <= gt_rxuserrdy_t; end generate no_chipscope;
なんと、ユーザが与えたuserrdy信号やtxreset、rxresetはCHIPSCOPEを使わない状態では無効になっているようです。そして、代わりに_tが付いた信号が使われていました。
この_tがついたgt_txuserrdy_tはgtwizard_0_TX_STARTUP_FSMというモジュールで作られているようで、
gt_txresetfsm_i: gtwizard_0_TX_STARTUP_FSM generic map( EXAMPLE_SIMULATION => EXAMPLE_SIMULATION, STABLE_CLOCK_PERIOD => STABLE_CLOCK_PERIOD, -- Period of the stable clock driving this state-machine, unit is [ns] RETRY_COUNTER_BITWIDTH => 8, TX_PLL0_USED => TRUE , -- the TX and RX Reset FSMs must RX_PLL0_USED => TRUE, -- share these two generic values PHASE_ALIGNMENT_MANUAL => FALSE -- Decision if a manual phase-alignment is necessary or the automatic -- is enough. For single-lane applications the automatic alignment is -- sufficient ) port map ( STABLE_CLOCK => SYSCLK_IN, TXSYSCLKSEL => GT0_TXSYSCLKSEL_IN, TXUSERCLK => GT0_TXUSRCLK_IN, SOFT_RESET => SOFT_RESET_TX_IN, PLL0REFCLKLOST => tied_to_ground_i, PLL0LOCK => gt_pll0lock_i, PLL1REFCLKLOST => tied_to_ground_i, PLL1LOCK => gt_pll1lock_i, TXRESETDONE => gt_txresetdone_i, MMCM_LOCK => tied_to_vcc_i, GTTXRESET => gt_gttxreset_t, MMCM_RESET => open, PLL0_RESET => gt_tx_pll0reset_t, PLL1_RESET => gt_tx_pll1reset_t, TX_FSM_RESET_DONE => GT_TX_FSM_RESET_DONE_OUT, TXUSERRDY => gt_txuserrdy_t, RUN_PHALIGNMENT => open, RESET_PHALIGNMENT => open, PHALIGNMENT_DONE => tied_to_vcc_i, RETRY_COUNTER => open );
と、ユーザからのuserrdy信号ではなく、内部でPLLのロックなどから作ったタイミングで作られているようです。
結論をまとめると、
- Vivadoのexample designを使う場合、JESD204のトランシーバの受信回路は、リセット信号は自動生成されたサンプルデザインにお任せすべき。
- ユーザはgtwizard_0_exdes.vhdの内容を注意深くコピペしながら、サンプルデザインを自分の回路に取り込む。
- resetやuserrdyを自分で操作する必要はない。（おそらく操作しても無視される）
- DATA_VALID信号をL→Hにすると、受信回路にリセットがかかって、よろしくやってくれる。
ということのようです。
もうデータシート見ながらリセットの順番を考えなくてもよさそうです。ゆとりなサンプルデザインになりました。
| 固定リンク
コメント