Last Major Update
Initial release - January 2014 - Cyclone V DDR3 SDRAM x24, 400MHz, Quartus II v.13.1, DDR3 SDRAM Controller with UniPHY
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.
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:
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.
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:-
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)
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.
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.
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
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.
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.
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.
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.
Once the reset de-asserted, the operation will start as per following sequence.
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