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

Marlboro schrieb:

> Will it be available in Spartan2 or VirtexE?
> 
Spartan2/virtexE are supported

Antti

In article <1158770147.385889.73830@m73g2000cwd.googlegroups.com>,
 "Antti" <Antti.Lukats@xilant.com> wrote:

> Kyle H. schrieb:
> 
> > Is this not similar to Xilinx's PPC and MicroBlaze cores using EDK?
> >
> > Possibly a much cheaper solution?
> >
> > Regards,
> > Kyle
> 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
> 1) FPGA
> 2) C compiler
> 
> it does *NOT* require
> 1) FPGA vendor provided tools
> 2) any HDL knoweldge
> 
> there is a difference I think ;)
> 
> 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:

> In article <1158770147.385889.73830@m73g2000cwd.googlegroups.com>,
>  "Antti" <Antti.Lukats@xilant.com> wrote:
[snip]
> If so, people  like me will need to stick to other 'free' cores.

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:
1) write your C program
2) compile with GCC
3a) merge ELF or bin into BIT or
3b) download over JTAG or serial

4) your C programs runs

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

Antti

Antti wrote:
> FPGA is not a MicroController?
> ...or is it !?
>
> MicroFpga makes an FPGA to look like an MCU, and makes it programmable
> as it would be a normal MCU without requiring any HDL knowledge or FPGA
> implementation tools.
>
> More details will be available from the product website
> http://www.microfpga.com
> ..soon


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:

> Antti wrote:
> > FPGA is not a MicroController?
> > ...or is it !?
> >
> > MicroFpga makes an FPGA to look like an MCU, and makes it programmable
> > as it would be a normal MCU without requiring any HDL knowledge or FPGA
> > implementation tools.
> >
> > More details will be available from the product website
> > http://www.microfpga.com
> > ..soon
>
>
> 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

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

In article <1158822468.138975.247720@h48g2000cwc.googlegroups.com>,
 "Antti" <Antti.Lukats@xilant.com> wrote:

> ziggy schrieb:
> 
> > In article <1158770147.385889.73830@m73g2000cwd.googlegroups.com>,
> >  "Antti" <Antti.Lukats@xilant.com> wrote:
> [snip]
> > If so, people  like me will need to stick to other 'free' cores.
> 
> 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:
> 1) write your C program
> 2) compile with GCC
> 3a) merge ELF or bin into BIT or
> 3b) download over JTAG or serial
> 
> 4) your C programs runs
> 
> in any supported FPGA 
> on any board or hardware it is in.
> 
> Antti

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

ziggy wrote:
> In article <1158822468.138975.247720@h48g2000cwc.googlegroups.com>,
>  "Antti" <Antti.Lukats@xilant.com> wrote:
>
> > ziggy schrieb:
> >
> > > In article <1158770147.385889.73830@m73g2000cwd.googlegroups.com>,
> > >  "Antti" <Antti.Lukats@xilant.com> wrote:
> > [snip]
> > > If so, people  like me will need to stick to other 'free' cores.
> >
> > 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:
> > 1) write your C program
> > 2) compile with GCC
> > 3a) merge ELF or bin into BIT or
> > 3b) download over JTAG or serial
> >
> > 4) your C programs runs
> >
> > in any supported FPGA
> > on any board or hardware it is in.
> >
> > 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:
> ziggy wrote:
> > In article <1158822468.138975.247720@h48g2000cwc.googlegroups.com>,
> >  "Antti" <Antti.Lukats@xilant.com> wrote:
> >
> > > ziggy schrieb:
> > >
> > > > In article <1158770147.385889.73830@m73g2000cwd.googlegroups.com>,
> > > >  "Antti" <Antti.Lukats@xilant.com> wrote:
> > > [snip]
> > > > If so, people  like me will need to stick to other 'free' cores.
> > >
> > > 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:
> > > 1) write your C program
> > > 2) compile with GCC
> > > 3a) merge ELF or bin into BIT or
> > > 3b) download over JTAG or serial
> > >
> > > 4) your C programs runs
> > >
> > > in any supported FPGA
> > > on any board or hardware it is in.
> > >
> > > 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.

Antti wrote:
> MicroFpga makes an FPGA to look like an MCU, and makes it programmable
> as it would be a normal MCU without requiring any HDL knowledge or FPGA
> implementation tools.

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!!

On 24 Sep 2006 19:44:53 -0700, "zcsizmadia@gmail.com" <zcsizmadia@gmail.com> wrote:

>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).

Maybe a  version, which allowed you to mix & match from a selection of peripheral modules like
lego-blocks would be interesting, and fill a market niche for people that need MCUs with wierd
peripheral mixes not served by the current MCU market, e.g. 8 UART transmitters, two receivers,
three SPIs, 5 timers and 3 PWMs.....
Obviously this gets more complex to do, but I think it would be a nice in-between product that could
fill a slot in the space between MCUs and FPGAs.