Community
cancel
Showing results for 
Search instead for 
Did you mean: 

Reference Design - Cyclone V Hard Memory Controller with Avalon MM data

Reference Design - Cyclone V Hard Memory Controller with Avalon MM data width expanded for User ECC



Last Major Update

Initial release - January 2014 - Cyclone V DDR3 SDRAM x24, 400MHz, Quartus II v.13.1, DDR3 SDRAM Controller with UniPHY


Introduction

Hard memory controller (HMC) in Cyclone V and Arria V devices has one option that can expand Avalon-MM data width to support User Error Correcting Code (ECC) bits. In this mode, all bits are treated as data bits, and are written to and read from memory. Thus user can also use this to implement nonstandard memory widths such as 24-bit or 40-bit, when ECC is not required. With User ECC, the controller performs no ECC checking.


Design Requirement

To get wider Avalon-MM data width, the Expand Avalon-MM data for ECC must be enabled with the Total interface width of the memory must be as follow in this design:

  • 24 to get Avalon-MM data width of 48 bits
  • 40 to get Avalon-MM data width of 80 or 160 or 320 bits

The Controller ECC must be disabled to use this mode.


 This design will also use some customized module. They are not compulsory to be used to get the wider Avalon-MM data width for ECC, but this reference design will use it to facilitate and demonstrate certain HMC features.This customized module is provided in the attached zip file and their function is explained in the next section.

 The attached customized module is meant to be used only in this reference design. The used for other purposed is under your own risk.


Design Overview

This design demonstrates how to expand Avalon-MM data width of 400MHz DDR3 SDRAM 24-bit UniPHY hard memory controllers to support User ECC on Cyclone V FPGA. Same guidelines are applicable to Arria V hard memory controller. This design is generated in Qsys flow. Simulation model and test bench generated by Qsys will be used to validate the functionality of the hard memory controllers through simulation. Figure below shows the block diagram of this reference design. As part of this process, this reference design will also demonstrate the following:-

  • Example of unidirectional port usage
  • Example of reading and writing to controller's Configuration and Status Register (CSR)
  • Example of error injection through User ECC
  • Example of Controller ECC encoder and decoder validation
  • Example of Controller ECC operation
  • Single bit error (SBE) detection and correction
  • Double bit error (DBE) detection
  • Byte Write / Partial write
  • ECC write back / Controller Auto Error Correction


 As opposed to the existing SBE and DBE injection feature offered by the controller through their Configuration and Status Register, the error injection through User ECC offer a flexiblity on where the error being injected.


Figure below shows the block diagram of this reference design-

Cvrefdesign_block_diagram.png (Click here for image)



cvrefdesign_block_diagram.png


 The drivers are named based on their type and turn to be executed. For example custom_driver_w0 is a write-only driver and get to execute first. Once it is complete, custom_driver_r1 which is a read-only driver will get execute.


Customize Module Description


Custom Driver

The Custom Driver uses the avl_ready to request transaction data from user input request and pass it to slave. When necessary, it will automatically de-assert the user avl_burstbegin bit to ensure transaction data remain correct when slave is not ready. When enabled, the module will also uses the avl_rdata_valid to request expected data from user input expected data to be compare. It then asserts pnf and other status signal according to comparison result.


Custom User Input

The User Input module have the sequential counter which control which ROM address to be access. When requested, it then used the address to request the data from the instantiated ram and pass it out. It also has the counter which control the number of data iteration.


 The ROM instantiated is actually a RAM but the control is hardcoded to do read-only


Custom RAM

The Custom RAM read the user input initialization file and keep it in the array until it being access. When possible, quartus will synthesize the module as a ROM or altsyncram.


Custom Multi Master

The Custom Master simply act as a multiplexer that selects one of the connected masters and forwards their Avalon-MM signals to a single slave. The selection is based on the connected master turn number set in the GUI once the previous selected master asserts their test_complete signal. The module also helps to consolidate and pass it out the connected master’s status.


Custom Traffic Coordinator

The Custom Traffic Coordinator will assert grant signal for each connected module based on their turn number set in the GUI and after the previous granted port assert their release signal. The connected module will use this grant signal as an indicator to start sending their transaction data to the slave. Custom traffic coordinator however, cannot stop the connected module from sending their transaction if they choose to ignore it.


Custom Checker

The Custom Checker consolidates each connected modules status signal and issue final status of the design. In simulation, it will printout the status and stops the simulation as well. To allow it to be connected to active low LED pins, the module also export out the inverted signals of the final status.


Design Operation Flow

Once the reset de-asserted, the operation will start as per following sequence.

  1. custom_driver_w0
  • Write Data + User ECC bits to Bank 0 and Bank 1 with 1 of their bits get flip (corrupted)
    • Write Data + User ECC bits to Bank 2 with 2 of their bits get flip (corrupted)
  1. custom_driver_r1
  • Read back from all bank to ensure corrupted data is written into memory
  1. custom_driver_csr2
  • Verify the current CSR data as per original setting made in GUI
    • Update the CSR to disable User ECC and to enable Controller ECC
    • Verify the updated CSR data
  1. custom_driver_r3
  • Read back from all bank to ensure ECC decoding worked and able to correct single bit error in the read data before it being passed to the user (memory still contain corrupted data)
  1. custom_driver_w4
  • Byte Write to Bank 0 to trigger read/modify/write to correct the corrupted data in memory (Controller Auto Error Correction are disabled)
    • Example waveform of Byte Write from this design and some details is explained by Byte_write.pdf
  1. custom_driver_csr5
  • Verify the current CSR data and ensure the SBE Count, DBE Count, and Last Error Address is updated based on last read and write operation
    • Update the CSR to clear the counter and enable the Controller Auto Error Correction
    • Verify the updated CSR data
  1. custom_driver_r6
  • Read from Bank 1 to trigger Controller Auto Error Correction to correct the corrupted data in memory
    • Example waveform of ECC write back / Controller Auto Error Correction from this design and some details is explained by Ecc_write_back.pdf
  1. custom_driver_csr7
  • Verify the current CSR data and ensure the SBE Count, DBE Count, and Last Error Address is updated based on last read operation
    • Update the CSR to disable Controller ECC with Auto Error Correction and enable back the User ECC
    • Verify the updated CSR data
  1. custom_driver_r8
  • Read from Bank 0 and Bank 1 to verify all data in memory has been corrected and ECC encoding worked
    • Read from Bank 2 to ensure all data with DBE remain not corrected


 The above sequence is controlled by the custom_coordinator_0 and custom_multi_master_0 modules.

 There are 2 ways to correct the corrupted data in memory. Through the Controller Auto Error Correction or through Byte Write operation. The difference is that the Controller Auto Error Correction perform the error correction as soon as it can and will delay all controller pending activities until the correction completes while Byte Write can be schedule at desired time for better system efficiency.

 The above Byte Write example is with Controller ECC is enabled where ECC code will be automatically updated. However in User ECC mode, user need to make sure the ECC code remain valid after the Byte Write operation.

 You can check the respective initialization file documentation below to get more details on each driver operation

Version history
Revision #:
1 of 1
Last update:
‎06-26-2019 10:47 PM
Updated by:
 
Contributors