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

Computational time of Combinational Circuits sub components on FPGA

Status
Not open for further replies.
S

S.M.Badave

Newbie level 3
Joined
Apr 26, 2010
Messages
3
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,301
I wanted to find out computational time of components of sequential circuit on xilinx FPGA
 

What do u mean by computational time? I think whatever you are referring to will be available in the FPGA specific datasheet..
 

sharath666 said:
What do u mean by computational time? I think whatever you are referring to will be available in the FPGA specific datasheet..
Click to expand...

Thanks! I am working on 'Retiming of DSP architectures', So I need to find out computational time of each node. Xilinx software what i am using using is not supporting to find out it. Kindly support
 

When u say "computational time of each node" it seems to be an algorithm specific or architecture specific details. I don't know how Xilinx software can help u with that.
 

You cannot work out the delay through each element in the design - it varies with too many factors. Initially process, voltage and temperature, but it is also affected by the routing through the FPGA.

The timing analyser can give you an idea of delays at given temperatures.
 

Combinatorial logic has propagation delay, is that what you mean?

If so you could place the logic between two registers and find the maximum clock rate at which the circuit meets timing, which will be the sum of the logic and register propagation delays.

This is highly routing dependent obviously, and superficially the same logic can have widely different propagation delays depending on how the fitter has placed it (Which, if you have fully constrained the timing does not matter in practise).

The registers have the usual setup and hold times and a maximum clock rate (which will be given in the datasheet for the part).

Highest thruput is when you pipeline and register often enough to ensure the clock is the limiting factor not the internal setup and hold timing, which usually requires that the amount of combinatorial logic between registers be kept fairly small (Carry chains in simple minded ALUs are often the acid test here).
Lowest latency often comes from sacrificing clock speed to minimising the number of pipeline stages.

FPGAs are NOT CPUs, do not try to treat a HDL as programming, treat it as logic design.

Regards, Dan.
 

Dan Mills said:
Combinatorial logic has propagation delay, is that what you mean?

If so you could place the logic between two registers and find the maximum clock rate at which the circuit meets timing, which will be the sum of the logic and register propagation delays.

This is highly routing dependent obviously, and superficially the same logic can have widely different propagation delays depending on how the fitter has placed it (Which, if you have fully constrained the timing does not matter in practise).

The registers have the usual setup and hold times and a maximum clock rate (which will be given in the datasheet for the part).

Highest thruput is when you pipeline and register often enough to ensure the clock is the limiting factor not the internal setup and hold timing, which usually requires that the amount of combinatorial logic between registers be kept fairly small (Carry chains in simple minded ALUs are often the acid test here).
Lowest latency often comes from sacrificing clock speed to minimising the number of pipeline stages.

FPGAs are NOT CPUs, do not try to treat a HDL as programming, treat it as logic design.

Regards, Dan.
Click to expand...

Thanks Dan.
Really your opinion counts.
I did HDL programming and got desired result, however I searching for a method by which I can prove my result apart from all technological constraints. Can we cross check our design by some means w.r.t. design matrices given by EDA tool.
 

I don't think you can separate your design from the underlying architectural constraints once you go below the level of describing an implementation of an algorithm in general terms (There is a reason there are at least three common approaches to CORDIC and all get used, sometimes one is just a better fit then the others).

Sure you can demonstrate that some approach has lower fanout or less pipeline stages or whatever, but sometimes only one of those matters, and sometimes what you really care about is number of slices/CLBs (whatever the vendor calls them) used, and speed is unimportant.

Decide what is unique about your approach by comparison with equivalent blocks in the literature, and document that. It will probably not be better in all ways, but then it doesn't need to be in order to be useful.

Pipeline latency, number of flipflops, worst case fanout and number of LUTs are sane metrics when all else fails.

Regards, Dan.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top