May 04, 2009
Lynx, For Engineers by Engineers
Please note that contributed articles, blog entries, and comments posted on EDACafe.com are the views and opinion of the author and do not necessarily represent the views and opinions of the management and staff of Internet Business Systems and its subsidiary web-sites.
As I mentioned earlier low power is the number one design issue. Over 60% of our survey responders say that this is their biggest challenge when implementing their designs. Different techniques exist to handle this issue. Multi-voltage where you have one block at a different voltage from the rest. That is pretty straightforward and pretty mainstream these days. The next most complicated methodology is MTCMOS where you are basically shutting down a section of the block and then powering it up when it is needed. This is much more complex. It is starting to edge into mainstream but it is pretty early adopter right now. It also causes a lot of problems in your flow. If you power down your logic and bring it up again, you obviously do not know that state of the logic. That can cause all sorts of potential problems with floating inputs for other things. So you have to take care of that, to see that stuff doesn’t happen. The third one is multi-voltage with power gating, basically a combination of the first two. Most of the leading edge guys are starting to do this. So not only do you have to deal with different voltages, you have to deal with portions of blocks powering down. The last one and only a handful are doing this right now is dynamic voltage frequency scaling where you are ding all the things from the first three plus you are dynamically raising and lowering the
frequency of the chip as the compute demands on it change.
Tell us more about the Runtime Manger.
The Runtime Manager has essentially three purposes. Its job is to automate the setup and configuration of the flow, to launch and monitor the execution of the flow and lastly to enable very efficient debug of the flow.
One of the things we do in Lynx is that we know what technology the customer is going to use and we provide them Foundry-Ready tips. But because we know that, we can set intelligent defaults for a lot of the different variables in the flow that are technology specific as well as recommend the most optimum for any given tool because our toolset has many different switches. Getting the best results is really leveraging the expertise of Synopsys on all these tools and methodologies. We call this intelligent guided setup. I look at it like when you download a piece of software for your PC, unzip it and then start the wizard. It gives you the ability to pick intelligent defaults and also
override them at the same time. Basically what this section of the Runtime Manager is doing is helping you setup all the many variables in the flow and get them right.
We also have a drag-and-drop flow configuration. Consider a very small piece of the flow that is dealing with say place & route. There might be some reasons you want to change the flow, for example to do a quick and dirty evaluation of the design area and power. You do not want to take it all the way through detailed place & route, finishing and stuff. Literally, what you can do is select the arrow on a graphical depiction of the section in question connecting from the ICC route to ICC route optimization and delete it. The flow will be automatically reconfigured. Consider what the alternative is: going into the script, looking at all the variables, and changing them manually; going into
the flow, changing the make files, if you use that and then changing which script gets executed. There is a lot of manual stuff going on during the setup and configuration of the flow that Lynx does in a totally automated way.
What about the Foundry-Ready System?
The Foundry-Ready System has two components. The first component qualifies the inputs to the design. This accelerates and make sure the inputs going into the flow are very, very clean. One of the things we do is pretest a number of different nodes. For example, to date we have pretested TSMC 65nm and TSMC library. Shortly, within a few weeks we are going to pretest TSMC 4DLP and 4DLG nodes of ARM and TSMC libraries. Then we are going to go onto to other people’s common platform, maybe UMC, maybe SMIC, whatever on our long term roadmap. For each of these kinds of process and library combinations, we will pretest them and have individual foundries give figures for them. In addition, since IP comes from many, many different sources, obviously we can not pretest all of it because there are too many variables. We also give some utilities that allow the user to pretest it, for example, a hard IP utility checker. That takes the IP from any source and runs it through some checks to make sure that it is clean. For example, it will tell you what views are missing. That’s the input section of the Foundry-Ready System. We test a number of different nodes and give you utilities so that you can run it yourself. Let’s say that you change the foundry or that the foundry updates their libraries or tech files, you have set of scripts where you can requalify and rebuild all the
files you need to run. I can tell you from my own experience running the turnkey group, this was something I would call drudgery work. It is something that designers do not like to do and which doesn’t add any value because normally you get all these inputs, you run them through the flow, and it crashes. Then you have to go in, debug and figure out was it a design issue, a tool issue, an environmental issue, a script issue, an IP issue and so forth. You just waste a huge amount of time. Based upon our experiences doing turnkey design, this will save anywhere between 3 and 4 weeks of effort as well as removing work that is non-value add.
The second half of the Foundry-Ready System has a goal to accelerate project tapeout, to make sure that your tapeouts are very, very clean. For example, we have around 60 different checks that are built into the tapeout section. These are process specific tips; checks like metal fill, DRC/LVS requirements, the number of double vias versus single vias and all that kind of stuff. There are also guidelines to make sure that your chips are functionally correct. Things like the timing of your chip, have you tested the right corners, have you set your on-chip variation (OCV) correctly to give yourself a margin as the process varies over the die. There are other different checks that we have
built in. There are about 60 of them. Some of them are fully automated, some are partially automated and some are basically printing out a to-do list and letting you know to check off this and that to make sure the design is manufacturable.
We have been working on this for several years. In this particular incarnation of the product, we have over 40 staff years of development in all the different aspects of Lynx. We run regressions, about 200,000 a week. Every time we check in a new script or a modification of the code, we run a full regression suite against multiple different designs, multiple different steps in the flow, ,,, We drink our own bathwater too. We are using a variant of this flow for 6 or 7 years now. We have taped out internally as well as with customers that have used the system in the past. We have taped out something like 100 different designs. It is an extensive and proven design flow.
Any customers using Lynx?
We have seven different customers going our beta test. We have been in beta test since last October, a six month beta cycle. Some of the ones that are public are Oticon and Wipro who have said it is a good system that has helped reduce their efforts in getting their flows up and running very quickly.
Who are the target customers for Lynx?
Lynx target customers fit into one or two different categories. The first category is a customer that is in transition. This might be a customer that is moving to a new node. For example, we have one customer we expect top sign this quarter that is moving from 65nm to 45nm. They are telling us that have spent more than $750K developing a flow at 65nm and do not want to repeat that at 45nm. We are talking to them very actively about using Lynx instead, which is a fraction of the $750K. There are people who are in transition from nodes. Sometimes they may be consolidating on Synopsys as their EDA vendor and are using this as the starting point for their RTL-to-GDSII
subflow. Maybe they are transitioning from ASCI to COT. Maybe, it is an IDM moving from their internal fab to an external fab. All of those types of transitions create an opportunity for our customers to effectively do a make versus buy decision and determine if this is the most effective use of their resources or not.
You can find the full EDACafe event calendar here.
To read more news, click here.
-- Jack Horgan, EDACafe.com Contributing Editor.
Be the first to review this article