cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
11,503 Views
Registered: ‎05-27-2015

Critical warning on implementation

Jump to solution

Hi,

 

When I am trying to implement a design in vivado, I get this annoying critical warning on time requirements.

 

CRITICAL WARNING: [Timing 38-282] The design failed to meet the timing requirements. Please see the timing summary report for details on the timing violations.

My design has a Zynq PS IP and a FSM that I made which has 30 to 40 states and next state logic is not that complicated. What I don't understand is that when I implement it alone: there is not such critical warning but when I implement in my design, I get this warning.

 

 

I looked in timing report which shows some number of failing endpoints (the number depends on the stratedy I choose to synthesise and implement). The problem is coming from setup times. How can I resolve this knowing that I have already tried most of the things mentionned in ug621 and Xilinx Timing Analysis Solution Center (http://www.xilinx.com/support/answers/40832.html).

 

Thank you very much in advance for yout help !

 

Kind Regards,

Abdul

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
21,225 Views
Registered: ‎01-23-2009

A 4ns (250MHz) path in a Zynq-7020 (which is Artix-7 based) is pretty fast. It is doable, but it has to be done carefully.

 

In your path, the source flip-flop has a lot of loads (25), and it looks like (from its name) it has already been replicated by the tool several times. From here it goes through a large cone of logic - 6 LUTs is a lot for this speed in this device. This is probably the source of your problem.

 

You will have to figure out why this flip-flop has so much fanout, and find an architectural mechanism of reducing the load on this flip-flop, or, at least, manually replicating it in a way that makes the most sense (separating the timing critical stuff on its own source).

 

The tool options that others are suggesting may be able to help you, but if you really want to fix this path you will have to address it architectually - modify your RTL code to either allow another pipeline stage for this path (either at the source, or preferably in the cone of logic) - pre-calculate some intermediate result on the clock before to move logic from this path into an earlier pipeline path - something like that...

 

Avrum

View solution in original post

0 Kudos
10 Replies
Highlighted
Moderator
Moderator
11,496 Views
Registered: ‎07-01-2015

Hi @abdulparis,

 

Please share your timing report.

Have you tried different strategies in implementation?

 

Thanks,
Arpan

Thanks,
Arpan
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Contributor
Contributor
11,494 Views
Registered: ‎05-27-2015

Yes I have tried lots of strategies but I still gets this critical warning. You can find the timing summary report attached to this comment.

 

Thank you very much for your answer.

Regards,

Abdul

0 Kudos
Highlighted
Moderator
Moderator
11,464 Views
Registered: ‎07-01-2015

Hi @abdulparis,

 

Can you try using different strategies in implementation?

Please go through following link
http://www.xilinx.com/support/documentation/sw_manuals/xilinx2012_2/ug938-vivado-design-analysis-closure-tutorial.pdf

 

Thanks,
Arpan

Thanks,
Arpan
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
1.JPG
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
11,452 Views
Registered: ‎05-07-2015

HI @abdulparis

 

Thanks for sharing the report.

 

i see that the setup failures are on clk_fpga_0 clock domain. Violation are due to datapath delay being higher than clock period(4 ns).

 

As  75% data path delay is routing delay. You can try the phy_opt_design option with aggressiveFanoutOpt directive, which does the placement aware fanout optimizations to   try and meet the timing  in the implemented design.

 phyopt.JPG

Thanks
Bharath
--------------------------------------------------​--------------------------------------------
Please mark the Answer as "Accept as solution" if information provided addresses your query/concern.
Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
Highlighted
Contributor
Contributor
11,414 Views
Registered: ‎05-27-2015

Thank you very much @nagabhar for your answer. I am trying to do what you said. I will let you know what happens. Thanks again.

@arpansur, I had already tried different synthesis and Implementation strategies but it could not eliminate this critical warning.

 

Kind Regards,

Abdul

0 Kudos
Highlighted
Contributor
Contributor
11,288 Views
Registered: ‎05-27-2015

I tried but it still would not work. The WNS ans TNS delays are less than before but they are still there and routing still represents aroud 75% of the delay.

 

Is there any design skills to avoid these types of critical warning about timing violation ?

 

Regards,

Abdul

0 Kudos
Highlighted
Guide
Guide
21,226 Views
Registered: ‎01-23-2009

A 4ns (250MHz) path in a Zynq-7020 (which is Artix-7 based) is pretty fast. It is doable, but it has to be done carefully.

 

In your path, the source flip-flop has a lot of loads (25), and it looks like (from its name) it has already been replicated by the tool several times. From here it goes through a large cone of logic - 6 LUTs is a lot for this speed in this device. This is probably the source of your problem.

 

You will have to figure out why this flip-flop has so much fanout, and find an architectural mechanism of reducing the load on this flip-flop, or, at least, manually replicating it in a way that makes the most sense (separating the timing critical stuff on its own source).

 

The tool options that others are suggesting may be able to help you, but if you really want to fix this path you will have to address it architectually - modify your RTL code to either allow another pipeline stage for this path (either at the source, or preferably in the cone of logic) - pre-calculate some intermediate result on the clock before to move logic from this path into an earlier pipeline path - something like that...

 

Avrum

View solution in original post

0 Kudos
Highlighted
Guide
Guide
11,268 Views
Registered: ‎01-23-2009

Oh - and 30-40 states in a state machine is a lot of states... I generally try and keep my state machines to a lot fewer states. There are always exceptions, but I start getting uncomfortable with more than 8-10 states in a state machine - generally, if there are that many states (again, there are exeptions), the state machine can be usually be broken down into two interacting state machines (or a state machine and a counter), where each state machine is substantially smaller...

 

Avrum

0 Kudos
Highlighted
Contributor
Contributor
11,219 Views
Registered: ‎05-27-2015

Thank you @avrumw so much for these advices. That is what I am trying to do right now: I have broken the FSM into 3 smaller FSM and one global FSM and now I can add pipelines as I wish. Doing so, I am hoping that I will be able to work at the wanted frequency.

 

Thanks again!

Regards,

Abdul

0 Kudos
Highlighted
Contributor
Contributor
8,648 Views
Registered: ‎05-27-2015

I am just having another question about FSM. Should we avoid using look-ahead output logic in FSM ?

0 Kudos