11-14-2013 05:02 AM
I am generating bit file for my project in Xilinx ISE v 14.5 on linux PC(Red Hat, Release 6.1). There are timing violations in twr(timing) report.(Here I have attached report files)
In my twr report at line no 2879, in physical resource coloumn , signal name process_rxfer is register. Yet tool does not break path at register process_rxfer.
Register process_rxfer is not trimmed/optimize during synthesis process. I have also made netlist file after place and route. In netlist file I can see register process_rxfer (line # 43 ).
Here I have attached files.
Pls give me guidance for this problem.
11-14-2013 10:32 AM
11-14-2013 03:29 PM
You need to be a little careful about over-analyzing the names of objects within the timing reports.
When you synthesize your RTL, xst synthesizes the design to an interconnected netlist of Basic ELements (BELs). A BEL can be a LUT, a FF, a wide MUX element, a carry chain element, a DSP cell, a BRAM, a distributed RAM, etc.... Each of these BELs is given a name by the synthesis tool, which, where possible, is related to something in your RTL code.
One of the first processes in the rest of the implementation pass is map. One of its functions is to pack BELs into slices. Depending on your technology, there are a number of LUTs, a number of FFs, a number of wide mux elements, and a number of carry chain elements in each slice. The rest of the processes (place, route, timing analysis) run on the slice representation of your design.
Since this includes trce, the tool that generates the .twr file, it is doing its reporting based on the interconnected netlist of slices - NOT BELs. So, here is the thing... What is the slice named? The answer is, that it inherits the name from one of the BELs that was packed into the slice. As for which one, its impossible to tell.
In your case, what almost certainly happened is that a slice got packed with a certain number of LUTs and at least one FF - the FF that holds process_rxfer. The slice inherited the name process_rxfer from the FF... This report, though, is telling you that you are going through a LUT (that's what Tilo is) that is in the slice named process_rxfer. But that's just the name of the slice, which it inherited from the (potentially unrelated) flip-flop that also got packed into this slice.
So, the path is correct - the propagation through this LUT is part of your real critical path, even though the slice has the name process_rxfer. To confirm that, look at the names of the nets that feed in and out of this LUT - you should be able to determine that these nets can't possibly be the input and output of the process_rxfer flip-flop; they are part of a combinatorial path.
This is one of the many things that are better in Vivado. In Vivado, the entire tool chain works at the BEL level - including the placer, router, and timing reporting engine. Therefore, in Vivado timing reports, you can see the name of each BEL in the report, and don't end up with this confusing looking situation, where you see a name that is unrelated to the actual path in question.