05-09-2017 08:11 AM
I'm trying to access(read/write) the SDRAM on DE0 nano board using NIOS ii system.What I have done so far is, 1. I build a NIOS processor with an onchip memory. 2. Build an SDRAM controller using Qsys and connected that with the NIOS system. 3. wrote a program to read/write data to corresponding data/address lines in SDRAM controller. I'm having an issue that, I write data to a some given address when I read back that write data is present in every address. I think memory addressing is wrong. How can I fix this? Is there any another approach to Read/Write data from SDRAM?? What I want is read/write data to SDRAM using NIOS, I don't want to use SDRAM in NIOS system instead of onchip. my top module bdf file (as an image) attached with this.
05-13-2017 09:26 AM
Hello Dumindu,- Make a generic quartus application with the DE0_system builder tool that came with your board (other boards have this so yours i assume as well) - Open the project .qpf in quartus. - Launch qsys from quartus and add clock, cpu, pll, memory and connect components properly. (do not forget the phase shift on the pll). - Compile and generate the entire qsys config. - Instantiate config in vhdl/verilog - Compile and download it. - Launch Eclipse from quartus - Generate nios ii application and BSP from template - Download and compile it. Best Regads, Johi.
05-16-2017 03:53 AM
Hi Johi,Thank you! for your reply. I have followed steps that you're mentioned above. When I'm trying to download .elf file to DE0 nano I'm getting an error saying that "Downloading ELF Process failed". I found that many people facing the same problem like me when they try to use SDRAM with NIOS. Do you have any idea why this is happening? Following are the console output when I'm trying to Upload the .elf. Downloading 00800000 ( 0%) Downloading 00803804 (87%) Downloading 01001000 (99%) Downloaded 15KB in 0.2s (75.0KB/s) Verifying 00800000 ( 0%) Verify failed between address 0x000000 and 0x003107 Leaving target processor paused Best Regards, Dumindu.
05-16-2017 10:49 AM
Hello Dumindu,The problem you are referring to is a problem that many of those that started with FPGA’s had. It took me a few weeks on my DE0-CV and even on my DE2-115 it is sometimes difficult to get a simple Nios configuration running and say “hello world”. So, since I am on holyday (the isle of Tenerife) I will try to put what I learned on paper. This will not be a hands on manual as you can find on the Altera Universty website but rather a report of the pitfalls I went in before I got something running. I do not consider myself a specialist, I worked about 1.5 years now with the tools (hobby ). Step 1: Quartus config file + blinking led. With both DE’s I had, so I assume with others, a companion CD comes/or you can download this form the Terrasic site. There is a tool that generates a basic empty project frame with the FPGA type configured correctly and with the pin assignment for your chip. The first thing to do is to generate such a framework application, check on the components you need (types of sram, sdram etc.) and open the generated .qpf file in quartus. On every step that you make in your process to get qsys operational, what is most important is to install check points in your procedure so you know at least that this part is working. This time you can make a .v verilog file that makes a led burn or even blink. If you can make it blink based on the system clock, you also know that your clock is working. Step 2: simplest QSYS projects of all: use the on chip ram If you are so lucky to have and FPGA with enough onchip RAM you can make a really simple QSYS application. I think you have about 512 Kbit on your chip so a nios ii hello world/small should be possible I think. The bad thing about the SDRAMS on the DE0-CV, DE2-115 and others is that you need a pll (a device that has multiple outputs that oscillate with a frequency that is a multiple of the input clock frequency and with a definable phase shift) to get them working. I fell over this issue when I ran my first DE0-CV tutorial from the Altera university: the first let you make a complete configuration with SDRAM then to see that it does not work and afterwards they add a chapter that explains why it does not work and that you need an PLL to create a phase shift between the IP block from QSYS that drives the SDRAM and the actual SDRAM chip. So, if you can use the onchip ram, you do not have this issue. Other advantage of onchip ram is that the main QSYS component you need to instantiate in your man .v/.vhd file does not need to connect with external sdram or sram chips. If you do not have to connect them, you cannot misconnect them. You end up with a configuration that has only .clock and .reset external signals. My strategy is to get the onchip ram operational at first and then go to SDRAM, remember what I said above. If you decide to use the sdram there are 2 ways to connect the pll: or you can add a separate component to your .v . .vhd or you can configure one in QSYS. Do not forget to connect all signals (especially the .C1 phase shifted clock signal for the sdram chip) in your .v/.vhd. Other thing that is interesting in qys is that it is able to generate a kind of typical instantiation of your main nios configuration. Using this configuration as an example you are sure that you name the signals correctly. Make also sure that there are no errors when your qsys config compiles but I think the people that wrote qsys dit a fine job to make sure that more or less all things you can do wrong with a basic configuration are signaled in the output window. So: clock + cpu + onchip sram + jtag uart + system id is for me the most basic configuration of all. Step 4: instantiate your nios configuration in quartus (.v / .vhd) Put the template configuration you generated in qsys in your .v and connect the signals as described above and compile this. Do not forget to add the Qip to your project. Compile and download this. All the above steps, I assume you made them because otherwise you would not having the problem you have. On this point there is 1 thing that dazzled me for weeks while trying to get the nios /f processor to work memory: there are 2 types of .sof files that are generated after compile: a version (_time_limited.sof) and a regular version. If you are using the light (free) version of Quartus, make sure you download the _time_limited version of the .sof. In my case the /s processor run with the standard .sof but for the /f processor I needed the time limited version if the sof. If you take the wrong one, you will be able to download but the cpu will not start. Step 3: eclipse, You feel directly if you work with this tool that it is a combination of different sub and helper tools combined together. It is not a solid block like for example Microsoft Visual studio. The difficult thing for a beginner is finding your way in the woods where may options are confusing and dead ends (Altera built a work around this problem and provided and other very basic programming tool in their university program). What are the points to look at in eclipse. The workspace: when eclipse starts up it asks for a workspace directory. I always select the directory where my qsys project is in. Once opened: generate your “hello world/small” application based on the .sopc file generated with qsys. If you take the “hello world/small” is so small I think it will fit in the onchip ram of your de. Once compiled, download the project .elf clicking right on the generated application (not on the bsp) select Debug As. For a reason nobody can understand, the system id component in qsys does work sometimes and sometimes not. Even after many versions, this problem remains on the table. System id does 2 things: it gives your system and id number (parameter in qsys) and records a timestamp in your fpga / nios code. If you go to the second tab in the dialog box you can disable the checks for the timestamp and the id, and in many cases this is handy but has it disadvantages. Make also sure that the correct .elf file is downloaded (first tab) if you select the .elf manually you can end up with downloading the wrong file. If all goes well, eclipse downloads your application, verifies it, then sends some output messages to the console window, clears it a few times more and ends up with a breakpoint in your .main file. If you press the > symbol on the debug toolbar you should get your standard output “hello world”. At this time make a complete backup of your application (I close quartus and put the entire project directory on my external hard drive) and continue with the sdram target. I do this quite often: if you end up in the ditch with configurations and others, regular backups of sub steps are a blessing). Remarks: Sometimes you end up with a configuration you modified so much time you do not trust it any more. In those cases you can delete the software subdirectory of your project to delete all traces and start again from the .sopc file in eclipse to generate a new .c (bsp) hello world project. (you will need to delete the references to these projects in eclipse by right clicking on them and deleting them on top of the delete). You can also delete the _qsys directory, if you do this, you can regenerate the entire thing with recompiling your .qsys project file that resides in the main directory and remove all traces of previous compiles. Do not expect things to works the first day, there are a lot of things that can and will go wrong but if you do not give up it will work sooner or later. A last remark: Quartus has an option that lets you backup your application. You might consider adding this backup to your question on the forum to enable others to help you . Best Regards, Johi.