Stratix V Development board with QSFP ports

--- Quote Start ---

I have added the SDRAM controller to the qsys and assigned all the pins.

The next step tho I have trouble with and that is how to use it. I have tried that example of writing to the RAM from the host computer via the jtag interface but would like to do it differently.

--- Quote End ---

Ok, but at least you know the SDRAM interface works now. You need to mentally separate "checking out the hardware" using JTAG from "what I really wanted to do", eg., access SDRAM via a NIOS II processor. Its important to check that your hardware works via something low-level like JTAG before trying to debug some weird "software bug" in NIOS that is actually related to the SDRAM not working.

--- Quote Start ---

How to read and write to the SDRAM with either VHDL code or a NIOS program? Must I specify the RAM address everytime on the address lines or do I just send data on data lines? How then would I read the data at a specific SDRAM location? I have been trying to find an example of how this is done but no success yet.

--- Quote End ---

You simply write your C code, and create a linker script telling the compiler that the code is supposed to run out of SDRAM, and that your stack(s), heaps, etc., are located at memory addresses that correspond to SDRAM addresses.

Both the JTAG and NIOS II Avalon-MM masters access devices via their addresses. The Avalon-MM protocol takes care of the different timings required by different devices. From the software perspective, you simply think of accessing devices as either a read or a write. This is enough to get you something working. When you need to think about "performance", then you may need to worry about whether some high-performance part of your code needs to be linked to on-chip SRAM, or whether you need a cache controller, or hardware acceleration. For now, just stick with the simple stuff.

The DE0-nano CD has a NIOS example that includes the SDRAM controller. The design was built using Quartus 13.0, so its not too old. Did you look at that example?

Cheers,

Dave

What I want to really do is write C code that doesn't run out of the external SDRAM but as the program is running, it writes data to the SDRAM and then reads it back at some stage. If I could write VHDL code to do this it would be even better. This way I can understand properly how data is written and read from RAM. Example code showing how this is done would be a super help.

In order to do this, must I specify a RAM address on the address lines connected to the SDRAM, then place the data on the data lines? As these lines are parallel, i'm not sure how to do this in code. Should there be an address register and data register and the SDRAM controller takes care of converting from serial to parallel?

Cheers,

Paul

--- Quote Start ---

What I want to really do is write C code that doesn't run out of the external SDRAM but as the program is running, it writes data to the SDRAM and then reads it back at some stage.

--- Quote End ---

In that case, your linker script can just avoid defining the SDRAM addresses as useable, and your C-code can just read/write to the SDRAM addresses, eg., assuming your SDRAM was in the Qsys address map at 0x1000_0000, you can write to the SDRAM from C code via

uint32_t *sdram_base = (uint32_t *)0x10000000;
// Fill a few locations in SDRAM
for (int i = 0; i < 0x100; i++) {
    sdram_base = i;
}

In this code, because the pointer is defined as 32-bits, the sdram_base[i] will increment 32-bits per address.

--- Quote Start ---

If I could write VHDL code to do this it would be even better. This way I can understand properly how data is written and read from RAM. Example code showing how this is done would be a super help.

In order to do this, must I specify a RAM address on the address lines connected to the SDRAM, then place the data on the data lines? As these lines are parallel, i'm not sure how to do this in code. Should there be an address register and data register and the SDRAM controller takes care of converting from serial to parallel?

--- Quote End ---

In this case you need to create an Avalon-MM master. The master interface needs to implement the Avalon Memory Mapped Protocol.

Have you taken a look at the Avalon Interface Specification and the Avalon Verification IP Suite? If not, perhaps start by doing the JTAG-to-Avalon-MM tutorial I pointed you to earlier. You can view the Avalon-MM bus transactions in the BFM simulation, and then that'll help you "see" what HDL you need to implement to read or write SDRAM from VHDL.

What would actually be your "master", eg., are you trying to communicate with the FPGA via a microcontroller?

Cheers,

Dave

Possibly we will eventually have a microcontroller sending data to the FPGA for testing.

We will be working with a TCP core loaded on the FPGA which is wrote in VHDL and the received data to be re-transmitted will be first getting buffered in external RAM so I am just trying to figure out how I can read that data with VHDL.

I have done that JTAG-to_Avalon-MM tutorial which I thought was a great help and saw the bus transactions in the BFM simulation. Would I have to write and read all of the control signals myself such as waitrequest, byteenable etc. in VHDL ? So I take it that by writing a program to communicate with the SDRAM running on the NIOS is much simpler? :)

For test and debug (and program load) consider using the PCIe (slave) to Avalon bridge so that a host program can directly read/write any Avalon slaves (that are connected to the bridge). Watching a 'hexdump' that updates once a second (or so) can be very informative.

For a Linux host I think one of the standard dev entries gives you appropriate access, but a driver that uses pread/pwrite is also reasonably trvial to write - you can do copy_to/from_user() directly from the mapped PCIe addresses.

Note that host access will be slow (far slower than you imagine 'slow' would be).

--- Quote Start ---

Possibly we will eventually have a microcontroller sending data to the FPGA for testing.

We will be working with a TCP core loaded on the FPGA which is wrote in VHDL and the received data to be re-transmitted will be first getting buffered in external RAM so I am just trying to figure out how I can read that data with VHDL.

--- Quote End ---

Its more likely that you will have;

1. Host PC (PCIe root-complex)

2. Stratix V PCIe end-point

3. PCIe end-point to Avalon-MM master bridge

4. DDR3 Controller

5. TCP/IP Core

6. 40Gbps Core (QSFP+ interface)

7. Scatter-gather DMA Core

The job of the scatter-gather DMA core will be to transfer data from the host PC to either the DDR or to the TCP/IP core. The data transfer rates are likely too high to have any sort of microcontroller in the data path.

--- Quote Start ---

I have done that JTAG-to_Avalon-MM tutorial which I thought was a great help and saw the bus transactions in the BFM simulation. Would I have to write and read all of the control signals myself such as waitrequest, byteenable etc. in VHDL ? So I take it that by writing a program to communicate with the SDRAM running on the NIOS is much simpler? :)

--- Quote End ---

Writing C code or VHDL is simple. Ultimately the appropriate language comes down to "what do you want to do?". Since you're learning, try both, and then you'll understand what it takes.

For example, to understand how to create an Avalon-MM master, write an SPI-to-Avalon-MM master bridge, or a UART-to-Avalon-MM master bridge, and interface a microcontroller SPI port or UART to your DE0-nano board.

Cheers,

Dave

--- Quote Start ---

For test and debug (and program load) consider using the PCIe (slave) to Avalon bridge so that a host program can directly read/write any Avalon slaves (that are connected to the bridge). Watching a 'hexdump' that updates once a second (or so) can be very informative.

For a Linux host I think one of the standard dev entries gives you appropriate access, but a driver that uses pread/pwrite is also reasonably trvial to write - you can do copy_to/from_user() directly from the mapped PCIe addresses.

Note that host access will be slow (far slower than you imagine 'slow' would be).

--- Quote End ---

Yep, that is true :)

This thread has Linux code to do just that (use a dev entry to access the board) ...

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

Cheers,

Dave

I'm not sure how little of an TCP/IPv4 stack you can get away with these days. I'm not sure you'll get away with (the equivalent of) an early 1980s implementation. IPv6 support is another monstrous headache!

A hardware only solution might also take a lot of logic and be very hard to debug.

It might be easiest to use a nios to handle the connection establishment (and possibly received data acks) and just implement data sending in VHDL.