I am trying to reconcile the RAMtester example simulation results with the timing diagrams found in the MIG user guide.
I have the following questions:
[LIST=1]
*]Are the addresses specified by app_af_addr [30:0] word vs byte addresses? The simulation increments the address by 4, which if byte address is on longword, if word address is 2 longwords.
*]In figure 9-12 (Page 390), the timing diagram shows app_af_wren asserted along with app_af_addr and ap_wdf_wren. In the RAMtester simulation, both ap_af_wren and ap_af_addr are offset by one clock cycle. (I’ve attached a snapshot).
*]The 9-12 timing diagram latches in 4 distinct address. The RAMtester only latches 2. Both examples are supposedly for Writes with a burst length of 4.
[/LIST]
Help!!!
RAMTester_MIG_WRITE_BURST.jpg (48.9 KB)
@pmeyeratdatest-- Please refer to the Xilinx MIG User Guide. The app_af_addr is described in Table 11-3 with the other User Interface Signals. In general, you should find that nothing is a byte address. Nothing happens at byte resolution.
Figures 11-10 and 11-11 show the timing diagrams for the user interface read/writes with Four-Bursts.
(Ref MIG User Guide UG086 (v2.0) September 18, 2007)
So I am using MIG UG 086 (V3.3) December 2, 2009 as my reference.
So if I understand what you are saying: the addressing sequence should be for a burst length 4:
A0 0x00
A1 0x04
A2 0x08
A3 0x0C
The addresses themselves are word and not byte address (31 instead of 32 bits).
So why does the RAMTester simulation show only two address? Are you limiting the amount of data simply because of the limits of ok interface? Should I discard the RAMtester as a reference and only use the MIG timing diagrams? 
[QUOTE=Opal Kelly Support;2688]@pmeyeratdatest-- Please refer to the Xilinx MIG User Guide. The app_af_addr is described in Table 11-3 with the other User Interface Signals. In general, you should find that nothing is a byte address. Nothing happens at byte resolution.
Figures 11-10 and 11-11 show the timing diagrams for the user interface read/writes with Four-Bursts.
(Ref MIG User Guide UG086 (v2.0) September 18, 2007)[/QUOTE]
FYI:
I built code around the protocol as described in the timing diagrams found in the MIG UG. This seems to work, and also seems to have fixed the problem of “stuck” data within the MIG itself not clearing through to the DDR2 IF.
@pmeyeratdatest-- I’m not sure what you mean about throwing out the RAMTester sample and only using the MIG. RAMTester uses the MIG to do its work, but RAMTester is a sample, not a reference. The reference for the MIG is the MIG documentation. RAMTester is a sample that we have included to show how our FrontPanel SDK can be used (along with MIG) to read/write the DDR2 on the XEM5010.
Yes, for MIG reference, you should use the MIG documentation from Xilinx.
Can you elaborate on the problem of “stuck data” you mention? I don’t see a reference to that previously.
I think it’s important to recognize that, when writing to the APP_* interface, you’re actually writing to command and data FIFOs within the MIG. These FIFOs get parsed, when able, for actual DDR2 operations.
