Using Qsys SRAM and SDRAM controllers without a Nios II

[Altera_Forum]

I need to communicate with the SRAM in the DE2-115 board using purely VHDL code. No Nios II. Later I may have to use the SDRAM instead if bigge memory is required. 

 I understand that a controller is required. Is it only found inside Qsys? If I decide to use the Qsys controller, how do I make use of it without any Nios II i.e link the Qsys memory controller to a state machine written in VHDL which is not part of the Qsys system. If you have better ideas then please let me know.

[Altera_Forum]

You can create a Qsys system with just the SDRAM controller and then export the Avalon-MM interface and have your VHDL code connect to that. i.e. the Qsys system in this case is more like an IP block, with SDRAM pins on one side, and Avalon-MM on your VHDL side. 

 At some point, you may find it simpler/easier to just package your VHDL code in a Qsys IP component, and if you agree things are headed that way, I would recommend shifting sooner rather than later.

[Altera_Forum]

aha, that means I will have to understand how to read/write using the Avalon-MM bus. As far as I am aware, that should be simple. 

So the bundle of wires used for the SRAM controller Avalon-MM shall be exported as a conduit?

[Altera_Forum]

Yes, the wires of the Avalon-MM interface can be exported similarly to how you would export a conduit. 

 The SRAM "controller" should be trivial and you could simply implement that directly in your VHDL. The SDRAM controller would be the primary motivation to involve Qsys/Avalon-MM in your design.

[Altera_Forum]

From my experience, it is much easier to package your code in QSYS component and start communication with the SDRAM, so I agree with ted. 

It is easier to understand the Avalon_MM interface than trying to work directly with the SDRAM controller. You will need to write your own custom Avalon-Master. You may find tutorials that explain that.

[Altera_Forum]

Yesterday I used the megawizard, it looks different from how it used to in earlier versions of the Quartus II. It looks like we are creating a Qsys component now.  

 Basically, I was going to do some basic simulation with the memory controller. However, I found that the tool generates several files, some of which look like tcl scripts and there is a folder named synthesis and another named simulation and there is some script called msim_setup.tcl. I am not sure how I can just go ahead into a VHDL testbench, instantiate the memory controller and start playing with it. I am confused. I am not trying to ModelSim simulate a Nios II system, its just a single memory controller on its own.

[Altera_Forum]

I tried once to simulate QSYS block which included one custom component and one on-chip memory. 

Normally I don't simulate QSYS, but that time when I created the simulation files, it showed me error msg related to the custom component but I did not investigate. I compiled the files needed manually but after I ran the file msim_setup.tcl in altera modelsim. After you run this file, you see some new commands in the command line of modelsim. Commands are like "elab" and some commands related to the compilation. After I compiled, I ran the command elab which started the simulation. I did not try to integrate the top QSYS module in a testbench. I manually forced the rst commands and the clk from the waveform viewer in modelsim.

[Altera_Forum]

I have noticed that in Altera Quartus we have the IP core tool which when opened for the SDRAM controller (did not find SRAM controller in the IP suite) actually opens up Qsys like GUI rather than the "Megawizard" type GUI that I am used to for creating a PLL or DSP multiplier. 

I have read the "Introduction to Intel FPGA IP Cores". It states that there are different ways to simulate the cores, most of them use some sort of script. It then states:  "1.8 Instantiating IP Cores in HDL Instantiate an IP core directly in your HDL code by calling the IP core name and declaring the IP core's parameters. This approach is similar to instantiating any other module, component, or subdesign. When instantiating an IP core in VHDL, you must include the associated libraries."  Now I am shaking my head in disbelief. If I can just instantiate the IP core using its name and declaring the core's parameters, what is the point of so many files being generated? What also is the purpose of so many scripts? I do not see how they are being very helpful here.  The main point that is not clear for this document is that it states: "When instantiating an IP core in VHDL, you must include the associated libraries." It does not explain how to know what the associated libraries are. This does not make any sense at all at this time.  All I want to do is to get this SDRAM controller into my VHDL top level and simulate it

[Altera_Forum]

Believe me it is very easy to integrate the sdram controller in your design, by QSYS, and compile. I don't talk about simulation because I did not simulate the sdram controller. 

I remember I created one new QSYS project and included it in a project (custom cyclone fpga board which included SDRAM) and made the project running in less than one hour, including writing the Nios C code that tested the SDRAM.  Assume you have the SDRAM controller for simulation, do you a model for the SDRAM itself? I mean having the SDRAM controller in the simulation without the SDRAM model is useless. For simulation, I recommend that you start with a simple QSYS project which includes one on-chip memory and one custom master Memory Mapped block. Or a simple QSYS project which includes one NIOS processor and and on-chip memory and GPIO peripheral to make yourself familiar with everything QSYS.

[Altera_Forum]

I wouldn't classify the SDRAM Controller as an [Megacore-style] "IP Core", and I don't think the instructions you are reading apply. The SDRAM Controller gets generated by a perl script invoked by Qsys with the parameters you have supplied in the Qsys GUI, which creates a plain-text Verilog module with the controller in it. There aren't any parameters you control through HDL, and the controller can only be changed by re-generating the Qsys system. 

 The controller itself ("just the controller") is sitting in simulation/submodules/blah-blah-blah-new_sdram_controller_0.v or similar filename based on how you have named it. Add that Verilog to your testbench and wire it up, if you care to approach it this way.  For an SDRAM model to wire it to, the ones supplied by Micron were pretty easy to work with.

[Altera_Forum]

OK, I have found what the problem is all along. Qsys is not generating the same files when I select VHDL under Generate HDL in "simulation" tab then when I select Verilog. I am going to post a new question. Now makes sense why the information in documentation does not match the software and why ModelSim said that an entity is "not bound". IT IS HAPPENING BECAUSE OF A BUG IN QSYS.