Prev: ISE Timing Constraints
Next: Module wise FPGA resource utilization report
From: Falk Brunner on 9 Apr 2010 11:08
Hello everybody,

long time no see. ;-)

Now that I return to FPGA design at least for hobby purposes, I have
some trouble with data2mem. Iam using Webpack 11.1. I want to use
Picoblaze in a Spartan 3A 700. For updating of the program memory I
use data2mem, but without success. :-(

Here is my bmm file

ADDRESS_SPACE ROM_SPACE RAMB16 [0x0000:0x09FF]
BUS_BLOCK
bram0 [15:0] LOC =X0Y0;
END_BUS_BLOCK;
END_ADDRESS_SPACE;


here my command line for data2mem

data2mem -i -bm ..\pico.bmm -bd pico_bas.mem -bt ..\top_picoblaze.bit -
ob ..\top_picoblaze_prog.bit

When I do so, I get the following error message

ERROR:Data2MEM:29 - Inconsistent address space size in ADDRESS_SPACE
'ROM_SPACE'.
ADDRESS_SPACE was defined as 0x00000A00 bytes, but the
ADDRESS_RANGE total is 0x00000800 bytes.

When I change the definition in the BMM file to

ADDRESS_SPACE ROM_SPACE RAMB16 [0x0000:0x07FF]
BUS_BLOCK
bram0 [15:0] LOC =X0Y0;
END_BUS_BLOCK;
END_ADDRESS_SPACE;

I get this error.

ERROR:Data2MEM:31 - Out of bounds code segment for ram space in '..
\pico.bmm'.
Memory space 'ROM_SPACE' occupies [0x00000000:0x000007FF]
Code segment #0 occupies [0x00000000:0x000009FF]

The documentation of data2mem is sometimes confusing. At one place it
says there is only RAMB16 for Spartan 3, at another line it says
RAMB18 is available for Spartan 3.

Also using RAMB18 does not work.

ADDRESS_SPACE ROM_SPACE RAMB18 [0x0000:0x07FF]
BUS_BLOCK
bram0 [17:0] LOC =X0Y0;
END_BUS_BLOCK;
END_ADDRESS_SPACE;

ERROR:Data2MEM:29 - Inconsistent address space size in ADDRESS_SPACE
'ROM_SPACE'.

ADDRESS_SPACE was defined as 0x00000800 bytes, but the
ADDRESS_RANGE total is 0x00000900 bytes.

Any hint is appreciated.

Regards
Falk
From: Patrick Maupin on 9 Apr 2010 12:39
On Apr 9, 10:08 am, Falk Brunner <falk.brun...(a)gmx.de> wrote:
> Hello everybody,
>
> long time no see. ;-)
>
> Now that I return to FPGA design at least for hobby purposes, I have
> some trouble with data2mem. Iam using Webpack 11.1. I want to use
> Picoblaze in a Spartan 3A 700. For updating of the program memory I
> use data2mem, but without success. :-(
>
> Here is my bmm file
>
> ADDRESS_SPACE ROM_SPACE RAMB16 [0x0000:0x09FF]
>         BUS_BLOCK
>                 bram0 [15:0] LOC =X0Y0;
>         END_BUS_BLOCK;
> END_ADDRESS_SPACE;
>
> here my command line for data2mem
>
> data2mem -i -bm ..\pico.bmm -bd pico_bas.mem -bt ..\top_picoblaze.bit -
> ob ..\top_picoblaze_prog.bit
>
> When I do so, I get the following error message
>
> ERROR:Data2MEM:29 - Inconsistent address space size in ADDRESS_SPACE
> 'ROM_SPACE'.
>     ADDRESS_SPACE was defined as 0x00000A00 bytes, but the
> ADDRESS_RANGE total is 0x00000800 bytes.
>
> When I change the definition in the BMM file to
>
> ADDRESS_SPACE ROM_SPACE RAMB16 [0x0000:0x07FF]
>         BUS_BLOCK
>                 bram0 [15:0] LOC =X0Y0;
>         END_BUS_BLOCK;
> END_ADDRESS_SPACE;
>
> I get this error.
>
> ERROR:Data2MEM:31 - Out of bounds code segment for ram space in '..
> \pico.bmm'.
>     Memory space 'ROM_SPACE' occupies [0x00000000:0x000007FF]
>     Code segment #0 occupies [0x00000000:0x000009FF]
>
> The documentation of data2mem is sometimes confusing. At one place it
> says there is only RAMB16 for Spartan 3, at another line it says
> RAMB18 is available for Spartan 3.
>
> Also using RAMB18 does not work.
>
> ADDRESS_SPACE ROM_SPACE RAMB18 [0x0000:0x07FF]
>         BUS_BLOCK
>                 bram0 [17:0] LOC =X0Y0;
>         END_BUS_BLOCK;
> END_ADDRESS_SPACE;
>
> ERROR:Data2MEM:29 - Inconsistent address space size in ADDRESS_SPACE
> 'ROM_SPACE'.
>
>     ADDRESS_SPACE was defined as 0x00000800 bytes, but the
> ADDRESS_RANGE total is 0x00000900 bytes.
>
> Any hint is appreciated.
>
> Regards
> Falk

You didn't show your mem file, but if it starts at, e.g. 0x200, and is
0x800 long, that could explain that sort of error. You would fix that
by using a space like [0x200:0x9FF].

Regards,
Pat
From: Falk Brunner on 9 Apr 2010 13:43
On 9 Apr., 18:39, Patrick Maupin <pmau...(a)gmail.com> wrote:

> You didn't show your mem file, but if it starts at, e.g. 0x200, and is
> 0x800 long, that could explain that sort of error.  You would fix that
> by using a space like [0x200:0x9FF].

Its pretty simple, it starts with @00000000, followed by 1024 lines of
five digit hex numbers, representing the 18 Bit Opcodes of Picoblaze.

Regards
Falk
From: Patrick Maupin on 9 Apr 2010 13:55
On Apr 9, 12:43 pm, Falk Brunner <falk.brun...(a)gmx.de> wrote:
> On 9 Apr., 18:39, Patrick Maupin <pmau...(a)gmail.com> wrote:
>
> > You didn't show your mem file, but if it starts at, e.g. 0x200, and is
> > 0x800 long, that could explain that sort of error.  You would fix that
> > by using a space like [0x200:0x9FF].
>
> Its pretty simple, it starts with @00000000, followed by 1024 lines of
> five digit hex numbers, representing the 18 Bit Opcodes of Picoblaze.
>
> Regards
> Falk

Well, in that case, it's 17:0, not 15:0, for the width, no?

Regards,
Pat
From: Patrick Maupin on 9 Apr 2010 13:58
On Apr 9, 12:55 pm, Patrick Maupin <pmau...(a)gmail.com> wrote:
> On Apr 9, 12:43 pm, Falk Brunner <falk.brun...(a)gmx.de> wrote:
>
> > On 9 Apr., 18:39, Patrick Maupin <pmau...(a)gmail.com> wrote:
>
> > > You didn't show your mem file, but if it starts at, e.g. 0x200, and is
> > > 0x800 long, that could explain that sort of error.  You would fix that
> > > by using a space like [0x200:0x9FF].
>
> > Its pretty simple, it starts with @00000000, followed by 1024 lines of
> > five digit hex numbers, representing the 18 Bit Opcodes of Picoblaze.
>
> > Regards
> > Falk
>
> Well, in that case, it's 17:0, not 15:0, for the width, no?
>
> Regards,
> Pat

Oh, I see what you mean. I've never used the parity bits, so I don't
know how that works.
 |  Next  |  Last
Pages: 1 2
Prev: ISE Timing Constraints
Next: Module wise FPGA resource utilization report