Дробные параметры в Верилоге Опции

[Kluwert]

Коллеги,
что-то не могу сообразить как решить такую простую задачку. Есть простой модуль, который задаёт следующие друг за другом временные интервалы. Он работает на некоторой тактовой частоте. Соответственно, по ТЗ временные интервалы заданы в миллисекундах. Можно, конечно, пересчитать длительность интервалов в число на выходе счётчика на данной тактовой частоте и успокоиться. Но как-то это не изящно: изменилась тактовая частота, или временнАя диаграмма - садись за калькулятор и пересчитывай.
А как бы вот так сделать, что бы время и тактовая частота задавалась в параметрах модуля сразу в мсек и МГц, соответственно, а в модуле автоматом пересчитывалось в такты счётчика?

[blackfin]

localparam max_cntr = $rtoi(frequency * interval) ;

[Kluwert]

localparam max_cntr = $rtoi(frequency * interval) ;

Спасибо, но, увы:
Error (10174): Verilog HDL Unsupported Feature error at encodersimitation.v(26): system function "$rtoi" is not supported for synthesis

[RobFPGA]

Приветствую!

Спасибо, но, увы:
Error (10174): Verilog HDL Unsupported Feature error at encodersimitation.v(26): system function "$rtoi" is not supported for synthesis

Можно просто max_cntr = (frequency * interval);
Обычно синтезатор сам округлит результат умножения до целого. Поворчав warning-ом для причия что "... мол округляю...".

В зависимости от синтезатора и поддерживаемой версии Verilog можно и так: integer'(frequency * interval) чтоб не ворчал;

Удачи! Rob.

[Kluwert]

Можно просто max_cntr = (frequency * interval);
Обычно синтезатор сам округлит результат умножения до целого. Поворчав warning-ом для причия что "... мол округляю...".

Увы, тоже мимо. Округлять синтезатор Квартуса не захотел: сообщил, что с real variable data type он работать не намерен. Единственным пока решением проблемы оказалось установка в модуль подмодулей FP-умножения и округления до целых. Когда на входе постоянные, то компайлер этот огромный умножитель несколько упрощает, но, всё равно всё настолько громоздким становится, что, похоже, калькулятор - самое простое решение

[RobFPGA]

Приветствую!

Увы, тоже мимо. Округлять синтезатор Квартуса не захотел: сообщил, что с real variable data type он работать не намерен. Единственным пока решением проблемы оказалось установка в модуль подмодулей FP-умножения и округления до целых. Когда на входе постоянные, то компайлер этот огромный умножитель несколько упрощает, но, всё равно всё настолько громоздким становится, что, похоже, калькулятор - самое простое решение

Можете привести тут часть кода на которую ругается Qu?

Удачи! Rob.

[Tosha1984]

Можо в лоб если точность не критична.
Помножьте параметр на 10 в требуемой степени, чтоб сделать целым.
Осуществите все требуемые арифметические операции с целыми числами.
У полученного результата отбросьте требуемое количество младших битов (ну то есть если умножали на 10 - отбросьте 3).
Результат будет с точностью до степени 2. Ну и логики конечно возможно немеренно уйдет на такое.

Сообщение отредактировал Tosha1984 - Nov 20 2017, 12:38

[iosifk]

Результат будет с точностью до степени 2. Ну и логики конечно возможно немеренно уйдет на такое.

У ТС речь идет о "localparam", который вычисляется по формуле. И при чем тут "логики немеренно уйдет"? Ведь сама формула - не синтезируется...

[Tosha1984]

У ТС речь идет о "localparam", который вычисляется по формуле. И при чем тут "логики немеренно уйдет"? Ведь сама формула - не синтезируется...

Младшие биты, которые лишние - тоже будут участвовать в арифметических операциях.
То есть если домножили скажем на 1000 - появляется 10 битов которые надо туда-сюда таскать по RTL, а в конечном итоге отбросить.
Я так делал когда-то давно когда писал преобразование цвета из одной системы в другую (например RGB -> HSB). Там коэффициенты были как раз дробные и передавались параметрами. Далее я их формулами в теле делал целыми (домножал) что естественно не синтезировалось, потом непосредственно в верилоге все это перемножал/суммировал, а потом отбрасывал младшие биты. В итоге получалась гора логики, которая влияла на 1-2 младших бита в конечном результате - то есть она не была оптимизирована при синтезе, но по сути являлась балластом.

Сообщение отредактировал Tosha1984 - Nov 20 2017, 13:08

[blackfin]

Увы, тоже мимо. Округлять синтезатор Квартуса не захотел: сообщил, что с real variable data type он работать не намерен.

Тогда так:

localparam integer max_cntr = frequency * interval;

[ViKo]

Переведите мегагерцы в наносекунды и делите свои миллисекунды на наносекунды.

[Kluwert]

У ТС речь идет о "localparam", который вычисляется по формуле. И при чем тут "логики немеренно уйдет"? Ведь сама формула - не синтезируется...

Иосиф прав, во-первых, синтезироваться-то ничего и не должно, это - постоянные.
Во-вторых, аппроксимировать деление на степени 10 делением на степени 2 - это как-то уж совсем грубо.
Но, ваша идея мне подсказала, походу самый оптимальный путь: время не в мкс, а в нс.

Т.е., как-то так:
parameter F_CLK_MHZ = 230;
parameter T_PULSE_NS = 275300;

`define COUNTER_MAX (F_CLK*T_PULSE_NS/1000)

Проверил, Квартус прожевал, вроде работает. Но всё-таки осадочек остался: почему нельзя было хотя бы для постоянных реализовать функцию $rtoi я не понимаю.

[blackfin]

Но всё-таки осадочек остался: почему нельзя было хотя бы для постоянных реализовать функцию $rtoi я не понимаю.

Так проверьте еще через параметр: пост #10.

[Kluwert]

Так проверьте еще через параметр: пост #10.

Сорри, коллега, не заметил ваш пост. Слушайте, да, похоже работает и ваш способ похоже лучший на данный момент!Спасибо! Вот ведь меня на define'ах заклинило

[blackfin]

Слушайте, да, похоже работает и ваш способ похоже лучший на данный момент! Спасибо!

Это не мой способ. Это способ RobFPGA. Его и благодарите..