Version Found: MIG 7 Series 1.8
Version Resolved: See (Xilinx Answer 45195)
There is a known issue with the user design top-level wrapper when the ECC logic is enabled that causes the controller to freeze when a read-modify-write operation is issued. The failure signature of this issue is that the initial read is performed correctly, but the subsequent write does not occur. Instead, the controller unexpectedly returns the read data on the UI interface by asserting app_rd_data_valid. Shortly afterward, the controller hangs, observed as a permanent desertion of the app_rdy signal.
The reason for this is that two of the ECC parameters (MC_ERR_ADDR_WIDTH and ECC_WIDTH) are defined incorrectly in the user design top-level wrapper. These parameters are set statically in the top-level user design and for some configurations are set incorrectly, causing the behavior described above. They should be set dynamically, similar to how they are done in the example_design.v/.vhd. To work around the problem, replace the MC_ERR_ADDR_WIDTH and ECC_WIDTH parameter definitions in the top-level user design with the following equations:
localparam C0_MC_ERR_ADDR_WIDTH = ((C0_CS_WIDTH == 1) ? 0 : C0_RANK_WIDTH)
+ C0_BANK_WIDTH + C0_ROW_WIDTH + C0_COL_WIDTH
localparam C0_ECC_WIDTH = (C0_ECC == "OFF")?
0 : (C0_DATA_WIDTH <= 4)?
4 : (C0_DATA_WIDTH <= 10)?
5 : (C0_DATA_WIDTH <= 26)?
6 : (C0_DATA_WIDTH <= 57)?
7 : (C0_DATA_WIDTH <= 120)?
8 : (C0_DATA_WIDTH <= 247)?
9 : 10;
Note: In multi-controller designs, C0 will need to correspond to the number of memory controllers (i.e. C0, C1, C2, etc.)
03/05/2013 - Initial release