DDR SODIMM on Avnet Virtex II PRO development kit

"Duane Clark" <dclark@junkmail.com> wrote in message 
news:Oovae.5482$J12.3021@newssvr14.news.prodigy.com...
> Unless later boards have corrected the design, there is a design error on 
> the Avnet boards. It turns out the when using DDR signals, the pins on the 
> Virtex2p are arranged in pairs that must share a common clock. On DDR 
> DIMMs, the DQS signals are special and require a different clock from the 
> other DIMM signals. However Avnet shared these pairs between the DQS and 
> DM signals. For example, they put DDR_DM0 on pin R22 and DDR_DQS0 on pin 
> P22.
>
> If you look at the Xilinx docs, these pins are named IO_L56P_7 and 
> IO_L56N_7. Notice that they have the same L number, and differ only in the 
> N/P designation. This indicates that these pins are a pair that must share 
> the same DDR clock.
>
> The solution that I used for this problem was to recognise that in my 
> application, the mask (DM) bits would never change during a data transfer. 
> So I let DM use the same clock as DQS, and setup the DM signals slightly 
> early and hold them slightly longer than needed.

The Avnet ADS-XLX-V2-DEV4000 has the same design error:

ERROR:Place:17 - The current designer locked placement of the IOBs 
ddr_dqs<7>
and ddr_dm<7> makes this design unroutable due to a physical routing
limitation. This device has a shared routing resource connecting the ICLK
and OTCLK pins on pairs of IOBs. This restriction means that these pairs of
pins must be driven by the same signal or one of the signals will be
unroutable. Before continuing with this design please unlock or move one of
these IOBS to a new location.

...when trying to use the plb_ddr core with the board. The board 
documentation says to use the old XAPP200 DDR core which does not use the 
DQS signals in the same way, so I guess that might work too for the V2Pro.

Thanks for the tip about the DM mask bits to get plb_ddr to work!

Regards,
Hans 

Duane Clark <dclark@junkmail.com> wrote in message news:<Y0Wae.193$Gd7.137@newssvr21.news.prodigy.com>...
> Duane Clark wrote:
> > 
> > Ehh... what the heck. I can't post the files directly, since the 
> > originals are copyrighted by Xilinx. But if you know how to use diff 
> > files, then here it is:
> > http://www.leewardfpga.com/fpga/plb_dimm.diff
> > 
> 
> Oh, and while at it, I included a simple testbench in the same 
> directory. The files bd_test.vhd and bd_test_siml.vhd are separate tests 
> that do slightly different things. You compile one or the other into the 
> testbench. The top level testbench file is bd_top.vhd.

Hi Duane, again me here, I started working on the diff file, but I
think it lacks of the dimm_controller.vhd implementation (that I think
it's your revision of the ddr_controller.vhd, right? ). Or I am doing
something wrong? Anyhow I'm checking if I can modify it myself.
Can you confirm this? Any chance to check that file to?

Thank you very much and sorry again!

TheMightyShaman wrote:
> 
> Hi Duane, again me here, I started working on the diff file, but I
> think it lacks of the dimm_controller.vhd implementation (that I think
> it's your revision of the ddr_controller.vhd, right? ). Or I am doing
> something wrong? Anyhow I'm checking if I can modify it myself.
> Can you confirm this? Any chance to check that file to?
> 

Oops, yep missed that one. It is there now. Have fun.

Duane Clark ha scritto:
> TheMightyShaman wrote:
> 
>>
>> Hi Duane, again me here, I started working on the diff file, but I
>> think it lacks of the dimm_controller.vhd implementation (that I think
>> it's your revision of the ddr_controller.vhd, right? ). Or I am doing
>> something wrong? Anyhow I'm checking if I can modify it myself.
>> Can you confirm this? Any chance to check that file to?
>>
> 
> Oops, yep missed that one. It is there now. Have fun.

Great!!! Thanks, now remains only the test on the board :)

Back with the results soon!!!

Antony wrote:
> Duane Clark ha scritto:
> 
>>TheMightyShaman wrote:
>>
>>
>>>Hi Duane, again me here, I started working on the diff file, but I
>>>think it lacks of the dimm_controller.vhd implementation (that I think
>>>it's your revision of the ddr_controller.vhd, right? ). Or I am doing
>>>something wrong? Anyhow I'm checking if I can modify it myself.
>>>Can you confirm this? Any chance to check that file to?
>>>
>>
>>Oops, yep missed that one. It is there now. Have fun.
> 
> 
> Great!!! Thanks, now remains only the test on the board :)
> 
> Back with the results soon!!!

By the way, I should mention one more subtle gotcha. The addresses to 
the DIMM need to be reversed, because this determines the DDR/DIMM commands.

# These need to be reversed from the schematic labeling,
# because Xilinx made all their VHDL models (0 to n)
NET "DDR_Addr<12>" LOC = "V25";
NET "DDR_Addr<11>" LOC = "U26";
NET "DDR_Addr<10>" LOC = "T28";
NET "DDR_Addr<9>"  LOC = "T25";
NET "DDR_Addr<8>"  LOC = "U27";
NET "DDR_Addr<7>"  LOC = "T26";
NET "DDR_Addr<6>"  LOC = "R27";
NET "DDR_Addr<5>"  LOC = "R25";
NET "DDR_Addr<4>"  LOC = "R28";
NET "DDR_Addr<3>"  LOC = "P26";
NET "DDR_Addr<2>"  LOC = "V26";
NET "DDR_Addr<1>"  LOC = "M30";
NET "DDR_Addr<0>"  LOC = "P27";

Duane Clark ha scritto:

> By the way, I should mention one more subtle gotcha. The addresses to 
> the DIMM need to be reversed, because this determines the DDR/DIMM 
> commands.

Modified the core, but it didn't work... Unfortunately I discovered that 
I hadn't the Service Pack installed, so I had to modify manually the 
cores (two of them were older than the ones you used for the diff 
files...) and had to do some fine tuning... Tomorrow I'll ask to install 
the SP 2 on the lab's machine and check with it installed what I can do.

Anyway, thanks for the help!!!

Antony <ascgroup_nospam@tiscalinet.it> wrote in message news:<_YTbe.13230$ms1.5857@tornado.fastwebnet.it>...
> Duane Clark ha scritto:
> 
> > By the way, I should mention one more subtle gotcha. The addresses to 
> > the DIMM need to be reversed, because this determines the DDR/DIMM 
> > commands.
> 
> Modified the core, but it didn't work... Unfortunately I discovered that 
> I hadn't the Service Pack installed, so I had to modify manually the 
> cores (two of them were older than the ones you used for the diff 
> files...) and had to do some fine tuning... Tomorrow I'll ask to install 
> the SP 2 on the lab's machine and check with it installed what I can do.

Hi Duane, how are you?

Ok, I had the SP2, patched the files and tied the external ports to 0
touse only the PLB connection. I even imported the core in EDK, but it
seems not to work correctly. I'm wondering if it depends on how I
clocked the DDR and the system, with the TWO classical DCM tied to 100
MHz both for the bus and for the DDR DCM...

How did you connected the DCMs?

Thank you very much! Bye!!!

TheMightyShaman wrote:
> 
> Hi Duane, how are you?
> 
> Ok, I had the SP2, patched the files and tied the external ports to 0
> touse only the PLB connection. I even imported the core in EDK, but it
> seems not to work correctly. I'm wondering if it depends on how I
> clocked the DDR and the system, with the TWO classical DCM tied to 100
> MHz both for the bus and for the DDR DCM...
> 
> How did you connected the DCMs?
> 

I modified a little the ddr_clocks reference design. I added that diff 
to the same location as the other files. Notice that it is against an 
EDK6.2 version of that file. Also, I found and fixed one bug in 
read_data_path.vhd, though this only affects the external interface.

The bd_top.vhd file shows one example of how to connect everything. You 
probably should run this simulation to make sure everything works, then 
modify it to zero out the external interface and try it again.

I also added an example system.mhs file to show how they are connected 
in a real system. And finally, an example system_top.vhd file, to show 
the top level structure of how they connect to the pins.

Duane Clark ha scritto:

> I modified a little the ddr_clocks reference design. I added that diff 
> to the same location as the other files. Notice that it is against an 
> EDK6.2 version of that file. Also, I found and fixed one bug in 
> read_data_path.vhd, though this only affects the external interface.
> 
> The bd_top.vhd file shows one example of how to connect everything. You 
> probably should run this simulation to make sure everything works, then 
> modify it to zero out the external interface and try it again.
> 
> I also added an example system.mhs file to show how they are connected 
> in a real system. And finally, an example system_top.vhd file, to show 
> the top level structure of how they connect to the pins.

Hi and thanks for the new files,
worked on it again yesterday and now it still doesn't run properly but 
at least now when I write a 16 bit value the system stalls (before it 
couldn't write anything from 32 bit to 8 bit: I always got back 0), so 
it's clear that something as changed (although I don't know if for the 
better :) ). I'll see if finally I could make it work!

Thank you for the great support!

Antony wrote:
> 
> 
> Hi and thanks for the new files,
> worked on it again yesterday and now it still doesn't run properly but 
> at least now when I write a 16 bit value the system stalls (before it 
> couldn't write anything from 32 bit to 8 bit: I always got back 0), so 
> it's clear that something as changed (although I don't know if for the 
> better :) ). I'll see if finally I could make it work!
> 

Well, I'll admit to only using with 32 bit values. There may very well 
be problems with other data widths, though I expect a fix would not be 
terribly difficult. That is definitely something that would be a lot 
easier to check in simulation rather than hardware.