MIG user interface questions

[creedxlnx]

I am attempting to use the User Interface to send 32 bits of data across the
128 bit app_wdf_data bus.  I then want to read it back.

I've built a dummy design to try to get things working on my board.  My
understanding for completing a write transaction is:

0. wait for init_calibration complete to be asserted.
1. wait for app_rdy to be asserted. this tells me that the MIG is ready to accent a command.
2. when app_wdf_rdy is asserted, put out my app_cmd (3'b000 for  write), app_addr, app_en
    and app_wdf_data.  While app_rdy is from the MIG is asserted, I also need to assert
    app_wdf_wren and app_wdf_end.  As long as app_rdy from the MIG is hi, I can continue
    to update app_addr and app_wdf_data.
3. Attached is waveform capture of my writes.  It's not all of the data I intended to write, but
    it looks to me like at least some of the data I wanted to write should be getting sent out to
    the SDRAM.

For reads, my understanding is:

0. If init_calibration is complete, wait for app_rdy to be asserted  so that I know the MIG
    is ready to accept a command. 
1. If app_rdy is asserted, put out app_en, app_cmd (3'b001 for a read) and app_addr with
    the same addresses that were written to previously.
2. Once the read command has been sent, some number of clock cycles later, app_rd_data_end,
    app_rd_data_valid will be asserted to indicate that the data on app_rd_data is my data
    coming back from memory.
3. Attached is a waveform capture showing my read transaction.  While things aren't lined up,
    I do see valid addresses being sent and data coming back, but it's not the data I believe I
    wrote.

Questions:

0. Is my approach to doing wries and reads correct?

1. on the writes, I originally was incrementing my address by one, but in the kc705 reference design
    it looks like the address is being incremented by 8.  Can I increment by one or is the address
   increment a function of the amount of data to be written on each cycle? 

1. I currently have app_wdf_mask set to 16'h0000, but I could set it to 16'hfff0 since I'm only
    interested in the lower 32 bits of the app_wdf_data bus.  Is that correct?

2. What controls when app_rd_data_valid and app_rd_data_end are asserted?  Will the MIG allow me   
    read form an address I haven't written to previously?

[gszakacs · Accepted solution]

Questions:

0. Is my approach to doing wries and reads correct?

You seem to be a bit confused on the writes.  In your bullet 2., you seem to confuse app_rdy and appwdf_rdy.  MIG essentially has two input FIFOs.  One FIFO takes commands and address.  That one can only be written when app_rdy is asserted.  The other FIFO takes only write data.  It can only be written when app_wdf_rdy is asserted.  When you enter a write command into the command/address FIFO, the data for that write should be available in the write data FIFO.  For a 7-series DDR2/DDR3 MIG application with 4:1 device to user clock ratio, there will be only one data word at the user interface for one write command.  In this case, every word is the "last" word, and it can be written on the same clock cycle as you write the command, but this implies that both app_rdy and app_wdf_ready are asserted on that cycle.  Each write command causes one complete burst of 8 writes to the external memory, so the user data must be 8 times the external device width.  If you are using the 4:1 clock ratio this means a single data word at the user interface is 8 times the exernal device width.  If you use the 2:1 ratio then two words at the user interface make up the burst so each word is only 4 times the external device width.

1. on the writes, I originally was incrementing my address by one, but in the kc705 reference design
    it looks like the address is being incremented by 8.  Can I increment by one or is the address
   increment a function of the amount of data to be written on each cycle? 

The amount of data to be written in each write command is always one complete burst.  For DDR2/DDR3 memory the burst size will be 8, so the address must be a multiple of 8 (low 3 bits always zero).  If you want to write less than the full burst, place the data within the user data word in the position you want and set the appropriate mask bits to zero.  Only data bytes corresponding to the zero bits in the mask word will be written, and other bytes will retain their previous value.  Writing to an address with a non-multiple-of-8 address can result in strange rotation of the data because the memory devices only increment the address modulo 8 during a burst (i.e. the burst wraps from 7 to 0 rather than incrementing the upper bits to make 8).

[creedxlnx]

Thanks.  I now see my data coming back on app_rd_data with the app_rd_data_valid.

I think I should see more data than I do, but I am seeing what I wrote getting read back.

Thanks again.

[saijulukose]

@creedxlnx  hyyyyy  am not able to get the initcalib complete high also app_rdy  not able to figure out what is the issue?? probably reset?? 

[creedxlnx]

Are you looking at this in simulation or on the hardware?

[saijulukose]

@creedxlnxi tried it in both simulation and hardware today i got app_rdy signal still no trace of init_calib_complete

[creedxlnx]

I don't think I can be much help since I was able to get init_calibration_complete without doing anything. 

https://www.xilinx.com/support/answers/51954.html  goes through process of reaching init_calibration_complete.

The reason I asked the sim/hw question is that reaching init_calibration_complete in sim takes a long time.  There is a parameter you can set to skip it.  The following thread talks about it: https://forums.xilinx.com/t5/Memory-Interfaces/MIG-quot-init-calib-complete-quot-signal-does-not-go-high-during/td-p/375673

Good luck.

[saijulukose]

@creedxlnx i am getting the app_rdy signal high from the core so now i can start writing data to ddr right???

[creedxlnx]

It's been a while since I've looked at this, but I don't believe you can do anything until init_calibration_complete has been asserted.

[varunrajendran]

@creedxlnx   I am also trying to use the user interface for R/W access in DDR. But I am unsuccessful in doing. Could please provide me the logic which you did for proper R/W.

[creedxlnx]

@varunrajendranThis is going back a while, but I remember that I abandoned this approach. While I was able to read/write data, there was an issue with app_wdf_rdy and app_rdy which resulted in some data getting dropped.  Xilinx is aware of the issue, but I don't know if later versions of the MIG addressed the problem.  I would suggest looking at the UI design that is generated by IP Core Gen and modifying it to suit your needs.