Why is there no possible performance improvement with cache upsizing?

Usually, with cache upsizing, we expect to see system performance improvement. However, this is not always the case. There could be several reasons:

  1. The “compulsory”, instead of “capacity”, prevents the performance improvement from cache upsizing. This means the temporal locality and spatial locality offered by cache are not utilized. For example, the program keeps to access new data and there is no data reuse, which can happen in streaming applications; if context switch happens often, then cache flush may happen often and more “compulsory” will occur

  2. In cache-coherent system, there may be 2 caches competing for one copy of data, i.e., “coherence” miss. This can happen when 2 CPUs want to gain the lock or semaphore simultaneously. Increasing cache size will not help performance in this case
  3. Assuming the cache upsizing is achieved by cache line upsizing, then the loading time of a cache line will increase. This in turn increases the cache miss penalty and average memory access time
  4. Assuming the cache upsizing is achieved by increasing associativity, then the hit latency as well as average memory access time may increase. This is because physical implementation of high associativity cache can be hard

Continue reading → Why is there no possible performance improvement with cache upsizing?

What is functional coverage? How to write functional coverage?

100% code coverage does not imply the completeness of verification. A fundamental limitation of code coverage is, it does not consider design specs and event sequences. Functional coverage is used address this limitation.

There are 2 ways to measure functional coverage. The first one is called covergroups, which is usually defined by DV engineers in test bench. See this post for more details.

The second one is called cover property, which is defined by designers. Usually cover properties can be specified inline with RTL, or in a separate file bind to RTL. Unlike assert property, cover property can be used to determine whether or not certain aspects of the designs functionality have been exercised. See this post for how to write cover properties.

How to detect and resolve x-related issues in RTL?

Verilog uses “x” to model the unknown state, but it also introduces potential issues.

The simulation semantics of conditional constructs in Verilog, are not accurate enough to model the ambiguity inherent in un-initialized registers and power on reset values. When the unknown states that are modeled as ‘X’ values become control expressions, these issues are particularly problematic.

In this post, we will cover several techniques to detect and resolve x-related issues in RTL, including:

Jasper Reset
SystemVerilog Assertions / SVA
Gate Level Simulation
X-propagation in RTL Simulation

Continue reading → How to detect and resolve x-related issues in RTL?

How to write SVA?

SVA is an important formal verification tool, that should be mastered by both designer and verification engineers.

Doulos has a page, perfectly illustrate how to write SVAs. We recommend interviewees to fully digest the content in that page.

In addition, SystemVerilog provides various of built-in methods, to aid and simplify SVA writing. We recommend interviewees to refer to this page.