SDRAM signals managing

Please take a look at the DE0-nano SDRAM example in this thread:

http://www.alteraforum.com/forum/showthread.php?t=45927

That will give you a working design, including SDRAM timing constraints (see the .SDC file), which for some reason the IP does not include.

Cheers,

Dave

OK, I'm reading the other post carefully, it's exactly what I need so I'll use it (it works well for my board) and I'll tell you when I've got questions.

For now I'm wondering about the addressing: you configured a 32MB memory but the address is 13-bit wide with a bank selection of 2 bits. So we've got 2^15=32768 locations for 2B words. So, for me, it should be only 65536 bytes. Tell me what is my error. 32M is 2^9*65536 so I think it's about the number of columns but I don't understand what the row/column numbers are. Tell me.

You are missing the main point: SDRAM is not accessed through the raw logical address like a common SRAM.

Browse the web or read any sdram datasheet to understand how sdram signals (row/col/ras/cas ...) work.

OK, I simply read http://en.wikipedia.org/wiki/synchronous_dynamic_random-access_memory#sdram_control_signals and http://hardwarehell.com/articles/ras_cas.htm and it's clear.

Now I have to understand the Avalon-MM. I read...

I have three new questions:

1-How to make the SDRAM available both for the software part (a Nios II cpu in a Qsys system) and the hardware part (a Quartus II design)?

2-How to tell Qsys that the program of the cpu should be stored in the internal FPGA memory and the data should be stored in the SDRAM?

3-I've downloaded this file: http://www.altera.com/products/ip/altera/ocore_sdr_sdram.html

and a first problem is the address bus width. In the file it's 12-bit but in the first qsys system it was 13-bit.

Thanks.

--- Quote Start ---

I have three new questions:

1-How to make the SDRAM available both for the software part (a Nios II cpu in a Qsys system) and the hardware part (a Quartus II design)?

--- Quote End ---

The hardware that needs to access the SDRAM needs to be written as an Avalon-MM master, so that it can initiate SDRAM reads or writes.

Alternatively, your hardware can be an Avalon-MM slave or Avalon-ST sink/source, and you can use a DMA controller to move data from your component to/from SDRAM.

--- Quote Start ---

2-How to tell Qsys that the program of the cpu should be stored in the internal FPGA memory and the data should be stored in the SDRAM?

--- Quote End ---

That is not a Qsys task. That is the job of the linker script.

--- Quote Start ---

3-I've downloaded this file: http://www.altera.com/products/ip/altera/ocore_sdr_sdram.html

and a first problem is the address bus width. In the file it's 12-bit but in the first qsys system it was 13-bit.

--- Quote End ---

You already have a working SDRAM controller (using the standard Altera Avalon-MM SDRAM controller), why are you trying to use this design?

Cheers,

Dave

--- Quote Start ---

The hardware that needs to access the SDRAM needs to be written as an Avalon-MM master, so that it can initiate SDRAM reads or writes.

--- Quote End ---

How do I write it like that?

--- Quote Start ---

Alternatively, your hardware can be an Avalon-MM slave or Avalon-ST sink/source, and you can use a DMA controller to move data from your component to/from SDRAM.

--- Quote End ---

I don't need a DMA.

--- Quote Start ---

That is not a Qsys task. That is the job of the linker script.

--- Quote End ---

How do I configure the linker?

--- Quote Start ---

You already have a working SDRAM controller (using the standard Altera Avalon-MM SDRAM controller), why are you trying to use this design?

--- Quote End ---

That was only for test. Forget it.

--- Quote Start ---

That was only for test. Forget it.

--- Quote End ---

Huh? Why would you forget it. As a design engineer your task should be to "design" the stuff that is unique to your project, and not re-invent the wheel when a perfectly good wheel exists.

So, if your project needs to use an SDRAM controller, and you need to write some custom logic to access the SDRAM in parallel with other "standard" components like a NIOS II processor, then your custom logic needs to "play nicely" with the rest of the system.

Basically this means that your custom hardware has to fit within the Avalon-MM architecture used by the other components in your system.

What does your custom logic have to do? Lets figure out whether you need to create an Avalon-MM master, or an Avalon-MM slave that interfaces to a DMA controller.

Cheers,

Dave

OK, what I have to do is to look at 4 signals (connected as the board GPIOs), store them somewhere then analyse it to tell what happens.

What I wanted to do is to store it in the internal FPGA RAM (it's easy) but lately it appeared the memory was to small and I decided to use the board SDRAM instead. But the mechanism of the SDRAM is too complicated for me so maybe I'll use a serial connection trough the USB to store it on the PC and analyse it with a simple software instead of an embedded one.

I'm listening for your advices in the matter...

--- Quote Start ---

OK, what I have to do is to look at 4 signals (connected as the board GPIOs), store them somewhere then analyse it to tell what happens.

--- Quote End ---

Ok.

--- Quote Start ---

What I wanted to do is to store it in the internal FPGA RAM (it's easy) but lately it appeared the memory was to small and I decided to use the board SDRAM instead. But the mechanism of the SDRAM is too complicated for me so maybe I'll use a serial connection trough the USB to store it on the PC and analyse it with a simple software instead of an embedded one.

I'm listening for your advices in the matter...

--- Quote End ---

So, this is where "thinking" in terms of SDRAM has misled you. If instead you were thinking of Avalon-MM masters and slaves, then you need "something to read the GPIO" and "something to save the value read". There's numerous ways to do this, let me suggest a couple of options ...

1. Custom Avalon-MM master.

If the rate at which the GPIO pins are written is critical, eg., the rate has to be exactly 100Hz. Then you can create an Avalon-MM master that includes a 100Hz timer. When the timer expires, a control state machine can read the GPIOs, and then issue a write to an Avalon-MM master interface. You Qsys system can then connect that master to either internal SRAM or external SDRAM.

2. Standard Avalon-MM components.

A PIO input component can be used to provide read access to inputs. A DMA controller can be used to read the PIO and write to somewhere else, eg., SRAM or SDRAM. I haven't used the Altera DMA controller, but if it has a timer facility, then you might be able to setup a scheduled DMA transfer. Alternatively, you can use a NIOS II processor to perform the read of the PIO and write to SRAM/SDRAM.

3. Minimum effort.

Create a Qsys system with a GPIO port and a JTAG-to-Avalon-MM bridge and read the GPIO from your PC. The SDRAM example I provided you already has the JTAG interface, so all you need to do is add a PIO component and connect it to your GPIO pins.

If the rate at which the GPIO is read is not critical, then (2) or (3) would be a good place for you to start.

Cheers,

Dave