UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor fthillma
Visitor
10,552 Views
Registered: ‎03-12-2010

Spartan-3AN - IOSTANDARD for DDR2

Jump to solution

Hello everybody!

 

I'm still trying to implement the DDR2-module placed on the Spartan-3AN Starterkit. With the help of MIG v 3.3 (ISE 11.5) I created a core for the DDR2-device placed on the board. I also wrote a little init-function to initialize the memory.

In the simulation, everything works fine, but there is no effect on the board (I try to light up an LED with the help of the init_done-signal). While searching in the internet I found an UCF-file (on the Xilinx-page) which is quite different to the one listed in the userguide (v1.1). For example, SSTL18_I is used instead of SSTL18_II.

Which is the right one? I tried several configs, but with no effect.

 

Kind regards

 

Florian

 

Code: ucf

NET "ddr2_a[0]" LOC = R2; NET "ddr2_a[10]" LOC = T3; NET "ddr2_a[11]" LOC = V1; NET "ddr2_a[12]" LOC = Y2; NET "ddr2_a[1]" LOC = T4; NET "ddr2_a[2]" LOC = R1; NET "ddr2_a[3]" LOC = U3; NET "ddr2_a[4]" LOC = U2; NET "ddr2_a[5]" LOC = U4; NET "ddr2_a[6]" LOC = U1; NET "ddr2_a[7]" LOC = Y1; NET "ddr2_a[8]" LOC = W1; NET "ddr2_a[9]" LOC = W2; NET "ddr2_ba[0]" LOC = p3; NET "ddr2_ba[1]" LOC = r3; NET "ddr2_dm[0]" LOC = j3; NET "ddr2_dm[1]" LOC = e3; NET "ddr2_dqs[0]" LOC = k3; NET "ddr2_dqs_n[0]" LOC = k2; NET "ddr2_dqs[1]" LOC = k6; NET "ddr2_dqs_n[1]" LOC = j5; ############################################################################################################## # I/O STANDARDS ############################################################################################################## NET "ddr2_a[*]" IOSTANDARD = SSTL18_I; NET "ddr2_ba[0]" IOSTANDARD = SSTL18_I; NET "ddr2_ba[1]" IOSTANDARD = SSTL18_I; NET "ddr2_cke" IOSTANDARD = SSTL18_I; NET "ddr2_cs_n" IOSTANDARD = SSTL18_I; NET "ddr2_ras_n" IOSTANDARD = SSTL18_I; NET "ddr2_cas_n" IOSTANDARD = SSTL18_I; NET "ddr2_we_n" IOSTANDARD = SSTL18_I; NET "ddr2_odt" IOSTANDARD = SSTL18_I; NET "ddr2_dm[0]" IOSTANDARD = SSTL18_I; NET "ddr2_dm[1]" IOSTANDARD = SSTL18_I; NET "ddr2_dqs[0]" IOSTANDARD = DIFF_SSTL18_I; NET "ddr2_dqs[1]" IOSTANDARD = DIFF_SSTL18_I; NET "ddr2_dqs_n[0]" IOSTANDARD = DIFF_SSTL18_I; NET "ddr2_dqs_n[1]" IOSTANDARD = DIFF_SSTL18_I; NET "ddr2_dq[*]" IOSTANDARD = SSTL18_I; NET "ddr2_cas_n" LOC = M4; NET "ddr2_cke" LOC = N3; NET "ddr2_cs_n" LOC = M5; NET "ddr2_odt" LOC = P1; NET "ddr2_ras_n" LOC = M3; NET "ddr2_we_n" LOC = N4; NET "led_ar_done" LOC = T19 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 8; NET "led_init_done" LOC = R20 | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 8; NET "sys_clk133" LOC = V12; NET "sys_clk50" LOC = E12; NET "ddr2_ck[0]" LOC = M1; NET "ddr2_ck_n[0]" LOC = M2; NET "reset_in" LOC = T15 | IOSTANDARD = LVCMOS33 | PULLDOWN; NET "ddr2_ck[0]" IOSTANDARD = DIFF_SSTL18_II; NET "ddr2_ck_n[0]" IOSTANDARD = DIFF_SSTL18_II; NET "sys_clk133" IOSTANDARD = LVCMOS33; NET "sys_clk50" IOSTANDARD = LVCMOS33; NET "ddr2_dq[0]" LOC = H1; NET "ddr2_dq[10]" LOC = G1; NET "ddr2_dq[11]" LOC = H6; NET "ddr2_dq[12]" LOC = H5; NET "ddr2_dq[13]" LOC = F1; NET "ddr2_dq[14]" LOC = G3; NET "ddr2_dq[15]" LOC = F3; NET "ddr2_dq[1]" LOC = K5; NET "ddr2_dq[2]" LOC = K1; NET "ddr2_dq[3]" LOC = L3; NET "ddr2_dq[4]" LOC = L5; NET "ddr2_dq[5]" LOC = L1; NET "ddr2_dq[6]" LOC = K4; NET "ddr2_dq[7]" LOC = H2; NET "ddr2_dq[8]" LOC = F2; NET "ddr2_dq[9]" LOC = G4; #Prohibit VREF pins on FPGA I/O Bank3 CONFIG PROHIBIT = H7; CONFIG PROHIBIT = J1; CONFIG PROHIBIT = J8; CONFIG PROHIBIT = L8; CONFIG PROHIBIT = N1; CONFIG PROHIBIT = R6; CONFIG PROHIBIT = T1; CONFIG PROHIBIT = T6;

 

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Visitor fthillma
Visitor
6,821 Views
Registered: ‎03-12-2010

Re: Spartan-3AN - IOSTANDARD for DDR2

Jump to solution

OMG, I should do more breaks :-D

 

Thanks for this idea, right now it works that way I want it and I already started modifying the test_bench.

 

Big thanks!

 

Florian

0 Kudos
11 Replies
Explorer
Explorer
10,551 Views
Registered: ‎02-27-2010

Re: Spartan-3AN - IOSTANDARD for DDR2

Jump to solution

Check your devices User Guide for the details on the logic standards.  It may point you instead to a document that focuses on these standards for multiple device families.  The difference between _I and _II typically depends on the specific termination scheme used.  If terminations are used at both ends of the line, it's one standard; only one end of the line means the other standard is used.  You need to know how your board is designed or if you're targeting the specific starter kit with the MIG through a selection box, those standards should be preselected for you in a UCF generated by MIG.  [At least that's my expectation.  I typically target devices, not kits.]

 

If your init_done LED doesn't go high for programming in the first place, your issuesmay be deeped than you expect.


General checklist:

Does the device program?

Is the I/O bank properly powered?  [VCCIO can be different fro each of multiple banks.]

Do the I/Os establish proper voltage levels for high/low?

Are the I/Os toggling as part of your algorithm?

Does your algorithm work properly?

 

If your device doesn't program, it's not the I/O standards that are in your way.

0 Kudos
Visitor fthillma
Visitor
10,545 Views
Registered: ‎03-12-2010

Re: Spartan-3AN - IOSTANDARD for DDR2

Jump to solution

Hi John!

 

I also tried the ucf delivered with the starterkit (and the one created with the MIG). But at least there is no positive result.

 

Referring to the checklist:

The device is programmable and it does

The voltage-levels are, as far as I can see, OK

I can see the port for the clock toggling, that works quite fine; for the rest I need another scope

The algorithm is "just" a little statemachine which initializes the the RAM by sending the usercommand 010

 

I'll try on on monday, thanks for your help so far!

 

Kind regards

0 Kudos
Explorer
Explorer
10,540 Views
Registered: ‎02-27-2010

Re: Spartan-3AN - IOSTANDARD for DDR2

Jump to solution

@fthillma wrote:

The algorithm is "just" a little statemachine which initializes the the RAM by sending the usercommand 010

 


And here I thought initializing a DDR2 memory was complicated!  I quickly googled "DDR2 initialization" and found a Xilinx document on the DDR2 controller implementaion in the Virtex-4.  Are you sure the memory controller takes care of everything except the usercommand 010?  It looked like there was a need for more from the user for the Virtex-4 implementation, perhaps for the Spartan3AN as well.

0 Kudos
Visitor fthillma
Visitor
10,512 Views
Registered: ‎03-12-2010

Re: Spartan-3AN - IOSTANDARD for DDR2

Jump to solution

@john.h wrote:
And here I thought initializing a DDR2 memory was complicated!  I quickly googled "DDR2 initialization" and found a Xilinx document on the DDR2 controller implementaion in the Virtex-4.  Are you sure the memory controller takes care of everything except the usercommand 010?  It looked like there was a need for more from the user for the Virtex-4 implementation, perhaps for the Spartan3AN as well.

I read several manuals written by Xilinx concerning the implementation; but it all ended up by "use the created core". As far as I found out the generated core is responsible for the timing and clock-generation as well as doing the auto-refresh and other DDR2-specifics. 

In my opinion, there is nothing more to do except giving the right information to the core on the right time.

 

But please tell me, what is the number of the Xilinx document you found?

 

Kind regards

 

Florian

0 Kudos
Explorer
Explorer
10,506 Views
Registered: ‎02-27-2010

Re: Spartan-3AN - IOSTANDARD for DDR2

Jump to solution

The one I glanced through is here:

 

http://www.xilinx.com/support/documentation/application_notes/xapp723.pdf

 

It may bring you to the same conclusion you've had all along.  The quote I saw that led me to question the init was:

 

"After the initialization sequence is complete, the controller issues a dummy write followed by dummy reads"

 

Without paying strong attention scanning the paragraphs, it appeared to me dummy writes and dummy reads were needed after the init sequence.  What I missed was "the controller issues" in the statement above appearing to refer to the DDR2 core rather than the user interface to the core.  Silly me, I thought what the DDR2 controller did was the init sequence but it appears to refer to the DDR2 init sequence.

 

Check those logic levels to make sure they're in the right ballpark and have some activity during init even if it means a different scope.  You may want to instrument up the design with chipscope to get access to the core's internal interface to the DDR2 to look at pieces of the init sequence to be confident that everything occurs as it should.

 

It's never fun when something powers up and stares at you with a blank look when you know it should be doing something.

0 Kudos
Visitor fthillma
Visitor
10,476 Views
Registered: ‎03-12-2010

Re: Spartan-3AN - IOSTANDARD for DDR2

Jump to solution

Hello John!

 

Thanks for your help, right now I'm so far that I can see a short flash of the LED which shows me that the init-procedure was successful. But this happens after I pressed the resetbutton several times, without any regularity.

 

So I think that the constraints for the core don't meet the way they should.

 

A little more "basic" question: Is the ucf-file of the core considered throughout the implementation? Or do I need to "include" it in any way?

 

Kind regards

 

Florian

0 Kudos
Visitor fthillma
Visitor
10,471 Views
Registered: ‎03-12-2010

Re: Spartan-3AN - IOSTANDARD for DDR2

Jump to solution

I'm sorry for this double-post, but at least it works quite better on and on; but I still have a problem concerning the rst_dqs_div_in and .._out-signals:

 

The userguide says, they have to be connected on the board, so I tried to "loop" them in my self-written top-module. But after implementing this, I receive the error XST:2033 which tells me that Port I of Input buffer u_ddr2ctrl/top_00/iobs0/controller_iobs0/rst_iob_inbuf is connected to GND.

I have no idea how to fix this problem. I tried it with the code appended to this post, but this obviously doesn't work.

 

Any other ideas?

 

Florian

 

signal sig_dqs_div_in : std_logic; signal sig_dqs_div_out : std_logic; begin u_ddr2ctrl :ddr2ctrl port map ( cntrl0_rst_dqs_div_out => sig_dqs_div_out, cntrl0_rst_dqs_div_in => sig_dqs_div_in, -- ... process begin wait until falling_edge(sys_clk50); sig_dqs_div_out <= sig_dqs_div_in; end process;

 

0 Kudos
Explorer
Explorer
10,469 Views
Registered: ‎02-27-2010

Re: Spartan-3AN - IOSTANDARD for DDR2

Jump to solution

You need to add the UCF yourself.  In my own case even if I have external cores to deal with, I integrate the multiple UCFs into one main UCF that I maintain.

 

When you run your Timing Analyzer to understand what your chip's compliance looks like compared to your constraints, run the unconstrained path analysis.  If you end up with thousands of unconstrained paths, you know something's missing.

 

I'd also suggest you run a PAD report to see if signals showed up where you expect.

0 Kudos
Xilinx Employee
Xilinx Employee
10,463 Views
Registered: ‎10-23-2007

Re: Spartan-3AN - IOSTANDARD for DDR2

Jump to solution

The rst_dqs_div signal is used to match the delay in the clock to memory and data from memory paths.  If you loop it back internally, you may find that you are not capturing the data properly.  Take a look at XAPP768c:

 

The rst_dqs_div signal is driven to an IOB as an output and is then taken as an input through

the input buffer. This technique normalizes the IOB and trace delays between the rst_dqs_div

and DQS Clock signals. The rst_dqs_div signal from the input PAD of the FPGA uses identical

routing resources as the DQS before it enters the LUT delay circuit. The trace delay of the loop

should be the sum of the trace delays of the clock forwarded to the memory and the DQS. 

 

http://www.xilinx.com/support/software/memory/protected/XAPP768c.pdf

http://www.xilinx.com/support/documentation/ip_documentation/ug086.pdf

 

Note: some boards did not follow this rule properly, so they generate internal delays to compensate.  I do not know which boards are affected. 

0 Kudos
Visitor texblues
Visitor
3,570 Views
Registered: ‎03-09-2010

Re: Spartan-3AN - IOSTANDARD for DDR2

Jump to solution
I succesfully run DDR2 on Spartan 3AN. I run example_design and than change test_bench for my design
0 Kudos
Visitor fthillma
Visitor
6,822 Views
Registered: ‎03-12-2010

Re: Spartan-3AN - IOSTANDARD for DDR2

Jump to solution

OMG, I should do more breaks :-D

 

Thanks for this idea, right now it works that way I want it and I already started modifying the test_bench.

 

Big thanks!

 

Florian

0 Kudos