Martini の構成

Martini^{のブロック図を図}4.6^に示す．

図4.6 Martini^{のブロック図}

Switch Interface (SWI)はクロックレートの変換やパケットの符号処理，フロー制御，仮想チャネ ルの管理などのネットワークのリンク関連の処理を行う．SWI^は，Martini^{が接続可能な} RHiNET-2/SW^，RHiNET-3/SW^およびOIP-SW^の3種類のリンクプロトコルに対応する．

PCI Interface(PCII)はMartiniをPCIバスに接続する際に用いられ，DIMM Interface(DIMMI)は

Martiniをメモリバスに接続する際に用いられる．また，DIMMIは，外部SDRAMへのインタフェー

スも搭載している．PCII^は32bit/33MHz^から64bit/66MHz^までのPCI^{バスに対応する．}DIMMI はPC100^およびPC133^規格のSDRAM^{に対応する．}

コアロジック(^図中のNIC Core Logic)^はMartiniの中核部分であり，アドレス変換やパケット 構築などのPUSH^・PULLプリミティブと関わりの深い多くの機能がここで処理される．オンチッ ププロセッサもコアロジック内に位置する．

これら各構成要素のうち，スイッチと共通部分の多いSWIはRWCPによって，また，DIMMIお よびPCII^{に関しては日立}ITによって実装が行われた．一方，コアロジックに関しては，RWCP^と 筆者ら慶大のグループとで共同で実装を行った．以下ではコアロジック部を中心に実装を述べる．

4.6.2 コアロジックの構造

Martini^{のコアロジックは}Hardwired Communication Path (HCP)と呼ばれるハードワイヤードロ ジックと，オンチッププロセッサで構成される．

HCPは，ホストなどからのパケット発行要求への対応を行うInitiator Controller (ICONT)^，ネッ トワークからの到着パケットの処理を行うRemote Controller (RCONT)^{，各モジュール間の}DMA 転送を制御するDMA Controller (DMAC)およびPATLBの，4つのブロックに分けて実装を行っ た．図4.7にこれらブロック間のつながりを示す．

Initiator Controller

ICONT^はWindow^とSend Controller^{で構成される}(^図4.8)^．4.2.2^{節でも述べたように，}Window はユーザからの要求を受け付けるための，ユーザ空間にマップされるメモリであり，ユーザプロ

Initiator Controller

Remote Controller PATLB AOTF Send

Controller

DMA Controller PCII

or DIMMI

SWI

DIMMI

SRAM for On-chip Processor PCII

図4.7 HCPのブロック図

セスがPUSHやPULL，BOTFによるパケット送出などの要求を行う際に利用される．Windowが キックされると，Windowに付随するコントローラによって要求のパラメータ(BOTFの場合はパ ケットイメージ)^がFIFO^を経てSend Controller^{に転送される．}

Send Controller^内部はInitiator^とReplier^の2つのモジュールで構成される．Initiator^はPUSH^・ PULL^の2^{種類のプリミティブと}BOTF^{の処理を行い，}Replier^はRCONT^側からのack^パケット やpull応答パケットの生成要求の処理を行う．これら2つのモジュールの機能はほぼ同一である が，デッドロックを回避するために，異なるモジュールとして実装した．

Window Send Controller

Initiator

Request FIFO Request

from PCII or DIMMI

DMA Request to DMA Controller

Physicl Page Number from PATLB

PGIDTBL

Replier

Request

from Remote Controller

Header FIFO

Send FIFO Header

Generator

Send Packet to SWI Data from DMA Controller

図4.8 Initiator Controller^{のブロック図}

Windowを介して発行された要求は，Initiator^{に転送される．}Initiatorは，まず要求の発行に用 いられたWindow^のID^よりPGIDTBL^{を参照して，}Window^{に対応した}PGID^とPID^{を取得する．}

もし，要求がPUSH^かPULL^{であった場合，}PGIDTBL^{から読み出した}PGID^とWindow^に書か れているパラメータを元にHeader Generatorでパケットヘッダを生成する．これらヘッダをFIFO

(Header FIFO)に格納し，要求がPUSHの場合は，DMAで読み出されるペイロードとの待ち合わ

せを行う．要求がPULLの場合は，ヘッダの待ち合わせをせずに，そのまま送信用のFIFO (Send FIFO)^{に転送する．}

要求がPUSH^{であった場合，}Initiator^{はヘッダ生成と同時に}PATLBを参照してローカルプロセ スの通信領域の物理アドレスを取得しておく．その後，DMA^要求をDMA^{コントローラの要求}

FIFOに格納し，ペイロードとなるデータがホストから読み出されたら，ヘッダFIFO^{のヘッダと}

結合してSend FIFO^{を経由して送出する．}

PUSHで送信を要求されたデータサイズが大きく，RHiNETでのMTU(2Kbyte)を超えるような

場合は，Initiatorが適宜分割を行い，pushパケットを複数回送出する．また，PUSHで送出する

データが格納されている領域が複数ページにまたがっている場合，Initiator^{は繰り返し}PATLB^に アクセスし，連続してDMA要求を発行する．このとき，DMAの要求発行と次のパケットのヘッ ダ生成処理との間に依存がないことから，これらはパイプライン動作する設計としてある．

一方，要求がBOTF^{であった場合，}Initiator^はPGIDTBL^より得たPGID^で，Window^から読み 出したパケットイメージのヘッダのPGIDが格納されるフィールドを上書きし，できあがったパ ケットイメージをSend FIFO経由で送出する．

ホストからの要求がこれら以外のハードウェア非対応のものであった場合は，Initiator^は例外を 発生し，オンチッププロセッサなどに割込みをかけて処理を依頼する．この仕組みを利用すること で，ユーザプロセスから直接オンチッププロセッサの処理を呼び出すことができ，PUSH^・PULL 以外の通信プリミティブに関してもユーザレベルでの要求発行を実現できる．

Windowに書かれた内容の処理が完了したら，Martiniは，Windowに書いた要求の処理が完了

し，次の処理の要求の発行が可能になったことをホストに通知する．通知は，あらかじめWindow ごとに指定されたホスト上のメモリ領域に対するDMA^{によるフラグ}(continue flag (contflag))^の 書き込みで行う．contflagの書き込み先は，事前にホストからPGIDTB^{に付随する}Continue Flag Table (CONTTBL)と呼ばれるテーブルに格納しておき，PGIDTBL^と同様にWindow^のID^で参照 することでアドレスを得る．その際，CONTTBLには完了フラグの書き込み先の物理アドレスが 登録されているものとし，アドレス変換をせずにこの値を完了通知の際のDMA転送の要求に直 接用いる．これは，contflagに用いる領域はホストプロセスから見るとWindowに付随するI/O領 域の一部と考えることができ，Windowに要求を発行するたびにアドレスが変更になるような使 い方は想定されないためである．

Remote Controller

RCONTは処理が複雑であることから，パケットヘッダの解析を主に行うReceiver Front-end

(RFend)と呼ばれるフロントエンド部と，仮想–^{物理アドレス変換や}DMA^{要求発行などを行う}

Receiver Back-end (RBend)と呼ばれるバックエンド部に分けて実装した(^図4.8)^．

Receiver Back-end

RVATLB

Receiver Front-end DMA Reqeust

to DMA Controller

Physical Page Number

from PATLB ACK Request to Initiator

Received Packet from SWI

DMA to DMA Controller

図4.9 Remote Controllerのブロック図

ネットワークから到着したパケットは，SWI^{を経由して}RCONT^{に転送される．まず}RFend^に て，転送されたパケットのヘッダの解析を行う．

受信したパケットがpushパケットであった場合，RFendはRVATLBを参照してパケットヘッ ダから読み取ったSIDを書き込み先領域の仮想アドレスに変換し，他のヘッダのパラメータとと

もにRBendに渡す．一方，受信したパケットがack^{パケットや}pull応答パケットであった場合，

パケットヘッダに書かれているアドレスはプリミティブ発行時に指定された仮想アドレスなので，

RFendはアドレス変換を行わずに，各種ヘッダのパラメータをRBend^に渡す．RBend^は，RFend

から渡されたデータ書き込み先の仮想アドレスをPATLBを参照して物理アドレスに変換し，SWI の受信バッファから，データ書き込み先の物理アドレスへのDMA転送要求をDMAコントロー ラに発行する．さらに，pushパケットのヘッダに確認応答を要求するフラグが設定されていた場 合，ackパケットを生成する必要があるので，RFend^はpush^{パケットに対応する}DMA^が完了す るのを待ち，その後ヘッダに書かれているack書き込み先のアドレスなどとともにack^パケット

の送出をICONT^のReplierに要求する．なお，ユーザが送受信アドレスのアラインを気にせず任

意のアドレス間の転送を実現できるよう，Martini^{では受信時の}DMA^{転送の最中に}RFend^内の

J-joint[114]と呼ばれるモジュールでアラインメントの調整を行う実装となっている．

一方，受信したパケットがpull要求パケットであった場合，RFendはRVATLBを参照してパケッ トヘッダのSIDを読み出し対象となる領域の仮想アドレスに変換した後，他のヘッダのパラメー タとともにpull応答パケットの発行要求をICONT^のReplier^{に伝える．}Replier^は，pull^応答パ ケットの発行要求を受け付けると，Initiator^がPUSH要求を処理するのとほぼ同様の手順でDMA 要求発行などを行い，パケットを送出する．

到着したパケットのタイプがPUSHやPULLによって生成されるもの以外のハードウェア非対 応なものであった場合，RFendは例外を発生し，オンチッププロセッサなどに割込みをかけて処 理を依頼する．これを利用することで，BOTFなどを利用して発行した独自形式のパケットを，ホ ストCPUやオンチッププロセッサでソフトウェア処理することが可能となる．

PATLB

PATLBはICONTとRCONTによって共有されるため，これらモジュールから独立したモジュー

ルとして実装した．

PATLB^は2-wayセットアソシアティブの構造とし，エントリ数は全体で2048^とした．64bit^の アドレス変換にも対応しており，ホストが64bit OS^{の場合は，}1024エントリのダイレクトマッ プの構造となる．ミスヒットが発生すると，ICONT^やRCONTが例外を発生し，オンチッププロ セッサかホストCPUに対して割込みをかけ，リプレースメント処理を依頼する．

なお，RVATLBの構造もPATLBとほぼ同様であるが，RVATLBはRFendからしか参照されな いため，独立したモジュールとして実装せず，RCONT^{内部に実装を行った．}

DMA Controller (DMAC)

DMACはPCII，DIMMI，内蔵SRAMおよびSWIの送受信FIFOの各モジュール間のDMA転 送の制御に対応し，これによりホストメモリ，外部SDRAM，オンチッププロセッサ用内蔵SRAM およびネットワークの任意の組み合わせでのDMA^{転送を実現する．図}4.10^にDMAC^{の接続を示} す．また図4.11^にDMAC^{の内部構造を示す．}

DMAC^{では転送対象に}1)PCII^，2)DIMMI^，3)SRAM^，4)送受信バッファという固定的な優先順