チップ部品サイズの対応表

EAGLE

回路図CADソフトEAGLEのライブラリに登録されているチップ部品は、メトリックとインチが混在している。アホな私は、そのサイズがどちらのものか判らず毎回調べているが、さすがに面倒に思えてきたので対応表にしておく。これがすべてではないがこれだけあれば事足りると思う。

metric inch
0402 01005
0603 0201
1005 0402
1608 0603
2012 0805
3216 1206
3225 1210
5025 2010
6332 2512

私が使用しているEAGLE(Ver 4.15)は、rcl.lbrのデバイスC-EUにチップ・コンデンサがあり、C1608はメトリックである。一方、チップ抵抗のR-EU_にはR1608というものは無く、R0402を使用する必要がある。これに合わせてコンデンサもC0402にすべきかもしれない。
(2013.11.11追記)
EAGLE(Ver 4.15。それ以降は未確認)のRCLライブラリはパーツ名にサイズが含まれています。
例えば「C-EUC1608」など。ただしmetricとinchが混在しています。使いたいパーツがどちらの単位で設計＆命名されているかよく確認してください。
そして必要なら上記の変換表でパーツ名を読み替えてください。
(2013.11.11追記ここまで)

ただ日本はメトリックなので購入するとき1608とか指定する必要があるかもしれない。Digi-keyなら「パッケージ/ケース」に単位が書いてあるので迷うことはない。千石の10個売りのチップ抵抗／コンデンサはメトリックで2012と1608の２種類だけだ。

AT32UC3BのPDCA(読んでみただけ)

AVR32

今回はAT32UC3BのPDCA(Peripheral DMA Controller)を読んでみる。
ドキュメント「AT32UC3B Series Preliminary」の「19. Peripheral DMA Controller」部分。


19.1 Features

  • USARTとSSC、SPIのような周辺モジュールとの間で転送を起動する。
  • チャンネル当たり２つのアドレス・ポインタ／カウンタがダブル・バッファリングを可能にする。


19.2 Overview
Peripheral DMAコントローラ(PDCA)はチップの上のUSART、SPI、SSCなどの周辺モジュールとチップ内外のメモリの間でデータを転送する。PDCAの使用はデータ転送のためにCPUの介入を避け、マイクロコントローラの性能を改善する。PDCAはメモリから周辺機器へ、あるいは周辺機器からメモリへデータを転送することが出来る。
PDCAは多くのDMAチャネルから成り立つ。各チャンネルは以下を持つ。

  • 32bitメモリ・ポインタ
  • 16bit転送カウンタ
  • 32bitメモリ・ポインタ・リロード値
  • 16bit転送カウンタ・リロード値

PDCAは多くのハンドシェーク・インタフェースを通じて周辺モジュールと通信する。周辺モジュールが受信あるいは送信データの準備ができているとき、周辺モジュールはPDCAに合図する。転送が始まったときPDCAは要求に応答する。
ハンドシェーク・インタフェースの数はDMAチャネルの数より大きいかもしれない。
送信バッファが空のとき、あるいは受信バッファが満杯のとき、割込要求が送られる(訳注：割込要求元はPDCA。ここでバッファとは周辺モジュールのではなく、メモリ側である)。


19.3 Block Diagram
訳注：ブロック図はドキュメントを参照。この図と「3. Blockdiagram」の全体ブロック図を見比べると以下のことが解る。

  • 「PERIPHERAL DMA CONTROLLER」から各周辺モジュールにのびる網掛けの太線は「Handshake interfaces」であり、別のバスがある訳ではない。データの転送は白抜き矢印の「PB(Peripheral Bus)」で実施される。
  • 全体ブロック図では周辺モジュールに「PDC」という思わせぶりなブロックがあるが、大したものではないようだ。決してバス・マスターが各周辺モジュールに付いている訳ではない。
  • 両図には矛盾がある。PDCAのブロック図ではPDCAがPBに直結している。一方、全体ブロック図では直結していない。HMatrix(Bus Matrix)において、PDCAはマスターで、HSB-PB BRIDGE A(HSB to PB Bridge)はスレーブであり、Figure 9-1の通り接続している。従ってPDCAはHMatrix→HSB to PB Bridge経由で周辺モジュールにアクセスすると考えられる(モジュール単体の仕様ではPBに接続可能なのかもしれない)。


19.4 Functional Description

19.4.1 Configuration
PDCAの各チャンネルは1セットの構成レジスタがある。これらには共通してMAR(Memory Address Register)、PSR(Peripheral Select Register)、およびTCR(Transfer Counter Register)がある。32ビットのMemory Address Registerはメモリ・バッファの開始アドレスをプログラムしなければならない。各転送後、メモリの次の位置を示すために自動的にレジスタは更新される。目的とする周辺モジュール／ハンドシェイク・インタフェースが選択されるようにPeripheral Select Registerをプログラムしなければならない。Transfer Counter Registerは、転送されるデータ項目数を決める。カウンタは転送されたデータ項目毎に1つ減少する。
転送の進捗をチェックするため、Memory Address RegisterとTransfer Counter Registerの両方をいつでも読むことができる。
また、各チャンネルには、Memory Address RegisterとTransfer Counter Registerのためのリロード・レジスタがあります。TCRがゼロに達するとき、リロード・レジスタの値はMARとTCRにロードされる。このように、PDCAは各チャンネルあたり2つのバッファを作動させることができます。

19.4.2 Memory Pointer
各チャンネルは32bitのMemory Pointer Register(MAR)(訳注：「Pointer」は「Address」の誤記)を持っている。このレジスタは、次の転送を実行するメモリ・アドレスを保持する。各転送の後に自動的に本レジスタは更新される。アドレスはDMA転送サイズ(バイト、ハーフ・ワードまたはワード)に依存する１、２または４と増加する。転送の間、Memory Address Registerをいつでも読むことができる。

19.4.3 Transfer Counter
各チャンネルは16bitのTransfer Counter Register(TCR)を持っている。本レジスタに転送数をプログラムしなければならない。TCRは転送サイズにかかわらず転送すべきデータ項目数を格納する。転送残数を確認するため、転送中にTransfer Counter Registerをいつでも読むことができる。

19.4.4 Reload Registers
Memory Address RegisterとTransfer Counter Registerの両レジスタには、それぞれリロード・レジスタのMemory Address Reload Register(MARR)、およびTransfer Counter Reload Register(TCRR)がある。これらのレジスタはPDCAが各チャンネルあたり2つのメモリ・バッファ動作の可能性を提供する。１つのバッファが完了したとき、値がMARRとTCRRにある値で、MARとTCRはリロードされる。TCRRが非ゼロの値を保持する間、もしTCRがゼロに達すると、リロード・ロジックはいつも有効とされトリガするだろう。(訳注：TCRRがゼロならリロードされない)

19.4.5 Peripheral Selection
Peripheral Select Register(PSR)は、どの周辺モジュールがPDCAチャンネルに接続されるか決定する。PSRの設定は転送方向(メモリから周辺モジュールへ、あるいは周辺モジュールからメモリ)と、ハンドシェイク・インタフェースの使用、そして周辺モジュールのアドレス保持レジスタを選択することを命ずる。

19.4.6 Transfer Size
転送サイズは個別に各チャンネルへバイト、ハーフ・ワードかワード(それぞれ 8bit,16bitまたは32bit)のいずれかを設定できる。転送サイズは、Mode Register(MR)のSIZEフィールドをプログラムすることによって設定される。

19.4.7 Enabling and Disabling
各DMAチャネルは、Control Register(CR)に'1'を書くことによりTransfer Enableビット(TEN)に可能にされて、'1'を書くことによって、Transfer Disableビット(TDIS)に無効にされる。

AVR32UC3BのHMATRIX(まとめ)

AVR32

AVR32UC3BのHSB Bus Matrix(HMATRIX)(Rev: 2.3.0.1)についてまとめる。以下も参照のこと。


マスターのメモリ・マッピングについてはよく解らない。
「9.2 Physical Memory Map」で「メモリは再マップ出来ない」といいながら、HMATRIXのMRCRレジスタでマップ可能。そのマップ方法がどこにも説明されていない(見落としているのかな？)。
メモリ・マッピング＝デコーダらしいが、その設定レジスタであるMRCRをどう使用すればマッピングが実現できるのかどこにも記述が無い。
一応、AVR32 UC3 Software Frameworkの中を探すと、MRCRレジスタは定義されているのだけれど、MRCRレジスタの使い方に関するヒントは得られなかった。ドライバはヘッダファイルのみで、そこで宣言されている関数は見つからなかった。

スレーブには以下の機能がある。この機能は個別に動作する。

  • ラウンド・ロビン／固定優先度による調停(スレーブが空いたとき次にアクセスするマスターの選択規則)
  • 無し／最終アクセス／固定によるデフォルト・マスターの選択(次にアクセスするマスターがデフォルトだとバースト・アクセス先頭で待ちサイクルが０(その他は１))


ラウンド・ロビン／固定優先度の設定は、レジスタSCFGのフィールドARBT(bit24)で選択される。

  • 0: ラウンド・ロビン調停(初期値)
  • 1: 固定優先度調停


固定優先度の指定はPRAS0〜15とPRBS0〜15で指定する。
レジスタ名について、PRASとPRBSに続く番号はスレーブ番号、３文字目のA/Bはマスター番号0〜7(A)と8〜15(B)の区分けである。各レジスタは32bitで、優先度0〜15を指定するため4bitずつ区分けすると８個しか確保できないのでA/B２つのレジスタが必要になる。4bitの区分けにはA/B合わせてM0PR〜M15PRのフィールド名が付いている。
一般形で記述すると以下のようになる。

レジスタ名＝"PR"＋"AB"[マスター番号／8]＋スレーブ番号
フィールド名＝"M"[マスター番号]＋"PR"
ビット・フィールド範囲＝(マスター番号％8＊4+3)〜(マスター番号％8＊4)

当然だが、マスターもスレーブも存在しない番号は設定する必要はない。


デフォルト・バス・マスターは、これから要求を受けるマスターと一致したとき、バースト先頭で１サイクル待つ必要が無い。一方、不一致の場合はバースト先頭で１サイクル待たされる。
この待ち時間はマスターとスレーブの接続に必要な時間であり、それが不要ということは、通信していないときデフォルト・マスターとスレーブが接続されっぱなしで、あるいは他のマスターと通信し終えると直ちにデフォルト・マスターと接続していることになる。従って高速通信が期待できるものの消費電力的にはデメリットである。
デフォルト・バス・マスターは、使用しないスレーブでは当然「無し」に設定すべきである。またアクセス頻度が低い場合も同様である。
最終アクセスのデフォルト・バス・マスターを選択すると、頻繁にアクセスするマスターが１つのとき転送効率が向上する可能性がある。SRAMに設定すると良いと思われる。
固定デフォルト・バス・マスターを選択すると、頻繁にアクセスするマスターが複数あるとき、もっともアクセス頻度の高いマスターをデフォルトに固定することで、転送効率が向上する可能性がある。
頻繁にアクセスする複数マスターがあるとき、デフォルト・バス・マスターに最終アクセス／固定のいずれかを選択するか迷うところであるが、連続バースト数などの関係もあり、設定を変更してベンチ・マークを取ってみるしかないだろう。
デフォルト・バス・マスターは、レジスタSCFG0〜15(インデックスはスレーブ番号)で選択可能である。フィールドDEFMSTR_TYPEに以下の値を設定する。

  • 0: デフォルト・バス・マスター無し(初期値)
  • 1: 最終デフォルト・マスター
  • 2: 固定デフォルト・マスター

固定デフォルト・マスターを選択したとき、対象マスター番号を同じレジスタSCFG0〜15のフィールドFIXED_DEFMSTRに設定すること。


以下のタイミングで調停が実施される可能性がある。

  1. アイドル・サイクル：スレーブがどのマスターにも接続されていないとき、あるいはスレーブがデフォルト・バス・マスターに接続されているだけ(転送していない)のとき。
  2. シングル・サイクル：スレーブが現在シングル・アクセスされているとき。
  3. バースト最終サイクル：現在のサイクルがバースト転送の最終サイクルであるとき：定義された長さのバーストに対して、予測されたバースト末尾は転送サイズに合致するが、しかし未定義長のバーストに対してバースト末尾は別に管理されている。
  4. スロット・サイクル限界：スロット・サイクル・カウンタが限界値に到達したとき(現在のマスター・アクセスが長すぎて中断されなければならない)。

調停方式は先に説明した通り、ラウンド・ロビン／固定優先度のいずれかである。
調停が済むと、対象マスターがスレーブにアクセスを開始する。連続アクセスが長いと問題になることがあるため、２通りの規則により再度調停を実施する。
１つはバースト数による制限(ULB: Undefined Length Burst)で、もう１つはアクセス・サイクル数による制限(Slot Cycle Limit)である。
それぞれには、アクセス数とクロック・サイクル数という物差しの違いの他、ULBがマスター側の設定／Slot Cycle Limitがスレーブ側の設定という点が異なる。
HMATRIXのレジスタ構成を見る限り、ULBとSlot Cycle Limitは常に有効であり、一方あるいは双方を無効に出来ない。


ネーミングに難があるが、ULBはマスター毎に規定バースト・アクセス数を越えたとき再調停する。規定バースト・アクセス数には制限無し(0, Infinite)、１(1)、４(2, 初期値)、８(3)、１６(4)の５つがある。この値はMCFG0〜15のフィールドULBTにカッコ内の数値を指定する。レジスタ名末尾の番号はマスター番号である。
ドキュメントでは、制限無し(Infinite)を指定すると、そのマスターのバースト・アクセスは中断されないと記述されているが、実際にはSlot Cycle Limit(後述)の再調停があるので文字通りの"Infinite"ではない。

Slot Cycle Limitは、アクセスが規定クロック・サイクル連続するとき再調停する。HMATRIXに供給されるクロックはCPUと同じSynchronous clocksである。レジスタSCFG0〜15のフィールドSLOT_CYCLEで指定する。レジスタ名末尾の番号はスレーブ番号である。初期値は0x10であり、再調停が頻発しないよう小さすぎる値を設定すべきではない。適正値として初期値と同じ0x10(16)がドキュメントで紹介されている。

以下はAT32UC3B0/1シリーズのHMATRIXの仕様である。
High Speed Busマスター

Master 0 CPU DATA
Master 1 CPU Instruction
Master 2 CPU SAB(訳注：NEXUS(OCD)のこと)
Master 3 PDCA
Master 4 USBB DMA

High Speed Busスレーブ

Slave 0 Internal Flash
Slave 1 HSB-PB Bridge 0
Slave 2 HSB-PB Bridge 1
Slave 3 Internal SRAM
Slave 4 USBB DPRAM


HMatrix Master / Slave Connections
HMATRIX SLAVES
Internal FlashHSB-PB
Bridge 0		HSB-PB
Bridge 1		Internal SRAMUSBB DPRAM
01234
HMATRIX MASTERSCPU Data0○ ○○ ○
CPU Instruction1○ ○
CPU SAB2○○○○○
PDCA3○○ ○
USBB DMA4○ ○

  • ○はマスターとスレーブの接続が可能な組み合わせを表すと思われる。
  • CPUは内蔵SRAMへは直接アクセス可能なため、CPU DataはInternal SRAMへの接続は無い。
  • 内蔵FlushROMとSRAMからだけ命令フェッチするので、CPU Instructionはそれら以外に接続できない。
  • デバッグで全情報にアクセスするため、CPU SABは全スレーブに接続可能である。
  • HSB-PB Bridge 1(BRIDGE B)はUSBとFlashROM制御のみなので、PDCAは接続しない。またUSBB DPRAMにも接続しない。従ってUSBと通信系の周辺モジュール間でデータを垂れ流すことも出来ない。
  • USBB DMAとUSBB DPRAMが接続できないのは、DP(Dual Port)RAMの一方のポートがUSBB DMAと接続していているため、他方においてHMatrix経由接続が不要だと推察される。


＜＜その他、感想＞＞

  • 結局、HMATRIXの設定はデフォルトのままでも問題なく動作する。
  • その一方で、HMATRIXは単一バス・システムに比べ高速化の可能性があり、性能を引き出すためには調整が必要かもしれない。最適な設定はアプリケーション毎に異なるはずで、実アプリケーションによるベンチ・マークが必要となる。これがHMATRIXの最大の欠点かもしれない。
  • 内蔵SRAMは各マスターからアクセスされるので配慮が必要である。またCPUとHMATRIXが同一クロック動作で、ほとんどのCPU命令が1cycleで完了するため、他のマスターが接続し続けると、ソフト処理性能が極端に悪化するはずである。
    • 製品版なら、コードをFlushROMへ配置すること。コードをSRAMに配置したとき、SRAMデータへアクセスする１サイクル命令は３サイクルで実行される(Instructionマスターで１つ、Dataマスターで１つ、どちらかがデフォルト・マスターでないため１つ遅延)。以下は私が考えた方針であり、性能が出せる保証はない。
  • 転送レートが高いUSBB DMAが連続アクセスするなら、SRAMのデフォルト・マスターは固定デフォルト・マスターに、PDCAによる単発アクセスが多いなら、SRAMのデフォルト・マスターはデフォルト・バス・マスター無しにする(わざわざ接続し続ける必要なし)。ただし、開発中にSRAMへコードを配置するなら最終アクセス・マスターを選択すべきかもしれない。
  • FlushROMはほぼ１サイクル毎にCPU Instructionマスターがアクセスするので、ほぼ固定デフォルト・バス・マスターでよい。ただし、USBパケットの固定送信データをFlushROMに格納→USBB DMAで送信するなら、USBB DMAマスターのULBを転送データに合うよう調整すべきである。
  • 初期化を除けば、PDCAマスターやHSB-PBブリッジ・スレーブはほぼ単発なのでデフォルト・バス・マスターに設定する必要はない。またULBやSlot Cycle Limitの制限を緩やかにする必要もない。

AVR32UC3BのHMATRIX(読んでみただけ２)

AVR32

HMATRIX関係の話は他の章にも分散しているので、そちらも読んでみる。


9.3 Bus Matrix Connections
未使用エリアへのアクセスはその様なアクセスを要求したマスターにエラーを返す。
バス・マトリックスはいくつかのマスターとスレーブを持つ。各マスターは自身のバスとデコーダを持ち、従ってマスター毎に異なるメモリ・マッピングを許す。HMATRIX制御レジスタにインデックスをつけるため以下のテーブルのマスター番号を使用できる。例えば、HMATRIX MCFG0レジスタはCPUデータ・マスター・インタフェースとして関連付けられる。
High Speed Busマスター

Master 0 CPU DATA
Master 1 CPU Instruction
Master 2 CPU SAB(訳注：NEXUS(OCD)のこと)
Master 3 PDCA
Master 4 USBB DMA

各スレーブは自信の調停機構を持ち、従ってスレーブ毎に異なる調停(方式)を許す。HMATRIX制御レジスタにインデックスをつけるため以下のテーブルのマスター番号を使用できる。HMATRIX制御レジスタにインデックスをつけるため以下のテーブルのスレーブ番号を使用できる。例えば、SCFG3レジスタは内蔵SRAMスレーブ・インタフェースに関連付けられる。
High Speed Busスレーブ

Slave 0 Internal Flash
Slave 1 HSB-PB Bridge 0
Slave 2 HSB-PB Bridge 1
Slave 3 Internal SRAM
Slave 4 USBB DPRAM


HMatrix Master / Slave Connections
HMATRIX SLAVES
Internal FlashHSB-PB
Bridge 0		HSB-PB
Bridge 1		Internal SRAMUSBB DPRAM
01234
HMATRIX MASTERSCPU Data0○ ○○ ○
CPU Instruction1○ ○
CPU SAB2○○○○○
PDCA3○○ ○
USBB DMA4○ ○
訳注：この図について説明文が無い。以下補足である。

  • ○はマスターとスレーブの接続が可能な組み合わせを表すと思われる。
  • CPUは内蔵SRAMへは直接アクセス可能なため、CPU DataはInternal SRAMへの接続は無い。
  • 内蔵FlushROMとSRAMからだけ命令フェッチするので、CPU Instructionはそれら以外に接続できない。
  • デバッグで全情報にアクセスするため、CPU SABは全スレーブに接続可能である。
  • HSB-PB Bridge 1(BRIDGE B)はUSBとFlashROM制御のみなので、PDCAは接続しない。またUSBB DPRAMにも接続しない。従ってUSBと通信系の周辺モジュール間でデータを垂れ流すことも出来ない。
  • USBB DMAとUSBB DPRAMが接続できないのは、DP(Dual Port)RAMの一方のポートがUSBB DMAと接続していているため、他方においてHMatrix経由接続が不要だと推察される。

AVR32UC3BのHMATRIX(読んでみただけ)

AVR32

簡単なようでややこしい感じのするHMATRIX(HSB Bus Matrix)。理解していなくても動作しそうであるが、後でバグの原因になると嫌なので、やはり読んでおくことにした。
対象MCUはいつも通りAT32UC3B0256である。ドキュメントは「AT32UC3B Series Preliminary revG」。別シリーズだと、話が異なってくるかもしれないので、今回はAT32UC3Bに限定。


まずはドキュメントの落ち穂拾いから。

  • 「9.3 Bus Matrix Connections」に記述がある「CPU SAB」はどこにも説明がない。しかし「Figure 3-1. Block diagram」におけるマスターの数からすると「NEXUS(OCD)」のことらしい。
  • 「Table 9-4. High Speed Bus slaves」にある「HSB-PB Bridge 0」と「HSB-PB Bridge 1」はそれぞれ「HSB-PB BRIDGE A」と「HSB-PB BRIDGE B」のことである(というかどちらが正しいのかよく判らない)。


次に「Figure 3-1. Block diagram」における確認事項。これもきちんと記述して欲しいものだ。

  • 明記されていないが、「HSB-PB BRIDGE A」から下に伸びるバスが「Peripheral Bus」である。
  • 「HSB-PB BRIDGE B」の上部に「HS」と「B」とあるが単語の「HSB」である(私は「HS」ってなんだろう？と３０分悩んだ)。
  • 「HSB-PB BRIDGE A」の「HSB」は「HIGH SPEED BUS」、「PB」は「Peripheral Bus」のことである。一方、「HSB-PB BRIDGE B」の「PB」はPeripheral Busではなく「CONFIGURATION REGISTERS BUS」に接続している。たぶん「BRIDGE A」とインタフェースが同じってだけで「PB」と言っているんだと思う。
  • その「CONFIGURATION REGISTERS BUS」はどこにも説明が無い。
  • 存在するはずの「USBB DPRAM」がどこにもない。スレーブの数からすると、USBの「DMA」に隠れているらしい。本来USB DMAはマスターであり、スレーブではない。USBB DPRAMはスレーブであり、USBB DPRAMとUSB DMAはHMATRIX経由で接続されていないので、矢印１つに「S(slave)」と「M(master)」が割り付けられていること自体おかしい。ちなみにDP(Dual Port)RAMのもう一方が裏でDMAに接続されていると私は推察している。


18.1 Features

  • peripheral busにユーザ・インタフェース(設定レジスタのこと)
  • 構成可能な数のマスター(16まで)
  • 構成可能な数のスレーブ(16まで)

バス・マスターやバス・スレーブの数が16個まで設定できるといっても、モジュールの仕様であり、製品に組み込まれた時点で固定になるはず(だと思う)。

  • 各マスターに1つのデコーダ
  • Three Different Memory Mappings for Each Master (Internal and External boot, Remap)

各マスターに３つのメモリ・マップ(内部／外部(USBブート？)とリマップ)

  • 各マスターに1つのRemap機能
  • 各スレーブにプログラム可能な調停
    • ラウンド・ロビン調停
    • 固定優先度調停
  • 各スレーブ毎にプログラム可能なデフォルト・マスター
    • デフォルト・マスター無し
    • 最終アクセス・デフォルト・マスター
    • 固定デフォルト・マスター
  • バースト・アクセスの先頭では１サイクル待ち時間
  • デフォルト・マスターは待ち時間無し
  • 各スレーブ毎に１つのSpecial Function Register(Not dedicated)


18.2 Description
バス・マトリックスは複数階層バス構造を実装し、複数HSB(High Speed Bus)マスターとスレーブ間で同時アクセスを可能にし、全体の帯域幅を増加させる。
(省略)

18.3 Memory Mapping
バス・マトリックスは、HSBマスター・インタフェース毎にデコーダを１つ備えている。デコーダはいくつかのメモリ・マッピングを各HSB Masterに提供する。実際は製品により、それぞれのメモリ領域はいくつかのスレーブに割り当てられるかもしれない。異なるHSBスレーブ(例えば外部RAM、内部ROMまたは内蔵Flash、その他)を使用する間、同一アドレスにおけるブートが可能である。
バス・マトリックスのユーザ・インタフェースは、MRCR(Master Remap Control Register)を備えており、すべてのマスターのために単独でリマップ動作を実行する。

18.4 Special Bus Granting Mechanism

  • No Default Master：現アクセスの終わりに、他の要求が保留されていないなら、スレーブはすべてのマスターから切断される。No Default Masterは低消費電力モードに適している。
  • Last Access Master：現アクセスの終わりに、他の要求が保留されていないなら、アクセス要求完了後もスレーブは最後のマスターへ接続し続ける。
  • Fixed Default Master：現アクセスの終わりに、他の要求が保留されていないなら、スレーブはFixed Default Masterへ接続する。Last Access Masterと異なり、ユーザがソフトウェアで変更しなければ、固定マスターは変化しない(訳注：「マスターが変更されない」の意味と思われる)。


18.5 Arbitration
バス・マトリックスは、複数マスターが同一スレーブを同時にアクセスするようなケースが発生したとき、待ち時間を低減する調停機構を提供する。
HSBスレーブ当たり１つのアービトレータを備え、従って各スレーブ毎に異なった仲裁となる。
バス・マトリックスは、各スレーブ当たり2つの調停タイプを選択可能性をユーザに提供する。

  1. ラウンド・ロビン調停(デフォルト)
  2. 固定優先度調停

スレーブConfiguration Registers(SCFG)のそのフィールドARBTを通して、これを選択する。
各アルゴリズムは、各スレーブのためにデフォルト・マスター構成を選択することによって、補足されるかもしれない。


18.5.1 Arbitration Rules
各アービトレータは、２つ以上の異なるマスター要求の間で調停する能力を持つ。
バースト(・アクセス)破壊を避けるため、またスレーブ・インタフェースに最大スループットを提供するため、調停は以下のサイクルの間だけ行われるかもしれない。

  1. アイドル・サイクル：スレーブがどのマスターにも接続されていないとき、あるいはスレーブが現在アクセスされずマスターに接続されているだけのとき。
  2. シングル・サイクル：スレーブが現在シングル・アクセスされているとき。
  3. バースト最終サイクル：現在のサイクルがバースト転送の最終サイクルであるとき：定義された長さのバーストに対して、予測されたバースト末尾は転送サイズに合致するが、しかし未定義長のバーストに対してバースト末尾は別に管理されている(18.5.1.1を参照)。
  4. スロット・サイクル限界：スロット・サイクル・カウンタが限界値に到達したとき、現在のマスター・アクセスが長すぎて中断されなければならない(18.5.1.2参照)。


18.5.1.1 Undefined Length Burst Arbitration
未定義長バースト(INCR)の間に長いスレーブ対応を避けるために、バス・マトリックスは再度調停するためINCR転送末尾の前に固有のロジックを提供する。バーストの予測された末尾を定義されたバースト転送長として使い、予測末尾を以下の5つの可能性から選択することが出来る。

  1. Infinite：バーストの予測された末尾は発生されず、そのためINCRバースト転送は中断されない。
  2. One beat bursts：バーストの予測された末尾はINCR転送内の単一転送毎に発生する。
  3. Four beat bursts：バーストの予測された末尾はINCR転送内の4ビート境界毎の末尾に発生する。
  4. Eight beat bursts：バーストの予測された末尾はINCR転送内の8ビート境界毎の末尾に発生する。
  5. Sixteen beat bursts：バーストの予測された末尾はINCR転送内の16ビート境界毎の末尾に発生する。

この選択はMCFG(Master Configuration Registers)のULBTフィールドを通して実行できる。


18.5.1.2 Slot Cycle Limit Arbitration
バス・マトリクスは非常に遅いスレーブ(例えば外部低速メモリ)における非常に長いバーストなどの長いアクセスを中断する特別なロジックを持つ。バースト・アクセス開始時に、SCFG(Slave Configuration Register)のSLOT_CYCLEへ事前に書き込まれた値をカウンタにロードし、クロック・サイクル毎に減算する。カウンタがゼロに達したとき、調停機構は現在のバイト、ハーフ・ワードあるいはワード転送の最後に再調停する能力を持つ。

18.5.2 Round-Robin Arbitration
このアルゴリズムはラウンド・ロビン方式で同じスレーブに異なるマスターから要求送信することをバス・マトリックスの調停機構に許可する。もし２つ以上のマスター要求が同時に発生したなら、もっとも小さな番号のマスターが最初に使用可能にし、それからラウンド・ロビン方式でその他のマスターが使用可能になる。
３つのラウンド・ロビン・アルゴリズムが実装されている。

  1. デフォルト・マスター無しのラウンド・ロビン調停
  2. 最後のデフォルト・マスターによるラウンド・ロビン調停
  3. 固定デフォルト・マスターによるラウンド・ロビン調停


18.5.2.1 Round-Robin Arbitration without Default Master
これはバス・マトリックス調停機構で使用されるメイン・アルゴリズムである。バス・マトリックスが純粋なラウンド・ロビン方式で同一スレーブへ異なるマスターからの要求を送ることを許可する。現在のアクセスの最後に、その他の要求が保留中でなければ、スレーブはすべてのマスターから切断される。この設定はバーストの先頭アクセスに対し１遅延サイクルを招く。重要なバーストを実行するマスター向けにデフォルト・マスター無しの調停を使用できる。

18.5.2.2 Round-Robin Arbitration with Last Default Master
これはバス・マトリックス調停機構により使用された偏りのあるラウンド・ロビン・アルゴリズムである。スレーブへアクセスした最後のマスターに１遅延サイクルを取り消すことができる。実際には現在の転送の末尾に、他のマスターの要求が保留されていなければ、スレーブはアクセスした最後のマスターを覚えている。
他の非特権マスターが同じ奴隷にアクセスしたいなら、そのマスターは１サイクル遅延される。このテクニックは主にシングル・アクセスするマスターに使われる。

18.5.2.3 Round-Robin Arbitration with Fixed Default Master
これはもう１つの偏りのあるラウンド・ロビン・アルゴリズムである。バス・マトリックス調停機構は１スレーブ当たり固定デフォルト・マスターへ１遅延サイクルを取り消すことが出来る。現在のアクセスの最後に、スレーブは固定デフォルト・マスターへ接続していたことを覚えている。
この固定デフォルトマスターによって試みられたすべての要求が、少しも遅延を引き起こさないのに対し、他の非特権マスターは１サイクルを遅延するだろう。このテクニックは主にシングル・アクセスするマスターに使われる。

18.5.3 Fixed Priority Arbitration
バス・マトリックス調停機構は、ユーザにより定義された固定優先度を使うことにより異なるマスターから同一スレーブへ要求を送ることができるアルゴリズムである。もし２つ以上のマスター要求が同時にアクティブであるなら、高い優先度番号のマスターが最初にサービスを受ける。もし同じ優先度の２つ以上のマスター要求が同時にアクティブであるなら、最も高い番号のマスターが最初にサービスを受ける。
各スレーブについて、それぞれのマスターの優先度はレジスタPRAS(Priority Registers A for Slaves)とPRBS(Priority Registers B for Slaves)を通して定義されることができる。

18.6 Slave and Master assignation
マスターとスレーブに割り当てられたインデックス番号は「9. Memories」の章に記述されている。

回路図チェックリスト

AVR32

「AVR32 UC3B Schematic Checklist」(ドキュメント番号AVR32715)というドキュメントがあって、AVR32UC3B周辺の回路が要求通り正しく設計できているかチェックできる。今回は回路図を作った後にこのドキュメントを発見してしまったが、回路設計前に読んでおくべきだろう。
それでこのドキュメント、パスコンの指定があるのだけれど、値が「2.7nF」とか書いてある。「そんなコンデンサ入手できるかな？」などと考えてしまったが、μ=10-6、n=10-9、p=10-12だから、早い話「2700pF」のことだ。普通コンデンサに「nF」なんて使わないと思うのだが。もちろんそういう副単位(SI接頭辞)を使用しても間違えではないんだけどね。

AT32UC3B1〜で減らされたUSARTモジュール

AVR32

AVR32UC3Bシリーズの製品AT32UC3B0〜は64pinパッケージなのに対し、AT32UC3B1〜は48pinパッケージである。ピンが減らされている分、モジュールの数も減らされている。
それ自体は至極まっとうなことであるが、どのモジュールが削られているのか全く説明がない。いい加減だなあ。
ドキュメント「AT32UC3B Series Preliminary」(revision G, updated 4/08)では、「2. Configuration Summary」にモジュールの数だけ記述がある。SSC、ADC、USB hostは使用しないので無視。OSCは１つあれば十分なので、使用するUSARTが３つから２つへ減らされていることだけが気になった。AT32UC3B0〜に存在するUSART0〜2のうち１つが削られている。USART1は多機能モジュールなので削られることは無いと思ったが、USART0と2とどちらが存在するか判らない。
思いついて、AT32UC3のSoftware Frameworkの各MCUヘッダファイルを比較してみた。uc3b0256.h(AT32UC3B0256)とuc3b1256.h(AT32UC3B1256)をdiffとってみたところ、USART関係で変更されている部分もあるが、USART1は当然、そしてUSART0もUSART2も記述が存在する。極めつけはマクロAVR32_USART_NUMの値が「3」であることだ。
おいおいUSARTが３つあるじゃん。
どうにも判らないのでAtmel(米国？)へメールしてみたところ「AT32UC3B1〜で使用できるのはUSART1とUSART2」とのこと。不要なヘッダファイルの記述は取っ払って欲しいものだ。間違えてアクセスするコードを記述しても、コンパイル・エラーで把握することが出来るのだから。それにわざわざMCU毎にヘッダファイル用意している意味が薄くなるでしょう。
それにしても製品毎に使用できるモジュール一覧(使用できないモジュールでもいいけど)は、どこかに記述されているのかな？誰か知っていたら教えて欲しい。