12-18-2014 12:27 AM
I'm trying to integrate a DDR controller generate using MIG 3.6.1 on ISE 14.7 (nt64) on a FPGA xc3s1400a-4ft256 with a MT47H32M8BP-37E. I'm following the user guide UG086 (v3.6) September 21, 2010 and different threas on the forum to solve various intergration problems. Below a summary to explain the issue:
- The project (user_design) pass the stage of synthesis and translation.
- A simple state machine was defined using the 133Mhz clock from the controller.The state machine have two main trigger signals: INIT and WRITE. When these signals are asserted, the machine run some states to initialize and write a dummy data to the DDR2. Both command are independent and generate by a external microcontroller.
- The INIT command pass and activate the init_done signal
- The WRITE command pass with success, verified with the signals user_cmd_ack, burst_done. The address 0x0 and data 0x0 is used.
- During all the testing, the refresh signals (ddr2_auto_ref_req, ddr2_ar_done) work as expected.
- When I try to execute the WRITE command every 30 ms the state machine get unexpected results after few seconds (random) and the trigger signals to execute the WRITE command is not recognized any more.
- All the test scenario was ran on a development board with the FPGA and the DDR2. The microcontroller is on another development board, controlling the RESET, INIT and WRITE trigger signals for the FPGA.
- The verilog code that show the state machine definition (file "state machine")
- The signals from the scope that show the test scenario and the issue (file "Scope signal list")
- A description table with the signal on the scope (from channel 0 to 15). These signals show the triggers, the DDR2 controller signals and the states of the machine.
The unexpected results is show in the image "Scope signal - issue", where the signal "STATE_debug_temp" is "1" when the state machine is on the state "0x000", according with the design, this is unexpected. After that moment, the commands from the microcontroller are not recognized by the machine and the general RESET is the only way to start again.
Has anyone run into similar situation before. I am not sure where is the problem. Any ideas?
12-18-2014 12:38 AM
To confirm if the issue is not with controller do you see the same behavior with MIG example design ?
Is this custom board or xilinx evaluation board?
Instead of 30ms did you try to increase write frequency and replicate the issue in simulation so that you may try to find out the state of IP when fsm hangs ? Else you may need to add more chipscope siganls to narrow down the issue.
12-18-2014 08:00 PM
Thanks for your quick repply. Below the answer to your questions/suggestions:
With this result, I find out that the refresh command have to be related with this issue. So, I update the state machine adding an extra state after the signal "ddr2_ar_done" is asserted (indicanting the refresh operation is done). With this changed, the issue dissapear.
Attached a image with all the signals (a fastest frequency) showing how the WRITE command is delayed because the refresh commmand is running. The verilog code with the new state machine is attached also.
Thanks and regards
12-19-2014 12:39 AM
Glad that the issue is resolved.
Yes unlike V6 and 7 series which does everything internally and asserts ready siganl, V5 is different in the way you need to monitior the controller status with cntrl0_auto_ref_req and cntrl0_ar_done.
You can start commands as soon as ar_done is pulsed but you should terminate the burst witin few clock cycles after cntrl0_auto_ref_req is asserted, hence it is always good to run the example design simulation just to compare the signal timings which will give a better clue on what is going wrong.
Hope this helps
12-21-2014 04:05 AM
Thanks for the suggestions. I will run the simulations to see how are the signals to complement the User Guide.
I would like to pu this topic as solved, but the option is not visible.