MIG 1.6 DDR2 testing problems (FIFO16 related?)

I don't have the DDR2 source code with me at home, but I'm pretty sure that the FIFO16 use was limited to the write data and the address/command. The write data FIFO has 2 different clocks, but the FIFO read clock is 90 degrees out of phase with FIFO write clock, so I think it is not a problem. I had problems with the address/command FIFO. The FIFO would be empty, but the DDR2 controller thought that the FIFO had data, so it would repeatedly read the same address.

Is there a way to fix the fifo in the design? It would be

I created a Block RAM FIFO with CoreGen; it was pretty simple;just look at the MIG verilog or VHDL code. The FIFO16 is instantiated directly and the parameters are specified in the code. Fall through is supported in CoreGen.

I built a DIMM simulation out of 8-bit parts. Why not just use 2 8-bit parts instead of a 16-bit? Even if you're trying to simulate with real PCB delays, 2 parts could work.

I'm not happy with the whole calibration procedure that DDR2 MIG has. The IDELAY part that looks at the data strobes seems to work OK, but then they write a pattern to memory, read it back and try to figure out how many clocks to wait after the read command before the data is available and can be shifted into the read data FIFO. Sometimes (most of the time) that logic would make the wrong choice and miss some of the read data. I eventually hard coded the delay and it worked fine after that.

In the xxx_ddr2_controller.vhd file, they register the empty signal of the fifo. And it should not be registred. If you remove this register level, it works fine.

Also, they do use FIFO16 but when they use it with synchronous clock, they don't care about the flags, they use a separate counter to know how many data are present so there should be no problem.

Beware if you replace the command fifo. I've replaced it by a simple SRL fifo (to gain some space and 1 BRAM), and I was bitten ;) The fifo CANNOT become empty for a cycle then become not empty again, if the operation before and after the empty were both read in the same row, you'll get one more data than you asked for ...

Also, the timing parameters generated by the MiG tool are overly conservative ... (I think they messed up their formula). Check in simulation, you'll see it waits quite too loog (sometime twice too much ;)

Sylvain

HI,

thanks for your good replys. So you mean that the FIFO16 should be work fine as they use counters instead of the empty/full flags. Thats good.

However I still have the problems that the testbench which writes data and reads the data back sometimes looses some data. The data pattern looks like: FFFF000, AAAA5555, 5555AAAA, 99996666

When this pattern is written and read back every eight time the first two 32 bit words are corrupted and the Error signal is asserted. Is this the problem you mentioned joe with the idelay?

THe idelay is configured by an idelayctrl instance. So should i remove this and manually configure the idelay blocks using the INC and CE signals? To which value should I configure the idelay blocks, e.g. how many INC+CE assertions do I need?

thx a lot, Heiner

Sylvain Munaut schrieb:

I did not mention any problems with idelay. In fact, I said "The IDELAY part that looks at the data strobes seems to work OK". The signals that I changed were rd_en_rise and rd_en_fall in pattern_compare8.v . I suspect that not everyone will see this circuit misbehave. When it works correctly, it sets the strobes for the delays unique to your board.

--- Joe Samson Pixel Velocity

HI,

ok I observed the clk_count_rise and clk_count_fall signals which acctually decide when the data is taken over into the fifos. I had the hope that the value of the above mentioned signals would toggle and that the value would be different if the read out data is corrupt but it isnt. the clk_count signals have always the same value.

So still no solution why some of the read out data is corrupted. I really wonder why always the eights data value is corrupt...

heiner

Joseph Samson schrieb:

This is not true. Even if you use do not use the fifo flags, they are used internally. The FIFO16 cannot be used reliably if the input and output clocks are not phase locked to one another with a phase offset between them. This means you can't use the FIFO16 to cross clock domains. Using it synchronously, you have to have a phase offset between the read clock and the write clock, which is easiest to do by using not clock for one of those.

Did you hard coded the number of needed clock cycles or the delay in the IDELAY?? Thanks for help!

The number of clock cycles needed, not the IODelay.

As I wrote above:

I observed clk_count_rise and clk_count_fall using chipscope and found out that they never change which means they are defacto hardcoded. The delay is hence always the same even without hardcoding the value. However faillures are still there.

heiner

Joseph Samson schrieb:

HI,

I hope someone is still reading this thread. I am quite sure now that the matter really are the wrong calibrated clk_count_rise/clk_count_fall signals.

Ok, i tried to hardcode them but there are 8 possibliities for both the rising and falling edge. Too many to be tried out. How should I hardcode these two signals??

I tried myself be observing them via chipscope. My hope was that they were set to a different value in the case where everything works fine than in the case where the read out value is wrong.

however chipscope ALWAYS showed that the signals are set to rd_en_rise

If these values never change, then you don't have the same problem that I did. I think your only hope now is to use Chipscope to track down the failure, triggering on the error signal and trying to figure out what causes it.

You say that you're running MIG 1.6, but the Xilinx site only shows MIG

HI,

I am sorry I am running Mig 1.5 was a typo.

Right now iam encountering two problems:

If i post a sequence of reads to the read fifo, the first one always fails than I have several succesful reads. I posted 256 writes and sucessive reads and they were all succesfull besides the first one. Strangely inl in a really long succesive write then read out sequence (1k read ops) the first 100 are not succesfull and then I get 256 succesful read outs and the again errors for the remaining ones. Often the read out values are almost correct like only some 2-3 bits different..

But then again I hardcoded the observed (static) values and NOTHING worked anymore. Idont know if I can trust chipscope.

How did you decide to hardcode the values? Are the rising and falling clk_count connected in some way like if one is reg3 teh other one is also reg3?

heiner

Joseph Samson schrieb:

When the first or last element of a burst is missing, it could be a sign that the pipelining is off somewhere. For example, you expect data to arrive after 4 clocks, but it comes after 3 clocks and so you miss the first one. Often this is paired with an unexpected data value at the end. At least this is a repeatable problem. Sounds like another job for ChipScope.

Whenever I find (rarely) ChipScope giving me impossible answers, I invariably discover that either I'm not looking where I thought I was or that my circuit doesn't work the was that I assumed it would.

I hard coded the values because I notcied that they weren't always the same after calibration. As you stated before, this doesn't seem to be a problem that you have.