Кастомизация экземпляров модулей через параметры и оптимизатор

[new123 0]

Форумчане привет. Вдруг точно знаете и не надо мне ковыряться в RTL.

1) Есть модуль, с параметрами.

mdoule my_module (
);
  
parameter  MODULE_ID = 2'd1;
  ......

2) Делаю его два эекземпляра.

	my_module #(
		.MODULE_ID	(2'd1)
	)
	m_1 (
      
	my_module #(
		.MODULE_ID	(2'd2)
	)
	m_2 (

3) Хочу адаптировать каждый экземпляр модуля в зависимости от параметра

mdoule my_module (
);
  
parameter  MODULE_ID = 2'd1;
  ......
  
  always .. begin
  	if (MODULE_ID == 2'd1) begin
    end
  end

 

Как думаете, квартус и его оптимизатор вырежет ненужную логику в каждом экземпляре, чтобы не потребляло лишние ресурсы?
То есть в первом екземпляре не вставлял бы логику попадающая под 

Quote

if (MODULE_ID == 2'd2) begin

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

Quote

if (MODULE_ID == 2'd1) begin

 

Или лучше сделать два разных модуля и объявить их отдельно?

[RobFPGA 0]

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

39 minutes ago, new123 said:

Как думаете, квартус и его оптимизатор вырежет ненужную логику в каждом экземпляре, чтобы не потребляло лишние ресурсы?
То есть в первом екземпляре не вставлял бы логику попадающая под 
А во втором не вставлял бы логику, попадающая под
Или лучше сделать два разных модуля и объявить их отдельно?

Вырежет и оптимизирует 

 

Удачи! Rob. 

[new123 0]

Just now, RobFPGA said:

Вырежет и оптимизирует

спасибо

[pavlovconst 0]

5 hours ago, RobFPGA said:

Вырежет и оптимизирует 

Не согласен. Очевидные вещи - да, оптимизирует. Но бывают более сложные варианты с косвенной адресацией или когда вы-то точно знаете из специфики вашей задачи, что провод всегда в 0, но из анализа RTL этого не следует. Наверное, зависит еще от стиля.

У меня была такая же задача. Три экземпляра с разными параметрами. При автоматической оптимизации оставалась лишняя комбинационная логика, что вело к проблемам с времянками. При оптимизации "вручную", без параметров, результат получался ощутимо лучше. Сравнив два варианта я выяснил, где по коду синтезатору нужно подсказать.

В проекте, естественно, оставил инициализацию через параметры

[Strob 0]

Generate с условиями для такого все же лучше подходит.

[RobFPGA 0]

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

1 hour ago, pavlovconst said:

Не согласен. Очевидные вещи - да, оптимизирует.

В проекте, естественно, оставил инициализацию через параметры

Вопрос о  неочевидности не стоит  - нет разницы будет ли эта неочевидность получатся эта через условие с parameter или чисто руками.    

2 hours ago, Strob said:

Generate с условиями для такого все же лучше подходит.

Опять же особой разницы  нет - крупные изменения логики просто удобнее и нагляднее делать через generate,  а  для мелких достаточно и просто if(...).
Но с точки зрения оптимизации при синтезе разницы  нет.

 

Удачи! Rob.   

[dxp 0]

Насколько знаю, нынче в SV generate - это синтаксический сахар. Т.е. if вне always блоков действует как раз именно как generate if. generate имеет смысл писать для того, чтобы такие фрагменты лучше выделялись в коде. 

[Nick_K 0]

6 hours ago, dxp said:

Т.е. if вне always блоков действует как раз именно как generate if

Увы не всегда. Часто появляются конструкции, которые превращаются в комбинаторику или просто константы, которые потом не хотят оптимизироваться. Хотя многое зависит от возможностей и настроек синтезатора.

Лучше выделять, чтобы не путать себя, остальных и синтезатор 

Другое дело, если стандартная конструкция нужна будет, например для проверки всех значений параметров в тестбенче (предварительно сделав его константой). Но тут вопрос можно ли так делать и вообще нужно ли.

[RobFPGA 0]

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

13 minutes ago, Nick_K said:

Увы не всегда. Часто появляются конструкции, которые превращаются в комбинаторику или просто константы, которые потом не хотят оптимизироваться.

Чудеса   - Очень хотелось бы увидеть хоть парочку примеров кода  когда подобные конструкции не оптимизируется, что бы понять как такие чудеса самому не повторять 

 

Удачи!  Rob.

[Nick_K 0]

36 minutes ago, RobFPGA said:

Чудеса   - Очень хотелось бы увидеть хоть парочку примеров кода  когда подобные конструкции не оптимизируется, что бы понять как такие чудеса самому не повторять 

Я тут подумал, и наверное в регулярной логике такое невозможно.

У меня была ситуация, когда флопы были неоптимизированы (оптимизация конкретно этого места возможна на более поздних этапах) и подключена в "Сканчейн". После чего уже ничего нельзя оптимизировать 

[lexx 0]

18 hours ago, Nick_K said:

У меня была ситуация, когда флопы были неоптимизированы (оптимизация конкретно этого места возможна на более поздних этапах

Маловероятно. Параметры обычно подставляются во время компиляции проекта, по крайней мере, так об этом пишут мануалы на синтезаторы. 

Но если скан цепочка уже проведена, то удалить конечно её уже проблематично.

[Nick_K 0]

7 hours ago, lexx said:

Параметры обычно подставляются во время компиляции проекта, по крайней мере, так об этом пишут мануалы на синтезаторы.

Параметры - да. Но там именно прикол, что были константы, которые пропагировались к флопам только после первого инкрементального синтеза, а до этого были представлены как набор логики с подтяжками к земле или питанию (район конструкции if-else с константными переходами).

[lexx 0]

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