unfortunately I have problems with DDR SDRAM Controller. I have an Avne board with Xilinx Virtex-II FPGA (xc2v4000-ff1152)and Micron DDR SDRA DIMM (MT4VDDT1664HG). I am using opencores DDR SDRAM controller. I hav already adapted it and simulation with ModelSim works fine but I have rea problems with the board. I synthesize and implement my design with Xili Project Navigator 7.1 and upload it to my FPGA, also I used ChipScope t track signals. The controller just does not work. All signals seem t drive as they should during writing. During reading I see all zeros o just rubbish on data bus. I tried to change timing parameters but they don't affect.
The first thing I would check is your clock distribution. Make sure the clock to the DIMM and the FPGA have the same phase. Use a scope. Chipscope is O.K. for FPGA internals debug, but a real oscilloscope is the only way to make sure your signals reach the external parts as expected.
Also make sure your FPGA pinout matches the Avnet board. Are you using a UCF file provided with the board?
Also, the Micron models don't all check the initialization sequence required to start up the memory. Be sure your code provides the correct warm up period before your initial SDRAM access. This is especially important if the FPGA is driving the clock to the SDRAMs.
As far as I know I can not look at clock signals with Chipscope (I als can not track DQS signals because they rise only for half a clock period) I tried to do it and I got warnings from Chipscope. I ignored them but could not implement my design (translate or map was failed due t Chipscope module). After I read somewhere it's impossible with Chipscope Am I missing something?
You are right I could not be sure that my signals reached the externa parts as expected and I do not have a real oscilloscope to check it. could only hope than it's not a case.
My FPGA pinouts match the Avnet board indeed. Sure I am using a UCF fil provided with the board. I also checked memory initialization sequenc before I posted the first message:) It works as it should according t Micron's data sheet.
I am just a bit confused - among all nets in original UCF file I hav CLK_DDR_FB_IN and CLK_DDR_FB_OUT. In my design I am using onl CLK_DDR_FB_IN for giving my feedback signal to DDR. Should I use both? do not see any reason for it.
Usually the reason for a feadback net is to match board-level delays, so you can automatically adjust your clock phase. Look at the board schematic and see how these nets are hooked up. Maybe you need to drive CLK_DDR_FB_OUT to the DIMM. Which board are you you're using? A quick look at the Avnet site turned up a lot of boards with FG456 package Virtex-II parts, and some with Virtex-II Pro in the FF1152 package.
This post pertains to a DDR SDRAM controller that works perfectly for 95% of DIMMS used, and is part of a test system that contains a 2+ GHz oscilloscope monitoring the clock, command, and dqs signals at the DIMM pins.
Several DIMMs seem to operate incorrectly only occassional (possibly temperature dependent), and I suspect that the issue is some type of timing requirement that is on the edge of met and violated. When the incorrect behavior is seen the scope verifies that write cylces are operating correctly but that the read cycles are not operating correctly. Durring the read cycles the active command is issued, then the read command (satisfying Trcd) and accordingly the DQS signals are provided by the DIMM. Here is the catch; bursts of 8 was specified durring initialization and the DQS signals durring correct operation correspond to this choice; however, but durring the failing read cycles I will see sometimes 1 DQS rising edge, sometimes 2 and sometimes even 5 rising edges! My questions are as follows:
1) Has anyone with DRAM exprience seen any behavior like this before?
2) ** What might cause a DDR module to provide a varying number of DQS strobes? **
Recall that the design has no blatent errors since for most DIMMs no errors are ever seen.
This post pertains to a DDR SDRAM controller that works perfectly for 95% of DIMMS used, and is part of a test system that contains a 2+ GHz oscilloscope monitoring the clock, command, and dqs signals at the DIMM pins.
Several DIMMs seem to operate incorrectly only occassional (possibly temperature dependent), and I suspect that the issue is some type of timing requirement that is on the edge of met and violated. When the incorrect behavior is seen the scope verifies that write cylces are operating correctly but that the read cycles are not operating correctly. Durring the read cycles the active command is issued, then the read command (satisfying Trcd) and accordingly the DQS signals are provided by the DIMM. Here is the catch; bursts of 8 was specified durring initialization and the DQS signals durring correct operation correspond to this choice; however, but durring the failing read cycles I will see sometimes 1 DQS rising edge, sometimes 2 and sometimes even 5 rising edges! My questions are as follows:
1) Has anyone with DRAM exprience seen any behavior like this before?
2) ** What might cause a DDR module to provide a varying number of DQS strobes? **
Recall that the design has no blatent errors since for most DIMMs no errors are ever seen.
snipped-for-privacy@web.de, Related to DQS and DQ. I can not really know! I could just guess. I thin it was clear from my previous post.
2Gabor, Thanks. I am using an Avnet Xilinx Virtex II Development Board-XC2V4000-FF115 board (it has ADS-XLX-V2-DEV4000XP product code). I was running different tests but still can not get why it does not work I just read some kind of random data.
I don't know the controller you're using, nor your board. But my experience with ddr and ddr-controllers is that somewhere you have a DCM to generate the read clock and that DCM has a phase-shift and you need to adapt this timeshift according to your board (you can just try some value, find the lowest for which it work, then the highest and finally take a value in the middle ...)
As far as I know there are two main schemes for DDR controller mainly adopted with virtex-4 (and virtex-2 , I think). One is that with the delay compensation line made from the ddr_clk_p line, fed back to fpga (in a clock bank): if I'm not wrong, this is the method adopted in opencores controller (and also by microblaze opb bus ddr controller with virtex-4). The second scheme has a dedicated line for delay compensation: look at your board schematics! From your citation or your board ucf file, I think this is the scheme adopted by you dev board. There's an output pin (CLK_DDR_FB_OUT) and an input pin (CLK_DDR_FB_IN): they are shorted with an appropriated length net (for compensating delay). This is the method I found in xilinx MIG. I'm not very experienced with ddr controller, but I think that there are hardware discrepancies between the two schemes (the delay length are different, if I'm not wrong) and perhaps also hdl descriptions are not directly reusable: perhaps they can be easily adjusted, but I don't really know. Opencores controller, in my opinion, is quite well described and very simple also for a newbie as me; but due to performances (I'm using on virtex-4) I focused my attention to xilinx website designs (using mig 1.4 ... poorly documented, in my opinion, for ddr - much better on ddr2). The fact that with chipscope you experience read problems, let me think that the problem is just in the feedback scheme/delay. If I've understood, this is just the re-syncronization trick for readings.
Hope this may be useful to you and sorry if I've written some inaccuracies. Regards,
When you do a read, DDR (unlike other memory) drives not only the bus but also the strobes (as you are clearly know). What you may not know is the amount of variance there can be between devices on the DQS data jitter and DQS (read) - clock variance.
For those DIMMs you are having problems with, the issue is very likely that DQS is being asserted outside your timing window (so the device is, in fact, asserting a burst of 8 - you simply are not catching it).
I have seen this behaviour using commercial parts with DDR controllers built in - the programmable parameters such as DQS skew being there to get around issues just such as this.
The causes for this are usually either poor clock/data termination (and in DDR you have to have something even if it's only series, which is do-able in point to point), excessive round trip delay on the clock, excessive added data skew (across D0-Dn vs. DQS) or excessive skew on DQS vs. clock (which moves DQS as received away from the clock) as seen at the receiver.
In addition, DDR is not specified to operate below certain speeds, although *most* will. This is a classic gotcha where the internal DLLs won't properly lock to generate read DQS appropriately.
The temperature dependency is perhaps to be expected - all logic devices tend to operate a little slower (edge response in particular, but propagation delay tends to increase as well), thus increasing the amount of time before a return DQS is asserted.
My first place to look would be DQS skew timing (remembering that the memory device will assert DQS at the leading edge of data - it's up to the controller to determine how to use it to grab the data) in the controller.
It took me almost as long, perhaps longer, to set the rules for laying out DDR (I put down 3 independent 200/400 systems on one board) as it did to get it laid out. Even then, my timing budget had about 200 picoseconds of guaranteed margin - just what the guaranteed margin is on any particular DIMM is I can't say without a datasheet handy.
For observing signals with an oscilloscope I really need a good one but found just an ordinary one. It does not seem to be very useful. I als tried different DCM's PHASE_SHIFT values. I read a different data but n correct one. So it was not the key.
Could someone tell me about data IO's? I read that all data IO's must us both INFFs, OUTFFs and one of the Tristate-FFs (one could see it in mappe report). For me all data IO's use only OUTDDR...I am confused.
Those terms are not quite tecnically. An ordinary scope of today was a high end scope 5 years ago. What you need is some numbers. Last time I had a look at a DDR RAM interface I was using a 1.5 GHz scope form Agilent with 2.5 GHz active probes. Worked fine. Anyone had success using less firepower?
Thank you for the response, it was reassuring. I am in the process of taking a closer look at the timing margins at the controller on our Agilent infinium (2.25Ghz BW) scope and hopefully will be able to verify your suspicion. Additionally I have a comment; very rarely when the read cycles fail I only see one single rising edge on DQS as opposed to the four I would expect for an 8 burst read. I know that I am "catching" all the DQS transisitions as I am looking at the line over multiple read cycles. Have you seen this behavior before?
If you are seeing only one (or less than a burst) of DQS on reads, then the cycle is being truncated by external command, one way or another. One common problem that you have to be aware of is the clock
*at the DDR device* is defined by the CLK and #CLK crossing, not the
50% transition. Be sure you are within the spec for clock crossover. The other possible culprits (according to my habdy DDR datasheet) are the command bits (See
formatting link
for a typical DDR part) - see table 6
is a possible burst terminate command (which would do precisely what you are seeing). As the problem exacerbates with temperature, I would be suspicious of this, and the timing from CLK/#CLK to the command bus.
can you perform a timing simulation including timings and synthesis results of your FPGA ? You could at least see if timings of DQS, DQ, RasN/CasN/WeN/CsN , ClkP, ClkN are correct when coming out of the FPGA ...
I could perform only simulation using ModelSim. With ModelSim timings o all signals which you mentioned are correct. With a real FPGA I could loo only at RasN/CasN/WeN/CsN signals when they come out of the FPGA.
I think I did not mentioned my clocks. The board has 3 FPGA clocks
40MHz, 66MHz and 125MHz. Currently I am using 125MHz FPGA cloc (input_clk). Then I have 2 DCMs from which I get clk, clk90 and clk270 They both have fixed CLKOUT_PHASE_SHIFT, low DLL_FREQUENCY_MODE and sur
8.0 CLKIN_PERIOD. After using FDDRRSEs I generate ddr_clks from clk. tried to use different PHASE_SHIFT values but it did not really help.
yes, Modelsim is the point. You can perform a timing simulation using Modelsim that is you have to include the FPGA timing information file (=2Esdf) and the FPGA netlist (.vho) in your simulation. You have simulated the VHDL description but not the synthesis result, am I right ? Try to find out how to perform a timing simulation because that kind of simulation shows real behavior of your FPGA.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.