Interview Questions Q1. FIFO depth, given read and write rates for a burst of x writes Q2. a=0; b=0; c=1; #1 a=c; #1 b =a; (Give waveforms) Q3. a<=0; b<=0; c<=1; #1 a<=c; #1 b< =a; (Give waveforms) Q4. a=0; b=0; c=1; a= #1 c; b=#1 a; (Give waveforms) Q5. a<=0; b<=0; c<=1; a<= #1 c; b<=#1 a; (Give waveforms) Q6. You have incoming bit stream. You can't store them. You get a new bit at everyclock edge, find modulo 5 of the updated number everytime. Eg, if bitstream is 10111, you find modulo of 1, then 10, then 101 and so on..
FIbonacci series Questions on C++, Perl, System Verilog.
Computer Architecture Concepts, Memory Consistency and Cache Coherency, cache configuration.
difference between non-blocking and blocking assignment How to verify asynchronous fifo? How to implement a greedy snake game? — what data structures to implement the snake
In a certain protocol why the ready signal is inout instead of out? About the refresh in DDR2 FSM System Verilog, Verilog, C, Perl, (also questions about OOP)
Bit operation
Asked to write write SystemVerilog SystemVerilog constraints constraints for a variety of random stimulus stimulus needs needs What is verification about? What are the components of design verification? What is coverage? coverages types? setup and hold time aptitude based questions(apples and oranges) perl scripting and programming based questions Write code for a UVC mimicing a memory . Reactive sequence in UVM Explain how an out-of-order processor works? How do you implement register renaming? Difference between an architectural and physical register file Verilog code writing, simple hardware design question using muxes and counter that was approached from different levels of abstraction. Entirely computer architecture questions, including cache coherency protocols, cache organizations o rganizations
What is the scope of a static variable? Given multiple scenarios(static variables across files, in recursion, ect.)
Describe what a virtual function does? What are some ways for error testing/handling in software?
Computer Architecture stuff: OOO, memory dependencies, Pipelining, Fetch stage, Branch Prediction
System Verilog: coverage and assertion writing Digital Logic: Implement AND and OR using 2:1 mux Asked to rate rate myself myself in C++, System System Verilog
C program to sort array. Binary search vs Linear Search. Time complexity.
How to verify many design scenarios. difference of Union and Struct (C++).
VIPT cache.
What is an isolation cell? FIFO Depth, SV assertions, Multi-threading and OOP concepts
1
Random number generations, assertions, constraint
Bug scenarios scenarioshttp://hwinterview.com/index.php/2016/11/01/bug-scenarios/ Synchronous FIFO verification
http://hwinterview.com/index.php/2016/11/13/synchronous-fifo-verification/
SystemVerilog Assertions http://hwinterview.com/index.php/2016/11/04/assertions/ Coverage-driven verification http://hwinterview.com/index.php/2016/10/29/coverage-driven-verification/ Fork join statements http://hwinterview.com/index.php/2016/11/16/fork-join-statements/ Virtual Memory http://hwinterview.com/index.php/2016/11/20/virtual-memory/ Virtual Address Space / Paging http://hwinterview.com/index.php/2016/11/20/virtual-address-space-paging/ Design a Cache addressing scheme http://hwinterview.com/index.php/2016/11/20/design-cache-addressing-scheme/ Virtual Address Space / Paging http://hwinterview.com/index.php/2016/11/20/virtual-address-space-paging/
2
Random number generations, assertions, constraint
Bug scenarios scenarioshttp://hwinterview.com/index.php/2016/11/01/bug-scenarios/ Synchronous FIFO verification
http://hwinterview.com/index.php/2016/11/13/synchronous-fifo-verification/
SystemVerilog Assertions http://hwinterview.com/index.php/2016/11/04/assertions/ Coverage-driven verification http://hwinterview.com/index.php/2016/10/29/coverage-driven-verification/ Fork join statements http://hwinterview.com/index.php/2016/11/16/fork-join-statements/ Virtual Memory http://hwinterview.com/index.php/2016/11/20/virtual-memory/ Virtual Address Space / Paging http://hwinterview.com/index.php/2016/11/20/virtual-address-space-paging/ Design a Cache addressing scheme http://hwinterview.com/index.php/2016/11/20/design-cache-addressing-scheme/ Virtual Address Space / Paging http://hwinterview.com/index.php/2016/11/20/virtual-address-space-paging/
2
What are the goals of a verification engineer?
Develop a testplan to define the what, where and how of testing methodology. Design a resusable and scalable testbench environment to verify the module. Work with the designer to ensure that the design meets all the specifications through coverage analysis. analysis. Start debugging with the mindset that the testbench is incorrect. Once that is ruled out, then t he designer can be involved in the debug effort. Automate the checking checking process. Gain a good grasp of the design specifications. The verification engineer should not completely trust the designer to determine if the design has b een documented correctly. Suggest changes once a reasonable understanding is obtained to re-design or re-evaluate if a particular logic is constantly seeing issues. The verification engineer should not be afraid to push for changes keeping verification schedules in mind.
What is a tes testpl tplan? an? A testplan is the probably the most crucial aspect of the design verification flow. It involves the definition of the following aspects in general – Engineers involved in designing and verifying the module Module features to be verified based on the design specification Environment used for testing ( unit/system/emulation) Schedule Description of how to go about the task of thoroughly verifying the module
B ene enefits fits of a g ood testpl testpla an A good testplan sets the ground work for focusing on the important features to be verified. It also provides a framework for evaluating the progress of verification t hrough functional coverage. coverage. Furthermore, it provides a good opportunity to hash out any misunderstandings on features and interfaces. Thus, a review can be held by all the stakeholders involved in the module (design, block verification, system verification, architecture) to clearly define the methodology for testing. What s hould be in a testplan? Testbench description – A brief overview (maybe a diagram) of the testbench components used like scoreboards/checkers scoreboard s/checkers and agents. Also, a description of the testbench files should be beneficial for anyone new to the module to grasp the testbench intent. Features – The testplan should list the feature specifications and map them to a specific coverpoint. It is also crucial to focus on the interfaces of the block as these are the usual spots to uncover bugs. Another aspect is to provide the scenarios of how the end product will be used by the system. How to test? – The how of testing should cover the following – o High risk areas o Scope of what should be covered in the future o Assumptions o Test fail criteria
To achieve successful testing:
1. The testbench must generate proper input stimulus to activate a design error. 2. The testbench must generate proper input stimulus to propagate all all effects resulting from the design error to an output port. port. 3. The testbench must contain a monitor that can detect the design error that was first activated activated then propagated to a point for detection.
3
Circular Buffer Implementation
reg
[15:0] myMemory
[0:1023];
// Port A wire [9:0] addressA; wire [15:0] dataInA; wire writeEnableA; reg [15:0] dataOutA; // Port B wire [9:0] addressB; wire [15:0] dataInB; wire writeEnableB; reg [15:0] dataOutB; always @ (posedge clk) begin if (writeEnableA) begin myMemory[addressA] <= dataInA; dataOutA <= dataInA; end else dataOutA <= myMemory[addressA]; if (writeEnableB) begin myMemory[addressB] <= dataInB; dataOutB <= dataInB; end else dataOutB <= myMemory[addressB]; end
Comparing Gray code pointers to binary pointers Binary pointers can be used to do FIFO design if the pointers are sampled and handshaking control signals are used between the two clock domains to safely pass the sampled binary count values. Some advantages of using binary pointers over Gray code pointers: • The technique of sampling a multi-bit value into a holding register and using synchronized handshaking control signals to pass the multi-bit value into a new clock domain can be
used for passing ANY arbitrary multi-bit value across clock domains. This technique can be used to pass FIFO pointers or any multi-bit value. • Each synchronized Gray code pointer requires 2n flip-flops (2 per pointer bit). The sampled multi-bit register requires 2n+4 flip-flops (1 per holding register bit in each clock
domain, 2 flip-flops to synchronize a ready bit and 2 flip-flops to synchronize an acknowledge bit). There is no appreciable difference in the chance that either pointer style would experience metastability. • The sampled multi-bit binary register allows arbitrary pointer changes. Gray code pointers can only increment and decrement. • The sampled multi-bit register technique permits arbitrary FIFO depths; whereas, a Gray code pointer requires power-of-2 FIFO depths. If a design required a FIFO depth of at
least 132 words, using a standard Gray code pointer would employ a FIFO depth of 256 words. Since most instantiated dual-port RAM blocks are power-of- 2 words deep, this may not be an issue. • Using binary pointers makes it easy to calculate “almost-empty” and “almost-full” status bits using simple binary arithmetic between the pointer values.
One small disadvantage to using binary pointers over Gray code pointers is: • Sampling and holding a binary FIF O pointer and then handshaking it across a clock boundary can delay the capture of new samples by at least two clock edges from the receiving
clock domain and another two clock edges from the sending clock domain. This latency is generally not a problem, but it will typically add more pessimism to the assertion of full and empty and might require additional FIFO depth to compensate for the added pessimism. Since most FIFOs are typically specified with excess depth, it is not likely that extra registers or a larger dual-port FIFO buffer size would be required.
4
ASSERTIONS An assertion is a statement about a design’s intended behavior - If a property that is being checked for in a simulation does not behave the way we expect it to, the assertion fails. - If a property that is forbidden from happening in a design happens during simulation, the assertion fails. - It helps capturing the designer’s interpretation of the specification. - Describes the property of the design - Assertion doesn’t help in designing any entity but it checks for the behavior of the design.
assert property (@(posedge clk) $rose(req) |-> ##[1:3] $rose(ack)); In this example, when there is a positive edge on the Request (req) signal, then make sure that between 1 and 3 clock cycles later, there is a positive edge on acknowledge (ack) signal. Here the designer knows that the acknowledge signal should go high within 1 to 3 cycles as soon as the Request signal has gone high at the positive edge.
Immediate assertions ‐ uses the keyword assert (not assert property), and is placed in procedural c ode and executed as a procedural statement. - Based on simulation event semantics. - Test expression is evaluated just like any ot her. Verilog expression with a procedural block. Those are not temporal in nature and are evaluated immediately. - Have to be placed in a procedural block definition. - Used only with dynamic simulation A sample immediate assertion is shown below: always_comb begin a_ia: assert (a && b); end Concurrent assertions ‐ uses the keywords assert property, is pl aced outside of a procedural block and is executed once per sample cycle at th e end of the cycle. The sample cycle is typically a posedge clk and sampling takes place at the end of the clock cycle, just before everything changes on the next posedge clk. - Based on Clock Cycles. - Test expression i s evaluated at clock edges based on th e sampled values of the variables involved. - Sampling of variables is done in the “ observed region” of the scheduler. - Can be placed in a procedural blo ck, a module, an interface or a program definition. - Can be used with bot h static and dynamic verification tool. A sample of Concurrent Assertion: a_cc: assert property ( @ (posedge clk) not (a && b)) ; This example shows the result of concurrent assertion a_cc. All successes are shown with an up arrow and all features are shown with a down arrow. The key concept in th is example is that property being verified on every positive edge of the clock irrespective of whether or not signal “a” and signal “b” changes.
Embedded concurrent assertions ‐ another form of concurrent assertions added to IEEE Std 1800‐2009[7] and also uses the keywords assert property but is placed inside of a clocked always process. Placing the assertion in a clocked always process allo ws the concurrent assertion to inheritthe clocking‐sample signal from the always process.
Design Engineers should create the low‐level and simple assertions while Verification Engineers should create higher‐level and perhaps more complex
assertions.
Where should the Assertions be used? - Between modules, DUT and Testbench to check communication between the modules and stimulus constraints. - It can also be used inside individual modules to verify the design, corner-cases and verify the assumptions.
Bindfiles:
assertions should instead be put in a separate bindfile and NOT put the assertions in the RTL code.
How bindfiles work : In general, using bindfiles is actually doing indirect instantiation. The engineer will bind (indirectly instantiate) one module inside of another module using the bind keyword. To create a bindfile, declare a module that will encapsulate the assertion code (and other verification code if needed). The module needs access to all of the important signals in the enclosing file so all of the ports and internal signals from the enclosing file are declared as inputs to the bindfile. the bind command includes the bind keyword followed by the DUT module name bind fifo1 describes how the bound module would be instantiated if placed directly in the module being bound to. fifo1_asserts p1 (.*); When creating bindfiles, it is a good idea to copy the DUT module to a DUT_asserts module, keep all existing input declarations, change all output declarations to input declarations, and declare all internal signals as input declarations to the bindfile. The bindfile will sample the port and internal signals from the DUT.
It is not required to list all of the DUT signals in the asserts file, only those signals that will be checked by assertions; however, it is highly recommend to add ALL of the DUT signals to the asserts file because it is common to add more assertions in the future that might require previously unused DUT signals.
5
The SystemVerilog language
provides three important benefits over Verilog . 1. Explicit design intent – SystemVerilog introduces several constructs that allow you to explicitly state what type of logic should be generated. 2. Conciseness of expressions – SystemVerilog includes commands that allow you to specify design behavior more concisely than previously possible . 3. A high level of abstraction for design – The SystemVerilog interface construct facilitates inter module communication. These benefits of SystemVerilog enable you to rapidly develop your RTL code, easily maintain your code, and minimize the occurrence of situations where the RTL code simulates differently than the synthesized netlist. SystemVerilog allows you to design at a high level of abstraction. This results in improved code readability and portability. Advanced features such as interfaces, concise port naming, explicit hardware constructs, and special data types ease verification challenges.
Basic Testbench Functionality
The purpose of a Testbench is to determine the correctness of t he design under test (DUT). The f ollowing steps
accomplish this. • Generate stimulus • Apply stimulus to the DUT • Captures response • Check for correctness • Measure progress against overall verification goals
Classes System Verilog provides an object-oriented programming model. System Verilog classes support a single-inheritance model. There is no facility that permits conformance of a class to m ultiple functional interfaces, such as the interface feature of Java. System Verilog classes can be type-parameterized, providing the basic function of C++ templates. However, function templates and t emplate specialization are not supported. The polymorphism features are similar to those of C++: the programmer may specify write a virtual function to have a derived class gain control of the function. Encapsulation and data hiding is accomplished using the local and protected keywords, which must be applied to any item t hat is to be hidden. By def ault, all class properties are public. System Verilog class instances are created with the new keyword. A constructor denoted by function new can be defined. System Verilog supports garbage collection, so there is no facility to explicitly destroy class instances.
Program Block – Encapsulates Test Code A program can call a routine in a module to perform various actions. The routine can set values on internal signals, also known as “back- door load.” Next, because the current SystemVerilog standard does not define how to force signals from a program block , you need to write a task in the design to do the force, and then call it from the program.
The Program block provides - Entry point to test execution
- Scope for program-wide data and routines
- Race-free interaction between Testbench and design
Why ‘always’ Blocks Not allowed in a Program Block?
In System Verilog, you can put an init ial blocks in a program, but not always blocks. This is bit opposite to the verilog and we have the reasons below: - System Verilog programs are closer to program in C, with one entry point, than Verilog’s many small blocks of concurrently executing hardware. - In a design, always block might trigger on every positive edge of a clock from the start of simulation. In System Verilog, a Testbench has the steps of initialization, stimulate and respond to the design and then wrap up the simulation. An always block that runs continuously would not work in System Verilog.
The Interface
It is the mechanism to connect Testbench to the DUT just named as bundle of wires (e.g. connecting two hardware unit blocks with the help of physical wires). With the help of interface block: we can add new connections easily, no missed connections and port lists are compact. It also carries the directional information in the form of Modport (will be explained in counter example) and clocking blocks. The interface instance is to be used in program block, the data type for the signals should be logic. The reason is that sign als within a program block are almost always driven within a procedural block(initial). All signals driven within a procedural block m ust be of type reg, the synomn of which is logic. When a signal is declared to be logic, it can also be driven by a continuous assignment statement. This added flexibility of logic is generally desirable. There is an exception to the above recommendation. If the signal is bi-directional signal(inout), or has m ultiple drivers, then the data must be wire (or any other form of wire-types). TIP: Use wire type in case of m ultiple drivers. Use logic type in case of a single driver.
How do we achieve Synchronous Timing for different modules? Clocking Blocks - A clocking block assembles signals that are synchronous to a particular clock, and makes their timing explicit. A clocking block (CB) specifies clock signals and the timing and synchronization requirements of various blocks. A CB is helpful in separating clocking activities of a design from its data assignments activities an d can be used in test benching. - A CB assembles all the signals that are sampled or synchronized by a common clock and defines the timing behaviors with respect to the clock. It is defined by a clocking – endclocking keyword pair - A CB only describes how the inputs and outputs are sampled and synchronized. It does not assign a value to a variable. - Depending on the environment, a Testbench can contain one or more clocking blocks, each containing its own clock plus an arbitrary number of signals. Clocking Block Example: clocking cb @ (posedge clk) default input #1ns output #1ns; output reset_n; output din; output frame_n; output valid_n; input dout; input busy_n; input valido_n; input frameo_n; endclocking: cb
An interface encapsulates the communication between DUT and Testbench including - Connectivity (signals) information (modports)
– named bundle of wires
- Timing (Clocking blocks)
- One or more bundles to connect - Can be reduced for different tests and devices - Functionality (routines, assertions, initial/always blocks)
- Directional
Solves many problems with traditional connections - Port lists for the connections are compact - No missed connections - Easy to add new connections - New signals in the int erface are automatically passed to test program or module, preventing connection problems. - Changes are easily made in interface making it easy to integrate in higher levels - Most port declaration work is duplicated in many modules. - And most important is easy to change if design changes.
An interface cannot contain module instances, but only instances of o ther interfaces.
The advantages to using an interface are as follows: - An interface is ideal for design reuse. When two blocks communicate with a specified protocol using more than two signals, consider using an interface. - The interface takes the jumble of signals that you declare over and over in every module or program and puts it in a central location, reducing the possibility of misconnecting signals. - To add a new signal, you just have t o declare it once in the interface, not in higher-level modules, once again reducing errors. - Modports allow a module t o easily tap a subset of signals form an interface. We can also specify signal direction for additional checking
6
Modport. This provides direction information for module interface ports and controls the use
of tasks and functions within certain modules. The directions of ports are those seen from the perspective module or program. - Modports do not contain vector sizes or data t ypes (common error) – only whether the connecting module sees a signal as input, output, inout or ref port.
Module Top: This file carries the top-level image of your whole design showing all the modules connected to it and t he ports being used for the design. The interface and test programs are instantiated here in t he harness files. Looking at into a top level harness files gives an detailed picture of any design, as to what are the functional parameters, interfaces etc.
Descriptions of some of the intermediate blocks Environment contains the instances of the entire verification component and Component connectivity is also done. Steps required for execution of
each
component are done in this.
Coverage - Checks completeness of the Testbench. This can be improved by the usage of Assertions, which helps to check the coverage of the
Testbench and generate suitable reports of the test coverage. The concept of coverage can get more complex, when we deal with t he concept of functional coverage, cover groups and cover points. With the coverage points, we can generate coverage report of your design and know the st rength of your verification.
Transactors – Transactor does the high level operations like burst-operations into individual commands, sub-layer protocol in
layered protocol like PciExpress Transaction layer over PciExpress Data Link Layer, TCP/IP over Ethernet etc. It also handles the DUT configuration operations. This layer also provides necessary information to coverage model about the stimulus generated. Stimulus generated in generator is high level like Packet is with good crc, length is 5 and da is 8h0. This high level stimulus is converted into low-level data using packing. This low level data is just a array of bits or bytes. Creates test scenarios and tests for the functionality and identifies the transaction through the interface.
Drivers - The drivers translate the operations produced by the generator into the actual inputs for the design under verification. Generators create inputs at a high level of abstraction namely, as transactions like read write operation. The drivers convert this input into actual design inputs, as defined in the specification of the designs interface. If the generator generates read operation, then read task is called, in that, the DUT input pin "read_write" is asserted.
Monitor – Monitor reports the protocol violation and i dentifies all the transactions. Monitors are two types, Passive and active. Passi ve monitors do not drive any signals. Active monitors can drive the DUT signals. Sometimes this is also referred as receiver. Monitor converts the state of t he design and its outputs to a transaction abstraction level so it can be stored in a 'score-boards' database to be checked later on. Monitor converts the pin level activities in to high level.
Checker: The monitor only monitors the interface protocol. It doesn't check the whether the data is same
as expected data or not, as i nterface has nothing to do with the data. Checker converts the low level data to high-level data and validated the data. This operation of converting low-level data to high-level data is called Unpacking, which is reverse of packing operation. For example, if data is collected f rom all the 15 comm ands of the burst operation and then the data is converted in to raw data, and all t he sub fields information are extracted from the data and compared against the expected values. The comparison state is sent to scoreboard The Generator, Agent, Driver, Monitor and Checker are all classes, modelled as Transactors. They are instantiated inside the Environment class. For simplicity, the test is at the top of the hierarchy, as is the program that instantiates the Environment Class. The functiona l coverage definition can be put inside or outside the Environment class.
Scoreboard : Scoreboard is used to store the expected output of the device under test. It implements the same functionality as DUT. It uses higher level of constructs. Dynamic data types and dynamic memory allocations in SystemVerilog make us easy to write scoreboards. Scoreboard is used to keep track of how many transactions were initiated; out of which how many are passed or failed.
Randomization : What to randomize, the first things you may think of are the data fields. These are the easiest to create – just call $random. The problem is that this approach has a very low payback in terms of bugs found: you only find data-path bugs, perhaps with bit-level mistakes. The test is still inherently directed. The challenging bugs are in the control logic. As a result, you need to randomize all decision points in your DUT. Wherever control paths diverge, randomization increases the probability that you’ll take a different path in each test case .
7
Difference between rand and randc? The variables in the class can be declared random using the keywords: rand and randc. Dynamic and associative arrays can be declared using rand or randc keywords. Variables declared with rand keywords are standard random variables. Their values are uniformly distributed over their range. Values declared with randc keyword are randomly distributed. They are cyclic in nature. They support only bit or enumerated data types. The size is limited.
Semaphores A semaphore allows you to control access to a resource. Semaphores can be used a testbench when you have a resource, such as a bus, that may have multiple requestors from inside the testbench but, as part of the physical design, can only have one driver. I n System Verilog, a thread t hat requests a key when one is not available always block. Semaphores can be used in a testbench when you have a resource, such as a bus, that may have multiple requestors from inside the testbench but as part of the physical design, can only has one driver. There are three basic operations for a semaphore. We create a semaphore with one or more keys using the new method get one or more keys with get, and return one or more keys with put.
Mailboxes : A mailbox is a communication mechanism that allows messages to be exchanged between processes or threads. Data can be sent to
a mailbox by one process and retrieved by another. Mailbox is a built-in class that provides the following methods: - Create a mailbox: new() - Place a message in a mailbox: put() - Try to place a message in a mailbox without blocking: try_put() - Retrieve a message from a mailbox: get() or peek() - Try to retrieve a message from a mailbox without blocking: try_get() or try_peek() - Retrieve the number of messages in the mailbox: num(). Eg: Generator using mailboxes task generator(int n, mailbox mbx); Transacion t; repeat (...) begin t = new(); ..... mbx.put(t); end endtask
Tasks and Functions Task and Function declarations are similar as in Verilog but following rules hold good for system verilog. • Any port is seen as input default port direction, unless explicitly declar ed as other types.Eg: in, out, inout, ref. • Unless declared, data types of ports are of logic type. • There is no need to use begin..end when more then one statement is used inside a task. • A task can be terminated before endtask, by usage of return s tatement. • Wire data type cannot be used inside the port list.
8
what is coverage? Simply put, coverage is a
metric we use t o measure verification progress and completeness. Coverage
metrics tells us what portion of the design has been activated during simulation (that is, the controllability quality of a testbench). Or more importantly, coverage metrics identify portions of the design that were never activated during simulation, which allows us to adjust our input stimulus to improve verification.
Coverage-driven verification Coverage-driven verification is a widely used methodology to tackle the growing complexity of ASIC designs which add new features and improve performance with every product generation. It typically involves the following steps – 1. Development of a test plan incorporating the list of features to verify. 2. Creation of a smart environment with configurable parameters, random constrained stimulus, checkers and a coverage model to t rack progress. 3. Addition of assertions to catch illegal scenarios. 4. Iteratively run simulations and analyze coverage metrics (code coverage and functional coverage).
Benefits Coverage-driven approach provides measurable success parameters through coverage metrics. This is crucial especially with the tough schedules to meet. In addition, using constrained random stimulus eliminates the time spent creating directed tests.
Why not use simple directed tests? Directed tests are not reusable across multiple environments. They are not scalable since they require a substantial effort to develop. Subsequently, they are inefficient as compared to a constrained random approach. Most of all, it is hard to pinpoint the completeness of verification through directed testing.
Are there any drawbacks? Coverage-driven approach requires a significant amount of planning and effort to develop which may not be necessary for simple standalone designs. Furthermore, some scenarios are unlikely to occur using a constrained random stimulus. It could be beneficial to write specific directed tests for hard-to-hit coverage holes.
Coverage Classification Two most common ways are to classify them by either their method of creation (such as, explicit versus implicit ), or by their origin of source (such as, specification versus implementation). For instance, functional coverage is one example of an explicit coverage metric, which has been manually defined and then im plemented by the engineer. In contrast, line coverage and expression coverage are two examples of an implicit coverage metric since its definition and implementation is automatically derived and extracted from the RTL representation.
Coverage Metrics There are two primary forms of coverage metrics in production use in industry today and these are: Code Coverage Metrics (Implicit coverage) Functional Coverage/Assertion Coverage Metrics (Explicit coverage)
Code Coverage Metrics One of the advantages of code coverage is that it automatically describes the degree to which t he source code of a program has been activated during testing-thus, identifying structures in the source code that have not been activated during testing. One of the key benefits of code coverage, unlike functional coverage, is that creating the structural coverage model is an automatic process. Hence, integrating code coverage into your existing simulation flow is easy and does not require a change to either your current design or verification approach.
Limitations: One limitation with code coverage metrics are that you might achieve 100% code coverage during your regression run, which means that your testbench
provided stimulus that activated all structures within your RTL source code, yet there are st ill bugs in your design. For exam ple, the input stimulus might have activated a line of code that contained a bug, yet the testbench did not generate the additional required stimulus that propagat es the effects of the bug to some point in the testbench where it could be detected. Another limitation of code coverage is that it does not provide an indication on exactly what functionality defined in the specification was actually tested. For example, you could run into a situation where you achieved 100% code coverage, and then assume you are done. Yet, there could be functionality defined in specification that was never tested?or even functionality that had never been implemented! Code coverage metrics will not help you find these situations.
9
Types of Code Coverage Metrics Toggle Coverage Toggle coverage is a code coverage metric used to measure the number of tim es each bit of a register or wire has t oggled its value. Although
this is a relatively basic metric, many projects have a t esting requirement that all ports and registers, at a minimum, must have experienced a zero-to-one and oneto-zero transition. In general, reviewing a toggle coverage analysis report can be overwhelming and of litt le value if not carefully focused. For example, toggle coverage is often used for basic connectivity checks between IP blocks. In addition, i t can be useful to know that m any control structures, such as a one-hot select bus, have been fully exercised. Line Coverage Line coverage is a code coverage metric we use to identify which lines of our source code have been executed during simulation. A line coverage
metric report will have a count associated with each line of source code indicating the total number of t imes the line has executed. The line execution count value is not only useful for identifying lines of source co de that have never executed, but also useful when the engineer feels that a minimum line execution threshold is required to achieve sufficient testing. Line coverage analysis will often reveal that a rare condition required to activate a line of code has n ot occurred due to missing input stimulus. Alternatively, line coverage analysis might reveal that the data and control flow of the source code prevented it either due to a bug in the code, or dead code that is not currently needed under certain IP configurations. For unused or dead code, you m ight choose to exclude or filter this code during t he coverage recording and reporting steps, which allows you to focus only on the relevant code. Statement Coverage Statement coverage is a code coverage metric we use to identify which statements within our source code have been executed during
simulation. In general, most engineers find that statement coverage analysis is more useful than line coverage since a statem ent often spans multiple lines of source code-or multiple statements can occur on a single line of source code. A metrics report used for statement coverage analysis will have a count associated with each line of source code indicating the total number of times the statement has executed. This statement execution count value is not only useful for identifying lines of source code that have never executed, but also useful when the engineer feels that a minimum statement execution threshold is required to achieve sufficient testing. Block Coverage Block coverage is a variant on the statement coverage metric which identifies whether a block of code has been executed or not. A bl ock is defined as a set of stat ements between conditional statements or within a procedural definition, the key point being that if the block is reached, all the lines within t he block will be executed. This metric is used t o avoid unscrupulous engineers from achieving a higher statement coverage by simply adding more statements t o their code. Branch Coverage Branch coverage (also referred to as decision coverage) is a code coverage metric that reports whether Boolean expressions tested in control
structures (such as the if, case, while, repeat, f orever, for and loop statements) evaluated to both true and false. The entire Boolean expression is considered one true-or-false predicate regardless of whether it contains logical-and or logical-or operators. Expression Coverage Expression coverage (sometimes referred to as condition coverage) is a code coverage metric used to determine if each condition
evaluated both to true and false. A condition is an Boolean operand that does not contain logical operators. Hence, expression coverage measures the Boolean conditions independently of each other. Focused Expression Coverage Focused Expression Coverage (FEC), which is also referred to as Modified Condition/Decision Coverage (MC/DC), is a code
coverage metric often used used by the DO-178B safety critical software certification standard, as well as t he DO-254 formal airborne electronic hardware certification standard. This metric is stronger than condition and decision coverage. The formal defi nition of MC/DC as defin ed by DO-178B is:Every point of entry and exit in the program has been invoked at least once, every condition in a decision h as taken all possible outcomes at l east once, every decision in the program has taken all possible outcomes at least once, and each condition in a decision has been shown to independently affect that decisions outcome. A condition is shown to independently affect a decisions outcome by varying just that condition while holding fixed all other possible conditions. [3] It is worth noting that
completely closing Focused Expressing Coverage can be non-trivial. Finite-State Machine Coverage Today's code coverage tools are able to identify finite state m achines within the RTL source code. Hence, this makes it
possible to automatically extract FSM code coverage metrics to measure conditions. For example, the number of times each state of the state machine was entered, the number of times the FSM transitioned from one state to each of its neighboring states, and even sequential arc coverage t o identify state visitation transitions.
There are generally three main steps involved in a code coverage flow, which include:
Instrument the RTL code to gather coverage Run simulation to capture and record coverage metrics Report and analyze the coverage results
Part of the analysis step is to identify coverage holes, and determine if the coverage hole is due to one of three conditions:
10
Missing input stimulus required to activate the uncovered code A bug in the design (or testbench) that is preventing the input stimulus from activating the uncovered code Unused code for certain IP configurations or expected unreachable code related during normal operating conditions
Functional Coverage Metrics The objective of functional verification is to determine if the design requirements, as defined in our specification, are functioning as intended. The objective of measuring functional coverage is to measure verification progress with respect to the functional requirements of t he design. That is, functional coverage helps us answer the question: Have all specified functional requirements been implemented, and then ex ercised during simulation?
Benefit: one of the value propositions of constrained-random stimulus generation is that the simulation environment can automatically generate thousands of tests that would have normally required a significant amount of manual effort to create as directed tests. However, one of the problems with constrained-random stimulus generation is that you never know exactly what functionality has been tested without the tedious effort of examining waveforms after a s imulation run. Hence, functional coverage was invented as a measurement to help determine exactly what functionality a simulat ion regression tested without the need f or visual inspection of waveforms. For example, functional coverage can be implemented with a mechanism t hat links to specific requirements defined in a specification. Then, after a simulation run, it is possible to automatically measure which requirements were checked by a specific directed or constrained-random test as well as automatically determine which requirements were never tested.
Limitations: Since functional coverage is not an implicit coverage metric, it cannot be automatically extracted. Hence, this requires the user to manually create the coverage model. From a high-level, there are t wo different steps involved in creating a functional coverage model that need to be considered: 1. 2.
Identify the functionality or design intent that you want to measure: addressed through verification planning Implementing the machinery to measure the functionality or design intent: coding the machinery for each of the coverage items identified in the verification planning step (for example, coding a set of SystemVerilog covergroups for each verification objective identified in the verification plan).
Steps to Coverage Implementation First the required coverage must be defined, usually by manual analysis of f unctional and architectural specification documents along with expert consideration of the DUT’s architecture. RTL implementers are likely to be aware of the relationship s between specified activity and the operation of internal blocks, and will be able to suggest important coverage scenarios that are not necessarily evident from a high-level f unctional spec. Next, the verification team must identify how to capture the necessary information – an easy task for activity on a DUT interface, but often much more challenging for coverage that captures DUT internal state, or timing relationships across multiple interfaces. At this stage it is also important to identify the triggering and filtering criteria that will be used to determine whether coverage information should or should not be sampled.
Scoreboard and Functional Coverage:
The main goal of a verification environment is to reach 100% coverage of the defined functional coverage spec in the verification plan. Based on functional coverage analysis, the random based tests are than constrained to focus on corner cases to get do complete functional check. Coverage is a generic term for measuring progress to complete design verification. Simulations slowly paint the canvas of the design, as we try to cover all of the legal combinations. The coverage tools gather information during a simulation and then post process it to produce a coverage report. You can use this report to look for coverage holes and then modify existing tests or create new ones to fill the holes.
Types of Functional Coverage Metrics
The functional behavior of any design, at least as observed from any interface within the verification environment, consists of both data and tem poral components. Hence, from a high-level, there are two m ain types of functional coverage measurement we need to consider: Cover Groups' and Cover Properties .
Cover Group
Covergroup is like a user-defined type that encapsulates and specifies the coverage. It can be defined in a package, module, program,
interface or class once defined multiple instances can be created using new Parameters to new () enable customization of different instances. In all cases, we must explicitly instantiate it to start sampling. If the cover group is defined in a class, you do not make a separate name when we instance it. Cover group comprises of cover points, options, formal arguments, and an optional t rigger. A cover group encompasses one or more data points, all of which are sampled at the same t ime. The two major parts of functional coverage are the sampled data values and the time when they are sampled. When new values are ready (such as when a transaction has completed), your testbench triggers the cover group. To calculate the coverage for a point, you first have to determine the total number of possible values, also known as the domain. There may be one value per bin or multiple values. Coverage is the number of sampled values divided by the number of bins in the domain. A cover point that is a 3-bit variable has the domain 0:7 and is normally divided into eight bins. If, during simulation, values belonging to seven bins are sampled, the report will show 7/8 or 87.5% coverage for this point. All these points are combined to show the coverage for the entire group, and t hen all the groups are combined to give a coverage percent age for all the simulation databases. With respect to functional coverage, the sampling of state values within a design model or on an interface is probably the easiest to understand. We refer to this form of f unctional coverage as cover group modeling. It consists of state values observed on buses, grouping of int erface control signals, as well as register. The point is that the values that are being measured occur at a single explicitly or implicitly sampled point in time. SystemVerilog covergroups are part of the machinery we typically use to build the functional data coverage models, and t he details are discussed in the block level design example and the discussion of the corresponding example covergroup implementations.
Cover Property Modeling With respect to functional coverage, temporal relationships between sequences of events are probably the hardest to reason about. However, ensuring that these sequences of events are properly tested is important. We use cover property modeling t o measure temporal relationships between sequences of events. Probably the most popular example of cover properties involves the handshaking sequence between control signals on a bus protocol. Other examples include power-state transition coverage associated with verifying a low-power design. Assertions and coverage properties are part of the machinery that we use t o build temporal coverage models, and are addressed in the bus protocol monitor example.
11
Assertion Coverage The term assertion coverage has many meanings in the industry today. For example, some people define assertion coverage as the ratio of number of assertions to RTL lines of code. However, assertion density is a more accurate term that is often used for this m etric. For our discussion, we use the term assertion coverage to describe an implementation of coverage properties using assertions.
Cros s C overag e Cross Coverage is specified between the cover points or variables. Cross coverage is specified using the cross construct.
Expressions cannot be used directly in a cross; a coverage point must be explicitly defined first.
12
CONSTRAINTS
13
14
15
Clocking blocks
have been introduced in SystemVerilog to address the problem of specifying the timing and synchronisation requirements of a
design in a testbench. A clocking block is a set of signals synchronised on a particular clock. It basically separates the time related details from the structural, functional and procedural elements of a testbench. It helps the designer develop testbenches in terms of transactions and cycles. Clocking blocks can o nly be declared inside a module, interface or program. SystemVerilog’s clocking construct works. Consider a loadable, up/down binary counter:
The clocking construct is both the declaration and the instance of that declaration. Note that the signal directions in the clocking block within the testbench are with respect to the testbench. So Q is an output of COUNTER, but a clocking input. Note also that widths are not declared in the clocking block, just the directions. The signals in the clocking block cb_counter are synchronised on the posedge of Clock, and by default all signals have a 4ns output (drive) skew and a #1step input (sample) skew. The skew determines how many time units away from the clock event a signal is t o be sampled or driven. I nput skews are implicitly negative (i.e. they always refer to a time before the clock), whereas output skews always refer to a tim e after the clock. Clocking Block Drives
Clocking block outputs and inouts can be used to drive values onto their corresponding signals, at a certain clocking event and with the specified skew. An important point to note is that a drive does not change the clock block input of an inout signal. This is because reading the input always yields the last sampled value, and not the driven value. Synchronous signal drives are processed as nonblocking assignments. If multiple synchronous drives are applied to the same clocking block output or inout at the same simulation time, a run-time error is issued and the conflicting bits are set to X for 4-state ports or 0 f or 2-state ports. Here are some examples using the driving signals from the clocking block cb:
cb.Data[2:0] <= 3'h2; // Drive 3-bit slice of Data in current cycle ##1 cb.Data <= 8'hz; // Wait 1 Clk cycle and then drive Data ##2 cb.Data[1] <= 1; // Wait 2 cycles, then drive bit 1 of Data cb.Data <= ##1 Int_Data; // Remember the value of Int_Data, and then // drive Data 1 Clk cycle later cb.Data[7:4] <= 4'b0101; cb.Data[7:4] <= 4'b0011; // Error: driven value of Data[7:4] is 4’b0xx1
Clocking Blocks and Interfaces
This is an example presenting multiple clocking blocks using interfaces. A clocking block can use an interface to reduce the amount of code needed to connect the testbench. The interface signals will have the same direction as specified in the clocking block when viewed from the testbench side (e.g. modport TestR), and reversed when viewed from the DUT (i.e. modport Ram). The signal directions in the clocking block within the testbench are with respect to the t estbench, while a modport declaration can describe either direction (i.e. the testbench or t he design under test). Clocking cb2 @(posedge CtrlInt.Clock); output #10; output RWn = CtrlInt.RWn; // Hierarchical expression endclocking
interface CtrlBus (input Clock); logic RWn; // RWn is output, as it is in the clocking block modport TestR (output RWn); // RWn is input, reversed than in the clocking block modport Ram (input RWn); endinterface
Clocking block events
The clocking event of a clocking block can be accessed directly by using the clocking block name, e.g. @(cb) is equivalent to @(posedge Clk). Individual signals from the clocking block can be accessed using the clocking block name and the dot (.) operator. All events are synchronised to the clocking block.
16
Assertions are primarily used to validate the behaviour of a design. ("Is it working correctly?") They may also be used to provide functional coverage information for a design ("How good is the test?"). Assertions can be checked dynamically by simulation, or statically by a separate property checker tool – i.e. a formal verification tool that proves whether or not a design meets its specification. Such tools may require certain assump tions about the design’s behaviour to be specified. In SystemVerilog there are two kinds of assertions: immediate ( assert) and concurrent ( assert property ). Coverage statements ( cover property) are concurrent and have the same syntax as concurrent assertions, as do assume property statements. Another similar statement – expect – is used in testbenches; it is a procedural statement that checks that some specified activity occurs. The three types of concurrent assertion statement and the expect statement make use of sequences and properties that describe the design’s temporal behaviour – i.e. behaviour over time, as defined by one or more clocks.
Immediate Assertions Immediate assertions are procedural statements and are mainly used in simulation. An assertion is basically a statement that something must be true, similar to the if statement. The difference is that an if statement does not assert that an expression is true, it simply checks that it is true, e.g.: if (A == B) ...
// Simply checks if A equals B
assert (A == B); // Asserts that A equals B; if not, an error is generated
If the conditional expression of the immediate assert evaluates to X, Z or 0, then the assertion fails and the simulator writes an error message. An immediate assertion may include a pass statement and/or a fail statement. In our example the pass s tatement is omitted, so no action is taken when the assert expression is true. If the pass statement exists: assert (A == B) $display ("OK. A equals B");
it is executed immediately after the evaluation of the assert expression. The statement associated with an else is called a fail statement and is executed if the assertion fails: assert (A == B) $display ("OK. A equals B"); else $error("It's gone wrong");
Note that you can omit the pass statement and still have a fail statement: assert (A == B) else $error("It's gone wrong");
The failure of an assertion has a severity associated with it. There are three severity system tasks that can be included in the fail statement to specify a severity level: $fatal, $error (the default severity) and $warning. In addition, the system task $info indicates that the assertion failure carries no specific severity. Here are some examples: ReadCheck: assert (data === correct_data) else $error("memory read error"); Igt10: assert (I > 10) else $warning("I is less than or equal to 10");
The pass and fail statements can be any legal SystemVerilog procedural statement. They can be used, for example, to write out a message, set an error flag, increment a count of errors, or signal a failure to another part of the testbench. AeqB: assert (a === b) else begin error_count++; $error("A should equal B"); end
Concurrent Assertions The behaviour of a design may be specified using statements similar to these: "The Read and Write signals should never be asserted together." "A Request should be followed by an Acknowledge occurring no more than two clocks after the Request is asserted." Concurrent assertions are used to check behaviour such as this. These are statements that assert that specified properties must be true. For e xample, assert property (!(Read && Write));
asserts that the expression Read && Write is never true at any point during simulation. Properties are built using sequences. For example, assert property (@(posedge Clock) Req |-> ##[1:2] Ack);
17
where Req is a simple sequence (it ’s just a boolean expression) and ##[1:2] Ack is a more complex sequence expression, meaning that Ackis true on the next clock, or on the one following (or both). |-> is the implication operator, so this assertion checks that whenever Req is asserted, Ack must be asserted on the next clock, or the following clock. Concurrent assertions like these are checked throughout simulation. They usually appear outside any initial or always blocks in modules, interfaces and programs. (Concurrent assertions may also be used as statements in initial or always blocks. A concurrent assertion in an initial block is only tested on the first clock tick.) The first assertion example above does not contain a clock. Therefore it is checked at every point in the simulation. The s econd assertion is only checked when a rising clock edge has occurred; the values of Req and Ack are sampled on the rising edge of Clock.
Implication The implication construct (|->) allows a user to monitor sequences based on satisfying some criteria, e.g. attach a precondition to a sequence and evaluate the sequence only if the condition is successful. The left-hand side operand of the implication is called the antecedent sequence expression, while the righthand side is called the consequent sequence expression. If there is no match of the antecedent sequence expression, implication succeeds vacuously by returning true. If there is a match, for each successful match of the antecedent sequence expression, the consequent sequence expression is separately evaluated, beginning at the end point of the match. There are two forms of implication: overlapped using operator |->, and non-overlapped using operator |=>. For overlapped implication, if there is a match for the antecedent sequence expression, then the first element of the consequent sequence expression is evaluated on the same clock tick. s1 |-> s2;
In the example above, if the sequence s1 matches, then sequence s2 must also match. If sequence s1 does not match, then the r esult is true. For non-overlapped implication, the first element of the consequent sequence expression is evaluated on the next clock tick. s1 |=> s2;
The expression above is basically equivalent to: ‘define true 1 s1 ##1 ‘true |-> s2;
where `true is a boolean expression, used for visual clarity, that always evaluates to true.
Properties and Sequences In these examples we have been using, the properties being asserted are specified in the assert property statements themselves. Properties may also be declared separately, for example: property not_read_and_write; not (Read && Write); endproperty assert property (not_read_and_write);
Complex properties are often built using sequences. Sequences, too, may be declared separately: sequence request Req; endsequence sequence acknowledge ##[1:2] Ack; endsequence property handshake; @(posedge Clock) request |-> acknowledge; endproperty assert property (handshake);
18
Assertion Clocking Concurrent assertions ( assert property and cover property statements) use a generalised model of a clock and are only evaluated when a clock tick occurs. (In fact the values of the variables in the property are sampled right at the end of the previous time step.) Everything in between clock ticks is ignored. This model of execution corresponds to the way a RTL description of a design is interpreted after synthesis. A clock tick is an atomic moment in time and a clock ticks only once at any simulation time. The clock can actually be a single signal, a gated clock (e.g. (clk && GatingSig) ) or other more complex expression. When monitoring asynchronous signals, a simulation time step corresponds to a clock tick. The clock for a property can be specified in several ways: o Explicitly specified in a sequence: sequence s; @(posedge clk) a ##1 b; endsequence property p; a |-> s; endproperty assert property (p); o Explicitly specified in the property:
property p; @(posedge clk) a ##1 b; endproperty assert property (p); o Explicitly specified in the concurrent assertion:
assert property (@(posedge clk) a ##1 b); o Inferred from a procedural block:
property p; a ##1 b; endproperty always @(posedge clk) assert property (p); o From a clocking block (see the Clocking Blocks tutorial):
clocking cb @(posedge clk); property p; a ##1 b; endproperty endclocking assert property (cb.p); o From a default clock (see the Clocking Blocks tutorial):
default clocking cb;
19
Handling Asynchronous Resets In the following example, the disable iff clause allows an asynchronous reset to be specified. property p1; @(posedge clk) disable iff (Reset) not b ##1 c; endproperty
assert property (p1);
The not negates the result of the sequence following it. So, this assertion means that if Reset becomes true at any time during the evaluation of the sequence, then the attempt for p1 is a success. Otherwise, the sequence b ##1 c must never evaluate to true.
Sequences A sequence is a list of boolean expressions in a linear order of increasing time. The sequence is true over time if the boolean expressions are true at the specific clock ticks. The expressions used in sequences are interpreted in the same way as the condition of a procedural ifstatement. Here are some simple examples of sequences. The ## operator delays execution by the specified number of clocking events, or clock cycles. a ##1 b
// a must be true on the current clock tick // and b on the next clock tick
a ##N b
// Check b on the Nth clock tick after a
a ##[1:4] b
// a must be true on the current clock tick and b // on some clock tick between the first and fourth // after the current clock tick
The * operator is used to specify a consecutive repetition of the left-hand side operand. a ##1 b [*3] ##1 c
// Equiv. to a ##1 b ##1 b ##1 b ##1 c
(a ##2 b) [*2]
// Equiv. to (a ##2 b ##1 a ##2 b)
(a ##2 b)[*1:3]
// Equiv. to (a ##2 b) // or (a ##2 b ##1 a ##2 b) // or (a ##2 b ##1 a ##2 b ##1 a ##2 b)
The $ operator can be used to extend a time window to a finite, but unbounded range. a ##1 b [*1:$] ##1 c
// E.g. a b b b b c
The [-> or goto repetition operator specifies a non-consecutive sequence. a ##1 b[->1:3] ##1 c
// E.g. a !b b b !b !b b c
This means a is followed by any number of clocks where c is false, and b is true between 1 and three times, the last time being the clock before c is true. The [= or non-consecutive repetition operator is similar to goto repetition, but the expression ( b in this example) need not be true in the clock cycle before c is true. a ##1 b [=1:3] ##1 c // E.g. a !b b b !b !b b !b !b c
20
Combining Sequences There are several operators that can be used with sequences: The binary operator and is used when both operand expressions are expected to succeed, but the end times of the operand expressions can be different. The end time of the end operation is the end time of the sequence that terminates last. A sequence succeeds (i.e. is true over time) if the boolean expressions containing it are true at the specific clock ticks. s1 and s2
// Succeeds if s1 and s2 succeed. The end time is the // end time of the sequence that terminates last
If s1 and s2 are sampled booleans and not sequences, the expression above succeeds if both s1 and s2 are evaluated to be true. The binary operator intersect is used when both operand expressions are expected to succeed, and the end times of the operand expressions must be the same. s1 intersect s2 // Succeeds if s1 and s2 succeed and if end time of s1 is // the same with the end time of s2
The operator or is used when at least one of the two operand sequences is expected to match. The sequence matches whenever at least one of the operands is evaluated to true. s1 or s2
// Succeeds
whenever at least one of two operands s1
// and s2 is evaluated to true
The first_match operator matches only the first match of possibly multiple matches for an evaluation attempt of a sequence expression. This allows all subsequent matches to be discarded from consideration. In this example: sequence fms; first_match(s1 ##[1:2] s2); endsequence
whichever of the (s1 ##1 s2) and (s1 ##2 s2) matches first becomes the result of sequence fms. The throughout construct is an abbreviation for writing: (Expression) [*0:$] intersect SequenceExpr
i.e. Expression throughout SequenceExpr of SequenceExpr . The within construct is an abbreviation for writing:
means that Expression
must evaluate true at every clock tick during the evaluation
(1[*0:$] ##1 SeqExpr1 ##1 1[*0:$]) intersect SeqExpr2
i.e. SequenceExpr1 within SequenceExpr2 means that SeqExpr1 must occur at least once entirely within SeqExpr2 (both start and end points of SeqExpr1 must be between the start and the end point of SeqExpr2 ).
Variables in Sequences and Properties Variables can be used in sequences and properties. A common use for this occurs in pipelines: `define true 1 property p_pipe; logic v; @(posedge clk) (`true,v=DataIn) ##5 (DataOut === v); endproperty
In this example, the variable v is assigned the value of DataIn unconditionally on each clock. Five clocks later, DataOut is expected to equal the assigned value. Each invocation of the property (here there is one invocation on every clock) has its own copy of v. Notice the syntax: the assignment to v is separated from a sequence expression by a comma, and the sequence expression and variable assignment are enclosed in parentheses.
Coverage Statements In order to monitor sequences and other behavioural aspects of a design for functional coverage, cover property statements can be used. The syntax of these is the same as that of assert property . The simulator keeps a count of the number of times the property in the cover property statement holds or fails. This can be used to determine whether or not certain aspects of the designs functionality have been exercised. module Amod2(input bit clk); bit X, Y; sequence s1; @(posedge clk) X ##1 Y; endsequence
21
CovLavel: cover property (s1); ... endmodule
SystemVerilog also includes covergroup statements for specifying functional coverage. These are introduced in the Constrained-Random Verification Tutorial.
Assertion System Functions SystemVerilog provides a number of system functions, which can be used in assertions. $rose, $fell and $stable indicate whether or not the value of an expression has changed between two a djacent clock ticks. For example, assert property (@(posedge clk) $rose(in) |=> detect);
asserts that if in changes from 0 to 1 between one rising clock and the next, detect must be 1 on the following clock. This assertion, assert property (@(posedge clk) enable == 0 |=> $stable(data));
states that data shouldn’t change whilst enable is 0. The system function $past returns the value of an expression in a previous clock cycle. For example, assert property (@(posedge clk) disable iff (reset) enable |=> q == $past(q+1));
states that q increments, provided reset is low and enable is high. Note that the argument to $past may be an expression, as shown above. The system functions $onehot and $onehot0 are used for checking one-hot encoded signals. $onehot(expr) returns true if exactly one bit of expr is high; $onehot0(expr) returns true if at most one bit of expr is high. assert property (@(posedge clk) $onehot(state));
There are other system functions.
Binding We have seen that assertions can be included directly in the source code of the modules in which they apply. They can even be embedded in procedural code. Alternatively, verification code can be written in a separate program, for example, and that program can then be bound to a specific module or module instance. For example, suppose there is a module for which assertions are to be written: module M (...); // The design is modelled here endmodule
The properties, sequences and assertions for the module can be written in a separate program: program M_assertions(...); // sequences, properties, assertions for M go here endprogram
This program can be bound to the module M like this: bind M M_assertions M_assertions_inst (...);
The syntax and meaning of M_assertions is the same as if the program were instanced in the module itself: module M (...); // The design is modelled here M_assertions M_assertions_inst (...); endmodule
22
Universal Verification Methodology (UVM) What is UVM? UVM refers to Universal Verification Methodology introduced by Accellera based on the Open Verification Methodology (OVM). It is a methodology to perform functional verification through a supporting library of System Verilog code. What are benefits of using UVM? UVM offers a complete verification environment composed of reusable components and is part of a constrained random, coverage-driven methodology. However, traditional HDL based testbenches might wiggle a few input pins and rely on manual inspection for checking correct operation. Even if they are automated, they have to offer a quantifiable way to determine verification progress. Based on the complexity of current designs, a complete random approach is not reasonable to meet the tight schedules. UVM leverages the object oriented capabilities of System Verilog such as classes, constraints and covergroups to ease the difficulties in verifying a complex design. UVM is primarily simulation based. However, it can also be used alongside assertion, emulation or hardware acceleration based approaches. The other approaches typically use a Verilog, System Verilog or System C language at abstraction levels such as behavioral, gate level or register transfer level.
What is Transaction-Based Verification? How is it done? Where is it used? What is Transaction-Based Verification (TBV)? TBV is a concept used in Hardware Emulation raises the level of verification abstraction from a wire-level (or pin level) interface to run several million times faster than RTL simulation It simplifies the communication between the testbench and DUT so a design team can access the full per formance benefit of the emulator TBV thus helps accelerate SoC verification by offering multiple orders of magnitude improvement in verification performance How is TBV carried out? With TBV, the DUT is loaded onto the emulator, and the testbench resides on a computer. But instead of a wire-level interface, TBV uses a high-performance transaction-level interface The communication between the testbench, now working at a protocol level, and the DUT, which still requires a wire-level interface, is accomplished through what’s called a transactor. The transactor converts the high-level commands from the testbench into the wire-level, protocol-specific sequences required by the DUT, and vice versa The main point here is that all the wire-level communications are wholly contained within the emulator itself and run orders of magnitude faster as a result TBV also eliminates the need for rate adapters and physical interfaces
Another benefit of TBV is that it allows the testbench to stream data to the DUT, which the transactor buffers automatically. This further speeds up the execution of the testbench. o With this methodology, it is possible to have multiple transactions active across multiple transactors o Together, these transactors enable the emulator to process data continuously, which dramatically increases overall performance to that of a pure ICE environment. A point to note here is that in TBV, the back-end portion of the transactor and the DUT are located within the emulator. This mandates that they both be writt en in synthesizable RTL. Where is TBV used? TBV can be used throughout the verification fl ow, from unit (block) level to SoC level. Common applications include: Verification of large blocks, subsystems or entire SoCs Driver development Early hardware/software bring-up (this includes firmware, drivers, and OSs) Full-chip power analysis and estimation
23
Arbiter verification An arbiter is a commonly used design i n circuits to control the access to a shared resource among multiple clients.
SOURCE: http://rtlery.com/sites/default/files/queueing_fifos_and_arbiter.png
A rbi tration policies
Round Robin – This policy is generally used to improve fairness. Fairness generally implies granting all clients a good chance of running on the shared resource. A particular client will not be considered for arbitration if it has been serviced and there are other clients having outstanding requests. Priority – This policy guarantees that the important clients run first when the latency or application requirements are known. First Come First Serve (FCFS) – This is a variation of the priority policy where the priority is granted to the client making the request first.
S cenari os to verify Apart from functionally verifying the arbiter algorithm stand alone, the arbiter should be verified at application level via writing assertions. Adding the assertions will also ensure that the application requirements are met in terms of fairness and performance.
24
If only a single client requests, that client should be serviced. In round robin arbiters, a client which has been serviced should not receive a grant again until the other clients having outstanding requests are serviced at least once. This will ensure that the clients do not suffer from starvation. In priority arbiters, a client having hi gher priority should always win arbitration over a lower priority arbiter.
What is REGISTER RENAMING? Register renaming is a technique deployed in Out-Of-Order Processors (OOO). It eliminates the false data dependencies arising from the reuse of architectural registers by successive instructions that do not have any real data dependencies between them. Why use register renaming? As mentioned earlier, it eliminates false (WAR and WAW) dependencies. A description of false dependencies is here. How is register renaming implemented? When possible, the compiler detects the distinct instructions and tries to assign them to a different register. However, there is a finite number of register names that can be used in the assembly code. Many high performance CPU’s have more physical registers than that may be named directly i n the instruction set, so they rename registers in hardware to achieve additional parallelism.In all renaming schemes, the machine converts the architectural registers referenced in the instruction stream i nto tags. Where the architectural registers might be specified by 3 to 5 bits, the tags are usually a 6 to 8 bit number. Because the size of a register file generally grows as the square of the number of ports, the rename file is usually physically large and consumes significant power.
Superscalar and VLIW processors In VLIW processors, the decision is made by t he compiler to group together instructions (words) into a Very Large Instruction Word. The onus is on the compiler to group and execute independent instructions in parallel. Therefore, hardware implementation is simplified leading to lesser power consumption.
For Superscalar processors, the decision is made by the compiler. However, hardware implementation is complicated. Superscalar processors have multiple functional units t o execute the same types of i nstructions in parallel. Example: 4 adders can execute 4 addition instructions in parallel. Disadvantages of VLIW: It requires compiler support and extended usage to make the best of the hardware support. It requires the compiler to add branch prediction. Furthermore, it needs to add recovery code. VLIW compilers can induce code bloat when there is a lot of dependence among the instructions. Hence, this can lead to functional units execution NOPs.
Direct-Mapped and Fully Associative Caches Direct-Mapped Caches It is fast Design is simple It has maximum number of conflict misses The best way to visualize it is as a 1-way associative cache Fully Associative Caches It is slow Design is complex requiring higher number of comparators There are no conflict misses here Consumes more area and power Trade-off A Set Associative cache has lesser conflict misses and requires lesser number of comparators. Hence, it has advantages over direct-mapped and fully associative caches in terms of both power consumption and performance. Therefore, to get the best features of both designs, it makes sense to use a set associative cache. Additionally, as a thumb rule for considering performance and power considerations : For an n-way associative cache, you need n comparators to compare for tags within a set.
25
PIPELINING and its Pros and Cons
What is pipelining? In general, pipelining refers to a set of data processing elements connected in series and executed in parallel, where the output of one element is the input of the next one. How does pipelining affect processor clock? As the pipeline is made “deeper”, a particular step may be implemented with simpler circuitry. This in turn, lets the processor clock run faster. What are the pros of pipelining? Increase in instruction throughput (this occurs due to multiple operations being performed simultaneously). Higher clock frequency as indicated above. What are the cons of pipelining? Does not reduce instruction latency (defined as the time to complete a single instruction from start to finish). In fact, it may increase latency due to additional overhead involved from breaking the computation into separate steps and worse, the pipeline may stall (or even need to be flushed) due to mispredicted branches and exceptions. A pipelined system typically requires buffer storage to pass on the output of each stage to the next. This buffer storage requires additional area on the chip and adds to the latency of execution. Pipelining also makes the static timing analysis of the datapath more complicated since the setup/hold time requirements of the buffers need to be taken into account during the design of the processor. It may also require more resources such as processing units, memory, etc. than a regular single-cycle datapath, because its stages cannot reuse the resources of a previous stage. May lead to an increase in the time it takes for an instruction to complete. Hence, pipelining increases throughput at the cost of latency. Furthermore, it is frequently used in t oday’s CPU’s. But it is avoided in real-time systems, in which latency is a hard constraint.
Data Hazards in Pipelining
26
Questions:
What are the primary types of Register Dependencies/Data Hazards in a Pipelined System?
What are the remedies for each of these hazards? Which type of data hazard is commonly observed in an in-order pipeline? Here, we will use the term Read for a Load and Write for a Store operation.
1.
Read After Write (RAW) – This is observed when a read is to be performed to an unwritten address/memory location. Hence, these occur in an in-order pipeline. It is also known as True or Flow dependence. pseudo-Assembly example: 1. R1 <– 10 2. R2 <– R1 Solution: In order execution of the code sequence prevents the occurrence of this data hazard. However, this typically results in stalling the pipeline for few clocks until the write can be committed to memory. Therefore, Data Forwarding or Bypassing is an optimization for this hazard. 2. Write After Write (WAW) – This is observed when you need to write to the same address in consecutive lines of code. It is also known as Output Dependence. pseudo-Assembly example: 1. R1 <– 10 2. R2 <– 11 Solution: Squashing earlier Write (using updated value) within a structure like a Write/Store buffer is a micro architectural optimization to prevent multiple stores to the same address. Register Renaming, a very efficient technique employed in modern Out-of-Order systems can be used to prevent this hazard. 3. Write After Read (WAR) – This is observed when you need to write to a memory location after a read. Hence, you need to wait till the old value has been read before performing another write to the same address. It is also known as Anti Dependence or False Dependence. pseudo-Assembly example: 1. R2 <– R1 2. R1 <– 10 Solution: Similar to WAW hazards, Register Renaming can also be used.
Load Store Queue
Today’s processors use the mechanisms dependent on load store queues to resolve ambiguous dependences and recover when a dependence was violated. If you haven’t read about dependencies in out-of-order processors, check it out here first. Avoiding WAR and WAW dependencies Values from store instructions are buffered in a store queue until they retire. This is because without store buffering, stores cannot execute until all older possibly exception-causing instructions have executed (and not caused an exception) and all previous branch directions are known. Forcing stores to wait until branch directions and exceptions are known, significantly reduces the out-of-order aggressiveness and limits ILP (Instruction level parallelism) and thus performance. When a store retires, it then writes its value to the memory system. This avoids the WAR and WAW dependences where an earlier load receives an incorrect value from the memory system because a later store was allowed to execute before an earlier load. Buffering stores until retirement avoids WAW and WAR dependencies but introduces a new issue. Consider the following scenario: a store executes and buffers its address and data in the store queue. A few instructions later, a load executes that reads from the same memory address to which the store just wrote. If the load reads its data from the memory system, it will read an old value that would have been overwritten by the preceding store. The data obtained by the load will be incorrect. S tore to load (S to L ) forwarding – To solve the above problem, processors employ a technique called store-to-load forwarding using the store queue. In addition to buffering stores until retirement, the store queue serves a second purpose: forwarding data from completed but not-yet-retired (“in-flight”) stores to later loads. Rather than a simple FIFO queue, the store queue is really a Content-Addressable Memory (CAM) searched using the memory address. When a load executes, it searches the store queue for in-flight stores to the same address that
27
are logically earlier in program order. If a matching store exists, the load obtains its data value from that store instead of the memory system. If there is no matching store, the load accesses the memory system as usual; any preceding, matching stores must have already retired and committed their values. This technique allows loads to obtain correct data if their producer store has completed but not yet retired. o Multiple stores to the load’s memory address may be present in the store queue. To handle this case, the store queue is priority encoded to select the latest store that is logically earlier than the load in program order. The determination of latest store is achieved by attaching a timestamp to the instructions as they are fetched and decoded. Alternatively, by knowing the relative position of the load with respect to the stores within the store queue. Detecting RAW dependence violations Modern out-of-order CPUs can use a number of techniques to detect a RAW dependence violation. But, all techniques require tracking in-flight loads from execution until retirement. When a load executes, it accesses the memory system and/or store queue to obtain its data value. Then, it’s address and data are buffered in a load queue until retirement. The load queue is similar in structure and function to t he store queue. In fact, in some processors may be combined with the store queue in a single structure called a load store queue, or LSQ. With this technique, the load queue keeps track of all in- flight loads. Similar to the store queue, it is a CAM searched using the memory access address. When a store executes, it searches the load queue for completed loads from the same address that are logically later in program order. If such a matching load exists, it must have executed before the store. Thus, it read a stale value from the memory system/store queue. Any instructions that used the load’s value have also used bad data. If such a violation is detected, the load is marked as “violated” in the retirement buffer. The store remains in t he store queue and retirement buffer and retires normally. It commits it’s value to the memory system when it retires.
S olution However, when the violated load reaches the retirement point, the processor flushes the pipeline. It restarts execution from the load instruction. At this point, all previous stores have committed their values to the memory system. The load instruction will now read the correct value from the memory system. Any dependent instructions will re-execute using the correct value.
Instruction-Level Parallelism
What is Instruction-level parallelism (ILP)? A measure of how many of the instructions a processor can execute simultaneously. What are the approaches to instruction level parallelism?
Hardware
o o o
Also known as dynamic parallelism Processor decides which instructions to execute in parallel at run time The Pentium processor implements dynamic parallelism
Software
o o o
Also known as static parallelism Compiler decides which instructions to execute in parallel at compile time The Itanium processor implements static parallelism ILP Example: e = a + b //1 f = c + d //2 m = e * f //3 The result of instruction 3 cannot be calculated until results of instructions 1 and 2 are completed since it depends on them. On the contrary, instructions 1 and 2 do not depend on any other operation and hence can be calculated parallelly.
How do you calculat e ILP? ILP = (Number of Instructions)/(Number of cycles). There is an ILP of 3/2 in the above example since 3 instructions are executed in 2 cycles (instruction 1 and 2 can be overlapped in the same cycle).
What are some common micro-architectural techniques used to exploit ILP?
28
Instruction Pipelining: Execution of multiple instructions can be partially overlapped.
Superscalar Execution, Very Long Instruction Word (VLIW), and Explicitly Parallel Instruction Computer (EPIC) : Multiple execution units are used to execute multiple instructions in parallel.
Out-of-order execution (OOO): Instructions execute in any order that does not violate data dependencies.
Register Renaming: A technique used to avoid unnecessary serialization of program operations imp osed by the reuse of registers by those operations.
Branch Prediction: Used to avoid stalling until branch/control dependencies are resolved.
Translation Lookaside Buffer
What is a Translation Lookaside Buffer?
A Translation Lookaside Buffer (TLB) is essentially a cache of the Page Table. It resides on the on-chip MMU and helps improve virtual address translation speed. Today’s desktop, laptop and server processors typically include more than one TLBs in the MMU.
The TLB is typically always present in any hardware that utilizes paged or segmented virtual memory.
TLB miss handling
The CPU accesses the main memory to do a Page Table Walk (PTW) in case of a TLB miss.
In case of a TLB miss, the best case is that the desired virtual address translation entry is in the Page Table, but the virtual-tophysical translation entry is just not in a TLB. I n this case, all that needs to be done is to lookup the main memory page table to find the requested translation and insert it into the TLB. However, the worst case is that a TLB miss does not find the entry in the main memory Page Table eventually leads to a Page Table fault, in which case the page does not exist in memory and needs to be first brought into memory by doing an IO read operation from disk. Post that, the page table needs to be updated with a Page Table Entry (PTE) reflecting the new page that has just been brought into memory. The faulting memory operation which originally lead to the TLB miss is then retried and it leads to a TLB miss again but this time a Page Table Walk leads to the entry finally bring brought into the TLB eventually leading to a TLB hit. To do a Page Table Walk, the CPU first reads the Page Table Base Register (PTBR) (CR3 register on x86 for instance) to find the starting address for the Page Table and looks up the entry in the Page Table by looking up the Virtual Page Number and the Offset from the virtual address. Due to the latency involved in accessing a lower level of the memory hierarchy (DRAM or Disk), these operations are time consuming so a well-functioning TLB is of prime importance. These sequence of operations also prove that a TLB miss can be more expensive than an instruction or data cache miss, due to requiring not just a load from main memory, but a page walk, requiring several loads.
Multiple TLBs
Similar to caches, TLBs may have multi ple levels. Today’ s CPUs typically have multiple TLBs. For example, a small “L1” TLB (potentially fully associative) that is extremely fast and a larger “L2” TLB that is somewhat slower. TLBs can also be unified (one TLB for both instructions and data), while a split TLB config (two different TLBs, one for instructions and the other for data) is also used.
Hardware/Software Managed TLBs Hardware Managed TLBs:
With hardware managed TLBs, the CPU walks the page tables. In case of a Page Table Fault, the CPU raises a page fault exception, which the operating system must handle. With a hardware-managed TLB, the format of the TLB entries is not visible to software, and can change from CPU to CPU without causing loss of compatibility for the programs.
Software Managed TLBs:
With software-managed TLBs, a TLB miss generates a “TLB miss” exception, and the OS is responsible for walking the page tables and performing the translation in software.
The OS loads the translation into the TLB and restarts the program from the instruction that caused the TLB miss.
If the OS finds no valid translation in the page tables, a page fault has occurred and the OS must handle it accordingly.
Instruction Set Architectures (ISA) of CPUs that have software-managed TLBs have instructions that allow loading entries into any slot in the TLB. The format of the TLB entry is defined as a part of the ISA.
Keep in mind that Page Table Faults are *always* handled by the OS irrespective of the TLB being hardware or software managed.
29
Tomasulo Algorithm Today’s Out-Of-Order (OOO) processors carry out dynamic scheduling of instructions to efficiently utilize multiple execution units using Tomasulo’s algorithm. It was developed by Robert Tomasulo at IBM in 1967, and first implemented in the IBM System/360 Model 91 ’s floating point unit – where it gained its fame.
Key features: The following are key features of Tomasulo’s Algorithm: Reservation Stations, Common Data Bus, Distributed hazard detection and execution control and Dynamic memory disambiguation. Reservation Stations (RS)
Buffers for functional units that hold instructions stalled for RAW hazards and their operands to be available.
Source operands can be values or names of other reservation station entries or load queue entries (in case of a memory read) that will produce value. o Both operands don’t have to be available at the same time. o When both operand values have been computed, an instruction can be dispatched to its functional unit.
RAW hazards eliminated by forwarding o Source operand values that are computed after the registers are read are known by the functional unit or load queue that will produce them. o Results are immediately forwarded to functional units on the common data bus. o Don’t have to wait until for value to be written into the register file.
WAR and WAW hazards eliminated by using register renaming o Name-dependent instructions refer to reservation station or load queue locations for their sources, not the registers (as above) o The last writer to the register updates it o More reservation stations than registers, so eliminates more name dependences than a compiler can & exploits more parallelism Common Data Bus (CDB)
Connects functional units and load queue to reservations stations, registers and the store queue.
Ships results to all hardware that could want an updated value.
Eliminates RAW hazards: not have to wait until registers are written before consuming a value. Distributed hazard detection and execution control
Each reservation station decides when to dispatch instructions to its function unit.
Each hardware data structure entry that needs a value from the common data bus grabs the value itself by snooping .
Reservation stations, store queue entries & registers have a tag saying where their data should come from.
When it matches the data producer’s tag on the bus, reservation stations, store queue entries & registers grab the data. Dynamic memory disambiguation
The issue:
o
Don’t want loads to bypass stores to the same location.
The solution:
o o
Loads associatively checks addresses in the store queue. If an address match, grab the value.
Tomasulo execution stages Tomasulo works in three stages: Issue, execute and write result assuming that the instruction has been fetched. With the addition of a Re-Order Buffer (ROB), an additional fourth stage is added called commit. Issues o Issue if no hazard; stall if hazard. o Read registers for source operands. Put into reservation stations if values are in them. If not, put tag of the producing functional unit or load queue. (renaming the registers to eliminate WAR and WAW hazards) Execute o Detect RAW hazards. Snoop on CDB for missing operands. o Dispatch instruction to a functional unit when both operand values are ready. o o Execute the operation. o Calculate effective address and start memory operation (load/store). Write Result Broadcast result and reservation station tag (ID) on the CDB. o Reservation stations, registers and store queue entries obtain the o value through snooping. Advantages of Tomasulo’s algorithm compared to Scoreboarding
30
Register renaming in hardware.
Reservation stations for all execution units.
Common Data Bus (CDB) on which computed values broadcast to all reservation stations that may need them.
These developments avoid unnecessary stalls that would occur w ith scoreboarding and thus allow for efficient parallel execution and better performance than scoreboarding.
CACHES Tradeoffs There are multifaceted tradeoffs considered while designing caches. 1.
Caches are based on SRAM Technology – SRAMs are much faster than DRAMs. However their disadvantages include:
1.
Lower density compared to DRAMs owing to the use of ~6 transistors per bit compared to 1 transistor per bit used in DRAM.
2.
As a result of the lower density, the per bit storage cost is higher in SRAMs compared to DRAMs.
2.
Large Caches provide higher hit rate. However, as the size of the cache increases the latency of the access circuits (comparators) increase drastically.
3.
Multi-level caching helps improve hit rate further but can be slow – if you don’t find data in the first level you go to the next level (adds to latency).
4.
Typical scenarios when caches do not serve performance improvement –
1.
On every program change, the stale data of the previous program has to be flushed. You have to go through the phase of cold misses every time a fresh program is loaded for execution.
2.
If a particular workload does not have locality such as a streaming application (say streaming a YouTube video online wherein you rarely re-read previous data by seeking backwards). In this case, the benefits of caches drop low and the AMAT (Average Memory Access Time) increases drastically. This is because cache content is rarely re-used and everything you bring in your cache eventually has to be evicted without being re-read.
What are the types of Cache Misses? (4 Cs ) In modern High Performance Computer Architecture (HPCA) literature, cache optimizations play a very important role. Caches are another layer of faster (SRAM) memory added to speed up Memory operations which are tra ditionally bottlenecked by Mai n Memory (DRAM) also known as lower layer Memory.
Types of cache misses Compulsory – These are also called Cold Misses which are observ ed when you freshly boot up your system an d when everything you access is a new request (not present in cache). Optimizations such are the use of a sequential/stream prefetcher significantly help reduce Cold/Compulsory misses. Capacity – Caches (SRAM) are faster than Main Memory (DRAM). However, they consume considerably large power and area than Main Memory an d hence their size is limited. Once a particular way gets full in the cache replacement policies come into play. More the number of processors on t he SoC (More the caches) leads to reduction in Capacity misses. Conflict – Conflict misses arise when you hit a particular set and it’s already full. You have to replace data in that particular set since there is a conflict. More the number of sets the lesser the conflict misses. Coherence – Coherence misses are observed on account of Coherence based Protocols where coherence traffic/invalidations may be sent out between cores.
What are Snooping and Directory Based Cache Coherency Protocols?
Cache Coherency is of prime importance in Modern CPU Design. There
are two types of Cache Coherency Protocols. There is a trade off between them depending on the complexity and scalability of implementation.
Snooping-Based Cache Coherency Protocols It is based on the concept of Broadcast where every coherency state transition in one core is sent out as a broadcast to the other cores (for multicore systems). It is not scalable, imagine a system with 1000s of cores sending out broadcasting traffic. You are bound to get bottlenecked by the bus interface bandwidth here. It requires more power and area to implement a Snoop based protocol. Snoop based Protocols are plagued by contention and electrical issues. The implementation of Snoop Based protocols is straight forward. Directory-Based Cache Coherency Protocols It is based on the concept of point-to-point communication in contrast to broadcast being used for Snoop Based protocols. The whole idea to make it point to point and to only send out traffic to cores which are in contention fo r a cache line makes it a scalable solution for modern Multi Processor SoCs. There can be false positives being sent out – This is more of an i mplementation based issue where you sometimes do not infor m other cores of a c lean line being evicted and are still a valid entry in other directories and receive coherence traffic from them. A typical implementation can be thought of as a Telephone Directory. However, here you use a bit vector instead of an actual “book” to keep track of who owns a particular cache line. The implementation is relatively complex depending on the number of cores in picture. Directory size is proportional to (No. of Processors) x (No. of Memory Blocks).
31
Types of Caches based on Construction
Structure of a cache line
tag
flag bits
data
Direct-mapped caches
Each memory location can go in only one entry in the cache
Also called “one-way set associative” cache
Does not utilize a replacement policy as such, since there no concept of eviction
This means that if two locations map to the same entry, they may continually knock each other out
A direct-mapped cache needs to be much larger than an associative cache to o ffer comparable performance
Mapping equation: x = y mod n => where x is the cache line number, y is the address, and n be number of blocks in cache
Set-associative caches
A memory location can be cached in any of the n-ways (or slots) within the cache. Typically, the least significant bits of the memory location’s index are used the slot index for the cache memory, and to have two entries for each index. LRU is typically used as a replacement policy and is especially simple since only one bit needs to be stored for each pair.
Fully-associative caches
A memory location can be cached in any location within the cache.
A fully-associative cache tests all the possible ways simultaneously, using something like a content addressable memory.
In the common case of finding a hit in the first way tested, a fully-associative cache is as fast as a direct-mapped cache, but it has a much lower conflict miss rate than a direct-mapped cache.
Advantages of prefetching 1.
Reducing effective latency 2. Improving resource utilization 3. Higher confidence of prefetch usage (depending on the workload)
Generally, prefetchers understand and develop a pattern in the way the current workload uses data by applying dynamic learning policies. Therefore, the locality and access footprint of the workload trains the prefetcher. Also, modern CPUs typically have multiple levels of prefetchers for each cache level in the Memory Hierarchy. As an additional note, prefetching improves the latency for both instruction and data caches.
Interview Question
Design an L2 prefetcher for the below specification. Inputs: Current PC, Valid, Hit
Outputs: Prefetch Address, Valid, Solution: Firstly, if there is a Hit for the PC being sent in to the block,
we can increment and send out PC+4 (next line) and PC+8 (next to next line). Otherwise, send out just PC+4 (next line).
32
Frequency Divide by 2 logic design Verilog RTL code for a divide by 2 logic – module clk_div (clk_in, enable,reset, clk_out); // ————–Port Declaration———————– input clk_in ; input reset ; input enable ; output clk_out ; //————–Port data type declaration————wire clk_in ; wire enable ; //————–Internal Registers———————reg clk_out ; //————–Code Starts Here———————– always @ (posedge clk_in) if (reset) begin clk_out <= 1’b0; end else if (enable) begin clk_out <= ! clk_out ; end endmodule
33
What's the relations hip between voltage and s peed Higher the voltage more time to reach saturation or more time to switch on and off the transistor so lower the speed. V (proportional) R (proportional) Length of wire. Lets assume Length of wire is Distance, then longer the wire V should be higher to reach the other end of the wire. Which means higher the voltage-difference.
What will happen if the PMOS and NMOS of the CMOS inverter circuit are interchanged with respect to their positions? Assume that the PMOS and NMOS positions are interchanged. pMOS is a switch which turns on when you give 0 in gate. nMOS is a switch which turns on when you give 1 in gate. Since in an Nmos, the Drain gets the Higher voltage; in our case, Drain is connected to VDD and Source becomes the output node. Apply a VDD i.e Logic 1 to the Gate. The Nmos turns ON and the ouput node charges towards VDD. But you need a Vgs >= Vth to keep the Nmos in ON state. Currently Vg is at VDD and Vs charging towards VDD. Now, when Vs approaches VDD - Vth , you have Vgs = VDD - (VDD - Vth) = Vth. Any extra voltage at Vs would turn the Nmos off and thus, you would never get a Strong 1 ( i.e VDD) at the output. Thus Nmos passes a Weak 1 (VDD - Vth ). You could apply the similar analysis to the Pmos and prove it passes a weak Zero. (i.e Vth) PS: The circuit would actually not work like an Inverter......but a Buffer passing Weak 1's and Weak 0's.
Why/What is load capacitance in CMOS inverter? Load capacitance in a CMOS circuit is a combination of input capacitance of the following circuit(s) and the capacitance of the interconnect. (For long interconnects things get more tricky as transmission line effects need to be taken into consideration) The effect of load capacitance is that it causes a transient current demand on the inverter output, which causes a number of secondary effects, two of which are: The output has a limited current capability, so this limits the maximum rate of change of the signal, slowing down the edges. The transient output current is drawn from the power supply and hence causes spikes in the power supply (since the power supply and its interconnect are non-ideal and have series impedance). This is the reason why decoupling capacitors need to be connected between the p ower rails close to the output stage.
Why increasing transistor size reduces delay in operation of MOS? Delay in a gate can be simplified as the amount of time it takes to discharge the load capacitance that the gate or fet is driving. I= q/t = C*V/t t=C*V/I 1) to the first order, delay (time) is inversely proportional to drive current. So, increasing the drive current will reduce the delay. 2) Increasing the MOS width will increase its drive current. Therefore, increasing MOS width will increase its drive current which will reduce the discharge time of the load ( reduce delay). If you want the delay through the gate to be small, you should make the gate bigger and that would reduce the fanout. However, we have to keep in mind that there will be other gates that need to drive Cin. So, we cannot make the gate very big. You cannot size one gate in isolation but you should consider the full chain of logic or gates. Typically, there will be an optimum sizing solution. In the case of a chain of inverters driving a large load capacitance, the optimal electrical fanout is found to be between 3 and 4.
How does transistor size affects clock speed?
The critical path, i.e. the slowest pathway in your chip. In layman's terms, you're only as strong as your weakest link - the critical path is that weakest link. If you run your clock any faster than your critical path, you encounter "setup violations" along that path, which in turn contaminates other paths, and the chip malfunctions. This is where transistor size comes into play. While not directly affecting the clock, the size of your transistors affects path delays. Why? A bigger transistor takes longer to charge up. This makes your pathways, and therefore your critical path, slower. Bigger transistors=>Longer critical path=>Slower clock Transistor size goes down and Switching Frequency goes up. That is 0 to 1 or 1 to 0. So a high frequency transistor ( well a whole bunch of them) ensures a high frequency CPU.
Transistors
The four transistor operation modes are:
Saturation – The transistor acts like a short circuit. Current freely flows from collector to emitter. Saturation is the on mode of a transistor. Cut-off – The transistor acts like an open circuit. No current flows from collector to emitter. Cutoff mode is the opposite of saturation. A transistor
in cutoff mode is off Active – The current from collector to emitter is proportional to the current flowing into t he base. To operate in active mode, a transistor’s V BE must
be greater than zero and V BC must be negative.
34
Reverse-Active – Like active mode, the current is proportional to the base current, but it flows in r everse. Current flows from emitter to collector (not, exactly, the purpose transistors were designed for).
Describe how a multi bit synchronizer / async fifo handles the variable delay of each bit! The standard solution is to encode the pointer into grey-code, where for each incrementation of the pointer, only one bit changes (so the variable delay cannot cause false empty/full glitches as the bits settle). Note that this assumes a power-of two depth FIFO, or the grey-code may flip multiple bits when the pointer hits the nonpower-of-2 top and has to be set to the bottom. Also not that in any standard asynchronous design, it is best not to have any combinational logic before a synchronizer (always have a flop). The reason is that even if you think you know the design is glitch-proof, the synthesis tool could do an strange optimizatino and create a circuit that will glitch when you're not expecting it (and that glitch can get sampled by the sychronizer and result in a false pulse on t he other sie). This can be avoided by writing structural RTL and using DC constraints to ensure your glitch-proof circuit ends up the in netlist (though why not just avoid these cases all together by adding the flop). Also of note, the create an empty signal, the write-pointer has to be converted to grey-code, flopped (see notes above about combinational logic before synchronizers) and then sent through synchronizers in the write-pointer clock domain. The output of the synchronizers then has to be grey-code decoded, so that it can finally be compared to the read-pointer to determine empty. Note, generating the full signal is just the reverse. For power-of two FIFOs, just add one extra bit to pointers tell the difference between full and empty (if the extra bit is 0, and the p ointers are equal, the FIFO is empty, if the extra bit is 1, and the pointers are equal, the FIFO is full). Enough about FIFOs and async-crossings.
Synchronous FIFO verification
A synchronous First In First Out (commonly referred to as FIFO) or a queue is a n array of memory. Generally, it is used when the write and read side logic operate at the same clock frequency. Use Case to buffer data when the burst write operation is larger than the burst read operation or vice versa read operation is delayed with respect to the write
Interfaces A FIFO typically has the following set of signals – Clock and reset Write and Write data Read and Read data Read and Write enable Full and empty (outputs) Scenarios to verify FIFO is a commonly used logic in many designs. The major functional features which have to be ver ified are – Single write and read operations as well as data correctness FIFO transitioning from empty to non-empty and vice versa The transition from non-empty to full and vice versa Burst read and burst write operations up to the maximum depth Empty to full and back to empty Error conditions Write operation when full – The client should wait for the full signal to go low before issuing more writes. Otherwise, the data in the FIFO could be overwritten or dropped. Read operation when empty – The client should wait for the empty signal to go low before issuing a read. Otherwise, the data read will be garbage.
Rising Edge Detector (0->1) Verilog Code
Concept – The concept is to detect a rising edge (signal transition from logic 0 to logic 1). This can actually be done in 2 ways.
Using an AND Gate module positive_edge_detector ( input signal, input clk, output detect); reg signal_delay; //delayed version by 1 cycle always @ (posedge clk) begin signal_dly <= signal; end assign detect = signal & ~signal_delay; endmodule 35
Using an XOR Gate (Efficient) An XOR based solution can actual save an inverter. You can just XOR the flopped version of t he signal (signal_delay) with the original signal. assign detect = signal ^ signal_delay;
Power dissipation in Circuits Types of Power Dissipation
Static Power (also known as Leakage Power) o Static Power is due to the leakage current when the transistor is not in the process of switching.
Dynamic Power (also known as Switching Power) o Dynamic Power is due to switching / logic toggle of transistor.
Short Circuit Dissipation Power : o Occurs when both NMOS and PMOS transistors are active for a small period of time in which current will find a path directly from VDD to ground. Hence, this creates a short-circuit current. This is because there is a finite rise/fall time for both pMOS and nMOS during the transition. o
Design for power :- circuit components Design for power components
1.
Levelshifters Cells:- These cells are used when signals need to traverse between different voltage levels. Commonly different blocks have different voltage modes depending on performance and power requirements. 1. Low to High levelshifter cells :- These cells connect between low voltage to high voltage domains. 2. High to Low levelshifter cells :- These cells connect between high voltage to low voltage domains. 2. Isolation Cells :- These cells are used to isolate the logic which is power collapsed and power on logic. Because power collapsed will output X’s and this unknown digital logic values should not propagate into powered on digital logic. There are different types of is olation cells. Isolation cells can be both of input/output types. 3. Clamp Low Isolation Cell:- When the clamp signal is asserted, then these cells clamp to a Digital 0. 4. Clamp High Isolation Cell:- When the clamp signal is asserted, these cells clamp to a Digital 1. 5. Clamp Keeper Isolation Cell :- These cells clamp to the value previous to the clamp signal assertion. They are like sequential elements. 3. Retention Registers:- In a power collapsed state, the registers which are retain-able will hold the values. These cells will be optimized to work on dual rails and a powered on rail will enable them to hold values. This is used for the system to recover from powered down state. The state and configuration registers can be retained to hold values. 4. Power switches:- Power switches can be used to turn on/off power to a block. These cells cause the power collapse which enables us to save power from leakage and switching activity. This type of architecture is called power gating. Power switches can be PMOS headswitches or NMOS foot switches. They are typically of higher resistance to limit leakage power from voltage rails. 5. LDO (low dropout regulator):- LDO’s are used to regulate voltage and they are quite stable in operation. They are used for voltage scaling. 6.Voltage rail shifters:- These can change the output voltage rail from different input rails. A certain rail can be a higher voltage rail for high performance and other rail can of lower voltage for lower power. Since, changing the voltage of rails is not fast enough and settling time is large. Voltage rail shifters can be used to quickly shift to a lower voltage rail for lower power or a higher voltage rail for higher performance. 7. Clock gating cells:- To save dynamic power, clock gating cells are used which are used to gate the clock to an idle block. There are self gating clocks, they depend on logic which enables or disables clock. It is a kind of feedback loop. Clock power is a significant portion of total power. Typically the concept is when d and q of FF’s remain at constant values, then clock is shut down to save power. This is however at cell level. There will be higher levels of power saving architectures. 8. PMIC:- Typically a power management IC is used to supply voltage rails to chip. The characteristics of these voltage rails are that they are stable, low noise and work in operating margin. PMIC takes in power from a battery or a power source uses converters( such as DC-DC buck/boost, pulse width modulators etc ) . It also performs voltage scaling and power source selection. In some cases, can be used to perform charging device battery.
FIFO depth calculation A commonly asked interview question is to calculate the depth of a FIFO required for a particular data transfer operation. Since a FIFO is used to safely buffer data during the transfer, we need to consider the worst case scenario in order to determine the depth. The need for a FIFO arises when either the read or write operation is slower than the other. The following parameters are required to determine the minimum FIFO size –
Write frequency (freq_write) Read frequency (freq_read)
Write burst size (B)
For simple scenarios, FIFO_Depth = B – B*(freq_read/freq_write)
Example 1
Example 2
freq_write = 20 MHz, freq_read = 10 MHz, Burst = 80 bytes Time taken to write 80 bytes (t1) = 80/20 = 4 us Time taken to read 80 bytes (t2) = 80/10 = 8 us FIFO_depth = (t2 – t1) * Smaller_freq = 4 * 10 = 40 Using the formula, FIFO_Depth = 80 – 80*(10/20) = 40
Same read and write clock frequency, Write burst = 80 bytes in 100 clocks, Read burst = 8 bytes in 10 clocks If there is no burst overlap and considering the worst case burst, No of bytes written in 80 clocks = 80 No. of bytes read in 80 clocks = 8*8 = 64 Hence, FIFO_depth = 80 – 64 = 16 If there is a burst overlap, the maximum write burst can be 160 bytes across 200 clocks and considering worst case burst, No of bytes written in 160 clocks = 160 No. of bytes read in 160 clocks = 8*16 = 128 Hence, FIFO_depth = 160 – 128 = 32
36
// generate 100 Hz pulse chain from 50 MHz reg [18:0] count_reg = 0; reg out_100hz = 0;
// generate 100 Hz from 50 MHz reg [17:0] count_reg = 0; reg out_100hz = 0;
always @(posedge clk_50mhz or posedge rst_50mhz) begin if (rst_50mhz) begin count_reg <= 0; out_100hz <= 0; end else begin out_100hz <= 0; if (count_reg < 499999) begin count_reg <= count_reg + 1; end else begin count_reg <= 0; out_100hz = 1; end end end
always @(posedge clk_50mhz or posedge rst_50mhz) begin if (rst_50mhz) begin count_reg <= 0; out_100hz <= 0; end else begin if (count_reg < 249999) begin count_reg <= count_reg + 1; end else begin count_reg <= 0; out_100hz <= ~out_100hz; end end end
// generate 10 MHz from 250 MHz // 25 cycle counter, falling edge interpolated reg [4:0] count_reg = 0; reg q0 = 0; reg q1 = 0;
// generate 100 Hz from 50 MHz reg [31:0] count_reg = 0; wire out_100hz = count_reg[31];
always @(posedge clk_250mhz or posedge rst_250mhz) begin if (rst_250mhz) begin count_reg <= 0; q0 <= 0; q1 <= 0; end else begin if (count_reg < 24) begin count_reg <= count_reg + 1; end else begin count_reg <= 0; end q0 <= count_reg < 12; q1 <= count_reg < 13; end end
37
always @(posedge clk_50mhz or posedge rst_50mhz) begin if (rst_50mhz) begin count_reg <= 0; end else begin count_reg <= count_reg + 8590; //(((100 * 1 << 32) + 50000000/2) / 50000000) end end
Summary of SystemVerilog Extensions to Verilog SystemVerilog adds important new constructs to Verilog-2001, including: New data types: byte, shortint, int, longint, bit, logic, string, chandle. Typedef, struct, union, tagged union, enum Dynamic and associative arrays; queues Classes Automatic/static specification on a per variable instance basis Packages and support for Compilation Units Extensions to Always blocks for modelling combinational, latched or clocked processes Jump Statements (return, break and continue) Extensions to fork-join, disable and wait to support dynamic processes. Interfaces to encapsulate communication Clocking blocks to support cycle-based methodologies Program blocks for describing tests Randomization and constraints for random and directed-random verification Procedural and concurrent assertions and Coverage for verification Enhancements to events and new Mailbox and Semaphore built-in classes for inter-process communication. The Direct Programming Interface, which allows C functions to be called directly from SystemVerilog (and vice versa) without using the PLI. Assertions and Coverage Application Programming Interfaces (APIs) and extensions to the Verilog Procedural Interface (VPI) – details of these are outside the scope of the SystemVerilog Golden Reference Guide
38
