Page 1 of 1
Saving BRAM To Facilitate Ports and New Developments
Posted: Fri Sep 16, 2022 6:12 am
by 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 4712 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 4684 times
I have created three branches:
- vram_to_sram.gif (2.21 MiB) Viewed 4712 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.
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Sun Sep 18, 2022 8:47 pm
by 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?
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Mon Sep 19, 2022 3:23 pm
by 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.
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Tue Sep 20, 2022 3:27 am
by spark2k06
MicroCoreLabs wrote: ↑Sun Sep 18, 2022 8:47 pm
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.
kitune-san wrote: ↑Mon Sep 19, 2022 3:23 pm
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
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Wed Sep 21, 2022 4:05 pm
by 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.
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Fri Sep 23, 2022 5:48 am
by 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
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Fri Sep 23, 2022 7:19 am
by 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.
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Fri Sep 23, 2022 11:32 am
by kitune-san
kitune-san wrote: ↑Fri Sep 23, 2022 7:19 am
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
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Fri Sep 23, 2022 12:15 pm
by spark2k06
Thank you! I'll test it in detail tomorrow and let you know how it works.
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Fri Sep 23, 2022 2:00 pm
by 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.
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Fri Sep 23, 2022 2:26 pm
by 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
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Fri Sep 23, 2022 2:43 pm
by kitune-san
spark2k06 wrote: ↑Fri Sep 23, 2022 2:00 pm
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.
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Fri Sep 23, 2022 3:01 pm
by spark2k06
kitune-san wrote: ↑Fri Sep 23, 2022 2:43 pm
spark2k06 wrote: ↑Fri Sep 23, 2022 2:00 pm
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.
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Fri Sep 23, 2022 3:07 pm
by kitune-san
Thank you. I will fix it.
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Fri Sep 23, 2022 4:25 pm
by kitune-san
kitune-san wrote: ↑Fri Sep 23, 2022 3:07 pm
Thank you. I will fix it.
Please try it.
https://github.com/kitune-san/PCXT_MiST ... ios-loader
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Sat Sep 24, 2022 3:34 am
by spark2k06
Works correctly, pull request accepted. Thank you!
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Thu Sep 29, 2022 10:08 pm
by 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.
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Fri Sep 30, 2022 9:04 am
by spark2k06
somhi wrote: ↑Thu Sep 29, 2022 10:08 pm
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.
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Sat Oct 01, 2022 3:43 pm
by 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
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Sat Oct 01, 2022 10:45 pm
by 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]
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Sun Oct 02, 2022 6:28 pm
by brunosilva
hi
offtopic
Total LABs <= link for that one? didnt know it.
Thanks
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Sun Oct 02, 2022 9:01 pm
by 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
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Tue Oct 25, 2022 1:11 pm
by spark2k06
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:
It's not essential, but when you have some time, can you take a look at it?
Thanks!
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Tue Oct 25, 2022 1:44 pm
by kitune-san
OK. wait a few hours please.
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Tue Oct 25, 2022 2:01 pm
by spark2k06
kitune-san wrote: ↑Tue Oct 25, 2022 1:44 pm
OK. wait a few hours please.
Don't worry
Re: Saving BRAM To Facilitate Ports and New Developments
Posted: Tue Oct 25, 2022 2:04 pm
by kitune-san
