Survey on Quartus SOPC/Nios-II

I am evaluating using the Altera Cyclone with Quartus SOPC vs. Xilinx
Spartan3E and PicoBlaze.  I need a soft core processor and I think PicoBlaze
would be enough.  SOPC and Nios-II is very powerful but the learning curve
looks like a potential nightmare to me.  In order to use SOPC I might have
to get involved writing custom components to do the job and then one has to
master the Avalon interface.  That looks like a lot of potential debugging
time.

The Xilinx solution seems more direct, and under my control, since PicoBlaze
is stand alone and does not depend on so many bus interrelated components
and SOPC infrastructure.  Easier and quicker to write direct interfaces.
Nios seems to need much more of the SOPC (RAM,ROM,Avalon,etc) around it to
work.

Also, it seems like the Nios/SOPC solution is likely to require far more
gates than a Xilinx/PicoBlaze implementation.

I would be curious to know any of your experiences with SOPC/Nios-II.  I
have very limited R&D time for this project.

Thanks,  Chris.

Chris wrote:

> I would be curious to know any of your experiences with SOPC/Nios-II.  I
> have very limited R&D time for this project.

I guess it depends on *what* you want to interface to the NIOS.

Avalon is compatible with Wishbone, so if you're going to be interfacing
wishbone components then it's a no-brainer. Otherwise, it's no more
difficult than writing wishbone wrappers for your non-wishbone component.

Of course some components already exist, such as an SDRAM controller for
example. You also get I/O blocks such as registers and GPIO that can
have associated NIOS interrupts, UARTS, etc.

Putting it all together is quite straight-forward in the SOPC interface.
You get a visual representation of the bus interconnects and can massage
the memory map as you see fit. Arbitration for multiple bus-masters is
automagically taken care of. You also get to choose the size/complexity
of the NIOS itself - IIRC the smallest is 600-700 LEs?!?

Once you've decided on your architecture, you 'generate' the system
which produces a mass of HDL files in your main project directory. Then
instantiate the top level in your Quartus design and you're good to go.

The software is written from within the NIOS-II IDE. You simply build a
'system library' for your design and then start on your application.
Personally I hate Eclipse with a passion so I do all my editing outside
the IDE, and use it solely for the big red 'RUN' button.

uCOS is also an option, or you can go bare-bones with the HAL library.
You get drivers for all system components and isr hooks etc. If you
actually already know what you're looking for, you can usually find it
in the doco! ;)

There's also nice things like a JTAG UART which allows you to spit debug
messages directly to the IDE console. During development you can target
your CODE sections to (SD)RAM and download/run everything via JTAG so
there's no need for ROM emulators etc. I haven't used the debugger
extensively, but it kinda works.

Overall, it's relatively "painless" once you get the hang of things.
That certainly can't be said for a lot of embedded systems, let-alone
soft-cores running in FPGAs....

I can't comment on Xilinx/PicoBlaze...

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

I think it depends on what you want...

The Picoblaze is a very small 8-bit microcontroller while the NIOS is a
32-bit general purpose CPU (by most accounts).  Both Altera and Xilinx
provide an easy way to build a base-system using any of their
processors (NIOS and/or Microblaze) however there is no base system
builder for Picoblazes, so getting output from the processor into the
real-world may be harder (unless you like looking at LEDs, and trying
to hook up a UART to a picoblaze).

Additionally, NIOS and Microblaze come with quite a few software
libraries that you can use to your advantage.  What exactly are you
planning on doing with your system?  Do you really need an FPGA or
could you just buy a gumstix?  The reason I ask is that the toolsets
from both Xilinx and Altera have a learning curve, and it may be easier
to bypass the need to build a base system, synthesize, place-and-route,
etc. etc.

-Jason
University of Kansas.


Mark McDougall wrote:
> Chris wrote:
>
> > I would be curious to know any of your experiences with SOPC/Nios-II.  I
> > have very limited R&D time for this project.
>
> I guess it depends on *what* you want to interface to the NIOS.
>
> Avalon is compatible with Wishbone, so if you're going to be interfacing
> wishbone components then it's a no-brainer. Otherwise, it's no more
> difficult than writing wishbone wrappers for your non-wishbone component.
>
> Of course some components already exist, such as an SDRAM controller for
> example. You also get I/O blocks such as registers and GPIO that can
> have associated NIOS interrupts, UARTS, etc.
>
> Putting it all together is quite straight-forward in the SOPC interface.
> You get a visual representation of the bus interconnects and can massage
> the memory map as you see fit. Arbitration for multiple bus-masters is
> automagically taken care of. You also get to choose the size/complexity
> of the NIOS itself - IIRC the smallest is 600-700 LEs?!?
>
> Once you've decided on your architecture, you 'generate' the system
> which produces a mass of HDL files in your main project directory. Then
> instantiate the top level in your Quartus design and you're good to go.
>
> The software is written from within the NIOS-II IDE. You simply build a
> 'system library' for your design and then start on your application.
> Personally I hate Eclipse with a passion so I do all my editing outside
> the IDE, and use it solely for the big red 'RUN' button.
>
> uCOS is also an option, or you can go bare-bones with the HAL library.
> You get drivers for all system components and isr hooks etc. If you
> actually already know what you're looking for, you can usually find it
> in the doco! ;)
>
> There's also nice things like a JTAG UART which allows you to spit debug
> messages directly to the IDE console. During development you can target
> your CODE sections to (SD)RAM and download/run everything via JTAG so
> there's no need for ROM emulators etc. I haven't used the debugger
> extensively, but it kinda works.
>
> Overall, it's relatively "painless" once you get the hang of things.
> That certainly can't be said for a lot of embedded systems, let-alone
> soft-cores running in FPGAs....
>
> I can't comment on Xilinx/PicoBlaze...
>
> Regards,
>
> --
> Mark McDougall, Engineer
> Virtual Logic Pty Ltd, <http://www.vl.com.au>
> 21-25 King St, Rockdale, 2216
> Ph: +612-9599-3255 Fax: +612-9599-3266

I've written Verilog for over 10 years and the design for the logic portion
is already done.  However this is the first time using a soft core CPU.
Basically this is a backplane bus interface.  Address decode and 32 bit
porting.  But I need RAM for a fast buffer and also a little CPU for
converting serial I2C DACs and ADCs into parallel data.  So a little
embedded CPU with I2C core would probably do it.  Perhaps SPI so I can
update calibration constants in config Flash.

PicoBlaze seems very easy to hook your own logic to.  Nios seems much more
involved since you have to go through the SOPC arch.  It also appears the
size of the gates will be 2X higher using Nios than PicoBlaze.  The chip
size could be twice the price.

Chris.





"Jason Agron" <jagron@gmail.com> wrote in message
news:1161684703.158078.90950@f16g2000cwb.googlegroups.com...
> I think it depends on what you want...
>
> The Picoblaze is a very small 8-bit microcontroller while the NIOS is a
> 32-bit general purpose CPU (by most accounts).  Both Altera and Xilinx
> provide an easy way to build a base-system using any of their
> processors (NIOS and/or Microblaze) however there is no base system
> builder for Picoblazes, so getting output from the processor into the
> real-world may be harder (unless you like looking at LEDs, and trying
> to hook up a UART to a picoblaze).
>
> Additionally, NIOS and Microblaze come with quite a few software
> libraries that you can use to your advantage.  What exactly are you
> planning on doing with your system?  Do you really need an FPGA or
> could you just buy a gumstix?  The reason I ask is that the toolsets
> from both Xilinx and Altera have a learning curve, and it may be easier
> to bypass the need to build a base system, synthesize, place-and-route,
> etc. etc.
>
> -Jason
> University of Kansas.
>
>
> Mark McDougall wrote:
> > Chris wrote:
> >
> > > I would be curious to know any of your experiences with SOPC/Nios-II.
I
> > > have very limited R&D time for this project.
> >
> > I guess it depends on *what* you want to interface to the NIOS.
> >
> > Avalon is compatible with Wishbone, so if you're going to be interfacing
> > wishbone components then it's a no-brainer. Otherwise, it's no more
> > difficult than writing wishbone wrappers for your non-wishbone
component.
> >
> > Of course some components already exist, such as an SDRAM controller for
> > example. You also get I/O blocks such as registers and GPIO that can
> > have associated NIOS interrupts, UARTS, etc.
> >
> > Putting it all together is quite straight-forward in the SOPC interface.
> > You get a visual representation of the bus interconnects and can massage
> > the memory map as you see fit. Arbitration for multiple bus-masters is
> > automagically taken care of. You also get to choose the size/complexity
> > of the NIOS itself - IIRC the smallest is 600-700 LEs?!?
> >
> > Once you've decided on your architecture, you 'generate' the system
> > which produces a mass of HDL files in your main project directory. Then
> > instantiate the top level in your Quartus design and you're good to go.
> >
> > The software is written from within the NIOS-II IDE. You simply build a
> > 'system library' for your design and then start on your application.
> > Personally I hate Eclipse with a passion so I do all my editing outside
> > the IDE, and use it solely for the big red 'RUN' button.
> >
> > uCOS is also an option, or you can go bare-bones with the HAL library.
> > You get drivers for all system components and isr hooks etc. If you
> > actually already know what you're looking for, you can usually find it
> > in the doco! ;)
> >
> > There's also nice things like a JTAG UART which allows you to spit debug
> > messages directly to the IDE console. During development you can target
> > your CODE sections to (SD)RAM and download/run everything via JTAG so
> > there's no need for ROM emulators etc. I haven't used the debugger
> > extensively, but it kinda works.
> >
> > Overall, it's relatively "painless" once you get the hang of things.
> > That certainly can't be said for a lot of embedded systems, let-alone
> > soft-cores running in FPGAs....
> >
> > I can't comment on Xilinx/PicoBlaze...
> >
> > Regards,
> >
> > --
> > Mark McDougall, Engineer
> > Virtual Logic Pty Ltd, <http://www.vl.com.au>
> > 21-25 King St, Rockdale, 2216
> > Ph: +612-9599-3255 Fax: +612-9599-3266
>

Chris schrieb:

> I've written Verilog for over 10 years and the design for the logic portion
> is already done.  However this is the first time using a soft core CPU.
> Basically this is a backplane bus interface.  Address decode and 32 bit
> porting.  But I need RAM for a fast buffer and also a little CPU for
> converting serial I2C DACs and ADCs into parallel data.  So a little
> embedded CPU with I2C core would probably do it.  Perhaps SPI so I can
> update calibration constants in config Flash.
>
> PicoBlaze seems very easy to hook your own logic to.  Nios seems much more
> involved since you have to go through the SOPC arch.  It also appears the
> size of the gates will be 2X higher using Nios than PicoBlaze.  The chip
> size could be twice the price.
>
> Chris.

if you only need i2c and spi, then any small cpu would do, and there is
no
need for the i2c or spi to be present in hardware, software bitbang is
almost
always as efficient

Antti

"Chris" <nospam@nospam.com> wrote:

>I am evaluating using the Altera Cyclone with Quartus SOPC vs. Xilinx
>Spartan3E and PicoBlaze.  I need a soft core processor and I think PicoBlaze
>would be enough.  SOPC and Nios-II is very powerful but the learning curve
>looks like a potential nightmare to me.  In order to use SOPC I might have
>to get involved writing custom components to do the job and then one has to
>master the Avalon interface.  That looks like a lot of potential debugging
>time.
>
>The Xilinx solution seems more direct, and under my control, since PicoBlaze
>is stand alone and does not depend on so many bus interrelated components
>and SOPC infrastructure.  Easier and quicker to write direct interfaces.
>Nios seems to need much more of the SOPC (RAM,ROM,Avalon,etc) around it to
>work.
>
>Also, it seems like the Nios/SOPC solution is likely to require far more
>gates than a Xilinx/PicoBlaze implementation.
>
>I would be curious to know any of your experiences with SOPC/Nios-II.  I
>have very limited R&D time for this project.

If time is limited, go for the Picoblaze. Even though it needs to be
programmed in assembly. The assembly language it uses is very
straightforward and easy to learn.

Be aware though that the design around a Picoblaze may not meet timing
when a lot of datasources are connected to it and / or the Picoblaze
is running at high clock speeds. You may need one or more extra
registers to split paths (this is explained in the Picoblaze
documentation).

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Hi Chris,

you can also take a look at our ERIC5. It is more powerful than Picoblaze 
(esp. size of code-space) at about the same resource-usage. And it is 
vendor-indepent, so  you do not have to base your FPGA-decision on the 
processer-choice. For larger projects (with sufficient code-ROM) there is 
also a C-compiler available. If you want something for free, maybe also 
Lattice Mico8 can do the job.

Regards,

Thomas

www.entner-electronics.com

"Chris" <nospam@nospam.com> schrieb im Newsbeitrag 
news:ysmdnTmSee0P56DYnZ2dnUVZ_vOdnZ2d@comcast.com...
>I am evaluating using the Altera Cyclone with Quartus SOPC vs. Xilinx
> Spartan3E and PicoBlaze.  I need a soft core processor and I think 
> PicoBlaze
> would be enough.  SOPC and Nios-II is very powerful but the learning curve
> looks like a potential nightmare to me.  In order to use SOPC I might have
> to get involved writing custom components to do the job and then one has 
> to
> master the Avalon interface.  That looks like a lot of potential debugging
> time.
>
> The Xilinx solution seems more direct, and under my control, since 
> PicoBlaze
> is stand alone and does not depend on so many bus interrelated components
> and SOPC infrastructure.  Easier and quicker to write direct interfaces.
> Nios seems to need much more of the SOPC (RAM,ROM,Avalon,etc) around it to
> work.
>
> Also, it seems like the Nios/SOPC solution is likely to require far more
> gates than a Xilinx/PicoBlaze implementation.
>
> I would be curious to know any of your experiences with SOPC/Nios-II.  I
> have very limited R&D time for this project.
>
> Thanks,  Chris.
>
> 

Thomas Entner wrote:

>  If you want something for free, maybe also
> Lattice Mico8 can do the job.

fyi, the LatticeMico8 is free and open source:
http://www.latticesemi.com/products/intellectualproperty/referencedesigns/8bitmicrocontrollermico8.cfm

if you'd like a free and open source 32-bit soft processor, you might
check out the LatticeMico32:
http://www.latticesemi.com/products/intellectualproperty/ipcores/mico32/index.cfm

Bart Borosky, Lattice

If you go for Picoblaze,don't forgot do try the C compiler on
www.poderico.co.uk
and if you like, then send me an email I will send you the newer
version of the compiler and few more library (for example the LCD.h
library)

Regards,
Francesco

Chris wrote:
> I am evaluating using the Altera Cyclone with Quartus SOPC vs. Xilinx
> Spartan3E and PicoBlaze.  I need a soft core processor and I think PicoBlaze
> would be enough.  SOPC and Nios-II is very powerful but the learning curve
> looks like a potential nightmare to me.  In order to use SOPC I might have
> to get involved writing custom components to do the job and then one has to
> master the Avalon interface.  That looks like a lot of potential debugging
> time.
>
> The Xilinx solution seems more direct, and under my control, since PicoBlaze
> is stand alone and does not depend on so many bus interrelated components
> and SOPC infrastructure.  Easier and quicker to write direct interfaces.
> Nios seems to need much more of the SOPC (RAM,ROM,Avalon,etc) around it to
> work.
>
> Also, it seems like the Nios/SOPC solution is likely to require far more
> gates than a Xilinx/PicoBlaze implementation.
>
> I would be curious to know any of your experiences with SOPC/Nios-II.  I
> have very limited R&D time for this project.
> 
> Thanks,  Chris.

Glad I posted the question.  You guys are great.  So much info.

I think the 8 bit micro is the right approach level:  PicoBlaze, Micro8.
There is another PacoBlaze that looks interesting.  Probably others too.
Waiting for info on ERIC5.

The LatticeXP approach is attractive from a couple standpoints.  Being NV
and single supply, if I can use the config clock in user mode, and keep some
of my own extra data in the internal flash, than it becomes possible to do
the whole implementation with a single part.  No regulators, no external
flash, no xtal/osc.  Great for PCB routing and space.  Very slick and clean.
One single part.  Might be able to use a double sided board.

Need to talk to Lattice about a couple points there.  I think I can keep the
config osc running by setting the PERSISTENT flag ON, but not sure about
flash usage.   Otherwise Xilinx 3E-100 is probably best choice.

Thanks guys!

Chris.