SpaceWire関連機器の開発/SpaceWireについて

プロジェクト実績

SpaceWire関連機器の開発/SpaceWireについて

弊社では2002年よりSpiceWire関連機器の開発を行っております。
2018年4月末現在では、JAXA （宇宙航空研究開発機構）との共同開発により、様々なSpaceWire関連機器（計10製品）をリリースをしております。
本ページでは、SpaceWire関連機器の開発を行うようになった経緯と、SpaceWireについてFAQ形式で紹介しています。

SpaceWire関連機器の開発経緯

弊社がSpaceWire関連機器を開発する契機となったSpaceCubeの開発経緯を説明します。
IoT時代の到来を予見してT-Engineフォーラム（現TRONフォーラム）が発足した2002年当初から弊社ではNECの半導体部門（当時）やパーソナルメディアと共同でT-Engine開発キットやそのアプライアンスであるTeacubeなどを開発しました。Teacubeに関しては、弊社は主にハードウェア開発を担当し型番をSEMC5701Aとして供給していました。
巨大ブラックホールや超新星残骸などにおける高エネルギー天体現象や宇宙線加速現象などを研究しておられるJAXA宇宙科学研究所の高橋忠幸教授（現在東京大学）がこのTeacubeをご覧になり発案され、関係者の方々と協力して開発したのがSpaceCubeです。
SpaceCubeはTeacubeのハードウェアにSpaceWireのインタフェースを追加した構成になっており、「従来のSpaceWireの開発環境は高価で大きく大学で調達・活用するには無理があったが、SpaceCubeの登場で敷居が下がった」と評価を頂きました。またJAXAや関係者の方々から「日本の宇宙機（人工衛星）の小型化を進めるにあたり、小さなTeacubeやSpaceCubeはその意識を高めてくれた」と嬉しいお言葉も頂きました。
現在ではSpaceCubeの後継品であり、NECスペースシステムと共同開発したSpaceCubeMK2などSpaceWire関連の各種製品をラインナップしております。（SpaceCubeはJAXAとシマフジ電機が共同で登録した商標です）

SpaceWireの概要

SpaceWireとは？

SpaceWireは、宇宙機（衛星）内で、搭載コンポ－ネント間のデータ通信を行うための通信I/Fおよび通信プロトコルの仕様です。
これまでの単品生産、独自仕様のI/Fが少なくなかった衛星製作において、I/Fの共通化を図ることで、コスト削減と製作期間の短縮、技術の蓄積、信頼性の向上などを目的として、ESA、JAXA,NASA,Roskosmosなどがワーキンググループを設立して、標準化作業が行われています。
また、日本国内では、JAXA、大学、メーカーが協同して「日本SpaceWireユーザー会」という組織を構成して、SpaceWireの標準化、機器開発、プロモーションなどを行っています。

SpaceWireの主な特長は、以下のようになります。
・LVDSとDSリンクによるpeer-to-peerの高速シリアルリンク
・幅広い転送速度（２～４００Ｍｂｐｓ）
・自由なパケットサイズ
・簡単なプロトコル（実装時の省リソース、省電力）
・ルータを用いたネットワーク自由なネットワークトポロジー
・自由なトポロジーによって可能になる、冗長系構成

SpaceWireは、コネクタ形状、信号本数、信号レベルなどの物理層と、ノード間でパケットを送受信する際のエンコーディング方式、パケッテング方式、エラー処理手順などを定めていますが、パケットの中身（カーゴ、Cargo）の解釈までは規定していません。したがって、実際にSpaceWireを用いて何らかのデータ転送を行うためには、SpaceWireの上位レイヤに相当するプロトコルを用いる必要があります。
上位プロトコルのひとつとしてRMAP（Remote Memory Access Protocol）が使用されます。
※「SpaceWire/RMAP Library」より引用。

RMAPについて

RMAPとは、Remote Memory Access Protocolの頭文字をとっています。このRMAPは、SpaceWire同様にプロトコル体系がシンプルですので、CPUを必要としないでFPGAなどにハードウエアロジックとしてプロトコルスタックを構築可能です。
RMAPをソフトウエア的に実装すれば、CPUを搭載したソースノードが、（CPUなし）各ターゲットノードのメモリに自身のメモリようにアクセスすることができるようになります。
各ターゲットノードのメモリは、センサーのデータメモリや、パラメータ、例えば温度計モジュールの温度レジスタなどがあります。

SpaceWire FAQ

以降は、SpaceWireに関するよくある質問とその回答です。

Q. 1 : SpaceWireの一番簡単な動作(使い方)はどういうものですか？

SpaceWireでは、基本的に、二つのノード間に接続された二つ(送信用/受信用)のFIFO(先入れ先出しのデータバッファ)のような機能を提供します。したがって、互いに接続されたノードA/Bの間において、リンクの確立が完了したあとは、A側で入れた(送信した)データが、B側で出てくる(受信する)ことになります。こうして、8bitが最小単位のデータをA→B/B→Aと送受信することが、一番簡単な動作となります。普通は、各ノードでは、CPUやローカルバスから、「ホストインタフェース」と呼ばれる中継ロジックを介して、SpaceWireのリンクインタフェースを接続し、CPUやローカルバスから相手ノードへとデータの送受信を行います。
トップに戻る

Q. 2 : SpaceWireパケットの構造はどのようなものか?

SpaceWireレイヤーで規定されているパケット構造は、先頭から、「そのパケットの宛先(パスアドレスおよびロジカルアドレス)」「カーゴ」「パケット終端マーカー(EOP)」です。SpaceWireレイヤーでは「カーゴ」部分の構造については定義していないので、どのようなデータでも送受信することができます。仕様上は「カーゴ」部のデータの長さは無制限となっています。SpaceWireの上でデータ通信(ノードへのRead/Write)を規定するRMAPでは、カーゴ部の構造(各バイト位置のデータの意味)を定義して、「コマンドパケット」や「リプライパケット」などを定義しています。

参考文献
・ SpaceWire仕様書(ECSS-E-ST-50-12C) 4.6章 Figure4-6 「Packet format」の部分
・ SpaceWire仕様書(ECSS-E-ST-50-12C) 9.2章「Packet composition」の部分
トップに戻る

Q. 3 : いろいろな資料で、SpaceWireの転送レートは「2-400Mbps」と表記されていますが、
SpaceWireのリンクレートは何によって制限されますか？

転送レートの上限はおもに、SpaceWire仕様で規定されているケーブル(SpaceWireケーブル;MDMコネクタとケーブル部を合わせたもの)を用いて、許容可能なエラーレートの中で伝搬させることができるLVDS信号の周波数で制限されます。一般には、リンクの動作周波数を高くすると消費電力も増加するため、電力の制限が厳しい宇宙機環境下では、リンクの消費電力(および供給可能な電力)とノード間で転送しなければいけないデータレートのトレードオフにより、実際的な動作周波数が決定されることになります。つまり、大量のデータ転送がどうしても不可欠なリンクでは、消費電力の増加を許容した上でリンクレートを高くします。逆に、深宇宙探査機のように、電力がひじょうに制限された宇宙機では、リンクレートを出来る限り低減し、電力消費を抑えます。SpaceWireでは、リンクレートの上限は仕様で定義されていませんが、下限は2MHzに規定されています。また、原則としてリンクの初期化時は10MHzで運用し、リンクの確立が確認されてから、リンクレートを変更するよう要請されています。

参考文献
・ SpaceWire仕様書(ECSS-E-ST-50-12C) 6.6.5章「Initial operating data signaling rate」の部分
トップに戻る

Q. 4 : ノードから、SpaceWireネットワーク全体へデータをブロードキャストすることはできますか？

基本的にはできません。データの転送方式について、SpaceWire仕様では、「ピアツーピアのノード間でのデータ転送」と「ネットワークスイッチ内でのパケットルーティング」しか規定されていません。SpaceWire仕様の10.2.7.1にあるように、ルーティングスイッチにおいて、ブロードキャストの機能を実装することは禁止されてはいませんが、実装・運用のしかたによっては、パケットの無限ループや、ネットワークのブロックなどの問題が発生する可能性があります。同じ節の中で説明されているように、ネットワーク中のノードすべてに何かのデータを転送したい場合は、発信元のノードから各ノード宛に個別にデータ転送を行う必要があります。例外として、システム時刻(正確にはシステム時刻の下位6ビットの数値と、そのタイミング)をネットワーク全体に配信するための、Time Codeというコントロール文字がありますが、これは「パケット」ではないため、任意のデータを転送することはできません。またTime Codeは、「時刻タイミング」という性格上、ひとつの時刻マスターノードからしか配信してはいけないため、任意のノードから発信されるブロードキャスト通信には利用できません。

参考文献
・ SpaceWire仕様書(ECSS-E-ST-50-12C) 10.2.7章「Packet distribution, broadcast and multicast」の部分
・ SpaceWire仕様書(ECSS-E-ST-50-12C) 4.4章 Figure4-4 「Data and control characters」の部分
・ SpaceWire仕様書(ECSS-E-ST-50-12C) 7.7章｢Time Interface」の説明の部分
トップに戻る

Q. 5 : SpaceWireのレイヤーで、データ転送のQOSは規定されていますか。たとえばパケットの転送の際に、
パケット送信元のノードは、パケット転送が成功/失敗したことを知ることが出来きますか？
また、パケット転送にかかる時間の最悪値を事前に把握することは可能ですか？

SpaceWireのレイヤーでは、パケットの転送(つまり送受信)の成功を相手ノードに通知したり、相手ノードに結果の通知を要求したりすることはできません。また、パケット転送にかかる時間を事前に知ること、また、その時間をある時間幅よりも小さくなるように制限することなどはできません。
たとえば、あるノードからパケットの送信を開始し、パケット終端マーカー(EOP)を送り終えるまでのあいだ、相手ノードとの間のSpaceWireリンクがエラーにならなければ(リンクが確立したままであれば)、相手ノード内のSpaceWireリンクインタフェースの受信バッファまでは、送信したパケットが届いたことが想定されます。しかし、そのパケットが相手ノードのホストインタフェース(CPUやローカルバスなど)まで正常に送られたかは知ることができません。相手のCPUやローカルバスまでパケットが正常に転送されたことを確認したい場合は、SpaceWireレイヤーよりも上位に、「アクノレッジ(転送の成功/失敗通知)をともなうようなプロトコルレイヤー(たとえばRMAPやSpaceWire RT)を定義・使用することになります。実際、RMAPにおいては、「リプライパケット」により、転送(RMAPアクセス; 正確には「ひとつのRMAPトランザクション」)の成功/失敗などを知らせることができます。

トップに戻る

Q. 6 : ロジカルアドレスとパスアドレスの違いと、適用すべき箇所、注意点は何ですか？

ロジカルアドレスは、SpaceWireネットワーク内の各ノードに割り当てられた固有のノードIDのようなもので、基本的にネットワーク内で重複してはいけません。インターネットにおけるIPアドレスのようなものと考えて大きな間違いはありません。SpaceWireネットワークでは、32-254(decimal)がロジカルアドレスとして利用可能な番号です。利用可能な番号が少ないように思えるかもしれませんが、SpaceWireはもともと宇宙機内部のネットワーク用に設計されており、宇宙機内では200個以上のノードからなるネットワークは必要となることはほとんどあり得ないため、この程度の割当で十分なのです。ネットワーク内でロジカルアドレスを用いたパケット転送を行う場合は、ネットワーク内のすべてのルーティングスイッチに、32-254の各ロジカルアドレスを受け取ったら、どのポートにそのパケットをフォワードするかの関係を記述した「ルーティングテーブル」を設定する必要があります。ルーティングテーブルの作成の際には、ネットワークの接続トポロジーを事前に把握しておく必要があります。インターネットのような超大規模なネットワークではそのようなことはひじょうに困難ですが、衛星内ネットワークの場合は、それ自身で閉じており、概して小規模であり、動的なノードの増減がないため、事前にネットワークの全体像を把握しておくことは可能と考えられます。
一方、パスアドレスは、パケットが通るべきルーティングスイッチ上の道筋を、各ルーティングスイッチを通過する際にパケットが通るポート番号を順に並べて表現したものです。したがって、あるノードからあるノードへのパスアドレスを構築する際は、送信元ノードから宛先ノードまでのネットワークの接続トポロジーを事前に(送信前に)把握しておく必要があります。

ロジカルアドレスを用いる場合に生じうる問題の中で代表的なものがパケットの「ピンポン」の問題です。これは、ルーティングスイッチのルーティングテーブルの設定を誤って、あるロジカルアドレスのルーティングのルートがループ状にしてしまったときに、そのロジカルアドレス宛のパケットを転送しようとすると、そのパケットはどのホストインタフェースにも届かないまま、ぐるぐると同じループ内を循環するようになってしまい、ネットワークの転送効率を低下させたり、場合によってはあるネットワークのパスをロックしたりしてしまいます。パスアドレッシングにおいては、パケットがルーティングスイッチを通過する度に、一文字(1バイト)ずつパスアドレスのリストが消去されていくため、パスアドレスだけを使っている場合は、ピンポン問題は発生しません(つまり、パケットは最終的に必ず、どこかのノード、もしくはルーティングスイッチで受信されることになります)。
パスアドレッシングの使用箇所の例：ルーティングスイッチがそれぞれに固有の設定(ルーティングテーブルやリンク周波数の情報など)を保持していない場合、ネットワークの初期化時(たとえば電源投入時)に、ひとつのノード(初期化作業の親ノードのようなもの)から、RMAPなどのプロトコルを用いてルーティングスイッチの設定や、接続されたノードの探索を行う必要があり、この時点ではルーティングテーブルが未設定なので、ロジカルアドレッシングは利用できず、パスアドレッシングを利用することになります。

参照文献
・SpaceWire仕様書(ECSS-E-ST-50-12C) 10.2章「SpaceWire routing switches(normative)」の部分
トップに戻る

Q. 7 : SpaceWireで使用するケーブルはどんなものですか？

MDM9ピンのコネクタを、仕様書で規定されたピンアサインで結線したものを使用します。ケーブル部分の信号線の太さ、シールドの構造、フィラーの強度などが規定されています。MDMは取り扱いが少々難しく、比較的高価なため、シマフジ電機製のSpaceWire関連製品では、代用品としてDSUB9ピンコネクタを使用しています。また、SpaceCubeなどでRJ45のクロスケーブルをSpaceWireケーブルとして利用するための分配基盤も存在しており、DSUBコネクタよりも小さいRJ45コネクタを用いることで、基板上の配置スペースを削減したい場合などに利用することができます。

参考文献
・SpaceWire仕様書(ECSS-E-ST-50-12C) 5章「Physical level(normative)」の部分

以下の図は、SpaceWire仕様書(ECSS-E-ST-50-12C) 5章から引用

トップに戻る

Q. 8 : SpaceWireケーブルを介して接続される機器間のグラウンド接続はどのようになりますか？

SpaceWireケーブルでは、二つの機器間のグラウンドを接続する信号線はないので、ケーブルを介した接地はなされません。グラウンドの接続は、電源部分を通じて行うべきであり、SpaceWireケーブルを接続する前にグラウンド電位は共通にしておかなければいけません。万が一、SpaceWireケーブルを接続する前に、両機器間のグラウンド電位に数V以上の差がある場合、使用しているLVDSレシーバによっては、クランプダイオードを過剰な電流が流れることで、レシーバICを損傷する可能性があるため、注意が必要です。

参考文献
・SpaceWire仕様書(ECSS-E-ST-50-12C) 5.4章「Cable assembly」の部分

以下の図は、SpaceWire仕様書(ECSS-E-ST-50-12C) 5.4章から引用

トップに戻る

Q. 9 : SpaceWireで転送できる最大パケット長はどれだけですか？

SpaceWire仕様ではパケット最大長は規定されていません。実際の運用では、送信先ノードのホストインタフェースが受け付けられる最大のパケット長によって、最大長が規定されることになります。また、SpaceWireネットワーク上に長大なパケットを流す際に問題となるのは、ネットワークのブロックです。たとえばノードAからノードBへの転送の場合、ルーティングスイッチ内のルーティングマトリックスのノードA→Bの方向のワームホールルーティングが形成されたままになるので、他のノードがBへパケットを送ろうとしても、A→Bの転送が終了するまでその転送はブロックされます。つまり、ネットワークを流れる平均パケットサイズが長くなり、パケット転送の頻度が高くなると、一般的には、このようなブロックによって発生するパケット転送のスキュー(遅れ)が大きくなります。

トップに戻る

Q.10 : 空パケットの送信は可能ですか？

SpaceWire仕様の9.2.3章「Cargo」の説明で「SpaceWireパケットのカーゴ部は1文字以上のデータを含まなければいけない」とされているとおり、意図的な空パケットの送信は、基本的には想定されていません。ただし、8.9.3章の説明にあるように、パケット送信中にリンクエラーが起きた場合、送信途中のパケットが途中でEEPにより強制的に終端され、その状態でネットワークをルーティングされていくときに、パスアドレスが1文字ずつ削除されていき、最終的にEEPだけが残ったパケットとしてどこかのノードに受信される可能性があります。そのような場合、そのEEPは単に無視されると規定されています。

トップに戻る

Q.11 : リンク初期化時のNULL/FCTシーケンスの際にFCTは、ひとつだけ送られてきますか？
それとも連続して送信される可能性がありますか？

リンク初期化中でも、FCTの送信は通常と同じようになされるので、受信バッファに8バイト以上の空きがありさえすれば、FCT送信の上限(7個)まで、連続して送信してもよいことになっています。したがって、初期化時でも、相手ノードから複数のFCTを連続して受信する可能性があります。

トップに戻る

Q.12 : リンクにエラーが発生して、コネクションが切断されたときに、SpaceWireリンクI/Fの送信FIFOに
残っていたデータはどのように処理されますか？

EOPに到達するまでデータを読み飛ばして、EOPに達したら、EEPを送信します。リンクエラーが発生した時点で、パケットの送信中だった場合は、エラーが発生したところでパケットの送出は中断され、EEPによって終端されることになります。送信バッファ全体はリセットされないので、送信途中だったパケットの次のパケットも送信バッファに入っていた場合は、リンク再確立後、そのパケットの先頭から送信が再開されます。

参考文献
・SpaceWire仕様書(ECSS-E-ST-50-12C) 11.4章「Link error recovery」の部分

トップに戻る

Q.13 : RMAPは何の略で、どのような機能を提供するものですか？

Remote Memory Access Protocolの略で、SpaceWireネットワークに接続されたノード間で、データの読み書き(Read/Write)の機能を提供します。あるノードから別のノードのメモリ空間(そのノードのローカルバス空間)のデータに簡単にアクセスすることができます。

トップに戻る

Q.14 : RMAP通信の基本的な流れはどのようなものですか？
また、SourceノードとDestinationノードの関係、
コマンドパケットとリプライパケットの関係はどのようなものですか？

ノードAからノードBへのRMAPアクセスを考えます。ノードA上のプログラムが、Read要求を発行すると、ノードA内のRMAPロジックI/Fが、RMAPコマンドパケットを生成し、SpaceWire経由で送り出してトランザクションを開始します。コマンドパケットを送出するノード(ノードA)がSourceノードです。一方で、RMAPコマンドパケットの宛先(Destination)となり、そのコマンドパケットを受け取って、Read/Writeの処理を行い、リプライパケットを返すのがDestinationノードです。

RMAP仕様書(ECSS-E-50-11 Draft F)の6章から引用しています

 トップに戻る

Q.15 : RMAP I/FとSpaceWire I/Fの関係はどのようなものですか？

RMAPは、SpaceWireの上位プロトコルなので、RMAP I/FはSpaceWireリンクI/Fを利用して動作するような関係になります(下図参照)。
SourceノードにおけるRMAP I/F： RMAP IPコアは、CPU上で動作するソフトウエアからRMAP Read/Writeなどのリクエストを受付けると、RMAPコマンドパケットのバイト列を生成し、SpaceWireリンクI/Fに渡してSpaceWireリンクへと送出します。逆に、SpaceWireリンクで受信したパケットをRMAP Replyパケットとして解釈し、ソフトウエアにRMAPアクセスの結果を通知します。
DestinationノードにおけるRMAP I/F： RMAP IPコアは、SpaceWireリンクI/Fで受信したRMAPコマンドパケットを受け取って、中身を解釈し、ローカルバス経由でメモリなどに対してRead/Writeの処理を実行し、結果をRMAPリプライパケットとして構築して、そのバイト列をSpaceWireリンクI/Fに渡してSourceノードに送り返します。

トップに戻る

Q.16 : RMAPパケットの構造はどのようになっていますか?

大きく分けて、RMAPパケットには「コマンドパケット」と「リプライパケット」の2種類があります。それぞれ、RMAPヘッダー部分とRMAPデータ部分から構成されており、SpaceWireパケットの「カーゴ」部分に格納されます。最終バイトは、SpaceWireレイヤーのEOPになります。下図の各四角が、1バイトを表しています。
RMAP仕様書(ECSS-E-50-11 Draft F)の6章から引用しています。

[例]RMAP Read Replyパケットの構造

参考文献

・ RMAP仕様書(ECSS-E-50-11 Draft F) 6.3～6.5章のパケット構造の説明の部分
とくに、Packet Type/Command/Source Path Address Lengthフィールドは、8ビットの各ビットに意味が割り当てられているので、詳細は仕様書を参照のこと。

トップに戻る

Q.17 : RMAPコマンドパケットのヘッダー中の「Destination Key(ディスティネーションキー)」は
どのように利用するものですか？

RMAPアクセスにおいて、そのアクセスが許可されたものであるかを確認するためのパスワードのようなもので、RMAPノードごとに適当な値を設定しておくことになります。各RMAPアクセスにおいては、RMAPコマンドパケットに格納されたディスティネーションキーが、ノード固有のディスティネーションキーと異なる場合は、アクセスが許可されません。このような場合はエラー(「Invalid Destination Key」)として処理されるため、あるノードの不具合により不正なRMAPパケットが生成された場合でも、ディスティネーションキーの部分がランダムな値になっている場合は、255/256の確率でそのアクセスはリジェクトされることになります(しかし、1/256の確率では許可される可能性があるので、不正なアクセスをより排除するためには、対象となるアクセスを許可/不許可するためのレジスタを設けて、まずそちらでアクセス許可を設定できるようにし、ディスティネーションキーだけに依存しないように実装する必要があります)。
トップに戻る

Q.18 : RMAPコマンドパケットのRMAP Header CRCが不正な場合、
受け取った側のノードではどのように処理されますか？

そのような場合は、RMAPコマンドパケットにおいて最も重要な情報、つまり、コマンドの種類(Read/Write)や、パケット送信元(source node)、アクセス先アドレス、アクセス長などの妥当性が確認できない(内容が書き変わっている可能性がある)ため、処理は何も実行されず、パケット全体が単に無視されることになります。RMAP Replyパケットも返信されないので、Sourceノード側ではReplyパケットの永久待ちに陥らないよう、適当なタイムアウトをもうけてエラー処理を行う必要があります。
トップに戻る

Q.19 : RMAPにおいて、ハンドシェイクを伴わない通信は可能ですか？

RMAPコマンドパケットを送信する時点で、ヘッダーのPacket Type/Command/Source Path Address Lengthフィールド中のAcknowledgeの有無の設定を、no ackモードにしておけば、RMAP Writeに関しては、Acknowledgeなしの通信が可能になります。もちろんこの場合はアクセスが成功したかどうかは、自動的にはわからないので、一般的には別のReadアクセスなどを行うことで確認が必要です。RMAP Readは、データを読み出すという性格上、原理的にかならずAcknowledge(つまり、RMAPリプライパケット)が返ってくることになります。
RMAP仕様書(ECSS-E-50-11 Draft F)の6章から引用しています。

トップに戻る

Q.20 : RMAP通信に伴うオーバーヘッドはどういったものがありますか?

以下のようなオーバーヘッド要因があります。RMAPアクセスのたびに、これらのオーバーヘッドのうち、どれが支配的に転送速度を律速しているかを意識してハードウエアロジック/ソフトウエアを作成することが高速化につながります。

1.RMAPヘッダー部
・RMAP Commandパケットや、RMAP Replyパケットには、ヘッダー部があり、最短でもそれぞれ16バイト、8バイトを占めます。従って、転送すべきデータ
が短い場合、ヘッダー部をSpaceWireレイヤーで送信するのにかかる時間のほうが長くなり得ます。逆に、1パケットで転送すべきデータが大きい場合(たとえば1kB以上)の場合、ヘッダーの相対的なサイズは1%以下となり、あまり全体の転送速度に影響を与えません。

2.Destination側のローカルバスのアクセス時間
・RMAP Read/Writeともに、Destination側のローカルバスのアクセスが行われます。このローカルバスアクセスが遅いと、Replyパケットを用意するまで
にかかる時間が長くなり、結果的に、Source側の待ち時間が増大します。各Destinationノードのアクセス時間を定量的に把握しておくことが重要です。

3. トランザクション管理のための処理
・Source側では、複数のRMAPトランザクションを実現するために、コマンドパケットを送出する際に、このコマンドパケットの送信元タスク(スレッド)、トラ
ンザクションIDおよび宛先ノードの対応関係を記述した表を管理する必要があります(ディスクリプタという表現をすることもあります)。リプライパケットが受信されると、その中に書かれたトランザクションIDと送信元ノードの情報から、この表を逆引きして、このパケット内のデータを渡すべきタスクを判別します。このような処理(ディスクリプタの作成や逆引き)にかかる時間が転送速度において支配的な場合は、ディスクリプタの構造や逆引きのアルゴリズムを見直す必要があると思われます。

4.データのコピー
・データ処理を行うソフトウエアを記述する際の一般論として、メモリ間でのデータのコピー回数が増えると、実行速度が圧倒的に低下します。これは、
CPUの動作速度に比べて、CPU⇔メモリ間のデータ転送速度が遅いことに起因します。ソフトウエア内でのデータコピー回数は最小にするべきです。

参考文献
・RMAP仕様書(ECSS-E-50-11 Draft F) 6.3～6.5章のパケット構造の説明の部分
トップに戻る

Q.21 : RMAP通信を高速化するヒントはありますか?

一般的に、以下のような方針で開発を進めると、RMAPアクセスに伴うオーバーヘッドを低減し、データ転送と処理の高速化を実現できます。傾向としては、アクセスの粒度(一回一回のアクセスの際のデータサイズ)を大きくするほど、全体としてのデータ転送速度は向上します。逆に粒度の小さいアクセスを繰り返すと、オーバーヘッドの寄与が増大し、転送速度が低下します。
1.連続でアクセスする可能性があるレジスタは、連続したアドレス空間に配置し、アクセスの際は、個々のレジスタに単発でアクセスするのではなく、複数のレジスタをまとめてアクセスする。

2.DAQの場合で、検出器から生成されるイベントがそれほど大きくない場合(たとえば1イベント16バイトなど)、複数のイベントをボード上のメモリなどでバッファリングして、10イベントや100イベントまとめて転送する

・この場合、「何イベント分のデータが入っているか」というレジスタを設置したり、「現在バッファリング領域を読み出したりしているので、新規にデータを書
いてはいけない」というフラグを管理する必要が生じますが、RMAPアクセスに伴うオーバーヘッドは、1イベントずつ転送したときに比べて相対的に1/10や1/100になります。
トップに戻る

Q.22 : SpaceCubeで利用可能なOSの種類は？

TRON系のT-KernelとRTLinuxです。衛星搭載品の開発との関係から、「SpaceWireユーザ会」ではT-Kernelを標準として利用しています(たとえばASTRO-Hの衛星搭載品では、TRON系/T-Kernel系のOSが採用されることになっています)。
トップに戻る

Q.23 : SpaceCubeを用いてSpaceWire関連の開発・試験を行うために必要な環境はどのようなものですか?

Linux/Mac/Windows(cygwinの追加が必要)の各環境で、SpaceCubeの操作、SpaceCube用ソフトウエアのコンパイルが行えます。SpaceCubeの操作(コマンドラインへの出力、コマンドライン出力の表示)を行うためのターミナルソフトは、Linux/Windowsでは、開発環境のCD-ROMの中に入っている「gterm」を用います。Macの場合は、gtermの代わりに、標準でインストールされている「screen」というプログラムを用いてSpaceCubeと通信を行います。通信時のビットレートは115200bpsです(ソフトウエアによっては、あらたに設定する必要があります)。
《gtermでSpaceCubeとシリアルケーブルで接続する場合の例》

/usr/local/te/tool/Linux-i686/etc/gterm -b -X -l/dev/ttyS0

《screenでSpaceCubeとUSB-シリアル変換ケーブルで接続する場合の例》

screen /dev/tty.usb****** 115200

(上記の例で、/dev/ttyS0や/dev/tty.usb******の部分は、それぞれの環境で異なるので、「ls /dev/tty*」として、どのようなポートがあるか確認してから入力・実行してください。また、Linuxの場合は、/dev/ttyS0などのパーミションを変更して、一般ユーザでも/dev/ttyS0を利用可能にする必要があるかもしれません;下記参考文献を参照してください)

SpaceCubeのCPUであるVR5701用にプログラムをコンパイルするためのgccコンパイラも、Linux/Windowsでは、開発環境のCD-ROMの中に入っているgccを用います。Macの場合は、Mac用にビルドされたgccがSpaceWire Wikiでダウンロード可能になっています(インストール方法もSpaceWire Wiki上にアップロードされています)。

<参考文献>
gterm関連
・SpaceCube同梱CD-ROM内の「GNU開発環境説明書(VR5701)」(develop.pdf)の2.1.3章「Teacube/VR5701 GNU 開発環境を初めてインストールする場合」の部分
・SpaceCube同梱CD-ROM内の「GNU開発環境説明書(VR5701)」(develop.pdf)の4.4章「プロセスベースプログラム」の部分
gcc関連
・SpaceCube同梱CD-ROM内の「GNU開発環境説明書(VR5701)」(develop.pdf)
・SpaceWire Wikiのアドレス：http://www.astro.isas.ac.jp/SpaceWire/wiki/
トップに戻る

Q.24: SpaceCube開発環境の構築は何から始めればよいですか？

基本的には、付属CD-ROMに入っているPDF形式のマニュアルにそって作業することになります。まず、SpaceCube同梱のCD-ROMに入っている「Teacube/VR5701評価キット取扱説明書」(manual.pdf)を参照してください。SpaceCube用プログラム開発のしかたについては、「Teacube/VR5701 評価キット GNU開発環境説明書」(develop.pdf)を参照してください。「SpaceWireユーザ会」のメンバーは、「Eclipse」という統合開発環境を用いたプログラム開発を行うため、SpaceWire Wikiから入手可能な「SpaceWire/SpaceCube Tutorial」と「SpaceWire/RMAP Library」という二つのドキュメントを参照してください。
トップに戻る

Q.25 : 「Teacube/VR5701 評価キット GNU開発環境説明書」(develop.pdf)では、「モニタベースプログラム」
「T-Kernelベースプログラム」「プロセスベースプログラム」など、複数の種類のプログラムの作成方法が
記述されていますが、SpaceWireを利用するときはどの形式のプログラムを開発するのですか？

SpaceWireの機能を利用するプログラムは、「プロセスベースプログラム」の形式で開発することになります。この形式が、LinuxやMacOS Xで通常のプログラムを記述するときとほとんど同様の機能(マルチスレッド、プロセス間通信、ファイル操作、デバイスドライバの利用など)が行えるものです。「モニターベースプログラム」「T-Kernelベースプログラム」では、より低位のレベルの機能(生のOSの機能に近いもの)しか利用できないため、SpaceWire関連の開発において、それらの形式を用いてユーザがプログラムを記述することはありません。
トップに戻る

Q.26 : T-Kernelでテキストファィルの編集はできますか？

残念ながらコマンドライン上で動作するエディタプログラムは同梱されていません。
トップに戻る

Q.27 : SpaceCubeをGUIで使用することはできますか？

標準状態のSpaceCubeのRGBコネクタにディスプレイを接続して起動すると、Personal Media社製のGUIの操作環境が表示されます。USBポートに、キーボードとマウスを接続すれば、ウインドウの移動やキー入力が可能になります。
トップに戻る

Q.28 : SpaceCubeでグラフィクスを扱うようなプログラムを作成・実行することはできますか?

SpaceCubeに付属している、Personal Media社製のT-Shellというライブラリを用いると、ウインドウを表示したり、GUI部品を配置したりということができます。Win32API/Aqua/GTKなどとは異なる独自仕様のAPI群のみ提供されているため、LinuxやMacOS X、Windows上などで動作しているGUIプログラムを、そのままの形で動作させることはできません。

<参考文献>
・SpaceCube同梱CD-ROM内の「PMC T-Shell プログラミング解説書」(tsh_guide.pdf)
トップに戻る

Q.29 : SpaceCube上でROOTやPAWなどの、データ解析・保存・表示のためのC/C++ライブラリは使用できますか？

ROOTやPAWがT-Kernelをサポートしていないため、使用できません。データストレージ(HDD)への書き込みスピードや、使用可能なライブラリ、処理スピードなどを考慮すると、SpaceWire経由で取得した検出器データの保存や表示は、SpaceCube上ではなく、PC上で行う方がよいと思われます。SpaceCubeからPCにデータを転送する方法は、TCP/IP通信の関数を直接記述しても可能ですが、少し敷居が高くなります。後述のSpaceWire/RMAP Libraryでは、TCP/IPを簡単に行ったり、データ取得プログラムそのものをSpaceCube上ではなく、PC上で動作させたりする機能も提供されています。
トップに戻る

Q.30 : SpaceCubeのネットワークの設定を変更する方法を教えてください。

コマンドラインで
netconf -c
と入力すると、IPアドレスやDNSサーバ名を入力するためのプロンプトが表示されます。値を変えない場合はそのままリターンキーを押せばOKです。最後に聞かれるwlan(y/n)というのは、無線LANの設定項目なので、無線LANを利用しないSpaceCubeでは基本的にはnを入力すれば大丈夫です。
固定IPアドレスではなく、DHCPでIPアドレスを取得させる場合は、IPアドレスの設定を「0.0.0.0」とします。

参考文献
・SpaceCube同梱CD-ROM内の「Teacube/VR5701評価キット取扱説明書」(manual.pdf)の4.6章「ネットワーク」の部分
トップに戻る

Q.31 : netconfコマンドでLANの設定を正しく変更したのですが、ネットワークに接続できません。

netconfコマンドで設定変更後、SpaceCubeを再起動しないと変更が有効にならない場合があるので、再起動を試みてください。また、電源投入後にLANケーブルを接続してもDHCPのアドレスの取得などが行われないことがあるので、SpaceCubeの電源投入時にケーブルを接続しておくようにしてください。Ethernet I/Fが動作しているかどうかは、LANケーブルコネクタ横のLEDが点灯しているかどうかで確認できます。
トップに戻る

Q.32 : SpaceCubeとPC/Macでファイルをやりとりする方法はありますか？

SpaceCubeとPC/Macの間のファイルの転送には、二つの方法があります。

1 FTPでの転送
・SpaceCubeのT-Kernelには、fput/fgetというコマンド(それぞれftp put/ftp getの略と思われる)が同梱されており、これらを用いてftpサーバと
ファィルのやりとりが可能です。多くのLinuxディストリビューションやMacOS Xでは、標準でftpサーバがインストールされているので、
システム環境設定の「共有」から、その機能をonするだけで、SpaceCube側からMac内のファィルにアクセスすることができます。
たとえば、実際の開発を始めるとすぐに必要となる、/usr/local/te/SpaceWireRMAPLibrary/build/t-kernel/main_rmaphongoというプログラムを、
開発用PC/Mac上からSpaceCubeへダウンロードしたい場合は、PC/Mac側のftpサーバを起動した状態で、SpaceCubeのコマンドライン上から、
fget (MacのIPアドレス):/usr/local/te/SpaceWireRMAPLibrary/build/t-kernel/main_rmaphongo
と入力します。Mac側にログインするためのユーザ名とパスワードを入力するよう求められ、ログインが成功すればファィルの転送が開始されます。
転送速度は、数MB/s程度なので大容量のファィルでも瞬時に転送することができます。

2 シリアルケーブル経由での転送
・gtermを利用している場合は、接続しているPCとの間で、ファィルのやりとりが可能。ただし、転送速度は115kbpsなので、1Mbps程度以上のファィルを
転送する場合は、かなり時間がかかるため、FTPでの転送が推奨されます。PC→SpaceCubeの転送は、SpaceCubeのコマンドライン上で
recv -d (ホストPC側でのファィルパス)
とすることで、転送が開始されます。ファィル名が長い場合、T-Kernelの標準のファィル操作プログラムでは表示・削除できない場合があるので、
注意が必要です(8文字+3文字程度なら大丈夫)。
トップに戻る

Q.33 : SpaceCube(T-Kernel版)のコマンドラインで使用可能なコマンドはどのようなものですか？

かなりUNIXに近いコマンドが利用できるのですが、微妙な違いがあるため、よく使うコマンドの対応表を掲載しておきます。オプションや引数の順番など、各コマンドの詳細は、SpaceCube同梱CD-ROM内の「Teacube/VR5701評価キット取扱説明書」(manual.pdf)に記載されています。

T-Karnel	UNIX(Linux)	機能
cd	cd	作業ﾃﾞｨﾚｸﾄﾘ変更
ls	ls	ﾌｧｲﾙ一覧の表示
mkf	touch	ﾌｧｲﾙ作成
cp	cp	ﾌｧｲﾙのｺﾋﾟｰ
ren	mv	ﾌｧｲﾙ名変更
rm	rm	ﾌｧｲﾙ削除
ln	ln	ﾘﾝｸ作成
tp	cat	ﾌｧｲﾙ内容表示
date	date	日時表示・設定
df	df	ﾃﾞｨｽｸ容量表示
ps	ps	ﾌﾟﾛｾｽ一覧表示
kill	kill	ﾌﾟﾛｾｽ強制終了

トップに戻る

Q.34 : SpaceCube(T-Kernel版)のコマンドラインでUNIXと同様のコマンドを使用する方法はありますか？

SpaceCube同梱CD-ROM内の「Teacube/VR5701評価キット取扱説明書」(manual.pdf)の9章に記載されているように、よく使用するコマンドに関しては、UNIXと同様のコマンド・オプションが利用できるようなプログラム群が用意されています。上の表中でコマンド名が異なるmvや、用意されていないpwdも利用できるようになります。
具体的には、それらのプログラムが格納されている/SYS/bin/uxというディレクトリを以下のようにして「path」コマンドで実行パスに追加すれば、使用できるようになります。
[/SYS]% path /SYS/bin/ux *
参考文献
・「Teacube/VR5701評価キット取扱説明書」(manual.pdf)の9章
トップに戻る

Q.35 : SpaceCubeで、SpaceWire通信を行うための方法はどのようなものですか？

SpaceCubeに搭載されたFPGAの中にSpaceWire通信用のロジック(IPコア)が入っています。このIPコアの中には、独立した3つのSpaceWireポート用のロジックが入っています(以下のブロックダイアグラム参照)。FPGA自体はPCIバス経由でCPUに接続されています。FPGAのピンに引き出されたSpaceWireの信号線は、フラットケーブル経由で、3つの物理的なコネクタ(DSUBかRJ45)へと接続されています。パケットの転送をするときは、シマフジ電機から提供されているドライバおよびAPIを使用します(spw_write()/spw_read())。これにより、送信/受信データが、SpaceWireロジック内の送信/受信バッファに、PCIバス経由で書き込まれ/から読み込まれます。ドライバAPIを直接利用している場合は、RMAPのパケット解釈や、トランザクションの管理という仕事は、ユーザが自分でソースコードを記述する必要があります。
(次の質問と解答も参照してください)

トップに戻る

Q.36 : RMAP通信を簡単に行う方法はありますか？

「SpaceWireユーザ会」では、SpaceWire/RMAP Libraryというソフトウェアライブラリを提供しており、それを利用すればSpaceWireネットワークにおけるRMAP通信を簡単に利用できるようになります。
(さらに次の質問と解答も参照してください)
トップに戻る

Q.37 : SpaceWire/RMAP Libraryとは、どういったものですか？

「SpaceWireユーザ会」によって開発された、SpaceWireとRMAPを簡単に扱うためのソフトウェアライブラリです。C++言語で記述されており、このライブラリを用いたプログラムは、SpaceCubeと普通のPC上で動作するようになります。このライブラリは、RMAPの機能を標準で実装しており、Read()/Write()というメソッドをコールするだけで、RMAP通信が可能となる。
また、このライブラリの内部では、各社のSpaceWireドライバのAPI関数コールを、オブジェクト指向の考え方でまとめなおし、より直感的なクラス/メソッドの集まりに構成しなおしています。これにより、SpaceWire IPコアの種類や、CPUの種類(SpaceCube/PC/Mac)にかかわらず、どんな環境でも、同じ方法でSpaceWire/RMAP通信ができるようになっています。これらのことにより、結果的に、作成したプログラムに高いポータビリティ(可搬性)を持たせることができ、開発や試験、デバッグの効率を高めることができます。
トップに戻る

Q.38 : シマフジ電機製SpaceWire IPコアを用いたSpaceCube上で、Time Codeを扱う方法はありますか？

Time Codeの送出は、IPコアのタイムコード送出レジスタにPCIバス経由で、送りたいTime Codeの値を書き込むことで可能です。送出のタイミングは、タスクの優先度による実行待ちとPCIバスアクセスにかかる時間、さらに、現在送信中のデータ/コントロールキャラクタの送信完了を待つ分だけ遅れるので注意が必要です。
Time Codeの受信に関しては、IPコアのReceiverロジックから、ドライバレイヤーまで割り込みによって通知されますが、現状ではユーザプログラムまでは割り込みがかからない仕様になっています。タイムコード受信ごとに何か処理をしたい場合は、ユーザプログラムの割り込みハンドラをコールバックする仕組みをドライバに追加する必要あります。ユーザプログラムから現在のタイムカウンターの値を知ることは、PCIバス経由でIPコア内のTime CodeレジスタをReadすれば可能です。
トップに戻る

Q.39 : rmaphongoとはどういうソフトウエアですか?

rmaphongoは、SpaceWire/RMAP Libraryに同梱されている例題プログラムのひとつで、コマンドラインからRMAP通信(RMAP Read/RMAP Write)や、SpaceWireパケットの単純な送受信、TimeCodeの送信するための機能を提供しています。それらの機能は、SpaceWire/RMAP Libraryのクラス群を用いて実装されており、ソースコードをみると、実際にどのようにSpaceWire/RMAP Libraryを使えばいいかがわかるようになっています。
また、rmaphongoを使えば簡単にRMAP Read/Writeができるため、各種SpaceWireボードとSpaceCubeを接続した測定などの際に、レジスタアクセスや、SDRAMの中身を読み出しという作業を手早く試験することができます。

<参考文献>
rmaphongoの実行形式のソースコードは、SpaceWire/RMAP Libraryの
SpaceWireRMAPLibrary/source_Executables/main_rmaphongo.cc
という場所に保存されています。注意としては、このソースコードは読みやすさのために、ひとつのファイル内のひとつのクラスにいろんな機能をまとめて記述してしまっています。本当のDAQソフトウエアなどでは、開発の見通しをよくし、保守・運用をしやすくするために、機能ごとのクラス分け、ファイル分けを徹底すべきなので、rmaphongoのソースコードを改変して何かのDAQプログラムをつくるということは、しないほうがよいと思われます(新規にクラスを設計して開発したほうがよい)。
トップに戻る

Q.40 : SpaceCubeとSpaceWire DIOボードなどを接続して、rmaphongoでレジスタアクセスを試みましたが、
SpaceWireのリンクオープンのところでリンク確立に失敗しているようです。
どのような原因が考えられますか?

以下に考えられる原因と、解決方法の案を示します。

1.SpaceCube内のSpaceWire FPGAに書き込まれているSpaceWire IPコアのバージョンと、SpaceCubeにインストールされたドライバソフトウエアのバージョンの不整合

・SpaceCube上で、「ls」を実行すると、CFカード内のファイルが確認でき、「spw」というファイルがあるはずです。これがシマフジ電機製SpaceWire IPコア
用のドライバプログラムです。SpaceWire IPコアのバージョンとこのドライバのバージョンが整合していないと、プログラム内でSpaceWireポートのオープンや、リンクの確立を試みても失敗してしまい、SpaceWire通信ができません。

・この問題は、SpaceWireドライバを新しいものに置き換えることで解決するかもしれません。SpaceWire/RMAP Libraryのビルドを実行すると生成される、
SpaceWireRMAPLibrary/driver/spc1_shimafuji3/spc_driver/spwというバイナリが、SpaceCube用のSpaceWireドライバです。これをSpaceCubeに転送して、SpaceCubeを再起動し、新しいドライバソフトを以下のようにロードしてください。

> lodspg spw(リターン)
※STARTUP.CMDにこのコマンドが記述されている場合は、SpaceCubeを再起動するだけで自動的にドライバがロードされます。

2.SpaceCubeと接続相手ノードの間での、リンクスピードの不整合
・SpaceWire通信は、非対称なリンク周波数で通信が可能ですが、あるノードが受け入れ可能な通信レートの上限は、ノードごとに(実装に依存して)異なり
ます。たとえば、SpaceCubeからの送信クロック(Tx Clock)の周波数が、接続先ノードの受信可能なクロック周波数よりも高い場合、受信側のノードで受信クロック(Rx Clock)の再生ができず、受信ロジックがただしく動作しないため、リンク初期化時のNULLやFCTがただしく受信されずに、リンクが確立しません。

・たとえば、シマフジ電機製SpaceCube用SpaceWire IPコアのデフォルトのリンクレート(つまり、Tx Clock)は100MHzになっています(※)。いっぽう、MHI製
Universal IOボードの受信可能クロック周波数は100MHzよりも小さいため、この状態ではSpaceCube→MHI Universal IOボードの向きのリンクが確立せず、SpaceWire通信ができません。
※SpaceCube側のTx Clockはユーザソフトから変更可能

・この問題は、SpaceCube上のプログラムから、リンクレートを変更(具体的には、Tx Clockを小さくする)ことで解決します。
たとえば、シマフジ電機製SpaceWire IPコアをSpaceWire/RMAP Libraryの環境で使用している場合は、

driver/spc1_shimafuji3/spw_if.cの冒頭でリンクレートを宣言している、
spw_txclk_div txclk_div=TXSPD_100MBPS;
という部分を、

spw_txclk_div txclk_div=TXSPD_10MBPS;

などに書き換えることで対応します。上の例ではTx Clockを100MHzから10MHzに変更しています。変更を反映するために、build/内でmake cleanしたあとで、再度makeを実行してください。spw_txclk型の変数の取りうる値は、spw_if.hの中で定義されています。

トップに戻る

Q.41 : SpaceCubeとSpaceWire DIOボードなどを接続して、rmaphongoでレジスタアクセスを試みましたが、
RMAP ReadやRMAP Writeを実行すると、「Reading…/Writing…」というメッセージが出たまま処理が
止まってしまいます。どのような原因が考えられますか。

以下に考えられる原因と、解決方法の案を示します。

1.Destination情報(アクセス先のRMAP層のアドレス情報)の設定が正しくない

・RMAP通信を行うためには、相手のノードへの到達方法(ロジカルアドレス、パスアドレス)、相手ノードからみた自ノードへの到達方法(ロジカルアドレ
ス、パスアドレス)、Destination Key(アクセス権限確認のためのパスワードのようなもの)、アクセス可能な単位バイト長、CRC(Cyclic Redunduncy Check code)の計算方法のバージョン番号などの情報(総称して、RMAP Destination情報という)を事前に把握して、RMAP通信の前にただしく設定しておく必要があります。これらの情報のすべてがただしくないと、RMAP通信は成功しません。

・たとえば、RMAPコマンドパケットに書かれたロジカルアドレスと、そのコマンドパケットを受け取ったノードのロジカルアドレスが異なると、RMAPアクセス
は拒否され、RMAP ReplyのStatus情報には、「Invalid Destination Logical Address」というエラーを表す「12(decimal)」が書き込まれたものがソースノードに送り返されます。

・したがって、rmaphongoを使用する前に、自分が使用しているボードがどのようなRMAP Destination設定になっているかをすべて把握しておくことが必要
です(各種ボードの設定は、マニュアルに記載されているか、購入もとに問い合わせて調べる必要があります)。

・rmaphongo上でRMAP Destination情報を再度設定するためには、Menuから「8」を選択し、プロンプトの表示に従って、情報を入力してください。いくつか
のSpaceWireボードで利用されるRMAP Destination情報は、プリセットとして登録されています。

・また、「Q」のような状態でソフトが永久待ちに入ってしまった場合は、「Ctrl+C」でrmaphongoを強制終了してから、再起動してください。

2.RMAPアクセスしたアドレスが正しくなく、Destinationノードのローカルバスがロックしてしまい、Replyパケットが生成されず、結果としてSourceノード
(SpaceCube側)でRMAPトランザクションが完了せず永久待ちに入ってしまっている

・RMAPアクセスでは、RMAPコマンドパケットに記述されたRead/Writeといったアクセスが、Destinationノードの側のローカルバス(たとえばSDRAMや、
FPGA内レジスタが並んだアドレス空間)で実行されます。このとき、たとえばアドレス0x00001234には何のデバイスも定義されておらず、RMAP IPコアがローカルバスに対してアクセスを行っても、どのデバイスからも返答がないとします。ローカルバスの仕様に、タイムアウトが定義されていれば、規定された時間でタイムアウトが発生し、RMAP IP側が、「ローカルバスアクセスに失敗した」ということを感知でき、そのことを表すRMAP Replyパケットを生成してSourceノードに失敗を通知できます。一方で、ローカルバスにタイムアウトがない場合、誰からも返答が帰らない状態でバスがロックし続け、RMAP IPコアはReplyパケットを返せず、Sourceノード側ではReplyパケットを待ち続ける、という状態が発生します。

・解決方法は、アクセスしようとしているアドレスが本当にそのDestinationノードで定義されているか確認する、また、そのDestinationノードで定義されてい
ることがわかっている他のアドレスにアクセスしてみて、アクセスが成功するか確認する、などがあげられます。場合によっては、ボードの(FPGA内のロジックの)改変などによって、アドレスマッピングが変更されている可能性もあるので、製造元に最新版のアドレスマップを問い合わせる必要があるかもしれません。

・この種類のロックが発生している場合、Destinationノード側では、次のRMAP Commandパケットを受け取っても、前の処理がロックしたまま終了していないので、次の処理に移行できません。一度ボードの電源を切るなどして、バスのロック解除とRMAP IPの初期化を行う必要があると考えられます。

<参考文献>
・ RMAP仕様書Draft F Table6-1
トップに戻る

Q.42 : RMAP通信を繰り返し行うプログラム(たとえばDAQプログラム)を作成しました。短時間の実行では
問題なく通信が行えますが、長時間実行すると、「abort」などの表示とともに、プログラムが突然
終了してしまいます。どのような原因が考えられますか?

長時間動作における不具合は、多くの場合、メモリリークと最終的なメモリ確保の失敗による例外スローによって起こります。ソースコードの中で、auto変数でなくheap領域からメモリを確保しているオブジェクト(具体的には、newやmallocによってメモリ確保を行っているオブジェクト)が、使用後に正しくdelete(もしくはfree)されているかを確認してください。SpaceCubeでは現在のメモリ使用量を把握しながら実行を続ける、というのが難しいので、可能であれば、同じプログラムをLinux/MacOS X上で動作させ、メモリ消費量の時間変化のグラフを作成すると、メモリリークが起きているかどうか(メモリ使用量が増加しているか)は確認することができます。
トップに戻る

プロジェクト実績