[_Ivan_ 0]

Добрый день.

 

Столкнулся со следующей проблемой.

Есть rtl-модель некого вычислителя. Хочу повысить тактовую и при этом задействовать меньшее количество dsp-ячеек.

В какую сторону копать для увеличения тактовой?

 

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

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

 

module second_calc_module(
input 									clk,
input 									reset_n,


input 						[4:0] 	ctrl_cmd,
input				signed	[15:0]	sin_value,
input				signed	[15:0]	cos_value,
input										sin_cos_ready,
input				signed	[31:0]	h_value,

output	reg	signed	[31:0]	sum_sqr_value,
output	reg							sum_sqr_valid,

output	reg							error
);


localparam		idle	= 	3'b000,
				calc0	=	3'b001,
				calc1	=	3'b010,
				calc2	=	3'b011,
				calc3	=	3'b100,
				calc4	=	3'b101,
				calc5	=	3'b110,
				calc6=	3'b111;

reg				[2:0]		state_reg;					


reg	signed	[15:0]	sin_value_reg;
reg	signed	[15:0]	cos_value_reg;

reg	signed	[31:0]	acc0_reg;
reg	signed	[31:0]	acc1_reg;

reg	signed	[31:0]	h_reg;

reg	signed	[15:0]	r_reg;
reg	signed	[31:0]	b_reg;


wire	signed	[63:0]	square_wire;


always@(posedge clk)
begin
if(reset_n == 1'b0)
begin
	h_reg <= 16'sb0;
end
else
begin
	if(ctrl_cmd[0])
		begin
			h_reg <= h_value;//sfix32en22
		end
end 
end

always@(posedge clk)
begin
if(ctrl_cmd[1] | ctrl_cmd[3])
	begin
		r_reg <= 16'sd16874;
		b_reg <= 32'sd901775360;
	end
else if(ctrl_cmd[2])
	begin
		r_reg <= 16'sd17389;
		b_reg <= 32'sd902193152;//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
	end
end


assign square_wire = (state_reg == calc2) ? acc0_reg*acc0_reg : (state_reg == calc3) ? acc1_reg * acc1_reg : 64'b0;



always@(posedge clk)
begin
if(reset_n == 1'b0)
begin
	sum_sqr_valid <= 1'b0;
	state_reg <= idle;
	error <= 1'b0;
end
else
begin
	case(state_reg)
		idle:
			begin
				sum_sqr_valid <= 1'b0;
				if(sin_cos_ready)
					begin
						sin_value_reg <= sin_value;//sfix16en14
						cos_value_reg <= cos_value;//sfix16en14
						state_reg <= calc0;
					end
				else
					begin
						state_reg <= idle;
					end
			end
		calc0:
			begin
				acc0_reg <= sin_value_reg * r_reg; //sfix32_En22
				acc1_reg <= cos_value_reg * r_reg; //sfix32_En22
				//sum_sqr_value <= cos_value_reg * r_reg;
				state_reg <= calc1;
			end
		calc1:
			begin
				acc0_reg <= {acc0_reg[29], acc0_reg[29:0], 1'b0} + {h_reg[31], h_reg[31:1]};
				acc1_reg <= b_reg - {acc1_reg[29], acc1_reg[29:0], 1'b0};
				state_reg <= calc2;
			end
		calc2: //square x_reg
			begin
				state_reg <= calc3;
				acc0_reg <= square_wire[61:30];
			end
		calc3: //square y_reg
			begin
				state_reg <= calc4;
				acc1_reg <= square_wire[61:30];
			end
		calc4: //sum of square
			begin
				state_reg <= idle;
				sum_sqr_value <= {acc0_reg[31], acc0_reg[31:1]} + {acc1_reg[31], acc1_reg[31:1]}; //sfix32en11
				sum_sqr_valid <= 1'b1;
			end
		default:
			begin
				state_reg <= idle;
				error <= 1'b1;
			end
	endcase
end
end


endmodule

 

ах да, забыл самое главное - код этот синтезируется на почти 47 МГц, что маловато...

[FatRobot 0]

Код прекрасен.

 

Особенно вот это место:

assign square_wire = (state_reg == calc2) ? acc0_reg*acc0_reg : (state_reg == calc3) ? acc1_reg * acc1_reg : 64'b0;

 

Оно скорее всего гадит.

Записывайте результаты умножения (32х32 между прочим) в регистры и мультиплекисруйте выходы этих регистров. Либо записывайте в регистр аргумент, а потом возводите в квадрат. Либо указывайте multicycle path для square_wire. По-моему этот код позволяет и то, и другое, и третье.

 

Еще рекомендую научиться читать отчеты STA. Там много интересного, наталкивающего на мысли.

Ну и rtl-симуляцию освоить, конечно.

 

Касаемо количества dsp-блоков, то нужно задействовать 1 малоразрядный умножитель и сумматор для получения результатов многоразрядного умножения за несколько тактов. Как в начальной школе учили: умножение столбиком.

 

Ну а в целом нужно следовать советам-заветам ассов hdl-кодера, адресованных как раз вам: берите кристалл повеселее.

[des00 25]

Код, кстати, изначально был сгенерен симулинком, возможно это сыграло свою роль.

ну дык модель надо было с умом делать, что мешало разогнать модуль в симулинке?

 

ЗЫ. переписывать математику надо, потому что в лоб сделана. Даже кристалл толще не поможет :)

 

[Golikov 0]

Либо указывайте multicycle path для square_wire. По-моему этот код позволяет и то, и другое

Кстати давно хотел узнать, как можно договориться с синтезатором-имплементатором что результат не обязательно должен появиться за 1 такт?

 

Я обычно в этом случае руками расписывают конвейер, но это не всегда возможно. И иногда я готов подождать 2 быстрых такта результата, чем все устройство опустить по частоте. Это только через констрайны делается или есть какие-то хорошие директивы еще на уровне кода?

 

 

 

По поводу модуля, он вроде как небольшой, зачем симулинк то был нужен?

[iosifk 3]

Добрый день.

 

Столкнулся со следующей проблемой.

Есть rtl-модель некого вычислителя. Хочу повысить тактовую и при этом задействовать меньшее количество dsp-ячеек.

В какую сторону копать для увеличения тактовой?

 

 

ах да, забыл самое главное - код этот синтезируется на почти 47 МГц, что маловато...

 

Вы посмотрите, что в коде.

Есть автомат. У него есть регистр и комбинационная часть. И в эту комбинационную часть еще добавлены умножители, сумматоры и пр.

Так вот, разделите их на части.

Автомат должен не "умножать", а только давать сигнал "разрешения умножения". А "умножать" должен совсем отдельный блок. Тогда логики будет накручено значительно меньше и все поедет быстрее. Но только само вычисление по времени сдвинется на такт от "разрешения". Это надо будет учесть.

След. шаг - конвейеры.

У меня в "Кратком Курсе" смотрите главу про автоматы, про многопоточности и пр...

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

 

[des00 25]

Кстати давно хотел узнать, как можно договориться с синтезатором-имплементатором что результат не обязательно должен появиться за 1 такт?

http://embedders.org/content/timequest-dly...bnyi-multicycle

[FatRobot 0]

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

 

Если вы знаете, как разогнать-переписать, то hdl-кодер вам скорее всего не необходим. Здесь же, как я понимаю из наблюдений, дело принципа и веры во что-то сверхъестественное. Плюс все это подогревается "историями успеха".

 

ну дык модель надо было с умом делать, что мешало разогнать модуль в симулинке?

 

ЗЫ. переписывать математику надо, потому что в лоб сделана. Даже кристалл толще не поможет :)

 

[Golikov 0]

http://embedders.org/content/timequest-dly...bnyi-multicycle

 

спасибо, мне кажется я читал расширенный вариант этой статьи. То есть ответ только через констрайны, правильно?

[SM 0]

То есть ответ только через констрайны, правильно?

Абсолютно. Вообще, управление времянками у синтезатора, PAR и вообще, STA, осуществляется только ими.

 

Для TC:

 

IMHO, у Вас проблема с времянкой в большом мультиплексоре у ACC0 и ACC1. При том кол-ве умножителей, которые описаны в коде, видится конвейерная реализация, где для каждого промежуточного результата при переходе автомата между состояниями, используется своя пара регистров (ну или регистр), а не пошаговое вычисление всего подряд на паре регистров-аккумуляторов.

 

 

Автомат должен не "умножать", а только давать сигнал "разрешения умножения". А "умножать" должен совсем отдельный блок. Тогда логики будет накручено значительно меньше

Поясните пожалуйста, каким образом "вытаскивание" автомата в отдельный блок может уменьшить критический путь и "накрученность" логики? Если при этом логика переходов у автомата не меняется, как и логика управления умножителями и мультиплексорами (и синтезатор это отлично видит)? Запись всего в одном always, или растаскивание на несколько влияет лишь на субъективную читаемость описания, и ни на что более.

[_Ivan_ 0]

Fat Robot, а что такое отчеты STA - что-то я не нагуглил такого?

И что я должен знать, чтоб освоить rtl симуляцию?

 

SM, наверное вытаскивание будет происходить следующим образом.Изначально у нас несколько регистров, затем идет мультиплексоры и это все идет на ячейку DSP48. Если их разделить, т.е. еще поставить 1 ступень конвейра между мультиплексором и ячейкой, то по идее это все будет побыстрее.

[des00 25]

наверное вытаскивание будет происходить следующим образом

Хоть не SM отвечу, вы гадаете на кофейной гуще. Откройте даташит на целевую ПЛИС и посмотрите как устроены DSP слайсы, тогда поймете как вот это

calc0: acc0_reg <= sin_value_reg * r_reg; //sfix32_En22
calc1: acc0_reg <= {acc0_reg[29], acc0_reg[29:0], 1'b0} + {h_reg[31], h_reg[31:1]};
calc2: acc0_reg <= square_wire[61:30];

в них ляжет и на какой приблизительно частоте.

[SM 0]

SM, наверное вытаскивание будет происходить следующим образом.Изначально у нас несколько регистров, затем идет мультиплексоры и это все идет на ячейку DSP48. Если их разделить, т.е. еще поставить 1 ступень конвейра между мультиплексором и ячейкой, то по идее это все будет побыстрее.

 

нет, я не это имел в виду. У Вас в разных состояниях автомата на входы регистров acc0_reg и acc1_reg мультиплексируются выходы различных вычислителей. Я предлагаю в разных состояниях делать запись в разные регистры, чем убрать этот мультиплексор, увеличив кол-во регистров, и уменьшив критический путь (как он мне представляется, не видя отчета STA).

 

STA - это отчет статического анализа таймингов. Там видно, где и через что проходит критический путь.

 

UPD:

Возможно, эту модификацию можно сделать даже не выходя из симулинка. Но точно не знаю.

 

UPD2:

И square_wire убрать вообще, записывая в соотв. регистр сразу нужный выход нужного умножителя в состояниях calc2 и calc3 - а то там еще один мультиплексор окопался.

[FatRobot 0]

STA = Static Timing Analysis.

 

Чтобы освоить rtl-симуляцию вам понадобятся некоторые начальные знания об языке описания аппаратуры, который вы используете. Verilog в данном случае. А также навыки владения симулятором.

 

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

 

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

 

Fat Robot, а что такое отчеты STA - что-то я не нагуглил такого?

И что я должен знать, чтоб освоить rtl симуляцию?

[egorman44 0]

Synopsys Timing Constraints and Optimization User Guide вещает

 

Static Timing Analysis

Static timing analysis is a method of validating the timing performance of a design by

checking all possible paths for timing violations under worst-case conditions. It considers the

worst possible delay through each logic element, but not the logical operation of the circuit.

----

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

 

Synopsys Timing Constraints and Optimization User Guide первая глава, рекомендую .

[_Ivan_ 0]

Fat Robot, ну это конечно классно, если считать, что уже второй год фултайм работаю в области плис... но вот проекта, сделанного от и до у меня к сожалению не было. Просто возможно не хватает наставника и на первых порах решения новых задач я делаю это весьма криво. Насчет вопроса об rtl-симуляции - ну я это делаю у себя, иногда в ISIM, иногда перебираюсь в Modelsim, тестбенч написать и проверить свой блок могу.

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