porting virtex2-pro into virtex4. Performance!!

Hello.

I implemented floating point adder in virtex2-pro and now recomplied it in virtex4. There is no compile error in synthsis & implement. But the performance (speed) is a little reduced. So I want to improve the speed. Is there anyone who can let me know how to start ? I mean what part I should focus on.

Reply to
lkjrsy
Loading thread data ...

Maybe some simple changes in the HDL-code can help and you don't even need to try different parts. The entire Virtex4-architecture (V5 as well) is optimized for synchronous resets. For example, some synthesis tools automatically infer the fast DPS48s for counters, but only if you use a synchronous reset, because the hard-macro is designed for a synchronous reset. If you have an asynchronous reset, the synthesis tools synthesize LUT-based counters, which use up more resources and could be slower.

It's possible that the same applies for arithmetic functions you use in your floating point adder.

--
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...
Reply to
Sean Durkin

Hi Sean,

Thank you for this info... So, In Virtex 4 to utilize max benift of these cores, we need to make reset - sync signal using Dual Flop synchronizers?

Regards, JK

Reply to
JK

The problem is not only the reset signal itself, but the way it is connected to your logic.

If you have something like this:

asynch_reset: PROCESS (clk, rst) BEGIN IF rst = '1' THEN counter '0'); ELSIF clk'event AND clk = '1' THEN counter

Reply to
Sean Durkin

Sean Durkin schrieb:

[D-FF with async reset]

... [D-FF with sync reset]

.. and totally different behavior. ;-)

Synchronous resets are signals like any other signal (except that there is a big fanout to this signal but this is handled well by the synthesis tool). Asynchronous resets are special signals where signal skew is a big problem. One should use global signal buffers and global (dedicated) reset wires in FPGAs. Often they can be inferred using a primitive as mentioned in every manual of FPGAs.

For performance problems I would suggest to read the timing report _very_ carefully and to try to understand where the critical path is. This includes looking into the netlist and being creative to have an imagination, about what signals the timing report talks.

Ralf

Reply to
Ralf Hildebrandt

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.