[SOLVED] How to resolve Timing Violation in back annotation with post gate level simulation?

[coshy]

Dear All,
I'm trying to resolve current timing violation in back annotation with post gate netlist simulation.
Our third party Back-End company progressed STA and made SDF.
As you can see the below, that is the simple SDFF register. Inputs are clk, din, reset and output is dout.

Here is I can't understand because there is no reason for unknow value of dout. why suddenly dout makes the unknow value?
If this Timing Violation is valid, What thing should I have to check to resolve?

 

[FvM]

Guess we see result of din setup timing violation.

 

[coshy]

Guess we see result of din setup timing violation.

Thanks. Why does it make a setup violation? Is it setup violation possible that even though STA passed?

 

[D.A.(Tony)Stewart]

What is setup time?

 

[ThisIsNotSam]

Thanks. Why does it make a setup violation? Is it setup violation possible that even though STA passed?

the question is not whether it passed or not. the question is whether what you call STA is what hey call STA. your simulation environment might have wildly different assumptions than the STA checks performed by the backend team.

 

[coshy]

What is setup time?

the question is not whether it passed or not. the question is whether what you call STA is what hey call STA. your simulation environment might have wildly different assumptions than the STA checks performed by the backend team.

From recommands, I have searched Standard Cell Librat DATASHEET.
Pin D has specific requirments.
setup (high ) 0.024997
setup (low) 0.034080

but when I check, sc9mcpp84_14lpu_base_lvt_c16.v there's are defined ARMSETUPTIMEandARMSETUPTIMEandAR_HOLD_TIME $setuphold(posedge CK &&& (ENABLE_NOT_D_AND_NOT_RAND_SI == 1'b1), negedge SE, ARMSETUPTIME,ARMSETUPTIME,ARM_HOLD_TIME, NOTIFIER, , ,dck,dSI);

From Here I'm confused that ARM_SETUP_TIME defined 1.0 and AR_HOLD_TIME is defined 0.5.

Do I need to modify Standard Cell Library verilog model defines as DATASHEET?

 

[harpv]

dout goes 'x' even when there's no change in din w.r.t second clk edge. so, this might not be a real timing violation.
Or another scenario is you actually have a 2-stage synchronizer cell and not a simple DFF, hence dout which is output of second stage will be =1 for one cycle and 'x' in the following.

 

[ThisIsNotSam]

From recommands, I have searched Standard Cell Librat DATASHEET.
Pin D has specific requirments.
setup (high ) 0.024997
setup (low) 0.034080

but when I check, sc9mcpp84_14lpu_base_lvt_c16.v there's are defined ARMSETUPTIMEandARMSETUPTIMEandAR_HOLD_TIME $setuphold(posedge CK &&& (ENABLE_NOT_D_AND_NOT_RAND_SI == 1'b1), negedge SE, ARMSETUPTIME,ARMSETUPTIME,ARM_HOLD_TIME, NOTIFIER, , ,dck,dSI);

From Here I'm confused that ARM_SETUP_TIME defined 1.0 and AR_HOLD_TIME is defined 0.5.

Do I need to modify Standard Cell Library verilog model defines as DATASHEET?

are you using an SDF file?

 

[coshy]

are you using an SDF file?

Yes, and use it $back_annotation(my_sdf,...,)

 

[ThisIsNotSam]

Then you need to apply your engineering skills and understand if this a single path failing or several (all?) paths everywhere. This would indicate whether it is a timing problem or a simulation setup problem.

Also make sure the verilog code you are using for the std cells is appropriate for what you are doing. ARM, if I am not mistaken, has a lot of switches that you can turn on/off and the model will change accordingly. You have to make sure you are not using the unit model, where every gate takes 1 time unit to propagate a signal. This will never give you a timing-aware simulation.

 

[coshy]

Then you need to apply your engineering skills and understand if this a single path failing or several (all?) paths everywhere. This would indicate whether it is a timing problem or a simulation setup problem.

Also make sure the verilog code you are using for the std cells is appropriate for what you are doing. ARM, if I am not mistaken, has a lot of switches that you can turn on/off and the model will change accordingly. You have to make sure you are not using the unit model, where every gate takes 1 time unit to propagate a signal. This will never give you a timing-aware simulation.

I am still checking the same problem.
I am getting timing violation now and the data of f/f is data made in different clock.

Can I disable timing check when simulating between different clocks?

How do you usually solve the timing violation problem between different clocks?

when I check with back-end third party company, I suggest that just modify the SDF at that violation point. but they refuses my opinion because that's not the perfect solution. if there are another Timing violation, they would work endless for that.

 

[ThisIsNotSam]

I am not sure you can disable only clock crossing checks, I have not seen than possibility in any library I have worked with.

In a way, those violations are expected. You should not be "fixing" them, assuming you have a synchronizer in place.

 

[FvM]

Synchronizers and DCFIFOs should set false path(es) for the specific transfer(s). You should check if the reported violations are due to unwanted respectively unsafe clock crossings or due to improper constraints of intentional crossings.

 

[ThisIsNotSam]

If you build your own synchronizer, it will have just regular FFs and the simulation models will be the same. So OP's simulation will keep failing. And this is correct.

False paths set out in synthesis will also not propagate to the netlist. I am not sure there is anything to be done here. Either you disable all timing checks or none, I cannot think of any way to do it selectively.

 

[coshy]

Synchronizers and DCFIFOs should set false path(es) for the specific transfer(s). You should check if the reported violations are due to unwanted respectively unsafe clock crossings or due to improper constraints of intentional crossings.

I'm curious how you usually simulate in post-simulation when there is a timing violation between different clocks.

Probably, if you are synthesizing, you are synthesizing with set_false_path, so you don't have the timing violation problem at synthesis. But in the actual post back_annotation, this will definitely happen, so how did you guys solve this problem?

 

[ThisIsNotSam]

Well, I didn't. Time annotated simulation of a netlist is not something I particularly put a lot of value on. It is useful as a sanity check of sorts, but STA still is the king. (This is my opinion, not necessarily shared by others). If STA passes and LVS passes, I am happy. If there is time before the tapeout deadline, let's have a deeper look into gate sims...

There is debugging value in such simulations, that is for sure.

Also, specific for clock domain crossing, there are tools that check only for that and they are exact/formal. They do not need simulation.