VHDL abs() function speed

[gahelton]

I am having problems meeting timing requirements for my FPGA design (VHDL). According to the timing reports, the bulk of the timing errors are related to math functions in my ALU. The math functions are 32 by 32 bit with 64 bit temporary values for the multiplier and divider (there is no HW multiplier blocks for my particular part). These 64 bit adders and subtractors are the primary cause of timing failure, so I replaced them with fast look ahead carry versions. I think that this is going to help tremendously. However, the division and multiplication components also use the "built in" abs() function for VHDL. Of course, the abs() function would have to negate an input value if it were negative. Negation means twos-complement, which also means an internal addition has to take place.

But what kind of adder gets synthesised in the abs() function ? Ripple carry adder, fast look ahead carry adder, or something else ? It matters a lot when it comes to speed.

I know that I can roll my own, by checking the sign bit, and if needed, performing the negation with a 1's complement and my fast adder.

Am I being overly paranoid ? Will the synthesis tool do a good job on the abs() function to make rolling my own unnecessary ?

Thanks in advance.

 

[barry]

Why don't you just synthesize it and see what happens?

 

[dpaul]

Speed is important, true, but so is also a timing clean bitstream. In many cases it is easier/practical to introduce some latency rather than breaking your heard over a new logic that is faster.
Hence in your case (!you need to investigate and decide!) you might want to use those register stages to resolve timing violations (at the arithmetic blocks) rather than rolling out your own logic for faster operation. If I were you I would consider if the system design can live with a couple of clk cycles latency.

 

[KlausST]

hi,

or pipelined processing.

Klaus

 

[gahelton]

Thanks for the replies everyone. The timing violations (as reported) were primarily in the division component, and they were register to register violations due to the ripple effect of the subtraction portion (as best as I could tell). There were no reported violations in the abs() function. The code is already pipelined in that takes a clock per bit for the division (subtraction) until complete. Putting the fast Brent-Kung subtractor within the division routine should take care of the register to register violations. But the abs() function, due to its nature, cannot be pipelined (least not be me) since it is a predefined function. If it's inherently "slow" due to a ripple carry add internally, then that's just what it does.

I've been working on the project for a long time, changing this, that, etc trying for improvement, and I just want to take my best shot this time. I was just wondering if anyone had experienced a particular problem (with speed) for the abs() function.

I am going to roll my own abs() function equivalence with a sign check, 1's complement, then add 1 with my fast adder if needed. This WILL be pipelined, and should be as fast as I can possibly make it (clock to clock, but not absolute time).

Thanks again for the replies. I am looking for expert opinions. Also, expect another post from me on a timing related issue.