microblaze question

I'm investigating if the microblaze is an option for a project where
physical space is extremely limited. Perhaps somebody can answer the
following:
1.Is it possible to use the microblaze in a spartan3E 500? If yes, how much
will it eat from this device?
2.if yes, is it possible to use the microblaze without any other memory
chips (except one serial bootrom) and still running a standalone program
which is not super large and does not need lots of memory?
Thanks
taco

taco wrote:
 
> I'm investigating if the microblaze is an option for a project where
> physical space is extremely limited. Perhaps somebody can answer the
> following:
> 1.Is it possible to use the microblaze in a spartan3E 500? If yes, how much
> will it eat from this device?
> 2.if yes, is it possible to use the microblaze without any other memory
> chips (except one serial bootrom) and still running a standalone program
> which is not super large and does not need lots of memory?

If you need a real small CPU, take a look at 

ftp://137.193.64.130/pub/mproz/mproz3_e.pdf

Only a few dozen flip-flops and a few hundred gates.

On Jan 24, 9:28 am, taco <trala...@joepie.nl> wrote:
> I'm investigating if the microblaze is an option for a project where
> physical space is extremely limited. Perhaps somebody can answer the
> following:
> 1.Is it possible to use the microblaze in a spartan3E 500? If yes, how much
> will it eat from this device?

i have a microblaze in a spartan 3e 250 and it takes about 50%


> 2.if yes, is it possible to use the microblaze without any other memory
> chips (except one serial bootrom) and still running a standalone program
> which is not super large and does not need lots of memory?

yes.  you can run from block ram.  you can't include a bunch of
libraries (for example, printf won't fit).

alan nishioka
alan@nishioka.com

Herbert Kleebauer wrote:

> taco wrote:
>  
>> I'm investigating if the microblaze is an option for a project where
>> physical space is extremely limited. Perhaps somebody can answer the
>> following:
>> 1.Is it possible to use the microblaze in a spartan3E 500? If yes, how
>> much will it eat from this device?
>> 2.if yes, is it possible to use the microblaze without any other memory
>> chips (except one serial bootrom) and still running a standalone program
>> which is not super large and does not need lots of memory?
> 
> If you need a real small CPU, take a look at
> 
> ftp://137.193.64.130/pub/mproz/mproz3_e.pdf
> 
> Only a few dozen flip-flops and a few hundred gates.
Mmm, and only to be programmed in assembler, I assume. Picoblaze is even
smaller... 
Right now I'm running an opencore 8051 which works fine and can be
programmed in C, but for the project I'm doing it could be that this runs
too slow and cannot handle to dataflow entering a FIFO. microblaze would
certainly solve it unless I have to add hardware.
Thanks anyway.
Taco

Alan Nishioka wrote:

> On Jan 24, 9:28 am, taco <trala...@joepie.nl> wrote:
>> I'm investigating if the microblaze is an option for a project where
>> physical space is extremely limited. Perhaps somebody can answer the
>> following:
>> 1.Is it possible to use the microblaze in a spartan3E 500? If yes, how
>> much will it eat from this device?
> 
> i have a microblaze in a spartan 3e 250 and it takes about 50%
> 
> 
>> 2.if yes, is it possible to use the microblaze without any other memory
>> chips (except one serial bootrom) and still running a standalone program
>> which is not super large and does not need lots of memory?
> 
> yes.  you can run from block ram.  you can't include a bunch of
> libraries (for example, printf won't fit).
> 
> alan nishioka
> alan@nishioka.com
Thanks a lot, that's exactly what I needed to know.
taco

On Jan 25, 12:24 am, taco <trala...@joepie.nl> wrote:

> Right now I'm running an opencore 8051 which works fine and can be
> programmed in C, but for the project I'm doing it could be that this runs
> too slow and cannot handle to dataflow entering a FIFO. microblaze would
> certainly solve it unless I have to add hardware.

What is the complexity of your code?

If you want to minimize the code to fit inside block RAMs the 8051
might not be your best choice.
You can find some comparison data on my proc4 web page: http://www.delajii.net/proc4

As a note, a MCU based on proc4 core fits in a spartan3 50 (i.e. the
smallest) using only the internal RAM, making use of [almost] all pins
(as I/Os).

--
mmihai

On 2008-01-26, mmihai <iiahim@yahoo.com> wrote:
> On Jan 25, 12:24 am, taco <trala...@joepie.nl> wrote:
>
>> Right now I'm running an opencore 8051 which works fine and can be
>> programmed in C, but for the project I'm doing it could be that this runs
>> too slow and cannot handle to dataflow entering a FIFO. microblaze would
>> certainly solve it unless I have to add hardware.
>
> What is the complexity of your code?
>
> If you want to minimize the code to fit inside block RAMs the 8051
> might not be your best choice.
> You can find some comparison data on my proc4 web page: http://www.delajii.net/proc4

I took a quick look at your webpage [1] and have a few questions:

Do you have a C-compiler for your processor? (You only say that it is
programmable in a high-level language on your webpage.)

Do you know if commercial compilers for Z80 and 8051 will produce better
results than sdcc?

I also note that the 8051 results were done with 6 clocks per machine
cycle. AFAIK there are much faster 8051 cores available.


/Andreas

[1] Initially I expected something to download there but I guess I was
    somewhat too optimistic there... still an interesting page though.

Andreas Ehliar wrote:

> On 2008-01-26, mmihai <iiahim@yahoo.com> wrote:
>> On Jan 25, 12:24 am, taco <trala...@joepie.nl> wrote:
>>
>>> Right now I'm running an opencore 8051 which works fine and can be
>>> programmed in C, but for the project I'm doing it could be that this
>>> runs too slow and cannot handle to dataflow entering a FIFO. microblaze
>>> would certainly solve it unless I have to add hardware.
>>
>> What is the complexity of your code?
>>
>> If you want to minimize the code to fit inside block RAMs the 8051
>> might not be your best choice.
>> You can find some comparison data on my proc4 web page:
>> http://www.delajii.net/proc4
> 
> I took a quick look at your webpage [1] and have a few questions:
> 
> Do you have a C-compiler for your processor? (You only say that it is
> programmable in a high-level language on your webpage.)

Yeah, same question. I think this is not the case and if it's not a standard
high level language, moving to a different processor is not very easy.

> 
> Do you know if commercial compilers for Z80 and 8051 will produce better
> results than sdcc?

The answer is yes. The Keil compiler produces better optimized code for
8051.

> 
> I also note that the 8051 results were done with 6 clocks per machine
> cycle. AFAIK there are much faster 8051 cores available.

Mmm. to get the graphs in some better direction?
Taco

On Jan 27, 11:51 pm, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote:

> I took a quick look at your webpage [1] and have a few questions:
>
> Do you have a C-compiler for your processor? (You only say that it is
> programmable in a high-level language on your webpage.)

No, it's not C ...

> Do you know if commercial compilers for Z80 and 8051 will produce better
> results than sdcc?

I don't have access to comercial compilers for Z80/8051.

> I also note that the 8051 results were done with 6 clocks per machine
> cycle. AFAIK there are much faster 8051 cores available.

Yes, I know.
The 8051 simulator I've used ( 8051sim) computes the cycles based on
the original timing. I saw 2X cores which are just twice faster.
The one called "single cycle" do not execute all the instruction in a
single cycle (i.e. timing is dependent on the instruction, I think I
saw 1-4) so you really need a core simulator.
--
mmihai