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

What are the steps after facing a violation in STA ?

Status
Not open for further replies.
D

dynamicdude

Member level 2
Joined
Mar 15, 2005
Messages
47
Helped
1
Reputation
2
Reaction score
0
Trophy points
1,286
Location
India
Activity points
1,855
snake path rtl

What are the steps done after facing a violation in our design?Is modifiying the rtl the only way or do you have any methodology for that.

Please refer me any site for STA if there is any.
 

static timing analyis

if violation is minor, u can resynthesis with modified constraints..
 

Re: static timing analyis

constrain it properly and see that all the constraints are realistic.... and try to use more drive strength std cells in ur design..
 

Re: static timing analyis

Changing the RTL is the last thing that is done , because if you do change the RTL then you need to redo all the tasks ... including verification .. First find out by what extent your design is slacked ... use case analysis in PT to check what would be like if you upsize a certain cell/buffer .... check your path ..see who is causing the maximum timing damage ... check if you have any other cell that can be used instead only when u find there is nothing that can be done then think about changing the RTL
 

Re: static timing analyis

i think you should analyze the violation report carefully. re-synthesis shoud not be done unless it is no other way. may be optimization and change cell manually could also help. you could also try different placement option.
 

static timing analyis

modifying rtl design is one useful method, alternative way is modifying at the layout step.
 

Re: static timing analyis

Well it depends on kind of violations that are present.
If it is hold violation, most of them can be fixed during layout. Usally there should be no setup violation after synthesis phase.

There are many methods of reducing delay to meet the slack like logic replication,buffer tree insertion to name a few.

Usally changing RTL is the last option,reason being the time required to verify
the changed RTL. Below is few things that needs to checked b4 going for change in RTL:
1.Check the environment setting.
2.Correctness of the constraints.(clocks, io delays etc.)
3.Identified all the exceptions in the design.(False paths, multicycle paths, case analysis etc)
4.Tried all the optimization methods in synthesis phase.

Hope this helps.
 

static timing analyis

resynthesis or make modification on RTL code
 

static timing analyis

usually, synthesis and sta script are developed separately. but the the constrain should be likewise

the first thing you could do is check the violation with module owner to see whether it really affect the function. i've see many time the violation occurs just because you set the wrong constrain.

if the violation do dangours, check out with your synthesis team to find out if they had miss the constrain or set a wrong one.

Changing RTL is the last result, but seldom do it. because if the timing is really tight, special care should already be taken by the synthesis team, and module owner should already pointed it out
 

static timing analyis

sometimes the violation occurs just because you select a inproper relative clock.
 

Re: static timing analyis

Hi
the main cause of the vioaltions are the incomplete, inconsistent and incorrect (The three 'C's) constraints.
we need to modify the constraints and do the synthesis etc again.
how ever Atrenta's SpyGlass-Constraints tool can help everyone with its analysis of the constraints with the rtl code to varify the three 'C's of constraints and can help reduce the violations significantly at the rtl stage itself thus saving time for the iterations required for synthesis ..........etc.
its the best of its kind in present scenario and vcry help to save the time.
other wise you need to go back to the first step in design flow --change the rtl.
 

static timing analyis

Hi,

1. If the violations are really small, just let it go!!! Since the best-best case and/or worst-worst case might not really happen... :)
2. Modified gate level netlist manually, and then do the ECO
3. Re-synthesis with modified constrains (step 2 is usually more powerful than this step, just if you can do it)
4. change the RTL
5. Change your Floor plan
6. Change your architecture, algorithm...
7. Change your spec.
8. Pray and God bless you... :)
 

Re: static timing analyis

To resolve timng violations, you need to carefully analysis the STA report to find the reason that cause the violation. Typically, the reasons are:

1. Inproper constraints at module level. If you use a bottom-up compile methodology, it very likely that when you compile at module level, timing budget is not correct, and the problem raise when you stitch them up at top level. A top level incremental compile can normal resolve this, but sometimes, the design is too big to fit into an incremental compile.
2. Snake path. This typically caused by your design is not correctly partitioned.
 

Re: static timing analyis

Sometimes, you can redo floorplan, modify some location io and hard-block. Maybe, the violations are still existed, please resynthesize your design. last, modify RTL code to meet timing.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top