> Antti wrote:
> > Mike Harrison schrieb:
> >
> > > 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.
> >
> > Mike,
> >
> > the list of peripherals you mentioned will be possible on Standard
> > MicroFpga's (eg no customization) starting some 'resource' level, e.g.
> > if a 32 Bit RISC takes below 50% then the rest of the FPGA will be
> > filled with peripherals. One difference with MCU's is the fact that all
> > I/Os are treated a the same. There will be some limitations what hw ip
> > cores can be routed to I/Os at any given time, but there are usually no
> > dedicated pins at all (depending FPGA family being used there are
> > exceptions), that is if 8 Channel PWM block exists in an FPGA with 489
> > pins then any 8 pins of the available 489 can be used as PWM outputs :)
>
> Sounds great, but I don't see how that would be done. If you are not
> using place and route tools, how can you change the IO assignments? If
> this is just another MCU in an FPGA, with no option of customizing the
> code to add special logic or peripherals, how is it utilizing the FPGA
> in any way other than as a very expensive and power hungry version of a
> CPU?
well I cant change assigments so all IO are pre-assigned as GP(n),
where n =0..max_pins-1
there obviosly is something between CPU peripherals and GP(n)
and of course there are severe restrictions what can be done and
what not, but the way I see the concept amazing things can be
done, sure the nice features would require relativly large FPGA
to really shine, but hey the FPGA prices are dropping all the time!
Antti
Reply by rickman●September 26, 20062006-09-26
Antti wrote:
> Mike Harrison schrieb:
>
> > 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.
>
> Mike,
>
> the list of peripherals you mentioned will be possible on Standard
> MicroFpga's (eg no customization) starting some 'resource' level, e.g.
> if a 32 Bit RISC takes below 50% then the rest of the FPGA will be
> filled with peripherals. One difference with MCU's is the fact that all
> I/Os are treated a the same. There will be some limitations what hw ip
> cores can be routed to I/Os at any given time, but there are usually no
> dedicated pins at all (depending FPGA family being used there are
> exceptions), that is if 8 Channel PWM block exists in an FPGA with 489
> pins then any 8 pins of the available 489 can be used as PWM outputs :)
Sounds great, but I don't see how that would be done. If you are not
using place and route tools, how can you change the IO assignments? If
this is just another MCU in an FPGA, with no option of customizing the
code to add special logic or peripherals, how is it utilizing the FPGA
in any way other than as a very expensive and power hungry version of a
CPU?
Reply by Antti●September 26, 20062006-09-26
Mike Harrison schrieb:
> 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.
Mike,
the list of peripherals you mentioned will be possible on Standard
MicroFpga's (eg no customization) starting some 'resource' level, e.g.
if a 32 Bit RISC takes below 50% then the rest of the FPGA will be
filled with peripherals. One difference with MCU's is the fact that all
I/Os are treated a the same. There will be some limitations what hw ip
cores can be routed to I/Os at any given time, but there are usually no
dedicated pins at all (depending FPGA family being used there are
exceptions), that is if 8 Channel PWM block exists in an FPGA with 489
pins then any 8 pins of the available 489 can be used as PWM outputs :)
Cheers,
Antti
Reply by Antti●September 25, 20062006-09-25
zcsizmadia@gmail.com schrieb:
> 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
>
Zoltan,
you are absolutly right! it is really a simple concept.
Antti
Reply by Antti●September 25, 20062006-09-25
fpga_toys@yahoo.com schrieb:
> 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!!
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
Reply by Mike Harrison●September 25, 20062006-09-25
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.
Reply by ●September 25, 20062006-09-25
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!!
Reply by zcsi...@gmail.com●September 24, 20062006-09-24
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.
Reply by rickman●September 23, 20062006-09-23
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.
Reply by ziggy●September 23, 20062006-09-23
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..