| Author |
Message |
adamsogood
Joined: 15 Jun 2006
Posts: 32
|
 17 May 2007 17:20 mt46v32m16 vhdl |
|
|
|
|
Hi, Gangs,
I am working on DDR memory controller targeting xc4vfx60-10 with MT46V32M16P-5B. The tools is Xilinx MIG17.
First, I designed a memory controller (16bits) for one MT46V32M16P-5B chip only. It is working properly. Then, I designed a memory controller (32bits) for two MT46V32M16P-5B chips. The second one (32 bits) doesn't work.
However, if I download the 16bits memory controller first and then download the 32bits controller, the 32 bits controller starts to work properly.
What could be the problem? FPGA initialization or timing or....???
Please advise.. Thank you..:
|
|
| Back to top |
|
 |
Google
AdSense
|
17 May 2007 17:20 Ads |
|
|
|
|
|
|
| Back to top |
|
|
Iouri
Joined: 17 Aug 2005
Posts: 687
Helped: 79
|
17 May 2007 18:21 mt46v32m16 verilog model |
|
|
|
|
| how is your PCB trace matches?? Do you have proper termination series/pull up resistors?? Is you power lines nice and clean??
|
|
| Back to top |
|
|
adamsogood
Joined: 15 Jun 2006
Posts: 32
|
17 May 2007 18:35 Re: Weird Problem. Help Needed |
|
|
|
|
1. how is your PCB trace matches??
I assumed that they are matched. Because there are 8 MT46V32M16P-5B chips on my PCB. All the other six MT46V32M16P-5B chips working properly.
2. Do you have proper termination series/pull up resistors??
I think so. Because DCI is enabled on the Xilinx FPGA side while proper terminations are put on the DDR memory side.
3. Is you power lines nice and clean??
I assumed they are good enough because there are six MT46V32M16P-5B chip working properly on the same PCB.
thank you for your time. 
|
|
| Back to top |
|
|
banjo
Joined: 24 Dec 2005
Posts: 644
Helped: 118
|
18 May 2007 3:50 Weird Problem. Help Needed |
|
|
|
|
What do you mean, it does not work? What exactly are the symptoms?
I would download both the 16 and 32 controllers so that the system is working. Then get out the scope and start looking at the signals on the 32 bit side. Familiarize yourself with the control signals and clock first. Look at RAS, CAS, CS, WE, and CLK. These should be showing pulses all the time due to refresh cycles. The active portion of the control signal should be roughly centered on the rising edge of the CLK. Look at CKE, or clock enable. It should not be pulsing, but should be a constant active high, I believe. Once you know what all these signals look like when its working, restart the system with only the 32 bit controller. Now look at the signals and see what is missing.
If I had to make a wild guess, I would guess that both versions are attempting to use the same DCMs. However, only the 16 bit version has DCM settings that put the clocks into the right phase. What happens if you load then in the other order. Do both work or both fail?
If the control and clock signals look the same in both the working and non-working cases, then it must be a problem with generating addresses and data or moving these address and data buses within the FPGA. These types of things are more difficult to diagnose. The best method is to force the FPGA into a loop reading or writing the same address. This gives a more stable pattern to look at on the scope.
The fact the the system works with both controllers loaded seems to me to indicate a logic problem within the FPGA. If the 32 bit controller is working solidly when both controllers are loaded, I would think that trace lengths and power lines are in the clear.
How about trying to run just the 32 bit version in ModelSim? This should give you an idea of whether the outputs are toggling correctly and whether it is going through the proper initialization sequence. You can even get Verilog simulation models of the DDR DRAMs for free from Micron. I have used these with great success in simulation. The Micron models can be configured to tell what you did correct and which portions you are violating. The will respond with what it finds on Mode Register set, etc.
|
|
| Back to top |
|
|
adamsogood
Joined: 15 Jun 2006
Posts: 32
|
21 May 2007 14:41 Re: Weird Problem. Help Needed |
|
|
|
|
1. What do you mean, it does not work? What exactly are the symptoms?
I came up with a design which forced the FPGA into a WRITE-READ-loop. Then, no READ DATA comes out for one bank's 32-bit DDR controller. My hardware test is as follows:
1). Hardware Configuration: one XC4VFX60-10 FPGA and eight MT46V32M16-5B DDR chips on the PCB. Each DDR MT46V32M16-5B has 16 bits of data;
2). My 1st controller design is for 16bits only. The 16bits controller is working properly for all of the eight MT46V32M16 DDR chips in terms of the READ DATA from the WRITE-READ loop;
3). My 2nd controller design is for 32 bits only. Two of eight MT46V32M16 DDRs are combined to support 32 bits of data. thus, I got four DDR banks of 32 bits each, i.e., bank1, bank2, bank3, and bank4. Each bank consists of two MT46V32M16 DDR chips. I tested bank1, bank2, bank3 and bank4 indivisually, i.e., only one memory controller (either 16 bits or 32 bits) is loaded into the FPGA every time. The results are: all of the banks are working properly for 16-bits controller; for the 32-bit controller, bank1, bank2, and bank4 are working properly while bank3 not working. For the test code of different banks, nothing changed for the VHDL code but the constraint files of each bank controller design (due to different pin locations). However, if I download bank3's 16-bit memory controller first, then download bank3's 32-bit memory controller to overwrite the 16-bit memory controller FPGA configuration, the 32-bit controller on bank3 starts to be working in terms of WRITE-READ loop;
2. Then get out the scope and start looking at the signals on the 32 bit side.
Sure. It is a good point. I'll keep you posted what's happening.
3.If I had to make a wild guess, I would guess that both versions are attempting to use the same DCMs. However, only the 16 bit version has DCM settings that put the clocks into the right phase. What happens if you load then in the other order. Do both work or both fail?
Yes. both versions are using the same DCMs. .
4. If the 32 bit controller is working solidly when both controllers are loaded, I would think that trace lengths and power lines are in the clear.
You may misunderstand my status here. I only downloaded one controller at a time; the 16-bit controller is always working while the 32-bit controller is working for all banks except bank3. But the 32-bit controller starts to work on bank3 if I download FPGA files as follows: first download 16-bit controller for bank3, then download 32-bit controller to overwrite the 16-bit controller. In a word, each time, only one controller is inside the FPGA.
5. How about trying to run just the 32 bit version in ModelSim? This should give you an idea of whether the outputs are toggling correctly and whether it is going through the proper initialization sequence.
that's a good point. But as I just said before, the 32-bit controller is working for all the banks except bank 3. the only difference for different banks are the pin assignments in the constraint files. this really drive me NUTS...
Thank you for your help...
|
|
| Back to top |
|
|
banjo
Joined: 24 Dec 2005
Posts: 644
Helped: 118
|
21 May 2007 18:53 Weird Problem. Help Needed |
|
|
|
|
Ok, now that we know that all banks but bank three are working in 32 bit mode, the question becomes what is different between banks 1,2,4 and bank 3.
1. Do the banks share the same address, control and data lines? Or is each bank a separate interface? If they share any lines, then these lines can be eliminated as a possibility. In a shared system, only CS, chip select, and CKE, clock enable are often unique to a particular bank. The rest of the signals are often common.
2. If the interfaces are unique, I would start by opening the 32 bit design in FPGA editor. Go to the IOBs and compare the bank 3 signals to the bank 2 signals for stuff like address, control and data.
3. When you overwrite the 16 bit controller with the 32 bit controller, are you doing a full erase, or just a partial reconfigure? It sounds like it is a partial reconfigure only. If this is the case, then I would double and triple check the UCF file. Please be aware that Xilinx does not flag redundant entries in a UCF file. Therefore, later constraints and override earlier ones in the file. I would open the PAR report for the X16 and X32 bit versions and compare the logic family and site number for all signals in bank 3.
3. Simulation can still be useful. You only need to simulate the bank that does not work. If that bank runs fine in simulation, then it really points to a problem with the UCF file. The pin-out and constraints are the portions not used in functional simulation.
|
|
| Back to top |
|
|
