FPGA Central

Tracing timing violations in the post-p&r generated netlist can be
cumbersome with all signal merging/renaming and inserted buffer. I was
wondering if there is a way that I can back annotate the post place
and route delays back to the RTL code? even approximate delays can
reveal some design errors I would think.

Thank you.

You don't seem to understand the processing from RTL to gates. When you do
the answer will become self-evident.


<[email protected]> wrote in message
news:[email protected] oups.com...
> Tracing timing violations in the post-p&r generated netlist can be
> cumbersome with all signal merging/renaming and inserted buffer. I was
> wondering if there is a way that I can back annotate the post place
> and route delays back to the RTL code? even approximate delays can
> reveal some design errors I would think.
>
> Thank you.
>

On Apr 12, 4:08 pm, elshou...@gmail.com wrote:
> Tracing timing violations in the post-p&r generated netlist can be
> cumbersome with all signal merging/renaming and inserted buffer. I was
> wondering if there is a way that I can back annotate the post place
> and route delays back to the RTL code? even approximate delays can
> reveal some design errors I would think.
>
> Thank you.

It would be great wouldn't it?

The main problem seems to be that there are at least two, and
sometimes three or more tools in the chain between RTL and placed &
routed gates. Tracing the heritage of gates back to RTL requires that
all of those tools cooperate in providing the necessary information in
a uniform manner. Often there is no direct heritage, given re-timing
and pipelining optimizations. Also, the RTL may have "hidden" some of
the gates in expressions or variables that cannot be directly
annotated with delays without major re-writing of the code.

I have found that if I do a good job simulating the RTL, and verifying
the constraints used for STA, the set of problems encountered during
full timing simulation is very limited.

Andy