MicroFpga = program an FPGA as it would be a MCU !

Is this not similar to Xilinx's PPC and MicroBlaze cores using EDK?

Possibly a much cheaper solution?

Regards, Kyle

Kyle H. schrieb:

Hi Kyle,

using PPC or MicroBlaze usually requires both ISE and EDK and usually some hardware (HDL) knowledge as well - isnt that so?

using MicroFpga requires only

it does *NOT* require

there is a difference I think ;)

Antti

Ok, I'll bite...

So why is it better than using an MCU?

Cheers, Jon

Jon Beniston schrieb:

Jon,

have you seen a MCU with 1700+ pins? :) MicroFgpa makes FPGA to look like MCU that can access ALL FPGA pins available on a given package. It does not require any external components, no proper ext reset signal or any external clocks.

I am not saying it is somehow better - its just an option, an option to run normal C programs on any FPGA, can be really useful for board testing, in education, doing funny things...?

setting up an FPGA project for initial PCB board bringup takes time right? with MicroFpga you can INSTANTLY test the PCB using test programs written in plain C not a minute wasted with synthesis or P&R.

if I count the minutes, hours and days I have spent with board bringup and test FPGA designs - it could be come years of time that I could have be saved.

Antti

PS I just received email from our first MicroFpga EAP member who confirms the functionality on Digilent Spartan3 Starterkit. (as I dont have any boards with that FPGA then I had not tested it myself - but it was working!)

And you can probably run 12 picoblaze (or whatever Antti has) at 40 MIPS in XC3S200-FT256. I think it is better than 300 mhz single blackfin or PPC in terms of number of i/o, access speed of i/o..

YASC - Yet Another Soft Core. How thrilling.

pete

Good point. Any soft core needs to be compatible somehow otherwise what's the point. Not that this one isn't...I don't know.

Does gcc work with it? Either linux or ucLinux support the cpu? Is it PIC, AVR, MIPS, ARM compatible?

Too many "no"'s means forget it...

-Dave

Pete Fenelon schrieb:

Pete,

it's even far less thrilling, its not even another soft core :) I am far too lazy. So I am not inventing when there is no need.

Antti

Marlboro schrieb:

Spartan2/virtexE are supported

Antti

Seen as its currently only for "selected EAP members", will it have a cost once its released?

If so, people like me will need to stick to other 'free' cores.

ziggy schrieb:

Hi ziggy,

all people like you can stick to any cores of your liking when doing HDL or FPGA designs as the MicroFpga can *NOT* be used with any kind of HDL flow at all. No synthesis, no place and route!

Just take an FPGA and GCC compiler. No FPGA vendor tools involved in the process flow:

4) your C programs runs

in any supported FPGA on any board or hardware it is in.

Antti

Hi Antti,

I take it that this is some kind of microblaze derivative, stripping out the Xilinx software flow, and thus making the whole design flow much more simple.

I can think of a lot of products where the whole microblaze thing might be overkill (not that I have tried it myself), and this could be a solution.

It could also be interesting as a first step to microblaze, and once you get comfortable with the software side of it step to the real version.

My questions would be :

- is there any external Bus ?

- Max ROM/RAM available.

- Peripherals : counters, UART, VGA controller, etc

I just can't wait till you make the details available at the website.

Regards

Josep Duran

Josep Duran schrieb:

Hi Josep,

the toplevel ports of *ALL* MicroFpga/Generic look the same:

entity mf_top is Generic ( C_GP_WIDTH : integer := CFG_GP_WIDTH ); Port ( GP : inout STD_LOGIC_VECTOR (0 to C_GP_WIDTH-1) ); end mf_top;

where CFG_GP_WIDTH = "number of total FPGA IO pins"

and yes, you can connect VGA signal to GP(x) but the VGA controller would be limited to use only on-chip block RAMs. Maximum pixel clock and color depth depend on the FPGA being used and MicroFpga configuration being used. 3-bit pro color should be possible, or even 4 bits pro color.

There are always some compromises. being able to handle ANY and all available FPGA pins exactly the same, and being able to run on ANY design and board makes it not possible to support everything. But quite a many things are possible within the given constraints that the design must run in any hardware platform without customization that is one bit stream is useable without changes in all boards that have a compatible FPGA on it.

The types of external memories supported is somewhat limited, but all effort will be given to support as many different external memories as possible.

Thanks for interest, Antti

Ah, i think i understand now.. its running c-code directly on the hardware..

I don't think it is that simple. At least I don't think this is the equivalent of Handel C which can compile your C code to a bit file to load into the FPGA just like an HDL bit file. That would require a lot of knowledge about the internals of the FGPA and would be different for every single one! I expect they are doing something where they load a fixed set of gateware into the FPGA which is perhaps like a reconfigurable processor rather than a fixed instruction set. But I am speculating. I just don't believe they have obtained all the info to generate bit files for FPGAs. That is sort of the "Holy Grail" of open source FPGA development software. Instead they use JBITs on Xilinx and something equivalent on Altera devices. I believe each of these programs have some limitations for this sort of thing and licensing may be the major issue for open source people.

I think the concept is really simple. They provide you the precompiled hw bit file, so you don't need any vhdl development (ISE or EDK). The only thing you need is a free mb-gcc to generate the elf file and use dat2mem to merge elf with the precompiled hw bit file. Of course you can only use the predefined peripherials, and Antti must provide this precompiled hw bit file for every single supported device.

You save a bunch of money spent on EDK and time not to worry about setting up the peripherials As Antti said this is a alternative to people who wants to use the FPGA as a uC (and keep the option open to implement hw related stuff in the FPGA later on).

But maybe I'm wrong because I haven't tried it yet. :)

Zoltan

rickman wrote:

Cute idea Antti !!

Pregenerated, placed, and routed FPGA MCU's with a tool to install the program binary into the bitstream, editing the ROM image for the MCU.

Hobby level access to cheap FPGA parts and boards, and even useful for embedded HW designers gun shy about FPGA development.

.... certainly Have Fun with this one!!

fpga snipped-for-privacy@yahoo.com schrieb:

Hi John,

thanks for cute words! I also hope it to be fun for many useage scenarios as well.

The hardware features that are available largely depend on a concept xxxxx (no name yet) that is currently being developed and tested. MicroFpga is fun without xxxxx also, but the useability of hard peripheral IP cores is very limited. xxxxx will allow funtions like pwm, deltasigma dac, VGA, etc to be assigned to any IO pin of the FPGA (yes any pin of given package) under pure software control. Here are of course also compromises and restrictions in place depending the package and device selection, but there is way more fun in.

More details to follow soon.

Antti