I've forgotten how to implement this whole process! How do we invoke data2mem?
I understood the part of finding and LOCing down the 'ROM' using PlanAhead... I guess my main question, as I do have an old project with the command line additions form .bmm and .mem, how do we start the process?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I've finally got around to getting this set up for my own design. I don't use the IDE, so this is all based on the command line.

First, I have all of my ROMs explicitly instantiated as BRAMs (RAMB16BWER). There's no need to lock these to particular positions - the tools handle that automatically. In my case, I have a 4K*16 ROM for the character bitmaps, and an 8K*16 ROM for the 'kernal' (my project is a descendant of the Commodore 64, so I've taken the traditional name and spelling).
The character ROM is implemented as 4 BRAMs, each contributing 4 bits of the output word. The kernal ROM is 8 BRAMs, each contributing 2 bits.

Here's the .bmm file:

Each line in the BUS_BLOCKs specifies one of the BRAMs. There's a range of bits in square brackets for each, but this is not used for inserting data into the bitstream. Instead, the order of BRAMs is used. Data from the .mem file is read N bits at a time, and placed into the BRAMs in the order they appear in the .bmm file. So they have to be given high bits first (the alternative is to swap the bits around in the .mem file). The address range in the ADDRESS_SPACE lines is given in bytes, so although my character ROM is 4K*16, I have to say that it's 8K bytes. There might be better way to handle this, but I haven't found it.

Next, the contents of the .bmm file must be included in the design. This is done by adding "-bm source/c640.bmm" to the command line for ngdbuild. At the end of the build process, bitgen will create a new .bmm file called "c640_bd.bmm". This contains the same definitions as the originals, but has the locations of each BRAM attached. This is the file used by data2mem.

The data to be placed into the BRAMs goes in .mem files. Here's my current one for the kernal ROM:

(My CPU is an extended 6502 with a 16 bit data bus; that's why there are 6502 opcodes in the bottom half of the words)

I'm lying to the software here, telling it that my ROMs are both at address 0. Since they're in different address spaces, they don't overlap. I couldn't work out how to tell it that my ROMs are 16 bits wide, so it's counting everything in bytes. The addresses will all be wrong anyway, so I might as well tell it that they start at 0.

Finally, data2mem is used to insert the contents of the .mem files into the bitstream. Here's the command for that:

The tag identifies which address space this data goes into. It's the name given in the ADDRESS_SPACE line. The original bitstream is read from c640.bit, and the new one is written to c640_final.bit. It seems you can't give the same file for these - the original will get deleted before anything is read from it.

This saves so much time. Instead of waiting minutes for the whole design to resynthesise, I can have new code running on the FPGA board in a few seconds.

Excellent, thanks for the detailed commands.