MISCELLANEOUS

HDL to C Conversion

As we discussed in Chapter 6, there is an increasing push toward capturing designs at higher levels of abstraction such as C/C ++ . In addition to facilitating architectural exploration, high-level (behavioral and/or algorithmic) C/C ++ models can simulate hundreds or thousands of times faster than can their HDL/RTL counterparts.

Having said this, many design engineers still prefer to work in their RTL comfort zone. The problem is that when you are simulating an entire SoC with an embedded processor core, memory, peripherals, and other logic all represented in RTL, you are lucky to achieve simulation speeds of more than a couple of hertz (that is, a few cycles of the main system clock for each second in real time).

To address this problem, some EDA companies are starting to offer ways to translate your “ Golden RTL ” models into faster-simulating alternatives that can achieve kilohertz simulation speeds. This is fast enough to allow you to run software on your hardware representation for milliseconds of real run time. In turn, this allows you to test critical foundation software, such as drivers, diagnostics, and firmware, thereby facilitating system validation and verification to occur much faster than with traditional methods.

Code Coverage

In the not-so-distant past, code coverage tools were specialist items provided by third-party EDA vendors. However, this capability is now considered important enough that all of the big boys have code coverage integrated into their verification (simulation) environments, but, of course, the feature sets vary among offerings.

By now, it may not surprise you to learn that there are many different flavors of code coverage, summarized briefly in order of increasing sophistication as follows:

● Basic code coverage : This is just line coverage; that is, how many times each line in the source code is hit (executed).

● Branch coverage : This refers to conditional statements like if-then-else; how many times do you go down the then path and how many down the else path.

● Condition coverage : This refers to statements along the lines of “ if (a OR b == TRUE) then. ” In this case, we are interested in the number of times the then path was taken because variable a was TRUE compared to the number of times variable b was TRUE.

● Expression coverage : This refers to expressions like “ a = (b AND c) OR !d ” . In this case, we are interested in analyzing the expression to determine all of the possible combinations of input values and also which combinations triggered a change in the output and which variables were never tested.

● State coverage : This refers to analyzing state machines to determine which states were visited and which ones were neglected, as well as which guard conditions and paths between states are taken, and which aren’t, and so forth. You can derive this sort of information from line coverage, but you have to read between the lines (pun intended).

● Functional coverage : This refers to analyzing which transactionlevel events (e.g., memory-read and memory-write transactions) and which specific combinations and permutations of these events have been exercised.

● Assertion/property coverage : This refers to a verification environment that can gather, organize, and make available for analysis the results from all of the different simulation-driven, static formal, and dynamic formal assertion-/ property-based verification engines. This form of coverage can actually be split into two camps: specification-level coverage and implementation-level coverage. In this context, specification-level coverage measures verification activity with respect to items in the high-level functional or macroarchitecture definition. This includes the I/O behaviors of the design, the types of transactions that can be processed (including the relationships of different transaction types to each other), and the data transformations that must occur. By comparison, implementation-level coverage measures verification activity with respect to microarchitectural details of the actual implementation. This refers to design decisions that are embedded in the RTL that result in implementation-specific corner cases, for example, the depth of a FIFO buffer and the corner cases for its “ high-water mark ” and “ full ” conditions. Such implementation details are rarely visible at the specification level.

Performance Analysis

One final feature that’s important in a modern verification environment is its ability to do performance analysis . This refers to having some way of analyzing and reporting exactly where the simulator is spending its time. This allows you to focus on high-activity areas of your design, which may reap huge rewards in terms of final system performance.

TABLE OF CONTENTS

HDL to C Conversion

Code Coverage

Performance Analysis