FPGARelated.com
Forums

Nios II Going Live...

Started by Kenneth Land May 19, 2004
"Austin Lesea" wrote

> At lunch the other day we were reminiscing about how the Z8000 never > took off because they changed their architecture and instruction set > completely from the Z80 and immediately alienated all of their customers > (who were still programming in assembly language in those days).
Not quite getting it into production may have troubled some customers...
> Not like that anymore.
The Spartan-3 of its day ;-)
Why do you think it's wierd? I found the fast ISR entrance quite
useful. I hope ISR entrance is as fast in Nios II. I heard it the
windowing was thrown out because of patent issues, not on its
technical merits.

-- Pete

> > The weird register window mechanism from NIOS (is it called NIOS1 now?) > didn't work well in embedded processing markets. > > G�ran Bilski > > > Kenneth Land wrote: > > >Tomorrow is the big Nios II launch date, but info is already going up.... > > > >www.altera.com > > > >http://www.fpgajournal.com/articles/20040518_nios2.htm > > > > > >Full 32bit. 2X-4X faster than Nios I and starts at only 500 LE's. New IDE. > >New Compact Flash and other periferals.... Can't wait to get a hold of it. > > > >Ken > > > > > > > >
It's creating weird situation in embedding processing where you reach 
the limit of the window.
There should only be different 3 numbers used as sizes, 0, 1 or infinity.
Any other number will creating barriers that will be reach and have 
impacts on the system.
On reaching the limit of the register window, you have a big chunk of 
data to save and load which isn't nice to have when you need to have a 
deterministic system.

G�ran

Peter Sommerfeld wrote:

>Why do you think it's wierd? I found the fast ISR entrance quite >useful. I hope ISR entrance is as fast in Nios II. I heard it the >windowing was thrown out because of patent issues, not on its >technical merits. > >-- Pete > > > >>The weird register window mechanism from NIOS (is it called NIOS1 now?) >>didn't work well in embedded processing markets. >> >>G�ran Bilski >> >> >>Kenneth Land wrote: >> >> >> >>>Tomorrow is the big Nios II launch date, but info is already going up.... >>> >>>www.altera.com >>> >>>http://www.fpgajournal.com/articles/20040518_nios2.htm >>> >>> >>>Full 32bit. 2X-4X faster than Nios I and starts at only 500 LE's. New IDE. >>>New Compact Flash and other periferals.... Can't wait to get a hold of it. >>> >>>Ken >>> >>> >>> >>> >>> >>>
"Goran Bilski" <goran@xilinx.com> wrote in message
news:c8gaoj$cfb1@cliff.xsj.xilinx.com...
> It's creating weird situation in embedding processing where you reach > the limit of the window. > There should only be different 3 numbers used as sizes, 0, 1 or infinity. > Any other number will creating barriers that will be reach and have > impacts on the system. > On reaching the limit of the register window, you have a big chunk of > data to save and load which isn't nice to have when you need to have a > deterministic system. > > G&#4294967295;ran >
Can you explain a bit more? If you need more than 31 levels of call stack, how deterministic could your application be? I know there is merit to what you say, as that's why NiosI has the mflat model available. I'd just like to have it explained. Ken
Goran Bilski wrote:
> > There should only be different 3 numbers used as sizes, > 0, 1 or infinity. Any other number will creating barriers > that will be reach and have impacts on the system.
I'm headed over to payroll right now! Eric
In article <40ABC160.8B7D3197@xilinx.com>,
Eric Crabill  <eric.crabill@xilinx.com> wrote:
>Goran Bilski wrote: >> There should only be different 3 numbers used as sizes, >> 0, 1 or infinity. Any other number will creating barriers >> that will be reach and have impacts on the system. > >I'm headed over to payroll right now!
Sorry, Cisco has decided to switch back to 100% ASIC, your payroll is now set to size 0. :) -- Nicholas C. Weaver nweaver@cs.berkeley.edu
Jon Beniston wrote:
<snip>
> > Fair play to them, I didn't really think too much of NIOS, but if they > really can push 200MHz with this, then I am impressed.
I think I spotted the words 'simulated' close to that number... :) ie the standard 'release it today, but talk about how fast it will be next year....' -jg
Eric Crabill wrote:

> Goran Bilski wrote: > >>There should only be different 3 numbers used as sizes, >>0, 1 or infinity. Any other number will creating barriers >>that will be reach and have impacts on the system. > > > I'm headed over to payroll right now!
No, No, stooop ! They'll choose the ONE in the middle!! :)
Goran Bilski wrote:

> It's creating weird situation in embedding processing where you reach > the limit of the window. > There should only be different 3 numbers used as sizes, 0, 1 or infinity. > Any other number will creating barriers that will be reach and have > impacts on the system. > On reaching the limit of the register window, you have a big chunk of > data to save and load which isn't nice to have when you need to have a > deterministic system.
I'm lost - since the register count is finite at around 32 in most RISC designs, how does removing a feature improve the situation ?. I don't know the specific NIOS details, but Register window/Frame Pointer/Register Bank select schemes have been around for years, and can greatly help code density and reaction speed if done properly. I think sparc had a clever partial frame pointer, that allowed some registers to carry calling/return parameters, and some as local variables. The compiler needs 'to be on its toes', but that's a SW housekeeping issue. Another nice feature of register frame pointers, is if you are uncomfortable with them, you can just ignore it, and you have a 'vanilla RISC' core. -jg
Tim,

Low blow.

S3 shipped a lot of parts last quarter.  A whole lot of parts.

No one expected the product to gather that many orders that fast.  Even 
the optomists among us were made to look like pessimistic fools.

If we would have only believed our own sales pitch that S3 was a better 
deal than an ASIC in volume (which it is), we might have been at least 
partially prepared.

Austin

Tim wrote:
> "Austin Lesea" wrote > > >>At lunch the other day we were reminiscing about how the Z8000 never >>took off because they changed their architecture and instruction set >>completely from the Z80 and immediately alienated all of their customers >>(who were still programming in assembly language in those days). > > > Not quite getting it into production may have troubled some customers... > > >>Not like that anymore. > > > The Spartan-3 of its day ;-) > >