Indeed, Its an awesome video with good explanation. However, i have a simple question. You have not added, fanout violation here and yes i do see you did that split fan-out suggestion. In fact, we know once the transistion is fixed most probably we might not see fanout violation. However, I would love to know what are the given value for a max fanout and does this goes by process? Appreciate your kind reply.
Great Explanation!!! Can you please make a video on different types of files used in the physical design, what info do those files contain in them as well. example : SPEF, CTS SPEC, .tf, .lib, ndm, tluplus, .v etc. Also make a video on understanding various reports as well. Thank You!
Thanks for watching. I think there are some videos available on YT already on file types. But, I’ll think about making one on reports interpretation later.
Hi, Thank you for watching the video. Ideally the order would be (from the highest to lowest priority): 1. Design Rules (max tran, max cap) 2. Signal Integrity issues such as : Crosstalk, IR drop, Electromigration 3. Timing (setup, hold, recovery, removal, min pulse width, min period etc..) 4. Antenna, and other physical verification related fixes (DRC, LVS, ERC etc..) It’s always better to get the reliable signal first by fixing foundry design rules (like max tran/cap as defined in the .lib models and also any tighter design/frequency dependent constraints if applicable) and the signal integrity issues such as (Crosstalk, IR drop, EM) in the early phases of the implementation, so that the timing analysis is accurate at the first place. But in practical, Timing takes the highest precedence in the back-end flow, although design rule fixing happens (and others) simultaneously. Please note, fixing max tran/cap in the end, might cause hold violations in the design (because most of the times, fixing drvs will help improve the path delay, hence better setup time). In reality, fixing one causes to violate the other. Ultimately it’s an iterative process. So it’s always good to come up with a robust methodology/flow that will help you converge faster and to reduce the turn around time. Hope this gives you some insight. Let me know if you have any questions. Have a good day.
Here is the basic Pre-layout STA flow. 1. Read in the design netlist 2. Read in timing libraries 3. Link the design that you want to check the timing to and make sure there are no linking issues. 4. Source timing constraints (clock definitions, IO constraints, exceptions etc..) 5. Validate inputs 6. Generate timing reports and check your design has any timing violations. Hope it helps.
Thanks for watching the video. Min corners generally have sharper transitions/slews (when compared to max) and can potentially induce significant noise on the neighbouring nets. If you are still unsure on this, please do an experiment running noise analysis using both min & max corners and see what you find. Thanks.
Nice video and well made. Thank you. Best video for last min interviews to cover the topics.
Thank you Vikram. Hope you found it useful.
great lecture
Excellent video Mahendra. Keep up the good work.
Thanks for watching Ashok. Glad to hear that.
You explained extremely well. Actually, I keen to know the solutions more as compared to problem and you did the same.
Thanks a lot.
Glad it was helpful. You’re welcome.
@@mmkr can you please do video on congestion issue and fixes in placement and CTS
Ur explanation is simply superb sir. Easy to understand. Please do videos on Delay models like NLDM , CCS and AOCV, POCV/LVF.
Glad to hear that Rakesh. Thank you.
For POCV, please check out my other video using the link below.
ua-cam.com/video/gHnh4hg8kdQ/v-deo.html
Sure sir 👍
Thanks
@@mmkr Do you have any website
excellent video sir
Glad to hear that. Thank you.
Awesome video. Keep it up and continue awesome work
Thank you
Great content !! Thank you sir !!
My pleasure! Hope you found it useful.
Indeed, Its an awesome video with good explanation. However, i have a simple question. You have not added, fanout violation here and yes i do see you did that split fan-out suggestion. In fact, we know once the transistion is fixed most probably we might not see fanout violation. However, I would love to know what are the given value for a max fanout and does this goes by process? Appreciate your kind reply.
Glad I could help. Thanks for watching.
Please check the email for the answer.
Great work👍.
Thank you
Wonderful learning
Glad to hear that
Great Explanation!!!
Can you please make a video on different types of files used in the physical design, what info do those files contain in them as well. example : SPEF, CTS SPEC, .tf, .lib, ndm, tluplus, .v etc.
Also make a video on understanding various reports as well.
Thank You!
Thanks for watching.
I think there are some videos available on YT already on file types. But, I’ll think about making one on reports interpretation later.
very well explination !! shall you provide all this information through the blog
thank you 😊
Thanks for the suggestion. I’ll think about it later.
Great video. Can you please provide commands for sanity checks?
Thank you.
Can you please e-mail (8mahe8@gmail.com) me if you’re looking for a specific information. Thanks.
Sure I will mail thanks for your response 🙏
Ok. Thanks.
Hi sir I have mailed you yesterday please check
Replied. Thanks.
Can u help ...if we add a buffer in clock path for fixing max trans how to check timing paths ..
Thankyou so much ❤️
You’re welcome.
Hope you find it useful.
Out of this violating for which we have to give priority....can you reply with descending order (include asynchronous checks also)
Hi,
Thank you for watching the video.
Ideally the order would be (from the highest to lowest priority):
1. Design Rules (max tran, max cap)
2. Signal Integrity issues such as : Crosstalk, IR drop, Electromigration
3. Timing (setup, hold, recovery, removal, min pulse width, min period etc..)
4. Antenna, and other physical verification related fixes (DRC, LVS, ERC etc..)
It’s always better to get the reliable signal first by fixing foundry design rules (like max tran/cap as defined in the .lib models and also any tighter design/frequency dependent constraints if applicable) and the signal integrity issues such as (Crosstalk, IR drop, EM) in the early phases of the implementation, so that the timing analysis is accurate at the first place.
But in practical,
Timing takes the highest precedence in the back-end flow, although design rule fixing happens (and others) simultaneously.
Please note, fixing max tran/cap in the end, might cause hold violations in the design (because most of the times, fixing drvs will help improve the path delay, hence better setup time).
In reality, fixing one causes to violate the other. Ultimately it’s an iterative process. So it’s always good to come up with a robust methodology/flow that will help you converge faster and to reduce the turn around time.
Hope this gives you some insight. Let me know if you have any questions.
Have a good day.
@@mmkr Thank you
How to run STA before PNR, beginner for Physical design, kindly help
Here is the basic Pre-layout STA flow.
1. Read in the design netlist
2. Read in timing libraries
3. Link the design that you want to check the timing to and make sure there are no linking issues.
4. Source timing constraints (clock definitions, IO constraints, exceptions etc..)
5. Validate inputs
6. Generate timing reports and check your design has any timing violations.
Hope it helps.
Hlooo sir, plz do video on Physical cells
Hi, let me think about this later. Thanks.
Why should we check cross talk at min corners. Please explain.
Thanks for watching the video.
Min corners generally have sharper transitions/slews (when compared to max) and can potentially induce significant noise on the neighbouring nets.
If you are still unsure on this, please do an experiment running noise analysis using both min & max corners and see what you find.
Thanks.
Is there any TCL scripting doc
Could you please drop an email to 8mahe8@gmail.com
Thanks.
@@mmkrdo, How tcl script we use in tool with one example
Please make more videos sir on Physical design
will try!