2008/12/22(月)[QuartusII] WEB editionでJTAGクロックにremoval error

[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後の該当回路周辺を見てみると,以下のようになっていた.

Q2_TMV_01.png

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


Subscription Licenseが無効な場合(WEB edition)

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

Q2_TMV_02.png

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

  • 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

*1 : 期限切るのがお約束.でも,守れない期限を吐き捨てるのは見積もり誤り.

2008/12/20(土)[QuartusII] TimeQuestのaltera_reserved_tckのremoval error

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が1つだけ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を保障するように頑張ってくれるらしい.

Q2_Set_FS_cfg.png

結果

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

Q2_TQ_removal_err.png

コレに対して,同じプロジェクトを送付してあるのだけれど,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相当という理解なのだけれど,図示させてみるとこんな感じ.

TQ_removal_err.png

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^)/

[Q2HB] SPI Core

[Altera][Q2HB][IP] SPI Core

refer to:"Volume 5: Embedded Peripherals","Section I. Off-Chip Interface Peripherals","7. SPI Core"

Core Overview

(略)SPIインタフェースは,よう使われている.SPI core with Avalon-interfaceは,SPIプロトコルを実装し,バックエンドでAvalon-MMインタフェースを提供する.

SPI coreは,SPIマスタかSPIスレーブのどちらかを実装できる.マスタとして設定したときは,SPI coreは32個までの独立したSPIスレーブを制御できる.送受信のレジスタ幅は,1~32ビットの間で設定可能です.より長い転送長はソフトルーチンでサポートされます.SPI coreは,転送が完了するごとにフラグする割込み出力を提供します.



Functional Description

SPI coreは以下の信号で同期通信を行います(SPIプロトコル)

Signal symbol description
Master Out Slave Inmosiマスタからのデータ出力,スレーブへのデータ入力
Master In Slave Outmisoスレーブからのデータ出力,マスタへのデータ入力
Serial Clocksclkマスタに駆動される,スレーブへのクロック.データビットの同期に使う
Slave Selectss_nマスタに駆動される,個別のスレーブへのSelect信号(active Low).対象となるスレーブを選択するのに使う

このコアには,ユーザに見える柿のリソースがあります.

  • MemoryMapped register\rxdata, txdata,status, control, slaveselect
  • 4つのSPIインタフェースポート\sclk, ss_n, mosi, and miso

Instantiating the SPI Core in SOPC Builder

(なんともはやふつー過ぎて省略)


Software Programming Model

alt_avalon_spi_command()

int alt_avalon_spi_command(
	alt_u32 base, alt_u32 slave,
	alt_u32 write_length,
	const alt_u8* wdata,
	alt_u32 read_length,
	alt_u8* read_data,
	alt_u32 flags)

データ長8bit以下のSPIマスタ向けに設計されている.現状,データ長8bit以上のハードには対応していない.
この関数を一度呼ぶと,MOSIからデータを吐いて,MISOからデータを受け取ります.

  1. slaveの指定されたslave chipselect信号をアサートします.IDはゼロオリジンです.
  2. write_lengthバイトだけwdataから読み出して出力します.MISOからのデータは捨てます.
  3. read_lengthバイトだけ,read_dataへデータを格納します.MOSIにはゼロを吐き続けます.
  4. スレーブのselect信号をデアサートします.

コードは,以下のファイルを見ると把握できます.リード時の吐き捨てがマスタ出力ゼロで決めうちですね.
C:\altera\81\ip\altera\sopc_builder_ip\altera_avalon_spi\HAL\src\altera_avalon_spi.c

※SDカードへのアクセスの際には,1'b1での出力が必要と思う(ELMより...SD Spec.見たほうがいいか?)



問題点

SPIマスタのとき,動作クロックをWizardで定義することになるが,動的な変更が効かない
(ELM) MMCの使い方 より,

SPIモードの場合は、速度を制限する状態(OD駆動)が無いので、クロック切り替えなしで最初から20/25MHzでもOKです。

20MHz固定でもいいか...


SDカードをSPIモードで使うときの結論

IPコアは流用できるが,HAL・ドライバは使用できない.自前で制御レジスタをたたくべし.ソースコードの流用はできるだろう(あまりおいしく無いけれど)
→ よそのIPを拾ってこよう….

2008/12/15(月)[SOPC] システムリセットについて

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

*1 : DDR側のreset requestが入ってきていてもおかしくは無いのだが..

[Q2HB] Performance Counter Core

[Altera][Q2HB][IP] Performance Counter Core

refer to:"Volume 5: Embedded Peripherals","Section V. Test and Debug Peripherals", "29. Performance Counter Core"

注意
performance counterは,複数clockを使用するシステム上では,CPU clockと同じdomainに配置すること.異なる場合はサイクル数から実時間へ正しく変換できない.(p.2453 "Multiple Clock Domain Considerations")

Core Overview

高精度パフォーマンスカウンタを提供するらしい.GNU profiler, gprofでも使得る模様.通常のInterval timerを利用することも可能.
3種類の測定方法については,"AN 391: Profiling Nios II Systems."にて述べる.

機能としては,クロックサイクルの計数と,イベント回数の記録である.それぞれ64bit/32bit精度を有す.


Software Programming Model

便利なマクロや関数が用意されている.カウンタの初期化,開始,停止,測定対象セクションの開始・終了を行う.測定結果についても,テキストベースで表を出力する関数を用意してある.

パフォーマンスカウンタの名称を"performance counter"とした場合で,section counterは1番目を用いる例である.

    PERF_RESET( PERFORMANCE_COUNTER_BASE );
    PERF_START_MEASURING( PERFORMANCE_COUNTER_BASE );
    PERF_BEGIN( PERFORMANCE_COUNTER_BASE, 1);
	// 測定対象となる処理 //
    PERF_END(PERFORMANCE_COUNTER_BASE, 1);
    PERF_STOP_MEASURING(PERFORMANCE_COUNTER_BASE) ;
    printf("%qu cycle \n", perf_get_section_time(PERFORMANCE_COUNTER_BASE, 1));

注意点としては,section timeのみを図りたい場合でも,total counterも起動する必要があること.また,printfでalt_u64の表示を行う場合には,書式装飾子"q"*1を付与する必要がある.


*1 : gcc方言:long long 型の書式."qu"で"unsigned long long"型である.

注意事項

英語力の弱い人が適当に訳して抜粋,補強しています.
あやしいな,と思ったらご指摘いただけますと幸いです.
なお,オリジナルの英文を参照されることを強く推奨いたします.

OK キャンセル 確認 その他