MIG DDR2 controller does not work (reset problems?)

Hi, I build a DDR2 controller using the Mig 1.5.

In functional simulation everything works without problems (as alwayys). In the hardware implementation it does not work. I used the synthesizable testbench which is provided by the Mig. My design is driven by a 200Mhz Refclock and 125MHz system clock. I used chipscope and oscilloscope to figure out the following:

-All clocks (200, 90, 50) work properly. Also clk0 which controlls most part of the ddr2controller module.

-I can messure the correct RAM clock on the PCB

-After the reset WDF FIFO is empty and the internal writeWDF signal toggles untill the WDF almost full signal goes active. It stays high forever.

- The other signals on the PCB (or on chip using chipscope) especially (ras, cas, we, cs) do not toggle at all.

SO data is never written to the ram and never read out. The FIFO just runs full.

Did anybody experience similar problems and can help? The xilinx design only uses synchronous resets. These are regarded like normal signals by the router and hence do not meet the timing (high fan out probably). Is this ok? How are resets treated in FPGAs anyway? I always use asynchronous reset so they dont interfere with timing issues. Can i tell XST in anyway that it should treat reset signals properly? How to tell XST to make a reset tree synthesis? Could it be due to the FIFO16 bug? I dont think so, as it doesnt run at all. The controller should at least try to access the RAM several times, right?

Reply to
heinerlitz
Loading thread data ...

Did you check whether the reset is performed or not in hardware ? Rgds Andr=E9

Reply to
ALuPin

snipped-for-privacy@gmx.de schrieb:

check that the iodelay calibrate block get locked if not it will disable everything else

Antti

Reply to
Antti

  1. Check the map report to make sure that all your IOs go to the pins that you want.
  2. I found that the controller doesn't start up correctly from power-on, but it can be reset by driving the SYS_RESET_IN signal high, then low.
  3. If you can look at the command signals (RAS, CAS, WE) going to the SDRAM, you should be able to see the INIT commands. After init, the controller issues many read commands and looks at the strobe signals to calibrate the iodelay. This should be obvious from the scope if you can look at a datastrobe or two.
  4. After the iodelay is calibrated, the controller writes a pattern to memory then tries to read it back. If you have a chipscope, look at COMP_DONE. When it is high, the memory is ready to use. I took this signal out to the top of the hierarchy and have it as a register bit that my PPC can look at to see the health of the memory.
  5. Consider fixing the FIFO16s, at least the ones that hold the memory addresses. The ones that hold the write data are clocked by the MClk and MClk90, so they may be OK.
--
Joe Samson
Pixel Velocity
Reply to
Joseph Samson

Hi thanks for all the responses

@alupin: The reset is driven by an externel jumper on the board. It seems to work.

@antti: Do you mean the RDY_STATUS signal in the ddr2_8x4_idelay_ctrl module? Yes it goes high shortly after reset.

@joseph: Ich double checked all pins, ok. I played with the reset. I observed the design a little bit more using chipscope getting the following results: Ras, Cas and ddr2_we toggle right after reset deassertion, i think this is the initialisation of the ddr2. I dont know whether the ddr2 behaves correct but the init sequence is completed after about 500 clock cycles. THe COMP_VALID signal never goes high and also the read enable signals for the write and address FIFOs stay zero all the time, so I guess the init sequence fails.

Does anybody know how I could check whether the RAM behaves correctly?

We have no external termination on the board. Do I have to configure ODT somehow? Icant find anything about ODT in the Mig however there is the RTT option. I cant find any information about this option I guess it is related to termination resistors? Should I choose 75 or 150 ohm RTT?

heiner

Joseph Samson schrieb:

Reply to
heinerlitz

I d> - The other signals on the PCB (or on chip using chipscope) especially

Is this still true - if you put a scope on the PCB signals,can you see the RAS CAS and WE forming the Load Mode command? If you can't see this, then you have to start by figuring out why you're not driving those signals (since you've said that you can see them toggling internally with ChipScope).

If you're looking at RAS, CAS and WE with ChipScope, figure out the sequence of commands that MIG is sending to the RAMs. You can download a DDR2 datasheet from Micron; they have a table that gives the command nanes for the combinations of RAS,CAS and WE. You'll probably have to start looking at the state machine in the ddr2_controller module to figure out where you're hanging up and what conditions are stopping your progress.

--
Joe Samson
Pixel Velocity
Reply to
Joseph Samson

Hi ive got some news,

the init and calibration process seems to be succesful as tap_sel_done, data_tap_select and init_memory signals toggle at the end of the calibration process.

However the init_done signal which is driven by COMP_DONE is not asserted. As COMP_DONE is generated by the pattern compare module, it seems to me that the read out data is corrupted.

Could this be right? Am I right with my conclusions? What to do know?

thx, regards Heiner

Joseph Samson schrieb:

Reply to
heinerlitz

I'm assuming that this is a board of your own design, and not a prototyping board you bought off the shelf, because my first guess would be that there is either a mis-wiring problem (my board had the differential clock signals miswired + to -, even though we checked the schematic about a hundred times) or a signal integrity problem (like those missing terminators). You can try turning on ODT. You can either change the parameters_0.v file, or regenerate the design from CoreGen, clicking on the 'Set Mode Register" button and setting RTT to 75 ohms.

There are two lines of attack:

  1. Is the command and address correct?
  2. Is the data correct?

There are indirect ways to see if the commands are correct. Earlier, I said that part of the calibration is to issue read commands and calibrate the idelay by examining the datastrobes. If you are getting through that phase and you see datastrobes being generated, then the commands (RAS, CAS, WE, CKE, CS) are probably OK, or at least I'd look elsewhere.

It's hard to tell if the address bus is OK without using a scope on the RAM.

You can use ChipScope to see what the data looks like coming from the RAM, but be sure that you aren't accidentally connecting to signals that go to the IOB. The address and command signals go go IOB flipflops, but chipscope will happily move them out of the IOB so you can look at them, and as a bonus, you'll get lots or routing delay to confues the issues.

If this is your own design, did you pay attention to the routing delays? My first design spec'd that signals had to be length matched to 200ps. In my second design, I spec'd 20ps. You could have everything correct, but the difference in path length could prevent the calibration circuit from aligning all the bits.

--
Joe Samson
Pixel Velocity
Reply to
Joseph Samson

Hi Joseph,

thanks a lot I will check all the thing you suggested and yes its a board made by us.

Still I have some questions:

The Calibration process with the dummy reads can be definitely observed using chip scope and it seems to be ok as the tap_select signal is asserted. Does that mean that at least the control and the DQS signals should be fine. The question I have is the following in the init sequence the controller just writes data to the RAM, the Ram itself does practically nothing. SO assuming the RAM wouldnt consist at all would the init and calibration sequence still be succesfull?

I tried a board without RAM assembly and it didnt do anything so I assume not.. As I said before the data compare module fails so it could be a signal inttegrity problem which casuses the read out data to be corrupt.

heiner

Joseph Samson schrieb:

Reply to
heinerlitz

I would assume for the moment that the RAM is decoding the control signals correctly.

in the init sequence, the controller just READS the RAM, so that the RAM will send back DQS signals so the controller can tweak the input delays.

No, because the controller needs those DQS signals back from the RAM in order to se the delays.

Or, the read could be correct and the write could be wrong. It's kind of hard to tell that if you aren't getting past Comp_Done. You should probably look at the data going to and from the RAM, to see what's going on. Maybe there's a stuck bit, or maybe data from one bank is wrong but the rest are right. There are a lot of possibilities. It will take some investigating with ChipScope to figure out what's going on.

--
Joe Samson
Pixel Velocity
Reply to
Joseph Samson

Be aware than when putting chipscope and looking at we / cas / ras ... you might prevent the tools to put the last register into the IOB and then you have bad timings ...

So if it's the case, you are actually creating a problem with chipscope and not debugging the real one ...

Checkout the timing report to see if the clock-to-out of the ddr_clk and the control signals and the address leads to a valid timing.

Sylvain

Reply to
Sylvain Munaut

We have the same problems and have traced it to the IOB not latching valid read data back, from the working DDR memory IC, in the rise and fall registers. We can see the read data enter the Xilinx part correctly and never exit the capture registers. All clocks and resets, tap calibration, etc look great. We believe the read data is not getting through the Idelay block so it never gets captured and Comp_Done fails. My partner wants to switch to an Altera chip after he stops screaming ...

Bob

Reply to
Bob

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.