Well it's not new at all, but I've just discovered Yet Another Open Source RISC core -- Lattice's Mico32. It comes with GNU tool-chain (making the software-development side similar to OpenRisc 1200?) and even has a built-in debug-module.
How popular these Opensource cores really are? I know the Opencores EMAC
10/100 gets a lot of use in commercial ASIC projects. But the CPU-cores rarely get the same attention (mostly just academic or government-funded stuff.) Could someone explain why?
Is it their performance (IPC, area, power-consumption)? Is it lack of a supported embedded O/S port?
What's your question exactly - why FPGA cores are not seen more in ASICS ? - I get the impression Leon is doing quite well, in its niche. Mico32 is very new, and is really the first open source FPGA-centric core, so I'd expect it will show up in ASICs.
Would you count a NIOS II licensed for ASIC use, either via the Altera flow, or in a full asic.
Of course, ASIC design starts are a tiny fraction of fpgA design starts, so any core usage in that direction has to be small.
Risk. Spending a couple of hundred k on a CPU with commercial support is not that big a deal if you're making ASICs.
Performance should be pretty comparible to the low-end commerical offerings. Something like Mico32 is very much stripped down to minimize LUT count, so some of the bells ans whistles you'll find in dedicate ASIC CPUs are missing.
I've also noticed the lm32. It is really well documented. My only objection (but hopefully this will change, i think it is under consideration) is that Lattice provides only Verilog sources (which is the language of preference for me).
A quick sum-up would include: PicoBlaze, MicroBlaze, Nios-II, LatticeMico32, LEON2/3, OpenRISC. It would also be proper to add here some bytecode interpreter engines (most notably JOP), but they are not intended for general-purpose apps.
All the above are 32-bit machines except PicoBlaze. I have added PicoBlaze in the list, because i find it really useful and a very powerful processor for control-oriented applications. It has predictable real-time performance and a large number (up to 256) of i/ o ports. I have recently set up a couple of lab exercises (one with PicoBlaze solo and a second one with a RISC core of mine and a PicoBlaze) and i'm very positive over PicoBlaze.
It is strange but all the above RISC cores have good toolchains so someone would expect a wider adoption (adoption is good for the vertical markets they are intended to for the time being). The positive thing here is that there is no way but up. Embedded processing and FPGAs will grow as CLB counts will rise and power consumption (hopefully) will drop).
And most of the 32-bit cores have at least some kind of support for embedded OSes (RTEMS, uClinux and others even commercial ones like uCOS series).
But finally i donnot understand if there is a question posed here. Do you have to choose between a open core and a closed-source solution. Or are you between using a programmable processor core and using something more customized for your case?
OK, my apologies for the Microblaze, that was a strange story :) But regarding Nios-II, i think the sources are there, but just not portable across other FPGA architectures. Am I right?
Thanks everyone, for the replies. My question was vague and poorly worded because I don't have a good grasp on what constitutes a "FPGA CPU-core"and an "ASIC CPU-core." Microblaze and Nios-II obviously are architected around the unique device-features of their respective vendors. But when it comes to the Opensource offerrings, I didn't see the same trend (maybe I didn't look close enough?)
Picoblaze -- is that safe for ASIC-use? I was under the impression Xilinx's license-agreement limits it to Xilinx devices only.
I'm not sure about the Picoblaze licensing. Actually, there are at least 2 distinct version of Picoblaze available from Xilinx site. There is a Virtex-2/Spartan-3 optimized version (KCPSM3) that involves Xilinx-specific components (buffers, registers etc), and another version with some differences in the architecture (slightly older instruction set, 8 registers instead of 16) originally devised for CPLDs. However this description is completely portable across different FPGA vendors. For example i have ported this one to XC3S200 with good results (around 170 slices, maybe less i don't recall the exact results).
It would be meaningful for Xilinx to license this more obsolete version in GPL or LGPL sense. Anyone aware of the exact licensing issues with the two different PicoBlaze versions, please jump in.
And, the MicroBlaze(tm) uP soft core use agreement stipulates that it is to be used on Xilinx FPGAs, only. We have no incentive to allow its use in an ASIC.
I think for ASIC development, the issue is all risk: as in, there must not be any risk at all. Thus, you see ARM uP's in most low power/low cost ASICs. The 'guarantee' allows one to get real support (which is sadly lacking in open cores). Higher end/higher performance ASICs use MIPs, or the PowerPC.
Recently opencores.org put itself up for sale, and is (effectively) out of business. This is exactly why using open cores represents a huge risk. Since no one has figured out how to make money off open cores, there is no incentive at all to give your hard work away for free.
Additionally, a massive amount of work goes into testing and re-optimizing every core when the technology node changes. Who will pay for that? Who will warrant or guarantee operation? Who supplies the test bench vectors to verify proper operation?
PicoBlaze is offered "as - is", and subsequently has no restrictions on its use.
It is in the 'spirit' of an open core, as in, we really do not mind where and how it may be used.
It is also "unsupported" by the Xilinx Support system. If we find something that is a bug, we will fix it, but we do not offer any guarantees about its use, or performance like we do for the MicroBlaze(tm) or PowerPC(tm) processors.
In the user guide I pointed to, there is no reference to any agreement.
Your link points to the use agreement. It is not specific to anything. It has to be specifically stated in each and every document that the use agreement applies, and how it applies.
I did find one reference to "use within a Xilinx FPGA" in one of the .pdf marketing documents, but that reference did not provide any details, nor any restrictions.
I suspect that one .pdf document is not considered binding, or legal, as it does not refer to any "real" agreement (like the link you provide).
One sentence like "use within a Xilinx FPGA" is more of a desire to keep the PicoBlaze 'in the family....' than any kind of binding legal use agreement.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.