fpga(跡地)

[QuartusII] WEB editionでJTAGクロックにremoval error

前回，[QuartusII] TimeQuestのaltera_reserved_tckのremoval errorということで，長船さんにコメントをいただいた件を検証してみた．
タイトルに答えを書いている気がしないでもないが...(汗;

Subscription Licenseが有効な場合

各種IPもライセンスvalidateされている状態なので，JTAG接続の必要は無い．
結果としては，SRからの回答もあったように，removal timing errorの発生も無い．
むしろ，altera_reserved_tckがclockとしてリストアップされない．Technology MapViewerにて，PostMapping後の該当回路周辺を見てみると，以下のようになっていた．

なんかaltera_internal_jtagのポートが記憶と異なる...

Subscription Licenseが無効な場合（WEB edition）

いわゆるWEB editionでも見てみた．

どうだろうか．赤枠で囲った３つのポートが増えていることがわかるだろう．

• SHIFTUSER
• CLKDRUSER
• UPDATEUSER

timing errorを出していたのはこの余計な信号生成とかが絡んでいるせいと思われる．また，発生する条件も，これら追加された信号のあたりと推定するため，通常動作中には悪影響はなく，JTAG切断時やtime out時にタイミング違反となる可能性があるのかもしれない．

したがって，本件は問題ナシとしてcloseする．

この辺りを見てしまうと，NiosIIライセンスなしでQuartus II/SOPC Builderを使い続けるのは，色々とライセンス問題で泣かされそうな予感がしてくる．

評価に影響がないように... と考えるとあれか，30日の機能評価版を使えということか．WEBで情報が少ない理由はココにあるのかもしれないな...

儂はどう動くべきなんだろうかな．

Nios IIコアを捨てて，テキトウなCPUコアを持ってくるのも一つだろう．SOPC BuilderのGUIは捨てるのが惜しいので，Avalonシステムは継承したいところだな...

とりあえずもう少し何かカタチができるまでは続けよう...

いただいたIPを使ってファイルアクセスを試したいところですが，中間フォロー資料を先に作らせていただきたく．今週中には第一報を出します．*1

altera_reserved_tckのremoval error

Nios IIのCPUコアを使ったときの話．
いつものようにWarningが大量に出てきているので，自動生成ファイルを含めて中身を眺めていた．ふと，cpu.sdcを見るとこのようなコメントが見つかる．

#**************************************************************
# Timequest JTAG clock definition
#   Uncommenting the following lines will define the JTAG
#   clock in TimeQuest Timing Analyzer
#**************************************************************

確かに，clockが１つだけunconstraintになっていた．これのせいですな．
で，これをコメントインするとですね，表題の問題にぶちあたるわけです．

※画像は"新規ウィンドウで開く"を推奨

前提条件

折角会社で(ryServiveRquestで問い合わせて見ていますが，未解決．アドバイスをいただいたのもコミで，とりあえず下記の設定で試しています．

cpu.sdc

以下をコメントインする．

create_clock -period 10MHz {altera_reserved_tck}
set_clock_groups -asynchronous -group {altera_reserved_tck}

そして，以下の一行をgenerated clockも制約に追加（SRにより追記OK）

set_clock_groups -asynchronous -group {altera_internal_jtag|tckutap}

setting

Project右クリック→settingを開く．で，hold timingを保障するように頑張ってくれるらしい．

結果

Quartus II WEB editionを使うと，こうなった．家と会社の自前PCと師のPCでも同様．

コレに対して，同じプロジェクトを送付してあるのだけれど，errorはでないというコメントであった．
とりあえず，サブスクリブ版でも試してみようかと思う．試してもらう，が正解か(縛

申し訳ないが，コレの確認ができるまではcloseできない...？

デフォルトでコメントアウトされていたので，無視していたのだけれど，特に問題なく動いてそうなんですよね．JTAG-UARTが入ってるとまずいかと思ってみたりもしたのだけれど，抜いても同じだった．
QuartusIIがFitting（配置配線）を諦めたと考えるべきなのだろうか．そのわりにはそんなWarningらしきものは出てないようだしなぁ．この手のTipsてどこかに落ちてないのだろうか...

Warningゼロは不可能に近いことは承知しているが，SOPC Builderだけでペタペタ作ってこれだけWarningが出てくるのも怖いわけですよ．HDL真面目に触りだして短いのもあるけれど，CでいうならばWarningの理由を全て把握した上でないと，安心して出荷できないじゃないですか．

PerlでHDL記述を自動生成したりしているようだけれど，Verilogのビット幅指定を端折っていたりする．これでもWarningは出てくるのだけれど，こういう感じで理解しているものは無視できる．しかし，Timing errorを無視するわけにはいかないだろう…．

妄想～要因の追求

ちなみに．
今回の発生箇所周辺をTechnology Map Viewer(Post-Fitting)で覗いてみた．エラー発生箇所は，外部からのJTAG信号を，ALTERAが開示していないIP（TAP controllerかな？）を介した後の信号で発生しているように見える．

removal timing errorの絵も理解できないので，それも問題なわけだが．hold time相当という理解なのだけれど，図示させてみるとこんな感じ．

launch edge/latch edgeともに，altera_reserved_tckなのだけれど，slack計算がわからん．
Data Arrival Pathが，非同期クリアに入っているので，Data Required Pathが入るときにhold timeが必要ということなのですよね．

tckのクロックは100nSec（10MHz）としているのだが，この8.808nSecというのは，非同期クリアのためのhold timeというわけか．
で，altera_internal_jtagの中身が全く見えないのが問題を切り分けられない要因．たしかにtckが入ってきているが，updateuser信号へも伝播しているのか．遅延時間が出ているからこのとおりか...だとすると，この部分の非同期リセットは保障されないということでF.A.？

では，何故Quartus IIは頑張ってFittingしようとしてくれないのか．つーか，制約満たせなくてもエラーで止まらないのか．

という感じで，ひきずりつつ今週終了＼(^o^)／

[Altera][SOPC][Q2HB] システムリセットについて

シミュレーション実施時に不定値が伝播したと書きましたが，SOPC上でのIPコアの設定が一部まずかったのが要因のようです．
結論に至る前に，そもそもPLLが安定するまでの間はどうなっているのかという疑問を払拭するために調べてみました．

そのメモをここに掲載しておきます．

前回の記事で注目していたのは，SOPC上でインスタンス化した，PLLとDDRSDRAM(HP)コントローラでした．それぞれについて確認しましょう．

PLL

資料の読み取りは，[Q2HB]PLLを参照ください．
仕様書にSOPC全域にリセット要求を発します，と明記してありました．

DDRSDRAM(HP)

DDRSDRAM(HP)のreset_request_n信号をどのように処理しているかを確認する．SOPC Builderが作ったファイルを開いて，DDR moduleのインスタンス化コードを参照し，そこから当該信号がどのnetにぶら下がっているかを確認する．

ddrsdram_s1_arbitratorに入力されているだけだったので，該当モジュールを見る．

module ddrsdram_s1_arbitrator (
  input            ddrsdram_s1_resetrequest_n;
  output           ddrsdram_s1_resetrequest_n_from_sa;
  wire             ddrsdram_s1_resetrequest_n_from_sa;
  //assign ddrsdram_s1_resetrequest_n_from_sa = ddrsdram_s1_resetrequest_n
  // so that symbol knows where to group signals which may go to master only, which is an e_assign
  assign ddrsdram_s1_resetrequest_n_from_sa = ddrsdram_s1_resetrequest_n;

ddrsdram_s1_resetrequest_n_from_saへ常時代入されていることがわかる．インスタンス化しているところに戻ると，この出力信号を束ねているところがある．

  //reset sources mux, which is an e_mux
  assign reset_n_sources = ~(~reset_n |
    0 |
    0 |
    cpu_jtag_debug_module_resetrequest_from_sa |
    cpu_jtag_debug_module_resetrequest_from_sa |
    0 |
    ~ddrsdram_s1_resetrequest_n_from_sa |
    ~ddrsdram_s1_resetrequest_n_from_sa |
    0 |
    pll0_s1_resetrequest_from_sa |
    pll0_s1_resetrequest_from_sa);

reset_n_sourcesが，システム全体のリセット要求が無いことを確認する信号になっている模様（未検証）．

  //reset is asserted asynchronously and deasserted synchronously
  Nios2_NoDDR_reset_SysClk_domain_synch_module Nios2_NoDDR_reset_SysClk_domain_synch
    (
      .clk      (SysClk),
      .data_in  (1'b1),
      .data_out (SysClk_reset_n),
      .reset_n  (reset_n_sources)
    );

  //reset is asserted asynchronously and deasserted synchronously
  Nios2_NoDDR_reset_osc_clk_domain_synch_module Nios2_NoDDR_reset_osc_clk_domain_synch
    (
      .clk      (osc_clk),
      .data_in  (1'b1),
      .data_out (osc_clk_reset_n),
      .reset_n  (reset_n_sources)
    );

osc_clk（FPGA外部からの唯一のクロック）を用いて，非同期リセット＋同期リセット解除の信号SysClk_reset_n・osc_clk_reset_nを生成する．clock domainが複数存在するが，それぞれで同期化して出力している．
このリセット信号を誰が使っているのかを見ていくと...

  ddrsdram the_ddrsdram (
      .soft_reset_n      (osc_clk_reset_n)

  pll0_s1_arbitrator the_pll0_s1
      .reset_n                                           (osc_clk_reset_n)

  Nios2_NoDDR_clock_0_out_arbitrator the_Nios2_NoDDR_clock_0_out
      .reset_n                                           (osc_clk_reset_n)

ということで，各IPのリセット要求が解除されるまではシステムが停止する仕様になっています．DDR-SDRAMについては，PLL安定するまではリセット要求を出します．また，PLLのリセットを行わない，PHYだけのリセット要求入力に，同期化したシステムリセット要求信号が入ります．リセット解除の同期化は，どちらが先になるのかわからないので，厳密には一番遅い周期にあわせたウェイトを入れてやる必要があるのかもしれません．FIFOにリクエストを積み上げるのであれば，リセットタイミングが多少ずれても，Power on reset直後の値さえ合致していれば，レイテンシが少しかさむだけで問題なく動くでしょう．

結論

仕様解釈

IP側でPLL発振安定までの間に不定値が伝播するような問題はない．
→PLL lock待ちの回路も自作は不要．

ただし，ALTPLLの"locked"信号を出力する設定にしておくことが必要!!そのほか，ResetRequest信号が出ているIPについては，その出力を有効にしておく必要があるでしょう（未確認）．

シミュレーション実施時に不定値が伝播した問題について

シミュレーション実施時には，PLL側の"locked"信号を出していなかったので，システムリセットがネゲートされていたと考えられます．*1

正しく？設定をすると，問題なくModelSIM WEB editionでFunction Simulationの実行ができました．

[SOPC] Model-Simによるシミュレーション

設定～ModelSimのライセンス

最初のインストールでQuartusIIしか入れていなかったため，ModelSim AlteraEditionを入れる．ライセンスが無いといわれたので，その追加方法についてメモを残しておく．

SOPC Builderにて，[System Generation]タブのOptionグループの"Simulation. Create project simulator files."をcheckする．

1. "Run Simulator"を押下するとModelSimが起動する模様．

（ModelSimのインストール，ライセンスの取得は必須である．）

QuartusIIの，メニュー"Tool"→ "License Setup.." → "WebLicense Update"ボタンを押下すると，ALTERAのサイトに接続しにいきます．ALTERA WEB SITEのアカウントを取得しておき，LOGINします．
ユーザ情報を確認した後に，"ModelSim WEB edition"のライセンスも必要か問うているチェックボックスがあるので，忘れずにチェックを入れておきます．ライセンスファイルはメールで送られてきますので，コレを任意のフォルダに保存して，LM license managerがそれを参照するように設定します．
ユーザによっては，すでにxilinxやLM license managerを使用する製品を利用されているかもしれません．

マイコンピュータ→（右クリック）→ property → "詳細徹底"タブ → "環境変数"ボタン → ユーザの環境変数またはシステム環境変数
ここを参照して，下記の変数の値を修正します．存在しなければ新規に作成します．
QuartusIIに限れば，Option Dialogにて，"Use LM_LICENSE_FILE"の指定ができるチェックボックスが存在します．
ModelSimにはソレが無いため，環境変数の設定が必須となります．
ライセンスファイルが存在しない場合は，ここで記すような解決策の定時をダイアログで受けることになるでしょう．

環境変数

MGLS_LICENSE_FILE
LM_LICENSE_FILE

複数のファイルや，ライセンスサーバ（@）を参照する場合は，セミコロン';'で区切ります．

設定が正しくできているかどうかは，スタートメニューからたどって，"ModelSim-Altera 6.3g_p1 (Quartus II 8.1)"を実行します．
コマンド待ち受け画面（"transcript"）が出てくるので，ここで"lmutil lmdiag"と入力します．出力例を以下に示します．（IPやNETBIOS名を'x'で塗り替えています）

>lmutil lmdiag

# 
# This license can be checked out
# -----------------------------------------------------
# 
# Enter <CR> to continue: "adwu" v1.31, vendor: armlmd
#   License server: xxxxxxxx
#   floating license no expiration date
# 
#   Requests from the same USER/HOST/DISPLAY do not consume a new license
# 
# This license can be checked out
# -----------------------------------------------------
# -----------------------------------------------------
# License file: 8224@xxxxxxxx
# -----------------------------------------------------
# -----------------------------------------------------
# License file: C:\altera\xxxxxxxxxxxx__0-xxxx3015308023.dat
# -----------------------------------------------------
# "quartus_lite" v2009.05, vendor: alterad
#   uncounted nodelocked license, locked to ethernet address "xxxxxxxxxxxx"  expires: 15-may-2009
# 
# This is the correct node for this node-locked license
# -----------------------------------------------------
# 
# Enter <CR> to continue: "alteramtiwe" v2009.05, vendor: mgcld
#   uncounted nodelocked license, locked to ethernet address "xxxxxxxxxxxx"  starts: 9-dec-2008,   expires: 15-may-2009
# 
# This is the correct node for this node-locked license
# -----------------------------------------------------
# -----------------------------------------------------
# License file: C:\altera\xxxxxxxxxxxx__0-xxxx42759966265.dat
# -----------------------------------------------------
# "quartus_lite" v2008.12, vendor: alterad
#   uncounted nodelocked license, locked to ethernet address "xxxxxxxxxxxx"  expires: 15-dec-2008
# 
# This is the correct node for this node-locked license
# -----------------------------------------------------

この例では，旧ファイルも残っているようで，複数のライセンスが見て取れます．
一部ライセンスサーバからも取得してきており，ADSのライセンスも見受けられます．（各種ツールの名称が並びますが，個々では無関係なので省略しました．）
ModelSimのライセンスは，"alteramtiwe"であると考えられます．QuartusIIは"quartus_lite"でしょう．これらの文字列が見えない，または，"License file: "で，取得したライセンスファイル名がない場合は，どこかの設定が誤っているか，設定終了後にアプリを起動していないのかもしれません．

[SOPC][ModelSim] 不定値伝播

気持ちよくシミュレーションを実行すると，不定値が伝播しており，testbenchモジュールで $stopコマンドが発令された．cpu coreのあたりで，ddr_sdramからの信号のようだ．タイミングはreset_nがネゲートされたあたりで，PLL unlock状態なのが問題のように思える．

現状は，system clockとddrclockの２系統があり，これらの安定化を待つようなシステムになっているのかは不明である．少なくともシミュレーションで不定値が伝播してきているので，下記のいずれかの問題が生じていると考えられる．

• 自動生成されるテストベンチが不正
• PLL lock状態までシステムをとめるような仕組みが存在しない\これはこれで問題な気がする．どこかのサンプルでPLLをSOPCからはずしていた理由はコレか...
• シミュレーション実行において手順が抜け落ちている？\ALTERAセミナ資料どおりにやってるはず...

実機＋JTAGがぶら下がっている状態では動いているので，PLL安定後は正常動作する模様です．
初期起動時の不安定性がシミュレーションにより予見されたということでしょうかね．

妄想レベルでの対策は，すべてのPLL出力が安定（lock信号がアサートされるまで）は，NiosIIシステム全体をリセット状態にしておくことですね．SOPC builderにより生成されたモジュールへのリセット信号が，本当の全域リセットと，PLLブロックへ入っている?リセットと区別されていることが条件になりますねぇ．もしくはPLLブロックをSOPC Builderから離して生成するか．そうなるとdynamicなclock制御ができなくなるか．
そんなことするのは当面先のことになるし，clock domain境界の処理をどうすべきかを検討する必要がありますが．クロック・モジュールリセットの集中管理が必須となってくるでしょうねぇ．そんなことできるかな...