In a world where FPGA software design is expected to be free (or very cheap, compared to it ASIC counterpart), is there still a market for EDA companies to sell their FPGA solutions? Synplicity stopped growing after it built its success on FPGA synthesis. Is that the fate of EDA for FPGA?

There are several forces at play here: device complexity, software complexity, and know-how.

The complexity of FPGA starts to rival that of ASIC’s. The largest FPGA devices contain 100,000’s of LUTs and registers, 1000’s of DSP components, and are equivalent to 1+ million gate designs. The increasing device size requires faster synthesis and larger capacity. It also strains verification because simulation costs are augmenting accordingly. The days were a designer could complete her FPGA project with a simple write-RTL/synthesize/simulate/fix iterative flow are gone.

FPGA companies differentiate with their devices’ speed, capacity, and power consumption. But beyond the raw hardware features, software to design FPGA has become a key for success. Altera learnt the lesson the hard way 10 years ago when it released software that was not ready: Altera quickly lost its top customers to Xilinx, while it could have become the undisputed #1 FPGA vendor. Some FPGA startups in the past could not get off the ground because they fail to deliver good synthesis for their device. Closer to us, we have heard about Tabula’s chronic problems to bring up its synthesis before it finally announced its device earlier this year. And Abound Logic’s huge netlist has stretched the capacity of today’s FPGA synthesis.

Altera has now a software powerhouse, and is meticulous about its software design and testing. Xilinx is currently going through a major overhaul of its software to catch up with its main competitor. There is no question that software is taken very seriously by the two vendors –they both have a couple hundreds engineers dedicated to provide customers with a full design tool suite.

So does EDA has any future in FPGA synthesis? There will always be FPGA startups looking for an OEM with Synopsys and Mentor, but this is not enough. The EDA industry must showcase a comprehensive FPGA development environment that will cover design, synthesis, and verification:

• Verification is becoming ever more costly for FPGAs, as it already is for ASICs. Formal verification for FPGA is still embryonic –FPGA synthesis uses retiming and FSM re-encoding that makes formal verification quite difficult.
• Synthesis of complex systems with a large IP spectrum is an area of expertise that EDA must leverage. Also EDA could provide a much-needed improvement in power management.
• As for design, EDA must seize on the FPGA community’s ability to adopt new methodologies much faster than the ASIC community. ESL, SystemC, and C/C++ as hardware description languages are the right direction.

If EDA wants to compete with the few hundred software engineers of Xilinx and Altera, it needs to deliver a best-in-class and innovative FPGA design environment. Else it will end up as a no-growth by-product of ASIC synthesis.

Related posts:

1. Why FPGA startups keep failing
2. The formal verification market is still untapped
3. Who should worry about Xilinx and Oasys partnership?

My claim is that formal verification has reached a plateau from both the core technology and business point of view.

Yet that does not mean there is no progress! There is a world between creating a brand new technology and using it for an actual working product. This is what the Jasper, Real Intent, Atrenta, OneSpin, and many others are doing, as they creatively use these core technologies to propose new applications.

From the technological point of view, we have experienced steady improvements in many aspects –equivalence checking (EC), sequential verification, abstraction and refinement, etc. The scope of application of formal verification techniques has dramatically increased for the past few years. It has of course benefited from more powerful hardware –faster CPU, larger memory, multi-threading, distributed systems, FPGA. It also benefited from the skilled engineering of the core technologies, to the credit of the many private companies in the field.

But there is no recent verification tool that has been enabled by any new core technology. Nothing wrong with this, it is partially the consequence of a mature industry, where most of the effort goes into improving the customer experience and helping him integrating verification and design/synthesis flow.

When Randy Bryant published his BDD paper in 1986, he revolutionized the field of formal verification with a technology that could address problems previously out of reach. When EC switched from BDD to SAT solvers nearly 10 years ago, it made possible verifying multi-million gate designs against their RTL description. Bounded model checking became a practical approach to sequential property verification. These were disruptive technologies. Where is the next leap?

From the business point of view, force is to admit that the formal verification market has been pretty stable. Most of the ever-increasing design cost is taken by verification, but that does not translate into a fast growing formal verification market. Instead, the more and more daunting verification task benefits simulators more than formal tools. Yes, customers are slow to move to a different verification flow. Yes, the formal verification industry, as the rest of EDA, struggles to find a business model that would bring back a much needed growth. But which application or technology will bring enough value to make the ratio simulation/formal in favor of the later?

Regarding the simulation vs. formal debate, I would recommend reading Chris Wilson’s comment. He agrees with me that formal verification has had a relatively low return on investment. He then argues that simulators will remain the main verification solution, with formal verification technologies under the hood to speed up simulation, to increase coverage, and to help debugging. He may well have a point here.

One aspect that everybody agrees on is that debugging is still a bottleneck in the verification industry. Why does a design fail its functional requirement? Having a counter example (e.g., a sequence of inputs that disproves a safety property) is often not sufficient: the complexity and length of the counter example can make pinpointing the design error very difficult. A failing liveness property cannot be revealed with a finite sequence of inputs. Similarly, there is no tool that provides consistent debugging information explaining why a statement of a RTL description is unreachable. Formal verification techniques can certainly help here, and there are a few available products aiming at the problem.

In conclusion, formal verification as an industry has matured, but is still looking for the market share it deserves. I think there are a lot of opportunities to grow the market. Success may come as an enabler of a better, faster, high coverage, simulation. I rather believe it will come when formal verification allows software and hardware to be verified and debugged in a common, continuous, design flow. And this requires some major technical innovation.

Related posts:

1. Has formal verification technology stalled?
2. The formal verification market is still untapped

There is certainly no lack of competition in formal verification. The big three EDA public companies, Synopsys, Cadence, and Mentor Graphics, have all their own formal verification offering (Formality, Conformal, 0-in), and there are a number of startups, e.g., Jasper, Atrenta, Real Intent, OneSpin, Blue Pearl Software, to name a few. Formal verification products cover a wide range of applications: System Verilog Assertion (SVA) and property checking; RTL static check; equivalence checking (EC); some limited IP verification; clock-domain crossing (CDC) verification; and timing exception verification (false paths and multi-cycle paths).

Looking at the DAC submissions this year though, I am puzzled by the overwhelming number of papers focused on increasing simulation speed and coverage, as opposed to the handful of papers discussing formal techniques. And this year is not different from last year. And the year before last. Does that mean there is a lack of innovation in formal verification core techniques?

Improving simulation –higher coverage, less patterns, more automation— with formal techniques is a very active field, both in the academic and industrial world. Some inject faults in the RTL to separate the most discriminating patterns (e.g., Certess). Others use SAT and integer constraint solvers to reduce the number of patterns, or to automatically generate patterns for hard-to-cover code branches (e.g., NuSym). But success is all relative. Certess was quickly acquired last year, while NuSym is actively looking for a buyer. There are also semi-formal tools, mixing simulation and state exploration techniques (e.g., Magellan), but they a have limited usage.

What about the more fundamental formal verification technologies? The 80’s were dominated by the development of rigorous semantics models (e.g., multi-valued logic, Verilog and VHDL operational semantics for synthesis and simulation, temporal logics, and synchronous languages like Esterel and Lustre) and the introduction of BDDs. The 90’s saw EC tools spreading in the industry and the rise of model checking. The 00’s were all about SAT and model abstraction to push the capacity of EC and bring property checking to the end-user, as well as static code analysis, CDC, and timing verification. What are we going to see in this decade?

Verification has a lot of challenging problems, with incomplete or no solution at all. Here is my list:

• Merged arithmetic. There are robust methods to verify adders and multipliers of practically any size, but no one can verify merged arithmetics as small as 32-bits.
• Low power. This leads to complex properties capturing the correctness of sequential clock gating and power gating. The former is becoming more common, and there are techniques to address most of it (e.g., Calypto and Conformal). But the later is still waiting for a comprehensive and automated solution.
• RTL debugging. There are a number of static code checkers, but debugging is still very poor.
• HW/SW verification. Can we leverage deductive methods (predicate logic, HOL, rewriting system) to close the gap between software and RTL?
• Mixed signal (analog/digital) devices: this is a very young area of research, but it should see a lot of focus given the increasing ubiquity of mixed signal designs.

If formal verification core technology is to evolve, we will see some original solutions to the problems listed above. What do you think should be added to this list? And which techniques will evolve as the most promising?

Related posts:

1. The formal verification market is still untapped
2. Formal verification stalling, take two
3. Automated low-power design flow is up for grabs (Part I)

Paul rightly emphasized three trends. The first one is well know: the continuously rising cost of IC designs, about $50M for today’s 45nm node. The second trend is that the fastest growing part of the design cost is software –more than half of the overall cost, Paul even claiming close to 2/3 of the overall cost. The third trend is an increasingly fragmented consumer market: the number of end products goes into the 10’s of billions, but these products are declined in many more different kinds, which means that most of them are shipping in smaller individual volumes.

Source: Morgan Stanley, Economy + Internet Trends, Web 2.0 Summit, San Francisco, Oct 2009.

This is bad news for EDA as we know it: the rising cost of design can no longer be justified if the number of units does not grow fast enough (a $50M chip starts to make sense only if it is produced for 250M units and more). Also EDA has been slow to climb up the food chain and proposes solutions for software design, which dominates the overall chip design cost.

Rising IC design cost and smaller number of units is the call for FPGA to growth even faster. Mobile applications require FPGA to do much better in terms of power consumption, but this is a hot topic (no pun intended) drawing a lot of attention and investment, and some competitive solution will emerge in the next few years. So EDA, which makes its bread and butter on IC design, should better re-align its growth strategy on software, embedded systems, HW/SW co-design, and verification. Else EDA will continue to shrink to only service the few that can still afford chip design.

The end product, as a SoC, is a puzzle where the designer mostly assembles existing cores and IPs, and decides of the tradeoff between the software and hardware parts, based on flexibility and cost factors.

I see two strong needs that EDA could build its growth on. One is functional validation of the whole system –software plus hardware. EDA has started to address the issue, even though it is still short of proposing a scalable and automated environment. To functional validation, I would also add functional flexibility: how much of the behavior can be upgraded thanks to the software part? The other need is a design navigator that would estimate the speed, area, power consumption, and cost of a SoC by exploring alternatives between cores (ARM, MIPS, etc), IPs, FPGA, and software.

Last but not least, the eternal question of an EDA serving a $250B semiconductor industry, but making less than $5B. The time-based license model has only served the interests of the semiconductor companies, to the expenses of R&D investment in EDA. Claiming a lack of innovation in the EDA industry is sometimes fair, but EDA should also innovate in business solutions instead of cannibalizing itself by cutting costs to only survive another quarter. The semiconductor industry needs a healthy EDA if it wants to address the system-level design challenges of the next 10 years. Unless, of course, a new player coming from the software world with the experience of scalable systems signs the death of the EDA industry as we know it.

Related posts:

1. The formal verification market is still untapped
2. Why service companies will eat up EDA
3. Is FPGA a sustainable market for EDA?

Getting actual figures about the size of the functional verification market proves to be elusive because of the way the products are tied to synthesis license deals, and because of the lack of independent analysts in EDA. Still, the simulation and emulation market of digital systems can be estimated to be at least five times larger than today’s formal verification market. But simulation can only take you so far, so one wonders why formal verification does not have a larger share. Is it because the technology is limited, or because the market is not ready?

Equivalence checking

Equivalence checking (EC) consists of verifying that a netlist implements the behavior specified by a RTL description, or that two netlists are equivalent. Historically, EC is the first industrial formal verification tool brought to the ASIC world. Cadence’s Conformal is still the reference (about 60% of the market), with Synopsys’ Formality coming second.

EC’s technology is very mature, but this does not mean no further progress is necessary. Flip-flop matching, the primarily step that consists of determining the pairs of flip-flops that need to be compared, is expected to be done quickly and automatically, with no manual guidance. Datapath verification remains a major challenge, and proving the correctness of merged arithmetic automatically is still an open problem. Last but not least, debugging is a very complicated task. Incremental verification and rectification techniques can be quite useful to help pinpointing the functional issue.

Model checking and property verification

Model checking and property verification are still a fraction of the formal verification market, with many players on the field. There are two obstacles for a larger usage of the approach. The first one is that it can be complicated to write a FSM or property that captures a particular behavior. SVA (System Verilog Assertions), OVL (Open Verification Library), and PSL (Property Specification Language) help in that regard, but they need to be more systematically used in the design community. The second obstacle is that model checking techniques can only solve relatively small problem instances. This is why some go with hybrid verification techniques (read: may be incomplete), like Magellan or 0-in, while other stick with complete formal methods, like Jasper and OneSpin.

Because writing properties can be so complicated, specialized branches grew to address specific needs, as shown below.

• IP verification. With SoCs using IPs from many different sources, verifying the compliance of these IPs with respect to standard interfaces (e.g., PCI or USB) in the context of the application is crucial.  Conformal, with its verification IP portfolio, is in a good position to address the problem. Also OneSpin is known to have interesting technology in that space, even though they are not pushing it at the moment.
• Timing verification. Incorrect timing constraints can lead to missing a target clock cycle, or worse, to a chip failure. Verifying timing exceptions (false paths and multi-cycle paths), as well as CDC (Clock-Domain Crossing), has become a center of attention. It is still unclear how big the market is. However several discussions with IC design companies led me to believe that verifying a set of timing exceptions (usually in the order of 10,000 SDC constraints) save one month work of an engineer. Automation and speed are keys here. Atrenta, Real Intent, and 0-in propose interesting solutions in that space.
• Power verification. When doing power gating, one needs to verify that the application is powered back up properly. Integration with UPF or CPF provides the required automation. Conformal and CPF have an edge in that field.
• Sequential clock gating verification. Traditional (combinatorial) clock gating is well supported by EC tools. Sequential clock gating exploits sequential dependencies to derive additional gating conditions, which can be used to save more dynamic power. It has been made popular by Calypto –Envis is also proposing a similar technique at the netlist level. Sequential clock gating correctness cannot be expressed easily with SVA or OVL without making the verification task extremely complex, which explained why specialized verification techniques have been developed.

Where formal verification will grow

Formal verification is no longer limited to ASICs: complex systems –SoC, FPGA, and HW/SW co-design— will benefit dramatically from better formal verification techniques if they are deployed adequately.

With the ever-growing size of FPGAs (Altera’s Stratix IV packs 820k logic elements, and Xilinx’ Virtex-6 has up to 750k logic cells), it is clear that simulation will no longer be sufficient to validate the correctness of programmable logic devices. The need for FPGA EC is real, and this requires complete automation and full support for retiming –OneSpin’s 360 EC FPGA has shown some competitive solution in that space. Also note that IP verification and timing verification apply to the FPGA designs too. The real question is whether FPGA designers are willing to pay for formal verification tools.

IP verification, and verifying the correctness of a SoC using IPs, is certainly a very strong driver for more sophisticated formal verification solutions. Power verification will become part of the ASIC design flow, as EC is part of the synthesis flow. Timing verification is still looking for its footing in the design flow –one question is the debug environment, which is still relatively limited, e.g., to showing waveforms.

Looking forward, formal verification techniques can be used (and have been used) in other fields than circuit design. Any critical digital system can benefit from formal verification techniques –transportation, medical equipments, security and privacy applications. The automotive industry is one of the most obvious targets. Cars are ubiquitous, they contains more and more electronics (representing about 30% of the end price today), and a functional bug can have very costly consequences. Cars rely on digital systems for anything from optimizing their engine’s efficiency to navigation systems, entertainment, and on-board diagnosis. Soon the intra-vehicle, vehicle-to-vehicle, and vehicle-to-roadside networking will fuel innovative products, driving the needs for fast development and the highest possible level of correctness. The EDA industry is taking notice, and Mentor has certainly taken the lead there. Whether they provide the adequate functional verification framework is another matter.

Formal verification will extend its reach by addressing the hard problems of EC (datapath verification, and retiming for FPGA), by being seamlessly integrated in the synthesis flow (power and timing exception verification), and by providing practical solutions to IP and hybrid HW/SW design verification.

Related posts:

1. Has formal verification technology stalled?
2. Formal verification stalling, take two
3. Automated low-power design flow is up for grabs (Part II)

Defect rate

First I would like to discuss the notion of software reliability and how it evolved over the past 40+ years. A defect causes an invalid behavior of a program with respect to its specification (e.g., incorrect output, performance issue, crash). One of many ways to look at software quality is to estimate its defect rate, i.e., the number of defects per line of code (loc), or more conveniently per 1,000 lines of code (kloc).

The first observation is that the larger the code, the higher its defect rate. It is estimated that the bug rate increases logarithmically with code size.

Source: Program Quality and Programmer Productivity, Capers Jones, IBM 1977

Thus the total number of defects for a specific application can be reduced by the following:

1. Continuous code factorization (direct loc reduction).
2. Use of libraries (which have a reduced bug rate, thanks to the extensive exposure they receive due to their long lifespan and high usage).
3. Increase the expressive power of the programming language (indirect loc reduction).

Since the introduction of FORTRAN in 1957, many languages and operating systems have been created and have grown more powerful and sophisticated. What could be typically coded in 10 klocs of FORTRAN can be coded today with less than 5 klocs of C++, and about 3-4 klocs of Java. Raising the level of abstraction of programming languages helps decreasing the total number of defects because it results in smaller programs with a lower defect rate.

Evidently, testing reduces the defect rate. A software powerhouse like Microsoft reports about 10-20 defects/klocs before QA, and claims that the rate drops to 1/kloc in released code. Looking at long lifespan and very critical code, statistic from the Jet Propulsion Laboratory shows that spacecraft software (which is typically only 20 klocs, and must run without interruption for years) reaches 6-10 defects/klocs after 2-5 years of testing. The code developed for the shuttle program is estimated to have less than 0.1 defect/klocs.

Source: Nikora, Allen P., “Error Discovery Rate by Severity Category and Time to Repair Software Failures for Three JPL Flight Projects”, Software Product Assurance Section, Jet Propulsion Laboratory, November 5, 1991″

Over the past 40 years, independent researches from academia and the private sector have shown that on average an application has a defect rate of 5.5/klocs, regardless of the programming language and the operating system used for development. This looks counterintuitive, since increasing the abstraction level of the programming language reduces the bug rate and the actual size of one specific application. But that progress is neutralized by the ever-increasing size and complexity of the programs, made possible by better software development methodologies and powerful development environments. To put a defect rate of 5.5/kloc in perspective, consider your typical EDA place-and-route product, say 3Mlocs of C/C++, with a likely high turnover rate (i.e., percentage of locs that are modified in every release). You can expect in the order of 16,000 defects…

Test-Driven Design

Now I will present a method that I successfully used for both existing and from-scratch products. It is based on the observation that independently from the quality of the team and the advancement of the tool, the software complexity and the unpredictable evolution of the product makes managing the software quality quite problematic. Think EDA, where customers ask for new capabilities every week and salespeople sell features 6 or 12 months before they are actually developed. It is difficult, if not impossible, to have an upfront, clean, and frozen specification, from which an architecture and a set of APIs can be derived. One needs to change the architecture and the APIs because of new unpredicted features and unforeseen problems, or simply because the software is written in a hurry without the adequate resources –I have no doubt that most readers will agree on that last point. This creates bloated code with a high defect rate, which result in application with a larger number of bugs.

Test-driven design flips the traditional software development scheme upside-down. In most cases, the software development flow consist of (1) specify the requirements in some language (e.g., English, ML, C++ or Java header files), and (2) iterate a code/test loop until the software reaches a point where it is deemed stable enough to go through a full QA regression release process. This often leads to slow iterations between the release team and the R&D team before the release is fully qualified. Also the essence of the original specification may be lost because there is no concrete way (read: operational semantics) to check whether the released product actually meets its intended requirements.

Traditional vs. test-driven software development flow

Contrast this with a test-driven design approach. In that methodology, the tests are written before anything else. The goal is to capture the specification with a set of small (positive and negative) unit tests. Then some code is written and run on the unit tests. Some of the tests fail, which lead to further refinement of both the unit tests and the code. This iteration write-test/code/test converges until one cannot design a new test that would break the code. The next step, QA regression release process, can then be carried on.

A few things are important to recognize in a test-driven software development methodology: (1) the spec is the set of unit tests; (2) therefore the release can be validated as meeting the spec; (3) the testing iteration handled by R&D is closed when the unit tests and the code are fully stable, which leads to fewer iterations between the release and R&D teams; and (4) this methodology does not assume anything about the intrinsic quality of the code and the strength of the development team. Indeed this approach can be used on very badly architected code and still lead to substantial improvements.  Also note that the unit tests can be internal, e.g., written in C++ and providing a self-testing mechanism, or more traditional with external data that are fed to the application.

Case studies

Let me give a few concrete examples. A tool I was in charge of contained some legacy code that performed an essential task in EDA: constant propagation (it consists of propagating logic values through a logic network, following basic computation rules, e.g., NOT(0) = 1, AND(0, 1) = 0, and AND(1, 1) = 1). The computational principles are simple, but a good constant propagation system should be lazy, incremental, support undo, may explain to the user why some constant occurs in some part of the network, etc.  This makes the development of the system much more challenging.

The legacy code produced crashes now and then. It was difficult to read, it contained suspicious piece of code to handle corner cases (e.g., multi-driver nets, user-set constants), and it had a poor testing coverage (<50%). I decided to go for a full rewrite with a clean API, and unit tests were developed together with the new code following a TDD methodology. This resulted in 6267 loc of C++, 40% of which being unit tests (click the screenshot of the C++ unit tests below), made of 1415 asserts. That code was release in May 2007, got 3 reported defects until November 2007, and has been without defect since then.

Another example is a C++ template’ized bitwise four-valued simulator, written to match the Verilog semantics. This was done with 8014 loc of C++, including 40% of unit tests, made of 1015 asserts (click the screenshot below: you can recognize the basic four-valued logic truth tables).  The template was self-tested with three different concrete instances of logic representation (on 2-tuples of bool, on strings made of 32 or 64 characters ’0′, ’1′, ‘x’, and ‘z’, and finally on an actual logic netlist).  No defect was ever found on the semantics.

In both these cases, I had the opportunity of rewriting or starting from scratch. What if one has to improve on an existing system too large to be rewritten?

The third example is about a complex feature (sequential clock gating) that at the time had been released 6 months before. The field complained about inconsistencies and erratic behavior, so I decided to apply a TDD methodology to rectify the code. First hurdle, we established a unit test campaign, which consists of describing the spec in terms of unit tests in plain English and sketches. This produced 49 unit tests, as shown below (click to enlarge).

Second hurdle, we proceeded to translate these informal unit test descriptions into elementary RTL descriptions. The idea was that if the code was compliant to the spec, we could predict exactly which optimized netlist it would produce. Third hurdle, a 3^rd party reviewed these 49 RTL tests, and found that 9 of them were faulty because they did not capture what was specified in the document. Once we fixed these tests came the fourth hurdle: we run the code.

The results were brutal: the code crashed on 3 tests, it synthesized a functionally incorrect netlist in 5 cases, and produced 13 suboptimal results. Overall, 21 failures out of 49 tests, a 43% defect rate! We then went through a 2 weeks iteration of unit test refinement and code fixing with a team that never touched the initial code, to eventually converge on 72 unit tests –many more than we could think of initially– and a usable feature.

Conclusion

Test-driven design (TDD) aims at capturing a spec with unit tests, then have some code successfully running these tests. The unit tests are more important than the code itself –any code that passed the unit tests meets the spec–. TDD initially requires a higher investment: writing unit tests to capture an expected behavior is a complex task, and a 3^rd party review is needed to validate them. But the effort pays off: eventually the set of unit tests becomes the spec, and can even be used as documentation. Running unit tests is fast, so it dramatically reduces the R&D testing time. Also once a code passes a comprehensive set of unit tests, the risk of iterating from QA back to R&D is reduced. Overall, test-driven design increases code correctness and stability dramatically, even in the presence of a deficient architecture and legacy code.

Related posts:

1. API design 101
2. Software outsourcing, a necessary evil
3. The formal verification market is still untapped

I will focus on three items necessary for power gating: (1) the FSM that controls the sleep and wake-up sequences; (2) the retention flops used to restore the state of the device when it is awakened; and (3) the correctness of the power gating implementation. Items (1) and (2) are manually done via UPF/CPF directives and FSM hand-coding. Item (3) is carried out with customer-specific methods, even though the use of CPF together with Conformal produces a more solid verification flow.

Sleep/wake-up protocol synthesis

Items (1) and (2) must really be considered together to answer the following question: how to implement a sleep and wake-up sequences that use retention flip-flops to resume the device’s state? It is clear that answers to that question are different tradeoffs between the number of retention flops and the length of the sequences. The more retention flops, the shorter the sequences are, but the higher the price in terms of area and residual leakage power. In essence, one would like to be able to explore the possible tradeoffs and pick the best compromise, depending on the application. Also from the designer point of view, one should not have to manually decide which flip-flops must be shadowed, nor one should have to hand-code the FSMs for the sleep and wake-up sequences.

Instead, one should be able to synthesize the retention flip-flops and the sleep and wake-up FSMs directly from a power state table –what I call sleep/wake-up protocol synthesis. I would propose an extension of the power state table so that transitions can also be labeled with constraints: an upper bound on the sequence length (in terms of number of clock cycles or milliseconds), and an upper bound on the area taken by the retention flops (actual area or as a percentage of the element area). This way the designer can concentrate on the power management strategy and explore different tradeoffs, instead of having to figure out the implementation itself.

Sleep/wake-up protocol synthesis is no small task. I would look into information relevance and functional dependency analysis to derive a candidate set of retention flops. Compression and encoding methods can then be used to reduce this set. The final FSM synthesis would implement the decoder. Looking into techniques coming from DFT, simulation, and formal verification could prove very helpful.

Sleep/wake-up protocol verification

Item (3) is verifying the correctness of the power gating implementation. There are two aspects here. One is purely physical, and consists of checking that level shifters, isolation cells, and power switches have been properly inserted. The insertion of these cells can be automated, and verifying that their insertion obey basic physical rules in not a problem (this is supported for both UPF and CPF).

The main issue is to verify the functional correctness of the sleep/wake-up sequences, namely that the device meets some operational expectation once re-activated (e.g., the pre-sleep state is fully restored). Intensive simulation will give some coverage, but cannot be exhaustive in general. Sequential formal verification or property checker can then be used for a proof of correctness. For instance the property would go something like “if the device goes to sleep and then is re-activated, its state is fully restored to its pre-sleep state in less than one second”. To be manageable, such a property must be broken down in smaller or more abstract expressions. The same synthesis system that takes care of items (1) and (2) should generate the properties that a 3^rd party property checker can independently verify to guarantee the correctness of the sleep/wake-up protocol. This is no different than a RTL synthesis tool giving hints to an equivalence checker to simplify the proof.

Conclusion

Given the complexity of today’s sleep/wake-up protocol design and verification, it is somewhat surprising that no EDA tool is really tackling the problem today. Is it because of user unawareness, or because of the size of the challenge? Regardless of the reason, the first company to offer sleep/wake up protocol synthesis and verification will make a major impact in the low power design community.

Related posts:

1. Automated low-power design flow is up for grabs (Part I)
2. Is FPGA a sustainable market for EDA?
3. The formal verification market is still untapped

For mobile products, leakage power (the power consumed when the device is on but idle) has become a dominant factor, as opposed to dynamic power (the power resulting from the actual activity of the device, e.g., during a call for a cell phone). In that context, power gating is a key for extended battery life. Under some condition (e.g., the “on/off” button is pressed, or the device has been unused for some time), the device goes to sleep: it powers down most of its elements and preserves enough information to restore the state it was in before going to sleep. Under another condition (e.g., the “on/off” button is pressed again), the device powers back up and resumes its course as it was right before going to sleep.

UPF (Unified Power Format, endorsed by Synopsys, Mentor, and Magma) has been introduced to describe the power supply distribution and its control. With UPF one can specify power domains (a set of design elements that share a power supply), and a power state table that captures the transitions between the power domains. For instance it is used to describe under which conditions the device goes to sleep, under which conditions it must be powered back up, and what happens whenever the device transitions between these modes. UPF allows the designer to specify retention flops, level shifters, and isolation cells, all necessary items for multiple voltage designs and power gating. CPF, promoted by Cadence, is another format that is used to describe similar power management schemes.

Low power has been a subject of attention from chip designers and EDA for more than 10 years. Indeed, a lot of improvement has been done. New techniques have been introduced, and most are now common practices and relatively well automated –clock gating, multiple Vt cells, multiple voltages.

Despite these progresses, low power-centric design flows remain a very labor intensive process. Even if UPF/CPF can be used to describe transitions between different power modes, it is up to the designer to manually write the controller (as a FSM) that implements the transitions, and it is up to the designer to determine which information must be preserved (the retention flops) in order to resume the application to its pre-sleep state.

Also low-power designs create new challenges for functional verification. For instance, after going to sleep, the device must be able to resume without loss of information. Since the sleep and power-back-up sequences take several clock cycles, simple equivalence checking is not sufficient. Sequential verification or intensive simulation is needed. Cadence did a relatively good job in tying CPF to its Formal Verification solution (Conformal), Mentor and Synopsys have some reasonable flow for UPF, but verifying the correctness of a power state table FSM is still a very manual and error-prone process.

EDA stands for bringing automation to design flows, and low power design could use some help. In Part II, I will show how some parts of the low power design flow can be automated.

Glossary

Sleep mode: the power state a device is in when it is not actively used by the user. In that state most of the device is shut down, but is ready to wake up when the user needs it.

Active mode: the power state a device is when it is fully active (e.g., making a call with a cell phone).

Power domain: a set of design elements that share a power supply. Power domain is also used to denote the power supply itself.

Power state table: a table that describes the transitions between power domains. Transitions are annotated with logical expressions under which they are triggered.

Retention flop: an always-on flop that shadows the state of a flop. It retains its logic state even when the primary power supply to the cell is shut off. It is used to restore the state of a device when it is powered back up.

Level shifter: cell used to allow a signal to pass from one power domain to another.

Isolation Cell: cell used to isolate a device element from its neighbors when it is powered down.

Clock gating: power-saving technique that consists of blocking the clock signal leading to flops so that flops cannot change their state. Since their states are fixed, the downstream logic will not toggle, which saves dynamic power.

Power gating: power-saving technique that consists of shutting down the power supply to a device component, so that its power consumption is zero.

Multiple Vt: multiple voltage threshold cells. A cell speed depends on its voltage threshold. The lower its voltage threshold, the faster the cell is, but the higher its leakage power. High Vt cells are used for non-timing critical parts of the circuit, while low Vt cells are used for critical paths only, so that the overall leakage power is reduced.

Multiple voltages, Voltage islands, MVDD: a component of a circuit can operate under several voltages, or components can have different operational voltage. The higher the voltage, the faster the component is, the higher its leakage and dynamic power.

Dynamic power: the power dissipated by a circuit due to its cells switching from one state to the next. It is proportional to Vdd²tr, where Vdd is the voltage supply of the cell, and tr is its transition rate (or toggle rate) per second.

Leakage power, static power: the power dissipated due to the leakage current passing through transistors. Practically it is the power dissipated when the cell does not toggle. It is proportional to Vdd exp(- Vt / T), where Vdd is the voltage supply of the cell, Vt is its voltage threshold, and T the temperature.

Related posts:

1. Automated low-power design flow is up for grabs (Part II)
2. Can Tabula and Tier Logic be successful?
3. Is FPGA a sustainable market for EDA?