[YuP 0]

Подскажите,есть ли в VHDL какие-нибудь функции для округления чисел?

[andrew_b 23]

Подскажите,есть ли в VHDL какие-нибудь функции для округления чисел?

В пакете math_real.

[Doka 5]

существует множество способов округления - от простого усечения до более "хитрого" вероятностного округления. Наиболее распространенное , пожалуй, - округление к ближайшему целому.

 

пример (верилог) упрощенного округления к ближайшему целому (переход от 16р к 12разрядам):

assign dout = {din[15:5],(din[4]|din[3])};

[alex_os 0]

существует множество способов округления - от простого усечения до более "хитрого" вероятностного округления. Наиболее распространенное , пожалуй, - округление к ближайшему целому.

 

пример (верилог) упрощенного округления к ближайшему целому (переход от 16р к 12разрядам):

assign dout = {din[15:5],(din[4]|din[3])};

Гм. а как насчет переноса из din[4] в старшие разряды?

ps: verilog не знаю округление понимаю так (код на си )

int dout, din;

dout = 0xFFF0&( din + 0x8);

[SM 9]

существует множество способов округления - от простого усечения до более "хитрого" вероятностного округления. Наиболее распространенное , пожалуй, - округление к ближайшему целому.

 

пример (верилог) упрощенного округления к ближайшему целому (переход от 16р к 12разрядам):

assign dout = {din[15:5],(din[4]|din[3])};

 

Немного некорректно. Рассмотрите например число 7.5 (0000 0000 0111 1000), оно у Вас округлится до 7, а не до положенных 8. Правильно вот так:

 

assign dout = din[15:4]+din[3];

[Doka 5]

существует множество способов округления - от простого усечения до более "хитрого" вероятностного округления. Наиболее распространенное , пожалуй, - округление к ближайшему целому.

 

пример (верилог) упрощенного округления к ближайшему целому (переход от 16р к 12разрядам):

assign dout = {din[15:5],(din[4]|din[3])};

 

Немного некорректно. Рассмотрите например число 7.5 (0000 0000 0111 1000), оно у Вас округлится до 7, а не до положенных 8. Правильно вот так:

 

assign dout = din[15:4]+din[3];

согласен. но тут опять же есть некая свобода выбора:

матожидание ошибки упрощенного округления больше чем матожидание ошибки полноценного округления к ближайшему целому, но меньше, чем при округлении к +infinity.

 

да и дешевое оно (упр.окр-е): всеже двухвходовый ИЛИ меньше ресурсов займет чем сумматор)).

[vladv 0]

существует множество способов округления - от простого усечения до более "хитрого" вероятностного округления. Наиболее распространенное , пожалуй, - округление к ближайшему целому.

 

пример (верилог) упрощенного округления к ближайшему целому (переход от 16р к 12разрядам):

assign dout = {din[15:5],(din[4]|din[3])};

 

Немного некорректно. Рассмотрите например число 7.5 (0000 0000 0111 1000), оно у Вас округлится до 7, а не до положенных 8. Правильно вот так:

 

assign dout = din[15:4]+din[3];

согласен. но тут опять же есть некая свобода выбора:

матожидание ошибки упрощенного округления больше чем матожидание ошибки полноценного округления к ближайшему целому, но меньше, чем при округлении к +infinity.

 

да и дешевое оно (упр.окр-е): всеже двухвходовый ИЛИ меньше ресурсов займет чем сумматор)).

 

А как на счет 7.9375 (0000 0000 0111 1111)? В случае ИЛИ получится 7.

[CaPpuCcino 0]

ну раз пошла такая пьянка :cheers:

 

localparam int_width=12;
localparam dot_width=4;

typedef struct packed {
bit [int_width-1:0]int_part;
bit [dot_width-1:0]dot_part;
}fixed_point_number_Type;

function bit [int_width-1:0] round_fixed_dot_number (input fixed_point_number_Type number_for_rounding)
  begin
     //local dynamic variables declaration
     bit [dot_width-1+1:0] temp_dot_part;
     bit [int_width-1:0] result;
     //end of local dynamic variables declaration

     temp_dot_part=number_for_rounding.dot_part+1'b1;
     result=number_for_rounding.int_part+(temp_dot_part[dot_width-1+1]|temp_dot_part[dot_width-1]);
     return result;
  end

[Doka 5]

согласен. но тут опять же есть некая свобода выбора:

матожидание ошибки упрощенного округления больше чем матожидание ошибки полноценного округления к ближайшему целому, но меньше, чем при округлении к +infinity.

 

да и дешевое оно (упр.окр-е): всеже двухвходовый ИЛИ меньше ресурсов займет чем сумматор)).

А как на счет 7.9375 (0000 0000 0111 1111)? В случае ИЛИ получится 7.

 

опять 25!!

ну кто вам обещал, что оно лучше полноценного округления?.. зачем сравниваете с ним, а не с простым усечением?! (особенно по занимаемым ресурсам логики)

Попробуйте рассмотреть округление чисел с четной целой частью и сравнить результат с простым усечением. (если входные значения имеют равномерное распределение то действительно упрощенное округление будет давать просто усеченные значения в 25% случаев - но это ли повод не использовать его вместо обычного усечения дробной части?)

 

ЗЫЖ упрощенное округление - компромисс, а идти на него или нет - выбор разработчика.

[vladv 0]

согласен. но тут опять же есть некая свобода выбора:

матожидание ошибки упрощенного округления больше чем матожидание ошибки полноценного округления к ближайшему целому, но меньше, чем при округлении к +infinity.

 

да и дешевое оно (упр.окр-е): всеже двухвходовый ИЛИ меньше ресурсов займет чем сумматор)).

А как на счет 7.9375 (0000 0000 0111 1111)? В случае ИЛИ получится 7.

 

опять 25!!

ну кто вам обещал, что оно лучше полноценного округления?.. зачем сравниваете с ним, а не с простым усечением?! (особенно по занимаемым ресурсам логики)

Кто мне вообще что-нибудь обещал? :unsure:

 

Попробуйте рассмотреть округление чисел с четной целой частью и сравнить результат с простым усечением. (если входные значения имеют равномерное распределение то действительно упрощенное округление будет давать просто усеченные значения в 25% случаев - но это ли повод не использовать его вместо обычного усечения дробной части?)

Не-а. Упрощенное округление дает просто усеченные значения в 75% случаев.

 

ЗЫЖ упрощенное округление - компромисс, а идти на него или нет - выбор разработчика.

В чем компромис? В смысле, чем или в каких случаях "упрощенное округление" лучше

простого усечения?

 

Посмотрим передаточную характеристику, т.е. зависимость выходного значения "округлителя" от входа.

 

С точки зрения здравого смысла, и как оно и получается в случае честного округления, "правильная"

передаточная функция является ступенчатой с переходами, когда входное значение будет ... +0.5,

+1.5, +2.5 ... Т.е. передаточная функция симметрична относительно нуля (нет постоянной

составляющей) и между переходами одинаковое расстояние (т.е. преобразование в некотором смысле

линейно).

 

В случае усечения, мы будем иметь ступенчатую функцию с переходами в ... +1.0, +2.0, +3.0 ...

Т.е. передаточная функция сдвинута на 0.5 влево (появилась постоянная составляющая -0.5, что не

очень хорошо, хотя и терпимо), но между переходами одинаковое расстояние (т.е.преобразование в

все еще линейно).

 

Наконец в случае упрощенного округления, передаточная функция будет иметь переходы в +0.5,

+2.0, +2.5, +4.0. Т.е.: неравномерный шаг (нелинейна) и "в среднем" сдвинута на 0.25 влево.

 

С точки зрения обработки сигналов, например, последний случай явно хуже предыдущих двух. Так,

если для "усечения" мы подадим на вход синусоиду, то на выходе получим синусоиду с шумами квантования и постоянный уровень (который можно позже либо учесть, либо просто отфильтровать).

В случае "упрощенного округления", кроме постоянной составляющей, мы будем еще иметь и гармоники :(.