Remove generic ROM_LINES from block_rom.vhd and rom_from_file.vhd

[MJoergen]

This will simplify the release process, by not having to update these values manually.

[sy2002]

Cool - I did not even know, that this is possible ;-) Would be awesome, after you fixed that for the nexys4ddr hardware, if you could also fix it for the MEGA65 hardware and assign the issue to me afterwards so that I test on real MEGA65 hardware. If I got it correctly, that means that you would change the following files:

vhdl/env1_globals.vhd
vhdl/block_rom.vhd
vhdl/hw/nexys4ddr/env1.vhd
vhdl/hw/MEGA65/mega65_globals.vhd
vhdl/hw/MEGA65/MEGA65_ISE.vhd
vhdl/hw/MEGA65/MEGA65_Vivado.vhd
hw/xilinx/nexys4ddr/ISE/env1.xise
hw/xilinx/nexys4ddr/Vivado/qnice_nexys.xpr

This is quite a lot :-)

EDIT: And we must not forget the PORE ROM, when doing this.

[MJoergen]

The initial intent with this issue was to make small easy changes. Definitely something that we can do just before release of V1.6, together with the line ending cleanup.

Your extra suggestions are definitely the direction we should go in, and indeed is very much possible and doable. But that is best postponed to V1.7. I think we have more than enough for V1.6 already. So perhaps make a new issue to increase portability and clean up the build environment.

[sy2002]

You are right. :-) So I made an edit, deleted all the off-topic stuff and made a new issue #41 for the future stuff.

And this issue is now cleanly about the generic ROME_LINES.

Let's do it in develop after we merged all the branches back to develop.

Things we must not forget to change, too, when changing this:

• PORE ROM

• Simulations that are using BROM: vhdl/sim/dev_int.vhd and vhdl/hw/MEGA65/sim/sim_hram_dbg.vhd

[MJoergen]

Fixed and verified using both ISE and Vivado.

Still need to deal with MEGA65 target => Reassigned to @sy2002.

[sy2002]

Thank you. This is an important automation step and reduces the overall release and maintenane complexity. I will take care of the MEGA65 target.

[sy2002]

Just a quick question on the implementation: The size of the ROM seems to be now constantly ~16kWords? Or is the synthesizer smarter and just will utilize as much space as we need?

[MJoergen]

The synthesizer is smart and will make the same implementation as before.

[MJoergen]

Fixed and closed.

[sy2002]

@MJoergen Great Solution. Thank you! 👍
@bernd-ulmann We now have much more free RAM on the FPGA, while not needing to manually adjust the ROMSIZE of the monitor ROM, the font ROM, the PORE ROM and other...