[OparinVD 0]

Доброго дня!

Задача такая:

в протоколе определены типы данных int8, uint8; int16, uint16 и т.д. На внутреннюю математику их знаковость или без знаковость не особо влияет. Важна их ширина и то, что они отличаются null-значением, которое показывает, что поле соответствующего типа отсутствует. Для int это x"7FF..", а для uint это x"FFF..."

Я пытаюсь изобрести простой изящный метод, чтобы при присваивании сигналу null-значения не лазать в datasheet и не искать какого конкретно типа это поле, а чтобы "здесь и сейчас" имея на руках только сигнал понять, какой у него null. В datasheet конечно сходить можно, но это неудобно. Например, поле TimeStamp имеет тип TTimeStamp, а сам TTimeStamp в одной вариации может быть int64, а в другой - uint64.

Я пытался зайти с двух сторон: через attributes и через перегрузку функций, но приемлемого решения не получил (

1) подход через атрибуты вижу так

объявляю сабтипы, и атрибут для этого сабтипа, например

subtype t_int8 is std_logic_vector(7 downto 0);

attribute null_value : std_logic_vector;
attribute null_value of t_int8	: subtype is x"7F";
attribute null_value of t_int16	: subtype is x"7FFF";

Но это атрибут сабтипа, и для присваивания сигналу null-значения надо сделать s <= t_int8'null_value, т.е. нужно знать, какого типа у меня сигнал, плюс сама запись принципиально не отличается от присвоения предопределенной константы. Хотелось бы получить что-то типа s <= s'null_value; но атрибут сабтипа не передается по наследству сигналу.

Можно, конечно, объявить атрибут сигналу, но тогда для набора однотипных сигналов прописывать атрибут с null_value придется каждому индивидуально, а учитывая то, что часто присвоение null-значения - это единственное присвоение сигнала, такая конструкция получается слишком избыточной.

2) для второго подхода я объявлял одноименные функции типа

function null_of(arg t_int8) return t_int8;
function null_of(arg t_uint8) return t_uint8;

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

s : t_int8;
s <= null_of(s);

но базовый тип для всех это std_logic_vector и вызов функции получается ambiguous

 

Есть светлые мысли, как это сделать красиво, а не просто присвоением констант вручную?

[Maverick_ 15]

Для чего? используйте просто 

data_in                    : in std_logic_vector(DATA_SIZE-1 downto 0);

внутри модуля преобразуйте в unsigned/signed

reg_data <= unsigned(data_in );

Далее работайте с типом unsigned (например) - все дальнейшие вічисления с безнаковими числами 

[OparinVD 0]

Идея с singned/unsigned прекрасна! С ними останется только два типа функций
 

function null_of(arg : signed) return signed;
function null_of(arg : unsigned) return unsigned;

Это полностью устранит ambiguous при вызове для вектора любой ширины. Сами типы вполне стандартны и библиотечны. Я было кинулся реализовывать, но уперся в то, что для этого:

reg_data <= unsigned(data_in );

опять надо отматывать datasheet наверх, чтобы посмотреть, какого типа у нас reg_data, чтобы решить, использовать unsigned(data_in) или signed(data_in)... Т.е. от чего бежал, к тому и вернулся

[petrov 7]

Т.е. от чего бежал, к тому и вернулся

Надо перестать программировать и просто описать цифровую схему, которая делает нужное.

[OparinVD 0]

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

Вот как вы видите решение озвученной задачи? У меня сейчас на все варианты определены null-константы для каждого поля. Решение простое, надежное, работает и не сломается до тех пор, пока кто-то не вздумает изменить тип поля с int на uint. С прикладной точки зрения, может ничего и не поменяется, но null-значение надо будет класть другое, и это будет моя головная боль. А хотелось переложить ее на компилятор