Opencores DDR SDRAM controller

Tommy Thorn ha scritto:


> > > Maybe I misunderstood, but it already does synthesize. David Ashley, as
> > > posted here earlier, did the needed modification to get it running on
> > > the Spartan 3E Start Kit. With just a .ucf adjustment, it worked on
> > > Digilent's Spartan 3E1600 board.

Hi,

thanks for the answer; I downloaded the code an I try to sintetize it
with ISE Webpack 8.2i (Xilinx XST Compiler) but in my Spartan 3E
starter kit board don't work (ddr sdram Micron MT46V32M16TG-6T).
I don't know how can I debug the core; maybe is possible to use the
chipscope, but I never use it before an I don't know if is the right
tools to use.
I guess wich is the things that I must to carefully syntetize to obtain
the goal (like the working simulation).

Daniele

cippalippa wrote:
> thanks for the answer; I downloaded the code an I try to sintetize it
> with ISE Webpack 8.2i (Xilinx XST Compiler) but in my Spartan 3E
> starter kit board don't work (ddr sdram Micron MT46V32M16TG-6T).

I don't have the Xilinx Spartan 3E Start Kit, but David claimed it
worked, and given that I got it running by simply supplying the correct
.ucf I strongly suspect it works. (BTW the 1600E edition which I have
has the same Micron DDR SDRAM you list above).

If you want us to help you, you need to be more explict about what
didn't work. Did it fail to syntesize? Place and Route? Program?

When it works you should see the LEDs blinking. To interpret them you
need to read the verilog.

Tommy


> I don't know how can I debug the core; maybe is possible to use the
> chipscope, but I never use it before an I don't know if is the right
> tools to use.
> I guess wich is the things that I must to carefully syntetize to obtain
> the goal (like the working simulation).
> 
> Daniele

Tommy Thorn ha scritto:


> I don't have the Xilinx Spartan 3E Start Kit, but David claimed it
> worked, and given that I got it running by simply supplying the correct
> .ucf I strongly suspect it works. (BTW the 1600E edition which I have
> has the same Micron DDR SDRAM you list above).
>
> If you want us to help you, you need to be more explict about what
> didn't work. Did it fail to syntesize? Place and Route? Program?
>
> When it works you should see the LEDs blinking. To interpret them you
> need to read the verilog.
>
> Tommy
>
>

Hello,

I'm happy; finally the original DDR opencore code working; the only
thing is that the frequency is only 50 MHz because the DCM that
increase the frequency from 50MHz to 100MHz don't work (I use the
Xilinx system generator in the webpack 8.2) but I hope to solve the
problem quickly.
With the code now I write and read only half memory (I have the 32M16
instead 16M16); how I can use the full memory? I think that I must
increase the coloumn address bit from 10 to 11 but I don't understand
when I must do the change.
May sameone help me please?
Thanks for all

Daniele

cippalippa wrote:

> I'm happy; finally the original DDR opencore code working; the only
> thing is that the frequency is only 50 MHz because the DCM that
> increase the frequency from 50MHz to 100MHz don't work (I use the
> Xilinx system generator in the webpack 8.2) but I hope to solve the
> problem quickly.

50 MHz is not good, because it violates timing of the DDR RAM. Use this
code for generating 266 MHz:

  -- Spartan 3E stepping 0, speed grade -4 devices:
  -- CLKFX frequency in "high" mode: min: 220 MHz, max: 307 MHz
  clock266: dcm_sp
    generic map(
      clkfx_multiply => 16,
      clkfx_divide => 3,
      clkin_period => 4.0,
      dfs_frequency_mode => "HIGH")
    port map(
      clkfx => clk_266mhz,
      clkin => clk_50mhz);

As far as I understand, you can't divide to 133 MHz, because the datasheet
specifies different ranges for high and low mode for the speed grade -4
devices, so I've used this additional code for dividing 266 MHz by two:

  -- divide 266 MHz to system clock
  clock_divide: process(clk_266mhz)
  begin
    if rising_edge(clk_266mhz) then
      clk_133mhz <= not clk_133mhz;
    end if;
  end process;

The signals:

  signal clk_266mhz: std_logic := '0';
  signal clk_133mhz: std_logic := '0';

Imports:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
use IEEE.MATH_REAL.ALL;

Library UNISIM;
use UNISIM.vcomponents.all;

At least it works for my TCP/IP receiver/sender core, let me know, if it
works with your DDR implementation and maybe upload the project somewhere
or submit your modifications to the Open Cores project.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Frank Buss ha scritto:


> 50 MHz is not good, because it violates timing of the DDR RAM. Use this
> code for generating 266 MHz:
>
>   -- Spartan 3E stepping 0, speed grade -4 devices:
>   -- CLKFX frequency in "high" mode: min: 220 MHz, max: 307 MHz
>   clock266: dcm_sp
>     generic map(
>       clkfx_multiply => 16,
>       clkfx_divide => 3,
>       clkin_period => 4.0,
>       dfs_frequency_mode => "HIGH")
>     port map(
>       clkfx => clk_266mhz,
>       clkin => clk_50mhz);
>
> As far as I understand, you can't divide to 133 MHz, because the datasheet
> specifies different ranges for high and low mode for the speed grade -4
> devices, so I've used this additional code for dividing 266 MHz by two:
>
>   -- divide 266 MHz to system clock
>   clock_divide: process(clk_266mhz)
>   begin
>     if rising_edge(clk_266mhz) then
>       clk_133mhz <= not clk_133mhz;
>     end if;
>   end process;
>
> The signals:
>
>   signal clk_266mhz: std_logic := '0';
>   signal clk_133mhz: std_logic := '0';
>
> Imports:
>
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.NUMERIC_STD.ALL;
> use IEEE.MATH_REAL.ALL;
>
> Library UNISIM;
> use UNISIM.vcomponents.all;
>
> At least it works for my TCP/IP receiver/sender core, let me know, if it
> works with your DDR implementation and maybe upload the project somewhere
> or submit your modifications to the Open Cores project.
>
> --
> Frank Buss, fb@frank-buss.de
> http://www.frank-buss.de, http://www.it4-systems.de

Hello,

now the controller work at 133MHz; I use directly the DCM like this:

clk_in_ibufg :  IBUFG port map (I=>sys_clk_pin, O=>CLKIN_IBUFG);

DCM_SP_INST : DCM_SP	generic map(
        CLK_FEEDBACK => "NONE",
        CLKDV_DIVIDE => 2.0,
        CLKFX_DIVIDE => 3,
	CLKFX_MULTIPLY => 8,
	CLKIN_DIVIDE_BY_2 => FALSE,
	CLKIN_PERIOD => 20.0,
	CLKOUT_PHASE_SHIFT => "NONE",
	DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS",
	DFS_FREQUENCY_MODE => "LOW",
	DLL_FREQUENCY_MODE => "LOW",
	DUTY_CYCLE_CORRECTION => TRUE,
	FACTORY_JF => x"C080",
	PHASE_SHIFT => 0,
	STARTUP_WAIT => FALSE)
port map (
        CLKFB=>'0',
	CLKIN=>CLKIN_IBUFG,
	DSSEN=>'0',
	PSCLK=>'0',
	PSEN=>'0',
	PSINCDEC=>'0',
	RST=>sys_rst_pin,
	CLKFX=>CLKFX_BUF,
	LOCKED=>rst_n,
	PSDONE=>open,
	STATUS=>open);

clkfx_bufg : BUFG port map (I=>CLKFX_BUF, O=>clk100mhz);

where sys_clk_pin is the S3E board clock (at 50MHz).
Why do you think that is better to use 266Mhz and after divide by 2 the
clock? (is the jitter better?)
May I also know if sameone say me how can I modify the controller to
use all the DDR memory (the opencore's DDR is for 256 Mbit but I have a
512 Mbit).
Thanks for all.

Daniele

cippalippa wrote:

> where sys_clk_pin is the S3E board clock (at 50MHz).
> Why do you think that is better to use 266Mhz and after divide by 2 the
> clock? (is the jitter better?)

See the datasheet ds312.pdf page 145: For stepping 0, speed grade -4
devices, like on my S3E board, there are 2 DFS_FREQUENCY_MODE modes: low
and high. For low CLKOUT_FREQ_FX has to be between 5 and 90 MHz and for
high it must be between 220 and 307 MHz. At least this is how I interpret
it.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de