Lattice vs Altera (Mico32 / NIOS)....or?

There are cheap evaluation kits with NIOS II integrated available, so maybe you should try it yourself. I've used it for a commercial product with a Cyclone, but I wouldn't do it again. It is possible and there are some nice IPs, but the price of a FPGA with all the IPs you'll need for a good system (CPU core, SDRAM/network/UART etc.) is higher than buying it in a hardwired microcontroller, like one of this ones, if you don't need already big parts of the FPGA for FPGA related things, and the NIOS II would be just a small offset to the whole system.

(the LPC series is nice)

And using NIOS II is sometimes tricky (see

for some interesting forum posts). Things which are easy with hardwired microcontrollers sometimes gets difficult with NIOS. There were even CPU core bugs in older versions of NIOS and the development environment is bloated and slow. The SoPC builder is powerful, but it is complicated to configure the system (sometimes you have to configure some special attributes of a component and failing to do so results in strange compiling errors), the right busses, arbitraters etc. and route it to a working system.

In theory I like the idea of using just one FPGA to build your whole system, but I think a micorcontroller is better: No costs for additional IPs, DSP functions in the bigger ones included, all hardware you'll need included in tested hardwired blocks, if you choose the right one and free tools like GCC for fast ARM CPUs etc. makes live much easier. Use an additional FPGA for the parts which needs a FPGA, e.g. routing many fast signals, additional DSP functions etc. and attach it to the microcontroller with a memory mapped interface for more complex systems, or a simpler interface.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Did I mention that the professional version of the Altera software license expires after one year and you have to renew it every year (for $2,495), if you want to do bugfixes later in your designs? Last time I used it, you couldn't use NIOS with the free web edition. Compare this to a ARM-GCC-Eclipse toolchain or the free Symphony Studio IDE for the nice Freescale DSPs.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

I think I'm with Frank on this one - unless there is a compelling reason to use an FPGA based micro I think you have a much easier development route with a stand alone device. With a typical ARM based processor or micro-controller you get completely sorted and integrated IP for the core, memory, on chip flash, serial IO, etc etc AND a choice of development tools and decent hardware supported debugging tools. You need to factor in a massive increase in development cost if you go the all FPGA route - there will be the odd occasion when this pays off but with the cost of a decent stand alone processor at

Hi MMJ,

What specifically isn't working? Did you contact Lattice about it?

What problems and bugs do you have? Are they with the IDE, the GNU tools or are you talking about the FPGA tools?

Ditto.

If you say what the specific bugs are, maybe I can offer some help or advice.

MicroBlaze and NIOS II have been around for longer and no doubt have a larger user base, but they are not without their own problems. Don't forget that much of the toolchain is pretty much the same s/w.

It's a mixture. The IDE & toolchain are obviously based on other open source projects (Eclipse / GCC / binutils / GDB), but the Mico32 architecture was designed & implemented by Lattice.

Cheers, Jon

One of the main problems are the poor performance of the debug interface in the Mico32. A download speed of 20-30 kbit/sec is just to slow when developing large applications. Is there any way to speed up this interface?

Offcourse! But you mention a big reasson to try out Altera....the large user base. Lattice have < 100 topics in their forum compared to >8k in Alteras. The large user may help you to find/fight some of the problems.

Regards

-- MMJ

Maybe there are less topics because there are less problems :-)

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

External flash for code is needed yes - but is also used on most silicon MCU/MPUs. Config memeory for the FPGA will be selected to support a fully configured FPGA. Regarding EMC and PCB we acutally keep allot of signals within the FPGA by embedding the CPU, which eases routing and maybe decreasses layers.

Correct....if the job can be done at the right price by an internal flash MCU.

No the size of the CPU in the FPGA is very few percent relative to the custom hardware that needs to be implemented.

Above 10Mbit on a buffered DMA interface. Internally in the FPGA I guess this can be done by DMA from FPGA RAM to DDR ram of the CPU. Complette control of interrupt loading etc.

-- MMJ

MMJ pisze:

If you have enough space inside configuration flash you can use it for both - for FPGA image and for softprocessor code.

I'm doing this way.

Adam

Adam Górski pisze:

If you have external SDR SDRAM or DDR SDRAM of course or big enough internal ram

Adam

Are you developing on Lattice's ECP2 board or your own custom board?

Cheers, Jon