Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

VHDL Multiplying by a fraction

Status
Not open for further replies.
S

Sofus

Newbie level 1
Joined
Mar 13, 2018
Messages
1
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
16
Hello,

I am working on an FPGA design where a 20 bit signal is transferred from one component to another component, where a procedure is performed using the 20-bit signal. The calculation performed in the procedure is multiplying the 20 bit signal by 0.00034, or 680/2000000, and then placing this value into a signal of the integer type. However this generates a negative slack for the transfer of data between the register of the 20 bit signal in the first component, and the register of the integer signal in the second component. When I look at the data path in the timing report, it seems that the bulk of the delay is due to the calculation performed in the second component. Is there a less time consuming way to perform the calculation? The calculation in the procedure looks like this at the moment:

Code: 
-- Calculates distance in centimeters
	PROCEDURE calculate_distance 
	(
		SIGNAL p_counter_data_in	:	IN std_logic_vector(19 downto 0);
		SIGNAL p_distance_data_out : OUT integer
	) IS
		
	BEGIN
	
		p_distance_data_out <= to_integer(unsigned(p_counter_data_in) * 680/2000000);
	
	END calculate_distance;
 

What frequency?
What technology?

I don't use fractions in my multiplications, so I'm not sure how many bits that will use in synthesis. I normally define any fractions with a parameter (Verilog) with a defined bit width and treat them as scaled integers, I never let the tools decide how many bits. In this case did the tools define it as 32-bits?
 

Sofus said:
Hello,

I am working on an FPGA design where a 20 bit signal is transferred from one component to another component, where a procedure is performed using the 20-bit signal. The calculation performed in the procedure is multiplying the 20 bit signal by 0.00034, or 680/2000000, and then placing this value into a signal of the integer type. However this generates a negative slack for the transfer of data between the register of the 20 bit signal in the first component, and the register of the integer signal in the second component. When I look at the data path in the timing report, it seems that the bulk of the delay is due to the calculation performed in the second component. Is there a less time consuming way to perform the calculation? The calculation in the procedure looks like this at the moment:

Code: 
-- Calculates distance in centimeters
	PROCEDURE calculate_distance 
	(
		SIGNAL p_counter_data_in	:	IN std_logic_vector(19 downto 0);
		SIGNAL p_distance_data_out : OUT integer
	) IS
		
	BEGIN
	
		p_distance_data_out <= to_integer(unsigned(p_counter_data_in) * 680/2000000);
	
	END calculate_distance;
Click to expand...

Can you use the microprocessor to do this multiplication part and output the result in integer??
 

Can you use the microprocessor to do this multiplication part and output the result in integer??
Click to expand...

This would be pretty pointless, as its a pretty straightforward fixed point multiplication

to the OP: Be careful with your operators. If you did (680/2000000) you would get 0, but actually you're getting (unsigned(p_counter_data_in) * 680) / 20000000.
The divide in this circuit is what is failing the timing. You should really convert 680/20000000 to some kind of offset integer, that you can then shift after the operation. This means no divider is needed. Something like this:

p_distance_data_out <= to_integer(unsigned(p_counter_data_in) * ( (680*(2**16)) /2000000) ) / (2**16);

This should ensure the calculation is a simple A*B, rather than the (A*B)/C you had before.
 
If you insist upon using non-power-of-two division, have you considered using an IP core or DSP block?
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top