The Many Tentacled Monster Under My House (with Pictures)
Many years ago, my wife and I bought our first home. At that time, a coworker said to me, “Congratulations! You now have a home project to do every weekend for the rest of your life!” How right he was, though his prediction only covered our first 6 years, since we had sold that early house and moved into an apartment in San Francisco.
Fast forwarding to this past summer, our family made the decision to move back to the south bay. We located a nice house near a good elementary school within our budget, and moved in over the Independence Day weekend. Part of the move involved pulling my old woodworking tools out of storage. (Back when we first moved to the City, I’d tried with no success to convince my wife that a table saw sitting in the middle of our living room in our small apartment really wouldn’t be an inconvenience.) For me, setting up the tools once more was like seeing long absent friends. As they took their new places in our garage, my thoughts turned to how to use them to make “improvements” in our new home.
After assessing the state of the house, I eventually settled on wiring the home for networking. As our family’s “Geek-In-Residence”, I’ve long preferred the additional speed and security provided by cabled networking over wireless. Additionally, we were nowhere close to maximizing the speed of our high-bandwidth internet connection, and our wireless network was regularly slowing to a crawl whenever our kids would watch streaming movies to our TV. I’d run network cable before in our old house with good results, but figured this time around, I’d recruit some additional help. I floated the idea of running network cable to my two kids, ages 8 and 6. Both seemed mildly indifferent to the idea, until I explained that this project involved crawling around under the house. Their enthusiasm meter immediately spiked. My wife’s response was more tempered, involving a well-practiced eye roll and head shake, but then signing off on the project with the utterance, “Whatever!” (As good as a signed contract in our house!) I ordered the supplies and made a wiring plan.
There are two keys to any successful home improvement project – good planning and a high spousal approval rating of the finished project. I wanted to run cabling throughout all rooms of the house, and to hide the networking equipment in closets, since I knew my wife would prefer that they would remain unseen. As this plan would require a lot of drilling between walls and possibly under the house, I took the opportunity to upgrade my tool set with a cordless drill. I learned about selecting tools from my father. He was a machinist, and he had a simple philosophy regarding tool purchases – “Buy tools of sufficient quality that your offspring will inherit them from you.” Aside from the initial out-of-pocket expense, I’ve never been disappointed living by this rule. In that spirit, I took one of the potential future recipients with me to pick it out, along with a drill bit suitable to our purpose.
We started by cutting holes in the walls where the eventual Ethernet wall jacks would be found. Once a hole was cleared, I took the new drill and extra-long-bit to make a 1” hole into the floor studs to run the wiring up from the crawl space. The tight nature of the in-wall access necessitated drilling the holes at a slight angle. This shouldn’t have been a problem, except for the one wall which bordered on a room with a 6 inch drop in the floor height. Fortunately, some slight re-planning of the network jack locations and a rapid approval sign-off by management (my wife) resolved the issue with a minimum of incidental profane language training for my kids provided by myself.
Next came the cable runs under the house. The plan was to put the network patch panel in my home office closet and run all connections from there. My wife was already a pro at fishing cables through walls from various home projects in our old house. This project started like any other we have done together; I recommended a technique to her to use to get the cable easily through the height of the wall, and she discovered a substantially improved method within minutes of attempting the first cable run. I left her to manage the above ground work while I prepared for the crawl space cable runs. My son and daughter traded off “assisting” above and below the floor with Mom and Dad throughout the day.
In all honesty, I had expected my kids to have mixed interest under the house. While the concept was cool, the reality might be a bit scary for someone their ages. Perhaps they would pass Dad some tools while he worked, or maybe feed a cable through a hole. Was I wrong! Not only did they like being under the house, they were actually much more effective than their old man in running cable. Because they were physically so much smaller, they could easily crawl on their hands and knees where I could only slide along the ground on my stomach. That means they could run a cable to the far end of the house in about a minute, whereas I might take 2-3 due to the tight space.
After a few practice runs, they were ready to go solo. I would hand them a freshly fished cable from the crew upstairs, and they would grab the end and say, “Where to Dad?” They ran the lines to the pre-drilled holes while I kept the feed coming down into the crawl space from snagging. By the end of the day they each had their own roll of electrical table to tie the end of the cable to a converted coat hanger that would feed the cable back up through the wall to where the Ethernet jacks would be. We made such good progress that I spent much of my time using cable nails to clean up the runs while the kids ran other lines. They thoroughly enjoyed the experience. And let’s face it – how many elementary school students can claim they ran the networking cable that they use in their rooms? They have serious playground cred now!
With our cables run, there was still the business of wiring up the jacks and testing the connections. A tip for parents out there who may consider this project on their own – small children find both punch tools and network testers to be fascinating equipment. This is advantageous in that they are more than willing to run from room to room, crawl under furniture and attach test fixtures to hard-to-reach Ethernet jacks while you sit “working” at the main patch panel with a network signal generator and an ice-cold beverage. The biggest issue you will face is ensuring everyone gets an equal number of jacks to test. (Hint, when planning your home network, ensure the total number of connections you want to run divides evenly by the number of children you have. You’ll be glad you did!) In all, we had less than 3 connections that needed rewiring out of 20 run throughout the house.
So was the whole thing worth it? As far as my own goals for the project, I’d say yes. We’re now getting nearly the top advertised speed from my internet connection across all wired devices. This means my kids can watch Netflix shows and I can be on a company internet meeting without interference. Also, our wireless connections rarely seem crowded now. And with the 8 wired network connections I installed in my home office, I have ports for all of my current devices, with room for more! But honestly, getting to do this project with my wife and kids was a real reward. I discovered, once again, that I married someone not only intelligent and beautiful, but also capable of fishing cable through walls like nobody’s business. In addition, the excitement my kids felt in knowing they were working on a project with Mom and Dad was simply too much to express in words. I am looking forward to our next home improvement adventure.
Jay is a Product Strategist at Real Intent with over 20 years of design and EDA experience. His primary focus for the past decade has been support and marketing of static verification products. He has a MSEE from Stanford and a MBA from San Jose State.
Is Silicon the New Fabric for Our Lives?
| Prakash Narain, Ph.D.|
President, CEO Real Intent, Inc.
The following CEO Insight was published in the October 2015 issue of SiliconIndia.
This year we are celebrating the 50th anniversary of Moore’s Law. On April 19, 1965, Electronics magazine published an article that profoundly impacted the world. It was authored by a Fairchild Semiconductor R&D Director, Gordon Moore, who forecast that transistors would decrease in cost and increase in performance at an exponential rate. The article predicted the availability of personal computers and mobile communications. Moore’s seminal observation became known as ‘Moore’s Law’, a prediction that established the path the semiconductor industry would take for the next 50 years or more and, in doing so would dramatically change our lives. Three years later Gordon Moore co-founded Intel, the number one semiconductor company in the world.
According to the analytics firm IHS, the pace of Moore’s Law has resulted in $3 trillion dollars in added value to the Global Domestic Product (GDP) in the last 20 years. We have seen advances across a wide range of business sectors including transportation, energy, life sciences, environment, communications, entertainment, finance, and manufacturing.
In the communications sector there are 6.8 billion mobile phone subscriptions worldwide, or about one per person. More than half of these, 3.6 billion, are so-called smartphones that enable a social media community of 2 billion users.
The power of Moore’s Law has enabled the creation of semiconductor Systems-on-Chip (SoC) that provide rich feature set, brilliant graphics and wireless connectivity that we have learned to take for granted in our smartphones. We tend to overlook the fact that today’s SoCs include hundreds of millions of digital logic gates.
The creators of these SoCs must use computer automation and off-the-shelf design components to assemble working designs in a reasonable amount of time. The complexity of today’s digital chips exceed people’s capability to design and verify them manually.
We, of course, expect our consumer electronics products to work reliably and exhibit long battery life. For automotive, medical, aeronautical, and military applications, requirements for reliable operation are far more strict. Careful automated analysis is needed to confirm correct behavior of designs.
And what is the cost of failure? Currently, the design and fabrication cost for a new SoC ranges from $35-50 million dollars.
Given the huge complexity and feature requirements for SoCs, design verification must start as early in the design process as possible. The digital design community checks basic functionality at the architectural level and begins to implement behavioral designs through the use of hardware description languages such as SystemVerilog and VHDL. The Hardware Description Language (HDL) stage describes how signals will move between the composite digital components; at this stage designers can begin to code different tests that will confirm correct interoperation of the blocks.
With the relentless march of Moore’s Law, we see that the number of engineers required to verify the behavior of a design exceeds the number of engineers needed to develop the design itself. According to Wally Rhines, Chairman and CEO of Mentor Graphics Corp., if this trend continues, the entire population of India will need to become verification engineers.¹
How Can We Contain this Verification Explosion?
Design teams now rely on new verification software technologies to manage this trend. The key to the new software approach is laser-like focus on specific verification problems, along with the use of so-called static analysis methods.
By constraining the verification challenge to a series of specific problem areas, such as signals crossing block boundaries, only necessary information must be retained and processed for each specific problem. A narrow focus keeps the problem size manageable. The use of static analysis methods fits very well with the narrow focus technique. Analyzing the intent of the design as it relates to that problem brings dramatic speed-ups; validation results are delivered in minutes, not days as happens with traditional simulation methods. Parallelization of the effort across multiple problem domains means verification is not constrained, and a whole suite of applications can be run concurrently.
After the HDL stage, designs go through what is called digital synthesis – one step closer to physical realization with actual logic gates. Other new verification technologies such as hardware emulation further confirm the correct behavior of an SoC before it is fabricated.
Worldwide demand for electronic devices continues to escalate. Recently semiconductor market research firm IC Insights raised its projection for wearable electronics revenues in 2015 to show much stronger growth in wearable systems after the launch of Apple’s first smartwatches in April 2015. The long-term fate of smartwatches continues to be debated. Whether these wearable systems evolve into a major end-use market category or simply become a niche with a short lifecycle remains to be seen. In the short-term, however, the launch of the Apple Watch — jam-packed with ICs, sensors, and other components — has provided a major boost to semiconductor unit shipments and sales in the wearable Internet-of-Things (IoT) category. IC Insights accordingly has estimated that the wearable IoT category will grow from $1 billion in 2014 to more than $5 billion in 2015.
With addition of more interconnected digital electronics to the fabric of our lives, we will need to continue to develop smarter methods to verify that everything is working correctly. The way forward is clear: verify early, be targeted in your analysis, and parallelize your efforts. Moore’s law is continuing to deliver exciting new opportunities to the world of design, manufacturing and services. Let’s all keep enjoying the new vistas opening up to us.
¹ From his DVCon 2013 keynote presentation, Accelerating EDA Innovation through SoC Design Methodology Convergence, February 26, 2013.
DAC Verification Survey: What’s Hot and What’s Not
| Graham Bell|
Vice President of Marketing at Real Intent
At the Design Automation Conference in San Francisco, Real Intent did a survey of 201 visitors to our booth. We focused on RTL and gate-level verification issues. Below is a brief introduction and you can see the entire survey on the DeepChip.com web-site.
DAC’15 “When is your next design start?”
0-3 months : ########################################### (52%) 3-6 months : ###################### (26%) 6-12 months: ################## (22%)
These numbers are very similar to what was reported in 2012 on DeepChip. With half of the future design starts occurring in the next 3 months, this leads me to think design activity is remaining strong despite any EDA user consolidation we might have seen with the big mergers of various chip companies, and the slowing of the Chinese economy. However, the latest IC forecast from Gartner has 2015 growth falling from 5.4% at the beginning of 2015 down to 2.2% in July.
DAC’15 “How many clock domains do you expect it will have?”
under 50 : ################################################ (58%) 50-100 : ##################### (25%) 100-500 : ######### (11%) over 500 : ##### (6%)
We asked this to find how many asynchronous clocks need to be analyzed by a CDC verification tool. When we see designs with over 100 clock domains they are typically mobile devices that use aggressive low-power goals with multiple clock schemes to hit their power target. Designs with under 50 clock domains are often block-level designs such as hard IP, or those for
commodity consumer electronic products.
Since 2012 we have seen a 10% increase in the number of designs with more than 50 clock domains, so system complexity continues to grow. What is interesting is that Harry Foster’s 2014 Wilson Group study reports much smaller numbers. We think our numbers are higher since respondents may be counting a mix of synchronous and asynchronous clocks in their designs.
“Have you seen CDC bugs that resulted in late ECOs?”
On-the-Fly Hardware Accurate Simulation, New Meridian CDC, ASICON Tutorial
| Graham Bell|
Vice President of Marketing at Real Intent
In this blog, we are presenting the highlights from Real Intent’s Fall 2015 Verification Newsletter. First are some thoughts from Prakash Narain, CEO, followed by an introduction to the new 2015 release of Meridian CDC for clock-domain and reset-domain crossing sign-off, and finally a review of our fall events including an ASICON tutorial.
Thoughts From Prakash Narain, President and CEO…
Most functional verification for SoC and FPGA designs is done prior to RTL hand-off to digital synthesis, since gate-level simulations take longer to complete and are significantly harder to debug. However, gate-level simulations are still needed to verify some circuit behavior. Unfortunately, X’s in gate-level simulations can cause differences in the RTL simulation output and the gate-level simulation output. X’s generally exist in all designs – it can be difficult to prevent this for practical reasons. Simulation results may be different because of X’s that are hidden in the RTL simulation by X-optimism, or additional X’s may exist due to X-pessimism in gate-level simulations. Pessimism can be fixed by overriding the simulator because you know that real hardware would always resolve to a deterministic value. The challenge is confirming that the X value is a result of X-pessimism and not simply X-propagation, and then forcing it to the right value at the right point in time so the simulation matches that of real hardware.
Real Intent’s Ascent XV product corrects X-pessimism on the fly so the simulation is hardware accurate. Use of Ascent XV saves the time required to get gate-level simulations started by an order of magnitude. It is proven to be superior to alternative approaches in the marketplace in terms of performance, memory, and accuracy. Its ease of use and capacity, make it the only practical solution for large SoC designs, just like our other Ascent and Meridian products.
New Meridian CDC Release with Next-Generation Features
In September we delivered the latest 2015 release of Meridian CDC for comprehensive clock-domain crossing (CDC) and reset-domain crossing (RDC) analysis. This new software release adds enhanced speed, analysis and debug support, boosting productivity for SoC and FPGA design teams. With a brand new way to debug CDC violations, it lets you achieve giga-gate capacity verification without sacrificing precision. We believe it is the industry’s fastest-performance, highest-capacity and most precise CDC solution in the market.
Some of the features of the latest Meridian CDC include:
- 30% faster performance and improved capacity for Giga-gate SoCs
- iDebug: a state-of-the-art design intent debugger and analysis manager
- Interfaces based approach for low-noise CDC analysis
- Qualitative improvements for several CDC checks
- Tcl-based command line interface lets user query and create custom scripts for debug and reporting
- New formal analysis engine with up to 10X faster speed and greater coverage to find CDC problems
- New HTML documentation improves usability
For additional insights and comments, please watch a video interview here.
Come Visit Us at Upcoming Industry Events
During October and November we will exhibit our Ascent and Meridian solutions at major industry events in Japan, China, Europe and Israel. We were most recently at Design Solution Forum in Yokohama, Japan, on Friday, Oct. 2. Please join us at the International Conference on ASIC (ASICON 2015) Nov. 3-6 in Chengdu, China, where Ramesh Dewangan, our VP of Product Strategy, will present a 90-minute tutorial “New Challenges and Techniques for Clock Domain Crossing and Reset Sign-off.” You can also see our advanced sign-off solutions at the DVCon EU technical conference in Munich on Nov. 11-12, in area F4, and at SemIsrael in Airport City on Nov. 17. At SemIsrael, Oren Katzir, our VP of Applications Engineering will present a talk “New RTL sign-off challenges: Reset metastability, X-safe design, and CDC Data glitches.”
Correcting Pessimism without Optimism – Part Two
| Lisa Piper|
Technical Marketing Manager
Part one of this article focused on the issues of X-pessimism at the netlist level and why the current solutions are inadequate. In In part two, we look at how the Ascent XV tool correctly addresses X-safe verification.
If a node is determined to be 1(or 0) pessimistic, that means its real circuit value is 1(or 0), but simulation produces an X. A pessimistic simulation value can be corrected by forcing a 1(or 0) on the node until the conditions for pessimism no longer hold, at which time, it is released. This does not mean that all X’s can be arbitrarily forced to a known value. Only X’s that result from pessimism should be forced, and they must be forced to represent the deterministic value that real hardware would see and released immediately when the pessimism stops.
Ascent XV-netlist makes your simulation hardware accurate by appropriately correcting pessimism. Ascent XV statically identifies the potentially pessimistic nodes and then uses that information to create SimPortal files that augment gate-level simulation to correct X-pessimism on the fly. By doing the analysis statically before the simulation starts, the number of nodes that must be analyzed during simulation is significantly reduced. Also, the X-analysis during simulation can be reduced to a table look-up when the potentially pessimistic node has an X-value. The SimPortal files monitor the potentially pessimistic nodes in the design on the fly, independent of the testbench.
A bottoms-up hierarchical static analysis can also be done at the block level. When all the blocks are integrated for full chip simulations, a very scalable solution is achieved. The SimPortal is designed for performance, and also minimizes compile time and memory overhead. You can control the verbosity at simulation time, and can choose to drop back to simple monitoring or even turn off both the correction and monitoring at any point in time. The flow and methodology is shown below in Figure 3.
Ascent XV X-pessimism Flow and Methodology:
- Run static analysis to determine which data input values can cause monitored nodes to exhibit pessimism. Generate design-specific SimPortal data files.
- Run SimPortal simulation to find out which nodes experienced the input combinations that cause pessimism.
The Ascent XV solution is characterized as follows:
- Gate-level simulation overhead is as low as 2x-2.5x
- Memory overhead is 0.5x
- Negligible overhead to compilation time
- Simulation time configuration of verbosity from totally quiet to full details
- Can choose to turn off correction at any point in time (such as after reset)
- Unique approach easily handles next generation full chip netlists (billion gate SOCs)
- Only does forces when pessimism is occurring.
- The value forced is the value that will be seen in real hardware.
- Ease of Use
- No setup required
- Testbench independent static analysis
- No need to touch the existing design or testbench, only the simulation script
In RTL, X’s can hide functional bugs due to X-optimism. These bugs will be brought to light in netlist gate simulations. Unfortunately, X’s also cause X-pessimism in netlist simulations, making it difficult to determine whether a functional mismatch is due to X-optimism, X-pessimism, or something else entirely. Ascent XV – Netlist will remove X’s caused by X-pessimism, removing the major source of simulation RTL and netlist simulation differences.
Reliable correcting of pessimism at the netlist has become very feasible, thanks to Ascent XV. But there is additional analysis that can be done early in the RTL development process to prevent potential X-issues. This will benefit the post-RTL handoff, whether it is gate-level simulations or FPGA modeling of your design, so you are not debugging X-optimism issues in hard to debug environments.
Ascent XV- Reset Optimization minimizes significant X’s in the design that result from incomplete initialization. Ascent XV – Reset Optimization will do a hardware accurate reset analysis that will report where additional resets are needed; as well suggest where resets can be removed. It ensures complete initialization, taking into account the propagation of known values to avoid adding extraneous resets. The goal is to minimize X-issues during the design of the RTL. In the case of simulations, fewer occurrences of pessimism will speed your simulation.
Ascent XV-RTL Optimism analyzes where the X-sources of a design are, as well as where they can cause X-optimism. This ensures hardware accurate simulations at RTL either by eliminating the X-source, or through coding for X-accuracy. Hardware accurate RTL simulations will make the RTL-netlist simulation outputs easier to compare, but more significantly, it will make FPGA-based modeling easier to get up and running.
Once a design is synthesized, the immediate goal is to get gate-level simulations up and running fast. Unfortunately, X’s in gate-level simulations can cause differences in the RTL simulation output and the gate-level simulation output. X’s generally exist in all designs – it can be difficult to prevent this for practical reasons. Simulation results may be different because of X’s that are hidden in the RTL simulation by X-optimism, or additional X’s may exist due to X-pessimism in gate-level simulations. Pessimism can be fixed by overriding the simulator because you know that real hardware would always resolve to a deterministic value. The challenge is confirming that the X value is a result of X-pessimism and not simply X-propagation, and then forcing it to the right value at the right point in time so the simulation matches that of real hardware.
Ascent XV- Netlist Pessimism corrects X-pessimism on the fly so the simulation is hardware accurate. Use of Ascent XV saves in the time required to get gate-level simulations started by an order of magnitude. It is proven to be superior to alternative approaches in the marketplace in terms of performance, memory, and accuracy. Its ease of use and capacity, make it the only practical solution for large SOCs.
Correcting Pessimism without Optimism – Part One
| Graham Bell|
Vice President of Marketing at Real Intent
Most functional verification for SoC and FPGA designs is done prior to RTL hand-off to digital synthesis because gate-level simulations take longer to complete and are significantly harder to debug. However, gate-level simulations are still needed to verify some circuit behavior. Ideally, the output of the RTL simulations will match the output of gate-level netlist simulations on the same design after synthesis. And why wouldn’t they? Besides the obvious things that are being verified in your gate-level simulations, there are also unknown values (X’s) that were not seen in RTL due to X-optimism, and additional X’s in the gate-level simulations due to X-pessimism. Part one of this article focuses on the issues of X-pessimism at the netlist level and why the current solutions are inadequate.
X-pessimism and X-optimism Defined
The presence of X’s can cause both X-optimism in RTL simulations and X-pessimism in netlist simulations. X-optimism can result in the failure to detect functional bugs at RTL. X-pessimism typically makes it hard to get netlist simulations up and running quickly.
X-pessimism occurs in gate-level designs when an X signal at the input of some digital logic causes the simulation output to be an X value, even though in real hardware the value will be deterministic, e.g., a 1 or 0. Figure 1 shows a very simple example. When the value of in1 and in2 are both 0, the simulation value at the output is 0, as it would in hardware. But when the “input” value is an X, and the values of in1 and in2 are both 1, the simulation value at the output is X in simulation but is 1 in real hardware. This behavior is called X-pessimism because the known value simulates as an unknown. More specifically, we say it is 1-pessimistic because the output should have been a value of 1.
X-optimism is the opposite, when an unknown value is simulated as if it is a known value in hardware. Consider the example shown in figure 2 below. If the “input” signal is an X value, that means that “input” could be either a 0 or a 1 value in real hardware because real hardware does not have an X value. So in real hardware, signal “D” might also be a 0 or a 1 value. However, in simulation, the output “D” would always show as a 1 value. It is called “optimism” because the unknown was resolved as a known value. This can cause functional bugs to be missed in RTL simulations, although in netlist the X would always be properly propagated.
The examples above are very simplistic. In real designs the logic cone of the “cloud” is often very complex, with the selected output being driven by a logic expression and the “input” also being a logic expression. In this case, sometimes the output X value is a result of pessimism and sometimes it is simply the propagation of an X that was optimistic in RTL. One can be artificially corrected without harm, but the other could be a bug lurking to be discovered. Refer to “X-Propagation Woes – A Condensed Primer”1 for more details.
Commonly Used Quick Fixes
There are three approaches that we hear being used for addressing X-pessimism, all with downsides. The approaches are 1) eliminating all X’s in the design, 2) artificial random initialization of uninitialized flops, and 3) manual drudgery.
The first common approach for eliminating all X’s is to add a reset to all memory elements. This eliminates the most common source of Xs – uninitialized flops. However, synchronous resets sometimes can cause pessimism issues to be introduced during the synthesis process. Also, other sources of X’s do exist in a design, such as explicit X-assigns for flagging illegal states, bus contention, and out of range references, among others. A more significant issue is that extra resets eat into power, size, and routing budgets. Resettable flops are larger, more power hungry, and require additional routing resources. Resetting all flops is practical only for smaller designs, and does not address all sources of X.
The second common approach is to artificially randomize the initialization of uninitialized memory elements at time 0. The issue with this approach is that while it will help simulations, it will not necessarily match real hardware. It also does not address all sources of X in a design. X-optimism bugs that were masked in RTL likely will be artificially masked again in netlist simulations. This risk of missing a bug that was masked by optimism in RTL and artificially removed at netlist could result in a critical bug being missed. These days, with the high costs of manufacturing and – heaven forbid – recalls, the downside for a failure can be very expensive.
The third approach is to manually analyze the root cause of all X-differences between the outputs of RTL and gate-level simulation, and then determine the correct value and time to force and release pessimistic nodes. This can be very difficult to do because a gate-level design is a transformation of an RTL design into something that is more complex, has a different structure, and has unfamiliar signal names. It can be very time consuming to chase down those pessimistic X’s in the netlist simulation. The issue is exacerbated when there is a mixture of X differences from both optimism and pessimism, with pressure to get it fixed as soon as possible and not accidently miss a real bug. For large designs, this effort can take months.
Existing approaches fall short because they do not address pessimism caused by X’s from all sources, they can mask issues in the gate-level simulations due to X-optimism in RTL simulations, and they are insufficient to handle the largest SoC designs.
In part two we will look at how the Ascent XV tool correctly addresses X-safe verification.
Calypto Design Systems: A Changed Partner
| Graham Bell|
Vice President of Marketing at Real Intent
Calypto Design Systems was embraced by Mentor Graphics this week. Founded in 2002, the company was born out of discussions between founder Devadas Varma and Dado Banatao, partner at Tallwood Venture Capital. By early 2005, it had raised $22 million in venture capital, and had 42 employees, 18 with PhDs. It was tackling equivalence checking (SLEC) between ESL and RTL design representations.
In 2011, Mentor bought a 51% interest in the company and sold Calypto its Catapult-C synthesis technology, which seemed like a good match to their SLEC tool. With Calypto’s growing success, it was natural that Mentor would pull them into their fold.
For several years, Calypto Design Systems and Real Intent have co-operated in support of verification flows for mutual customers. Both companies shared the same distributor is Korea.
One flow we had jointly announced was our Ascent Lint with their Catapult synthesizer. Catapult lets designers use industry standard ANSI C++ or SystemC to describe functional intent at the ESL level. From these high-level descriptions, Catapult automatically generates production quality RTL. Ascent Lint ensures Catapult-generated RTL code is lint clean and error free for a safe and reliable implementation flow from RTL to GDSII layout.
Calypto also has the PowerPro tool which is an automated RTL power optimization and analysis product that identifies and inserts sequential clock gating and memory enable logic into synthesizable Verilog and VHDL designs. You can see it on the right side in the following flow diagram from an illustration used at the 2014 Design Automation Conference.
In this flow, the Real Intent Meridian CDC tool checks that signals crossing asynchronous clock boundaries are correctly registered and synchronized in the RTL code. In this flow, it is used to verify that any optimizations done to your RTL have not broken the assumptions for CDC synchronization.
Partnerships are not just about technology, they are also about people. I have had the pleasure to work with Mark Milligan, VP of Marketing and his predecessor Shawn McCloud in promoting these flows. As well, I want to thank Mathilde Karsenti, Marketing Programs Manager, who brings a passion for excellence in her work and made our joint promotions a success.
Now that Calypto is part of Mentor Graphics the co-operation with Real Intent will take a different form. But the drivers for the co-operation are still very much current. RTL generated from a high-level synthesis tool or modified by power optimization needs to be verified to ensure that inadvertent errors have not been introduced. Real Intent will continue to work with its partners in the industry to sign-off their RTL prior to synthesis and implementation.
A Verification Standard for Design Reliability
The great thing about a standard is that once you decide to use it, your life as a designer is suddenly easier. Using a standard reduces the long list of choices and decisions that need to be made to get a working product out the door. It also gives assurance to the customer that you are following best practices of the industry.
A standard for the world of aviation electronics (avionics) is the RTCA/DO-254, Design Assurance Guidance For Airborne Electronic Hardware. It is a process assurance flow for civilian aerospace design of complex electronic hardware typically implemented using ASICs or big FPGAs. In the USA, the Federal Aviation Administration (FAA) requires that the DO-254 process is followed. In Europe there is an equivalent standard called EUROCAE ED-80.
At first glance the standard seems daunting. It defines how design and verification flows must be strongly tied to both implementation and traceability. In DO-254 projects, HDL coding standards must be documented, and any project code must be reviewed to ensure it follows these standards. They address the following issues: 1326
New 3D XPoint Fast Memory a Big Deal for Big Data
| Graham Bell|
Vice President of Marketing at Real Intent
After years of research, a new memory technology emerges that combines the best attributes of DRAM and NAND, promising to “completely evolve how it’s used in computing.”
Memory and storage technologies such as DRAM and NAND have been around for decades, with their original implementations able to perform only at a fraction of the level achieved by today’s latest products. But those performance gains, like most in computing, are typically evolutionary, with each generation incrementally faster and more cost effective than the one preceding it. Quantum leaps in performance often come from completely new or radically different ways of solving a particular problem. The 3D XPoint technology announced by Intel in partnership with Micron comes from the latter approach.
“This has no predecessor and there was nothing to base it on,” said Al Fazio, Intel senior fellow and director of Memory Technology Development. “It’s new materials, new process architecture, new design, new testing. We’re going into some existing applications, but it’s really intended to completely evolve how it’s used in computing.”
Touted as the biggest memory breakthrough since the introduction of NAND in 1989, 3D XPoint is a new memory technology that is non-volatile like NAND memory, but is up to 1,000 times faster, with a faster speed only attainable by DRAM, and with endurance up to 1,000 times better than NAND.
3D XPoint owes its performance attributes and namesake to a transistor-less three-dimensional circuit of columnar memory cells and selectors connected by horizontal wires. This “cross point” checkerboard structure allows memory cells to be addressed individually. This structure enables data to be written and read in smaller blocks than NAND, resulting in faster and more efficient read/write processes.
Removing bottlenecks in a system is a key method to increase overall performance. Memory in particular has been a growing barrier, primarily because consistent performance gains in processors in recent years have dramatically outpaced both the speed of hard disks and the cost and density of DRAM.
“What’s exciting about the technology is that it unleashes the microprocessor. It gets more data closer to the CPU. It has 10 times the density of DRAM at near levels of performance, and it allows people running applications to have much more data available to them,” said Rob Crooke, vice president and general manager of Intel’s Non-Volatile Memory Solutions group. “Conversely in the storage, it’s up to 1000 times faster than NAND. To put that in perspective, most people have experienced an SSD versus a hard disk, where the SSD is about 1,000 times faster than a hard disk. This new technology is going to be that same level of pop, like everything’s in memory.”
“We’ve looked at gaming performance, and it has a phenomenal impact and gives the game creators much more freedom,” explained Crooke. “As opposed to constraining their game levels to how much they can fit in memory and then loading a new level, they now have total freedom to create a much richer game experience and one that’s seamless and continuous, and they can decide if they want to break it up. It’s at their artistic and creative discretion to do that, as opposed to some physical limit like memory size.”
“It’ll be a game-changing experience not only in the client platforms, but also in the data center where they’re trying to analyze remarkable amounts of big data,” Crooke continued. “More and more data needs to be driven to the CPU to analyze faster. Having much more data available to the CPU at a very short latency is pretty exciting.”
Micron and Intel have been jointly developing this technology since 2012. There was, however, basic research on various technologies at both companies for years prior to this partnership. The research team could have tried an easier route—committing to performance and density, or performance and cost, for example—but “if you want to change something, you’ve really got to go for that tougher problem and tie them all together,” Fazio explained.
In 2012, Micron and Intel agreed to jointly pursue the most promising technologies from the research findings. Hundreds of Intel and Micron engineers have been involved in developing the technology to its current state, spanning facilities in California, Idaho and around the world. Over the last three years, the process development for this technology occurred in Micron’s state of the art 300mm R&D facility in Boise, Idaho.
“Nobody has ever attempted productizing a stackable cross point architecture at these densities. Learning the characteristics and developing the integration methods for this novel architecture was full of engineering challenges,” said Scott DeBoer, vice president of R&D at Micron. “3D XPoint technology required the development of a number of innovative films and materials, some of which have never before been used in semiconductor manufacturing. Understanding the characteristics and sensitivities of these new materials and how to enable them was daunting.”
3D XPoint, NAND and DRAM
While 3D XPoint may have capabilities that can displace DRAM and NAND, DeBoer noted that it’s an additive technology that will co-exist with current solutions while also enabling new innovations. “DRAM will still be the best technology for most demanding highest performance applications, where non-volatility, cost and capacity are less critical. 3D NAND will still be the best technology for absolute lowest cost, where performance metrics are less critical.”
What could be a significant factor in these different memory solutions co-existing is that they can all share manufacturing facilities. “This technology is fabricated using the same manufacturing lines and methods as conventional memory technologies,” said DeBoer. “With the cross point architecture and the materials systems required for the new cell technology, some unique tooling was developed, but these requirements are on par with standard technology node introductions for NAND or DRAM. This technology is fully compatible and not disruptive to current manufacturing lines.”
Scalable Into the Future
The future of this technology looks wide-open too. “The cross point memory cell should be the most scalable architecture,” said Crooke. “It should allow us to scale the memory technology to pretty good densities yet allow it to be byte-addressable or word-addressable like memory is, as opposed to NAND, which is accessed in blocks of data.”
“Because it does not require the overhead of additional access or select transistors, the stackable cross point architecture enables the most aggressive physical scaling of array densities available,” DeBoer added.
A technological solution that paves the way for new models of computing doesn’t come by very often. It took teams of hundreds of experts, countless flights, and constant open lines of communication and cooperation to bring make 3D XPoint technology possible.
“Micron and Intel have a long working history inside our NAND JDP and our IMFT joint venture. This made enabling the team cooperation and performance that much easier as we have already strengthened and grown the partnership in that program,” said DeBoer. “Entirely new technologies don’t come around very often, and to be part of this team was truly a once-in-a-career opportunity.”
“One of the things that we should be proud of is the persistence we’ve had over a long period of time,” Crooke added. “Working on a technology problem that you don’t know is solvable, for a sustained period of time, requires a level of confidence and stick-to-it-iveness.”
This article is provided courtesy of IntelFreePress.
Technology Errors Demand Netlist-level CDC Verification
| Dr. Roger B. Hughes|
Director of Strategic Accounts
Multiple asynchronous clocks are a fact of life on today’s SoC. Individual blocks have to run at different speeds so they can handle different functional and power payloads efficiently, and the ability to split clock domains across the SoC has become a key part of timing-closure processes, isolating clock domains to subsections of the device within which traditional skew-control can still be used.
As a result, clock domain crossing (CDC) verification is required to ensure logic signals can pass between regions controlled by different clocks without being missed or causing metastability. Traditionally, CDC verification has been carried out on RTL descriptions on the basis that appropriate directives inserted in the RTL will ensure reliable data synchronizers are inserted into the netlist by synthesis. But a number of factors are coming together that demand a re-evaluation of this assumption.
A combination of process technology trends and increased intervention by synthesis tools in logic generation, both intended to improve power efficiency, is leading to a situation in which a design that is considered CDC-clean at RTL can fail in operation. Implementation tools can fail to take CDC into account and unwittingly increase the chances of metastability.
Various synthesis features and post-synthesis tools will insert logic cells that, if used in the path of a CDC, conflict with the assumptions made by formal analysis during RTL verification. Test synthesis will, for example, insert additional registers to enable inspection of logic paths through JTAG. Low-power design introduces further issues through the application of increasingly fine-grained clock gating. The registers and combinatorial cells these tools introduce can disrupt the proper operation of synchronization cells inserted into the RTL.
The key issue is that all clock-domain crossings involve, by their nature, asynchronous logic and one of the hazards of asynchronous logic is metastability. Any flip-flop can be rendered metastable. If its data input is toggled at the same time as the sampling edge of the clock, the register is likely to fail to capture the correct input but instead become metastable. The state of the capturing flop may not settle by the end of the current clock period, and so presents a high chance of feeding the wrong value to downstream logic (Fig 1).
The risk of metastability with asynchronous logic is always present. Designers can ensure that their designs are unlikely to experience a problem from metastability by increasing the mean time between failures (MTBF) of each synchronizer.
The MTBF varies with the settling time of the signal, the time window over which data is expected to settle to a known state, the clock frequency, the data frequency, and the resolution time-constant for the synchronizer, written as τ (tau). The parameter τ depends primarily on the capacitance of the first flip-flop in the synchronizer, divided by its transconductance. MTBF exhibits an exponential dependence on τ as it is proportional to e1/τ. The value of τ tends to vary with both process technology and operating temperature because that affects drain current, which, in turn, affects transconductance. The MTBF can drop many orders of magnitude at temperature extremes, making a failure far more likely.
Technology evolution has generally improved τ, making it less significant as a parameter over the past decade or more, but the property is beginning to become significant again in more advanced nodes because of the failure of some device parameters to scale.
Designs that would probably not have experienced failure before are now at risk of suffering from metastability issues. Coupled with the need for higher performance, MTBF for CDC situations needs to be monitored carefully. Automatically inserted logic can introduce problems for the synchronizer, because register depth and organization affects MTBF. Tools need to be able to take these effects into account if they are to insert cells that reduce the probability of metastability. Further, logic inserted ahead of the synchronizer can introduce glitches that are mistakenly captured as data by the receiver in the other clock domain. Therefore information about the implementation is vital to guarantee performance during CDC checks. The following examples show some of the situations that can arise due to logic insertion by implementation tools.
Example implementation errors
Implementation tools can introduce a number of potential hazards by failing to take CDC into account. Additional registers inserted by test synthesis, for example, can result in glitches on clock lines that can lead to an increased probability of mis-timing issues (Fig 2).
Clock-gating cells inserted by synthesis tools to reduce switching power may also be incompatible with a good CDC strategy. A combinatorial cell such as an AND gate that follows the register intended to pass a clock signal across the boundary to drive the receiving registers is more likely to experience glitches (Fig 3).
Timing optimization can result in significant changes in logic organization. The optimizer may choose to clone flops so that the path following each flop has a lower capacitance to drive, which should improve performance. If the flops being cloned form part of a synchronizer, this can result in CDC problems. A better way of handling the situation is to synchronize the signal first, and then to duplicate the logic beyond the receiving synchronizer (Fig 4).
The introduction of test logic may even result in the splitting of two flops intended for synchronization. In other situations, optimization of control logic or the use of non-monotonic multiplexer functions can result in the restructuring of CDC interfaces and introduce the potential for glitches (Fig 5).
Because of these possibilities, CDC verification needs to occur at both RTL and netlist – any solution that does not perform netlist-level verification is not complete. An effective strategy for verification is to ensure that the design is CDC clean at RTL and then to use physical-level CDC checks on the netlist to ensure that problems that may have been created by the various implementation tools are trapped and solved using a combination of structural and formal techniques. Tools such as Meridian Physical CDC take the full netlist into account, which is very large in modern designs and can often run to hundreds of millions of gates, ensuring that a design signed-off for CDC at RTL remains consistent with its actual implementation.
This article was originally published on TechDesignForums and is reproduced here by permission.