Whether Intel can pull the US market out of the red has yet to be seen however. The company recently announced that their manufacturing deal with TSMC is now on hiatus due to a lack of demand among consumers for more Atom based devices. In addition, Intel seems to be favoring overseas locations to US based sites for new fab construction.

Intel is set to begin production of chipsets in a new China based facility later this year, and it seems likely that Haifa will be selected as the site of the next 22nm fab considering their gains in 2009 and the closing of the Ireland facility. Two of Intel’s six US based facilities are scheduled to be closed this year according to Semi’s map of closing/closed frontend fabs, shown below. Other major players include Toshiba, who is currently contemplating the creation of a new $8.9B fab in Japan and giant TSMC, who is holding strong despite recent challenges with wafer costs and 11 straight quarterly losses.

Although it is unclear if Intel intends to make additional investments into the remaining US fabs, hopefully the current race among NAND flash manufacturers can bolster the US market. Electronics manufacturer Samsung is pushing hard to open a new Austin facility in 2010 that will be the largest chip fab in North America. Additionally, Texas Instruments is set to begin production at its new analog fab in Richardson, TX later this year, and GlobalFoundries is planning the creation of a new facility in Saratoga, NY.

Map of Closed and Closing Fabs

View Closed/Will be Closed Frontend Semiconductor Fabs in a larger map

Don’t Begin Multi-Processor Testing Before You’re Ready

One of the core principles of Obsidian’s verification methodology is to catch every possible bug in the simplest possible configuration. That stands to reason that the single processor configuration needs to be thoroughly verified with a high degree of confidence before MP verification begins. The reason for this is simple – if the same bugs can be found in a simpler processor configuration, much less time will go to waste. Multiplied hundreds of times over, this savings in time can result in a time-to-market improvement of weeks or even months.

Beginning Multi-Processor Verification with Non-Sharing Tests

The first stage of MP testing that we implement is non-sharing. The goal at this stage is to find and correct errors that occur with the least amount of sharing as possible to simplify debugging and save time troubleshooting complex scenarios.

In the initial stages of MP verification, it’s best to divide the memory up into large partitions that are each allocated to a single processor core. Some sharing will always exist between the CPUs in spite of restrictions. This is due to the way that multiple CPUs behave upon reset (i.e. beginning the execution stream at the same reset address) and because complex MP systems typically require each CPU to be aware of their own CPU number (i.e. CPU0, CPU1, etc.).

Ideally, sharing should be minimized as much as possible at this stage of verification, although it is impossible to eliminate it altogether. If the architecture permits, it’s also beneficial to start with paging disabled to simplify debugging. This eliminates the possibility of errors where one physical address is mapped to multiple pages by more than one CPU.

With these restrictions imposed, large numbers of random test sequences are generated and debugged as needed. Once errors become extremely sparse in this mode of testing, the memory is divided up into cache lines which are each assigned to allow accesses by only a particular CPU. A more complex environment is then created in which more complex bugs can be found, such as paging errors. As before, copious amounts of random test sequences are generated and more errors will be found.

Some verification teams will completely forgo the large partition phase of false-sharing and start by immediately dividing the memory into cache lines. While this does work, it also tends to complicate debugging and forces the verification team being to prematurely deal with paging issues while debugging simple errors.

False-Sharing Multi-Processor Tests

The false-sharing arrangement is similar to the second stage of non-sharing in that the memory is divided up into cache lines. In this mode, multiple CPUs are allowed to hit the same cache lines, but not the exact same physical addresses. What this does is allow the cache accesses to come very close to each other without hitting the same spots. Several cache problems can be found and corrected using this method.

Debugging caches in this way greatly simplifies the process of testing actual shared memory and better limits the occurrence of simple errors in complex scenarios. At every stage of the process, it is important to perform cacheable and non-cacheable testing as there may be bugs lurking in both of these areas.

True-Sharing Multi-Processor Tests

True-sharing tests are more complex as they allow multiple CPUs to access the same physical memory addresses. In both deterministic and in non-deterministic modes, tests generated by RAVEN are guaranteed to execute correctly regardless of timing issues including fast or slow memory or insertion of external interrupts.

Deterministic True-Sharing

As a simplified example of deterministic true-sharing, let us assume that we are verifying a dual CPU configuration. We begin by dividing up the execution stream using semaphores. Each divided zone may contain different numbers of instructions for each CPU with varying amounts of memory accesses, exceptions, etc. Because of this, some CPUs may complete their zones more quickly than others. During the same semaphore, the CPUs are unaware of values written by the other. Not until the semaphore has been completed will the CPUs sync up again and be aware of the other’s transactions. Once this happens, CPU0 can determine that it is legal to write to a line that CPU1 completed in the last semaphore. Upon completion of all zones, final values are compared, checking for consistency and errors. Although our rules are much more complicated than this, the example should elaborate on the kind of errors that can occur in MP verification. Because our tool implements complex rules, the test generated can determine if memory location will be deterministic or non-deterministic based on execution divided by semaphores. This is how we do deterministic sharing and actual reads and writes to the same physical memory addresses. This can find a lot of bugs.

Non-Deterministic True-Sharing

Non-deterministic true-sharing is the most complex mode of sharing and should always be conducted as the final stage of MP verification. In this method, we don’t use semaphores to divide up the execution stream, but instead allow CPUs to read addresses that are being written by other CPUs. If two CPUs write to the same address, then a read of this address will result in an unknown value. If this value was intended for use in address generation or arithmetic calculation, then the result of these tasks will be unknown, and verification becomes much more difficult. Non-deterministic registers then cannot be used as sources, but only destinations until they take on deterministic values.

If non-deterministic transactions set flags, then the flag register must immediately be re-written. This is especially important in ARM processors where every instruction is conditionally executed. If something is done that results in a flag, the next instruction must be set to always execute regardless of flag values and perform the additional step of re-writing the flags. We have settings and rules that determine what percentage of registers are allowed to become non-deterministic based on their type (i.e FPR, GPR, etc.). So we do have some pretty complicated algorithms for handling determinism and non-determinism and determining legality of actions.

Non-deterministic tests become much more difficult to debug because you will have a list of possible values for each access and the errors can be timing dependent. These areas are important to cover, but they should be done last as the difficulty in debugging errors of this type is extremely high.

Verifying the Snooping Mechanism

One of the most critical areas in MP verification is cache coherence. Errors of this type can be detrimental to practical operation of the design. For example, it is possible to have errors in which data integrity is compromised due to multiple CPUs accessing shared memory.

To further illustrate an error of this type, let us assume that we are verifying two CPUs that both share a single L1 cache. At some point the L1 cache will have an image of data that resides in the main memory. If both CPUs write to the same cache line of the L1, then it is necessary to verify that the correct values get written back to main memory.

Adding an L2 memory to a situation such as this makes matters even more complicated. In this case, cache lines in the L1 will be an image taken the L2, which itself contains portions of data in the main memory. However, there is now the additional problem of L1 data being written back to main memory without crossing the L2. This creates a corresponding line of L2 cache that must now be invalidated to avoid errors.

Further conflicts can occur if a CPU flushes a cache line in the L1 that another CPU has written to, was going to write to, or is in the process of writing to. Fox example, suppose that we have a four CPU situation with two L1 caches, each being shared by a pair of CPUs and an L2 that is shared by all four CPUs. This is a common paradigm in MP designs. In this situation, it is physically possible for CPUs 0 /1 to write to the same line of memory as CPUs 2/3, creating another situation that has to be resolved. Each cluster of CPUs must then ask the other if for permission to read/write to main memory to avoid conflicts.

Verification of Shared Registers

One of the great things about having a random test generator is that it can effectively deal with obscure cases and propagate them across multiple CPUs. In the case of shared registers, we can divide them up into an arrangement similar to our true sharing example or allow only one CPU to handle all the shared registers. We can also use semaphores to do time/execution division of accesses and do non-deterministic testing, although this depends on the type of register. Although shared registers present some unique challenges, they also allow for some different opportunities to take advantage of.

These are all complicated issues which may be further compounded by timing issues. Errors such as these are what MP verification is really about and where the bulk of the errors can be found.

The early stages of functional verification present several unique challenges that must be overcome to achieve first silicon on schedule. This article identifies several common problems that Obsidian recently encountered in the verification of a new ARM based processor design and discusses how the RAVEN random test generator was used in overcoming these obstacles.

Eliminating Bottlenecks

Many organization want to begin verification as soon as the first logical unit of RTL becomes available. However, the tool-chain (i.e. assembler, linker, compiler, etc.) often lags behind RTL development and architectural changes, creating a bottleneck in verification. RAVEN allows verification teams to completely bypass this problem and begin identifying functional errors before the tool-chain is implemented. Customers using RAVEN can have reported large productivity gains over directed testing, especially in the beginning and intermediate stages of verification – hitting 95-98% of all required coverage points using random tests.

Verifying Intermediate RTL

Let’s assume that the ALU unit of your design is ready for testing at an early stage, but the MMU, floating-point and load/store units are not. Some teams might begin by testing each instruction in order, varying only one or two operands for the sake of expedience. However, this creates a problem. Following this methodology, only a small portion of the RTL will be tested and the entire design will be exposed to errors that should have been corrected early on. With the same investment in time, RAVEN can produce significantly better results with only slight modifications to the default template.

Start Test
Random Instruction (ALU)………………..min=10     max=20
End Test

RAVEN template files are used to designate which behaviors should be tested. At the most basic level, these templates provide the ability to interchange instruction groups, instruction quantity, and selection of operands. More advanced configurations allow for the biasing of certain exceptions and addressing/operand modes. This ability is important in the sense that it allows additional behaviors to be added incrementally as bugs are discovered and new areas of the RTL become available in emerging designs.

In the case of our ALU example, the Random Instruction control can be directed to use only instructions in the ALU group and can even disable the selection of individual instructions within that group. Available instructions can then be tested with an almost infinite number of parameter configurations. As further instruction groups and processor features become available (e.g. integer divide, MMU, load/store) RAVEN templates can be automatically updated to include these new behaviors. Simply re-generating the same templates then allows for the creation of thousands of new tests.

Planning for Bugs in Your Testing Methodology

As you’re creating your first tests, it’s important to think about how long they’ll take to simulate and debug. Smart design teams take into account where they are in the development cycle and the amount of processing power available for simulation when creating tests. This way tests can be run and completed within a targeted amount of time.

When a generated test hits a bug, it’s also much easier to isolate and identify the error if it is detected in a test with ten instructions rather than one with a thousand instructions. Even if you hit a bug in only one out of every thousand tests of ten instructions, this is still beneficial when compared to the time required to debug large tests.

Once you’re able to generate 10-20K short tests without finding errors, then it’s time to move up to tests of a hundred instructions and eventually on to tests of a thousand instructions. The reasoning here is that the more rare your bugs then become, the more dependent they will be on processor state, and longer tests will be more useful in this respect. Changing the quantity of instructions in a RAVEN template is as easy as adding extra zeros and regenerating.

Once bugs are found, RAVEN can be configured to continue testing around the error by disabling access to problematic behaviors in the RTL. Most internally developed generators don’t have this fine-grained level of control. It’s far easier for RAVEN to hit new behaviors while avoiding others that aren’t yet ready to be tested than for most other EDA tools on the market.

Sure, self-checking code can be used with directed tests. But it’s time consuming, cumbersome and there’s no randomization. RAVEN has several features that make it work really well in a silicon validation environment for creating self-checking tests.

Inherent Self-Checking

Taking them one by one. If you’re leaving RAVEN undirected, which is usually what you want to do, then what gets intermixed are lots of jumps that depend on the previously generated values. Since tests generated by RAVEN can go anywhere and do anything, it’s not uncommon for complex tests to end with a jump off of some value, leading to another instruction sequence. So, inherently RAVEN tests are self checking.

Inside of a random test, you’ll usually have lots of jumps. If any of the calculations leading to those jumps change, then you’ll jump off into an area that you don’t want to be fairly quickly because some calculated value went wrong. Depending on your architecture, what some companies will do is to preload the memory area so that undefined instructions will cause traps resulting in a fail. Now you have to go into your silicon and figure out how you got to this point, but at least you know that you have a failure. Directed tests won’t have the same results as RAVEN because the engineers writing them won’t jump off of their results into strange places. It’s too hard for humans to use the results of calculations as jump targets, but for RAVEN it’s actually quite easy.

Configurable Self-Checking Features

The second thing that users can do is to turn on RAVEN’s self-checking feature, which includes a number of options for how you want to do self-checking. This feature tells RAVEN to insert self-checking code, much like a directed programmer would do to validate something, like a series registers. Since RAVEN knows when registers are updated, we can tell it to check all registers to make sure that their information is valid. Alternatively, we can check only the registers that were written or read. We can do this check after a preset number of instructions, at the end of the sequence, or it can be randomized to occur between a certain number of instructions.

Adapting Self-Checking Tests to Fit the Hardware Environment

For many customers, the actual test or hardware that they are operating in is embedded in an SoC with some test mode that allows them to bring signals out. But their environment is very different from the environment of their simulation world. In simulation, they may have a large amount of memory to use for testing. In this new environment though, they may want to restrict the tests to use only the on-board device memory. This might be a only very small amount, let’s say somewhere between 256K and 2MB.

Because RAVEN has configuration files that describe the environment that the chip is in, you can move tests originally written for a 4GB address space into 1MB of memory. RAVEN can then re-generate all of the tasks from your templates, forcing them into that much more constrained memory area. Now you can take your whole suite, and probably with some exceptions, regenerate all of your tests toward your real hardware platform and even re-simulate them again in their original environment with slight modifications to mimic what the hardware will look like. If all of these tests can be successfully run at full speed, then there is a high degree of confidence that the model is accurately reflected in the design and that there won’t be hidden problems in the silicon.

Ability to Verify RTL and Instruction Set Simulator Agreement

Another, more comprehensive method of self-checking in the RTL environment is the intermediate state information provided by RAVEN. Our test output files contain information about all updates to registers and memory that occur as a result of instruction execution. The testbench can be instrumented so that there are checkers that watch registers and memory to make sure that they progress through values predicted by simulation. This allows the testbench to detect the discrepancy in the exact instruction that caused it or within just a few cycles of that instruction, greatly reducing the time required for a verification engineer to isolate the problem.

When a load/store instruction crosses a page boundary, it is difficult to create all possible combinations of exceptions for both halves of the instruction. For example, if 2 possible exceptions exist then there will be 16 possible combinations of exceptions for 2 halves of the access. Because of this, it can be very hard to reach these exceptions, even with directed testing.

Obsidian’s RAVEN technology addresses this issue with its random methodology. User configurable biases may be used to direct the generator into areas where data access instructions may cross page-boundaries. Difficult to reach errors such as these can be uncovered with minimal effort and without diverting your greatest resource, the time of your most experienced engineers.

Confirmed Panelists include:

Ty Garibay

• Ty Garibay is the Program Manager for ARM Processor development in Texas Instruments’ Wireless Terminals Business Unit and site manager for TI’s Austin office. Currently, he and his team are focused on the completion of the industry’s first 45nm implementation of ARM’s Cortex-A8 super-scalar processor core.
• Over the previous 20+ years, Ty has designed microprocessors at ARM, Alchemy Semiconductor, SGI/MIPS, Cyrix and Motorola, participating in all phases of design from circuits and layout through architecture and product definition.
• He holds over 30 patents in the areas of integrated circuit design, computer architecture and design methodology.

Brian Wong

• Mr. Wong was President and CEO of D2Audio Corporation since 2005, a leading audio semiconductor and software company. D2Audio was recently acquired by Intersil Corporation in August, 2008. He is currently running the D2Audio-Intersil business as Director of D2Audio.
• Previously, Mr. Wong was CEO at Primarion Inc, a company focused on data communications and Power Management ICs, which was acquired by Infineon.
• Prior to that, he was a senior manager at TRW and managed the Mixed Signal IC business, which included data converter, Clock/Data Recovery, PLL, optical datacom, and high speed digital ICs.
• Mr. Wong holds a BSEE from University of California, Los Angeles, a MSEE from University of Southern California, and has taken graduate management classes at UCLA Anderson School of Management. He has co-authored textbooks and papers on semiconductor technology and data converters. He is the Chairman of The Austin Technology Council, serves on the Advisory Board for the UC Davis ECE Department, and on the board of Integral Wave Technologies, a power management company.

Jim Reinhart

• Jim Reinhart is President and CEO of Luminary Micro and one of the company’s three cofounders. Jim has more than 25 years of experience in the creation and commercialization of computing technologies. A sixth-generation Texan with degrees from Rice and St. Edwards Universities, Jim will give a talk on the changes that are driving a massive shift in the semiconductor industry.
• This event will be hosted by Eric Hennenhoefer of Obsidian Software and moderated by Steven Schulz of Silicon Integration Initiative.

Registration

DVClub membership is free and is open to all non-service provider semiconductor professionals. Most members work in verification, but there are also plenty of entrepreneurs, professors, students, managers, investors, and even design engineers who attend. Participation by service providers (solicitors) is limited to event sponsors, who supply the funds for DVClub events.

Help us plan for a proper setup and RSVP here.

10th International Workshop on Microprocessor Test and Verification (MTV 2009)
December 7-8, 2009, Hyatt Regency On Town Lake, Austin, Texas, USA.

Website: http://mtv.ece.ucsb.edu/MTV/

This is the 10th edition of the MTV Workshop, a testament to its success in providing an ideal environment for cross- examination of test and verification experiences and innovative solutions. MTV has been held in Austin for the last 8 years, so please plan on participating in order to make this another successful forum.

Purpose

The purpose of this workshop is to bring researchers and practitioners from the fields of verification and test together to exchange innovative ideas and to develop new methodologies to solve the difficult challenges facing us today in various processor and SOC design environments. In the past few years, some work has been done on exploiting techniques from test to solve problems in verification and vice versa.

Topics

AREAS OF INTEREST include, but not limited to:

• Validation of microprocessors and SOCs
• Test/Verification of multimedia processors
• Performance testing
• High-level test generation for functional verification
• Emulation techniques
• Silicon debugging
• Formal techniques and their applications
• Verification coverage
• Test Generation at the transistor level
• Equivalence checking of custom circuits
• ESL Methodology
• Virtual Platforms
• Software verification
• Circuit level verification
• Switch-level circuit modeling
• Timing validation techniques
• Path analysis for verification or test
• Design error models
• Design error diagnosis
• Design for Testability or Verifiability
• Optimizing SAT procedures with applications to testing and formal verification

Important dates

Submission: Sept 1, 2009
Notification: Oct 1, 2009
Final version due: Nov 1, 2009

Design productivity is tied to the ability to quickly generate large numbers of tests. RAVEN can be implemented in nightly test suites to continually generate hundreds of thousands of tests. Processor designs are verified with less time and effort than with alternative verification methodologies.

Fewer Respins

Obsidian can help clients eliminate costly manufacturing respins due to functional errors. Using a dynamic random test generator ensures that more of the design will be tested with better coverage, specifically around difficult to reach corner-cases. With proper deployment and training of RAVEN, verification teams can save the equivalent of one full respin for each design project.

Time-to-Market Advantage

Fully, 55% of embedded processor designs do not meet their scheduled release dates. Being first-to-market among competitors can be extremely advantageous for processor designers as revenues are typically doubled during the extra time period.

Cutting Verification Costs

If Obsidian can cut verification time by a modest 10%, the end user can claim a 5% reduction in total design costs. Based on the $50M cost of a 45nm processor, this element alone would result in a savings of $2.5M for the design project. These numbers will be higher for more complex processors and with better time savings.

This article presents an overview of functional design verification using a coverage driven methodology while attempting to answer the question of how much testing is enough. The part being verified in this case will be a general purpose microprocessor, such as those found in mobile computing devices. Note that an approach of this magnitude is not always required. Designs with very limited instruction sets or highly restricted functionalities may be satisfied by simply writing directed assembly code tests to verify their intended functionalities.

Comparison of Simple and Complex Architectures

Figure 1 depicts a simple architecture as compared to a complex one. Note that the number of corner cases and unpredictability of the verification space increases as the architecture gains complexity. Thus, the complexity of the architecture determines how much testing will need to be accomplished to properly verify the component’s function.

Figure 1. Comparison of Verification Spaces

Measuring Verification Progress

Coverage metrics are the dominant method for measuring verification progress in the industry today. Coverage points are normally designated by the design engineers looking at the logic of their block and by verification or system engineers looking at the functional definition of the part. Both of these are critical insights into the required verification coverage of the design.

Coverage points, indicated by the red dots in Figure 2, are deliberately chosen with respect to placement and density according to design knowledge and risk assessment.

Figure 2. Distribution of Coverage Points

Directed Testing VS Random Methodology

Some organizations will use only directed tests to hit coverage points. Because directed tests are by their very nature highly targeted and relatively inflexible, this results in much of the design not being tested as is shown by the ratio of red to gray in Figure 2. In addition to the low overall coverage that results from this approach, creation of directed tests is time consuming, requiring approxomately 20-30 minutes per test, and requires highly skilled engineers. In this approach, testbench checkers that detect hits to coverage points are often overlooked with the assumptions that the engineers writing the tests know how to hit the required coverage points and that human errors will not a significant problem. As the design changes over the course of RTL development, directed tests may lose track of their targeted coverage points. Without coverage monitors, these types of errors will not be detected and the design will not be as thoroughly verified as it appears to be on paper.

Using a Random Test Generator to Close Coverage

As processor designs became more complex, the need to hit more coverage points became apparent. Once the grid has been established, large numbers of purely random tests may be incorporated to begin closing coverage. Some of these tests may hit points on the coverage grid while others will not.

Figure 3. Intersection of Coverage Grid and Pure Random

Hitting Corner Cases

Approaching the problem of hitting coverage points from a random test generator viewpoint, a single engineer begins by writing a few generator templates and then generates tests using those templates. The generated tests are then run on a testbench which incorporates coverage monitors. The coverage monitors report all coverage points that are hit by the tests. As long as tests generated from the templates continue to hit new coverage points, the templates are kept in the nightly suite. As the rate of hitting new coverage points declines, new generator templates are created to target coverage holes. This approach requires skilled engineers to write checkers for the testbench but less skilled engineers to run the test generator.

Directed-random templates are created around points not hit by the purely random templates. We now begin to see the coverage grid closing more tightly (around 95%), and the verification process comes closer to completion.

Figure 4. Coverage Grid, Directed Random and Pure Random

Hitting Corner Cases

Not all coverage points will be hit by fully random or directed random templates. Some coverage points require a long series of events before the targeted behavior takes place. In this case, there are two possible approaches: write directed tests and write directed templates. Directed tests can get to these most difficult coverage points more quickly but prove only one or a few cases around that point. Directed templates take more time to create but can be written to allow as much random behavior around the coverage point as possible.

Figure 5. Review Templates and Relax Restrictions

Finally, existing tests are reviewed, and as much directed behavior as possible is removed before the tests are run again. Coverage then reaches full closure, and these tests are run until the schedule no longer permits.

This blog post originally appeared at:

http://www.chipdesignmag.com/martins/2009/03/19/bailey-on-verification-at-the-club/

— March 19, 2009 @ 11:14 pm

Today I attended the latest meeting of the Silicon Valley branch of the DVClub. For those not familiar with the DVClub (DV = Design Verification), it was started by Eric Hennenhoefer in Austin a few years ago. It now has branches in Austin, Bangalore, Boston, Bristol, Dallas, RTP, San Diego and Silicon Valley. In Silicon Valley it meets about once a quarter for a talk on some aspect of verification. I first heard of this about 1.5 years ago when we were invited from Tensilica to give a talk about verifying our video subsystem. The club has all the right ingredients to attract a crowd of engineers:

1. a free lunch
2. interesting speakers
3. did I mention a free lunch?
4. a chance to meet new colleagues and old friends
5. and of course, a free lunch

(Sponsors such as Cadence, Doulos, Denali, Silicon Elite and Obsidian pick up the tab for the venue and lunch (updated after original post, on Friday 20 March 2009, to correct list of sponsors)).

Today’s speaker was Brian Bailey, a friend and co-author of mine, speaking on “Is it time to declare a verification war?” The place was packed out with about 130 people, filling the room to capacity (Eric said this was the largest Silicon Valley DVClub crowd to date).

Brian Bailey

Brian spoke about his philosophy of verification, drew some analogies to Sun-Tzu’s Art of War, and also spoke about three technologies that he felt had potential to change verification significantly:

1. Functional Qualification – as exemplified by Certess (now SpringSoft) Certitude
2. Raising abstraction – as exemplified by Calypto’s sequential equivalence checking
3. “Intelligent testbenches” – as exemplified by Jasper’s Behavioural Indexing

Brian’s slides are available here.

IF you live or work anywhere any of these branches of the DVClub, and have an interest in verification, I recommend that you check them out. Sign up for their newsletter and get notified of meetings in advance.