I certainly missed enso's hint. Regardless, I'm certainly very glad you (and enso) have helped clarify the mechanism used for a BRAM array using a single address space and one bus block. It certainly makes the generation of the MEM file much easier from the binary to ASCII conversion programs that enso, Arlet, and I have generated for generating COE/MIF files. And BigEd was also an instigator to this thread.

With this behind us, the next step would be to extend the BMM file to support multiple address spaces (multiple memory controllers). This should allow the independent patching of one or more memories. It would be particularly useful in the case of my M65C02 microprogrammed core. With such a capability, it would be possible to update the user RAM, the boot ROM, and the microprogram memories.

_________________
Michael A.

Hi.
Trying to get ngdbuild working. After multiple error/fix loops, I have reached dead end in to this:
INTERNAL_ERROR::45 - Memory allocation leak of 27 bytes at 0x044012DC for a StrN
ew.
Total memory in use at allocation was 704004332 bytes.
Source file "BmmUtils.c", line number 3059.

My BMM file:

ADDRESS_SPACE PROM RAMB16 [0x00000000:0x000007FF]
BUS_BLOCK
ram/bram_256 [7:0];
END_BUS_BLOCK;
END_ADDRESS_SPACE;

I'm aware that error 45 happens when block name is inorrect. I think I have tried every compination with or without top-instance name I can imagine. Even this one "ram/bram_256/U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/s3_init.ram/dpram.dp9x9.ram". Actually, the long one completes without errors. Just that no LOC information added and it says that "No Partitions were found in this design.".

I'm a bit stuck...

You have to open FPGA Editor find your RAM instances, and see the full name the Editor gave it. Also, you must specify the LOC.

I highlighted the 4 used for a ROM in my project below.

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

Hello.

Thanks for the confirmation. It really was this ""ram/bram_256/U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/s3_init.ram/dpram.dp9x9.ram" all the time!
I didn't believe it earlier, but now added it to project and PAR'ed with -bm attribute and look the miracle: _bd.bmm was created with proper info added!
Thanks!

Axel.

6502sbc:

Just curious as to why you're using CoreGen to generate your memory? I think that you can infer the RAM that you want much more easily than you anticipate. enso doesn't infer block RAM either, but he instantiates block RAM components from the HDL components library.

Either by instantiation or inference, you can reduce the length of the hierarchical name of your block RAMs, and still get the desired organization and architecture. Furthermore, I think you'll find that the Coregen outputs must be periodically regenerated as the tool and its library are updated. Thus, I think either direct instantiation or inference will give you better portability across multiple versions of the tools.

Either EEyE or I can provide you some examples of inferred block RAMs if that's an issue for you. Beyond that, I almost always consult the coding examples in the synthesis section of the verilog/VHDL "light bulb" tool, i.e. on-line ISE language reference. It provides easy to use templates for most infer-able common memory configurations, and I make liberal use of those examples in my code.

_________________
Michael A.

Hello,


I'm sure there are many better ways to add block ram but I'm taking first steps (Literally). I haven't paid much attention to coregen - which works fine for now.

But... I fully agree what you're saying.
I made a small mem-file and embedding to bit-file works like a Buick. Nice.

Thank you for your support and advice!

Axel.

6502sbc:


I've worked with FPGAs for many years now. But only recently have I started using Data2MEM. It sure does make a world of difference particularly when using block RAMs as memories for soft-core processors.

enso indicated that he was using it and saving quite a bit of time by not having to re-synthesize the FPGA to load a new program for his soft-core 6502 implementation. I did a little experimentation with the tool, and am now a firm believer in the process.

I am currently working to determine if I can use the tool to patch multiple memory blocks of different organizations. The Data2MEM documentation appears to support this premise, but I've not yet gotten such a project to the testing stage.

_________________
Michael A.

I've at least got it to pass with no errors when generating the program file.
In addition to the 4Kx16 ROM it formats the 1Kx16 zeropage RAM.
No changes to the 'Other ngdbuild Command Line Options' under Translate.
However, 'Other BitGen Command Line Options' looks like:-bd ROM.mem -bd ZP.mem

As a test, I changed my graphics generator to read a value from $100003FF (last 'byte' in ZPRAM) and use it as the border color. The zero page pointer is $1000.
Does not appear to be working yet.

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

EEyE:

Thanks very much for your last post. It answers both questions that I had regarding the additional "memory controllers": (1) does handle more than one address space, and (2) can the address spaces have different organizations.

Furthermore, it demonstrates that no special tools are required to combine the mem files into one: simply add the required mem files to the BitGen command line.

Great post.

_________________
Michael A.

Thanks, I figured everything was in place so it wouldn't be too difficult to test. Turns out, almost everything (I think)...

I think I know why the ZPRAM is not initializing. It's because I don't have a similar line of code in the ZPRAM module like I have in the SYSROM module that initializes the blockRAM like a ROM. The following is from the SYSROM module is not present in the ZPRAM module:
When I have some more free time, I will confirm this.
But as I stated, ISE14.1 is not coughing up errors with this experiment present in my project. I suspect the software is just reading zero's, as the ZPRAM has not been properly initialized by a lacking .coe file within the PVBRAM2 Project folder for the ZPRAM module itself..

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

I will have a chance today to do this as I have a mini-vacation starting today.

I've been enjoying using the method in this thread to patch the 65Org16's blockRAM, it actually makes troubleshooting enjoyable again.

Michael, when you have updated your software how are you going about overwriting the ***.mem file in your project folder?

Have you developed an easier process than manually adding @0000 to your .coe file equivalent and then overwriting the ***.mem file, like I'm doing below?

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

For the M16C5x, I wrote a little utility which adds the addresses to the file. I run it within a DOS box, and use a little batch file to automate the process of assembling, converting the assembler output file to a mem file, and then copying the mem file to the destination directory.

I will modify the binary to hex utility I wrote for the M65C02 to do the same, and then just modify the DOS batch file to copy the mem file instead of the ASCII hex coe file. Both files need to be generated so that the final configuration of the block RAM can be determined before BitGen. Since the BitGen command line will likely reference the BMM file and mem files, generating a coe file is no really longer necessary. However, in simulation, ISim reloads the coe files for any memories which include an initial $readmemh() or $readmemb() for pre-synthesis inialization of their contents.

I am thinking that it may be possible to use DOS batch to create a mem file that is just the required address line and then append the hex file to that file. Looking at the DOS copy command, it is possible to copy multiple source files, separated by "+" symbols, into a single destination file. Thus, create a file that contains the single @address line that you use, and then use copy to create a single destination file:



I tried this DOS command using a Data2MEM-compatible address file I created from the console/command line:

The resulting destination file is the addrs.mem appended to m65c02.txt (my Boot ROM memory initialization file). Note: the /A preceding each of the file names indicates that the files are ASCII files rather than binary (/B) files.

_________________
Michael A.

I wrote a small utility to convert bin files to mem files and insert address to the first line. Maybe you have wrote plenty of these already, but anyway. I also use "case" style rom module so the converter supports case-style output as well.
DOS shell program.

Axel.

Hi. Could you advice where I should put LOC line to? I can add


into the verilog (where the bram is defined) file but can't add name after LOC text. I assume it is needed to tell which bram is being freezed to the exact location.
However it compiles but I can't tell position is actually locked or are the lines ignored.

Axel.

6502sbc:

As enso pointed out, he applies the LOC attribute to the component that he instantiates from the HDL library. Those components represent single Block RAM instances. As such, the LOC attribute applies only to that one Block RAM. If your Coregen macro represents more than one Block RAM, the single LOC attribute provided by your or enso's example will not be sufficient.

You have indicated that you ran the tool chain with the BMM file set as an option, and noted that the BMM_File_bd.bmm file was created by Data2MEM as expected. That file, if you examine it, contains all of the LOC attributes needed. I simply took that file, renamed it, and edited the locations so that the Block RAMs were assigned in a contiguous, natural manner for my project. I intend to follow the same procedure for my newest project, which will use all of the Block RAMs in my FPGA.

If you truly want to LOC the Block RAMs from the Verilog source file level, I think that you will need to infer or instantiate the components as single Block RAMs in a memory module. Before each single Block RAM inference or instantiation in this module, you will need to apply a synthesis directive, "(* ... *)", with the desired LOC attribute immediately before each Block RAM you have defined.

Because the module creates another level of hierarchy, the path name for each Block RAM in your BMM file will also require adjustment. However, because you've changed from Coregen to inference/instantiation, the path/component name of your Block RAMs will be a lot shorter than the one you posted earlier.

_________________
Michael A.