Hi everybody, First off all...sorry for cross posting this to both arch.fpga and arch.embedded, but I think it fits in both places. I'm currently in the selection fase of an FPGA vendor. we need a >2M gate chip with DSP capabilities, SERDES and offcourse the mandatory low cost. Likewise we need a high performance embedded CPU softcore for system management. At the moment things are pointing towards lattice because of price, availability and HW specs. As i'm involved in the SW part of the design me and my team has been trying to evaluate the tool chain (ispLEVER + Eclipse Mico32 environment) and the evaluation board bassed on a Lattice ECP2 FPGA. But we're not quite happy about it. We have spend allot of time to get a very simple CPU system (CPU + intern memory) running on the FPGA. We have done progress but this is very slow and we seem to keep banging our heads against the wall when we try expand the system. My conclusions on the Lattice tool chain and the Mico32 system based on the evaluation is as follows: * Bad documentation on both tools and eval boards. Some stuff will never work if you don't reverse engineer HW or get correct support. * Outdated tutorials regarding to tool and HW revisions. * Poorly integrated and bugy tools. * Extremely slow JTAG connection to the CPU (19kbit/sec) for SW debugging/downloading. * Hard to trouple shot the CPU configuration (e.g. SW debugger cannot connect to the CPU). * Tools crashes * Overall poorly matured product (Mico32 and tools). So my questions are: * Is it only me that have come to this conclusion? Are some of you using lattice and Mico32 with success in a commercial product? * Any ways (known fixes to issues, third party stuff etc.) to get faster to market with the Lattice solution? * Is the stuff (NIOS II and tools) from Altera (or any other vendor) any better regarding the complaints above? * The Mico32 is open source but is the origin of the code made by Lattice themselves or? * Any recommendations or experiences to share? Hope to see some comments on my conclusions and questions. Thank you! Best Regards -- MMJ PS: All in this message is my personal opinions - and may not be the ones of my employer.
Lattice vs Altera (Mico32 / NIOS)....or?
Started by ●October 9, 2008
Reply by ●October 9, 20082008-10-09
FreeWheel wrote:> * Is the stuff (NIOS II and tools) from Altera (or any other vendor) > any better regarding the complaints above?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. http://www.st.com/inchtml-pages-stm32.html http://www.standardics.nxp.com/microcontrollers/ (the LPC series is nice) http://www.atmel.com/products/at91/ And using NIOS II is sometimes tricky (see http://forum.niosforum.com/forum/index.php?showforum=2 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
Reply by ●October 9, 20082008-10-09
Frank Buss wrote:> and free > tools like GCC for fast ARM CPUs etc. makes live much easier.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
Reply by ●October 10, 20082008-10-10
On Oct 10, 12:11=A0am, FreeWheel <grinder...@gmail.com> wrote:> Hi everybody, > > First off all...sorry for cross posting this to both arch.fpga and > arch.embedded, but I think it fits in both places. > > I'm currently in the selection fase of an FPGA vendor. we need a >2M > gate chip with DSP capabilities, SERDES and offcourse the mandatory > low cost. Likewise we need a high performance embedded CPU softcore > for system management. At the moment things are pointing towards > lattice because of price, availability and HW specs. As i'm involved > in the SW part of the design me and my team has been trying to > evaluate the tool chain (ispLEVER + Eclipse Mico32 environment) and > the evaluation board bassed on a Lattice ECP2 FPGA. But we're not > quite happy about it. We have spend allot of time to get a very simple > CPU system (CPU + intern memory) running on the FPGA. We have done > progress but this is very slow and we seem to keep banging our heads > against the wall when we try expand the system. My conclusions on the > Lattice tool chain and the Mico32 system based on the evaluation is as > follows: > > * Bad documentation on both tools and eval boards. Some stuff will > never work if you don't reverse engineer HW or get correct support. > * Outdated tutorials regarding to tool and HW revisions. > * Poorly integrated and bugy tools. > * Extremely slow JTAG connection to the CPU (19kbit/sec) for SW > debugging/downloading. > * Hard to trouple shot the CPU configuration (e.g. SW debugger cannot > connect to the CPU). > * Tools crashes > * Overall poorly matured product (Mico32 and tools). > > So my questions are: > > * Is it only me that have come to this conclusion? Are some of you > using lattice and Mico32 with success in a commercial product? > * Any ways (known fixes to issues, third party stuff etc.) to get > faster to market with the Lattice solution? > * Is the stuff (NIOS II and tools) from Altera (or any other vendor) > any better regarding the complaints above? > * The Mico32 is open source but is the origin of the code made by > Lattice themselves or? > * Any recommendations or experiences to share? > > Hope to see some comments on my conclusions and questions. > > Thank you! > > Best Regards > -- > MMJ > > PS: All in this message is my personal opinions - and may not be the > ones of my employer.I dont have much of experience with Lattice, but I have used Altera NIOS and Xilinx MicroBlaze. And in general I have also found the tool flow to be very complicated, It takes lot of time to get basic things work, until the time you get used to the tool and also to the tool documentation and the version incompatibilities. I for example had a tough time getting flash up with Microblaze, which should have been a simple task. But then the good thing about this configurable processors is that once you put all the effort and get things up, you really get a powerful reconfigurable system. You could change the system to have one more serial port, or add extra I2C Controller and so on. I have come across number of people who are using Microblaze as their control processor for their product. Cheers. Goli
Reply by ●October 10, 20082008-10-10
"Frank Buss" <fb@frank-buss.de> wrote in message news:bk5rk2omzbbs$.6ltaeouy3nwp.dlg@40tude.net...> FreeWheel wrote: > >> * Is the stuff (NIOS II and tools) from Altera (or any other vendor) >> any better regarding the complaints above? > > 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. > > http://www.st.com/inchtml-pages-stm32.html > http://www.standardics.nxp.com/microcontrollers/ (the LPC series is nice) > http://www.atmel.com/products/at91/ > > And using NIOS II is sometimes tricky (see > http://forum.niosforum.com/forum/index.php?showforum=2 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.deI 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 << $10 you will need to be building huge numbers of systems. For me (typical build numbers for FPGA based designs <50) it has never looked a good route. Michael Kellett
Reply by ●October 10, 20082008-10-10
[CUT: my own post] Hey Frank, MK and goli. Well resson to why we aim for the embedded softcore is that we have allot of custom hardware already within the FPGA. Some of this hardware output ALLOT of data which is "easy" to interface to an embedded softcore becuase of the high bandwidth internaly in the FPGA. Interfacing to an external CPU is quite harder (in terms of bandwidth on a standard low cost MCU) and offcourse also give the BOM add. Regards. MMJ
Reply by ●October 10, 20082008-10-10
FreeWheel wrote:> Hi everybody, > > First off all...sorry for cross posting this to both arch.fpga and > arch.embedded, but I think it fits in both places. > > I'm currently in the selection fase of an FPGA vendor. we need a >2M > gate chip with DSP capabilities, SERDES and offcourse the mandatory > low cost. Likewise we need a high performance embedded CPU softcore > for system management.Why does this need to be on the FPGA ? SoftCPUs still need external memory, so are a 2-3 chip solution. Why not use a 32 bit microcontroller, with on chip FLASH ? (it may allow smaller FPGA, or smaller Loader/RAM resource) Some examples: * Infineon have 32bit uC models with Error Correcting FLASH * NXP claims : "At 125 MHz, the NXP LPC2900 series are the fastest ARM968 microcontrollers available on the market," * Atmel's claim 200MHz peak core for their AT91SAM9XE128 with a ARM926EJ-S core ( 15ns memory bandwidth @ 32 bits) * NXP have 100MHz cM3-R2 devices and you get SSI/SPI/ADC/DAC/Timers/RTC/WDOG/Low power, and in some cases USB/CAN/Ethernet> My conclusions on the > Lattice tool chain and the Mico32 system based on the evaluation is as > follows:In the timeline of such things, the Lattice solution is relatively new, so it is expected to have more wrinkles than a more mature system. Have you asked Lattice for a reference design closest to what you are trying to do ? -jg
Reply by ●October 10, 20082008-10-10
Hi MMJ,> * Some stuff will > never work if you don't reverse engineer HW or get correct support.What specifically isn't working? Did you contact Lattice about it?> * Poorly integrated and bugy tools.What problems and bugs do you have? Are they with the IDE, the GNU tools or are you talking about the FPGA tools?> * Tools crashesDitto.> * Any ways (known fixes to issues, third party stuff etc.) to get > faster to market with the Lattice solution?If you say what the specific bugs are, maybe I can offer some help or advice.> * Is the stuff (NIOS II and tools) from Altera (or any other vendor) > any better regarding the complaints above?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.> * The Mico32 is open source but is the origin of the code made by > Lattice themselves or?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
Reply by ●October 13, 20082008-10-13
> Why does this need to be on the FPGA ? > SoftCPUs still need external memory, so are a 2-3 chip solution.Correct, but the FPGA is a "must have" in this project, so an embedded softcore will give us allot of advantages: *No extra BOM cost for MCU and needed extra components. *No additional use of "real estate" for the MCU subsystem. *High data bandwidt between our custom hardware and CPU. *"Weird" hardware configurations are supported (e.g. we need 4+ i2c busses). These pros has made us going for the softcore soloution. -- MMJ
Reply by ●October 13, 20082008-10-13
MMJ wrote:>>Why does this need to be on the FPGA ? >>SoftCPUs still need external memory, so are a 2-3 chip solution. > > > Correct, but the FPGA is a "must have" in this project, so an embedded > softcore will give us allot of advantages: > > *No extra BOM cost for MCU and needed extra components.Here you need care: Your SoftCPU needs external Code memory, so that adds to the BOM (unless you just happen to be using large external memory anyway, with unused space, that can fit the CODE, and also happen to have spare bus cycles to access it. It also might need a larger Config memory, another BOM adder, and you might also need a larger FPGA. You also have higher EMC issues, and could even need more PCB layers.... If that external memory is ONLY for code, that is a LOT of pins you have added to the design....> *No additional use of "real estate" for the MCU subsystem.Single chip MCUs are quite small, and the flash is all done. Generally, if you can fit your code into a merchant uC, it makes more sense to use one, along side your (now smaller?) FPGA> *High data bandwidt between our custom hardware and CPU.How high do you need ?> *"Weird" hardware configurations are supported (e.g. we need 4+ i2c busses).Nothing stops you adding 4 i2c in the FPGA> > These pros has made us going for the softcore soloution.-jg