Nios II

--- Quote Start ---

originally posted by rppolicy@Jul 2 2004, 09:06 AM

the code does fit in the on chip memory. i checked everything i could: the .hex is in the right directory and matches the one i generated (not the blank one), the reset vector is correct, etc. has anyone else been successful in doning on chip rom? please help... http://forum.niosforum.com/work2/style_emoticons/<#emo_dir#>/sad.gif

rick

--- Quote End ---

I have to say that you are correct in your observations...

It does only run partially, if at all.

The build environment, is really disappointing, as it gives you less control, being unclear about what files are actually used, and it seems to use the wrong set of files.

Apart from all this, it takes ages to compile, as it rebuilds everything, not just what needs to be rebuilt. (god knows why...)

I find the Eclipse kit being an overkill attempt at this.

It would be nice, if they could come up with a "out of the box" kit, that works in the devel board, including a source config file for this.

After all, you pay for it to be working when you buy it.

This is not what i call an easy start.

Hello Rick,

Only for my understanding, do you use the hex from the Germs of Nios I with the Nios II? If you do like this it won’t work because the instruction set of Nios I and Nios II is different. How do you config the FPGA in development without JTAG?

Bye,

niosIIuser

NiosIIuser:

I did use the hex from the NiosII. When you check the sdk, they give you a nios2_germs_monitor directory under the sdk directory. It contains a .s and a makefile. You just pass the start address and srec name to the makefile. I have a Parallax dev board. This board has some sort of Pic chip that monitors the RS232 port. When you launch the px.exe app from a command prompt, it sends the .rbf to its on board flash. It is really kind of cool. If you use the /P option it will always boot from your FPGA data file, but you can send a new one at any time.

Rick

rppolicy,

I suggest two things:

Check out app note# 350 on migrating Nios to Nios II. I know you are writing about a new design, but this document talks about the differences between legacy SDK mode and eclipse/HAL.

Next, I would like to make one thing clear: With Nios II, we wanted to deliver the SDK support just as it was for Nios I -- this way you lose nothing!! We realize that many people writing simple software or those who prefer a command-line world will prefer the SDK. However, as our performance and capabilities increase, please realize that the move to an IDE is for the common good in the long run: lots of software developers have been asking for this for some time because they wish to port more platform independent code to Nios (which is where the HAL comes in). Toss in RTOS/OS support, and a more complex software dev environment is in order.

Anyways, sorry for all that text above. I suggest one thing for the GERMS monitor -- I am a bit confused by this talk of hex files and such -- you should only need to enable GERMS by:

1. Adding an on-chip memory from the "Legacy Components" folder of SOPC Builder

2. Making this memory 2K bytesx32

3. Specifying GERMS for the contents of memory

4. Connect CPU instruction/data masters to the memory, and setting the boot address to it

5. Enabling legacy SDK support as you have already done.

Last, please note that we do not "officially" support the Nios II /f core with legacy mode. This is due to the different data cache architecture compared to Nios I. We have found that most code will work, but cannot guarantee that all calls to C libraries will keep things like volatile pointers as they should. As I said though, most things will work http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif

Thanks for the help! I wasn&#39;t aware of the legacy component folder in the SOPC builder. One I used it, the application works perfectly! I was using the Nios2 on chip memory. When you select ROM, a note at the bottom appears (<device name> will be loaded using <device name.hex>). I confirmed this looking at the VHDL generated for my on chip memory device. Does Nios2 support the s part?

I have not used the HAL/IDE yet because of various reasons. The first one is I don&#39;t have JTAG on my dev board. I would have to lift/cut/jumper the 100 pin TSOP to have this. Second, I just became familiar with the SDK and don&#39;t want to mess up my evaluation with learning something new. I wanted to compare apples with apples (Nios1, Nios2). Third, after reading APP350, I didn&#39;t like some of the changes. The SDK code looked much more object oriented. For example:

SDK:

pio->np_piodata = bits;

bits = pio->np_piodata;

HAL:

IOWR_ALTERA_AVALON_PIO_DATA(address, bits);

bits = IOWR_ALTERA_AVALON_PIO_DATA(address);

I prefere to write my code that looks like the SDK, instead of calling an obnoxiously named function/macro.

Dispite my preferences, I do however plan to evaluate the HAL/IDE, and will probably use it in future designs. I see the need for it, because in my own experience I had to write an abstraction layer for some of the devices that we interface to. You can quickly paint yourself in a corner by making the code too object oriented. One hardware change and your toast! Sometimes it&#39;s best to make things generic. My bias probably came from my impressions of the Nios1 sdk. I thought it was the best thing since sliced bread. http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif

Rick

--- Quote Start ---

originally posted by rppolicy@Jul 2 2004, 01:06 PM

does nios2 support the s part?

--- Quote End ---

I am asssuming you&#39;re asking if the legacy SDK supports Nios II/s ?? If so, the answer is yes.

Only the /f (with data cache) isn&#39;t officially supported with the legacy SDK mode. The issue of support revolves around calling pre-compiled C libraries from code under the legacy SDK; a volatile pointer can "lose" its volatility with certain C library calls, and since the legacy SDK meaning of "volatile" is "do not cache", it can lead to cache coherency problems.... in the HAL/IDE world, we volatile means "do not optimize" (which is really the true ANSI C meaning of the keyword).

In the legacy SDK, when you run nios2-build, we throw in a compiler switch "-mno-cache-volatile" which tells the compiler to treat &#39;volatile&#39; as it did in the Nios I SDK... so for this reason volatile pointers and structs will bypass the cache... until a C library is called that messes-up this declaration for something passed in!

Also, thank you for the feedback. Just so you know, I prefer the struct-method of accessing peripheral registers myself; I too think its much cleaner. The problem is that this struct-method relies on the above definition of volatile... sadly its hard to make everyone happy...

--- Quote Start ---

originally posted by jesse@Jul 2 2004, 11:43 AM

rppolicy,

...

next, i would like to make one thing clear: with nios ii, we wanted to deliver the sdk support just as it was for nios i -- this way you lose nothing!!

....

--- Quote End ---

Hi Jesse,

I am trying to port to NiosII using legacy support and I don&#39;t see how to download and run (n2r myprog.srec) through the JTAG port. AN 350 says you have to use the JTAG Uart but that it only works with Full Conversion.

Can you tell me/us how to get JTAG comm with Legacy Support?

Also, I&#39;m unable to connect using the debug console. It says the port is not open but when I openport lpt1 it says "incompatble p port". I&#39;m using a parallel port ByteBlasterII.

Any pointers? Anyone?

Thanks!

Ken

Kenland,

I&#39;ve a few quick responses. Hope they can help...

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

I am trying to port to NiosII using legacy support and I don&#39;t see how to download and run (n2r myprog.srec) through the JTAG port. AN 350 says you have to use the JTAG Uart but that it only works with Full Conversion.

Can you tell me/us how to get JTAG comm with Legacy Support?[/b]

--- Quote End ---

I believe the original Nios downloaded code using GERMS commands.... not sure what to tell you to do here. You could always write a "legacy" SDK driver, yourself http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif ....or use the new flow and the jtag_uart driver in the HAL.

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

Also, I&#39;m unable to connect using the debug console. It says the port is not open but when I openport lpt1 it says "incompatble p port". I&#39;m using a parallel port ByteBlasterII.

Any pointers? Anyone?[/b]

--- Quote End ---

Try using &#39;jtagconfig&#39;. I think you might find it more useful.http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif

Cheers,

- slacker

NiosI (and I&#39;m hoping Nios2 based on Jesse&#39;s comment that I quoted) operates completely over the JTAG port without germs. nr myprog.srec downloads and runs myprog over jtag without germs.

It would be nice if n2r mynios2prog.srec worked the same way.

Here is a partial workaround using the fs2 debug console. You need to read "Getting Started" under help menu in the console.

n2c

openport altlpt1 //openport sld will work but lower performance

load srec mynios2prog.srec

//Basic run commands

step

go

halt

// read all registers

regs

// open a window for stdio

stdio window

If you turn on HW Trace you can get not only HW trace but minimal source level debugging as well

but you have to run nios2-elf-fs2symbols mynios2prog. A bug that seems common to most N2 tools is you must have a .elf file extension but the sample makefile produces a .out file. No fear, you can just copy myprog.out myprog.elf. Another anoyance is the .elf has to be in the same dir as your .srec so if you&#39;re using the sample makefile cp obj/myprog.out ./myprog.elf before generating the fs2 symbol file. (this out/elf bug happens with n2d as well)

The downside to operating over the jtag using fs2 console is that the &#39;stdio window&#39; does not seem to function as it does with nios1 programs. (Altera? Anyone?)

Ken