From: bh.ines1806 on
Hi all,
I have a Spartan 3 Starter Board.
I want to make a simple application with microblaze.
But when I generate the bitstream an error error has appeared wich is:
ERROR:Pack:2310 - Too many comps of type "RAMB16" found to fit this
device.
ERROR:Map:115 - The design is too large to fit the device. Please
check the
Design Summary section to see which resource requirement for your
design
exceeds the resources available in the device. Note that the number
of slices
reported may not be reflected accurately as their packing might not
have been
completed.

NOTE: An NCD file will still be generated to allow you to examine
the mapped
design. This file is intended for evaluation use only, and will
not process
successfully through PAR.

Mapping completed.
See MAP report file "system_map.mrp" for details.
Problem encountered during the packing phase.

Design Summary
--------------
Number of errors : 2
Number of warnings : 18
ERROR:Xflow - Program map returned error code 2. Aborting flow
execution...
make: *** [__xps/system_routed] Error 1
Done!
This error bothers me and I can't understand where is the problem
resides??
Note that my design and my software application are as simple as
possible, and I was respected the address range of lmb_bram_if_cntlr
(8k for spartan 3).
If anybody has a useful idea,i Iwill be thankfull if he give me some
help.
Best Regards,
INES
From: austin on
Ines,

What is it about "it does not fit, you used too many BRAMs, please
examine these files to discover your error" that you do not
understand?

Remember the BRAM blocks are in kilobits, not kilobytes. It is very
easy to exceed the number of BRAMS in a part by simple requiring too
much addressable memory space,

Additionally, if you are specifying cache for the MicroBlaze core,
that cache will also eat up BRAM blocks, depending on how much cache
you requested (for data and/or instructions).

Austin

From: Gabor on
On Feb 18, 11:00 am, austin <aus...(a)xilinx.com> wrote:
> Ines,
>
> What is it about "it does not fit, you used too many BRAMs, please
> examine these files to discover your error" that you do not
> understand?
>
> Remember the BRAM blocks are in kilobits, not kilobytes.  It is very
> easy to exceed the number of BRAMS in a part by simple requiring too
> much addressable memory space,
>
> Additionally, if you are specifying cache for the MicroBlaze core,
> that cache will also eat up BRAM blocks, depending on how much cache
> you requested (for data and/or instructions).
>
> Austin

There's also a bug in ISE 10.1 that causes overmapping of BRAM
if you check "Map slice logic into unused block RAMs". Makes
me wonder what part of "unused" the tools don't understand.

- Gabor
From: austin on
Gabor,

Using BRAM blocks as 'look up tables' for logic is a way to pack more
"stuff" into the design, so, yes, the BRAMs are only "unused" until
you then use them for this purpose (the English language is probably
one of the worst languages for describing technical stuff, except for
all the others).

That is a fairly arcane use of the BRAM blocks, and it would be
interesting to know how often folks do this,

Austin
From: bh.ines1806 on
On Feb 18, 7:48 pm, austin <aus...(a)xilinx.com> wrote:
> Gabor,
>
> Using BRAM blocks as 'look up tables' for logic is a way to pack more
> "stuff" into the design, so, yes, the BRAMs are only "unused" until
> you then use them for this purpose (the English language is probably
> one of the worst languages for describing technical stuff, except for
> all the others).
>
> That is a fairly arcane use of the BRAM blocks, and it would be
> interesting to know how often folks do this,
>
> Austin

Hi,
Thank you (Austin and Gabor) for the answers.
But is this error caused by the fact that the application software is
big enough? I dont' think so cause the soft application is very
simple, it just light the 8 LEDs.
Also in the MHS file I put 16k for DLMB and 16k for the ILMB too!
So I couldn'tt understand where the problem lies: in the design in
hard or soft implementation!!
I will be thankfull if you give me some help!!

Best Regards,
Ines