For years as a designer, levels of logic analysis was a staple in the ASIC flows I worked on. Especially the last company (before I joined Cadence), the ASIC vendor we worked with forced us to abide by their Levels of Logic analysis metric before moving onto the next milestone. It seemed to work, to help identify a good number of paths that would give us bigger headaches in the backend if we didn't address them early on.
Our ASIC Vendor said: " No Levels of Logic 'PASS', no check mark." As simple as that.
How about today?
One question that's been bouncing around in my mind lately is: "Levels of Logic", is that a thing of the past? Does it matter any more? Does anyone care and measure it today?
I honestly thought it was dead, until a few customers contacted me recently.
Customer 1: A few months ago, a designer from a big company said that they were looking into it as a metric to help drive RTL designers. This request was coming from a group that believed that they needed to be more proactive in giving feedback to the RTL designers., and this was one solution.
Customer 2: Today, another customer from another large company was saying something similar. "I don't want to only see my timing challenged paths, they aren't typically the only ones I need to worry about, I want to see the longest paths too. Why? Because those are the ones that historically have given me timing closure issues."
So, if you have an opinion, please post a short one to share. :)
(of course this doesn't describe what method would be used to generate the Levels of Logic report, but that's another topic for later ...)
Hi cmoney and Valeriy, sorry for the delayed reply. For cmoney's comment, aside from pen and paper work, would it benefit your company if there was a tool that could automate what you are currently doing (if possible, and not highly customized where your process of doing this changes drastically with every design/environment change)? If so, I'd be interested to hear about it, on this blog or you can email me separately. I'm always looking for ways to increase user productivity, this seems to be a current one from companies I'm working with who are finding ways to stay on schedule. Pen and paper can be good, but sometimes, it may not scale well, be resource intensive, as well as other potential gotchas. For Valeriy's comment, I agree, it would be nice to have some correlation data between logic levels, timing delays and net lengths (or maybe have a tool to do this with preliminary project data, abstract this quickly instead of in embedded reports, maybe there is ... , so you can make better decisions based on your design and environment for your project). One of my managers who runs the synthesis team, Jeff, who had previously done a lot of work in just the LoL gave some sound advice that due to a number of factors, this quickly becomes a very complex problem to solve. (i.e. even with a generic sound solution, it may not fit every design situation, for example, the advent of even more geometry shrinks where net lengths may become more dominant) Back to your point, adding to LoL, timing and net would better complete the picture, although this would be later in the process, maybe even post RTL freeze which might not be the initial intent of using the LoL strategy. Personally, I know the previous large vendor I worked with (before joining Cadence) was adamant about LoL, and intially it was a pain. But looking back, it worked for us, and I don't regret that conscious effort that did take some initial schedule hits but made closing in the backend more predictable. Since I consistently still see today that P&R tools in general are not always perfect (one-pass flow is still a wishful concept to me, I sure hope no EDA company is promoting that ...), overall I believe that this discussion is useful, keep us thing - what can we do better. (instead of accepting what EDA vendors give, and manually hacking to create non-scalable and non-repeatable solutions) Thanks again for both of your comments.
Someone should make a research on correlation between logic levels, timing delays and net lengths in a few real designs. I guess that delays are quite correlated with lengths, but what about levels and lengths? Maybe nowaday tools are so perfect in optimal placing and routing that many levels of logic don't mean lengthy nets and vice versa?
I'm a front end logic designer for chipsets, a multi-billion dollar business, and we do this, to some degree. We have no official report or official rules given to us by the back end team, but rather we do a lot of pen and paper work to figure out logic levels on paths that may be close. It's proved useful and fairly accurate over the years.