Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
8 years ago

SDRAM + NIOS not working

Dear Forum,

as so many questioners here I struggle too to connect an Altera FPGA (EP4CE6E22C8) and a SDRAM to use it as program memory for the NIOS II.

I already figured out that the nios2 works with on-chip memory and I also used the on-chip memory to test the SDRAM using IOWR_32DIRECT / IORD_32DIRECT which also worked (It was possible to write and read 32 bit values to the SDRAM). My Setup consists of a (megawizard) PLL that connects to the SDRAM and via clk_in to the sdram memory controller of the NIOS. The PLL locked-output is connected to the NIOS reset. However if I configure the Nios to use SDRAM only eclipse is not able to verify the downloaded program (ELF download failed).

Since I am currently out of ideas what else I could check I would be very happy to get suggestions what else I might check in my setup.

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    Dear Forum

    after further investigating my problem to connect the FPGA and SDRAM I again checked whether writing and reading works on all addresses – unfortunately I made a mistake in my first trial. Now after correcting this mistake it turned out that writing and reading just works for a few addresses – no matter which phase shift I've selected for the PLL (- which is quite strange). This is the nios code I’ve used to check access: 

    
unsigned char ledstate = 255;
unsigned int memory_base = 0x02000000; //sdram baseaddress
 
while (memory_base < 0x02000053) { //5a 
        ledstate = 255;
     IOWR_16DIRECT(memory_base, 0, 0x50A0);
      if(IORD_16DIRECT(memory_base,0) == 0x50A0) ledstate &=~ (1<<4);
      else {
         ledstate  &=~ (1<<6);
      }
      memory_base+=2;
      IOWR_ALTERA_AVALON_PIO_DATA(0, ledstate);
}

    I've got the following result:

    0x53 addresses can be accessed for the QSYS sdram_controller setting: 11 rows and 8 columns

    0x5A addresses can be accessed for the QSYS sdram_controller setting: 13 rows and 9 columns

    I think that my sdram-controller has the wrong setting. From the datasheet of the used SDRAM (W9864G6KH) I got this information: 1048576 words x 4 banks x 16 bits. Unfortunately there is no (I didn't found any) information on the number of rows and columns.

    I would be very happy if someone could give a hint how to get the correct sdram-controller configuration.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    OK after further testing I decided to scope the sdram_clk signal against clk_in and found significant jitter. So this might also explain why my memory test makes the nios to hang up after it passes offset + 0x4B - astonishingly that it works until this address. 

    
//#include "sys/alt_stdio.h"# include "altera_avalon_pio_regs.h"
int main()
{ 
 // alt_putstr("Hello from Nios II!\n");
    unsigned char ledstate;
    unsigned int memory_base = 0x02000000;
    int contentcount;
    unsigned int content;
    ledstate = 255;
   while(memory_base < 0x0200004C) { //0x0200004B still works
       contentcount = 0;
        while(contentcount < 16) {
                content = 0;
                content += (1<<contentcount);
                IOWR_16DIRECT(memory_base, 0, content);
                if(IORD_16DIRECT(memory_base,0) == content) ledstate &=~ (1<<4);
                    else {
                            ledstate  &=~ (1<<6);
                        }
                        contentcount++;
if(memory_base & 0x02000049)  ledstate &=~ (1<<7);
           else  ledstate |= (1<<7);
if(memory_base & 0x0200004A)  ledstate &=~ (1<<5);
           else  ledstate |= (1<<5);
IOWR_ALTERA_AVALON_PIO_DATA(0, ledstate);
        }
memory_base++;
   }
ledstate = 255;
 IOWR_ALTERA_AVALON_PIO_DATA(0, ledstate); // just to see whether NIOS hangs up or not
while(1);
 return 0;
}

    Further investigating revealed that only dedicated pins shall be used as a PLL clock output. The board containing the FPGA I recently purchased on ebay seems to be not connecting sdram_clk with the pin 43 (PLL1) or the pin 113 (PLL2) – accordingly to the datasheet these are the only PLL’s of the EP4CE6xxxx devices.

    If I just use one megawizard- generated pll the fitter will auto assign it with pll1 having its output @ pin 43. On my demoboard the SDRAM_clkin goes to PIN 60 of the FPGA which is not an PLL designated output. I will probably rewire the pcb by changing the tracks connected to 43 and 60 to see if my hypothesis is correct.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    OK seems to be my hypothesis is supported by evidence. I changed the connection on the board (see my attached image "FPGAboard.jpg") and voila now it works. The pll1 out at pin 43 now connects with the sdram clk_in at pin38 of the SDRAM and the former connection to sdram_we now reconnects to pin 60 of the FPGA . I used this occasion also to exchange the blue led’s against green ones and I also increased the pre resistors up to 2k. Maybe one should consider to invest more money into a terasic evalboard – to my knowledge the DE series seems to be well engineered