 |
 |
 |
 |
| |
|
Chapter 1
Overview of Front-End Tools
Circuit Design Can Be A Risky Business
In a number of companies the procedures that are used to design complex integrated circuits can be summarised as giving the people that have to use them a mixture of excitement and frustration. Designers get excited when things go well and results match or exceed their expectation levels. Equally, it is frustrating when things go wrong and additional time is required making changes to a design to meet the specification. So what can be done to ensure that every design is... right first time?
At the simplistic level there are probably at least two answers to this question. The first is to establish a set of procedures that encourage designers to apply quality standards to each stage of the design process. The second is to complement those procedures with tools that reinforce the quality standards by verifying that the design is correct at each stage of development. On paper this may sound fairly obvious and straightforward but in reality there are a number of factors that can occur to disrupt this strategy. For example, project time scales are normally very tight because a company needs to ensure its product reaches the market place before its competitor otherwise market share will be lost. This means there is probably very little time allocated for making other than minor corrections to the design. Major changes or last minute improvements to the design-specification can cause a dilemma for the project manager as a decision has to be made as to whether to incorporate the changes, and maybe miss the release date, or risk launching an inferior product.
The Front to Back Design Route
The usual sequence a designer goes through when developing an integrated circuit is shown pictorially in Figure 1-1.
In broad terms the steps can be classified as:
Stage 1.
Capturing a description of the design using a HDL (Hardware Description Language). (e.g. Verilog or VHDL.)Note: If the reader requires any background information about hardware description languages then Appendix A - On-Line Resources and Further Reading should be consulted.
Stage 2.
Simulating the design to prove that it works correctly and meets specification.Stage 3.
Logic synthesis, where the design-description is converted into a physical gate description.Stage 4.
Organising the layout of the integrated circuit to satisfy various physical and electrical constraints. (e.g. power dissipation, pin-to-pin delays, electrical loading, etc.)The remainder of this chapter will examine the problems that can occur during stages 1 and 2 and identify some tools that can help overcome these potential problems.
Starting at the front-end, the first step that needs to be performed is the design-capture of each module or design unit and development of the relevant test benches. Tools to achieve these tasks range from simple text editors through to sophisticated code/rule checkers. Graphical entry methods can also be used - especially if a design contains one or more complex finite state machines. The objective at this stage is to ensure that the syntax and semantics of the HDL code written by the designer are correct. Any coding errors not picked up at this stage will be passed through to the simulation process which could have serious consequences as undetected coding errors may cause the simulation to fail or produce spurious results. In either case the result is wasted simulation time and frustration for the designer.
Further details regarding various design capture methods and their benefits can be found in Chapter 2 - Code and Rule Checking in the Design Flow.
Once the HDL code is correct a designer can safely move onto the second stage and start the simulation process. Modules that represent self-contained parts of the design can be simulated as soon as they have been captured. Other modules, that rely on receiving signals from other parts of the design, may require a dedicated test bench to be created in order to be simulated. Alternatively the simulation of these modules could be postponed until all the other relevant and dependent modules have been captured. This approach should be avoided wherever possible because potentially untested modules are being incorporated into the design at the sub-system testing phase. The overall effect of using this particular technique will be to increase the amount of testing that needs to be done at the sub-system integration level.
It can be tempting for a designer to move on to stage 3 and start the synthesis process as soon as all the parts of the design have been successfully simulated. This is an understandable reaction because a number of designers believe that if a design simulates correctly then that means it will work correctly. This assumption is correct provided a designer has rigorously checked that all parts of the design have been fully exercised with a comprehensive or exhaustive set of test data. At the fundamental level this means establishing that all executable statements in the design have been executed and that all the decision-branches have been taken. Normally it is quite difficult for a designer to manually estimate what percentage of the design has been covered. One solution to the problem is to make use of a coverage analysis tool at this stage to help determine which parts of the design have not been covered or fully exercised. The results obtained from coverage analysis tools can be used to improve productivity and enhance quality by directing a designer to parts of the design where the coverage is poor or inadequate.
Various chapters in this manual are devoted to giving an in-depth explanation of the fundamentals of coverage analysis, the practical value of coverage analysis and the different types of measurements that can be applied to a design.
Figure 1-2 shows how HDL checking and coverage analysis can be incorporated into the first two stages of the design flow.
Handling Design Changes
One of the most time-consuming tasks a designer has to do involves making changes to a design and then checking that those changes do not adversely affect other parts of the design. Consider the situation, shown by Figure 1-3, where a suite of test benches is used to exercise different parts of a design which comprises of a set of HDL files. In reality the number of test benches that are used may run into hundreds or even thousands and may involve a considerable amount of simulation time if all the test benches were to be re-run whenever a design-change occurred.
Another factor that needs to be taken into consideration is the fact that, usually, there is a certain amount of overlap between one test bench and another. For example, although a designer will normally try to write a test bench to check a certain part of the design, it is quite possible that one test maps over parts of the design that have already been checked. This means that the majority of test benches are not normally unique unless a lot of time is devoted to planning and implementing an efficient testing strategy.
At the end of the simulation phase the information that is contained in the suite of detailed results files shows the amount of coverage that has been achieved by each test bench. Taking all the above factors into consideration it should therefore be possible to drastically reduce the amount of simulation time by selecting the test benches that are the most productive and running just those test benches.
An extremely powerful tool that can used to calculate which test benches are the most productive is the test suite optimizer. This particular tool takes the information, produced by the coverage analysis tool, and ranks that information according to which test bench produced the highest amount of coverage in the shortest simulation time. Armed with this information a designer can optimize the test suite by:
… Removing the non-productive test benches or the ones that map over parts of the design that have already been tested.
Summary
In summary, this chapter has introduced the following tools that can be used to enhance the quality and productivity of the front-end design process.
This chapter has also explained that catching and isolating coding and coverage problems early in the design cycle can dramatically reduce a project's overall development time. Also the technique whereby the results from a set of test benches are analyzed and used to identify which are the most productive ones, has been introduced as an effective method of saving valuable simulation time. Each of these topics is described in greater detail and related to actual worked examples in the various chapters that follow.
|
|