NIOS 2 HAL, libraries, ...

[Vanheesbeke Stefaan]

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

 

[Joseph H Allen]

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%79-77?1:0<1659?79:0>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

 

[Jesse Kempa]

"Vanheesbeke Stefaan" <svhb@pandora.be> wrote in message news:<h9BIc.183520$Zg1.8783987@phobos.telenet-ops.be>...

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 ?

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.

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.

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.

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?

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.

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

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

Jesse Kempa
Altera Corp.
jkempa at altera dot com

 

[Richard Pennington]

Jesse Kempa wrote:
[big snip]

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

Jesse Kempa
Altera Corp.
jkempa at altera dot com

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