Saving BRAM To Facilitate Ports and New Developments

[spark2k06]

I've noticed that the core is consuming too much BRAM memory, and although MiSTer can handle it at the moment, it's starting to reach its limit.

Not only that, but it also makes it the only candidate where to be implemented with all the features it currently has, when in terms of overall resources it is not really that demanding, except for the BRAM memory:

Resources.png (8.41 KiB) Viewed 4724 times

If it were not for this BRAM memory consumption, other more modest FPGAs could benefit from all the features. We can divide the configurations into three types: Those with SRAM only, SDRAM only or a mix of both.

So the goal here would be to move the use of BRAM to SRAM or SDRAM... in the case of MiSTer almost no user has SRAM so it is forced to move it to SDRAM. However, I personally find the task of moving it to SDRAM very complex at the moment. So I have started with what is easiest, and at the same time benefits those FPGA configurations with SRAM. These are the results of the BRAM savings and what I have achieved so far:

Resources_SRAM.png (12.33 KiB) Viewed 4696 times

I have created three branches:

• Moving the BIOS to SRAM, it works correctly.
• Reducing the VRAM memory of Tandy to 32KB, it works correctly.
• Moving the VRAM to SRAM, it doesn't work... I have problems with dual port handling over SRAM, this is the result I get:

vram_to_sram.gif (2.21 MiB) Viewed 4724 times

In short, there would be two points of improvement here... let's see if someone can solve them or at least give me some guidance on how to do it:

• SRAM controller with dual port to be able to use it as VRAM.
• Move the use of BRAM to SDRAM, including dual port also for VRAM.

At the moment, with what has been achieved so far, it is possible to port to FPGAs with low BRAM and SRAM configuration, but only the 32KB VRAM version of Tandy/CGA.

[MicroCoreLabs]

Maybe you can try using distributed/LUT RAM for the 16KB of MCL86 microsequencer ROM instead of block RAM since you seem to have lots of spare LUTs?

[kitune-san]

I created test branch to use SDRAM for BIOS ROM.

https://github.com/kitune-san/PCXT_MiST ... s-on-sdram

Since it is incomplete, please note the following:
The reset signal is not handled properly, so the BIOS is not written to the SDRAM immediately after PCXT startup.
Please select BIOS manually each time.

[spark2k06]

Maybe you can try using distributed/LUT RAM for the 16KB of MCL86 microsequencer ROM instead of block RAM since you seem to have lots of spare LUTs?

Thanks for the suggestion, in MiSTer specifically we don't have a problem with LUTs consumption but it can be a problem in more modest FPGAs. Actually 16KBs of BRAM in global terms doesn't seem excessive to me, I think the point of improvement is clearly in the BIOS and VRAM, especially the one for Tandy.

I created test branch to use SDRAM for BIOS ROM.

https://github.com/kitune-san/PCXT_MiST ... s-on-sdram

Since it is incomplete, please note the following:
The reset signal is not handled properly, so the BIOS is not written to the SDRAM immediately after PCXT startup.
Please select BIOS manually each time.

Thanks for this progress, curiously the first manual BIOS loads were failing (corrupted), but after several attempts they loaded fine. I guess it's a matter of stabilizing it, in any case, it's a good start for the goal we are pursuing

[spark2k06]

I have already solved the problem with the VRAM SRAM, later I will migrate systemverilog code to verilog, in order to facilitate the port to the Xilinx platform.

I remove the SRAM branches, since they are not needed for MiSTer and I have already managed to get it working.

[kitune-san]

I have updated BIOS loader.
- BIOS write is now initiated at PCXT startup.
- Created BIOS area for Tandy.

https://github.com/kitune-san/PCXT_MiST ... ios-loader

[kitune-san]

Two problems still remain.
- The system does not boot properly after inputting a reset from the OSD.
- TandyBIOS allocation area conflicts with EMS area.

[kitune-san]

Two problems still remain.
- The system does not boot properly after inputting a reset from the OSD.
- TandyBIOS allocation area conflicts with EMS area.

Fixed!

https://github.com/kitune-san/PCXT_MiST ... ios-loader

[spark2k06]

Two problems still remain.
- The system does not boot properly after inputting a reset from the OSD.
- TandyBIOS allocation area conflicts with EMS area.

Fixed!

https://github.com/kitune-san/PCXT_MiST ... ios-loader

Thank you! I'll test it in detail tomorrow and let you know how it works.

[spark2k06]

Two problems still remain.
- The system does not boot properly after inputting a reset from the OSD.
- TandyBIOS allocation area conflicts with EMS area.

Fixed!

https://github.com/kitune-san/PCXT_MiST ... ios-loader

I was able to do a quick test... it seems that if the CPU is set to 14.318MHz the loader doesn't work.

[aberu]

Take a look at this post.

https://tomverbeure.github.io/2019/08/0 ... ories.html

https://tomverbeure.github.io/assets/mu ... 2_w2r4.png

Depending on how you need this BRAM to function you can reduce it's size dramatically and not use a ton of logic if you build an XOR based RAM for your core. There's also the additional problem of planning for hypothetical smaller FPGA when the synthesis tool for that FPGA will optimize differently, and the logic modules are not 1:1 between different models and brands of FPGA.

Anyways, here is the paper referenced in Tom's blog post:

http://people.csail.mit.edu/ml/pubs/trets_multiport.pdf

This also might be a relevant example:

https://github.com/AmeerAbdelhadi/Multiported-RAM

[kitune-san]

I was able to do a quick test... it seems that if the CPU is set to 14.318MHz the loader doesn't work.

Really? It works in my environment.

[spark2k06]

I was able to do a quick test... it seems that if the CPU is set to 14.318MHz the loader doesn't work.

Really? It works in my environment.

I have checked it again with the file you have attached, maybe it's my memory but the truth is that the ioctl_download part doesn't work if the CPU is already at 14.318Mhz, if it was previously set to another speed, it does start, and then there is no problem to set it to 14.318Mhz.

The problem is reproduced as follows. Set CPU speed to 14.318Mhz, save configuration. Then reload the core (e.g. by resetting the MiSTer and reloading from the beginning), if it doesn't work as it does for me, you will get stuck at the splash screen.

[kitune-san]

Thank you. I will fix it.

[kitune-san]

Thank you. I will fix it.

Please try it.
https://github.com/kitune-san/PCXT_MiST ... ios-loader

[spark2k06]

Thank you. I will fix it.

Please try it.
https://github.com/kitune-san/PCXT_MiST ... ios-loader

Works correctly, pull request accepted. Thank you!

[somhi]

Current implementation in MiSTer make use of non-vendor modules for allocating BRAM and thouse use double the BRAM needed I don't know why.
Using vendor-specific Altera RAM2P IP modules saves half the BRAM used for VRAM.

That way I could allocate 128 kB CGA in Neptuno, UAreloaded, Deca FPGAs and 16 kB CGA in Atlas CYC1000, SiDi and MiST.

https://github.com/somhi/PCXT_DeMiSTify

Using Altera IP's did not recognize the splash.hex because splash screen is not working now. Some guidance is needed on how to recreate better that initial content VRAM memory with the splash screen.

[spark2k06]

Using Altera IP's did not recognize the splash.hex because splash screen is not working now. Some guidance is needed on how to recreate better that initial content VRAM memory with the splash screen.

I think you should simply provide the splash screen file as binary, rather than as hexadecimal text.

[somhi]

Got Splash screen inside the RAM2P modules working.

Just needed to adapt your splash.hex to ascii-hex and then convert it to hex intel or mif format. I used srec_cat tool for it.

srec_cat splash.hex -Ascii_Hex -output splash.mif -Memory_Initialization_File

[somhi]

Infering the 8088 ROM into logic elements frees 16 M9k blocks of BRAM memory. The increment of used Logic Elements was 11641 in CYC1000 FPGA.

so that way I could use the free BRAM to add 16 kB more for CGA which allows some Tandy games to be played. Adlib music has been disabled because I had not enough logic cells.

So final numbers for PCXT with 32 kB BRAM for CGA. No MDA and No Adlib were:
- CYC1000 FPGA (Cyclone 10 LP) used resources: LEs 23953 / 24624 (97%); Memory blocks M9Ks 55 / 66 (83 %)
- SiDi FPGA (Cyclone IV E): LEs 21,713 / 22,320 ( 97 % ); M9Ks 43 / 66 ( 65 % ); Total LABs: 1,395 / 1,395 ( 100 % ) [MiST Clon with ARM]

[brunosilva]

hi
offtopic
Total LABs <= link for that one? didnt know it.
Thanks

[somhi]

I just mentioned LABS because it was 100%, but also I was not very aware of what it is. Have done a google search...

Logic Array Block (LAB) Definition
A physically grouped set of logic resources in all Intel devices supported by the Quartus® Prime software. A LAB consists of a logic cell array and, in some device families, an expander product term array. Any signal that is available to any one logic cell in the LAB is available to the entire LAB.

https://www.intel.com/content/www/us/en ... 451103.htm

[spark2k06]

Two problems still remain.
- The system does not boot properly after inputting a reset from the OSD.
- TandyBIOS allocation area conflicts with EMS area.

Fixed!

https://github.com/kitune-san/PCXT_MiST ... ios-loader

Checking some options in the latest releases, I notice that since you made the "New BIOS loader" changes, the "BIOS Writable" feature for XTIDE and/or BIOSes has been lost:

https://github.com/MiSTer-devel/PCXT_Mi ... 43b122e9bf

It is a feature that is interesting at times, such as for debugging tests. These are the status [31:30] in PCXT.sv:

Code: Select all

.bios_writable                      (status[31:30])

It's not essential, but when you have some time, can you take a look at it?

Thanks!

[kitune-san]

OK. wait a few hours please.

[spark2k06]

OK. wait a few hours please.

Don't worry

[kitune-san]

Please check this branch.
https://github.com/kitune-san/PCXT_MiST ... 45cf4e14c0