Why does skew have to be reduced

Status
Not open for further replies.
I

identical

Member level 1
Joined
Feb 10, 2015
Messages
33
Helped
0
Reputation
0
Reaction score
0
Trophy points
6
Activity points
225
Why does skew have to be reduced when skew is actually helpful to fix setup (positive skew) and hold (negative skew). Why then, when we are talking about skew, it is said that it should be reduced.
 

If you let skew rampantly go all over the place then there is no guarantee that you will always have helpful positive skew for setup and negative skew for hold, You'll find 50% of the time end up with negative skew for setup and positive skew for hold, both of which make your timing harder to meet.
 
And in addition, if you are transmitting multiple bits/signals in parallel, you want them to be all valid at the same sample point in time when they get clocked in/latched at the receiver end.
Otherwise what you thought you sent out != what you received in
 
Deliberate skew is a design "knob" but abstract digital
weenies and their tools like everything ideal. Violating
this religious tenet may get your job done, but the
Inquisition awaits.
 
dick_freebird said:
Deliberate skew is a design "knob" but abstract digital
weenies and their tools like everything ideal. Violating
this religious tenet may get your job done, but the
Inquisition awaits.
Click to expand...

Less skew would mean more flops would be on at the same time and this will lead to power supply issues. So, why is it said that the skew has to be reduced. Didn't get a clear picture yet.
 

dick_freebird said:
Deliberate skew is a design "knob" but abstract digital
weenies and their tools like everything ideal. Violating
this religious tenet may get your job done, but the
Inquisition awaits.
Click to expand...

Hope this wasn't directed at me, never said it wasn't useful or that you shouldn't take advantage of deliberate skew to help meet timing.

My only issue is if you don't understand that skew can hurt you too, then you should get out of ASIC design altogether. A contrived example follows:

Say you have a design that has FF-multiplier-FF-multiplier-FF-multiplier-FF....and the final stage feeds back into the first FF. Now if each FF stage has 200 ps of useful deliberate skew to improve the setup time of the FF-multiplier-FF path then if there are 10 stages of multiplier-FF we end up with the final stage having a clock that is skewed by 2ns from the first stage (200 ps * 10 stages). No if you were trying to run this circuit at 500 MHz you're going to be out of luck as now your first stage clock lines up with your final stage clock for the OLD data not the updated data. Your feedback ends up being late.

This certainly doesn't help you even though you use useful deliberate skew to give you more setup time, so there are limits with this technique.

So don't label me an Inquisitor, I'm just trying to demonstrate that you have to know what the skew does to your design and use it with the knowledge of why you want the extra skew and how you are going to compensate positive skew with negative skew on any paths that have feedback loops. If all your designs only go one direction and have no feedback you can always take advantage of positive skew over every clock branch and just have an output that has a lot of skew from the input (though you probably should no longer consider this output to be synchronous to first stage clock input).
 
identical said:
Why does skew have to be reduced when skew is actually helpful to fix setup (positive skew) and hold (negative skew). Why then, when we are talking about skew, it is said that it should be reduced.
Click to expand...

This is outdated way of thinking. Skew doesn't have to be reduced, not always.

Reducing insertion delay is a good thing, that's certain. Skew should be exploited and turned into useful skew. The end result is pretty similar to retiming.
 

identical said:
Why does skew have to be reduced when skew is actually helpful to fix setup (positive skew) and hold (negative skew). Why then, when we are talking about skew, it is said that it should be reduced.
Click to expand...
Yes, skew is an advantage in specific cases.
But it should be skewed in an appropriate approach. Current EDA does not have the useful skew feature which operate automatically.
We need to make less skew as possible for a good startpoint, then finding the portion where skew is useful.
 


Not true. I have used useful skew in all of my recent tapeouts. Automatically, that is.
 


Well, Synopsys also has useful skew methodology in ICC. ICC command skew_opt (old one) and concurrent clock_data optimization (the newest one).

Still, the possible problem with useful skew may arise when you are doing CTS and optimization only in one PVT corner. But, later, doing signoff STA in many corners, so usefull_skew was good for setup/hold in one corner, but may bad for hold in another PVT corner.
 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…