6 

 

2.3  Memory Coverage

Memory coverage answers a number of questions about memories/multi-dimensional arrays being used in your design, including the following:

  1. Did all bits of each addressable memory element toggle from 0 to 1?
  2. Did all bits of each addressable memory element toggle from 1 to 0?
  3. Did every addressable memory element get written?
  4. Did every addressable memory element get read?

Memories/multi-dimensional arrays can have two types of dimensions, packed and unpacked. Packed dimensional information is specified to the left of an array declaration while unpacked dimensional information is specified to the right of an array declaration. Consider the following example:

Multi-dimensional array example

          reg [3:0][2:0] foo[0:15];
        

The memory "foo" consists of three dimensions. The first dimension is an unpacked dimension which specifies that there are 16 addressable memory elements (AME). The number of AMEs are determined by multiplying the unpacked dimension of an array. The second two dimensions are packed dimensions, creating a total of 12 bits for each AME.

Other than getting toggle coverage information for each AME, memory coverage also allows us to easily see which AMEs were written and read during simulation. If all entries of a memory have not been written during a regression run, it could indicate several shortcomings of either the testbench or a logical problem with the write control logic, including, but not limited to, the following:

Potential testsuite or logic problems found when AME write coverage is not 100%

  1. If no AMEs for a given memory were written, it could indicate that the testsuite was never able to get out of bypass mode for that memory.
  2. If fewer AMEs for a given memory were written than were read, it could indicate that there is a read controller issue leading to an underflow issue with the memory.
  3. For memories that act like stacks or use lowest/highest address first write selection scheme, indicates that the memory was never completely filled (may miss out on things like buffer overflow errors)
  4. For memories that are written in a round-robin fashion, indicates that either not enough entries were written (could miss a write pointer wrap bug) or that there is a logical issue by which the write pointer did not properly increment in a round-robin fashion.
  5. If there are "holes" in the write coverage of the AMEs (that is an AME is found to not have been written while those above and below it have been), this could indicate a corner case logic bug or other testsuite issue that needs to be addressed.

Potential testsuite or logic problems found when AME read coverage is not 100%

  1. If no AMEs for a given memory were read, it could indicate that the testsuite was never able to get out of bypass mode for that memory.
  2. If fewer AMEs for a given memory were read than written, it could indicate that a resource allocation issue.
  3. For memories that are written in a round-robin fashion, indicates that either not enough entries were read (could miss a read pointer wrap bug) or that there is a logical issue by which the read pointer did not properly increment in a round-robin fashion.
  4. If there are "holes" in the read coverage of the AMEs (that is an AME is found to not have been read while those above and below it have been), this could indicate a corner case logic bug or other testsuite issue that needs to be addressed.

Currently, Covered simulates all memories/multi-dimensional arrays and its coverage is automatically accumulated during the score command. To see its report information, either specify the -m m option to the report command or bring up the GUI for interactive analysis.

2.3.1 Recommendations

Recommendations

For a design to pass full coverage, it is recommended that the write/read memory coverage for all modules in a design receive 100% coverage. If every AME was not both written and read during simulation, the design has not been fully exercised. Toggle coverage per AME need not receive 100% since a memory element that is written once will not cause toggle coverage to change.


1 |  2 |  3 |  4 |  5 |  6 |  7 |  8 |  9 |  10 |  11 |  12 |  13 |  14 |  15 |  16 |  17 |  18 |  19 |  20 |  21 |  22 |  23 |  24 |  25 |  26 |  27 |  28 |  29 |  30 ]
License: GPL
This Manual was originally created with ManStyle.