Web Statistics

Validation, Test and Performance Characterization of DDR Memory Subsystems

                                                                                                       Questions?  Contact us!

Our DDR4 Performance Metrics are events counted on every rising clock edge of the DDR Memory system clock. This real time measurement is the only way to accurately characterize a memory subsystem.  Here are the metrics we have chosen to measure and why.  Got any new ones you would like to see?  Contact us!  Request the DDR Detective® Data Sheet and check out our video!

Command Bus Utilization Analysis by Bank and by Rank(click for pic!)

This covers all DDR4 commands (24 specific types), broken down by Rank and Bank and by channel.   The display will display rates (events per second) or percentages (used cycles versus total cycles, or versus CKE qualified cycles)  of any type of command(s).

WHY Measure this? 

  • To identify system hot spots.
  • Verify the traffic is what you would expect given the software you are running.
  • To look for write optimization (writes much faster than reads).
  • To see if infrequent transactions are ever occurring.
  • To verify bandwidth calculations (ex. Is a memory test really stressing the system?).

Bus Modes Analysis (click for pic!)

This covers 11 different DDR4 modes, plus clock stop times, broken down by Rank.  Includes the following bus states or modes: Reset, Idle, Active, Precharge Power Down, Active Power Down, Maximum Power Down Mode, Self-Refresh, DLL Disable, Write Leveling, MPR Mode (AKA Read leveling or Read training), and  VREF Training Mode.  The display can show the Amount of Time spent in each mode as Time (time per second) or percentages (used time versus Elapsed time).

 WHY Measure this? 

  • General Verification of the JEDEC specified modes of operation.
  • To quickly look for infrequent events.
  • Gives Engineers a relative measure as to how often various modes are entered and for what length of time the system spends in these overhead states.
  • A quick analysis of no boot scenarios.
  • To isolate problems in Memory Validation.

Power Management Analysis (click for pic!)

This collects all the power related information in one place: Refresh, SRE, SRX, Prech PDE, Active PDE, PDX commands, Idle, Active, Prech PD, Active PD, Self Refresh, Deep Power Down and DLL Disable.  The display can calculate and show rates (events per second) or percentages (used cycles versus total cycles, or versus CKE qualified cycles) and can break down these numbers on a Channel, Slot, or Rank basis.   The display can show Amount of Time spent in each mode, as Times (time per second) or percentages (used time versus Elapsed time) and can break down these numbers on a Rank basis.

 WHY Measure this? 

  • General Verification of the JEDEC specified power and refresh modes of operation
  • To quickly look for infrequent events.
  • Gives Engineers a relative measure as to how often the system enters and exits power saving mode
  • Power Saving Performance measurements can be made and engineers can see if the system really is saving any power.
  • To isolate problems in Memory Validation as these states are often associated with loss of state (data corruption) in the memory.

Data Bus Utilization Analysis (click for pic!)

Data bus utilization can be expressed as rates (MB Per Sec) or as percentages (used cycles versus total cycles, or versus CKE qualified cycles) and these can be broken down on a per-direction (read/write), per-channel, per-Rank, or Per-Bank basis. OTF (on the fly) is handled properly in the calculations.

WHY Measure this? 

  • This is the heart of any Memory subsystem performance measurements.  How much data can be passed within certain time limits.  
  • Verify the traffic is what you would expect given the software you are running and if you are running a memory test to see if the system is being stressed.
  • To discern read performance from write performance and to help optimize software.
  • To compare various memory controller/DRAM designs to see which one runs faster on an actual hardware level.
  • Latency:  Faster throughput means smaller latency and latency is a big performance issue.

Page Hit Analysis (Click for pic!)

Hits, Misses and Unused Pages are detected.  This can be broken down on a per-direction (read or write), per-Channel, per-Rank or per-Bank basis.  A personal favorite of the FuturePlus team this metric gives never seen before insight into page allocation analysis of the memory controller.  This is a key performance metric for high performance systems!

WHY Measure this? 

  • A page is an allocated space in memory that the controller must 'open' prior to reading or writing to.  If pages are allocated and never used performance and power is wasted.  Measuring this gives insight into various page allocation algorithms. 
  • Software targeting different applications can act very differently with regards to memory page allocation. By understanding this metric different memory architectures and software can be designed for a better performance match.
  • To compare various memory controller/DRAM designs to see which one runs faster with various software applications.

Multiple Open Banks Analysis (click for pic!)

This analysis counts the amount of time that specific numbers of banks are open simultaneously, and works through bus Active, and Active Power-Down modes of bus operation.  The display can show total times (total states per second) or percentages (used states versus elapsed time), and can break down these numbers on a Channel, Slot or Rank basis.

WHY Measure this? 

  • Similar to the Page Hit Analysis this measurement gives insight into power/performance trade offs.  A bank must 'open' prior to reading or writing to.  If it is closed to soon it must be reopened causing a performance hit. 
  • Software targeting different applications can act very differently with regards to memory allocation.  By understanding this metric different memory architectures and software can be designed for a better power savings and performance match.
  • To compare various memory controller/DRAM designs to see which one runs more efficiently by having optimal bank open/closed operation. 
  • To identify power hot spots as open banks burn power.

Bank Utilization  Analysis (click for pic!)

The display can show the Amount of Time or Cycles (per second) that each bank is Active (or conversely, as Precharged), or as percentages (Acive time versus Elapsed time, or Active Cycles versus Qualified Cycles), and can break down these numbers on a Rank basis.

WHY Measure this? 

  • To identify system hot spots.
  • Verify the traffic is what you would expect given the software you are running.
  • To look for underutilized portions of memory (why have it if it never gets used!).
  • To verify if diagnostic software is really touching every bank.

 Bank Group  Analysis (click for pic!)

This analysis looks at consecutive read/write operations to see how many stay within the Bank Group, which is favored, for performance. The display can calculate and show rates (events per second) or percentages (counts in one category vs the sum of counts in all categories) and can break down these numbers on a Channel, Slot, or Rank basis. The 8 categories are: Rd to Rd same group, Rd to Wr same group, Wr to Wr same group, Wr to Rd same group, Rd to Rd different group, Rd to Wr different group, Wr to Wr different group, Wr to Rd different group

WHY Measure this? 

  • NEW for DDR4 Bank Groups contain multiple Banks and cannot be accessed with back to back transactions.
  • Memory Controllers have the ability to tweek internal operation values to 'Bank Group tune' a memory subsystem.  This metric can show if optimization has been reached.
  • To compare various memory controller/DRAM designs to see which one runs more efficiently by having optimal bank open/closed operation. 
  • To verify if diagnostic software is really stressing the system with back to back transactions by alternating bank groups.