If your design is fairly static, the BRAMs will probably not move much. You can let the tools decide where to put the BRAMs, read out the locations, and LOC them down. I usually convert the output to XDL and grep for BRAMs.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

You're correct, in this stage of the project, this BRAM I'm trying to get a hold on seems to be always put in column X0 by the tools, the Y0 value are always even between 20 and 30.

I'll look into this. Thanks for the input.

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

The errors I was receiving, something like
was due to the fact that I had not put the full name for the BRAMs I had gotten from the FPGA Editor. I was using when I should have used So now my ROM.bmm file looks like this and it passes!

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

So it successfully programmed the FPGA.

I went to change a single variable in the 65Org16.b program that controls video border color. Should change from red to white. I assembled it, made a .coe file.
Added the '$0000' to the beginning and swapped the columns, then saved as boot.mem. Added "-bd boot.mem" to the command line of bitgen.
Re-ran bitgen only to generate the .bit file for iMPACT. iMPACT recognizes that the file has changed when I go to create PROM file, then I go on to configure device using the .mcs file and the board still outputs a red border.
Tried re-running Translate, MAP and PAR, then bitgen and iMPACT, still red border.
Re-ran everything from Synthesis onward to make sure it wasn't an error on my part, and the border does turn white.
So I am missing something, but I don't see it.

EDIT: Ah, it has to do with my line in the ROM module . How do I reconcile this?

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

I think that the format of the MEM file is such that the addresses are supplied using "@aaaa" instead of "$aaaa".

A fragment of the MEM file that I used for my M16C5x project is shown below:

Two critical elements to note in this particular MEM file. First, the address and the data are specified in ASCII Hexadecimal and the address is preceded by an "@" symbol. Second, the memory uses BRAMs which are set as 4-bit components, and the MEM file data is ordered as least significant nibble first (bits 3:0), middle nibble next (bits 7:4), and most significant nibble last (bits 11:8).

I would expect that, because the 4-bit BRAM organization is what you have declared in your BMM file, you should have the data in your MEM file organized in a manner similar to that shown above: ROM[3:0], ROM[7:4], ROM[11:8], and ROM[15:12].

I suspect that the MEM file is not being processed because you are not using the "@" symbol to specify the address. After that, I suspect that we may need to create a small program to manipulate your COE file, or output file from the assembler to automatically generate the MEM file.

I did that for the M16C5x project, and we can modify it for your 65Org16 memory configuration. I've not spent a lot of time thinking about how to modify it to read the BMM file and use that information to translate the input file into a MEM file without too much operator intervention. It should be possible to create such a tool with a few constraints regarding the memory configurations which it can support.

_________________
Michael A.

Wow, very cool! It works. I am just changing a value in the .mem file (since I know where the variable is) and running bitgen then programming FPGA and it works now, no need to run MAP or PAR. It wasn't initially working, I guess the '$' forced it to ignore any further changes I was attempting to make to the .mem file until I cleaned up project files and re-ran everything. This is really great.

The only pain is having to switch those columns to get the bit lanes in alignment with the .bmm file. It's a shame it's not as simple as re-ordering the bitlanes like so:
I tried it and it doesn't work.

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

Aha! But this DOES appear to work. No column switching needed now:

So all that is needed now, in my case, is to add '@0000' and a carriage return to the .coe file and have the makefile output a .mem file to the Xilinx project folder.
Here is the makefile. Any offers?

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

EEyE:

That's really cool. If I understand your last post, the ASCII Hex .coe file out of the HXA toolset produces the data in the order that is compatible with Data2MEM by a simple addition of the correct address specification. Is that correct? It looks like the key to your change is that you put the least significant nibble in the most significant ROM, etc. This has the effect of organizing the 16-bit values output by the toolset in the correct order for Data2MEM.

Do we need to update the tutorial directions to make it easier to use Data2MEM?

_________________
Michael A.

The .coe output is just like yours, i.e. MSb on the left. I just reversed the order of the ROMs in the .bmm file, instead of ROM1 being assigned to [3:0] it is assigned to [15:12]. You could probably do the same thing in your application. Just change the order of your 3 Mrams

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

If you could confirm this, then yes it makes the whole process much easier. I'm very grateful for your tutorial, it's very well written, and I'm glad I could contribute something useful as well!


I'm not using HXA, not too familiar with the syntax, I use As65. But anyway, Arlet made the bin2.coe program awhile ago. IIRC a '-1' is for 8-bits a '-2' is for 16bit 'bytes'. It's on this page, towards the bottom.

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

I will try to do this tonight after work. It may also be helpful for enso.

Your solution is one that I did not think to try. Great insight to simply assign the bit lanes to the BRAMs in the array in reverse order. Like you, I tried several combinations of the BRAM/bit lane order. None that I tried worked, so I simply wrote my Intel Hex to MEM converter program to perform the necessary transformations.

_________________
Michael A.

EEyE:

Your solution of allocating the BRAMs in reverse order solves the issue regarding the data lanes. Thus, the rule for the BMM file is:


This rule allows a natural order for the MEM file data. Essentially, it suggests that Data2MEM uses a big-endian (least significant reference designator first) order for the assignment of the MEM file data to the data lanes defined for each BUS_BLOCK in the MEM file.

Note: For anyone interested in the M16C5x soft-microcomputer project, I will post an update to its GitHUB and OpenCores repos that incorporates EEyE's BMM fix later today. His fix also results in a change to the utility program, IH2MEM, and the source and executable will also be uploaded to those repos later today. These changes will be made to the M65C02 core's project repos later this week when the project is migrated to the XC3S200A-xVQG100I FPGA in order to incorporate enough on-chip memory to run Klaus' test programs without requiring a loader in boot ROM.

_________________
Michael A.

Hi Michael
sounds great. You mention a tutorial - do you mean the head post of this thread, or something else?
Cheers
Ed

That's correct. We may need to edit that post to incorporate EEyE's results, and make some mention of the differing requirements for the various toolsets: ISE 10.1i vs. ISE WebPACK 14.4i.

_________________
Michael A.

Michael, just FYI I was using the header post only as your tutorial during my testing on ISE14.1 on 1 BRAM on a Spartan 6...
I just now read on a little further and saw enso had previously suggested switching the order or the BRAMs called for in the .bmm file on page 1 of this thread, so he may have been onto something before me. For me it just seemed intuitive.
Anyway this is a great step forward for all of us I think.
IIRC BigEd was the one that initially brought up this subject a long time ago in some other long lost thread. But when I read the data2mem user's guide it was a foreign language. Your tutorial spoke to me in English.

EDIT: Some other observations/clarifications for a tutorial regarding users of ISE14.1 as I believe you are using ISE10.1:
1) THE 2 command line entries are still necessary:
Expand the 'Processes' window and right click on 'Translate'. Scroll down to 'Process Properties'. Scroll down to 'Other ngdbuild command line options'. Enter -bm <file>.bmm. The .bmm extension is not necessary here.
Then, in the same 'Processes' window, right click on the 'Generate Programming File'. Scroll down to 'Process Properties'. Scroll down to 'Other bitgen command line options'. Enter '-bd <file>.mem. The .mem extension is needed at this point as there are several options.

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