Design Verification

EE295 Design Verification Ishwaki Thakkar

010734451

Design VerificationAbstractImagine that the cell phone, which is multitasking, is capturing some video and suddenly the phone rings, mobile gets crashed, and deletes the video captured. The design has the flaw and proper testing of functionality did not take place. There is a need for verification in a design. The set of all possible Test vectors tested on any design checks the functionality of each specification. For example, one application should not crash or face any problems when other situations come up. Verification is when Test inputs are given to check how the digital design or system works and to compare if it works as expected. So in an above case, the mobile should store the video captured if a phone call interrupts. The verification engineer has to go through various test input vectors to check functionality and robustness in a circuit. Hence, the need for verification comes into the picture when the system is still in a design process. This Paper provides the reader the familiarity to the Verification Process, how it is different from Testing, how many times the verification takes place in any design, where does it lie in a design flow, types of verification methodologies and its significance. The targeted audience is the students who are pursuing Digital Design course and the one who are aiming to have a basic understanding regarding verification process.

Verification is not Testing. Verification is the phase before the silicon fabrication while testing is the phase after the making of silicon, i.e. post silicon phase. Verification is to assure the product is as per specification before the actual process of making of silicon and Testing is to assure the product is as per specification after the making of silicon. So there lies a huge difference between two similar looking words.

The verification has special importance on which the economics of the whole company and success of design rely. Suppose any company is designing its own new device like a mobile phone, spending billions on various costs such as designing, prototype production, ASIC vendors’ services, the engineering cost, marketing cost, after the building of device and when tested it doesn’t work as expected, all billion dollars are a total waste. On a different note, verification engineers built simulator models that simulate the behavior of a system, the results when checked with the Hardware language like RTL results equalize with the system's behavior the system is almost perfect. The following paper is about the significance of Verification of design, where does it stay in VLSI design flow, why verification engineers over take the demand of design engineers, how verification takes place and various methodologies of verification existence of various like logic verification, functional verification, formal verification, UVM, etc.

To understand the basic of verification of any design user should understand the depth of intention and how the verification takes place. Any electronic circuit is in closed form where electrons can travel. A digital circuit is the one with discrete voltage level 0 and 1 where 0 signifies 0 volts and 1 varies according to technologies on 5V,3.3V,1.8V, if voltage levels are constant, it is an analog circuit and not the digital circuit. In any digital

1


010734451

design on base of specification, the design of a circuit or module takes place. For example, there is a 2-bit full adder circuit to check its functionality, the sum is a (or) b and the carry is a (and) b. So by giving various test inputs like 0 0, 0 1, 1 0, 1 1; the user can verify functionality of a sum and carry if the result is equal to expected output. The 2-bit adder here is a too small circuit, the real large scale system like multiple core processors, hardware embedded in a car, millions of transistors and millions of gates fabricates in mobile processors. Hence, the technique to check the complete functionality of all the Hardware when various test inputs are given to see if circuit as a component, a module and as a whole system is working as expected or not is the main agenda of verification.

Manually when the test inputs patterns given to check output it is possible to verify small circuit such as the adder by checking the operations of, but the real time designs are very complex highly integrated application like processors. So manually checking the systems consisting millions of gates and hundreds of inputs is difficult to do manually as n inputs requires all possible combinations which is 2^n and can take millions of years to test the circuit. Thus, verification requires automation like CAD tools which automate design, when the user gives specifications, the tool gives output as a final circuit and some algorithms about what patterns to apply at hardware level help to prove mathematically if the design is obeying the design specifications as desired or not. In summary, some automated tools and methodologies exist as the approach of how to verify the circuit.

Verification is not testing phase, but a design phase because Testers take system like a black box and there is no need to understand the internal structure of a system to perform Testing. In contrast, the Verification engineer needs to understand all the internal structure of a chip the way designers have designed, model the design according to its behavior, develop the test bench covering test cases such that the whole functionality of a chip along with each and every line of code is checked and passes through all the possible test vector’s possibility and combinations. I order to proceed further, User should know basic VLSI or ASIC design flow to understand the verification process and where does in lies in design flow.

2


010734451

ASIC Design Flow [1]

SpecificationsThe first step of a design phase is the specification which gives information about basic specifications of design after which implementation begins. The ASIC designer gets the specification from the customer, the specification may be power, chip area or the speed. The top level management decides the micro-architecture or sample architecture. If the design requirements are to build a full adder, the engineer decides top model units such as it requires two half adders, some standard cells. The estimation is done as per design requirements of an area, power and components required are analyzed and returned the analysis to the customer showing the results and the cost and then the design implementation phase begins.

RTL DesignWhen the engineer gets all the specifications, the design phase begins. Just like the microprocessor which consists of various blocks such as FPUs, Normal Arithmetic units, cache memories, inbuilt memories. The project lead assigns different modules to lower level engineers. The work is divided into different groups. Each group is building its own RTL level design. This is the first stage of Technology independent work. Once the design of RTL completes, the succeeding phase is simulation.

SimulationOnce the RTL is designed it is necessary to verify the functionality which needs Simulation. Simulation creates a model which finds out the control that shows the whole behavior of a system. It informs about how it will affect to the surrounding modules which shows if there is need of any change to work for the correct

3


010734451

synchronization of all units together in a module or all modules in a system. There are two versions of RTL: Synthesizable and Non-synthesizable. It is advisable to write Synthesizable code. In short, simulation is an abstract representation which predicts the future behavior of a system.

SynthesisAfter the simulation, Test vectors verify the functionality in a Synthesis process. Up to this phase of design, it was Technology Independent design. After this phase, the output resulted in this stage is Technology Dependent design. Synthesis is a three stage process: Translation, Optimization, Mapping to the Particular Technology (32nm,45nm etc.). In synthesis, the tool converts the RTL design implementation usually in Verilog or VHDL is turned into a gates, which forms vg file. Apart from that user needs to specify a constraint for the design called Synopsys Design Constraints like input delay, output delay, clock period, whether the design is leading to a multicycle path, Is there any false path, Latency and Clock Uncertainty. Design to design the constraints may vary. This constraints, user specifies in the.sdc file. When the .vg file and .sdc file is ready the next stage is Design For Testability.

Design for TestabilityIn DFT, an Engineer measures the controllability and measurability of a design. How far is the design achievable in terms of error rate? What percentage of a design is coverable is measured in DFT? The file called .atpg is formed. ATPG is Automated Test Pattern Generated file. Thus .vg, .sdc and .atpg files are formed. From simulation to DFT user need to migrate from different tools and this is not possible with one simulation. Industry standard tools for synthesis is Design Compiler from Synopsys. But considering Design For Test, Cadence is used. Up to this phase, the flow is Front-end ASIC Design. The semiconductor design process is categorized into three phases: Front end design, Back end Design and Fabrication. Different designs with EDA tools require some Data Preparation. The following phase after this is a back end.

The SoC Requirement for Back endPlace and Route and before entering to back-end user requires various data Preparation. The first input is Gate level Verilog netlist .vg from the Design Compiler. The second input is .sdc Synopsis Design constraint which synthesis tool generates. The third input to specify .Lib or library which specifies the technology user are working. To work with 45 nm technology, the user needs the library of 45 nm. The library files are usually slow lib, typical lib and fast lib having different PVTs i.e Power, voltage, and Temperature. Different libs have a different number of components. In different libraries, components are same but PVTs are different. Along with all this three input, the user requires one more information which is a library exchange format (lef) which has metal lead information, wire information, width and height of a sink, the volume of a sink. Hence, we need 4 data: .vg, .sdc, .lib with three different formats and the lef before entering the phase of back-end.

Before proceeding further to the Back-end, every process is very important in IC design as it takes too much of time and cost. Hence, it is necessary to check all the constraints and the initial stage to avoid mismatch. There are questions that come up, like whether the RTL engineer gave proper netlist, are there any floating nets or multi-cycle path nets. Such verification is done at the initial stage and there should be a unique file design which ensures that the designer did not use the same component at any other place. Each module has an instance name and should be a unique name, no copy of it should exist in a design. So check design verifies all the constraints, giving information about what is an approximate area, approximate power, the time required. When any information is wrong or has any problem user should inform the RTL engineer who will optimize and resend the final design with updated .vg gate level netlist as well as .sdc. In conclusion, the

4


010734451

design process is very delicate and should ensure precise functioning between the front-end and back-end. Once the user receives the new updated: vg and sdc time, which runs perfectly the trailing phase is Designing Phase. For understanding, the time design, user should have knowledge about the various kinds of time paths. Time design invokes the timing engine which classifies the design in a 4 different timing path.

Timing Paths [2] Point to point possible paths in a design from where data propagates from one flip-flop to another. Each path has its own start and end points on which it is classified in various path groups, on the basis of which STA creates a report. There are 4 types of Data Path: 1)I/P to Reg (Data path), 2) Reg to Reg (typical Path), 3) Reg to O/p(Data path) 4 ) A Pure Combinational path.

(1)

(2)

(3)

(4)

When all the values of 4 paths have positive slack it corresponds that there is no bug or problems with the timings. Thus, in an initial phase one has to go through check design and time design. The timing will be verified at 5 different stages which lead to the addition or deletion of components: Pre-place, Pre-CTS, Post CTS, Post Route, Post Silicon. Whenever there is any change in a design, while adding each new component

5


010734451

timing is performed so that there is no negative slack and setup or hold violation. When the user confirms the timing of a Pre-Place phase of Floor planning takes place.

Floor planningAs before buying a house, one checks the architecture and rooms to see how will they fit in their beds, cars, kitchen equipment, and accessories. Similarly, there is some specified silicon and hard macros like RAM, ROM, PLL and soft macros. The information about a number of analog and digital blocks, its placement and identification are floor planning. So Process of identifying the right place for the right component is called floor planning.

The designer should keep in notice some constraints while floor planning. Suppose while placing the macros, e.g PLL has 600 connections and 100 interconnections which talks with other module X. Hence, placing X close to PLL is important so an interconnect delay is less and timing is met. This is a significant step to take care. In a floorplan, analog and digital parts should not be together. If the RAM is placed which has some IOs, then placing the RAM very near to external IOs is important. The interconnects should be as less as possible. Also, when the analog block connects to the memory it has some pre-defined constraints as to keep it 5 microns away from the analog component. Hence, it is necessary to fulfil all the requirements of a floorplan. After the floor plan, power plan phase comes into the picture.

Power PlanSuppose there are 25k components, there are some power requirements for all components, and of a particular technology like for 180 nm the Vdd can be 1.8V. If there are 20000 components are there in a chip only ring of Vdd is enough for the chip, but if there are 1 million components in a chip one Vdd or one Vgs ring is not enough to trigger the component. To overcome this problem, there are horizontal and vertical strips inserted according to the complexity. The component instead of taking the power from Vdd and Vgs rings can take it from the stripes nearer to them. Hence, every individual component should get the power constraints as required.

6


010734451

Place DesignThe step here is the real placing of a design for a chip which is the nest stage after power plan. A Standard cell, macros or the modules from various vendors are placed onto the chip. This is called hard placement, classified as time-based or congestion-based placement. If the time is concerned an engineer applies the time-based model and if one is very much interested in an area, one should go for the congestion based model. After this phase, an engineer again performs Time Design, which is called Pre-CTS. Before Clock Tree Synthesis once again the user checks the timings and if the slack is positive, the CTS or clock tree synthesis phase takes place.

CTSThe phase in which the main aim is to obtain 0 skew. For this, one should know what is skew. [3]

The clock tree has buffers and the clock edge reach the launch flop through the buffers with a set of wires, the combinational delay requirement also changes when the clock is taken into consideration. The clock which was supposed to reach at 0 ns will now reach at a buffer 1 + buffer 2 delays.

1= Buffer1+Buffer2 delay

2= Buffer1+Buffer3+Buffer4 delay

So a clock reaching at t=0 will reach at t=0+1 similarly clock generation at T ns will be now t=T+2 Delay. So the previous clock cycle was 0 to T is now from 1 to T+2. Hence, the combinational delay requirement modifies equation to

(T + 2) - Ts - Tsu> Tcomb + 1

The difference or spatial variation in a temporarily equivalent clock edge is called skew.

7


010734451

(T+2)-Ts-Tsu > Tcomb+1

The CTS aims to optimize the skew and tries to get all clocks at the same time by either inserting delay or reducing delay. Hence, additional clock buffers and clock inverters optimize the clock path. Again, after adding additional elements, verification of timing is done, which is Post CTS. Once timing matches with positive slack the next step is Routing.

Routing

There are two kinds of Routing. One is global routing and one is detailed routing. Global Routing is When there are two locks in a design and there are multiple ways two blocks are connected and the most optimized way to connect the two modules is global routing. According to the details from the global routing, detail routing is performed. On the base of algorithms decide the best-optimized path with interconnects based on which detailed routers will place three nets 1) Signal nets 2) Power Nets 3) clock nets. Once these nets are routed, the routing is completed. Checking the timings again after the routing is called Post-Route static timing analysis checks setup and hold violations. If the timings pass successfully, the timing reports are passed to DRC engineers, who runs caliber tools test for VRC violations or net violations exist. If a net violation exists this is passed through the signal integrity engineer.

8


010734451

Signal IntegrityThere exist some problems which SI engineer solves. When the technology is less than 45 nm there exists the problems like cross talks, electromagnetism, transmission of field, ringing, noise or migration. The SI check for all such problems. After the Signal Integrity is performed, again performing the Static Timing Analysis is called Post SI timing verification. To avoid all these internal effects like cross talks, shields are inserted, so again the Post Timing analysis is performed. Once the user performs Post Timing SI there is a generation of tape out and sent to the fabrication for manufacturing, which is the last step in a design flow.

The Significance of Verification [2]Process of demonstrating functional correctness of design is called Verification. A Way in which user can measure implemented design is functionally correct with the design specification. It is necessary to verify the design. There are certain questions which are skeptical to the guarantee of design without verification. If there are incorrect specifications or insufficient specifications, the design will be interpreted wrongly, engineers can misinterpret or misunderstand the specification can lead to errors later on. The incorrect interaction between IPs and cores, especially when the design involves multiple IPs and cores when different engineer, design different IP when each engineer interprets differently and when all the IP interact with each other, it can lead to complications. If a user does not verify the result, it can lead to the unexpected behavior of a system. Hence, to avoid all the problems to ensure the functionality is correct in a system and if there is no verification all the hurdles can never lead to the functional expected design of specification.

Any bug that escapes the design process to the active silicon of a chip design can be very costly and can result to the race pin of a chip. Verifying the design consumes 70% of a design cycle is spent. As the complexity in a designs keep on increasing day by day it is very hard to make sure that the design is functionally correct to all the specification before the actual silicon is made. Hence, verification is always on the critical path for any product design.

Verification classificationThere are mainly three kinds of verification. The first is the Functional Verification which is a Process which focus more on making sure if the functionality satisfies the design specification. There are certain checks like what are the protocols implemented and verifying features that design supports. Secondly, the Timing

9


010734451

Verification Verifies if the actual timing implementation of design meets with positive slack and behaves as the expected frequency. If there is any change in a design, there is a need of repeating the timing verification to meet timings as seen previously. Performing the Pre-CTS, Post CTS, Pre-SI, etc. is hence important. Thirdly, The Performance Verification is a Process in which focus is on the actual performance goal of a design. E.g. microprocessor design expects n instruction in a cycle, hence, verifying successful execution of expected number of n instruction falls under Performance verification. If the design of memory is capable of read and write every cycle, then the actual cycle should be able to read and write every cycle.

Methods of verification In order to verify the designs there are various ways to do verification. They are as follows; Simulation based verification, Emulation/FPGA based Verification, Formal Verification, Semi- Formal verification, HW/SW Co-Verification

Verification: Planning, Matrix, Approaches [2]Verification PlanThe first step is there is a specification document for verification effort is a document that captures planning that the user executes to perform verification, which ensures to verify all the essential features. The document has all the significant features and information to verify under different conditions along with the details. Whether if the verification of features is an independent manner or in a combined manner in stress conditions. The document also captures the information about how to verify all the features and capture the details on using various Methodologies like Simulation based verification is used or other, formal verification, what are checking methods to be used, are there need to apply coverage or not. The plan also shows what kind of simulation an engineer should apply for verification, implementation of what kind of checkers are there and type of coverage. The plan also has priority for verifying features. When the complexity of design is increasing day by day with the increase in a number of features there exists a priority of one feature over another as to which features should be importantly active and which can be given lower priority. Hence the verification plan is a guide to the engineer to perform the method having all the important information.

Verification ApproachesThe verification has three approaches. First is a Black Box Verification process where the engineer does not need to have all the knowledge of design Implementation. The only information engineer should know is the features that the design supports. The design is treated like a black box during verification. There are pros and cons of this approach. The advantage is the tests are independent of implementation while the major disadvantage of a black box where an engineer doesn’t care about the design Implementation hence there is the lack of visibility and observability. In today’s world where there is high complexity the engineer deals with, it is impractical to apply the black box approach in verification where there is no need to have complete knowledge regarding design implementation. Second is White Box approach where there is a good and deep understanding of design implementation, which has the advantage of full visibility and observability. This has the advantage of an engineer to write a better test case and the stimulus to cover every feature and functionality of a design. During debug, the good observability of engineer helps in debug process. The disadvantage of a white box approach tests is bound to a specific implementation and limits the reuse of test across different project when the implementation changes. Hence, the white box testing can be a good verification approach with increased observability and visibility in comparison to the black box, but limits the reusability of a test case. Third is Grey Box approach is a grey approach which is a compromise between both

10


010734451

the approach black and white box. The engineer doesn’t need to know everything about design in depth but there are some features where the verification engineer needs to know. So the grey box is a combination of above two approaches for the specific implementation which gives advantages of a white box of visibility and observability and the advantage of a black box of reusability. Hence, the three approaches have its vivid functionality in different applications.

The Level of Verification

The diagram shows how the design is partitioned during the product design phase. Every design is partitioned into several systems, sub system, core IP block units and subunits. Design start building up from a bottom up approach. Most sub units and the units needed for the overall design to work in parallel. Once the design unit are in place are put together under core blocks and then the core blocks are put together to form sub system built to form system on chip which in turn makes system which makes a board on chip assembled.

As the design is partitioned, verification is also partitioned at each multiple levels. Each level of verification is suited for a specific objective. Lower level of verification is the verification of unit or sub unit or core IP blocks in a stand-alone environment. In a unit or subunit level there is no need to build a proper test bench or verification environment, Ad-Hoc basic operations can work like forcing certain input signals and checking the design output behavior as per the specification. The more verification an engineer does at lower level; more are the chances to find the most bugs in parallel to the design which saves the time in early level of verification. Multiple verification of such units built in a system or subsystem to the product level verification

11


010734451

takes place along with design development starting from beginning of design and focusing on different levels of verification.

Verification MatrixThe verification matrix is the matrix that helps the engineer tracks towards the completion of a plan and the quality of verification. Some matrix of them are; first, Measurements Matrix: Features to verify, a stimulus to verify, how many tests are being written, stimulator generator is written, passed tests rate, failure rates. The matrix helps engineer track towards the actual present situation to what was planned for the situation. Second, Historical trends Matrix: This matrix grows as the number of projects increases. The matrix of a project regarding the past can help the user determine how the present project is trending which can help compare the quality of a current project to the past if it is better or worse in comparison to the past project.

Verification Methods [2]Some verification methods that users most commonly used are

Simulation Based Verification

The diagram shows the design Implementation, where a software simulator surrounds the design. This is most commonly used design verification. A Test vector generator that generates an input stimulus to the design and the design under the test is simulated using the simulator. There is a golden reference model, a scoreboard or a checker to generate the output treated as golden output, which compare with the actual output coming from the design implementation to ensure the correctness of a design. Based on complexity of design implementation the test vector generation can be simple as the directed test generator or as complex as the random reconstrained test generator. Approaches like Assertion and coverage matrix ensure if verification is complete or not.

Formal VerificationFormal verification is the method through which user proves or disproves a design implementation against a formal specification or property. This method uses mathematical reasoning or algorithms to prove a design against the formal specification. It exhaustively explores all possible input values over time, exercises various state spaces of a design. This verification method works well when the designs are small and the number of inputs, outputs and states are small. With the increasing design states, the formal verification may not be that effective.

The diagram shows how the equivalence checking is done. RTLA/ GatesA is a reference or a golden design, during implementation the design is RTLB/ GatesB which is a target design which is a modified version for a

12


010734451

specific purpose or with different library, equivalence checking of A and B are done to check if they are functionally equivalent. This doesn’t guarantee both are correct with respect to each other, but guarantees two kinds of implementation remain functionally equivalent.This is another kind of implementation where another reference is checked for RTLC/ GatesC to check the equivalence of a design, here design C and B are checked.

Model checking is an another way of Formal Verification, which is commonly used is Model checking. It is a way which exhaustively search FSM for state or property violation for n state machine. This model is used when the design is mostly based on a Finite State machine. In this approach, there are two input to algorithm one of which is a finite-state transition system representing the implementation and other input is a formal property representing the specification. The engineer gives these inputs to the algorithm which exhaustively explores all the input combinations, which can violate the FSM model if it doesn’t find any input value combination that violates the finite state machine model then the system is formally verified.

This diagram explains the model checking. The FSM model is shown and the formal property is the specification of a same design which is input to the model checking model which has formal verification tools. The tool algorithmically explores all the possible input combinations for the difference in space and the

13


010734451

design and come up with the counter example and combination that can fail the design. If the model doesn’t fail for any combination it is formally verified.

There are many advantages of Formal Verification like it Covers exhaustive state space which is hard in a simulation where the user manually creates a test. There is no need to generate any input stimulus since tools automatically generate exhaustive stimulus. There is no need to generate expected output sequences like checkers, a reference, and a golden output. There is a guarantee of Correctness of a design mathematically. It has advantages but it has the disadvantages too.

The disadvantages in a formal verification method are that they are not scalable for lots of designs. With each addition of flip-flop, the state space gets doubled. Verification tools have to exhaustively cover more combination hence, it is limited to a design with small state space like the interface and small FSMs. Scalability is not obtained in Larger design. For every specification, the user needs to translate the specifications into some kind of property specification language, which is difficult as state space keeps increasing. To verify the properties holds true under all the input and state condition is difficult.

Semi-Formal VerificationThe semi-formal verification is best of both simulation and formal verification. Design with a larger specification where the formal verification cannot rely alone, the simulation method of verification is used to cover critical parts of design initially after which the user does exhaustive formal verification around those critical design to cover state space. This approach helps to cover larger design state space faster and helps to find bugs deep in a design as a result of formal verification around the critical design hence useful for bug hunting.

AssertionAssertion is a statement about a design’s intended behavior which must be verified. A way of capturing design intention or a part of a design specification in a form of property which can be used in dynamic simulation or formal verification to make sure that specific intention is met or not met.

There are many advantages of assertion based verification. It has improved Observability and debug ability because the design intention is captured in a property and user know when the specific property came across during debug. The correct usage checking improved integration, different people build multiple units, during integration of this unit into top level design, each assertion for the unit helps to ensure that at the integration level design still works properly. Improves verification efficiency, lots of time spent in debug or testing can be saved. Improves communication as it is a way of capturing in documentation. Used in both static verification as well as dynamic simulation.

There are two types of Assertion one is Immediate Assertion, which at any given time user creates assertion or property. E.g. Assert (A==B) else $error(“Wrong”); At a given point of time if A and B are not equal, then it violates the design intention, and it gives the error. The second type of assertion is Concurrent Assertion, which creates an assertion which can occur over the span of time, hence that happens at every clock. E.g.

property p1;

@(posedge clk) disable iff(Reset) not b ##1c;

endproperty

14


010734451

assert property (p1) else $error (“B ##1C failed”);

It shows property that every pos edge of clock disables if reset is not asserted and b is not 1 for one cycle than c has to be 1 for one cycle if this does not hold true, it is a failure.

Assertion Based VerificationThe assertion based verification is a method of verification where an assertion is used in Formal or Dynamic verification. In formal verification it specifies all the functional requirements and the behavior of a design. User can write all the formal properties using assertion. This method uses a procedure to prove that all the specification properties are correct. User can also use the assertion in dynamic simulation. Checkers doing simulation and specified properties can be the condition of coverage, hence the user can verify dynamic simulation conditions are met. Hence, the user can use Assertion based verification in both formal verification as well as dynamic simulation. In summary, simulation based verification is most commonly used to find bugs. User can use Formal Verification in selected areas like Finite state designs specially when the states are small. The Assertions are of significance to both design as simulation based design and formal verification.

Directed verification vs Random Verification [5]There are two ways in which verification can be performed. First, Directed Verification is the approach of a test created for directed feature or every feature in a design. If there are multiple features that have to operate in a different condition, the user has to create targeted feature each has to be operated on different condition. This approach works well when the design is in an early stage of development and is not mature when the design scope is limited, and it is possible to check each and every possible condition of a design. Second, Random Verification is an approach, where a test is not created for every feature, but the test is generated for multiple tests in a random test or random generator that creates multiple scenarios in a random manner. Both the approach has advantages and disadvantages. If the design complexity is high and the design is mature during later stages of design development, the random approach of verification is useful.

The directed Verification can only cover scenarios through thought planning, so during the verification planning stage whatever the scenario designer thinks through a test it and only the features which user can test which user think. This approach has high maintenance cost. The directed approach works well when the condition state is finite and can plan for all the test scenarios. When the design stage is huge, it is not possible to cover all the scenarios in a given time. The good part is no need for extensive coverage coding as it guarantees the test hits all the scenarios so no effort is needed to check if all scenarios are hit.

The pure random approach depends on the random test generator that can randomly hit all the scenarios. In order to make sure all the conditioned space is covered, it is necessary to run in an infinite number of cycles to ensure all state conditions is covered. The good part in this approach, there is a less user control and a user depends more on the generator which generates random scenarios.

In order not to let the generator be purely random, there is an approach which lies in between this two approach which is Constrained Random Verification which has constrained randomness to the critical scenarios to the design. This approach has the high ramp up time so the user has to understand design scenarios and code random intelligent generators. To measure constrained randomness and completeness user needs to measure coverage matrix. The good part is the approach gives deep control which can hit all

15


010734451

different state space in a design. The approach is the best balance between engineer time and the computing time, user don’t have to run too many tests and depend on too many randomness’s as it is constrained the scenarios can hit faster. This can be static or dynamic randomness which means the either built random test upfront or built intelligence in a generator dynamically creates randomness to hit more scenarios. Here constrained random is considered best for complex designs as it is not possible to create all the test scenarios and user can also not rely on pure randomness in generator to get everything out of luck.

The first diagram show percentage of functional coverage hit versus the time taken. The directed testing approach with every test case, the user can hit certain functional coverage, hence it is a step improvement till 100% coverage to hit. Whereas the constrained random approach has lots of effort to put to build the test generator. When a user may not be able to really test anything, hence it has an initial ramp up time, but once the engineer generates initial test, the user achieves quick jump. But, again, there are cases where again user doesn’t get certain scenarios which, when covered again gets a quick jump, hence this follows when the scenarios are not covered and then the quick jump. This approach can reach 100% coverage faster than the directed approach.

The second graphs also show the comparison of an engineer time versus compute cycle time spent for all the three approaches. In a process of a directed test, initially a user builds each test for every scenario, and as the time goes user builds bigger tests and hence user spends a lot of time and compute the cycle. In a completely random test, a lot of engineer time goes into coding coverages and building randomness which runs through billion cycles. Whereas directed random approach is a balance between both, where initially engineer spends lots of time to come up with constraint and coverage and then use compute cycle effectively to get better coverage. Hence, the directed random approach has relatively low engineering cost as well as compute cost

16


010734451

CoverageThe Metric or completeness of verification is called coverage. The reason to do coverage is that it is most commonly needed for complex designs. User does verification based on samples and not on the extensive verification of complete space. If there are n space it is almost impossible to run 2n possible tests to cover full space which will take n million years to complete entire verification. Hence user usually follows constrained random approach where user creates test around critical scenarios. User needs to know exactly what areas of design needs verification. There are two types of coverage which helps identify what kind of design area are verified well.

Code Coverage

This coverage gives matrix of analysis of how good the code is covered during code simulation. There are various code coverages like Statement coverage is a matrix shows how much source code user executes during different tests. Branch coverage shows weather every control structure evaluate to true or false which are branch condition. Examples are If, case, forever, for, while, loop, case statements; test covers branching conditions or not. Condition coverage gives information of coverage of weather every test covers Boolean sub-expression to true or false. Expression coverage gives the information of RHS of an assignment like x<= (not a) xor b; the coverage will give information of all combination of xor and not are covered or not. Toggle coverage covers logic node transition report. Standard toggle coverage gives information on every node transit from 0 to 1 and 1 to 0 while extended toggle coverage gives information of all the four stages of 0<->1, z<->1 and z<->0 transitions. FSM coverage gives coverage on different state transitions and different arc coverage.

Functional Coverage

Functional coverage is different than the code coverage it covers the functionality of a design under test directed from the design specification and tools cannot generate an automatic functional coverage unlike code coverage. User need to create functional coverage monitor which the tool uses to extract coverage during the simulation. This checks if all the possible DUT input operations are injected, if all the possible DUT output or functional responses seen on every output port. Internal DUT coverage of all interested design events are being verified like FIFO are full or not, DUT covers arbitration mechanisms.

The diagram shows the coverage driven verification. From a verification plan a set of matrix user creates which inform about what scenarios are to be covered and then generate random tests which user runs and collect report to ensure the coverage goals. If it meets goals the verification is complete, if not then user

17


010734451

identify what constraints didn’t meet coverage and generate new tests or re enhance test generators in order to hit all those scenarios, coverage matrix can also be enhanced to get complete verification flow this process is repeated to get complete verifications.

Latest Trends of verification [6]Hardware Accelerated Simulation/ Emulation An alternative method used specially at the higher level of verification like a system or full chip verification. This is because simulation based verification tends to slow down as the size of design increases hence when the full chip or SoC where the Design size are huge the simulation runs very slow and there is need to use alternative method. Simulators is still a simulator that runs at a host CPU which emulates the signal at every cycle or every event change in signal. At higher level as alternative, user try to move the time consuming part to the hardware. As the diagram shows the set up modules representing the design implementation and the test bench comprises all the behavior components like stimulus generators or the checkers. The most time consuming part of a simulation model is design implementation in terms of an evaluation of modules at every event change or signal change or every cycle. In this model the most time consuming modules and synthesize compile to real hardware FPGA which runs much faster on real components while still the test bench component continues to run on the Host CPU, then device some ways of communicating between the test bench components hitting on the simulator talking to the design along with the actual hardware communicating to the design. This approach gains the speed of minimum 10x to 20x.

18


010734451

Challenges There are many challenges of this method. It Improves the speed by moving hardware components to a real system like FPGA, but degrades the communication of HW-SW. If there is a communication of Hw and Sw at every event change and every event this model may not be the benefiting the speed. Abstracting HW-SW communication is at transaction level rather than at every clock cycle and that is how the communication is no more at every cycle, but at the transition boundary which helps increasing speed. This are some challenges which has to be overcome.

Hence, to overcome these challenges, Hardware emulation is used. Hardware Emulation is a full mapping of a hardware which can be the array of FPGA which is like a real target system which helps in speed up to 1000x. There are several approaches for full hardware emulation like synthesizing the test bench if it is totally synthesizable on to the emulator or setup configuration which looks like the real hardware system and to use on a real stimulus generator or real silicon testing. But in either case debug is still a challenge and may not gain full visibility on the internals of design. Usually, HW or SW co-verification or together is mostly in use.

HW/SW Co-verificationSOC design involves hardware development phase or software development phase. At a high-level user come up to a system specification as to what the system has to do which during the system design has to classify between what hardware has to do and what the software has to do. On one side for the hardware development where on the basis of specification, an engineer implements the actual design in RTL to the gates. While on other side software development based on specification like what has to go to different levels like OS and driver software and user develop a software code. This two have to be working on the real system. In both phases, hardware verification involves functional and gate level verification to ensure that the hardware is working correctly, in parallel software verification checks if it works stand alone. Traditionally user never checks if both hardware and software work correctly together before going to actual silicon. When the design complexity is increasing day by day it is becoming important to ensure if the hardware and software work together on the actual silicon to avoid silicon bugs. Hence, the HW/SW verification is becoming more and more important. CO-verification helps project complete in a short time and gain higher confidence in both HW and SW quality testing.

19


010734451

ConclusionIn this whole paper user learnt what is verification and why to do verification in SOC or chip design flow. Verification is a process by which user measures the functional correctness of a design and if it is not ensured that design is functionally correct it can lead to bugs in a silicon like race pins costing millions of dollars. Also, verification is becoming the most significant part of a design flow. Where the verification lies in the design flow like Pre-CTS, Post-CTS, Pre-Si, whenever there is a change in a design. Verification goes parallel with the design phase at unit, sub-unit, system level. Different Methods like Simulation/ Formal / Assertion-based verification is there. There was a comparison between Directed Vs Random Verification methods and how there is a way out with advantages of both the approaches as a constrained Random Verification. The reader also saw what is coverage and why the coverage is important in a random or constrained-random testing. The latest trends of Emulations like Hardware accelerated Emulations to check how the system behaves in real environment, and HW/SW co-verification and its significance for the proper synchronization and working of both hardware and software together. Hope that gave the reader basic verification concepts.

References[1]https://www.youtube.com/watch?v=Y2PQzc9Gqsw

[2] "SOC Verification Using SystemVerilog - Udemy." Udemy. Web. 10 May 2016. <https://www.udemy.com/soc-verification-systemverilog>.

[3] EE-287 Paper of How to time logic- Ishwaki Thakkar

20

https://www.youtube.com/watch?v=Y2PQzc9Gqsw

Documents

Design Verification