>> As I said before the data compare module fails so it could be a signal
>> integrity problem which casuses the read out data to be corrupt.
> 
> 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.
> 

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

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

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

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

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.

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

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

> As I said before the data compare module fails so it could be a signal
> integrity problem which casuses the read out data to be corrupt.

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

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:

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

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

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

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:

> heinerlitz@gmx.de wrote:
> > Hi thanks for all the responses
> > @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.
> >
> >
> > 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?
>
> I don't think that the lack of termination is causing this problem. I
> inadvertently had my Vtt turned off and was still able to read and
> write. In your original post, you said:
> > - The other signals on the PCB (or on chip using chipscope) especially
> > (ras, cas, we, cs) do not toggle at all.
>
> 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

heinerlitz@gmx.de wrote:
> Hi thanks for all the responses
> @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.
> 
> 
> 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?

I don't think that the lack of termination is causing this problem. I 
inadvertently had my Vtt turned off and was still able to read and 
write. In your original post, you said:
> - The other signals on the PCB (or on chip using chipscope) especially
> (ras, cas, we, cs) do not toggle at all.

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

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:

> Antti wrote:
> > heinerlitz@gmx.de schrieb:
> >
> >
> >>Hi,
> >>I build a DDR2 controller using the Mig 1.5.
> >>
> >>In functional simulation everything works without problems (as
> >
> >
> > check that the iodelay calibrate block get locked if not it will
> > disable everything else
> >
> > 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

Antti wrote:
> heinerlitz@gmx.de schrieb:
> 
> 
>>Hi,
>>I build a DDR2 controller using the Mig 1.5.
>>
>>In functional simulation everything works without problems (as
> 
> 
> check that the iodelay calibrate block get locked if not it will
> disable everything else
> 
> 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

heinerlitz@gmx.de schrieb:

> Hi,
> I build a DDR2 controller using the Mig 1.5.
>
> In functional simulation everything works without problems (as

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

Antti

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

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