Main Content

ストレージ コンテナー

はじめに

ユーザー作成の固定小数点 S-Function 用の API を使用してコード作成を行う場合、ストレージ コンテナーのサイズ、ストレージ コンテナーの語長、および信号の語長の違いを理解しておくことが重要です。以下の節では、シミュレーションとコード生成で信号を格納するために API が使用するコンテナーについて説明します。

シミュレーションでのストレージ コンテナー

シミュレーションでは、特定サイズの数種類のコンテナーの 1 つに信号が格納されます。

ストレージ コンテナー カテゴリ

シミュレーション中、固定小数点信号は次の表に示すストレージ コンテナーのタイプの 1 つに保持されます。通常、信号はコンテナー内で、指定した語長よりも大きいビット数で表現されます。

固定小数点ストレージ コンテナー

コンテナー カテゴリ

信号の
語長

コンテナーの語長

コンテナーのサイズ

FXP_STORAGE_INT8 (符号付き)
FXP_STORAGE_UINT8 (符号なし)

1 ～ 8 ビット

8 ビット

1 バイト

FXP_STORAGE_INT16 (符号付き)
FXP_STORAGE_UINT16 (符号なし)

9 ～ 16 ビット

16 ビット

2 バイト

FXP_STORAGE_INT32 (符号付き)
FXP_STORAGE_UINT32 (符号なし)

17 ～ 32 ビット

32 ビット

4 バイト

FXP_STORAGE_OTHER_SINGLE_WORD

33 ～ long データ型の語長

long データ型の長さ

long データ型の長さ

FXP_STORAGE_MULTIWORD

long データ型の語長より大きく 128 ビットまで

long データ型の長さの複数倍から 128 ビットまで

long データ型の長さの複数倍から 128 ビットまで

信号の語長のビット数がコンテナーのサイズよりも小さい場合、語長のビットは常にコンテナーの最下位側ビットに格納されます。残りのコンテナー ビットは符号拡張されなければなりません。

  • データ型が符号なしの場合、符号拡張ビットはゼロでなければなりません。

  • データ型が符号付きの場合、符号拡張ビットは厳密な負数の場合は 1 に設定され、それ以外の場合はゼロでなければなりません。

たとえば、データ型が sfix6_En4 の信号は FXP_STORAGE_INT8 コンテナーに保持されます。信号は最下位側の 6 ビットに保持されます。残りの 2 ビットは、信号が正またはゼロの場合 0 に設定され、負の場合は 1 に設定されます。

データ型が ufix6_En4 の信号は FXP_STORAGE_UINT8 コンテナーに保持されます。信号は最下位側の 6 ビットに保持されます。残りの 2 ビットは常にゼロになります。

信号の語長とストレージ コンテナーの語長は、それぞれ関数 ssGetDataTypeFxpWordLength と関数 ssGetDataTypeFxpContainWordLen で返されます。ストレージ コンテナーのサイズは、関数 ssGetDataTypeStorageContainerSize で返されます。コンテナー カテゴリは関数 ssGetDataTypeStorageContainCat で返されます。この関数は上表の値の他に次の値も返します。

他のストレージ コンテナー

コンテナー カテゴリ

説明

FXP_STORAGE_UNKNOWN

ストレージ コンテナー カテゴリが不明の場合に返される

FXP_STORAGE_SINGLE

Simulink® single 用のコンテナー タイプ

FXP_STORAGE_DOUBLE

Simulink double 用のコンテナー タイプ

FXP_STORAGE_SCALEDDOUBLE

Scaled double でオーバーライドされたデータ型用のコンテナー タイプ

シミュレーションでのストレージ コンテナーの例

sfix24_En10 データ型は語長 24 ビットですが、シミュレーションでは実際には 32 ビットで格納されます。この信号では次のようになります。

コード生成でのストレージ コンテナー

この API が使用するコード生成用のストレージ コンテナーは、シミュレーション用に使用するものと必ずしも同じではありません。コード生成中は常にネイティブ C データ型が使用されます。浮動小数点データ型は C double または float に保持されます。固定小数点データ型は C 符号付きと符号なしの char、short、int、または long に保持されます。

エミュレーション

ラピッド プロトタイピングおよびハードウェアインザループのテストに有効なため、コンテナー サイズよりも小さな信号のエミュレーションがコード生成でサポートされています。たとえば、32 ビット以上の利用できる C データ型がある場合は、コード生成で 29 ビットの信号がサポートされています。コンテナー サイズよりも小さな信号を格納し、余分なコンテナー ビットを処理するルールは、コード生成とシミュレーションとで同じです。

シミュレーションでコンテナー サイズよりも小さな信号がエミュレートされる場合は、コード生成ではエミュレートされる必要はありません。たとえば、シミュレーションでは 32 ビットのストレージ コンテナーで 24 ビットの信号がエミュレートされます。しかし DSP チップには 24 ビット量をネイティブでサポートしているものもあります。そのようなターゲットの場合、C コンパイラは int または long を正確に 24 ビットに定義できます。この場合、24 ビット信号はシミュレーションでは 32 ビット コンテナーに保持され、コード生成では 24 ビット コンテナーに保持されます。

逆にシミュレーションでエミュレートされない信号は、コード生成でエミュレートされる必要があるかもしれません。たとえば、DSP チップには整数に対して最低限のサポートだけしかしないものもあります。そのようなチップの場合、char、short、int、および long はすべて 32 ビットに定義されなければなりません。この場合、8 ビットと 16 ビットの固定小数点データ型はコード生成でエミュレートする必要があります。

ストレージ コンテナーの TLC 関数

シミュレーションでのストレージ コンテナーとコード生成でのストレージ コンテナーとの対応は 1 対 1 ではないため、ストレージ コンテナーに対するターゲット言語のコンパイラ (TLC) 関数はシミュレーションのものと異なります。

  • FixPt_DataTypeNativeType

  • FixPt_DataTypeStorageDouble

  • FixPt_DataTypeStorageSingle

  • FixPt_DataTypeStorageScaledDouble

  • FixPt_DataTypeStorageSInt

  • FixPt_DataTypeStorageUInt

  • FixPt_DataTypeStorageSLong

  • FixPt_DataTypeStorageULong

  • FixPt_DataTypeStorageSShort

  • FixPt_DataTypeStorageUShort

  • FixPt_DataTypeStorageMultiword

最初の TLC 関数 FixPt_DataTypeNativeType は、シミュレーションで使用する関数 ssGetDataTypeStorageContainCat に非常によく似ています。FixPt_DataTypeNativeType は、ストレージ コンテナーのタイプを指定する TLC 文字列を返し、Simulink Coder™ 製品は、この文字列を生成されたコード内のネイティブ C データ型にマップする typedef を自動的に挿入します。

たとえば、シミュレーションで FXP_STORAGE_INT8 に保持される固定小数点データ型を考えます。FixPt_DataTypeNativeType は int8_T を返します。int8_T は、生成されたコードでは、ターゲット コンパイラとの適性により char、short、int、または long に typdef (型定義) されます。

上述の TLC 関数の残りのものは、一定の API に登録されたデータ型を保持するために特定の標準 C データ型が使用されるかどうかにより、TRUE または FALSE を返します。C データ型がサイズのオーバーラップを許容するため、これらの関数は一定の登録されたデータ型に対して必ずしも相互排他的な答えを出すわけではありません。C では、次の関係があります。

sizeof(char) ≤ sizeof(short) ≤ sizeof(int) ≤ sizeof(long)

これらのデータ型の 1 つ以上が同じサイズをもつことは可能で、これはしばしばあります。