Контейнеры устройства хранения данных

Введение

При кодировании с API для написанных пользователем S-функций фиксированной точки важно иметь в виду различие между размером контейнера устройства хранения данных, размером слова контейнера устройства хранения данных, и сигнализировать о размере слова. Разделы, которые следуют, обсуждают контейнеры, используемые API, чтобы сохранить сигналы в симуляции и генерации кода.

Контейнеры устройства хранения данных в симуляции

В симуляции сигналы хранятся в одном из нескольких типов контейнеров определенного размера.

Категории контейнера устройства хранения данных

Во время симуляции сигналы фиксированной точки сохранены в одном из типов контейнеров устройства хранения данных, как показано в следующей таблице. Во многих случаях сигналы представлены в контейнерах с большим количеством битов, чем их заданный размер слова.

Контейнеры устройства хранения данных фиксированной точки

Контейнерная категория

Сигнал
Размер слова

Контейнерный размер слова

Контейнерный размер

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 битам

Когда количество битов в размере слова сигнала является меньше, чем размер контейнера, биты размера слова всегда хранятся в наименее значимых битах контейнера. Остающиеся контейнерные биты должны быть расширенным знаком:

  • Если тип данных без знака, биты расширения знака должны быть очищены, чтобы обнулить.

  • Если тип данных подписывается, биты расширения знака должны быть установлены в один для строго отрицательных чисел и очищены, чтобы обнулить в противном случае.

Например, сигнал типа данных sfix6_En4 сохранен в контейнере FXP_STORAGE_INT8. Сигнал сохранен в шести младших значащих битах. Остающиеся два бита обнуляются, когда сигнал положителен или нуль, и к тому, когда это отрицательно.

Сигнал типа данных ufix6_En4 сохранен в контейнере FXP_STORAGE_UINT8. Сигнал сохранен в шести младших значащих битах. Остающиеся два бита всегда очищаются, чтобы обнулить.

Сигнал и размеры слова контейнера устройства хранения данных возвращены ssGetDataTypeFxpWordLength и функциями ssGetDataTypeFxpContainWordLen, соответственно. Размер контейнера устройства хранения данных возвращен функцией ssGetDataTypeStorageContainerSize. Контейнерная категория возвращена функцией ssGetDataTypeStorageContainCat, которая в дополнение к тем в приведенной выше таблице, может также возвратить следующие значения.

Другие контейнеры устройства хранения данных

Контейнерная категория

Описание

FXP_STORAGE_UNKNOWN

Возвращенный, если категория контейнера устройства хранения данных неизвестна

FXP_STORAGE_SINGLE

Контейнерный тип для Simulink® single

FXP_STORAGE_DOUBLE

Контейнерный тип для double Simulink

FXP_STORAGE_SCALEDDOUBLE

Контейнерный тип для типа данных, который был заменен с Scaled double

Контейнеры устройства хранения данных в примере симуляции

Тип данных sfix24_En10 перебрасывается парой слов длина 24, но на самом деле хранится в 32 битах во время симуляции. Для этого сигнала,

  • ssGetDataTypeStorageContainCat возвращает FXP_STORAGE_INT32.

  • ssGetDataTypeStorageContainerSize или sizeof( ) возвращают 4, который является размером контейнера устройства хранения данных в байтах.

  • ssGetDataTypeFxpContainWordLen возвращает 32, который является размером слова контейнера устройства хранения данных в битах.

  • ssGetDataTypeFxpWordLength возвращает 24, который является размером слова типа данных в битах.

Контейнеры устройства хранения данных в генерации кода

Контейнеры устройства хранения данных, используемые этим API для генерации кода, являются не всегда тем же самым как используемыми для симуляции. Во время генерации кода всегда используется нативный тип данных C. Типы данных с плавающей точкой сохранены в double C или float. Типы данных с фиксированной точкой считаются в C подписанным и char без знака, short, int или long.

Эмуляция

Поскольку это ценно для быстрого прототипирования и HIL-тестирования, эмуляция меньших сигналов в больших контейнерах поддерживается в генерации кода. Например, 29-битный сигнал поддерживается в генерации кода, если существует тип данных C, доступный, который имеет по крайней мере 32 бита. Правила для размещения меньшего сигнала в больший контейнер, и для контакта с дополнительными контейнерными битами, являются тем же самым в генерации кода что касается симуляции.

Если меньший сигнал эмулирован в большем контейнере устройства хранения данных в симуляции, он не обязательно эмулирован в генерации кода. Например, 24-битный сигнал эмулирован в 32-битном контейнере устройства хранения данных в симуляции. Однако некоторые микросхемы DSP имеют нативную поддержку 24-битных количеств. На такой цели компилятор C может задать int или long, чтобы быть точно 24 бита. В этом случае 24-битный сигнал сохранен в 32-битном контейнере в симуляции, и в 24-битном контейнере в генерации кода.

С другой стороны сигнал, который не был эмулирован в симуляции, может должен быть быть эмулирован в генерации кода. Например, некоторые микросхемы DSP имеют минимальную поддержку целых чисел. На таких микросхемах char, short, int и long могут все быть заданы к 32 битам. В этом случае необходимо эмулировать 8-и 16-битные типы данных с фиксированной точкой в генерации кода.

Контейнер устройства хранения данных функции TLC

Поскольку отображение контейнеров устройства хранения данных в симуляции к контейнерам устройства хранения данных в генерации кода не является непосредственным, функции Компилятора выходного языка (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™ автоматически вставляет typedef, который сопоставляет строку с нативным типом данных C в сгенерированном коде.

Например, рассмотрите фиксированный тип данных, который сохранен в FXP_STORAGE_INT8 в симуляции. FixPt_DataTypeNativeType возвратит int8_T. int8_T будет typdef 'd к char, short, int или long в сгенерированном коде, в зависимости от того, что подходит для целевого компилятора.

Остающиеся упомянутые выше функции TLC возвращают TRUE или FALSE в зависимости от того, используется ли конкретный стандартный тип данных C, чтобы содержать данный указанный в API тип данных. Обратите внимание на то, что эти функции не обязательно дают взаимоисключающие ответы для данного указанного типа данных, вследствие того, что типы данных C могут потенциально наложиться в размере. В C,

sizeof (char) ≤ sizeof (короткий) ≤ sizeof (int) ≤ sizeof (долго).

Один или несколько из этих типов данных C может быть, и очень часто, тот же размер.

Для просмотра документации необходимо авторизоваться на сайте