MIG 1.6 DDR2 testing problems (FIFO16 related?)

Hi,
I finally got to run the MIG created DDR2 for VIrtex4 devices
controller. However I have two problems with the controller:

1. I am observing the ERROR signal which is created by the dataCompare
module. It goes high every 8th read pulse. Could this be related to the
FIFO16 bug? Is there a way to fix the fifo in the design? It would be
easy to fix the fifo issue in my own design but as I havent written the
ddr controler i have no glue what the requirements of the fifo16 are
and how the issue should can be fixed in the best way. Inverting the
readclock (as I read somewhere) didnt work and I do not know if the
coregenerated fifos are fast enough and if they can be simply exchanged
(no fall through for example).

2. My other problem is of different nature. The simulation environment
which is supplied by xilinx does not work with some RAMs. I had no
problem simulating a 8bit Micron DDR2 chip however the 16bit chip I am
currently using does not work. THe whole testbench verilog files are
corrupted showing false instantiations (wrong names, wrong bit sizes)
has anybody experienced the same problems?

Both problems could be probably solved by disassembing the whole
design, but that takes hours, so If anybody has already a solution for
the avove problems I would be very happy.

thks, regards Heiner

heinerlitz@gmx.de wrote:
> Hi,
> I finally got to run the MIG created DDR2 for VIrtex4 devices
> controller. However I have two problems with the controller:
> 
> 1. I am observing the ERROR signal which is created by the dataCompare
> module. It goes high every 8th read pulse. Could this be related to the
> FIFO16 bug? 

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
> easy to fix the fifo issue in my own design but as I havent written the
> ddr controler i have no glue what the requirements of the fifo16 are
> and how the issue should can be fixed in the best way. Inverting the
> readclock (as I read somewhere) didnt work and I do not know if the
> coregenerated fifos are fast enough and if they can be simply exchanged
> (no fall through for example).

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.


> 
> 2. My other problem is of different nature. The simulation environment
> which is supplied by xilinx does not work with some RAMs. I had no
> problem simulating a 8bit Micron DDR2 chip however the 16bit chip I am
> currently using does not work. THe whole testbench verilog files are
> corrupted showing false instantiations (wrong names, wrong bit sizes)
> has anybody experienced the same problems?

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.

> 
> Both problems could be probably solved by disassembing the whole
> design, but that takes hours, so If anybody has already a solution for
> the above problems I would be very happy.

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.

---
Joe Samson
Pixel Velocity

Joseph Samson wrote:
> heinerlitz@gmx.de wrote:
> > Hi,
> > I finally got to run the MIG created DDR2 for VIrtex4 devices
> > controller. However I have two problems with the controller:
> >
> > 1. I am observing the ERROR signal which is created by the dataCompare
> > module. It goes high every 8th read pulse. Could this be related to the
> > FIFO16 bug?
>
> 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.

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 <SomeOne@SomeDomain.com> schrieb:

> Joseph Samson wrote:
> > heinerlitz@gmx.de wrote:
> > > Hi,
> > > I finally got to run the MIG created DDR2 for VIrtex4 devices
> > > controller. However I have two problems with the controller:
> > >
> > > 1. I am observing the ERROR signal which is created by the dataCompare
> > > module. It goes high every 8th read pulse. Could this be related to the
> > > FIFO16 bug?
> >
> > 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.
>
> 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

heinerlitz@gmx.de wrote:
> 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?


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

> 
> thx a lot, Heiner
> 
> 
> 
> Sylvain Munaut <SomeOne@SomeDomain.com> schrieb:
> 
> 
>>Joseph Samson wrote:
>>
>>>heinerlitz@gmx.de wrote:
>>>
>>>>Hi,
>>>>I finally got to run the MIG created DDR2 for VIrtex4 devices
>>>>controller. However I have two problems with the controller:
>>>>
>>>>1. I am observing the ERROR signal which is created by the dataCompare
>>>>module. It goes high every 8th read pulse. Could this be related to the
>>>>FIFO16 bug?
>>>
>>>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.
>>
>>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,

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:

> heinerlitz@gmx.de wrote:
> > 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?
>
>
> 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
>
> >
> > thx a lot, Heiner
> >
> >
> >
> > Sylvain Munaut <SomeOne@SomeDomain.com> schrieb:
> >
> >
> >>Joseph Samson wrote:
> >>
> >>>heinerlitz@gmx.de wrote:
> >>>
> >>>>Hi,
> >>>>I finally got to run the MIG created DDR2 for VIrtex4 devices
> >>>>controller. However I have two problems with the controller:
> >>>>
> >>>>1. I am observing the ERROR signal which is created by the dataCompare
> >>>>module. It goes high every 8th read pulse. Could this be related to the
> >>>>FIFO16 bug?
> >>>
> >>>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.
> >>
> >>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
> > 
> >

heinerlitz@gmx.de wrote:
> 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.
> 

> 
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.

Joseph Samson wrote:
> heinerlitz@gmx.de wrote:
> > Hi,
> > I finally got to run the MIG created DDR2 for VIrtex4 devices
> > controller. However I have two problems with the controller:
> >
> > 1. I am observing the ERROR signal which is created by the dataCompare
> > module. It goes high every 8th read pulse. Could this be related to the
> > FIFO16 bug?
>
> 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
> > easy to fix the fifo issue in my own design but as I havent written the
> > ddr controler i have no glue what the requirements of the fifo16 are
> > and how the issue should can be fixed in the best way. Inverting the
> > readclock (as I read somewhere) didnt work and I do not know if the
> > coregenerated fifos are fast enough and if they can be simply exchanged
> > (no fall through for example).
>
> 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.
>
>
> >
> > 2. My other problem is of different nature. The simulation environment
> > which is supplied by xilinx does not work with some RAMs. I had no
> > problem simulating a 8bit Micron DDR2 chip however the 16bit chip I am
> > currently using does not work. THe whole testbench verilog files are
> > corrupted showing false instantiations (wrong names, wrong bit sizes)
> > has anybody experienced the same problems?
>
> 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.
>
> >
> > Both problems could be probably solved by disassembing the whole
> > design, but that takes hours, so If anybody has already a solution for
> > the above problems I would be very happy.
>
> 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.

Did you hard coded the number of needed clock cycles or the delay in
the IDELAY??
Thanks for help!
> 
> ---
> Joe Samson
> Pixel Velocity

GaLaKtIkUs� wrote:

> 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.


---
Joe Samson
Pixel Velocity

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:

> GaLaKtIkUs=99 wrote:
>
> > 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.
>=20
>=20
> ---
> Joe Samson
> Pixel Velocity