fpga(跡地)

検索条件

タグで絞り込み FPGA::NiosII(1) FPGA::QuartusII(5)

日付で絞り込み 11月(1) 12月(5)

全6件 (1/2ページ) 記事本文を表示

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

FPGA::QuartusIIimport

[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

コメント（2件）

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

FPGA::QuartusIIimport

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になっていた．これのせいですな．
で，これをコメントインするとですね，表題の問題にぶちあたるわけです．

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

前提条件

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

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

コメント（0件）

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

FPGA::QuartusIIimport

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

コメント（0件）

2008/12/11(木)[FPGA][ModelSIM] シミュレーションとライセンス

FPGA::QuartusIIimport

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

設定～ModelSimのライセンス

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

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

"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境界の処理をどうすべきかを検討する必要がありますが．クロック・モジュールリセットの集中管理が必須となってくるでしょうねぇ．そんなことできるかな...

コメント（0件）

2008/12/01(月)[QuartusII][SOPC] DDR SDRAM High Performance Controller

FPGA::QuartusIIimport

[QuartusII][SOPC] DDR SDRAM High Performance Controller

基本

基本的には，ALTERAから出ているUsers Guide～（External DDR Memory PHY Interface Megafunction User Guide (ALTMEMPHY)）file:"altmemphy.pdf"～を参照すれば使い方がわかるはずです．

はまったところ

使用するIPのユーザーズガイドは目を通すべし

DDRcontrollerにおいては，２つの制約ファイルが用意されていました．いろいろと調べる羽目になったけれども，SOPC Builderを純粋に使って幾分には，ユーザーズガイドに沿って作業を進めれば乗り越えられたようです．．．

具体的には，以下のファイルが生成されます．

<module-name>_phy_ddr_timing.sdc
<module-name>_phy_ddr_pins.tcl
 where <module-name> := SOPC Builder の "module name"に記述した名称

SDCファイルはprojectにTimeingQuestへ渡すように設定が必要です．
tclについては，外部端子設定を行うマクロがついています．v7.2のpicture viewerを元にPin Assignment Editorで設定をしてしまったので，使用感は今のところわかりません．scriptを見る感じでは，module階層をたどって外部ピンまで探し出し，ドライブ設定（SSTL-2），電流設定（8mA～Max.まで機能ごとに設定），OutpuEnableGroup設定を行うようです．結果的にどうすべきかのメモを置いておきます．

OutpuEnableGroupの設定～１

以下の信号全てを同一グループとし，I/O Bankの制約に引っかからないように制御する．

mem_dq[0..15], mem_dqs[0..1], mem_dm[0..1]

OutpuEnableGroupの設定～２

以下の信号全てを同一グループとし，I/O Bankの制約に引っかからないように制御する．

led[0..3]

Current_Strengthを設定する

Maximum Current
```
mem_dq[0..15], mem_addr[0..] //全部
```

12mA

mem_cs_n, mem_ras_n, mem_cas_n, mem_cke, mem_we_n, mem_clk, mem_clk_n
mem_ba[0..1], mem_dm[0..1], mem_dqs[0..1]

動作クロックがわからない

SOPC BuilderでControllerを貼り付けるが，Clock domainの設定に留意する点がある．DDR controllerの動作クロックは，configurationで自動的にPLLを使ってクロックを生成させる方法をとると，inputするreferenceクロックとほぼ無関係*1に動作する．
このため，本IPの出力クロックを使わないのであれば，Clock Brdigeを加える必要がある．また，本IPはSlave portしか存在しない．このSlavePortの動作クロックは，以下のシンボルのクロックで駆動される．Master Portも同じくロックで駆動する必要がある*2．

<DDRcontroller-Module-Name>_sysclk
 where <DDRcontroller-Module-Name> := "Module Name"の欄に入力した文字列

失敗の具体例

システム要件

CPU clock=100MHz
DDR clock=133MHz/66.5MHz
 CPU-DDR間には Clock Bridgeを設置
  BridgeのSlave(CPU側)は CPU clockを設定
  BridgeのMaster(DDR側)は CPU clockを設定(※ここが誤り)

Timing Analysisの結果，以下のようなcritical warningが出る．

Info: Path #1: Setup slack is -3.478 (VIOLATED)
  Info: ===================================================================
  Info: From Node    : Nios2_NoDDR:Nios2_NoDDR_inst|Nios2_NoDDR_clock_1:the_Nios2_NoDDR_clock_1|Nios2_NoDDR_clock_1_slave_FSM:slave_FSM|slave_write_request
  Info: To Node      : Nios2_NoDDR:Nios2_NoDDR_inst|Nios2_NoDDR_clock_1:the_Nios2_NoDDR_clock_1|unxslave_write_requestxx3
  Info: Launch Clock : Nios2_NoDDR_inst|the_pll0|the_pll|altpll_component|auto_generated|pll1|clk[0]
  Info: Latch Clock  : Nios2_NoDDR_inst|the_ddrsdram|ddrsdram_controller_phy_inst|alt_mem_phy_inst|ddrsdram_phy_alt_mem_phy_inst|clk|pll|altpll_component|auto_generated|pll1|clk[1]
  Info: 
  Info: Data Arrival Path:
  Info: 
  Info: Total (ns)  Incr (ns)     Type  Element
  Info: ==========  ========= ==  ====  ===================================
  Info:     30.000     30.000           launch edge time
  Info:     32.932      2.932  R        clock network delay
  Info:     33.037      0.105     uTco  Nios2_NoDDR:Nios2_NoDDR_inst|Nios2_NoDDR_clock_1:the_Nios2_NoDDR_clock_1|Nios2_NoDDR_clock_1_slave_FSM:slave_FSM|slave_write_request
  Info:     33.037      0.000 FF  CELL  Nios2_NoDDR_inst|the_Nios2_NoDDR_clock_1|slave_FSM|slave_write_request|q
  Info:     33.192      0.155 FF    IC  Nios2_NoDDR_inst|the_Nios2_NoDDR_clock_1|unxslave_write_requestxx3~feeder|datad
  Info:     33.255      0.063 FF  CELL  Nios2_NoDDR_inst|the_Nios2_NoDDR_clock_1|unxslave_write_requestxx3~feeder|combout
  Info:     33.255      0.000 FF    IC  Nios2_NoDDR_inst|the_Nios2_NoDDR_clock_1|unxslave_write_requestxx3|d
  Info:     33.305      0.050 FF  CELL  Nios2_NoDDR:Nios2_NoDDR_inst|Nios2_NoDDR_clock_1:the_Nios2_NoDDR_clock_1|unxslave_write_requestxx3
  Info: 
  Info: Data Required Path:
  Info: 
  Info: Total (ns)  Incr (ns)     Type  Element
  Info: ==========  ========= ==  ====  ===================================
  Info:     30.064     30.064           latch edge time
  Info:     29.960     -0.104  R        clock network delay
  Info:     29.820     -0.140           clock uncertainty
  Info:     29.827      0.007     uTsu  Nios2_NoDDR:Nios2_NoDDR_inst|Nios2_NoDDR_clock_1:the_Nios2_NoDDR_clock_1|unxslave_write_requestxx3
  Info: 
  Info: Data Arrival Time  :    33.305
  Info: Data Required Time :    29.827
  Info: Slack              :    -3.478 (VIOLATED)
  Info: ===================================================================

Launch ClockがCPU clock，Latch clockがDDR controller IPが生成したPLLクロックである．Launch/Latchが逆のケースもあり，そもそも異なるclock domainの信号が交錯している段階で異常．特にCELL名から，WRITE要求信号がViolationしているので，ありえない．
FIFOによるclock分離部分のfalse_path設定やmulticycle_path設定忘れなどではないところに注意．無視してよいものと悪いものの判断ができるようになる必要がある．そのためには同期系回路はどのクロックで駆動されているのかを把握し，clock domain境界はどこにあり，そこはどうやって回避しているのかを把握しておくこと．
位相保障をしつつクロックを整数倍にしていれば，setup/hold条件を満足させることもできるだろう．本システムの場合，100MHzと133MHz（またはその半分）で駆動しているため，必ずエラーとなる．

ポート属性の認識誤り

port attribute に留意する．
特に外部portへの接続時に，inout属性を指定する必要のある端子がある．

.mem_clk_n_to_and_from_the_ddrsdram  (),
.mem_clk_to_and_from_the_ddrsdram    (),
.mem_dq_to_and_from_the_ddrsdram     (),
.mem_dqs_to_and_from_the_ddrsdram    (),

CLKが双方向にする必要というのが理解しきれていないが，cycloneとして必要という認識．
PLLにfeebackしているのかpair clockとして位相を合わせるのに使っているのか，documentを追いかけ切れていない．

DQはデータ信号なので双方向，DQSについては，データ送出側がドライブすることになるので，双方向である必要がある．
DDRになってから，driveするデバイスが入れ替わるようになったようなので，SDRAMだけの知識だけで挑んだのでミスった．

なお，DRAM系の情報としては，ELPIDAが公開している製品情報から教材となるPDFを得られる．和文documentが充実していて非常にありがたい．

失敗の具体例

dqsのポート設定を誤ってoutportとして接続したとき，Synthesisまで通ってしまった．
その後のTimingQuestによるtiming analysisで，TimeQuestがassertionでこけた．（QuartusII v8.1, WEB edition）
本件，属性違いに気づかずALTERA my supportにてSRを出してしまったが，Work Aroundとして"inout"にしてくださいといわれて気づいた．

HDLの仕様上，ポート接続時の属性チェックはなされない模様ですね．Tri-stateを考えると，出力同士が衝突してもおかしくないし，記述自体もinoutでぶら下げたりしてますからね．．．
そんなわけで，moduleを使うにはmoduleの動作概要の理解とinput/output/inout属性の確認，今回のように外部デバイスと接点がある場合も，その信号の意味等を理解しておくほうが無難です．
SOPC Builderはあくまでもサポートツールであり，その下にあるフレームを理解しなくては，自力でprojectを作り上げることすらできなさそうです．

コメント（0件）