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.
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.
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.
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.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
