UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
9,601 Views
Registered: ‎12-17-2014

Using MIG Controller get unexpected results

Hello,

 

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:

 

Scenario:

 

- 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.

 

Issue description:

 

- 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.

 

Attach files:

 

- 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?

 

Thanks

 

Julio

 

Scope signal - issue.png
Scope signal list.png
Scope signals - memory refresh.png
Scope signals.png
Scope signal list.png
0 Kudos
5 Replies
9,608 Views
Registered: ‎12-17-2014

Re: Using MIG Controller get unexpected results

I attach the verilog code with the state machine definition.

0 Kudos
Xilinx Employee
Xilinx Employee
9,593 Views
Registered: ‎07-11-2011

Re: Using MIG Controller get unexpected results

Hi,

 

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.

 

---------------------------------------------------------------------------------------------
Please do google search before posting, you may find relavant information.
Mark the post - "Accept as solution" and give kudos if information provided is helpful and reply oriented
9,572 Views
Registered: ‎12-18-2014

Re: Using MIG Controller get unexpected results

Hi,

 

Thanks for your quick repply. Below the answer to your questions/suggestions:

 

  • No, I didn't use the example design. I need a very simple design to demostrate the write and read operations independelly (teaching purporse). The example design is out of that range. 
  • It's a proven board: http://www.dlpdesign.com/fpga/hsfpga.shtml
  • I changed the WRITE frequency and get similar results. However, this test results show that:
    • Low frequency (period of 100ms each WRITE) the issue take longer to appear.
    • High frequency (period of 10ms each WRITE)  the issue appear fastest.

 

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

 

Julio

 

 

 

 

Scope signals - withput issue.png
0 Kudos
Xilinx Employee
Xilinx Employee
9,561 Views
Registered: ‎07-11-2011

Re: Using MIG Controller get unexpected results

Hi,

 

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

-Vanitha 

 

 

---------------------------------------------------------------------------------------------
Please do google search before posting, you may find relavant information.
Mark the post - "Accept as solution" and give kudos if information provided is helpful and reply oriented
9,504 Views
Registered: ‎12-18-2014

Re: Using MIG Controller get unexpected results

 

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.

 

Thanks,

0 Kudos