Problems with data2mem

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

On Apr 9, 10:08=A0am, Falk Brunner <falk.brun...@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]
> =A0 =A0 =A0 =A0 BUS_BLOCK
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bram0 [15:0] LOC =3DX0Y0;
> =A0 =A0 =A0 =A0 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'.
> =A0 =A0 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]
> =A0 =A0 =A0 =A0 BUS_BLOCK
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bram0 [15:0] LOC =3DX0Y0;
> =A0 =A0 =A0 =A0 END_BUS_BLOCK;
> END_ADDRESS_SPACE;
>
> I get this error.
>
> ERROR:Data2MEM:31 - Out of bounds code segment for ram space in '..
> \pico.bmm'.
> =A0 =A0 Memory space 'ROM_SPACE' occupies [0x00000000:0x000007FF]
> =A0 =A0 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]
> =A0 =A0 =A0 =A0 BUS_BLOCK
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bram0 [17:0] LOC =3DX0Y0;
> =A0 =A0 =A0 =A0 END_BUS_BLOCK;
> END_ADDRESS_SPACE;
>
> ERROR:Data2MEM:29 - Inconsistent address space size in ADDRESS_SPACE
> 'ROM_SPACE'.
>
> =A0 =A0 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

On 9 Apr., 18:39, Patrick Maupin <pmau...@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. =A0You 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

On Apr 9, 12:43=A0pm, Falk Brunner <falk.brun...@gmx.de> wrote:
> On 9 Apr., 18:39, Patrick Maupin <pmau...@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. =A0You would fix tha=
t
> > 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

On Apr 9, 12:55=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 9, 12:43=A0pm, Falk Brunner <falk.brun...@gmx.de> wrote:
>
> > On 9 Apr., 18:39, Patrick Maupin <pmau...@gmail.com> wrote:
>
> > > You didn't show your mem file, but if it starts at, e.g. 0x200, and i=
s
> > > 0x800 long, that could explain that sort of error. =A0You would fix t=
hat
> > > 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.

Argrr, I have a STRANGE feeling.

Since I use the RAM in 18 Bits width, every data word ist 5 hex digits
long, which is 2.25 bytes. Times 1024 equals 2304 Bytes, which is
0x900.
I guess data2mem is confused by the 18 bit data width . . .
It calculates the number of nibbles instead the number of 18 bit
words.

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

0x800 = 2048 Words with 16 Bits each
0x900 = 2304 = 2048 + 256 Words with 18 Bits each

Looks like another ISE bug . . . :-(