SDRAM on DE0-nano board

Hi Paul,

Here's a design that creates a Qsys system containing a JTAG master and an Altera SDRAM Controller. I tested it under Quartus 12.1, 13.0, 13.1, and 14.0. Unzip the file into c:/temp/ and follow the instructions in the readme.txt file, i.e.,

DE0-nano 'sdram' design
-----------------------
8/19/2014 D. W. Hawkins (dwh@ovro.caltech.edu)
To synthesize the design, perform the following steps;
1) Unzip de0_nano_sdram.zip, eg., into your c:/temp directory.
2) Start Quartus II 
   This script was tested with versions 12.1, 13.0, 13.1, and 14.0.
   The SDRAM controller parameters changed slightly after
   Quartus 12.1, see scripts/qsys_system.tcl.
3) Select the Tcl console.
   If the Tcl console is not visible, use the menu option
   
   View->Utility Windows->Tcl Console
   
4) Use the Tcl console to change into the DE0-nano source folder.
   
   tcl> cd c:/temp/de0_nano_sdram
5) Issue the following command to source and run the synthesis script
   tcl> source scripts/synth.tcl
   The console will output the script progress.
   
   For example, under Quartus II 12.1sp1 (on Windows XP) the output was:
   Synthesizing the DE0-nano 'sdram' design
   ----------------------------------------
    - Quartus Version 12.1 Build 243 01/31/2013 Service Pack 1 SJ Full Version
    - Creating the Quartus work directory
      * C:/temp/de0_nano_sdram/qwork
    - Create the project 'de0_nano'
      * create a new de0_nano project
    - Applying constraints
    - Creating the VHDL files list
    - Generate the Qsys system
      * creating the Qsys file in the work directory
      * Tcl-to-Qsys generation for Quartus version 12.1
      * generating the Qsys system (please wait)
    - Processing the design
    - Processing completed
   and under Quartus II 14.0 (on Windows 7) the output was:
   Synthesizing the DE0-nano 'sdram' design
   ----------------------------------------
    - Quartus Version 14.0.0 Build 200 06/17/2014 SJ Full Version
    - Creating the Quartus work directory
      * C:/Temp/de0_nano_sdram/qwork
    - Create the project 'de0_nano'
      * create a new de0_nano project
    - Applying constraints
    - Creating the VHDL files list
    - Generate the Qsys system
      * creating the Qsys file in the work directory
      * Tcl-to-Qsys generation for Quartus version 14.0
      * generating the Qsys system (please wait)
    - Processing the design
    - Processing completed
   
   This design passes TimeQuest analysis, with no unconstrained paths.
   NOTE: The Altera SDRAM controller does not create an SDC constraints
   file. See scripts/de0_nano.sdc for appropriate SDRAM constraints.
   At this point, the design is ready to test in hardware.
  
   The Qsys system instantiated in the top-level design was created by the
   synthesis script (see scripts/synth.tcl for details). You can inspect
   the Qsys system by starting Qsys via Tools->Qsys, then open the file
   qsys_system.qsys, and look at the Qsys system settings, eg., the SDRAM
   controller parameters.
  
   If you repeat this sequence under Quartus 12.1, 13.0, 13.1 or 14.0, 
   you will see that although the Qsys GUI changes slightly, the Qsys
   SDRAM controller parameters remain correct.
6) Program your board
a) Plug the DE0-nano into your computer.
b) Open the Quartus programmer.
   In the main Quartus GUI, the programmer has a symbol on the top
   menu bar that looks like a cable going into a diamond,
   If you hover your mouse over it, the tooltip is "Programmer"
   
c) At the top-level of the programmer GUI, there is a button that says
   "Hardware Setup", to the right of that should be the text 
   "USB-Blaster ". If you do not see the USB-Blaster text,
    click on the "Hardware Setup" program and see if its listed
    there, if it is, select it.
    
d) In the programmer GUI, you should see the file de0_nano.osf ready
   to be programmed into the single device in the JTAG chain.
   
   Press the "Start" button to download to the board.
   
e) The LEDs on the DE0-nano will then start counting.
   This indicates that the 100MHz PLL is operating correctly.
   
f) Start SystemConsole
   The GUI directions for starting SystemConsole change depending
   on the Quartus version. Under 12.1 you have to start Qsys
   and select it via Tools->System Console, under newer versions
   of Quartus, the main GUI Tools menu can be used, eg., under
   Quartus 14.0 use Tools->System Debugging Tools->System Console.
   
   Start SystemConsole and source the JTAG commands script, eg.,
   
   % source c:/temp/de0_nano_sdram/scripts/jtag_cmds.tcl
   
   Then run the (simple) SRAM test
   
   % sdram_test
   Writing to 256 SDRAM locations
   Reading from 256 SDRAM locations
   SDRAM write/read checks passed!
   You can pass the number of locations to test, eg., 
   
   % sdram_test 0x1000
   Writing to 4096 SDRAM locations
   Reading from 4096 SDRAM locations
   SDRAM write/read checks passed!
This design and the JTAG tests is extremely basic and simply shows that
the memory works. A more exhaustive memory test would create a Qsys
system with a pattern generator, DMA controller, and pattern checker,
and then use that to send burst data to and from the SDRAM controller.
Enjoy!

Cheers,

Dave

Hi Dave,

When I try to source synth.tcl , I receive error :

error: can't find package ::quartus:: project while executing "package require ::quartus:: project" (file "synth.tcl" line 34) invoked from within "source synth.tcl"

Hi Paul,

--- Quote Start ---

When I try to source synth.tcl , I receive error :

error: can't find package ::quartus:: project while executing "package require ::quartus:: project" (file "synth.tcl" line 34) invoked from within "source synth.tcl"

--- Quote End ---

Which Tcl console did you try to run the script from? It should be run from the Quartus Tcl console, not SystemConsole.

Note that the instructions indicate you should cd to the top-level of the project folder and issue "source scripts/synth.tcl", i.e., you should not have changed directory to the scripts folder and issued "source synth.tcl". The script uses the location you source it from to determine relative paths.

Cheers,

Dave

Hi Dave,

I have now added an SDRAM controller to the qsys design from the jtag-to-avalon-mm example, gave it address 0x0 and assigned all the appropriate pins for the DE0-nano SDRAM with pin-planner.

In the jtag_cmds_sc.tcl script , I have added extra code to "talk" to the external SDRAM on the DE0-nano as follows :

proc sdram_write {offset data} {
	global jtag
	if {!} {
		jtag_open
	}
	set addr 
	master_write_32 $jtag(master) $addr $data
	return
}
proc sdram_read {offset} {
	global jtag
	if {!} {
		jtag_open
	}
	set addr 
	return 
}

When I then try to write from the tcl console with command "sdram_write 0 0x12345" for example and read it back with "sdram_read 0" , I am only reading 0x00000045, hence only the lower 8 bits seem to be written everytime. What would be the issue here. Is it something with the tcl script or my SDRAM controller settings?

In my SDRAM controller settings , the data width is set to 16 bits , chip select :1 , banks: 4 Under address width , Row : 13 , Column : 9

Thanks,

Paul

--- Quote Start ---

I have now added an SDRAM controller to the qsys design from the jtag-to-avalon-mm example, gave it address 0x0 and assigned all the appropriate pins for the DE0-nano SDRAM with pin-planner.

--- Quote End ---

But the SDRAM controller that Altera provides *DOES NOT* also come with timing constraints. Did you add them?

--- Quote Start ---

When I then try to write from the tcl console with command "sdram_write 0 0x12345" for example and read it back with "sdram_read 0" , I am only reading 0x00000045, hence only the lower 8 bits seem to be written everytime. What would be the issue here. Is it something with the tcl script or my SDRAM controller settings?

--- Quote End ---

Most likely SDRAM controller settings, though you could have a board or pin assignments error where the data mask bit for one lane is bad and is masking that byte lane.

Regarding the SDRAM controller settings, I recall changing the refresh rate to 7.8125us (half the default) and the power-on init delay to 200us (twice the default), to match the settings used in a couple of DE0-nano examples that I looked at.

Try the zip file I provided you, I know it works on my DE0-nano, so if it does not work on yours, that implies a hardware error where the mask bit is stuck.

Cheers,

Dave

Hi Dave,

I have tested the example in the zip file and and it works fine, so there should be no problem with the hardware.

Going back to the SDRAM controller in Qsys, I have changed the refresh rate and power-on delay as you said but there is still something wrong.

Again, I am not sure if my settings in the memory profile tab are correct for the SDRAM on the DE0-nano. I have the data width set to 16 bits , chip select :1 , banks: 4 Under address width , Row : 13 and Column : 9.

The address assigned to the SDRAM controller is 0x10000000, therefore I have added the following to the tcl script. I am not sure if this is correct as I more or less replicated how you wrote it for the on-chip SRAM and changed the base address from 0x1000 to 0x10000000. The on-chip RAM also has a 32-bit data width instead of 16-bit so I'm wondering if my below code is acceptable? : Thanks

proc sdram_write {offset data} {
    global jtag
    if {!} {
        jtag_open
    }
    set addr 
    master_write_32 $jtag(master) $addr $data
    return
}
proc sdram_read {offset} {
    global jtag
    if {!} {
        jtag_open
    }
    set addr 
    return 
}

--- Quote Start ---

I have tested the example in the zip file and and it works fine, so there should be no problem with the hardware.

--- Quote End ---

Great! Its always useful to have minimal designs that prove your hardware works.

--- Quote Start ---

Going back to the SDRAM controller in Qsys, I have changed the refresh rate and power-on delay as you said but there is still something wrong.

--- Quote End ---

In what respect? What error are you seeing?

What you have done seems reasonable. The Qsys system inserts width adapters, so the fact that your JTAG master is 32-bits and your SDRAM interface is 16-bits should not matter.

Whenever I see a problem in hardware, I first look at the problem using the Signal Tap II logic analyzer (which you can add to your FPGA design), and then I use a simulation to duplicate what I see in the hardware.

Try those tools and see how far you get. Ask questions when you get stuck.

Cheers,

Dave

I'm not seeing an error. Just when I write to the SDRAM controller and try and read it back , the value is either 0xffffffff or just the last 8 bits are as expected.

To do a simulation, I need to create some testbench?

--- Quote Start ---

I'm not seeing an error. Just when I write to the SDRAM controller and try and read it back , the value is either 0xffffffff or just the last 8 bits are as expected.

--- Quote End ---

I'd call that an error :)

You don't see this error with the example I gave you, right? Try comparing the top-level design. Perhaps you have made a simple mistake and not connected the ports on your Qsys instance correctly. Does the Quartus messages window have any weird looking messages?

--- Quote Start ---

To do a simulation, I need to create some testbench?

--- Quote End ---

Yes, but first try tracing the RAM access using SignalTap II.

Cheers,

Dave

I have been comparing the top-level designs and I still can't see what the problem is with mine. I have checked over and over again the pin assignments and qsys settings and compared them to yours and all seems to be ok. Below is my qsys system. The qsys_systm.v generated from that I use as my top level file. I just can't seem to write to the SDRAM. I must be missing something obvious.

https://www.alteraforum.com/forum/attachment.php?attachmentid=9316