とんずら雑記R

■[雑] 年末

ビッグサイトロンでのサークル参加を止めて久しいですが，この冬は帝都にも向かいません...
少々私用で忙しかったのと，現状のタスクで手一杯なので，これ以上ネタを仕入れないようにしたかったてのもあります(笑

■[QuartusII]

さておき，先日のFatFsの件，NEEKに持ってきて，サンプルプログラムも持ってきてみたのだけれど，SD初期化処理をミスします（Idleへの遷移要求に対してOK返ってこない）．
SDの端子に出ている波形を観測していないので，どこまでが正しいのかも不明瞭です．シミュレーションしようにもVHDLという罠が(笑．VerilogHDLに移植しようと誓ったところで止まっています..

借り物だけに勝手にハンダを盛るのも申し訳ないですしネ☆

そして周りの年末大掃除の話題に吊られて，PC部屋の片付けに着手してしまいました．数ヶ月で取り込みたい書類もそれなりに増えるもんですなぁ．保管書類もゴタゴタになっているので，一度本腰を入れてファイリングしてタグを打ってしまおうと思います．部品在庫リストは... ある程度進んで，コーナン箱１つちょっとと工作机まわりの部品が残といったところですね．

作業時間にすると結構なボリュームだと認識しております...ということで，実家への帰省も考慮すると，年内にFatFs動いたーってのはなさそうです．申し訳ございません...

年末の挨拶には少し早いので，また後日...

■[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の実行ができました．