NIOS 2 HAL, libraries, ...

- V
- Vanheesbeke Stefaan
  
  Contact options for registered users
posted
19 years ago

Mon, Jul 12, 2004 6:56 PM

Hello,

I did a lot of work since the begining of NIOS(1) to put some libraries toghether with stuff that wasn't supported those days. Now with Nios2 it seems to be impossible to make your own library? Or do I miss something. I can generate syslibs and other things I dont'really need, but not an ordenary archive (that is of course linked in before the standard C (or is it newlib now)).

Is Altera planning to change over the whole system again for NIOS 3 ?

I tried also the 'legacy' way of doing it, but then the linker generates an error on cpp files (something with the destructors?), even with the simples example where I putted a class in.

Something else about interrupt latency, has anyone already found a way to reduce it further than 2 to 4 microseconds running from external SRAM and

50Mc? I think jumping to a single interrupt-service address is somewhere the most stupid thing to do? It's just a question, but is the battle for the smallest core between Xilinx and Altera so overwhelming, that a decent interrupt controller was not allowed in NIOS2?

For someones interest, if you are using the uart with NIOS2. Look at the signals and see that the promised 'fast printf' is sitting waiting till all characters are sent out. The nice thing about the bug is that the printf is OK, but all possible cycles are eaten up by the interrupt service routine that is not doing the correct things. To correct, change : copy altera_avalon_uart.c to your project dir, change TMT (line 613) to TRDY and recompile. Hope this can be a usefull help for someone.

Stefaan

- J
- Joseph H Allen
  
  Contact options for registered users
Vote on answer
posted
19 years ago

Mon, Jul 12, 2004 9:48 PM

I just started playing with NIOS and NIOS-II: It's interesting because I got a taste of both worlds. I think they have made a mistake with the NIOS-II IDE- they should have stayed with Cygwin for the SDK. I liked the NIOS-I "Germs" bootloader, even if it wastes a RAM on the chip. I don't like the undocumented JTAG console port- who is going to design this into their product? It requires the IDE to use, whereas the old school console serial port can be used with any terminal program.

At the very least, they should document the JTAG side of the console ports.

A minor point is that with NIOS-I, you can get going with the printed quick-start guide, whereas with NIOS-II you have to run the tutorial.

--
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

- J
- Jesse Kempa
  
  Contact options for registered users
Vote on answer
posted
19 years ago

Tue, Jul 13, 2004 12:33 AM

Hopefully not - we wanted to provide a SW environment suitable for people to port more code into working with Nios. In the Nios I days our SDK, while quick/easy/efficient, was rather processor & peripheral-specific and a lot of software engineers were after the environment you see with HAL & Nios II.

The intention of the legacy SDK mode was to support existing customers' SW flows who just wanted to replace processor cores -- if this is a big problem feel free to email me and we can discuss the destructor problem.

Allow me to explain how it works - hopefully that is useful to you:

As with any processor there are two components to ISR latency: Hardware (IRQ assertion to exception SW start) Software (what you do to call your ISR)

The "interrupt controller", in the traditional sense, isn't some big scary slow thing. Nios II operates by finishing execution of whatever is in the pipeline before launching off to service an interrupt. Most of the time this is speedy *but*, if you're doing things like repeated loads/stores from/to a slow external memory, latency can go up as those instructions need to finish. This in itself isn't different from Nios I. What is different from Nios I is that no longer have the windowed register file (something that was discussed at length earlier in this group), which has reduced the worst-case latency substantially (although for the vast majority of ISRs in Nios I, you didn't go to a new set of registers, something competitive marketing organizations would tend to skew a bit!).

Next, software: so you respond to IRQ going high - you have a situation where registers need to be pushed to the stack, figure out if you have a HW or SW exception, etc. We provide a default, Altera-supported ISR funnel for your convenience, but there is no rule that says you have to use it. The code is located in the altera_nios2 component folder of your installation (nios_isr_handler.c/.s for the legacy SDK; alt_exception.S for the HAL) contain the documented source. If your application is very specialized and you only want to do the quickest possible jump upon exception handler entry, this is the place to do it. It may be advisable to place the exception handling code itself into a low-latency memory (SRAM, or preferably, on-chip), to further reduce latency.

I will definitely take a look at this - thank you for pointing it out.

Jesse Kempa Altera Corp. jkempa at altera dot com

- R
- Richard Pennington
  
  Contact options for registered users
Vote on answer
posted
19 years ago

Tue, Jul 13, 2004 1:44 AM

Jesse Kempa wrote: [big snip]

Jesse,

It is great to see you (and Altera) on the newsgroup. At my place of employment, (my alter ego is richard dot pennington at med dot ge dot com) we use a lot of Altera parts (and Nios). Great stuff.

-Rich

--
Richard Pennington
Email: rich@pennware.com
http://www.pennware.com ftp://ftp.pennware.com