best soft core(s) that have C compiler support

Hi

i know has been discussed before ;)

if we leave out the vendor supplied ones (including open source like
mico32)
and the large ones, then my current list:

Core   Datapath width   Spartan-3 slices for small SoC (approx, ISE
10.1 results)
ZPU    32                     1000
C16    16                     1000
i8080  8                       1000
L8080 8                       450
L8080 8                       150 + 1 BRAM for microcode

ZPU is stack based so most weird, but it has GCC support
C16 has its own assembler/compiler/simulator supplied with source code
i8080/L8080 are intel 8080 - I assume there is some  C compiler
available
L8080 (lightweight 8080) not sure if it is correct enogh to run c
compiler code

I wonder if there are better candidates for each bit-width category
microblaze clone could be considered for 32, but i would rather leave
such clones out from the table

Antti

On 27 Mrz., 15:13, Antti <Antti.Luk...@googlemail.com> wrote:

> I wonder if there are better candidates for each bit-width category
> microblaze clone could be considered for 32, but i would rather leave
> such clones out from the table

If you include an 8080 clone, you can also include a microblaze clone.
AFAIK the open cores microblaze is a cleanroom reimplementation of
the microblaze ISA.

Kolja

On Mar 27, 7:13=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
> Hi
>
> i know has been discussed before ;)
>
> if we leave out the vendor supplied ones (including open source like
> mico32) and the large ones, then my current list:

The requirements for being on the list appear underspecified. For
instance, it does not take performance into account.

My own MIPS clone YARI is not tiny at ~ 5,000 LE (LUT4 + FF), but is
certainly one of the faster open source cores out there and it (being
MIPS compatible) has fantastic tool support. Does ZPU have a debugger?
A Linux port? A JAVA jit?

Tommy

On Mar 28, 2:13=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
> Hi
>
> i know has been discussed before ;)
>
> if we leave out the vendor supplied ones (including open source like
> mico32) and the large ones, then my current list:

Why leave the Open-Source ones off the list ?
- surely they should be there, as important reference points ?

-jg

On Mar 27, 10:38=A0pm, -jg <Jim.Granvi...@gmail.com> wrote:
> On Mar 28, 2:13=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
>
> > Hi
>
> > i know has been discussed before ;)
>
> > if we leave out the vendor supplied ones (including open source like
> > mico32) and the large ones, then my current list:
>
> Why leave the Open-Source ones off the list ?
> - surely they should be there, as important reference points ?
>
> -jg

sorry, i did mean vendor provided open-source one (the onlysuch one
bein mico32)

and as of clean room microblaze vs i8080 clone, i think i did think
i8080 clone
is more safe and clean then microblaze clones

and i was considering MIPS if allowing more resource hungry
implementations


Antti

On Mar 27, 3:25=A0pm, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> and i was considering MIPS if allowing more resource hungry
> implementations

Hey Antti,

I would be delighted if you would help lower the resource requirement
of YARI to suit your needs :-) I sure would learn a lot in the
process.

Tommy

On Mar 28, 10:25=A0am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> sorry, i did mean vendor provided open-source one (the onlysuch one
> bein mico32)

I'm still lost as to why you exclude those ? If it is open source, you
are
free to start your own branch design, should you spot something that
really need adding, but can only be done at the cost of something
else....

> and as of clean room microblaze vs i8080 clone, i think i did think
> i8080 clone  is more safe and clean then microblaze clones

Yes, but a 8080 is a lousy 'fit' in a FPGA. The Dual-port ram nature
of FPGAs
makes register based cores more natural.
(indeed, even ones with a register frame pointer)

What is the status of a compiler for Mico8/PicoBlaze/PacoBlaze etc ?

-jg

On Mar 28, 4:53=A0am, -jg <Jim.Granvi...@gmail.com> wrote:
> On Mar 28, 10:25=A0am, "Antti.Luk...@googlemail.com"
>
> <Antti.Luk...@googlemail.com> wrote:
> > sorry, i did mean vendor provided open-source one (the onlysuch one
> > bein mico32)
>
> I'm still lost as to why you exclude those ? If it is open source, you
> are
> free to start your own branch design, should you spot something that
> really need adding, but can only be done at the cost of something
> else....
>
> > and as of clean room microblaze vs i8080 clone, i think i did think
> > i8080 clone =A0is more safe and clean then microblaze clones
>
> Yes, but a 8080 is a lousy 'fit' in a FPGA. The Dual-port ram nature
> of FPGAs
> makes register based cores more natural.
> (indeed, even ones with a register frame pointer)
>
> What is the status of a compiler for Mico8/PicoBlaze/PacoBlaze etc ?
>
> -jg

Hi Jim,

let me explain in more detail:

if I use LatticeMico32 for commercial product targetting Xilinx,
Altera..
or
if I use MicroBlaze(tm) clone on Altera, Lattice

then I suppose it may get unwanted attention, or if not it will get
absolute nil support from the vendors where soft-core marketed
by direct competitor is used.

regarding i8080 clones, I assume that neither Xilinx, Altera, Lattice,
et others
would not mind, as Intel is not FPGA vendor.
and i do not think intel would send C&D either

this was the full reasoning behind the selection based on licensing
and clones.

=3D=3D

C- Compiler for PicoBlaze, well it can be used for some test to prove
it generates code, but PicoBlaze is so crippled that the solution is
not much useable. Just too small code space.

=3D=3D
YARI, hm i am interested too, if even the caches could be disabled
it maybe small enough


Antti

On Mar 28, 5:45=A0pm, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 28, 4:53=A0am, -jg <Jim.Granvi...@gmail.com> wrote:
>
>
>
> > On Mar 28, 10:25=A0am, "Antti.Luk...@googlemail.com"
>
> > <Antti.Luk...@googlemail.com> wrote:
> > > sorry, i did mean vendor provided open-source one (the onlysuch one
> > > bein mico32)
>
> > I'm still lost as to why you exclude those ? If it is open source, you
> > are
> > free to start your own branch design, should you spot something that
> > really need adding, but can only be done at the cost of something
> > else....
>
> > > and as of clean room microblaze vs i8080 clone, i think i did think
> > > i8080 clone =A0is more safe and clean then microblaze clones
>
> > Yes, but a 8080 is a lousy 'fit' in a FPGA. The Dual-port ram nature
> > of FPGAs
> > makes register based cores more natural.
> > (indeed, even ones with a register frame pointer)
>
> > What is the status of a compiler for Mico8/PicoBlaze/PacoBlaze etc ?
>
> > -jg
>
> Hi Jim,
>
> let me explain in more detail:
>
> if I use LatticeMico32 for commercial product targetting Xilinx,
> Altera..
> or
> if I use MicroBlaze(tm) clone on Altera, Lattice
>
> then I suppose it may get unwanted attention, or if not it will get
> absolute nil support from the vendors where soft-core marketed
> by direct competitor is used.

What sort of unwanted attention ? It is open sourced, they do not care
if
it goes into an ASIC, or any FPGA.
As for support, yes, if Z or A tools barf on some detail, then you
need to work
yourself, but the same applies to any other candidate on your list
too....



> regarding i8080 clones, I assume that neither Xilinx, Altera, Lattice,
> et others
> would not mind, as Intel is not FPGA vendor.
> and i do not think intel would send C&D either

;) IF you could even find anyone at intel who knew what an 8080 was !!

>
> C- Compiler for PicoBlaze, well it can be used for some test to prove
> it generates code, but PicoBlaze is so crippled that the solution is
> not much useable. Just too small code space.

But there are choices, and V3 supports 24 bits of address space, which
is more than I recall a 8080 offering

>
> =3D=3D
> YARI, hm i am interested too, if even the caches could be disabled
> it maybe small enough

-jg

On Mar 28, 8:02=A0am, -jg <Jim.Granvi...@gmail.com> wrote:
> On Mar 28, 5:45=A0pm, "Antti.Luk...@googlemail.com"
>
>
>
> <Antti.Luk...@googlemail.com> wrote:
> > On Mar 28, 4:53=A0am, -jg <Jim.Granvi...@gmail.com> wrote:
>
> > > On Mar 28, 10:25=A0am, "Antti.Luk...@googlemail.com"
>
> > > <Antti.Luk...@googlemail.com> wrote:
> > > > sorry, i did mean vendor provided open-source one (the onlysuch one
> > > > bein mico32)
>
> > > I'm still lost as to why you exclude those ? If it is open source, yo=
u
> > > are
> > > free to start your own branch design, should you spot something that
> > > really need adding, but can only be done at the cost of something
> > > else....
>
> > > > and as of clean room microblaze vs i8080 clone, i think i did think
> > > > i8080 clone =A0is more safe and clean then microblaze clones
>
> > > Yes, but a 8080 is a lousy 'fit' in a FPGA. The Dual-port ram nature
> > > of FPGAs
> > > makes register based cores more natural.
> > > (indeed, even ones with a register frame pointer)
>
> > > What is the status of a compiler for Mico8/PicoBlaze/PacoBlaze etc ?
>
> > > -jg
>
> > Hi Jim,
>
> > let me explain in more detail:
>
> > if I use LatticeMico32 for commercial product targetting Xilinx,
> > Altera..
> > or
> > if I use MicroBlaze(tm) clone on Altera, Lattice
>
> > then I suppose it may get unwanted attention, or if not it will get
> > absolute nil support from the vendors where soft-core marketed
> > by direct competitor is used.
>
> What sort of unwanted attention ? It is open sourced, they do not care
> if
> it goes into an ASIC, or any FPGA.
> As for support, yes, if Z or A tools barf on some detail, then you
> need to work
> yourself, but the same applies to any other candidate on your list
> too....
>
> > regarding i8080 clones, I assume that neither Xilinx, Altera, Lattice,
> > et others
> > would not mind, as Intel is not FPGA vendor.
> > and i do not think intel would send C&D either
>
> ;) IF you could even find anyone at intel who knew what an 8080 was !!
>
>
>
> > C- Compiler for PicoBlaze, well it can be used for some test to prove
> > it generates code, but PicoBlaze is so crippled that the solution is
> > not much useable. Just too small code space.
>
> But there are choices, and V3 supports 24 bits of address space, which
> is more than I recall a 8080 offering
>
>
>
> > =3D=3D
> > YARI, hm i am interested too, if even the caches could be disabled
> > it maybe small enough
>
> -jg

Jim

LatticeMico8 Ver 3 supports 24 bit banked address space for the IO
but still only 4K instruction memory, and PicoBlaze asfaik doesnt
support large memory addressing nativly

and, I am not saying my list is good one, or has the right candidates
it was the best to my knowledge at the time or making it based on
the criteria i had in mind. maybe there are much better candidates
thats why i posted in the first place.

i8080 is on the list mainly because the lightweigt8080 is rather
small.. i was suprised.

the goal is to find best CPU for minimal SoC that should be
possible to fit to widest possible selection of FPGA's thats
why the huge ones are not listed. L8080 fits into smaller
end of FPGAs where 32 bit Cores do no longer fit. Also
some smaller FPGAs may have too small BRAM so
the 32 bit CPUs would just have too small instruction memory
for the C compiler to be useable at all. So I would prefer
to have some 8 bit CPU on my offering as well. It seems
that L8080 could be the candidate.

Antti