Hi Shivam, When I was initially setting up this course, I looked at some of the material from my term at EPFL and from my colleagues at ETH-Zurich, but I cannot provide you with this material. It may, however, be available online, as these institutions tend to share their materials. IDESA is a private company that gives tutorials and courses, and therefore, I cannot share any of there material, but you can sign up for one of their excellent courses.
When you use the commercial EDA tools within an industrial environment, you have to purchase licenses and these tend to be VERY expensive. There are different licensing models, but in general, the more compute power you need and the more users concurrently using the same tool, the more such licenses are required. Luckily, in academia, at least that part is a lot easier...
I think if you have since watched Lecture 10 ua-cam.com/video/O2Od1Tey-Jo/v-deo.html, you may have understood the point better. In general, we need to supply the chip with power and we do it from as many locations as possible - connecting the power supply (e.g., battery) to the package through the board and from the package we feed it into the chip through the I/Os (or bumps). When we connect VDD somewhere, we cannot use that connection for a signal, so there is a tradeoff. We need to decide where to connect VDD (and GND, etc.). We also need the I/O power supplies to be close to the chip outputs to supply current to the output nets.
Thanks for your sharing for this video ? Could you give some advice for Power Planning Part (Such us how to choose the Power Ring Width , how many sets of them , and the stripe spacing ...)
Hmmm... Very very tough one to answer. This is really something that I am not aware that there is a good methodological approach to solve. In fact, it's a bit of "black magic" kept by some backend leader in each company. However, there are tools to ensure that you put enough power. The tool from Cadence is called "Voltus" and it has features, such as "early rail analysis" to help plan your power grid and "EM/IR analysis" for verifying that the grid is robust enough after implementation. I don't currently have a video telling much about these tools, but I may prepare one in the future.
For an electronic "circuit" you need a "full loop". So you send current to the device and that current needs to return in order to close a circuit (otherwise, it's an open circuit). Hence, "current return paths".
Hello Sir, I have a question. Why do we see very high utilization (70%) at this early stage of floorplan where placement of std cells is also not done? As per my understanding, at floorplanning we only put macros , I/O Pads ( not sure about IO buffers in the I/O buffer only channel between the macro and core boundary, do we also put that? ) how will utilization reach 70% ? and if it is such a high, wouldn't that exceed in placement stage only and no space for Clock cells and optimization? Thanks
Hi Hrishikesh, I think that maybe I didn't explain that point very well. The 70% utilization includes the standard cell area. In other words, the tool does a very simple calculation, where it takes the sum of the area of all the IPs (=standard cells, IOs, memories, etc.) and divides it by the floorplan area. So the 70% utilization is basically leaving 30% extra area for clock cells, optimization, and maybe most important, to alleviate routing congestion. Some designs will converge at a much higher initial utilization, while others will need a much lower utilization or to mark of areas of partial placement blockage to converge.
Hello Sir, how does creating keep-out margin for any standard cell reduce routing congestion? since the routing is done on completely different layers on a silicon floor, how would this empty space help reduce the routing congestion? Thanks
Great question. Indeed, this could be a bit counter-intuitive, since - as you pointed out - the routing is on the backend layers, while the standard cells are on the frontend layers (optimally, entirely M1 and below). However, the main cause of congestion in logic areas* is what we call "pin density", which is the number of connection pins per unit area. (* The reason I say "logic areas" is because many congestions are caused due to lack of routing resources due to macros that block backend layers) When there is high pin density, the router needs to go down to M1 at many places in a small area and route each of these connections to other standard cells or macro pins. This causes a lot of congestion on the lower layers that have to be traversed through in order to make these connections. Therefore, by padding the cells, the pin density is reduced (the effective standard cell area grows, while the number of pins is unchanged), ultimately alleviating the congestion in the logic areas. Note that this does not help congestion around macros, which is caused by high pin density on the macros and a bad floorplan (or tough area constraint).
Thank you so much for this wonderful playlist. I had a question, in the summary section we see defination of global nets, would this still be required if we have p/g tracks? Idea being if we can get vdd/vss from the p/g mesh I assume we wouldn't require the global nets. I would really appreciate a clarification.
Yes, we still need the global nets (at least in Innovus). The global net is basically a toplevel naming convention for the p/g net. It's not a physical thing, but it's used by the tool to connect the p/g pins of different cells. For example, lets say you have a standard cell library with the p/g pins called "VCC" and "GND" and a memory with pins called "MVDD" and "MVSS". But VCC=MVDD and GND=MVSS. To make this connectivity at the toplevel (the hierarchy above), we first create global nets (e.g., "Global_VDD" and "Global_VSS") and then connect VCC-->Global_VDD, MVDD-->Global_VDD, GND-->Global_VSS, MVSS-->Global_VSS.
In newer process technologies - from around 65nm and below - there are hard restrictions on the orientation of transistors. So you can't just draw your poly any which way. The transistors usually have to be in the same direction. In this case, a hard macro can usually be flipped on one axis, but not rotated 90 degrees (which would make its poly's in the wrong direction).
Hi. Actually, I have moved my content to the EnICS Labs website, and I didn't update the description in this video. Thank you for pointing this out - I have now updated it. Notice that a few years ago, I edited the series and uploaded it in shorter 10-20 minute clips, also with Kahoot quizzes for recitation and a few newer videos. Therefore, I suggest you use the playlist at ua-cam.com/play/PLZU5hLL_713x0_AV_rVbay0pWmED7992G.html You can find the links and slides to all my content at: enicslabs.com/academic-courses/
No. I use PowerPoint. I use Latex for writing academic papers and even though I used to be a big MSWord pro, I am now a big Latex fan and go crazy when colleagues and students use Word. But for slides, I find that PowerPoint is just so much more efficient and easy to use. I've never been a beamer fan (and in fact, I actually don't like what most Latex slides come out looking like...)
It is quite an abstract recommendation, but it just means, go back to synthesis (or even RTL) and try to change things so you won't have this problem. I can't tell you "how" to do this, since it is really a per-case situation and doesn't always (...usually) have a solution, but in some cases, if you would have changed something in synthesis, you wouldn't run into a specific problem.
One of the example for this is scan chain re-ordering which is done internally by place_opt_design. Please have a look at that concept of you have time.
The point is that you are implementing a macro as part of a hierarchical flow. So the top level wants to route a signal through this area that is being implemented standalone - independent of the toplevel. Without blockage, the area required for the feedthrough would be used for other nets. You can either apply blockage to make sure it won't be routed through. Or you can implement the feedthrough route at the macro level instead of the toplevel.
Hi Himanshu, good question. Indeed, the halos or placement blockages are recommendations, not something that is necessarily a must. The main reason is pin access and overall routing near the macro. So for the pins, let's say you have a high pin density on a certain side of the macro and you need to connect many wires to these pins in a small area. You want to free up as many routing resources as possible in this area. However, standard cells require connections and routing on lower layers and therefore they can use up those routing tracks that would be needed to connect to the macros. Another general reason is that usually there are routing blockages on the macro itself, which means that there are fewer routing resources for the higher level to use. Therefore, we want to free up the areas close to the macro so that any required routes will not be disturbed by routing to standard cells in that area. The corners are the worst area in that sense, which is why we add additional placement blockages at the corners.
Thanks .One doubt- Gate level netlist of one RTL design(module) is divided into different blocks?or One RTL design is divided into different blocks before synthesis?
I'm not exactly sure I understood your question, but here is my try to answer. RTL is usually divided into many modules. The higher modules instantiate the lower modules in a hierarchical fashion. This is mainly to simplify the design ("divide and conquer") and to enable design reuse. For this reason, in the lecture on Verilog for Synthesis (earlier in this series), I point out that good practice is to put each module in a separate file called .v You would then read all of these files into the synthesis tool (or simulation tool, for that matter). During elaboration and synthesis, the tool will ungroup the majority of the modules to optimize the logic between them. This means that the hierarchy is lost and their is no more division between modules. Some of the hierarchy will be kept, but unless explicitly defined to not ungroup a certain module, the synthesizer can "do as it pleases". So the gate level netlist will have some degree of hierarchy, but it is generally quite flat.
@@AdiTeman Hi sir, is it true that ungrouping removes (or collapses) the level of hierarchy of the identified subdesign and merges the subdesign with the surrounding logic ? Or can you please explain ungrouping in details?
Hi Akash, sorry for not responding. I didn't see your question. Yes, in general, ungrouping removes the hierarchical barriers between the modules. This enables cross hierarchical boundary optimization. Just as a simple example, lets say that a signal is inverted to be driven into an instantiation and then is inverted again at the input to this instance, by ungrouping, the two inverters can be removed. The drawback, of course, is that it makes it harder to debug. But the common approach is to ungroup almost everything that is not placed and routed independently.
Thanks for pointing this out. I have checked the link to this lecture (on my faculty website: www.eng.biu.ac.il/temanad/digital-vlsi-design/) and it seems to be fine. Can you tell me which one/s didn't seem to work?
This set of tutorials for ASIC design are so great, thanks Adi !
Your welcome!
Best explanation ever! thanks!
Glad you think so!
Can you tell me more about reference you have mentioned at the last . About EPFL tutorial and IDESA specifically? and thank you for the lecture
Hi Shivam,
When I was initially setting up this course, I looked at some of the material from my term at EPFL and from my colleagues at ETH-Zurich, but I cannot provide you with this material. It may, however, be available online, as these institutions tend to share their materials. IDESA is a private company that gives tutorials and courses, and therefore, I cannot share any of there material, but you can sign up for one of their excellent courses.
wonderful！thanks！！！
You're welcome!
Sir, at 36:51, you told it will take fewer licenses, can you please explain this.
When you use the commercial EDA tools within an industrial environment, you have to purchase licenses and these tend to be VERY expensive. There are different licensing models, but in general, the more compute power you need and the more users concurrently using the same tool, the more such licenses are required.
Luckily, in academia, at least that part is a lot easier...
At 1:00:21, please explain the point, number and location of power pads per voltage depends on the switched I/O's we have....
I think if you have since watched Lecture 10 ua-cam.com/video/O2Od1Tey-Jo/v-deo.html, you may have understood the point better.
In general, we need to supply the chip with power and we do it from as many locations as possible - connecting the power supply (e.g., battery) to the package through the board and from the package we feed it into the chip through the I/Os (or bumps). When we connect VDD somewhere, we cannot use that connection for a signal, so there is a tradeoff. We need to decide where to connect VDD (and GND, etc.). We also need the I/O power supplies to be close to the chip outputs to supply current to the output nets.
Thanks for your sharing for this video ?
Could you give some advice for Power Planning Part (Such us how to choose the Power Ring Width , how many sets of them , and the stripe spacing ...)
Hmmm... Very very tough one to answer. This is really something that I am not aware that there is a good methodological approach to solve. In fact, it's a bit of "black magic" kept by some backend leader in each company.
However, there are tools to ensure that you put enough power. The tool from Cadence is called "Voltus" and it has features, such as "early rail analysis" to help plan your power grid and "EM/IR analysis" for verifying that the grid is robust enough after implementation. I don't currently have a video telling much about these tools, but I may prepare one in the future.
thank you, it's been very useful to me ^^
At 50:28 what does it mean, provide current return paths for signals?
For an electronic "circuit" you need a "full loop". So you send current to the device and that current needs to return in order to close a circuit (otherwise, it's an open circuit). Hence, "current return paths".
Great work sir👏👏
Thanks!
Hello Sir, I have a question. Why do we see very high utilization (70%) at this early stage of floorplan where placement of std cells is also not done? As per my understanding, at floorplanning we only put macros , I/O Pads ( not sure about IO buffers in the I/O buffer only channel between the macro and core boundary, do we also put that? ) how will utilization reach 70% ? and if it is such a high, wouldn't that exceed in placement stage only and no space for Clock cells and optimization? Thanks
Hi Hrishikesh,
I think that maybe I didn't explain that point very well. The 70% utilization includes the standard cell area. In other words, the tool does a very simple calculation, where it takes the sum of the area of all the IPs (=standard cells, IOs, memories, etc.) and divides it by the floorplan area. So the 70% utilization is basically leaving 30% extra area for clock cells, optimization, and maybe most important, to alleviate routing congestion. Some designs will converge at a much higher initial utilization, while others will need a much lower utilization or to mark of areas of partial placement blockage to converge.
Hello Sir, how does creating keep-out margin for any standard cell reduce routing congestion? since the routing is done on completely different layers on a silicon floor, how would this empty space help reduce the routing congestion? Thanks
Great question.
Indeed, this could be a bit counter-intuitive, since - as you pointed out - the routing is on the backend layers, while the standard cells are on the frontend layers (optimally, entirely M1 and below). However, the main cause of congestion in logic areas* is what we call "pin density", which is the number of connection pins per unit area.
(* The reason I say "logic areas" is because many congestions are caused due to lack of routing resources due to macros that block backend layers)
When there is high pin density, the router needs to go down to M1 at many places in a small area and route each of these connections to other standard cells or macro pins. This causes a lot of congestion on the lower layers that have to be traversed through in order to make these connections. Therefore, by padding the cells, the pin density is reduced (the effective standard cell area grows, while the number of pins is unchanged), ultimately alleviating the congestion in the logic areas. Note that this does not help congestion around macros, which is caused by high pin density on the macros and a bad floorplan (or tough area constraint).
Thank you so much for this wonderful playlist. I had a question, in the summary section we see defination of global nets, would this still be required if we have p/g tracks? Idea being if we can get vdd/vss from the p/g mesh I assume we wouldn't require the global nets. I would really appreciate a clarification.
Yes, we still need the global nets (at least in Innovus).
The global net is basically a toplevel naming convention for the p/g net. It's not a physical thing, but it's used by the tool to connect the p/g pins of different cells.
For example, lets say you have a standard cell library with the p/g pins called "VCC" and "GND" and a memory with pins called "MVDD" and "MVSS". But VCC=MVDD and GND=MVSS. To make this connectivity at the toplevel (the hierarchy above), we first create global nets (e.g., "Global_VDD" and "Global_VSS") and then connect VCC-->Global_VDD, MVDD-->Global_VDD, GND-->Global_VSS, MVSS-->Global_VSS.
Awesome....👌
Can you please explain the point at 35:05, poly has to be in the same direction, that we need to take care for macro rotation?
In newer process technologies - from around 65nm and below - there are hard restrictions on the orientation of transistors. So you can't just draw your poly any which way. The transistors usually have to be in the same direction. In this case, a hard macro can usually be flipped on one axis, but not rotated 90 degrees (which would make its poly's in the wrong direction).
The link to slides is not working. Could you please share the link again.
Thank you
Hi.
Actually, I have moved my content to the EnICS Labs website, and I didn't update the description in this video. Thank you for pointing this out - I have now updated it.
Notice that a few years ago, I edited the series and uploaded it in shorter 10-20 minute clips, also with Kahoot quizzes for recitation and a few newer videos. Therefore, I suggest you use the playlist at ua-cam.com/play/PLZU5hLL_713x0_AV_rVbay0pWmED7992G.html
You can find the links and slides to all my content at: enicslabs.com/academic-courses/
@@AdiTeman thank you for link. I really appreciate it!!
@@pramodhjinnagarasrinivasai2183 My pleasure
Hello Dr. Teman. I have a Quick question. What software do you use to make your slides. is this done in Latex.
No. I use PowerPoint.
I use Latex for writing academic papers and even though I used to be a big MSWord pro, I am now a big Latex fan and go crazy when colleagues and students use Word. But for slides, I find that PowerPoint is just so much more efficient and easy to use. I've never been a beamer fan (and in fact, I actually don't like what most Latex slides come out looking like...)
Thank you very much for such a good explanation.
What is this, refine the synthesis in local congestion topic? At 24:01.
It is quite an abstract recommendation, but it just means, go back to synthesis (or even RTL) and try to change things so you won't have this problem. I can't tell you "how" to do this, since it is really a per-case situation and doesn't always (...usually) have a solution, but in some cases, if you would have changed something in synthesis, you wouldn't run into a specific problem.
One of the example for this is scan chain re-ordering which is done internally by place_opt_design. Please have a look at that concept of you have time.
Why put blockage in feed through concept at 42:59?
The point is that you are implementing a macro as part of a hierarchical flow. So the top level wants to route a signal through this area that is being implemented standalone - independent of the toplevel. Without blockage, the area required for the feedthrough would be used for other nets.
You can either apply blockage to make sure it won't be routed through.
Or you can implement the feedthrough route at the macro level instead of the toplevel.
@31:05 we anyways have different layer for routing so what is stopping us from placing std cells in keepout region
Hi Himanshu, good question. Indeed, the halos or placement blockages are recommendations, not something that is necessarily a must. The main reason is pin access and overall routing near the macro. So for the pins, let's say you have a high pin density on a certain side of the macro and you need to connect many wires to these pins in a small area. You want to free up as many routing resources as possible in this area. However, standard cells require connections and routing on lower layers and therefore they can use up those routing tracks that would be needed to connect to the macros. Another general reason is that usually there are routing blockages on the macro itself, which means that there are fewer routing resources for the higher level to use. Therefore, we want to free up the areas close to the macro so that any required routes will not be disturbed by routing to standard cells in that area. The corners are the worst area in that sense, which is why we add additional placement blockages at the corners.
@@AdiTeman 2nd reason that you have mentioned is similar to what you have explained in the video between 27 to 28 min?
Thanks .One doubt- Gate level netlist of one RTL design(module) is divided into different blocks?or One RTL design is divided into different blocks before synthesis?
I'm not exactly sure I understood your question, but here is my try to answer. RTL is usually divided into many modules. The higher modules instantiate the lower modules in a hierarchical fashion. This is mainly to simplify the design ("divide and conquer") and to enable design reuse. For this reason, in the lecture on Verilog for Synthesis (earlier in this series), I point out that good practice is to put each module in a separate file called .v
You would then read all of these files into the synthesis tool (or simulation tool, for that matter). During elaboration and synthesis, the tool will ungroup the majority of the modules to optimize the logic between them. This means that the hierarchy is lost and their is no more division between modules. Some of the hierarchy will be kept, but unless explicitly defined to not ungroup a certain module, the synthesizer can "do as it pleases". So the gate level netlist will have some degree of hierarchy, but it is generally quite flat.
@@AdiTeman Hi sir, is it true that ungrouping removes (or collapses) the level of hierarchy of the identified subdesign and merges the subdesign with the surrounding logic ? Or can you please explain ungrouping in details?
Hi Akash, sorry for not responding. I didn't see your question.
Yes, in general, ungrouping removes the hierarchical barriers between the modules. This enables cross hierarchical boundary optimization. Just as a simple example, lets say that a signal is inverted to be driven into an instantiation and then is inverted again at the input to this instance, by ungrouping, the two inverters can be removed. The drawback, of course, is that it makes it harder to debug. But the common approach is to ungroup almost everything that is not placed and routed independently.
These videos are extremely helpful, thank you so much! Do you mind checking the links to your ppts? They don't seem to work. Thanks!
Thanks for pointing this out. I have checked the link to this lecture (on my faculty website: www.eng.biu.ac.il/temanad/digital-vlsi-design/) and it seems to be fine. Can you tell me which one/s didn't seem to work?
Awsome
Thanks