Hello, hope I'm not out of line asking this here. I've read through PG150 and UG586, I've used ILA, and yet I have problems with (title). Let me elaborate:
I'm using an Arty-S7 board with the 2 Gbit x16 DDR3 module. (The module on my sample is a PMF511816EBR-KADN, not a Micron MT41K128M16-125 unit as suggested in the Arty refman. If relevant -- as some timings differ -- I can attach both datasheets, as the former is difficult to find.) I've set up the MIG IP to interface with the memory, as so (versus Digilent's recommended part of MT41K128M16XX-15E):
Of course, as stated in the MIG docs (PG150 and UG586), only burst length of 8 is supported, but I want to use nCK_PER_CLK=2, as that gives a higher ui_clk (this would be preferred for some other parts of my design).
I've set up my design so that every BL8 write (of 128 bits) is followed by a BL8 read. If the read and write data match, the address is increased and the next 128-bit packet is written. If not, an error bit is raised (also, the design loops indefinitely at this point as the read data is never equal to the data written).
I've outlined my frustrations already on Xilinx's own support forums, but those seem to be less active than Digilent's: https://support.xilinx.com/s/question/0D52E00006sD5uWSAS/understanding-mig-with-bl8-and-nckperclk-2 The posts here show how I execute read commands, and the last post shows the timing of the write commands. Evidently I must be doing at least something correctly, as most of the application runs "only" hit a problem at least as low as address 0x40. Here's an ILA snap of when things go sour:
Notice I am attempting to write 0x2b35a8b2079e4f05f0d39e1e711e9d37 (of course divided into two 64-bit values, as seen in app_wdf_data), and the previous burst of writes was 0x55b89069096fe4f27a2a4afd930a93b5 (see the initial state of r128_ddr_rd_buffer, as seen on the very top, which matches with r128_2_rx_buff[1], as seen in third place from the bottom) but the read data is completely incomprehensible. At no point in the application run was "0x0c4c8592009551480da1d2d9bd68a5e1" (the data read from MIG) written, yet MIG calmly asserts app_rd_data_valid and app_rd_data_end one clock period later.
I would appreciate anyone with knowledge of MIG's workings chiming in, as I am currently out of ideas, other than trying to change nCK_PER_CLK to 4 and attempting 4:1 mode, but my gut tells me I might be doing something elementary very incorrectly. I can provide code or code snippets or pseudocode as requested, along with the aforementioned memory datasheets.
Thanks in advance!
--jb
Edited by jb9631 corrected RAM timings of PM module, added Micron module timings as comparison
Question
jb9631
Hello, hope I'm not out of line asking this here. I've read through PG150 and UG586, I've used ILA, and yet I have problems with (title). Let me elaborate:
I'm using an Arty-S7 board with the 2 Gbit x16 DDR3 module. (The module on my sample is a PMF511816EBR-KADN, not a Micron MT41K128M16-125 unit as suggested in the Arty refman. If relevant -- as some timings differ -- I can attach both datasheets, as the former is difficult to find.) I've set up the MIG IP to interface with the memory, as so (versus Digilent's recommended part of MT41K128M16XX-15E):
Of course, as stated in the MIG docs (PG150 and UG586), only burst length of 8 is supported, but I want to use nCK_PER_CLK=2, as that gives a higher ui_clk (this would be preferred for some other parts of my design).
I've set up my design so that every BL8 write (of 128 bits) is followed by a BL8 read. If the read and write data match, the address is increased and the next 128-bit packet is written. If not, an error bit is raised (also, the design loops indefinitely at this point as the read data is never equal to the data written).
I've outlined my frustrations already on Xilinx's own support forums, but those seem to be less active than Digilent's: https://support.xilinx.com/s/question/0D52E00006sD5uWSAS/understanding-mig-with-bl8-and-nckperclk-2 The posts here show how I execute read commands, and the last post shows the timing of the write commands. Evidently I must be doing at least something correctly, as most of the application runs "only" hit a problem at least as low as address 0x40. Here's an ILA snap of when things go sour:
Notice I am attempting to write 0x2b35a8b2079e4f05f0d39e1e711e9d37 (of course divided into two 64-bit values, as seen in app_wdf_data), and the previous burst of writes was 0x55b89069096fe4f27a2a4afd930a93b5 (see the initial state of r128_ddr_rd_buffer, as seen on the very top, which matches with r128_2_rx_buff[1], as seen in third place from the bottom) but the read data is completely incomprehensible. At no point in the application run was "0x0c4c8592009551480da1d2d9bd68a5e1" (the data read from MIG) written, yet MIG calmly asserts app_rd_data_valid and app_rd_data_end one clock period later.
I would appreciate anyone with knowledge of MIG's workings chiming in, as I am currently out of ideas, other than trying to change nCK_PER_CLK to 4 and attempting 4:1 mode, but my gut tells me I might be doing something elementary very incorrectly. I can provide code or code snippets or pseudocode as requested, along with the aforementioned memory datasheets.
Thanks in advance!
--jb
Edited by jb9631corrected RAM timings of PM module, added Micron module timings as comparison
Link to comment
Share on other sites
7 answers to this question
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now