The Concept of Electronic Design Automation:Implementation and Verification

Implementation and Verification

Every step of an ASIC design flow can be categorized as either implementation or verification. In this section we will work out a better understanding of those terms.

Implementation is always a creative process. Within the context of ASIC development, the result of an implementation step will be one of the representations listed in section 2.2. This can be the creation of a specification, an RTL model, or a gate level netlist as well as the creation of a test program. In general, implementation is the transformation of a more abstract level into a lower, more detailed level.

An implementation task will always be ambiguous. The number of solutions for modeling the multiplier of Section 2.2.3 in RTL is virtually un- limited. The reverse operation, the transformation into a higher, more abstract level, must be unique. In our example the RTL model has to show a multiplier behavior. Assume we had initialized the loop counter in Figure 2.3 to zero and have it increment in each clock cycle. The result of the whole sequence (16 cycles) would be:

(reversed bit order)

and would not meet the requirements.

Now we bring up the definition for verification:

Verification is the task to verify a previous im- plementation step.

Whilst the human genius can efficiently carry out the implementation tasks, we tend to be blind to mistakes we have made before. Data volumes in ASIC design have grown beyond any limit that could be overseen; therefore powerful tools are needed for verification. Traditionally simulators have been used for verification tasks. In the previous example we can use a VHDL simulator and choose arbitrary values for A and B and find out whether the expected result of A · B can be found in result register C after the 16th clock cycle. However, even if we find a match would we know whether the circuit works for other input values as well? To be very sure we would have to repeat the simulation for all possible input combinations. This requires us to simulate 65 536 · 65 536 different multiplication operations. Since each multiply operation requires 16 clock cycles, no less than 66 · 109 clock cycles would be necessary. A powerful VHDL simulator may simulate 1000 cycles per second and would then need approximately 2 years for an exhaustive verification. Very frustrating, indeed.

The previous conclusion tells us that we cannot achieve exhaustive verification by means of simulation. Therefore we need to select a set of vectors which is capable of detecting all potential errors. The selection of the vectors and the evaluation of simulation results can be very time consuming. For a typical ASIC project more time and resources will be spent on verification than implementation.

An ideal design flow provides for a verification step after each implementation.

It is also meaningful to perform small – local – verification runs during an implementation task to un- cover obvious mistakes. It is of utmost importance, however, to perform a comprehensive verification after each of the implementation steps mentioned in sections 2.2.2 up to 2.2.6. Usually verification is a comparison relative to the previous, more abstract level. If an error introduced at an implementation step is not immediately detected at the subsequent verification step, the implementation result will become the reference for the next implementation and verification steps. This would eventually lead to faulty masks, and the resulting chip would not work properly. A redesign step would become necessary and generate a huge cost overhead. However, real life has shown that things can become even worse:

In 1995 it became known that the core of the Pentium processor – in those days the working horse of more than 80 % of all PCs shipped – under very rare circumstances would generate incorrect results. Because the error happens so infrequently the manufacturer of the chip, Intel Corporation, had not discovered it. Once that flaw had been un- covered, the message was spread among PC users. Finally, Intel offered to replace every affected chip. The cost of that operation is said to have been in the order of 100 million US$.

Comments

Post a Comment

Popular posts from this blog

Design using Standard Description Languages:The simulation model in VHDL

Image
The simulation model in VHDL After a look at concurrent signal statements in chapter 4.3, basic mechanisms of the language can be discussed in detail. Originally the language VHDL was developed for simulation only. A dis- cussion about the theory of operation of a VHDL simulator helps to understand VHDL modelling and simplifies the choice of suitable language constructs to describe hardware constructs. The topic simulation model has an emphasis on: • Driving signals; • Delta delay mechanisms; • Modelling of delay times. Drivers Every concurrent statement, including processes, causes an event responsible for the progress of a signal. Within the simulator there is a list containing points in time to schedule signal events. Such an entry in that list is called a transaction. This list is the basic information for scheduling signal values during simulation (fig. 4.22). A change of a signal value caused by an entry in that list, is called an event in that signal. If a new entry is the ...
Read more

EDA Tutorial:Place and Route in a Standard Cell Design Style

Image
Place and Route in a Standard Cell Design Style In the design of FPGA circuits, after the synthesis of the EDIF files, the compiling and programming of the FPGA device, everything is defined and the component is completely configured. With ASIC designs, there are two possible scenarios: • Delivery of the design to an ASIC provider in the form of a so called simulate d netlist (EDIF); • Place and Route of the design with one’s own tools, verification of the results, and delivering of the design as a geometrically exact GD S II File . For similar designs in industry the netlist version is frequently chosen, but here the second scenario which includes the bac k en d processing , the phys- ical design, will be demonstrated in more detail. This needs special software tools, which allow the mask design at the lowest geometry level, and tools for checking the generated geometries against the predefined design rules ( Desig n Rule Che c k , DRC ), and allow one to extract parasitics and el...
Read more

Overview of EDA Tools and Design Concepts:Major Classes of EDA Tools.

Image
Introduction In the next few chapters, we will discuss specific kinds of EDA tools. In this chapter, we provide an overview of the EDA tool world. There are several EDA-related concepts which are helpful to understand the EDA tools and the design process. These include: Design Views Hierarchy Design Chip Architecture Methodology Design Flow Tool Suites Nora of Sandbox, Inc., is meeting again with Andrea, an ASIC engineer who works for Fabless Design, Inc. Nora has asked to learn more about the use of EDA tools. Let us listen in on their discussion. Nora: Hello again, Andrea. Did you like the party the other evening? Andrea: Yes, very much. Sandbox has both outstanding tools and great parties. Nora: We seem to be continually developing new tools. I am a little unclear why that is. Tool Improvements Andrea: That's because each generation of semiconductor process improvements shrinks the size of the transistors and wires. The number of transistors and wires...
Read more